case for Lisp

[pg@das.harvard.edu]

	In article <9501027917.AA791764534@ccmail.NSD.FMC.COM>,
	paul_hasse@NSDGATE3.nsd.fmc.com (paul hasse) wrote:

	> I am looking for ideas on how to present a case for developing 
    > applications originally in lisp and when necessary, using a 
    > translator to take it to C.

Because the question "Why Lisp?" gets asked so often, I devoted the
first chapter of _On Lisp_ (Prentice Hall, 1993) to it.  See that for
the kind of argument you might present to your organization.  But I
warn you that few people are going to be convinced to use a language
on the basis of its power.  The great majority of programmers are
used to some particular language, and are only going to learn a new
one when they are forced to.

How are they forced to?  Ultimately, on the basis of the language's
power.  They work for a company that writes software in Cobol; the
company is crushed by competitors that use C; the programmer has to
learn C to get a new job.  

So I think that Lisp (or Dylan, which is Lisp by another name) will 
only become widespread when companies start to use it to beat their 
competitors to market.  Fortunately, hardware makes it almost inevitable 
that this this will happen, for the same reason that it was inevitable 
that C would replace assembler.

	From: creedy@mitre.org (Chris Reedy)

Let me also reply to some of the problems Chris mentioned:

	1.  Garbage collection. 
	  a.  You can't use _any_ garbage collecting system if you have _hard_
	real time requirements.  You may have problems if you _ever_ need to do a
	full garbage collection in a soft real time environment.

By far the greatest cause of GC is one's programming style.  It is not 
that difficult to write software that conses little or never.  Gensym 
writes real-time applications in Lisp, for example.  Two people from 
Gensym wrote about it in the Sept 91 Communications of the ACM.

The new generation of garbage-collectors are really good, though.
Avoiding GC is now much less of an issue than it was 10 years ago.

	2.  Too Slow.  Again, we know the issues here.  However, if Lisp _with_
	_declarations_  performs as well as other languages you had better decide
	how and when you will supply the necessary declarations.  

Supplying declarations is not as mysterious or inconvenient as people
think.  Nor as ugly, since you can easily write a macro to insert
declarations into numeric expressions.  I have included such a macro
in the new introduction to Common Lisp that I'm writing now.

	3.  Too Big.  A Lisp image for a _small_ program can be ten times the size
	of a corresponding executable written in C.  Again, you need to think
	about when and how you will address this issue.  (It may not be an issue
	at all in a prototyping environment).

This was another subject dealt with in the articles in the Sept 91 CACM.
Many Lisp systems come with tree-shakers that can discard the bits of
Lisp that you don't need at runtime.  And as you say, it's not an issue
in a prototype.

	5.  Conversion to C.  How are you going to do the conversion? 

One way to do it is to write code that is isomorphic to C.  Even doing
this, it will still be a big win to write the program in Lisp.

If you use closures, you're going to have a hard time translating it. But
if something is impossible to translate into C, it's also impossible
to write in C, so perhaps the best bet, ultimately, is to take full
advantage of Lisp and write a program that no competitor using C can 
duplicate.

	6.  The Listener.  The Lisp habit of dropping into the listener when
	something goes wrong is great when you're debugging and a disaster if you
	have a non-computer literate user.  

It's actually one of the advantages of Lisp that it catches errors at
runtime.  When you get an error in a C program, it seg-faults and your 
whole app crashes.  To your annoyed user, there may be little difference
between the two cases.  But suppose you know a piece of code is flaky.
In Lisp you can wrap the call in an ignore-errors during your demo.  What 
recourse do you have in C?

Paul Graham