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: fdb77,5f529c91be2ac930 X-Google-Attributes: gidfdb77,public X-Google-Thread: 1108a1,59ec73856b699922 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,25d5234e7b6ca361,start X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-02-26 14:22:44 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: xanthian@well.com (Kent Paul Dolan) Newsgroups: comp.lang.java.advocacy,comp.object,comp.lang.ada Subject: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP Date: 26 Feb 2003 14:22:43 -0800 Organization: http://groups.google.com/ Message-ID: 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> NNTP-Posting-Host: 129.8.249.134 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1046298163 10520 127.0.0.1 (26 Feb 2003 22:22:43 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 26 Feb 2003 22:22:43 GMT Xref: archiver1.google.com comp.lang.java.advocacy:59373 comp.object:58414 comp.lang.ada:34629 Date: 2003-02-26T22:22:43+00:00 List-Id: [Sorry if you see this half a dozen times, groups.google.com was having a senior moment, never confirmed the previous attempt to post this article.] Richard Riehle wrote: > soft-eng wrote: >> If the DOD had its way, _everything_ would have been >> written in Ada. It helps to remember the context. The DoD had, and has to this day, a situation where battlefield computers programmed in different languages couldn't talk to one another. A couple of obvious results of this kind of situation are that people die from friendly fire problems, and that people die from corrupted transmissions. It was, and still is, important that the computer software share a single language, with that language's exact semantics for primitives and user declared types, so that communication succeeds and at least the people fighting on our side get to claim they got killed by the enemy instead of friendly forces or computer glitches. One of the most direct ways to assure that software talent for this common language was and remained available was to make it the case that _all_ DoD software was written in this same language, mandatorily. Top Secret clearances are expensive to produce, and keeping cleared people employed as contractors is easier if their language skills translate between application desmenes. Beyond that, DoD had many languages that were in use nowhere else, so finding programmers at all for any program on a staffing up-curve was problematic; while having a DoD-wide language also in widespread commercial use would have made the programming staff-finding chore simpler. Making the language mandatory DoD-wide made sense for other reasons as well. Logistics bobbles can kill people in wartime at least as readily as howitzer aiming bobbles, it's just usually less immediately obvious. A side result of the need to have all kinds of applications programmed in this common language is that the language had to support the idioms of a wide varieties of applications: to do scientific calculations like FORTRAN, business calculations like COBOL, communications bit fiddling and calculations like C, and so forth. This _does_ tend to make for a fairly large language, but various application areas can pretty much stick to the subsets included for their needs and ignore the parts they don't need, so the language isn't so large from the viewpoint of any one programmer. > In 1996, Assistant Secretary of Defense, Emmett Paige, an > Ada advocate, decided that Ada had sufficient success in > the projects where it had been used that it should stand > on its own merits instead of being a part of a mandate. Which was total BS, and a whitewash besides. BS because you don't "optionally" need battlefield compatibility, "optionally" need programmer portability; these are always needed, and the mandate should have been strengthened and better enforced, not removed. Whitewash, because what had actually happened was a rebellion among the services, that should have had a large number of officers cashiered if not court-martialed. Abuse of the exemption system had gutted the Ada mandate, and commands, one where I worked among them, were scamming the exemption system to get ongoing exemptions for problems they caused themselves in the first place, in very straightforward attempts to avoid converting software staff to Ada software staff, and prolonged so long as they could keep getting exemptions that let them avoid doing the hard work needed to become unexemptable. If the Ada mandate hadn't been dropped, the rebellion would have to have been treated as what it was. The DoD chose to cave rather than apply military standards to a military discipline problem. > In the early days of Ada, the mid-1980's, when compilers > were not adequate and people using the language did not > understand how it was different from what they already > knew, there were a fair number of failures. > Since that time, and with the advent of the Ada 95 > standard, there have been significant successes with Ada. > The compilers are as good as one will find with any other > language. The language supports an level of reliability > not found in most other languages. It turns out to be > easier to understand and learn than seemed to be the case > when it was an entirely new set of ideas. This is way true. As a statistic of one, I'm a much better programmer in many other languages (C, C++, Pascal, Fortran, Java, Perl, Modula-2, StarLogo, for examples), but I _prefer_ programming in Ada. It is just a much better programming language [and this isn't a casual comment; I say this having committed software development professionally that delivered code in a gross of programming languages and dialects over a long career] than the others. >> Theoretically, they are all working in Ada using very >> strict procedures. In actual practice, there are a lot of >> people who are actually getting real things done! The mythology of "people getting stuff done by ignoring the rules" is that the bozos doing so only consider the short term costs: what it takes to meet management's ridiculously short milestones. Factoring maintenance costs into the picture, these people should be shot, but their managers should preceed them to the firing squad for allowing what they do to happen. What you really have here is the "programmer as prima donna" syndrome: rules are for other people, "I'm a hacker!" Indeed. > And many of those people are getting real things done in > Ada. Especially in the transportation industries, worldwide. > There is a long list of highly successful military and > non-military software written in Ada. Most of it is > targeted to safety-critical software rather than the > desktop. We certainly can point to failures in projects > that used Ada. We can also point to failures in projects > using any other language. In my experience, the failures > in which Ada was used had nothing to do with Ada. In most > cases, those failures had to do with poor management and > poor engineering. That, of course, can be said about software failures independently of language issues: management is expected to succeed given _any_ Turing complete language, but "software management" is still mostly an oxymoron: the technically incompetent leading the unherdable technocrats. >> It keeps everybody happy. The cushy-job crowd spends >> years to do projects-that-will-go-nowhere using various >> revisions of Ada, following very complicated specs. It helps to remind those who think of programming as a "cushy job" that programmer burnout rates are high, programmer divorce rates extraordinary, programmer work hours are obscene, programmer job security is next to non-existent, programmers come home from long work weeks of programming to spend hours more in unpaid self-training to keep up with a field that abandons those who stop learning for even six months. > Those complicated specs are necessary because they are > related to complicated systems. Ada has been highly > successful in uncomplicated systems, and also highly > successful in some of the most complex safety-critical > systems ever designed and deployed. In case you did not > know it, every time you board a commercial jetliner, there > is a high probability you are depending on Ada at many > levels, for your safety and dependability of arrival. >> The get-the-job-done crowd, in the meanwhile, can get all >> kinds of exemptions and stuff, and gets a lot of real >> work done. The real work can then even get some Ada >> framework around it to keep the Ada people feeling >> productive! And now you have an unmanageable, unmaintainable mess that should never have been allowed to happen: heads should roll. > You either don't know much about the current state of Ada > software practice, or you were on a project that was badly > managed and are one of those who thinks the problem was > Ada. I recall a project at NASA Kennedy Space Center > where I found a lot of people complaining about Ada. It > turned out that Ada was not the problem. Rather, the > management had insisted that all programming use a vi > editor. The engineers assumed this was inherent to Ada > and constantly complained about Ada when the problem was > that they hated the editor. Which is hilarious; the vi(), nvi(), stevie(), vim(), elvis(), and so on, family of editors were first written for the use of _secretaries_; they are the easiest editors to use imaginable, with wonderful ergonomic, navigation, and search-and-replace mechanisms, and the more up-to-date versions are far past wonderful, with text type specific color syntax highlighting, Turing complete scripting languages, and a wealth of special purpose features. Like any powerful tool, they take time and training to achieve high skill levels and productivity though [for example, I'm writing this article in vim(), from which I will then cut and paste the whole article into my browser's utterly incompetent editor widget, to avoid the pain of using that widget), and many people, dropped into vi() unwarned, suffer horribly. > Another project was on a contact won by a large and > overly-bureaucratic organization that staffed their > leadership team with some of the most incompetent people I > have ever seen in software development. Given what I've seen at various employments, incompent people doing software management is utterly the norm. You get a combination of Peter Principle Promotions: programmers with no leadership skills suddenly floundering foolishly in jobs they should never have accepted; and Lateral Ludicrousness: horizontal transfers of folks who might be wonderful warehouse worker managers, arriving with the idea that because you can manage something with essentially no technical content, you have the skills to manage something with intensly challenging technical content, but where most of the management issues are technical issues, and most of your decisions have to be made having no idea what the disputing parties are saying. > The programmers were relatively good, but they were > saddled with this ineffe[c]tive management. The project > was delayed, delayed, delayed, and the complexity > increased due to the meddling of these incompetent > managers. The contract was later won by another > contractor that had better and more experienced > leadership. They did the job, in Ada, just fine after > firing (should have set fire to) some of the deadwood that > was keeping things from getting done. Amen, except the second crowd is a fairy tale in my wide and long experience. > I have seen project after project completed successfully > using Ada, often on-time and withing budget. with budget; use budget; burn_budget(); ??? ;-) > Sorry your experience is different. The issue is not the > language, but the competence of the people using it. I > find Ada easy to understand, easy to use, and a great > pleasure to engage for simple and complex programming > tasks. My experience is that people properly trained will > find it as pleasant as I do. As with vi(), as with ClearCase, if you don't _learn_ the tool thoroughly _before_ forming your initial in-use opinions of it, you'll hate it forever. > When I compare it to the other languages I know, including > Java and C++, I realize that Ada is still the best option > for any real-time embedded software system where a high > level of safety is required. The concurrency features are > far superior to those in Java, and the surprises far less > frequent than one enjoys in C++. True. On the downside, as a no-longer-mandated and distinctly fringe, almost "cult", language, Ada lacks the wide variety of intensely useful and daily burgeoning libraries of already invented wheels of Java, the programming hordes willing to debug open source code of C and C++, the just-for-fun applications and game authoring tools that make other languages more able to attract young programmers to become language-X junkies. Mostly, this is due to conscious decisions, budget shortsightedness or unconscious arrogance in the Ada community: "our language is just so damned incredibly superior in its serious applications, there is no need for it to cater to the unwashed masses". That way lies relegation to the dustbin of programming languages history, the track down which Ada seems inexorably headed to this day, whatever its admitted successes. Ada was intended to replace obscure languages like Jovial. Instead it has become one of them. The Countess of Lovelace should sue for damages to her good name. > Richard Riehle Crossposted to comp.lang.ada, which _really_ should add comp.lang.ada.*, where * == {misc,gnat,advocacy,???}, to give discussions like this a home.