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: Steve Whalen Subject: Re: Time to join the fold? Date: 1999/01/23 Message-ID: #1/1 X-Deja-AN: 435975051 Sender: swhalen@netcom2.netcom.com References: <78abg4$cnc$1@its.hooked.net> Organization: ? Newsgroups: comp.lang.ada Date: 1999-01-23T00:00:00+00:00 List-Id: What Tucker said... AND >From a technical management perspective, I'll try to throw in another "dimension" to the guess work on: How long will it take for an experienced programmer coming from C or Assembler or other language that does not "impose" significant type and structure discipline on the programmer, to become productive in Ada95. Obviously, there's no real answer: maybe a few months, maybe never, depending on the person and support they get (or don't get). However, you have one important, but usually overlooked advantage to learning and using Ada95 effectively: You already know your problem domain. The only way I can think of to illustrate my "dimension" is with the dreaded "hypothetical": the scenario: Experienced Assembly language programmers (of "equal" talent/productivity) are both assigned to learn a new problem domain AND a new language and implement a small system (both are learning the same new problem domain, one will program in C, the other Ada95). I can almost guarantee you that the person learning C will appear to be more productive early on in the "race" because the compiler will not place any roadblocks in their way. The C programmer will probably have a functioning program before the (frustrated) Ada95 programmer has gotten the first program to compile. However, toward the end of the "race", the Ada95 programmer should have a (correctly) functioning SYSTEM, while the C programmer is still debugging PROGRAMS (because of the deep logic flaws that untyped languages tend to encourage, or at least give you no help in finding). >From my experience, I'd say you are in a BETTER position to switch to Ada95 than most, because you alread have a working "program", and therefore, a thorough knowledge of your problem domain (although as Tucker points out, you may have logic bugs you'll discover in your current system just from trying to properly define them to Ada95). I'd present Ada95 to management as a way to produce a higher quality end product, and NOT oversell it as a way to get "something" functioning the fastest. Maybe another way to say it: C will almost always win the race to get the first "something" running, but Ada95 will win the race to get a stable, quality product into customers hands. Steve P.S. Please note that I did not include C++ in the "early race winning" category on purpose. While I don't want to start another Ada95 vs C++ war, my oveservation is that while C++ has some neat features, I see too many projects that spin out of control because with C++ you don't get the "mandatory benefits" that come with the strongly typed/structured approach of Ada95, but you do get much of the complexity/power. To badly paraphrase a quote I once saw attributed to C++'s designer: C makes it easy to shoot youself in the foot, C++ makes it a little harder to shoot yourself, but when you do, you blow your whole leg off [end of bad paraphrasing job]... My observation from real world C++ projects (most poorly managed) is that C++ makes it pretty easy to blow up whole city blocks, especially when there is weak management of the system design and development process. In less than perfect environments, I think you still get a lot of Ada95's benefits, often in spite of the environment. However, it IS possible to have a management and environment so undisciplined that I'd recommend C over Ada95 too (and for the same reasons I recommend Ada95 over C++ "in general": fewer city blocks blown up, and the project eventually gets done (if not done "well")). -- {===--------------------------------------------------------------===} Steve Whalen swhalen@netcom.com {===--------------------------------------------------------------===}