[ruby-talk:15547] FW: evolving lisp

Hi,

Thought you might find this interesting.

Wayne

----- Original Message -----
From: "Miles Egan" <[e-mail]>
Newsgroups: comp.lang.lisp
Sent: Sunday, May 20, 2001 1:59 PM
Subject: evolving lisp


> Like many of the readers of this group, I've spent a lot of time pondering
> the popularity and evolution of lisp.  I've also spent a lot of time
> playing with the various implementations of lisp out there and I've come
to
> a few tentative conclusions:
>
> 1.  Althouth Lisp users often criticize Scheme for it's overly
conservative
> and incomplete definition, in many respects Lisp now suffers from the same
> incompleteness for modern application development.  Many of the tools
> needed to develop typical modern-day applications are non-standard among
> implementations, crude and often only partially functional, or simply
> unavailable.  FFI, database connectivity, network protocol bindings, gui
> toolkit bindings, xml tools etc.  are fragmented and unstandardized among
> all CL implementations.
>
> 2.  Ironically, the diversity of CL implementations seems to exacerbate
the
> problem of extending CL.  The implementations I've seen of some of the
> above tools clearly expend a lot of effort trying to support them all,
with
> code which is a mess of implementation-specific switches and parallel FFI
> code.  I have to imagine that time spent dealing with cross-implementation
> compatibility is time not spend adding robustness, functionality, or
> documentation.  The irony here, of course, is that in some ways it is the
> very standardization of Lisp that allows for this kind of forking because
> there is a reference standard upon which to base new and otherwise
> divergent implementations.
>
> 3.  As a result of this fragmentation, Lisp is actually a poor choice for
> many important kinds of application development.  More and more it is
> pushed into the role of a central application intelligence interfaced with
> more mainstream applications which provide connectivity to the rest of the
> world.  Only its superb core design has allowed to retain even this
> position.  But for many other applications, the burden of maintaining this
> kind of homogeneous system is too high and it really is easier to develop
> in a more gregarious language.
>
> To me, this is truly depressing.  The more I study Lisp the more I
> appreciate the genius of its design.  As others have recently commented in
> this group, mainstream computer hardware has finally evolved to the point
> where all the old objections to Lisp are irrelevant and other popular
> languages are much LESS efficient.  In the distributed, networked world of
> modern software development, Lisp should be king, but it languishes in
> niche applications.
>
> A survey of the handful of languages that are growing reveals some obvious
> commonalities.  Living languages today are either funded and marketed by
> huge corporations with vast advertising and development budgets or are
> open-source languages supported by volunteers.  Since a Java or C# push
> isn't likely for Lisp, the only alternative seems to be a strong
> open-source development effort.  My impression of the popular open-source
> languages (Perl, Python, Ruby, Tcl and, to a lesser extent, Ocaml) is that
> they all have the following in common:
>
> 1.  A single implementation.  This means any extensions or add-on modules
> are developed only once and that their authors need only worry about
> architecture-related portability issues.  All developer effort goes toward
> maintaining and improving a single common implementation.
>
> In general, the authors of language extensions and external bindings are
> less experienced than the gurus who develop the core language, so it's
> crucial that the techniques for doing this are straightforward and
> well-documented.  I think that, in the long run, the success of an
> open-source langauge depends on these people more than on the core
> designers.  Most of these people would run in terror if they saw how
> difficult it is to write GTK bindings that work in CMUCL, CLISP, and ACL,
> for example.
>
> 2.  A simple and straightforward means of bootstrapping the language on
any
> sane platform with a c compiler.  All of these languages are very
portable.
>
> 3.  No langauge standardization bureaucracy.  The langauge designers are
> free to evolve the langauge when necessary.  These langauges have evolved
> quickly in response to user requests and technological shifts.
>
> Although there are high-quality free implementations of Lisp, the
> open-source Lisp community has so fair failed to build any of the momentum
> of these lesser langauges.  I believe it's due to the failure to recognize
> their strengths.  I may be heading a new and fairly large-scale
development
> effort soon which will involve a fair amount of the sophisticated logic
and
> intelligence for which Lisp is such a superb tool, but I don't think I can
> choose Lisp in good conscience for two reasons.  First, because I know I
> will waste a lot of time patching together code to interface to the rest
of
> the system and second because none of my developers are going to know
Lisp.
> Why?  Because the kinds of programs on which most younger programmers cut
> their teeth are a PITA to write in any open-source Lisp.
>
> What can be done about this?  I think it's imperative that the open-source
> Lisp community should learn from the Pythonistas:
>
> 1.  Pick a single open-source Lisp and focus all development effort on
that
> implementation.  We have more than our share of brilliant implementors,
but
> splitting our efforts among CLISP, CMUCL and SBCL is lethal.
>
> 2.  Do what it takes to make porting this implementation as simple as
> possible.  This implementation should compile and run on any new
> posix-compliant platform with nothing more than a C compiler.  It should
> also be trivial to make executables with this Lisp and it should function
> as an executable script interpreter with no extra gymnastics.
>
> 3.  Take advantage of having a single reference implementation to define a
> clean and straightforward CPAN-like system and a well-documented and
> straightforward C FFI.  I know there are efforts to define something like
> this now, but, to my eyes, they are all severely limited by the difficulty
> of supporting so many implementations.
>
> 4.  Build full-featured and reliable interfaces to common toolkits and
> protocols on this infrastructure.  Lisp should talk to databases as
> fluently as Perl, parse XML as well as Python, speak SNMP, HTTP, LDAP,
> IMAP, and SOAP, and couple with C as easily as Ruby.
>
> 5.  Take advantage of having a single implementation to extend and change,
> when necessary, the Common Lisp standard.  Obviously this should be done
> extremely carefully, but I think it's a mistake at this point to consider
> the CL spec to be either complete or sacrosanct.
>
> Speaking as an open-source hacker that would love to do what he can to
help
> promote and grow lisp, I think these kinds of changes are necessary.  As
it
> stands now, trying to get anything done in the current Babel is even more
> frustrating than watching Ruby, Perl, and Python slowly reinvent Lisp the
> hard way.
>
> --
> miles egan