Newsgroups: comp.object,comp.lang.eiffel,comp.lang.c++,comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!rochester!udel!news.sprintlink.net!tank.news.pipex.net!pipex!in2.uu.net!pipeline!psinntp!psinntp!psinntp!hqda-ai!grant
From: grant@pentagon-ai.army.mil (Pete Grant)
Subject: Re: Why is one OO language more productive than another?
Message-ID: <DEICGI.MJM@pentagon-ai.army.mil>
Organization: U.S. Army Artificial Intelligence Center, The Pentagon
References: <42dm1p$kks@goanna.cs.rmit.edu.au> <42fosn$i17@martha.utcc.utk.edu> <42joi1$aft@snlsu1>
Date: Wed, 6 Sep 1995 23:41:05 GMT
Lines: 79
Xref: glinda.oz.cs.cmu.edu comp.object:38027 comp.lang.eiffel:10756 comp.lang.c++:147855 comp.lang.smalltalk:28059

In article <42joi1$aft@snlsu1> Patrick Frend <frend@ferndown.ate.slb.com> writes:
>mbk@caffeine.engr.utk.edu (Matthew Kennel) wrote:
>>Dale Stanbrough (dale@goanna.cs.rmit.edu.au) wrote:
>>: In article <26h5Zh$02s@zoe.pcix.com> , traymond@pcix.com writes:
>>: >Well, lets put it this way.  It seems that the languages that
>>: >have the highest programmer productivity are untyped.  You
>>: >can draw some conclusions from that.
>>
>>Yes: Smalltalk and CLOS are more productive than C++. 
>
>I don't doubt that you are more productive in generating code
>that more or less works. But are these languages more productive
>over the entire lifecycle of the system. (Maybe over 15 years!).
>Is there any evidence.

Yes (I speak only on behalf of Lisp/CLOS as I have no Smalltalk
experience).  The attributes of a language that increase produc-
tivity do not disappear after initial development is completed.
They remain in effect throughout the entire lifecycle.  

>How can you 'prove' that you have caught the majority of type errors.
>(N.B. Testing does not 'prove' anything. It simply shows that what
>you have tested worked at the time you tested it). Perhaps 33% of my time
>is taken up in generating tests forthe software I write; anything that a tool
>can do for me is greatly appreciated.

Can you 'prove' it in a statically typed language?
>
>How do you test for the critical error-handling routines which 
>hopefully will 'NEVER' get called, but if they do, they 'MUST' 
>work 'FIRST TIME'.

The same way as in C++.

>How well do these languages integrate with other, more traditional
>type languages (i.e C C++ Pascal etc). Can't afford to throw all the
>existing code away. Would take another 15 years to re-write.
>
Modern Lisp systems integrate fully with other languages.

>How efficient is the software generated. Most software is not 'real-time'
>but much of it interacts with the user. Everything else being equal if
>'A' feels 'snappier' than 'B' that I'd go for 'A' every time. Too bad if
>you sell 'B'.
>
This where  the difference shows -- although the difference is no longer
as great as it was a few years ago.  We have a system we originally
developed in Lisp and converted into C++.  Comparing the performance
of the two systems revealed some surprises:

Overall, the C++ system is significantly faster.  However, the C++
seems to win primarily in the I/O area.  Timing the purely compu-
tational module shows both to be about even.

>Sorry to be so negative, but I'm in an argumentative mood;-> I don't doubt
>these languages (smalltalk etc) are usefull, but in general, industry
>needs alot of convincing before swapping to a 'new' technology.

The subject of this thread is whether or not one language is more 
productive than another -- not on what the industry has decided to 
accept.  The commercial world's history has plenty of examples of
products that thrived in the marketplace even though superior products
were available.  The winners are too often chosen on the basis of
marketing efforts rather on the merits of the product.

As a person who has programmed in these languages extensively,
I would rate the productivity from low to high:

Assembler------>C-->Pascal---C++------------->Lisp

As a final note, I don't recall seeing anyone with real commercial
exprerience in Lisp or Smalltalk argue that these languages are
not more productive.  Taking a course in Lisp isn't sufficient to
qualify -- you wouldn't give much weight to the opinion of a Lisp
programmer who has only dabbled with C++.

Pete.


