Newsgroups: alt.lang.design,comp.lang.c++,comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!bloom-beacon.mit.edu!spool.mu.edu!agate!darkstar.UCSC.EDU!news.hal.COM!decwrl!netcomsv!netcom.com!vrotney
From: vrotney@netcom.com (William Paul Vrotney)
Subject: Re: Comparing productivity: LisP against C++ (was Re: Reference Counting)
In-Reply-To: simon@rheged.dircon.co.uk's message of Fri, 16 Dec 1994 21:32:48 GMT
Message-ID: <vrotneyD11MDv.Ks7@netcom.com>
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
References: <19941203T221402Z.enag@naggum.no> <LGM.94Dec5075553@polaris.ih.att.com> <D0CLt9.6K3@research.att.com> <BUFF.94Dec15103904@pravda.world> <D0xAIp.3Dn@rheged.dircon.co.uk>
Date: Mon, 19 Dec 1994 05:39:31 GMT
Lines: 65
Xref: glinda.oz.cs.cmu.edu comp.lang.c++:103958 comp.lang.lisp:16093

In article <D0xAIp.3Dn@rheged.dircon.co.uk> simon@rheged.dircon.co.uk (Simon Brooke) writes:

> In article <BUFF.94Dec15103904@pravda.world>,
> Richard Billington <buff@pravda.world> wrote:
> >Dick Gabriel said that Lucid's experience with developing their
> >"C" tools (Energize), their experience indicated at least a 3 fold
> >difference between using C and Lisp as development languages - the
> >increased being in lisp's favour (i.e., productivity was 3 to 1 improved
> >if one used lisp). I agree with LGM, this proves nothing, but is simply
> >some heresay which is contrary to Mr. Trickey's heresay.
> 
> Well, cf Erik Naggum's response to the above, Dick Gabriel in
> particular and the Lucid team in general must be taken as LisP
> experts, so that may to some extent weight against their experience as
> reported above. Nevertheless, if this statement is something Dick has
> published and provided some quantifiable support for, it would be
> extremely useful material. There is so *damn* *little* serious study
> of the comparative productivity of differing programming tools.

It seems like computer science is stuck with surveys here.  Is there any
more scientific approach?

> 
> No, I'm not expecting any study which "conclusively proves" that any
> particular language is "the best" for any but very special purposes
> (and indeed I'd take with a large pinch of salt any study which
> claimed to); but it's useful to hear from people who have a wide range
> of expertise in more than one language. 
> 
> My own view, for what it's worth, is that LisP is probably more like
> eight or ten times as productive as C, in terms of delivered user
> level functionality per programmer hour (I don't know enough C++ to
> comment). However I'm biased towards LisP; although I used BCPL before
> LisP, LisP is far and away my preferred language. My experience runs
> to about 80KLOC in C, probably five times that in various LisPs (but
> mainly Interlisp/LOOPS).
> 

This is close to my experience.  I have mentioned that there feels like a 5
to 1 productivity ratio in Lisp to C++ to my colleagues who are more or less
experts in both Lisp and C++ and the usual response is that it is too
conservative an estimate.  One part of the big ratio is attributed to the
lack of a good C++ library.  I created a Lispy C++ library for myself which
includes lists, dynamic typing and other nice Lispisms, and this helped
considerably but the productivity ratio is still pretty high.  I think an
even bigger part of the ratio is due to the lack of the ability of C++ to do
what is referred to as exploratory programming.  If exploratory programming
is important to developing the application then this makes the ratio really
high.  For example, in developing my Go program in Lisp the ability to do
exploratory programming feels like it shoots up the ratio to more like 100
to 1, seriously!

This leads me to believe that for a complex enough application, like a Go
program, it is better to develop it in Lisp then recode in C++ in the last
two weeks before delivery.  Or better yet compile efficiently (enough) in
Lisp when that becomes more feasible.

It is interesting to muse with the powerful software automation of the
"software ICs" paradigm, such as NEXTSTEP, in the future perhaps the only
interesting programming will be consuming software ICs, producing software
ICs and otherwise exploratory programming.  Contrary to popular opinion,
perhaps Lisp (or Lisp like languages) will be one of the few surviving human
written programming languages of the future.
-- 
William P. Vrotney - vrotney@netcom.com
