In article <··········@necco.harvard.edu> ··@hershey.harvard.edu (Paul Graham) writes:
--> [This is a response to a thread that originally began on info-mcl.]
-->
--> In article <······················@ccmail.NSD.FMC.COM>,
--> ··········@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
guess I gotta get this...
--> 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.
not necessarily--that only happened to me once, in 1976, when I was told
that at college I'd have to use FORTRAN. each change after that was made
because I chose to, after investigation and discovering that the
language was WAY more powerful than what I'd been using.
--> 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
^^^^^ right. that was it.
--> From: ······@mitre.org (Chris Reedy)
Hi Chris!
--> 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.
-->
--> 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.
paraphrasing your previous paragraph:
--> By far the greatest cause of SLOWNESS is one's programming style. It is not
--> that difficult to write software that is noticeably FASTER.
--> 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.
my experience (not as extensive as Ken Anderson's) is that declarations
are not the source of or solution to the problem. or at least the ones
I've faced...
lousy algorithms are. every time I've had a problem for which I found a
speedup, it wasn't by using declarations--it was by seriously altering
the algorithm.
two weeks ago I produced a 3x speedup in the interface between our DB
and the clients by making an algorithm change. no declarations involved
at all.
this is not to suggest that decls aren't worthwhile...but I dont' think
they are the holy grail here.
--> 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.
we have a convenient, albeit occasionally cryptic firewall for this.
it's quite short/small, uses debug-hook to create a pop-up containing
the various restarts, which are not necessarily very meaningful for the
user, but they can be told what the messages mean, and we can replace
the messages when we need to. kudos to Jeff Morrill for creating this.
one of the choices is of course to continue on into the
listener/debugger. casual users typically won't ever choose that one.
--> 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.
this can happen in lisp too. I have IGNORE-ERRORS around some places and
one of them STILL manages to crash our standalone client app. I think.
it's damn tough to debug such a thing.
-- clint