Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

ACM SIGPLAN "Lisp Pointers" is gone. is Lisp dying?

27 views
Skip to first unread message

Tomoyuki Tanaka

unread,
Jun 28, 1997, 3:00:00 AM6/28/97
to

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: tan...@ucdavis.edu or tan...@indiana.edu

Kent M Pitman

unread,
Jun 29, 1997, 3:00:00 AM6/29/97
to

[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 <5p1kcp$aht$1...@mark.ucdavis.edu>
ez07...@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.


Marc Wachowitz

unread,
Jun 29, 1997, 3:00:00 AM6/29/97
to

pit...@world.std.com (Kent M Pitman) wrote:
> 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.

As you're the editor - or at least that's my impression - of ISLisp,
I wonder whether you'd comment a bit on its perspective? (Assuming it
has any future; some people don't seem to like it, but I still think
there would be use for a small Lisp which could be statically compiled
and embedded into "traditional" programs/libraries - and ISLisp might
be at least a starting point.) Do you expect semantic changes beyond
working draft 20? Is there still hope that some kind of top-level name
space management (modules, packages, whatever) is introduced? What about
fixnums or similar optimization facilities, a reliable way for macros
to parse e.g. :rest, and to recognize unnamed symbols, and the option to
pass some name to gensym for a potential debugger, or print-object as a
generic function - to name just a few concerns wrt. goals claimed in the
introduction? (More detailed criticism is available on request, in case
there's still movement in this area and someone isn't too busy and/or
bored to care about these issues ;-)

Somehow it seems lots of people even in the Lisp community are seeing
macros mostly as tools to provide syntactic sugar (thus Dylan's departure
from s-expressions and fully expressive macros). Very sad, IMO.

> In the future, I hope the choice of what language people program in
> will become more of a private choice,

Well, except for isolated programmers, I doubt it. Hardly any company
would risk being left with code in some language which nobody of their
employees is able to maintain (and even more than one single language
is frequently already a problem). In many cases this may be sad from a
technical viewpoint, but I doubt that technology will cause significant
changes to such commercial problems (hmm, this sounds like yet another
argument for overthrowing capitalism).

Of course, at home I can already use almost every language which I find
interesting - assuming there's some implementation available (frequently
the case for Linux/x86), or I can build one with reasonable effort; but
I guess that wasn't primarily what you had in mind ;-)

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

At least we can hope that the euphory for Java may perhaps improve some
system interfaces for garbage-collected languages. At this time, I think
that's the most severe _technical_ hindrance for multi-language usage
on modern platforms, since the rest can usually be solved with reasonable
effort by thin interfaces, without hurting the more flexible languages
(like Lisp) too badly.

-- Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de>

Martin Rodgers

unread,
Jul 4, 1997, 3:00:00 AM7/4/97
to

With a mighty <sfw205l...@world.std.com>,
pit...@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

0 new messages