Re: Selling Lisp

[creedy@mitre.org (Chris Reedy)]

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

> Hello fellow lispers.  I am in the process of convincing my organization that 
> lisp is good language to use for application development.  We all know the 
> advantages of lisp with respect to being an excellant prototyping
environment.  
> 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.  I 
> hope to compress development time using this approach.  a list of companies 
> which do this or simply use lisp would help in persuading my fellow engineers 
> who are primarily non-lispers.
> 
Ok -- A little background first:  I used to work for a company that was
selling Lisp applications to traditionally non-Lisp users (the company has
since folded).  A lot of the information below is based on that
experience.  I like Lisp and use MCL on my home machine.  I also use C++
on my home machine, so I have a foot in both communities.  So, (flame
retardant suit on) let me give you my impression of why you have a tough
job ahead of you.

1.  Garbage collection.  We know the issues here.  However, the argument
that emphemeral garbage collectors solve the problems doesn't carry a lot
of weight with the skeptics.  Some specific problem areas you may need to
address:

  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.

  b.  User interfaces with garbage collectors are the pits.  I like to see
things as I type them and have button pushes happen when I push the
button, not at some later point in time.  (The little "GC" cursor that MCL
uses simply helps explain why the system is behaving badly but is not a
fix for the bad behavior).  If your users are not computer literate (and
potentially even if they are) this will probably be a major source of
unhappiness.  (Aside:  I think this might be a good area for some research
in garbage collection algorithms in a true multi-processing environment).

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 could lose
your case if you demonstrate an application that is "too slow" and then
lamely try to explain how putting in the declarations will create
something with acceptable speed.

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).

4.  Bindings and COTS Integration.  Many current programming efforts are
done in environments where you have to integrate with other software such
as DBMSs and GUI packages.  We all know that this can be done by using the
foreign function interface.  However, you may have to devote significant
effort to developing these interfaces as opposed to getting them for free
in C.  Also, people are not tolerant of the "similar to" approach.  For
example, if they want MOTIF they may not accept a GUI system which is
"similar to" or "almost exactly like" MOTIF.

5.  Conversion to C.  How are you going to do the conversion?  If you use
an automatic translator the resulting C code will probably be
unmaintainable, all the examples I have ever seen certainly are.  If you
perform a manual translation you need address the problems associated with
memory management in C/C++.  You may have to make significant changes in
your design in order to support C/C++ style memory management where the
program knows what is garbage and frees it when it becomes garbage (a good
argument for _using_ a garbage collector, even after the program is
converted).

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.  When you're demonstrating people will
be more tolerant if the program outputs an "I'm failing" message and
terminates than being thrown into this mysterious thing called a
listener.  After all you're giving them the same thing they're used to
when they run MS Windows :-).

------

So what would I suggest you do about all this.  First, you need to examine
the kinds of applications your organization prototypes and/or fields and
the environment that these applications run in.  Then you need to decide
how appropriate Lisp is for each kind of application.  Hopefully you will
come to the conclusion that Lisp is appropriate for some significant part
of your organization's applications.  If you don't come to this
conclusion, you should fold your tent and disappear into the night.  (I
don't see any problem with acknowledging that some part of the application
base is better done in C, and you might score some points for technical
honesty).

Second, you need to decide how you should address the kind of issues I
discussed above.  See if you can find someone who can and will play
devil's advocate to help you refine and solidify your arguments.

Third, you need to decide how you will approach your management.  Based on
what you said above, your reason for proposing Lisp is a significant
increase in productivity for software development.  That's a good argument
since it can be easily translated into dollars.  You need to be prepared
to discuss the secondary costs of adopting Lisp, such as, for example,
training of maintenance programmers and additional or upgraded hardware. 
You want to try to make an argument that using Lisp can _potentially_ save
a lot of dollars (or something management can easily translate into
dollars, such as labor years).

Finally, I would suggest that when you approach management, you propose a
prototype as proof of concept of your approach.  For your prototype, pick
some problem that you think will show Lisp off to its best advantage, one
that maximizes its good points and where the bad points (see above) are
minimized or unimportant.

Make sure that the dollar commitment you are requesting (for the
prototype) from your management looks good with respect to the proposed
costs and benefits or your approach.  You will look particularly good if
the investment to prove the concept looks very small relative to the
potential benefit.  ("Even if he's wrong we're only risking x dollars and
if he's only half right we still save big!")  However, don't overstate
your case -- that will always come back to haunt you later.

Bottom Line: If you can convince yourself that using Lisp makes both
technical and business sense for your organization, go for it.  Be
prepared to address the issues and deal with the skeptics.

  Best wishes and good luck, Chris.

Chris Reedy, Workstation System Engineering Center, Z667
The MITRE Corporation, 7525 Colshire Drive, McLean, VA 22102-3481
Email: creedy@mitre.org  Phone: (703) 883-7183  FAX: (703) 883-6991