Re: Selling Lisp

[neves@neves.ils.nwu.edu (David Neves)]

In article <creedy-0302951409380001@clreedy-mac.mitre.org>,
creedy@mitre.org (Chris Reedy) wrote:
> 
>   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.
If you running on a tiny 4K machine there is not much you can do.  However
running on a bigger memory machine helps quite a bit.  Getting rid of
documentation strings and lambda lists can help as well.  Also there is no
one telling you that you have to use garbage collection in Lisp.  You can
do allocation and deallocation from your own memory pools.  The one thing
you can't do (that you can do in languages like C) is to explicitely
release one lisp datatype and reallocate it as another datatype.

>> 
> 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.
You can profile your code and put declarations in the functions where most
of the time is spent.  Profiling will probably suggest an algorithm
problem which will save even more time.
> 3.  Too Big.  A Lisp image for a _small_ program can be ten times the size
> of a corresponding executable written in C.
MCL is big for small things.  However I would say that most vertical
market code isn't that sensitive to memory footprint.   Even Hypercard
comes up in a 2.5 Meg partition. 
> 
> 5.  Conversion to C.  How are you going to do the conversion? 
If you are going to deploy in C then you should just develop in it.  To
make the conversion easier you will probably have to ignore much of the
user interface of MCL and that negates some of the advantage of MCL.
> 
> 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. 
There is no need for a program to drop a user into a listener.  An
appropriate condition handler(s) can trap all errors and put up
appropriate dialogs.

The biggest problem you might find is the "What do we do with code when
you leave" question.  There are lots of neat languages and environments
out there.  However one reason that employers stick with the more popular
languages is that they know that they can easily get someone to fill in
should you leave.