Although this is a followup to some of the Lisp+ discussions that have
been going on, I've started it under a new thread because I think that
it is a new concept. (Now new to me, but new wrt the ongoing debate.)
The reason that *I* (a long time, hundreds of thousands of lines of
code) Lisp programmer still get this "oh no, here we go again; maybe I
should use C (or, god forbid, C--)" feeling everytime I begin a new
project in Lisp is that there is no "one true Lisp *IMPLEMENTATION*"
CL went a long way to correcting this age old problem (how many other
programming languages can even boast age old problems!?) but there
are still ten slightly different ones, none of which are (a) free, (b)
complete, and (c) run on everything (or, at least both unix and IBM
PCs). In most other sucessful cases (C, web browsers, etc) there are
one or two major implementations and that's pretty much it. And
generally one of those is free and everyone uses it (gcc, netscape).
I believe that we would go a *long* way toward resolving the lisp
lossage nightmare if we took the following steps:
1. *Everyone* (at least everyone who deal with freeware) work from and
on the same implementation; gcl? cmucl? kcl? whatever. The goal being
that when someone says "Lisp? Where do I get it?" The answer isn't
"Well, that's a hard question....." (How do we agree? Dunno. Maybe
just vote amongst ourselves and everyone agrees to simply use the
winner!)
2. Get whatever it is we agree upon to ship with every unix box, and
package it for PCs. Indeed, give the damned thing to Gates (with the
proviso that they can't charge for it).
(Optional 3. Have a version that runs like (I really hate to have to
say this) perl/awk/sed: like you type: lisp foo.lsp to the shell and
it just does what's in foo.lsp without bothering you. (This is both
very useful, and, I think, required to get unix users out of their
wedgedness about PERL, which is evil incarnate.))
(Optional: 4.While we're at it, now that we have one true lisp, why
not make the interpreter (at least for unix) do shell things so that
unix users can at least vaguely understand what it means to be able to
talk to your programming environment.)
(Optional: 5. Provide a means whereby other packages written in dumb
languages can use our "Universal Lisp" as a convenient internal
programming language.)
With all the smart people in this community, this CAN'T be THAT HARD!
It just takes the will and some swallowing of your NIH pride!
'Jeff
In <··········@usenet.srv.cis.pitt.edu>, ·······@neurocog.lrdc.pitt.edu (Jeff Shrager) writes:
> ...
>1. *Everyone* (at least everyone who deal with freeware) work from and
>on the same implementation; gcl? cmucl? kcl? whatever. The goal being
>that when someone says "Lisp? Where do I get it?" The answer isn't
>"Well, that's a hard question....." (How do we agree? Dunno. Maybe
>just vote amongst ourselves and everyone agrees to simply use the
>winner!)
Hard to enforce. The problem is that the features supported differ to much.
>2. Get whatever it is we agree upon to ship with every unix box, and
>package it for PCs. Indeed, give the damned thing to Gates (with the
>proviso that they can't charge for it).
He'll find a way to charge and he prefers VB anyway. Otherwise, if you have
net access you can get it easy enough anyway (it might help if the FAQ would
give a rating of the implementations (feature support, best fit for which
environment etc)
>(Optional 3. Have a version that runs like (I really hate to have to
>say this) perl/awk/sed: like you type: lisp foo.lsp to the shell and
>it just does what's in foo.lsp without bothering you. (This is both
>very useful, and, I think, required to get unix users out of their
>wedgedness about PERL, which is evil incarnate.))
If the lisp interpreter would skip ove a first line starting with # this could
already be done with current Unix mechanisms.
>(Optional: 4.While we're at it, now that we have one true lisp, why
>not make the interpreter (at least for unix) do shell things so that
>unix users can at least vaguely understand what it means to be able to
>talk to your programming environment.)
scsh?
>(Optional: 5. Provide a means whereby other packages written in dumb
>languages can use our "Universal Lisp" as a convenient internal
>programming language.)
Elk? Guile? Due to less bulk, scheme seems to be a better choice for that
>With all the smart people in this community, this CAN'T be THAT HARD!
>It just takes the will and some swallowing of your NIH pride!
>
>'Jeff
>
Hartmann Schaffer
: (it might help if the FAQ would
: give a rating of the implementations (feature support, best fit for which
: environment etc)
This is a good step, but the features don't really differ so much that
it's worth having so many whole new implementations! All the major
ones are just CL by some other name with very slight
incompatibilities. I've used about 20 lisps now in as many years and
haven't had to relearn the language once; just spend a week trying to
find and bring up the closest and most convenient implementation for
my platform -- which is never close nor convenient. In the real world
you type "cc" (or gcc) on *any* unix box and you win; you run qbasic
on *any* dos box and you win. You bring up the same VB everywhere! I
can't believe that there's any reason to have 12 slightly different
lisp implementations, none of them fully supported and on all major
platforms.
: >(Optional: 5. Provide a means whereby other packages written in dumb
: >languages can use our "Universal Lisp" as a convenient internal
: >programming language.)
: Elk? Guile? Due to less bulk, scheme seems to be a better choice for that
Whichever. This is my point exactly. The answer to: "How do I run
lisp?" Is: "Well, it's a long story, beginning with: Which one?"
Which is annoying to us heavy lisp users, embarassing to the
community, and is going to make lisp extinct.
'Jeff
In article <··········@usenet.srv.cis.pitt.edu> ·······@neurocog.lrdc.pitt.edu (Jeff Shrager) writes:
>
> This is a good step, but the features don't really differ so much that
> it's worth having so many whole new implementations! All the major
> ones are just CL by some other name with very slight
> incompatibilities. I've used about 20 lisps now in as many years and
> haven't had to relearn the language once; just spend a week trying to
> find and bring up the closest and most convenient implementation for
> my platform -- which is never close nor convenient. In the real world
> you type "cc" (or gcc) on *any* unix box and you win; you run qbasic
> on *any* dos box and you win. You bring up the same VB everywhere! I
> can't believe that there's any reason to have 12 slightly different
> lisp implementations, none of them fully supported and on all major
> platforms.
This this not fully correct. If a Common Lisp was installed on a machine
and you type "cl" or "gcl" you usually win unless your system administrators
did a bad job. And it doesn't make sense to use something that is already
there versus something that is more powerful but needs to be installed. For
example it is silly to use "vi" over Emacs only because "vi" is usually
there and you sometimes have to install Emacs.
Common Lisp was invented to serve just that purpose that you complain about.
However I will admit that I have often complained that Common Lisp should
have been defined in two levels: Level 0 containing all of the special forms
and minimal functions and Level 1 containing all of the rest that could be
defined in terms of Level 0. If you *really* think about it there are *far*
more dialect of C and C++ if you consider the myriad of very different C and
C++ libraries that exits. Since Common Lisp essentially defines the
equivalent of these libraries with only one consistent definition then by
your way of thinking Common Lisp is a bigger win than C or C++ since all of
those C and C++ library choices are not always there (nor could they be!).
>
> Whichever. This is my point exactly. The answer to: "How do I run
> lisp?" Is: "Well, it's a long story, beginning with: Which one?"
> Which is annoying to us heavy lisp users, embarassing to the
> community, and is going to make lisp extinct.
>
Quite the opposite. Lisp has always been an evolving language which is why
it may outlive others like C++ and Java. The idea of a Common Lisp is just
a sanity check in that evolution, but also it satifies your requirements
above.
The reasons why Lisp *appears* to becoming extinct was discussed in this
newsgroup before. The consensus was that the reasons were more political
than pragmatic. But politics swings radically which is why I predict that
Lisp will be rediscovered in the future. If Lisp is a genuinely good idea,
and it seems to be since it has survived for so long, then it will not
become extinct, since genuinely good ideas do not become extinct. Unless of
course they are hit by a meteor.
--
William P. Vrotney - ·······@netcom.com
In article <··········@nic.wat.hookup.net> ········@wat.hookup.net writes:
>In <··········@usenet.srv.cis.pitt.edu>, ·······@neurocog.lrdc.pitt.edu (Jeff Shrager) writes:
>
>>(Optional 3. Have a version that runs like (I really hate to have to
>>say this) perl/awk/sed: like you type: lisp foo.lsp to the shell and
>>it just does what's in foo.lsp without bothering you. (This is both
>>very useful, and, I think, required to get unix users out of their
>>wedgedness about PERL, which is evil incarnate.))
>
>If the lisp interpreter would skip ove a first line starting with # this could
>already be done with current Unix mechanisms.
Many Lisps let you do something like this:
lisp -load foo
which is pretty close.
-- jd