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,efe03f20164a417b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1995-03-17 04:58:07 PST Path: bga.com!news.sprintlink.net!EU.net!uknet!hrc63!gmrc.gecm.com!valiant.gmrc.gecm.com!bill From: bill@valiant.gmrc.gecm.com (R.A.L Williams) Newsgroups: comp.lang.ada Subject: An observation of Ada (may offend) Date: 17 Mar 1995 09:27:29 GMT Organization: GEC-Marconi Research Centre Message-ID: <3kbkm1$41o@miranda.gmrc.gecm.com> NNTP-Posting-Host: valiant.gmrc.gecm.com X-Newsreader: TIN [version 1.2 PL1] Date: 1995-03-17T09:27:29+00:00 List-Id: In article Vladimir Vukicevic wrote: [well-deserved dismissal of student gripe deleted] : Speaking of why people think Ada is not a good language... it'd be nice : if someone collected the many myths about Ada, and collected them all : together for distribution to the unbelievers. :-) This would simplify : telling people about Ada, especially if all they've heard was that it's : a "big ugly ancient language used by the government", or that it's too : 'huge' to be worth doing anything with. Not 'myths' but 'gripes' - its a matter of perspective! Some years ago I spent some time writing applications in Ada 83 (of course, it was just 'Ada' then). I wrote both workstation and embedded applications and I formulated a number of gripes about the language at the time. I'm now (re-)learning Ada in its Ada95 form and I'm glad to see that many of the gripes have been addressed. Anyway, FWIW, here's a list (in no particular order). I'd be interested to see how many strike a chord with other people: a. No unsigned integers (fixed in Ada95) HCTBAEL. b. No bit level manipulation (fixed in Ada95 but only for unsigned ie. mod INTEGERs, I can't test a sign bit, not that I need to) HCTBAEL. c. Inflexible I/O - no unformatted binary files - this may have been fixed in Ada95 but GNAT doesn't support STREAMs yet so I haven't been able to play with it. d. No pointers to functions - except for the 'ADDRESS attribute which, being a chapter 13 item is at the whim of the compiler vendor (not very portable). This is fixed in Ada95. e. No short cut operators (+= etc.) -- sorry, we've had this debate already in another thread, I've heard the objections, I still like the operators. f. Undefined 'baggage' in the run-time system. OK, this is unavoidable with a language like Ada, it makes me nervous with Eiffel and C++ as well, but, so far, I haven't tried to use those languages in embedded systems (got a C++ one coming up soon). Its not so much needing a run-time system, its not knowing what's in it. This is largely a compiler vendor issue, not a language issue. HCTBAEL g. Task overhead for serialized data access. Fixed in Ada95 with protected types I believe, that's one of the next things to play with. h. And a special one for Ada95: poor encapsulation of objects. I can define a 'member function' for a class by including the class in the parameter list. Unlike C++ or Eiffel, I can do this *anywhere* in my code, even a nested function hidden somewhere seemingly 'irrelevant'. Whereas other features of Ada go out of their way to force the programmer to follow 'good practice' (sometimes a matter of opinion), this seems very lax. HCTBAEL = "How can this be an embedded language?" My experience with Ada, confirmed by many people that I spoke to at the time was that, for embedded systems at least, Ada was used as cosmetic window dressng to a vast quantity of assembler. This was made necessary by the shortcomings of the language for addressing low level machine interactions. To some extent, the same was also true of X11 software on workstations. I see from responses in other threads that this may have changed in recent years. All I can say is about time! : -- Vladimir Vukicevicn : -- vladimir@intrepid.com Bill Williams bill.williams@gec-mrc.co.uk