Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!crackers!jjmhome!smds!rh From: rh@smds.UUCP (Richard Harter) Newsgroups: comp.software-eng Subject: Re: COCOMO Summary: Functionality of languages Message-ID: <572@smds.UUCP> Date: 20 Jun 91 05:15:42 GMT References: <1991Jun19.174716.6861@netcom.COM> Distribution: comp Organization: SMDS Inc., Concord, MA Lines: 70 In article <1991Jun19.174716.6861@netcom.COM>, jls@netcom.COM (Jim Showalter) writes: > Well, this wasn't my original objection, but as long as you've brought > it up, this is the OTHER thing I find absurd about the COCOMO approach: > the focus on SLOC. You cranked out 20 KSLOC of code in 1962. What language > was it? Assembler? FORTRAN? In 1990 I cranked out 20 KSLOC of Ada, > complete with tasking, genericity, exception handlers, constraint checking, > etc. To achieve this same level of functionality in a 1962 language, I > might well have had to write 10-100 times as many lines of code. How > much assembler would you have to write to provide dynamic binding and > inheritance a la C++? My guess is: considerably more than you could write > in a year (ask Stroustrup!). It all depends on what you are doing. Scientific analysis, physical modelling, and numerical analysis, and so on, require much the same amount of code whether you are doing it in FORTRAN-II or Ada -- the bulk of the code is the expression of numerical calculations. I am still not going to buy your 10-100 times as much code. I recollect that circa 1972 we did the real time emulation for the ABM PAR radar in 75,000 lines of FORTRAN-IV (on top of an 'off the shelf' task and interrupt manager written in assembler) -- emulation meant that the data was coming from a different type of radar, so we had to recast the data to make it appear that it was coming from a phased array radar. That little gem did an awful lot of work -- quite frankly I rather doubt that a modern team of programmers using Ada would do it in as few lines of code. [The total number of lines of production code was higher than 75,000 because of the extensive number of auxiliary data reduction, editing, and analysis programs.] If anything I think that in the old days we coded tighter and delivered more functionality per line of code than is the practice today -- we had to because of the limitations of the machines available. When I say 'we' I really mean those who worked hard at producing efficient well organized code -- then, as now, there was a lot of bad code being written. What we didn't have were a lot of packages and utilities and functionality that weren't available because they weren't written yet. More importantly the problems we are solving today aren't the problems we were solving then. > As with all such metrics, the baselines should be calculated in terms of > COMPLEXITY. How many complexities could you write per year in 1962 vs > 1991? THAT'S the critical issue, and I believe there is a wealth of > evidence that modern languages and environments have greatly increased > productivity when it is measured in this way. SLOC obscures the truth. I try to write as few complexities as I can. :-). However I have to admit that I have been told that my notion of simple is somewhat daunting. :-) Seriously, I don't think that complexity is the right thing to talk about. What is true is that the objectives and scope of what one does with computers today is much broader and much different than they were 20 years ago. A lot of this has to do with the increased capability of the machines themselves. A lot has to do with the fact that yesterdays problems were solved yesterday -- I don't need to write a data analysis and display package -- vendor X will sell me one right out of the box, complete with near instaneous color graphics for the cost of a month of programming time. But if you are simply saying that language X enhances my functionality enormously because it has all sorts of nifty software engineering principles embedded in the language I think you are overstating the case -- I already know those nifty principles and can use them in whatever crufty 3GL I happen to be stuck with at the moment. [If you mean to argue that Joe Blow with his still damp CS diploma will be better served by using language X I shan't argue with you.] This is not to say that I won't use language X -- I will if it lets me write cleaner, simpler code. -- Richard Harter, Software Maintenance and Development Systems, Inc. Net address: jjmhome!smds!rh Phone: 508-369-7398 US Mail: SMDS Inc., PO Box 555, Concord MA 01742 This sentence no verb. This sentence short. This signature done.