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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3a9b49a9162025eb X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-02-06 10:18:26 PST Message-ID: <3E42A61C.20905@cogeco.ca> From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Bye-bye Ada ? (Ada95 Wholesale Changes?) References: <3E3B7BB5.A1A070@adaworks.com> <3NY_9.9226$x63.6255@nwrddc01.gnilink.net> <3E40A07A.CD174746@adaworks.com> <1044457651.769640@master.nyc.kbcfp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 06 Feb 2003 13:14:52 -0500 NNTP-Posting-Host: 198.96.47.195 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1044555293 198.96.47.195 (Thu, 06 Feb 2003 13:14:53 EST) NNTP-Posting-Date: Thu, 06 Feb 2003 13:14:53 EST Organization: Bell Sympatico Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!snoopy.risq.qc.ca!torn!webster!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Xref: archiver1.google.com comp.lang.ada:33840 Date: 2003-02-06T13:14:52-05:00 List-Id: Hyman Rosen wrote: > Richard Riehle wrote: > >> In Ada, used well > > I suspect that you are a Japanese Joiner as well :-) > > I think that any of the regular posters here would be > able to program as well in C++ as in Ada. I'm pretty > sure that if I had to work in Ada it wouldn't take me > very long to get up to expert level. Well, I can say that for small projects, your statement is probably true. But I can speak for my own experience, that in largish C++ projects, I always spent an incredible amount of time looking in core files and working with a debugger to find out why some "strange behaviour" was happening in those C++ projects. Sometimes it was related to those automatic type promotions, and at other times, it was related to memory corruption problems of one sort or another (and it need not even be your own code! Sometimes C++ library code does this to you). On top of all this, once you get your large C++ application to actually work, you then want to "port it" to another platform, with sometimes a different compiler (or even a different/updated gcc compiler). What do you find? - Changed behavior in automatic type promotion, leading to changed application behavior - #include file problems - C++ library incompatibilities/limitations Sure you can say that this occurs due to poor planning, or design. But the Ada point is that this is not checked, nor enforced up front by your tools. My hobby time is time I hate wasting this way ;-) In smallish projects, Ada sometimes takes me longer. This is usually due to library issues and bindings. The payoff is huge though (for me) in largish projects. In the last 4 years (I think) of using Ada (since my conversion ;), I've only encountered memory corruption once (I had freed an object twice due a logic/design error). The rest of my time is "quality time with the compiler", learning how to avoid certain design errors, and learning how to better engineer modules so that the dependencies are pure and correct (C++'s elaboration is pale by comparison). My debugging time is 25% or less of the C++ debugging time. (This gives me a much more pleasant use of my hobby time). When I debug, it is because I am finding out why _I_ made some logic error. It is not due to corruption, or some faulty elaboration order; not due to external memory references that the linker decided were the same (name collision), not due to #include file sequence, not due to automatic type promotion surprises etc. SUMMARY: I don't agree with your statement for large projects. > You're probably right about the level of C++ code around. > It's easy to bludgeon C++ code into submission when it > won't compile, instead of understanding what is wrong. I also believe that inexperienced programmers can produce better code in Ada95. You won't get the same from them in C++, even if they can wrap their head around the existing code they must read and customize. But then, this is just my opinion on the subject. DON'T TRY THIS AT HOME 8-) Ada programmers may wince at this, but here is something that I find really useful about Ada95 for my own Open Source development: If I look at a spec of a package I want to "clean up", and I don't like the way the data type is presented, and want to make some sort of wholesale change to the package, I'll first make the necessary tweaks or major changes to the specs. This may include: - Changing constants to enumerated types / vice versa - Changing a weak type to a strong type - Making types more range specified (subtypes) - Changing function/procedure API changes - Change a record/tagged type (class) to the other kind etc. Then I jump into emacs, and start invoking "make" and let the compiler tell me about all of those new errors that will now spew of the compiler. Using emacs I jump to the source of the error (using emacs macros) and make all the necessary changes, until the errors go away. With Ada95 this has never failed me, though I expect some little case may bite me some day, doing changes like this. THIS HAS NEVER WORKED WELL FOR C++. C++ would never identify all of the necessary changes, because of the number of "automatic conversions" and so on. C++ never tells you that you have a missing case in a switch statement, and its very forgiving mixing enumerated types with ints etc. C++ will not tell you when a related constant or #define needs to be updated. This Ada95 feature has made it possible for me to very quickly produce clean library interfaces, because I am not reluctant to make wholesale changes when I think it might be beneficial to the client. CURIOUSITY POLL? I'd be interested if anyone actually uses this type of procedure in more "critical" application development roles. I am sure that others must take advantage of this, if not secretly so? ;-) Is this type of thing frowned upon by DOD projects, or do they even know this type of thing happens? Just curious. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg