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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Xref: utzoo comp.lang.ada:2909 comp.lang.c++:5529 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!uunet!cme!durer!rowe From: rowe@cme.nist.gov (Walter Rowe) Newsgroups: comp.lang.ada,comp.lang.c++ Subject: Re: Ada Message-ID: Date: 16 Nov 89 19:08:35 GMT References: <14033@grebyn.com> <7053@hubcap.clemson.edu> Sender: news@cme.nbs.gov Organization: National Institute of Standards and Technology In-reply-to: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu's message of 15 Nov 89 16:06:41 GMT List-Id: Ignore that last one ... got trigger happy ... ---------------------------------------------------------------------- >>>>> On 15 Nov 89 16:06:41 GMT, billwolf@hubcap.clemson.edu (Bill Wolfe) said: billwolf> This is blatantly false; consider the November 1988 billwolf> article in IEEE Software ("Large Ada projects show billwolf> productivity gains"): billwolf> [...irrelevant text deleted...] billwolf> on the project was counted only once. Roughly 13 percent of billwolf> the delivered software was reuseable. Uhmmm ... correct me if I'm wrong here, but if a project is well designed (ie. module specs are written to be general), I think there would be a higher degree of re-usability for those modules, regardless of the language used. That's the purpose of writing generalized code. Any good computer scientist/programmer knows that, right? Imagine having to write sin(), cos(), etc, for every application you needed them for. This would of course be ludicrous, so those in the know wrote good, generic routines to handle these functions and now you take them for granted. What I'm trying to say is that re-usability is not necessarily an attribute of the programming language being used, but more likely it is the result of using good system design techniques. Who cares if its C++, Ada, C, or Pascal? If you approach the design correctly, your solution will be general enough so as to apply to the greatest number of variations of the same problem. Thats what re-usability is all about, isn't it? Not re-inventing the wheel? billwolf> Sounds like a continuing *success* to me ... Sure, but so is Pascal (originally designed as a learning tool), but its not highly used outside of Academia just like Ada is not highly used outside of DoD. Ever wonder why? billwolf> A prime example is Unix; the current POSIX effort aims to billwolf> standardize 1960's technology, thus resulting in a "lowest billwolf> common denominator" which locks users into obsolescence. I disagree. Its not locking into obsolescence. Its forcing one to meet only a minimum set of requirements, which allows a maximum amount of flexibility above and beyond those requirements. As long as you meet these minimum requirements, you still have the freedom to enhance UNIX any way you see fit. They aren't restricting you to these, but saying that you must provide at least these things. billwolf> Modern programming languages provide a variety of features billwolf> to support development and maintenance of software products. billwolf> These features include strong type checking, separate billwolf> compilation, user-defined data types, data encapsulation, billwolf> data abstraction, generics, flexible scope rules, billwolf> user-defined exception handling, and concurrency mechanisms. I have to agree with Bill on this point: more languages ARE beginning to evolve into useful tools for productivity, rather than learning tools, or tools intended for specific applications. However, I think in order to be most productive and efficient for a given application, a language still must cater to that application to some extent (ie. COBOL for record transaction processing, C for systems programming, etc). > [...] There is the August 21 89 issue of Government Computer News > describing the problems which the huge FAA Advanced Automation > System is having due to IBM Ada implementations and tools (or lack > thereof). billwolf> Are you saying that this is the fault of the *language*, or billwolf> of IBM? More than likely its IBM, although most of their projects seem to come out of a committee, and in that respect, draw a striking resemblance to Ada. So, possibly both are at fault since Ada was designed by a committee, too. I think the basic point being made is that too many hands in the pot spoil the soup, and I tend to agree with this. Its good to get outside opinions so that one can be as objective as possible, but I still think that fewer people can supply a much more rational decision. > the programming style being promulgated by DOD for Ada [descriptive > variable names] is anti-conducive to the stated goal of readability; billwolf> To C hackers, who are accustomed to single-letter variables, billwolf> yes. Software engineering specialists tend to have the billwolf> opposite perspective. Admittedly, I fall into the C hacker category, but I think Ted makes a valid point here. I'd much prefer to shuffle through a few pages of documentation at the top of a print-out than have to look at unsightly long variable/procedure/function names. I support giving variables meaningful names, just not unsightly long ones. If the docs are good at the top of a file are good (ie. they clearly and concisely convey the concept of what this code is suppposed to do), then you shouldn't have to clutter the code with paragraph long names. You're trying to infer the logic being applied, not the details of the individual statements (for alone they mean nothing anyway). billwolf> Bill Wolfe, wtwolfe@hubcap.clemson.edu Walter Rowe, rowe@cme.nist.gov --- My opinions are my own, and bare no reflection of the opinions of the United States Government.