Newsgroups: alt.lang.design,comp.lang.c++,comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!cs.utexas.edu!uunet!sytex!smcl
From: smcl@sytex.com (Scott McLoughlin)
Subject: Re: Comparing productivity: LisP against C++ (was Re: Reference Coun
Message-ID: <BFs5Xc1w165w@sytex.com>
Sender: bbs@sytex.com
Organization: Sytex Access Ltd.
References: <3dvgr9$e2l@celebrian.otago.ac.nz>
Date: Fri, 30 Dec 1994 05:14:46 GMT
Lines: 70
Xref: glinda.oz.cs.cmu.edu comp.lang.c++:105254 comp.lang.lisp:16204

nmein@bifrost.otago.ac.nz (Nick Mein) writes:

> The simple fact is that Marco's code did not contain application-defined
> error handling. I do not accept that because CLOS provides default error
> handling that application-defined handling is not (ever) required.
> 

Howdy (and Happy New Year),
        
No one has made the simple observation: this whole debate is
foolish. It's been debated before and it was foolish then and
it is still foolish.

I happen to think the Lisp'ers did a surprisingly good job
responding to the challenge given that it was a bit twiddling
and file/io task, a traditional strength of C/C++.

If you want to march C/C++ right up to the top of the hill, as
it were, include image size in the challenge. On my machine, at
least, the C/C++ program will be miniscule, which is nice when
writing small utilities like this.

As for scalability, I personally think that wrapping a toy 
utility up in a few "class Image {" style wrappers is a big
fat joke. I tried, (and failed, I freely admit) to write an
"Image" class a few years ago.  Designing reusable, extensible
classes in C++ seems to be quite a black art, though some folks
seem to be good/getting better at it as time marches on. Anyway,
I'd give both the C++ and the Lisp examples a big F- on 
scalability. But it wasn't part of the challenge anyway.

As for error handling, really robust error handling with good
cleanup and elegant resumption is pretty tough going no matter
how good your language facillities are. I think that most folks
who care about this kind of thing recognize Lisp's CONDITION 
system and UNWIND-PROTECT facillity as one of the more complete
and elegant language level error handling systems. It has a
fairly long history as well.

Anyway, none of the examples used either C++'s or Lisp's error
handling facillities. I don't see what the big deal is over
who exactly calls "exit()". If the runtime system does it for
you, so much the better. I'd give both programs a big F- on
error handling.

In conclusion, C and C++ are fine languages. They are very
popular and need not be "defended".  I think that Lisp and
Lisp like languages will become more popular.  I formerly
though the environments were too darn big, but very popular
4GL's are rapidly dwarfing Lisp systems in size, so I think 
this is less of a concern.  Lisp's memory management is a
real boon WHEN YOU CAN AFFORD IT, which is quite frequently
I think.  The Lisp compiler folks continue to work pretty
hard on making GC cheap, cheaper than most naive refcount
schemes.  Lisp is real nice for "rapid prototyping", especially
when "real algorithms" are involved so you need something
more than a forms painter/record manager. With moder Lisp
compilers, the "prototype" can frequently be cleaned up
and deployed. Not a bad deal.

As for C/C++, I use them all the time and I don't suspect that
will change much in the near future.  The need to interface with
OS level services at a very low level seems to be _increasing_
with the proliferation of middleware API's, so C and C++ will
remain in my toolbox for years to come.

=============================================
Scott McLoughlin
Conscious Computing
=============================================
