Newsgroups: alt.lang.design,comp.lang.c++,comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!nntp.club.cc.cmu.edu!godot.cc.duq.edu!hudson.lm.com!news.pop.psu.edu!news.cac.psu.edu!howland.reston.ans.net!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: nmein@bifrost.otago.ac.nz's message of 20 Dec 1994 01:05:53 GMT
Message-ID: <vrotneyD13o6z.92L@netcom.com>
Followup-To: alt.lang.design,comp.lang.c++,comp.lang.lisp
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
References: <19941203T221402Z.enag@naggum.no> <BUFF.94Dec15103904@pravda.world> <D0xAIp.3Dn@rheged.dircon.co.uk> <vrotneyD11MDv.Ks7@netcom.com> <vogtD12y8D.HLL@netcom.com> <3d5alh$6j7@celebrian.otago.ac.nz>
Date: Tue, 20 Dec 1994 08:13:47 GMT
Lines: 83
Xref: glinda.oz.cs.cmu.edu comp.lang.c++:104118 comp.lang.lisp:16102

In article <3d5alh$6j7@celebrian.otago.ac.nz> nmein@bifrost.otago.ac.nz (Nick Mein) writes:

>
>   Richard Billington, Simon Brooke, William Vrotney, Jim McDonald and Christopher
>   Vogt have written that programming in Lisp is 2 - 10 time more productive
>   than programming in C (two of the posters professed to having little 
>   experience with C++). Surprisingly, no suggestion is made that this 
>   productivity advantage is restricted to any particular problem domain (perhaps
>   Lisp is 10x more productive for an NLP system, but only 2x more productive
>   if you are writing a Unix device driver?).

I don't think that the productivity ratio is related to particular problem
domains as much as it is to the complexity of the problem domains.  And so I
would agree with the gist of your last sentence in the above paragraph, but
for different reasons (I wouldn't even guess 2x but more like 1x if that for
the Unix device driver).

Also I should add that I think that it is more than just the complexity of
the problem domain that increases the ratio.  Uncertainty is another.
Uncertainty of the algorithm and data representation.  This is where
exploratory programming methods are also very helpful.  Although complexity
and uncertainty of the problem domain frequently go hand and hand they don't
have to.  For example I helped develop an AI scheduling algorithm in Lisp
that took about six months to develop with a lot of intensive exploratory
programming.  But the final algorithm turned out to be coded in only about 6
pages of code.  Hence the final algorithm was not very complex but the
uncertainty or finding the correct abstractions was the hard part.  Now that
I think back at this task, doing the same thing in C++ seems down right
silly.  However I could easily recode the algorithm in C++ today in a few
hours.

>
>   Anyway, I found the claims rather surprising, so here is a challenge. The
>   following toy program loads a 256x256 8 bit grayscale image from a file, 
>   inverts it, and saves it to another file. I consider myself to be an
>   intermediate-level C++ programmer. The program took me an hour (almost to
>   the minute) to design, code, debug and test (Ok, I didn't test it very much).
>   I look forward to seeing the previous posters' Lisp implementations of the
>   same. It should only take them 6 - 30 minutes to knock them together, less
>   if they are reasonably experienced in Lisp.
>

>   - Negate image program deleted -

In my understanding of the productivity ratio this last paragraph does not
reflect any sort of important proof.  Writing a small piece of a BITBLTer is
so well understood and so non-complex that I can not see any advantage to
simply coding this thing in Lisp versus coding it in C++.  You only have one
Struct, Image, with two slots and a couple of methods.  This hardly
qualifies as a complex program.  In fact being a die hard Lisper that I am I
would probably still write this thing in C since it looks like an OS
utility.  We already have a very elegant language for writing OS utilities
called C.  I wouldn't even waste the time doing this in C++ unless there was
a requirement to provide an object interface.

By the way, I for one lose, it would probably take me more than 30 minutes
from start to finish to write your program in Lisp, so I will not even
start.  But, if you really want to demonstrate the effect of the
productivity ratio lets pick a challenge that shows off Lisp and not one
that should obviously be done in C.  Here is my challenge:

 "You are given spectral sound files representing frequency, amplitude,
 bandwidth and time of sounds picked up by hydrophones in the ocean.  You are
 looking for torpedo sounds but the hydrophones pick up the sounds of the
 ship dragging the hydrophones and other miscellaneous noise in the ocean.
 Develop an existing standard blackboard system shell and source model and
 discover the blackboard level abstractions that allow the top level of the
 blackboard to identify a torpedo source specified in the source model.
 Hint1: Use the harmonic structure of sound sources for source modeling and
 identification.  Hint2: You need to consult with human experts on torpedo
 sounds and do many experiments with that data to develop the rules."

This was one of my last tasks that I did in approx. 6 months in Lisp.  How
long would it take you to do this in C++ given that you do not have our
results?  I am very serious about this challenge to make a point but I hope
that you do not start it because I predict that you, assuming you get some
guidance of where to start, will fumble around for the first three months
only to discover that you need another 3 months to reinvent and implement
that portion of Lisp in C++ to give you the interactive visibility you need
to do the experiments.  This prediction is based on the AI programs that I
developed in C++ instead of Lisp.
-- 
William P. Vrotney - vrotney@netcom.com
