dougs@baldwin.WV.TEK.COM (Doug Schwartz;685-2700;61-252;641-4115;Baldwin) (01/31/91)
In article <1900@blackbird.afit.af.mil> jcardow@blackbird.afit.af.mil (James E. Cardow) writes: >We are looking for a way to compare the effort to develop comparable >systems developed in different programming languages. The comparison >is to improve the ability to project the cost based on analogy. I seem to recall something about NASA comparing Ada and FORTRAN in the development of (flight?) simulators. It seems like it was in EE Times a couply of months ago. From what my feeble memory can dredge up, the gist was that Ada didn't save them any time or lower the number of bugs, but did provide greater reusability. Even though I've read them regularly for years, can anyone tell me if EE Times publishes any sort of year-end index to articles? I regularly wade through back issues trying to find an article that suddenly has relevance. -- Doug Schwartz dougs@orca.wv.tek.com Tektronix Wilsonville, OR
marick@cs.uiuc.edu (Brian Marick) (02/01/91)
dougs@baldwin.WV.TEK.COM (Doug Schwartz;685-2700;61-252;641-4115;Baldwin) writes: >I seem to recall something about NASA comparing Ada and FORTRAN in the >development of (flight?) simulators. It seems like it was in EE Times >a couply of months ago. You may be referring to `Lessons Learned in the Transition to ADA from Fortran at NASA/Goddard', Carolyn Elizabeth Brophy, U. Maryland Technical Report UMIACS-TR-89-84, August, 1989. From the abstract: "One surprising result was that the percentage of time the Ada project spent in the various development activities was very similar to the percentage of time spent in these activities when doing a FORTRAN project. Another surprising finding was the difficulty the Ada team had with unit testing as well as with integration. [It goes on to describe what should be done differently next time.]
pcg@spl27.spl.loral.com (Paul C George) (02/02/91)
I believe this the Work of Ed Siedewitz (creator of GOOD method) at Nasa Ames reasearch center. The application was flight dynamics simulators for spacecraft, including the control system, Attitude dynamics and environment. This was a well understood domain where new projects were slight deltas from previous. A report is available from NASA, but as it is at home I can't give you the citation. email me if you need it. As to productivity, he attributed most of the lack of improvement in error rates to the lack of familiarity with Ada concepts, and the fact that a soon as a programmer got productive, they were hired away by commercial firms. As a data point, by the 4th Ada project, they were producing 130 SLOC/day vs 28.8 for fortran. Statements/day was 24 vs 14.4. Reuse was 32% for the 2nd Ada project, reaching 90% by the 4th. By comparison Fortran projects ranged from 16 - 36% (these figures are from his presentation in the procedings of the 4/90 CASEWorld conference)
fjs@bonz.enet.dec.com (Jay Shields) (02/06/91)
jcardow@blackbird.afit.af.mil (James E. Cardow) writes: >We are looking for a way to compare the effort to develop comparable >systems developed in different programming languages. The comparison >is to improve the ability to project the cost based on analogy. >... >Are there generalizations that can be made on >the order of saying for instance 'the effort to produce three lines >of assembly language is equal to the effort required to produce one >line of Ada?' Capers Jones gives values for comparison of effort to assembler for about 25 languages in his book "Programming Productivity" (McGraw-Hill, 1986). Of course, assembly language is therefore 1 - 1; 1 statement in ADA, however, is worth approx. 4.5 statements of assembler. While these figures are of course approximate, they might be the starting point you're looking for. In addition, the book talks about function points, which may provide you with another way of comparing differing systems. It's worth checking out. Hope this is what you're looking for. -- F. Jay Shields Digital Equipment Corporation Stow, MA fjs@bonz.ogo.dec.com (508) 496-8081
kingsley@hpwrce.HP.COM (Kingsley Morse) (02/07/91)
My understanding is that APL is the most productive language to use. However, it's hard to read, so the learning curve is long and steep. I remember a study by IBM showing that applications can be developed 4 - 10 times faster with APL.
straub@jogger.cs.umd.edu (Pablo A. Straub) (02/08/91)
In <7790001@hpwrce.HP.COM> Kingsley Morse (kingsley@hpwrce.HP.COM) writes: > >My understanding is that APL is the most productive language to use. >However, it's hard to read, so the learning curve is long and steep. >I remember a study by IBM showing that applications can be developed >4 - 10 times faster with APL. Development time is usually not the main cost (especially if you only consider coding). Maintenance is usually the main cost, and readability is crucial there. Besides, if I cannot read the code I can barely trust it. Pablo Straub, straub@cs.umd.edu
theo.bbs@shark.cs.fau.edu (Theo Heavey) (02/08/91)
kingsley@hpwrce.HP.COM (Kingsley Morse) writes: > My understanding is that APL is the most productive language to use. However, > it's hard to read, so the learning curve is long and steep. I remember a stud > by IBM showing that applications can be developed 4 - 10 times faster with > APL. Development with APL *may* be faster or easier BUT to use APL for a product that will have a life of more than a few runs is IMHO NUTS. Even the best APL programs are basically _unmaintainable_ by *anyone* including the developer. Being a former-IBM employee I know my division was a C house for development purposes. One of our people was well versed in APL and he was totally discouraged by our management for any development in the language after he could not conduct a proper walk through with a program prototype he had built himself. Theodora Heavey Florida Atlantic University Dept. of Computer Science
romero@convex.com (Paco Romero) (02/08/91)
I think Standard ML is one of the best modern (post-Algol) programming languages. It's cheap too. It's functional, but compiled in its best implementation, and very, very expressive. Francisco J. Romero email: romero@convex.com CONVEX Computer Corp.
mikef@cs.ed.ac.uk (Mike Fourman) (02/08/91)
In article <1991Feb07.204301.7022@convex.com> romero@convex.com (Paco Romero) writes: >I think Standard ML is one of the best modern (post-Algol) programming languages. It's cheap >too. It's functional, but compiled in its best implementation, and very, very expressive. Agreed! - but htere are at least three good implementations - which is best for you will depend on your budget, your hardware, your need to integrate with software in other languages, the importance you place on adherence to standards etc. I'm thinking of PolyML NLML POPLOG/ML - I know of other good compilers being developed. -- Prof. Michael P. Fourman email mikef@lfcs.ed.ac.uk Dept. of Computer Science 'PHONE (+44) (0)31-650 5198 (sec) JCMB, King's Buildings, Mayfield Road, (+44) (0)31-650 5197 Edinburgh EH9 3JZ, Scotland, UK FAX (+44) (0)31 667 7209
itcp@praxis.co.uk (Tom Parke) (02/14/91)
theo.bbs@shark.cs.fau.edu (Theo Heavey) writes: >kingsley@hpwrce.HP.COM (Kingsley Morse) writes: >> My understanding is that APL is the most productive language to >> use. However, it's hard to read, so the learning curve is long and >> steep. I remember a study by IBM showing that applications can be >> developed 4 - 10 times faster with APL. >Development with APL *may* be faster or easier BUT to use APL for a >product that will have a life of more than a few runs is IMHO NUTS. >Even the best APL programs are basically _unmaintainable_ by *anyone* >including the developer. Yup, my first ever computer job was maintaining a suit of APL code. It was fun (I was young) because it was *so* hard. I recall there was a three liner that took an entire day to comprehend. Tom -- Tom Parke (my opinions and spelling are strictly temporary) itcp@praxis.co.uk Praxis, 20 Manvers St., Bath BA1 1PX, UK