Newsgroups: comp.lang.c++,comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!hookup!ames!pacbell.com!att-out!nntpa!nntpa.cb.att.com!lgm
From: lgm@polaris.ih.att.com (Lawrence G. Mayka)
Subject: Re: Comparing productivity: LisP against C++ (was Re: Reference
In-Reply-To: lofaso@gandalf.arlut.utexas.edu's message of 23 Dec 1994 14:24:45 GMT
Message-ID: <LGM.94Dec26164728@polaris.ih.att.com>
Sender: news@nntpa.cb.att.com (Netnews Administration)
Nntp-Posting-Host: polaris.ih.att.com
Organization: AT&T Bell Laboratories, Naperville, Illinois, USA
References: <3d86vh$1na@Mars.mcs.com> <D15BJ1.5Gq@research.att.com>
	<hbakerD15HAI.GCL@netcom.com> <D182M9.By1@cogsci.ed.ac.uk>
	<LOFASO.94Dec23082445@gandalf.arlut.utexas.edu>
Date: Mon, 26 Dec 1994 22:47:28 GMT
Lines: 65
Xref: glinda.oz.cs.cmu.edu comp.lang.c++:104887 comp.lang.lisp:16196

In article <LOFASO.94Dec23082445@gandalf.arlut.utexas.edu> lofaso@gandalf.arlut.utexas.edu (Bernie Lofaso) writes:

   either C or C++. I retain some degree of skepticism, even though I agree
   with the premiss of Lisp having a higher "productivity", because I am not
   totally convinced that the practitioners proclaiming its superiority are
   not (unintentionally) using test cases which are naturally more suitable
   for Lisp than C or C++. I don't know many (read none) people who write Lisp
   to interface to X-windows or make Sybase queries. These tasks are more what
   I'd envision as being a part of real world problems, not writing blackboard

There are plenty of CLOS programmers writing X-based GUIs and making
database queries (I do both myself), and there are fine commercial
products which support just such applications.  CLOS offers some
unique strengths very applicable to both of those two areas.

   systems. The simple observation that people with much Lisp expertise had to
   look up file I/O smells more than faintly of people who deal with
   specialised programs that probably wouldn't meet most definitions of real
   world programming. (Alert! Sweeping generalization here. Insert your own
   doubt factor to achieve comfort.)

I can only assume that the unfamiliarity was not with file I/O in
general, but with binary file I/O in particular.  Historically, Lisp
culture generally tends more toward:

- In-memory processing, instead of temporary files

- Persistent memory (via images or databases), instead of explicit
binary file I/O

- Object-passing between programs within a single address space,
instead of file-passing between programs in separate address spaces

- Builtin/uniform printing and parsing of objects when a
quick-and-simple approach is sufficient, instead of a unique ad-hoc
file format for every application

etc.

Thus, READ and WRITE are certainly well-known, but READ-BYTE and
WRITE-BYTE less so.

   say a struct. Common Lisp has gone a long way to enriching available data
   structures and I think it likely that good CL programmers can approach C
   and C++ efficiency in most programs. What they won't tell you when they
   make their "I can be nearly as efficient as you" argument, is that there is
   an additional level of effort involved and their productivity ratio suffers
   greatly. There ain't no such thing as a free lunch - remember. You either
   sweat the details and trade off speed for development time or you
   don't. Arguments of CL programmers having it both ways should be HIGHLY
   suspect.

The CL argument is actually the well-known 90/10 (or 80/20) rule.  The
claim is that in many or even most applications, the majority of the
run time is spent in a fairly small fraction of the source code.  Only
that portion needs to be heavily tuned for speed--and only after the
application's behavior is otherwise correct.  The net result is still
a time-to-market advantage, decreased development cost, and--very
important to managers--reduced risk of project failure.
--
        Lawrence G. Mayka
        AT&T Bell Laboratories
        lgm@ieain.att.com

Standard disclaimer.
