[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
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: ······@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.
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
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.
From: ······@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.
Another option is to use a real-time CLOS implementation, but I don't
know if such an implementation is available for general public
purchase yet.
--
Lawrence G. Mayka
AT&T Bell Laboratories
···@ieain.att.com
Standard disclaimer.
In article <··········@necco.harvard.edu> ··@hershey.harvard.edu (Paul Graham) writes:
> 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.
I say it is an issue in a prototype, and that tree-shakers are a pain.
Typical Common Lisp implementations produce images and running
systems that are far too large. Unfortunately, for years and years
people have been claiming that it's not a problem, because "memory
is so cheap" or because "good operating systems" will be able to
handle large images efficiently. As a result, tremendous damage
has been done to Lisp's reputation by creating the impression that
Lisp systems are inherently very large when in fact they can be
extremely small.
That said, however, I have to note that I have fewer problems with
programs too large for machines and running out of swap space than
some C++ programs seem to.
> 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.
There's no much (if anything) that can't be translated into C one
way or another. That's why it's possible to write Lisp compilers
(such as KCL's or my version of the Franz Lisp compiler) that compile
Lisp to C. Closures can be handled.
BUT these compilers don't emit C that you'd want to maintain as C.
There are some things billed as Lisp-to-C "translators" that must
do better, but since I've never seen their output I can't say whether
it's good enough.
One way to translate to C is to write a new program using what you
learned from the Lisp one. That may be more effective than if you
try to restrict your Lisp to what can be translated straightforwardly
by hand (or w/ the aid of tools you could easily write).
-- jeff
In article <··········@cogsci.ed.ac.uk>, ····@aiai.ed.ac.uk (Jeff Dalton) wrote:
> BUT these compilers don't emit C that you'd want to maintain as C.
> There are some things billed as Lisp-to-C "translators" that must
> do better, but since I've never seen their output I can't say whether
> it's good enough.
check out ftp://ftp.netcom.com/pub/hb/hbaker/CheneyMTA.html (also .ps.Z) and
ftp://ftp.netcom.com/pub/hb/hbaker/cboyer13.c
In article <··········@cogsci.ed.ac.uk> ····@aiai.ed.ac.uk (Jeff Dalton) writes:
>From: ····@aiai.ed.ac.uk (Jeff Dalton)
>Subject: Re: case for Lisp
>Date: Mon, 6 Feb 1995 15:33:11 GMT
>In article <··········@necco.harvard.edu> ··@hershey.harvard.edu (Paul Graham) writes:
>
>> 5. Conversion to C. How are you going to do the conversion?
>>
>One way to translate to C is to write a new program using what you
>learned from the Lisp one. That may be more effective than if you
>try to restrict your Lisp to what can be translated straightforwardly
>by hand (or w/ the aid of tools you could easily write).
Another approach, used by lets see um "emacs", "autocad?" "interleaf?" and
probably others, it to write the thing in Lisp and 'C' together. That way the
product is very flexible, yet can do things only accessible via 'C'.
Bill
In article <··········@necco.harvard.edu> ··@hershey.harvard.edu (Paul Graham) writes:
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.
You probably missed the last time this thread went around: besides
the rather large runtime, CommonLisp has a serious problem with space
for certain data structures compared to C. In particular, small
structures containing numerical and/or character data can easily
require several times as much space in CommonLisp than in C. That is
because of space overhead for extra pointers and type information
that cannot realistically be eliminated in a CL implementation.
Many of the symbolic languages or garbage collected languages fell
into the same trap as CommonLisp by not addressing this issue.
Notable recent exceptions are Eiffel and SML2000.
Thomas.
In article <······················@bitburg.bbn.com>, ········@bitburg.bbn.com (Ken Anderson) writes:
|> You probably missed the last time this thread went around: besides
|> the rather large runtime, CommonLisp has a serious problem with space
|> for certain data structures compared to C. In particular, small
|> structures containing numerical and/or character data can easily
|> require several times as much space in CommonLisp than in C. That is
|> because of space overhead for extra pointers and type information
|> that cannot realistically be eliminated in a CL implementation.
Is X3J13 going to continue working to improve the standard,
or lispers are more interested in defining new languages (read: Dylan)
before getting one to be competitive?
Specifically, I am thinking of `class names which are lists', which
is compatible with the current symbol-only restriction, and could
homogeneize the type system. Practical interest? Support for
`generic classes' (as called in Eiffel) [I think some people call
them parametric].
Rough example
[discussion would be needed on the scope of the formal parameters,
as well as on the format and possibilities of actual parameter lists
(eg: probably quotes and backquotes should be used, as the type restrictions
could also specialize, and parts of them be parameters of the new definition)]
Although not shown here, some parameters might expect things other than types
(eg: numbers for (mod n) types).
(defclass (foo (x-type real) y-type &optional (z-type (or x-type null))
((x :accessor x :type x-type)
(y :accessor y :type y-type)
(z :accessor z :type z-type)))
(make-instance '(foo single-float fixnum))
=> uses of `x' can be open coded
=> uses of `y' can be open coded and a fixnum stored directly in the object
(make-instance '(foo single-float fixnum fixnum))
=> now `z' can be open coded, too (can't be null)
(make-instance '(foo complex t))
=> ERROR
Work on extending DEFSTRUCT syntax wouldn't be necessary,
as (:metaclass structure-class) should do the right thing.
There are issues regarding SUBTYPEP, method dispatching, etc.
(I would go for the `dumb' solutions, as the thing here is about
efficiency. It also seems to me that it doesn't exist a
candidate for a `smart [and complicated]' semantics which is
_Evidently_Right_).
This is orthogonal of any work on generic functions to extend
the form of specializers, which would be non-trivial
(and should be approached from a MOP perspective, really).
--
Fernando D. Mato Mira http://ligwww.epfl.ch/matomira.html
Computer Graphics Lab
Swiss Federal Institute of Technology (EPFL) Phone : +41 (21) 693 - 5248
CH-1015 Lausanne FAX : +41 (21) 693 - 5328
Switzerland E-mail : ········@di.epfl.ch
In article <·················@netcom4.netcom.com> ···@netcom4.netcom.com (Thomas Breuel) writes:
>
>You probably missed the last time this thread went around: besides
>the rather large runtime, CommonLisp has a serious problem with space
>for certain data structures compared to C. In particular, small
>structures containing numerical and/or character data can easily
>require several times as much space in CommonLisp than in C. That is
>because of space overhead for extra pointers and type information
>that cannot realistically be eliminated in a CL implementation.
BTW, C has a similar problem when compared to Common Lisp in
some cases, because Lisp represents conses (hence lists) more
efficiently that what you'll get with malloc.
-- j
In article <··········@cogsci.ed.ac.uk> ····@aiai.ed.ac.uk (Jeff Dalton) writes:
>BTW, C has a similar problem when compared to Common Lisp in
>some cases, because Lisp represents conses (hence lists) more
>efficiently that what you'll get with malloc.
Not true in general. It depends which malloc you are using.
In article <··········@necco.harvard.edu> ··@hershey.harvard.edu (Paul Graham) writes:
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.
Very true.
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.
Programmers choose languages not because of their power but because of
their utility. Being able to write a mean 8-queens, Fibonacci, or
constraint solver doesn't matter in the UNIX market; being able to
grind through 100M text files quickly, start processes, allocate
pseudo ttys, execute UNIX-specific file-system operations, write
scripts that start up quickly, and read and write DBM files does.
In fact, I would very much like to use languages that are more
powerful than C, awk, and Perl. Like many programmers on UNIX, I know
CommonLisp, SML, and other languages intimately. In fact, I learned
Lisp before I learned C. But CL just doesn't get most of my work done
effectively. That's why it is particularly frustrating when people
like you stand up and say, in effect, "well, you aren't using CL
because you are stupid".
Of course, judging from your defense of CL, you do not seem to have a
good idea yourself where the real problems with applying CL outside
its current niches are. So, it isn't surprising that you seek fault
with the customers and not the language and its implementations. But
until you realize that the problem is with CL, not with the people who
aren't buying, you are never going to fix it.
Thomas.
In article <··········@necco.harvard.edu> ··@hershey.harvard.edu (Paul Graham) writes:
Let me also reply to some of the problems [with CL] Chris mentioned:
1. Garbage collection. [...]
2. Too Slow. [...]
In my experience, the majority of cycles on UNIX machines generally
goes into running code written in languages that are much less
efficient than CommonLisp and that use automatic memory management
(Perl, awk, etc.). That has actually been true for many years.
Similar patterns probably exist on other OSes as well (CMS/REXX,
DOS-Windows/VisualBasic-WordBasic, etc.).
The market has been quite willing to buy slow, garbage collected
languages. If CommonLisp doesn't succeed, this isn't the reason.
Thomas.