From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f25e853f410d55da X-Google-Attributes: gid103376,public From: stt@houdini.camb.inmet.com (Tucker Taft) Subject: Re: Time to join the fold? Date: 1999/01/22 Message-ID: #1/1 X-Deja-AN: 435790133 Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.camb.inmet.com References: <78abg4$cnc$1@its.hooked.net> Organization: Intermetrics, Inc. Newsgroups: comp.lang.ada Date: 1999-01-22T00:00:00+00:00 List-Id: Mike Silva (mjsilva@jps.net) wrote: : ... : Now for my questions (all assuming that I determine that switching to Ada is : a good idea). First, how long would it take me (a long-time C [and a bit of : C++] programmer) to get productive in Ada? Not long. If you tend to be a C programmer who writes one ".h" file for every ".c" file, and who tries to minimize the amount of information exposed in the .h file, then you already know the fundamental idea of a package and a private type, with a separation between package spec and body. Using packages right is really the key to using Ada, and to some extent using appropriate modularization via .h/.c pairs is the key to using C right. One of the great things about Ada is that the compiler is so picky, that it helps you learn the rules of the language more quickly. You can make that even better by minimizing your use of predefined numeric types like "Integer," but instead defining your own numeric types with the appropriate range. Then the compiler will help more in catching the use of the wrong type as an array index, or the wrong type passed to a function or procedure. : ... Second, what is the best way to : present the case to my boss? He's open-minded, but switching to a new : language that I don't know is bound to require plenty of justification. Almost all of the Ada 95 compilers have excellent interoperability with C. Rather than trying to rewrite the whole thing right away, pick a well defined abstraction (i.e. one of those .h/.c pairs), and rewrite that in Ada. For fun, you might want to pick one that has been a major source of bugs in the past. For simplicity, pick one that has relatively few external interface points exposed in the .h, but plenty of groddy internal interactions in the .c. Or pick a new abstraction associated with some particular enhancement, and write that part in Ada, while the main part of the program is still in C. : I know of most of the main Ada web sites and the success stories and "why Ada" : articles they have, but I was wondering if some of you might have further : opinions and/or experiences in "converting" a project or company to Ada. Start with a small piece, and work up slowly. Try to keep track of how many bugs are caught by the compiler, caught by run-time checks, or left to you to track down at run-time. I think you will be very impressed with how few bugs make it through to the painful debugging stage. A remarkable percentage of mistakes, sometimes even relatively deep "logic errors," are caught by the compiler and the compiler-generated run-time checks. My usual analogy is giant slalom gates on a ski slope. Any hacker on skis can make it through one giant slalom gate. But if you start to pepper the slope with slalom gates, only a skier who has a deeply correct approach to skiing can make it through them all. Each compile-time and compiler-generated run-time check is trivial in its own right, just checking that two types match, or that a value is in some range. But for a program to make it all the way through all of these consistency checks, it needs to be internally consistent and logical in a deep sense. Otherwise it is almost certain to be tripped up by one of these "trivial" checks. And based on empirical experience, a program with a bug generally gets tripped up by one of these checks remarkably close to the source line where the underlying flaw resides. : Thanks a bunch for any insights. : Mike Silva -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA