Newsgroups: alt.lang.design,comp.lang.c++,comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!hookup!caen!night.primate.wisc.edu!sal.wisc.edu!waldorf.csc.calpoly.edu!kestrel.edu!mcdonald
From: mcdonald@kestrel.edu (Jim McDonald)
Subject: Re: Comparing productivity: LisP against C++
Message-ID: <1994Dec23.022624.25607@kestrel.edu>
Sender: mcdonald@kestrel.edu (Jim McDonald)
Organization: Kestrel Institute, Palo Alto, CA
References:  <D18H22.2vt@world.std.com>
Date: Fri, 23 Dec 1994 02:26:24 GMT
Lines: 49
Xref: glinda.oz.cs.cmu.edu comp.lang.c++:104758 comp.lang.lisp:16181


In article <D18H22.2vt@world.std.com>, tob@world.std.com (Tom O Breton) writes:
|> One thing this thread has roundly demonstrated is that it is not easy to
|> compare productivity, particularly since people can interpret the same
|> requirements in widely different ways.
|> 
|> The first guy wrote a program that checked for several errors and
|> allowed different image sizes to be handled by simply changing height &
|> width. No _wonder_ that took longer! IMO that is entirely due to the
|> more ambitious approach, which swamps any differences due to language.

Excuse me?  The "first guy" (Nick) wrote a program that checked for about
1/100 of the errors that the lisp versions looked for, and was not 
parameterized to handle different dimensions (e.g. 100 * 100 * 3) or 
different byte sizes (e.g. 4 bit or 16 bit or 1024 bit bytes), and it 
still took him about four times longer to write.   

He wrote a *less* ambitious program and it took him longer.  Now, what
does that say about the languages?  [Actually, not much, I fear, given
the trivial nature of the task.]

|> What _is_ important to me is not how fast one can bang out trivial code,
|> but how easily one can refine existing code.

Which is why I asked Nick to revise his to accept a header format
in his data files to specify the data format and to allow structured
modifications to the internal array (e.g. invert just the first 
plane).  That's already present in the version I wrote that took
half the time he spent for the trivial version.

|> IE, it may take me a few extra seconds to type
|> 
|>         int
|>         main( int argc, char** argv )
|> 
|> but the effect of that on my productivity is negligible. However, if
|> (say) changing a variable takes me 30 seconds to find every instance
|> (with editor help) and 30 seconds to recompile, that _does_ have a
|> significant effect on productivity.
|> 
|> Another important issue is how easy it is to provide the
|> "non-functional" stuff: safety and efficiency. For instance, now that
|> C++ has exception handling the first program need not have written out
|> all those checks against NULL and presumably would thereby have been
|> written about as fast as the others.

Very true.  Part of the luxury of lisp environments is that the
exception handling systems have about 20 years of tradition and 
experience to build on, providing them with mature capabilities.
