From: Tomoyuki Tanaka
Subject: ACM SIGPLAN "Lisp Pointers" is gone. is Lisp dying?
Date:
Message-ID: <5p1kcp$aht$1@mark.ucdavis.edu>
about a year ago (?)
ACM SIGPLAN "Lisp Pointers" died.
is Lisp dying?
is Lisp going to be like APL or FORTH in a few decades?
(when are we going to have a new editor for SIGPLAN Notices?)
;;; TANAKA Tomoyuki (Please call me "Mr. Tanaka" or "Tomoyuki".)
;;;
;;; For <soc.culture.japan> and <soc.culture.asian.american> FAQ
;;; files, see <http://www.cs.indiana.edu/hyplan/tanaka.html>.
;;;
;;; e-mail: ······@ucdavis.edu or ······@indiana.edu
From: Kent M Pitman
Subject: Re: ACM SIGPLAN "Lisp Pointers" is gone. is Lisp dying?
Date:
Message-ID: <sfw205ltkhe.fsf@world.std.com>
[I am replying to comp.lang.lisp only; as a matter of personal
preference, I absolutely abhor cross-posting and I prefer not
to contribute to the enormous pain it causes.]
In article <············@mark.ucdavis.edu>
········@dilbert.ucdavis.edu (Tomoyuki Tanaka) writes:
> about a year ago (?)
> ACM SIGPLAN "Lisp Pointers" died.
This was an administrative problem with the ACM--they sell magazines
on a schedule. They do not pay their editor. They do not pay their
writers. It is very difficult in the modern world for writers on a
regular basis, without compensation, to put together a whole magazine.
I am hoping Lisp Pointers will revive itself on the web. I have more
articles I plan to write for my column--but I'd personally prefer not
to see ACM dictating terms of when I'm "good" for delivering free copy
and when I'm "bad" for not delivering free stuff in time for them to
sell. A more laid-back web publication would be better. Or maybe it
will only end up that we'll each self-publish and there will be no
overriding "magazine" interface--but that's ok, too. It doesn't mean
we're dying--sometimes it just means we're each out of synch.
is Lisp dying?
I think if Lisp were dying, it would be dead. Lisp plainly didn't
become the language of choice for everyday commodity programming about
a decade ago when that war was being fought. However, at the same
time, it continued to survive because it provides features necessary
to certain tasks--the tasks for which it was originally designed:
large problems for which other languages do not scale up, problems
involving rapid change that require runtime redefinability, problems
that are ill-defined and not subject to precise
requirements/definitions documents, etc. Lisp was designed originally
for the AI community which was working on the world's hardest
problems. Its resilience in certain markets including planning and
scheduling, dealing with large quantities of heterogeneous data, etc.
have allowed it to survive. I see no evidence that it is receding in
those markets, and in some it may be gaining. But if you define
"life/death" of the language as its percentage of visibility in the
mainstream, you're being unfair, I think. The metric of success for
whales or mosquitos required in the world, in terms of how many it takes to
keep the ecosystem stable is not a simple numeric equivalence.
(There may be a lot of mosquitos, but they're not busy doing as much
or thinking as hard as those few whales. The comparison with C and
Lisp may be apt. :-)
is Lisp going to be like APL or FORTH in a few decades?
I frankly think this is an irrelevance, meaningful only to trend
followers and not particularly meaningful to practitioners. A language
is either available or it is not; it either has the interfaces to other
languages that you need or it does not.
Because of the large amount of investment required to change Lisp
in a way that compatibly runs old programs but still accomodates new
programs, Lisp changes slowly. However, there does seem to be motion
toward integrating Lisp through modern databases, object interfaces,
and even DLLs. (Part of this depends on what you think counts as Lisp;
I think Dylan is in the Lisp family, and represents a substantial step
forward in terms of the incorporation of DLLs into Lisp.)
In the future, I hope the choice of what language people program in
will become more of a private choice, and that the focus will be on
interface points between programming languages, just as in the past
the focus has been on the internals of objects being insulated and
only the points of communication among objects were important.
What matters is not how many people are using a language but how many
of those people using it are successful and whether the overall market,
whatever its size, is sustainable. Right now, several companies are
in the market, and that seems an encouraging sign.
With a mighty <···············@world.std.com>,
······@world.std.com uttered these wise words...
> Because of the large amount of investment required to change Lisp
> in a way that compatibly runs old programs but still accomodates new
> programs, Lisp changes slowly. However, there does seem to be motion
> toward integrating Lisp through modern databases, object interfaces,
> and even DLLs. (Part of this depends on what you think counts as Lisp;
> I think Dylan is in the Lisp family, and represents a substantial step
> forward in terms of the incorporation of DLLs into Lisp.)
I also think that Dylan is in the Lisp family, and its history
certainly supports this.
I welcome, as you put it, the incorporation of DLLs into Lisp. Is
there a good technical reason for not doing this? I can see why it
took so long for it to happen. After all Lisp, is a very different
language to Pascal or PL/I. Now that DLLs are so widely supported (I
can think of at least a handful of OSs that support dynamic linking),
the time for a language like Dylan has, I think, arrived.
However, this is not comp.lang.dylan, but comp.lang.lisp. Should we
then take a broader view of Lisp, that can incorporate such ideas, or
is that only for DylanHeads? I think it's too early to say that Lisp,
as defined by Common Lisp, is dying. Even if the common (pun intended)
perception amoung non-Lisp programmers is that Lisp _is_ dead. Some
people think that Clipper is also dead, but no, it lives on.
So how important is a language's image? Perhaps this is why some of us
feel so sensitive about Lisp's perceived weaknesses? I'd like to make
Lisp stronge by embracing those features, like DLLs, that are seen to
make other languages strong. Lisp is good at being flexible and
absorbing ideas from other languages. This results in additions to the
language, like CLOS. How would we add support for DLLs to Common Lisp?
We don't even have a standard FFI or support for multitasking, but is
this a problem? Individual vendors address these issues independantly.
Lisp programmers can deal with the differences, in spite of any source
code complications. These minor inconveniences are no technical reason
for not using multitasking or an FFI.
So, Common Lisp vendors should be able to address the DLL issue in the
same manner. Unless there's some deep technical problem that I'm not
aware of, that can't be beaten by a vendor?
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Please note: my email address is gubbish
Will write Lisp code for food