billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,2847,) (04/28/89)
From article <39400015@m.cs.uiuc.edu>, by render@m.cs.uiuc.edu: > Written 8:12 pm Apr 25, 1989 by billwolf%hazel.c@hubcap.clemson.edu: >> Personally, I'd like to see a good COBOL vs. Ada study, >> if anybody knows of one (or is interested in doing one)... > > Why? This would be like comparing a pterodactyl and a red-tailed > hawk. They both fly, but they're at different evolutionary stages. You know that, and I know that, but there are large numbers of businesses who DON'T know that, and it would be very helpful to have a study which would convincingly demonstrate the benefits (obvious to you and I) of switching to a far more advanced language. Bill Wolfe, wtwolfe@hubcap.clemson.edu
barkley@weiss.cs.unc.edu (Matthew Barkley) (05/12/89)
In article <5314@hubcap.clemson.edu>, billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,2847,) writes: > > ... a far more advanced language. Ada, that is. I have used FORTRAN, COBOL, Pascal, C, and BASIC during the last 20 years. None of the other 4 comes close to COBOL in that language's real strengths: Record-oriented I/O and reporting. I have not used Ada, but I suspect that it isn't any better than the others. The ease of formatting an output page in COBOL (with all the nasty editing done for you) just doesn't exist anyhwere else, in my non-Ada experience. Can Ada really do as well? Those who haven't used both Ada and COBOL need not reply; I'm looking for experience, not speculation. Matt Barkley barkley@cs.unc.edu Any opinions expressed are not necessarily shared by anyone else, and may not even be my own. How an organization can have an opinion is beyond me.
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,2847,) (05/13/89)
From barkley@weiss.cs.unc.edu (Matthew Barkley): > I have used FORTRAN, COBOL, Pascal, C, and BASIC during the last 20 > years. None of the other 4 comes close to COBOL in that language's > real strengths: Record-oriented I/O and reporting. I have not used > Ada, but I suspect that it isn't any better than the others. The ease > of formatting an output page in COBOL (with all the nasty editing done > for you) just doesn't exist anyhwere else, in my non-Ada experience. > Can Ada really do as well? Those who haven't used both Ada and COBOL > need not reply; I'm looking for experience, not speculation. COBOL is hard-wired; there are certain things that it's very hard to do in Report Writer, for example. I have a generic Ada report-handling package which doesn't interfere with the programmer and yet abstracts away from the details of making sure that a page feed occurs (calling the (optional) user-supplied procedure to print a page footer, doing the page feed, calling another user-supplied procedure to print a page header, resetting the "virtual line number" (provided by the package) to 1, etc., as necessary); the user-supplied procedures can utilize the full power of Ada to do their work. For example, I have a date-and-time package which will generate the date and time in any of a large number of forms. I have generic Standard_Page_Header procedures which are simply instantiated with a page title (optionally computable at run time) to give me a user-supplied page header procedure suitable for use by the report handler in about 3 minutes, which automatically prints the date and time on the left, the page number on the right, and the title in the middle. If this standard procedure doesn't fit my needs, I can quickly write my own instead, and supply *it* to the report handler. All the formatting things that are hard-wired into COBOL can be rather easily set up as formatting procedures in a formatting package. Some of the things I've done with my report handling package would have required hours to get the Report Writer to do (with legions of SUPPRESSes...). Plus there's all the maintainability, reuseability, and so on that comes with the greatly improved modularity available in Ada. In my opinion, there's simply no contest; I wouldn't seriously consider using COBOL even in the domain for which it was designed. Bill Wolfe, wtwolfe@hubcap.clemson.edu
ts@cup.portal.com (Tim W Smith) (07/09/89)
Those "obvious" benefits of switching to a more advanced language did not show up in the productivity studies of De Marco and Lister reported in their book "Peopleware". ( I may have the names wrong, since this is from memory ). They found that language did not have a correlation to performance except that assembly language programmers got left behind. Tim Smith
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,2847,) (07/10/89)
From article <20256@cup.portal.com>, by ts@cup.portal.com (Tim W Smith): > Those "obvious" benefits of switching to a more advanced language > did not show up in the productivity studies of De Marco and Lister > reported in their book "Peopleware". ( I may have the names wrong, > since this is from memory ). > They found that language did not have a correlation to performance > except that assembly language programmers got left behind. I've seen such studies; one major flaw is that they did not study languages which are designed around the concept of reuseable software components. Start using Ada generics and see what happens to your productivity... If we simply compare the things which most high-level languages have pretty much identical facilities for doing, we shouldn't be surprised to find that the only differences are those imposed by, e.g., the excessive amount of typing necessary to produce a COBOL program relative to the benefit derived. If we are to compare advanced languages, then we must also assume that the applications involved are nontrivial, and that they are to be given a quality implementation. Further, the studies only consider the time required to hack something together. I submit that the costs of maintenance over the life of the product are simply omitted from such studies; when we consider the vast difference between the ease of modifying a highly modular Ada product and the torture of modifying (and subsequently trying to debug) products written in languages without even local variables, much less highly secure abstract data types, it is clear that no comparison which does not include these lifecycle costs is really useful. Also, there are typically costs in the form of product inferiority which arise in some languages but not others. If I were to try to implement a priority queue in COBOL, it would have to be bounded; the result is either squandered storage (when the queue is small) or application failure (when the queue is large). The use of unbounded Ada components results in a higher-quality application. Finally, the studies typically address only sequential coding; such studies should cover a range of applications which includes multitasking. One example would be the writing of a database system; another would be the implementation of high-performance software components which are not only secure under conditions of multiple requests from multiple tasks to a single instance, but which actually satisfy these requests in a parallel fashion. Many business applications have poor response times because they are unable to exploit multitasking. I haven't checked _Peopleware_ specifically, but perhaps you can tell us how many of these factors were considered in their study, and whether Ada was even part of the analysis... Bill Wolfe, wtwolfe@hubcap.clemson.edu