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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1108a1,59ec73856b699922 X-Google-Attributes: gid1108a1,public X-Google-Thread: 11232c,59ec73856b699922 X-Google-Attributes: gid11232c,public X-Google-Thread: 103376,583275b6950bf4e6 X-Google-Attributes: gid103376,public X-Google-Thread: fdb77,5f529c91be2ac930 X-Google-Attributes: gidfdb77,public X-Google-ArrivalTime: 2003-04-18 11:54:52 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.uchicago.edu!logbridge.uoregon.edu!arclight.uoregon.edu!wn13feed!wn12feed!worldnet.att.net!207.217.77.102!newsfeed2.earthlink.net!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!stamper.news.atl.earthlink.net!harp.news.atl.earthlink.net!not-for-mail From: Richard Riehle Newsgroups: comp.lang.java.advocacy,comp.object,comp.lang.ada,misc.misc Subject: Re: the Ada mandate, and why it collapsed and died (was): 64 bit addressing and OOP Date: Fri, 18 Apr 2003 11:55:26 -0700 Organization: AdaWorks Software Engineering Message-ID: <3EA04A1E.CAFC1FEF@adaworks.com> References: <3E4E8F8C.9C096985@adaworks.com> <9fa75d42.0302250710.5549baaf@posting.google.com> <3E5C7033.BD5DC462@adaworks.com> <9fa75d42.0302260618.7506cba7@posting.google.com> <3E5CF5C6.84822F57@adaworks.com> <8qkczsAcGcn+Ew83@nildram.co.uk> Reply-To: richard@adaworks.com NNTP-Posting-Host: 3f.bb.88.99 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Server-Date: 18 Apr 2003 18:54:51 GMT X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en Xref: archiver1.google.com comp.lang.java.advocacy:62391 comp.object:61326 comp.lang.ada:36295 misc.misc:13438 Date: 2003-04-18T18:54:51+00:00 List-Id: Kent Paul Dolan wrote: > I merely lack the level of specific > formal education in computer language > design that make most of what the OP > thinks of as "simple principles" look > simple when reduced to standards-ese, or > look simple when trying to convince > other mid-level and junior programmers > that Ada is an "easily understood > language". I suppose I should interpret that as a response to my contention that Ada is not as hard to learn as many have suggested. In fact, Ada, once some fundamental ideas are understood, is not that difficult. However, in its early days, when those fundamental ideas were new, even revolutionary, they were difficult for even experienced programmers to grasp. Now, so many of those ideas have been adopted in the design of other programming languages, that, when one mentions one of them in the context of Ada, the response is often, "So what? Language XYZ has that feature too." True, not all of the ideas have been adopted. The most difficult idea for many programmers to grasp is the set of visibility rules in Ada. In my experience, once those are understood, everything else falls into place. Some Ada programmers spend years fighting the visibility rules, and continue to raise questions, debate, and engage in endless language lawyering in an attempt to subvert, thwart, or whine about them. > If that claim were true, the years of > language lawyering that have filled and > continue to fill comp.lang.ada would not > have been necessary. In the case, Ada is > conceptually an extremely difficult > language to understand, and I'm not sure > why that needed to be so. Pascal [from > which Ada mostly derives], at least in > its early incarnations, is in contrast > supremely easy to understand from the > practicing programmer's viewpoint, which > made it a splendid learning langauge and > quite fair in practice as well. I disagree. Ada is not conceptually difficult to learn or understand. It does include some new ideas, and new ideas are sometimes difficult to grasp at first. That is quite different. Again, many people who were required to learn Ada for their work were resentful of the mandate and spent their time inventing reasons why they believed they could not do something instead of discovering how easily they could do it. If a programmer wants to fight the visibility rules, for example, he can do so, can grumble about them, find reasons why writing a particular program is so hard, and so on. This attitude reminds me of my first experience on a part-time high-school job in which I was required to use a floor-buffer. The standard floor-buffer uses a large circulating brush which, as it polishes the floor, can exert a powerful thrust vectored over its clockwise motion. A human, regardless of their strength, cannot overcome the force of the brush using brute strength. That same human, learning to gently balance the rotating brush, can make it go anywhere. I became quite skilled at controlling the buffer and could eventually command it using a single finger. The Ada visibility rules are a powerful force in the language design. The programmer can exert all kinds of energy in complaints about it. However, once one understands this feature, takes charge of its inherent force, and incoporates it into a design and corresponding source code, it makes the Ada programming (and especially the maintenance) process much more pleasant than one might find in competing programming languages. Most of Ada is pretty simple. Besides the visibility rules, there are two other parts of the language that are a bit difficult for some newcomers: accessibility rules (for objects and access types) which prevent many of the pointer related mistakes so common in many languages, and tasking, a feature designed to incorporate concurrency in the language. Most of the other features of the language, such as type safety rules, separate compilation, type derivation, object aggregates, abstract data types, control over defined scope, generic templates, exception handling, packaging of common entities, information hiding, encapsulation, etc; these features that once seemed so strange to programmers experienced in procedural abstractions, are now commonplace throughout the programming language community. When introduced in Ada, they seemed strange, even bizzare. Now they are accepted practice. Even so, Ada is not intended for one-person, single program, projects where an individual programmer can grasp every detail of the program. It is intended for large-scale projects where many programmers and designers must interact over a set of complex requirements and integrate those requirements into a single, well-functioning whole. Ada makes that kind of project easier to develop, easier than one might experience in most other languages. One can make the case that Ada is not the best choice for certain classes of software. I still believe it is not appropriate, using the current compiler technology, for eight-bit microcontrollers (e.g., I-8051), but a subset of Ada might be. Smalltalk is still a better language for some kinds of software, especially where one needs a lot of dynamic properties and frequent modification of the code. Smalltalk is, however, a terrible choice for the kinds of software Ada is targeted to build. There are other languages one can compare to Ada that also have serious potential for embedded-real-time safety-critical software. As I examine them, in some detail, I keep discovering that they simply fall short. It is said, "The Devil is in the details." C++, for example, when I look at it closely, seems inappropriate for developing software of the kind I just described. Each time I look for a competing technology, when compared to Ada, it simply falls short. A better Ada could be designed. There are things about the language that could be improved. I hope someone will eventually design a language that is better than the current Ada design. At this point, though, when I am looking for a language that has a high regard for reliability and dependability, Ada still has the edge. Richad Riehle