Why is the Lisp community so fragmented? [closed]

2019-01-21 03:02发布

问题:

To begin, not only are there two main dialects of the language (Common Lisp and Scheme), but each of the dialects has many individual implementations. For example, Chicken Scheme, Bigloo, etc... each with slight differences.

From a modern point of view this is strange, as languages these days tend to have definitive implementations/specs. Think Java, C#, Python, Ruby, etc, where each has a single definitive site you can go to for API docs, downloads, and such. Of course Lisp predates all of these languages. But then again, even C/C++ are standardized (more or less).

Is the fragmentation of this community due to the age of Lisp? Or perhaps different implementations/dialects are intended to solve different problems? I understand there are good reasons why Lisp will never be as united as languages that have grown up around a single definitive implementation, but at this point is there any good reason why the Lisp community should not move in this direction?

回答1:

The Lisp community is fragmented, but everything else is too.

  • Why are there so many Linux distributions?

  • Why are there so many BSD variants? OpenBSD, NetBSD, FreeBSD, ... even Mac OS X.

  • Why are there so many scripting languages? Ruby, Python, Rebol, TCL, PHP, and countless others.

  • Why are there so many Unix shells? sh, csh, bash, ksh, ...?

  • Why are there so many implementations of Logo (>100), Basic (>100), C (countless), ...

  • Why are there so many variants of Ruby? Ruby MRI, JRuby, YARV, MacRuby, HotRuby?

  • Python may have a main site, but there are several slightly different implementations: CPython, IronPython, Jython, Python for S60, PyPy, Unladen Swallow, CL-Python, ...

  • Why is there C (Clang, GCC, MSVC, Turbo C, Watcom C, ...), C++, C#, Cilk, Objective-C, D, BCPL, ... ?

Just let some of them get fifty and see how many dialects and implementations it has then.

I guess Lisp is diverse, because every language is diverse or gets diverse. Some start with a single implementation (McCarthy's Lisp) and after fifty years you got a zoo. Common Lisp even started with multiple implementations (for different machine types, operating systems, with different compiler technology, ...).

Nowadays Lisp is a family of languages, not a single language. There is not even consensus what languages belong to that family or not. There might be some criteria to check (s-expressions, functions, lists, ...), but not every Lisp dialect supports all these criteria. The language designers have experimented with different features and we got many, more or less, Lisp-like languages.

If you look at Common Lisp, there are about three or four different active commercial vendors. Try to get them behind one offering! Won't work. Then you have a bunch of active open source implementations with different goals: one compiles to C, another one is written in C, one tries to have a fast optimizing compiler, one tries to have some middlle ground with native compilation, one is targeting the JVM ... and so on. Try to tell the maintainers to drop their implementations!

Scheme has around 100 implementations. Many are dead, or mostly dead. At least ten to twenty are active. Some are hobby projects. Some are university projects, some are projects by companies. The users have diverse needs. One needs a real-time GC for a game, another one needs embedding in C, one needs only barebones constructs for educational purposes, and so on. How to tell the developers to keep from hacking their implementation.

Then there are some who don't like Commmon Lisp (too big, too old, not functional enough, not object oriented enough, too fast, not fast enough, ...). Some don't like Scheme (too academic, too small, does not scale, too functional, not functional enough, no modules, the wrong modules, not the right macros, ...).

Then somebody needs a Lisp combined with Objective-C, then you get Nu. Somebody hacks some Lisp for .net. Then you get some Lisp with concurrency and fresh ideas, then you have Clojure.

It's language evolution at work. It is like the cambrian explosion (when lots of new animals appeared). Some will die, others will live on, some new will appear. At some point in time some dialects appear that pick up the state of art (Scheme for everything with functional programming in Lisp in the 70s/80s and Common Lisp for everything MacLisp-like in the 80s) - that causes some dialects to disappear mostly (namely Standard Lisp, InterLisp, and others).

Common Lisp is the alligator of Lisp dialects. It is a very old design (hundred million years) with little changes, looks a little bit frightening, and from time to time it eats some young...

If you want to know more, The Evolution of Lisp (and the corresponding slides) is a very good start!



回答2:

I think it is because "Lisp" is such a broad description of a language. The only common thing between all the lisps that I know is most things are in brackets, and uses prefix function notation. Eg

(fun (+ 3 4))

However nearly everything else can vary between implementations. Scheme and CL are completely different languages, and should be considered like that.

I think calling the lisp community fragmented is like calling the "C like" community fragmented. It has c,c++,d,java,c#, go, javascript, python and many other languages which I can't think of.

In summary: Lisp is more of a language property (like garbage collection, static typing) than an actual language implementation, so it is completely normal that there are many languages that have the Lisp like property, just like many languages have garbage collection.



回答3:

I think it's because Lisp was born out of, and maintains the spirit of the hacker culture. The hacker culture is to to take something and make it "better" according to your belief in "better".

So when you have a bunch of opinionated hackers and a culture of modification, fragmentation happens. You get Scheme, Common Lisp, ELISP, Arc. These are all pretty different languages, but they're all "Lisp" at the same time.

Now why is the community fragmented? Well, I'll blame time and maturity on that. The language is 50 years old! :-)



回答4:

Scheme and Common Lisp are standardized. SBCL seems like the defacto open source lisp and there are plenty of examples out there on how to use it. It's fast and free. ClozureCL also looks pretty darn good.

PLT Scheme seems like the defacto open source scheme and there are plenty of examples out there how to use it. It's fast and free.

The CL HyperSpec seems as good as the JavaDoc to me.

As far as community fragmentation I think this has little to standards or resources. I think this has far more to do with what has been a relatively small community until recently.

Clojure I think has a good chance to become The Lisp for the new generation of coders.

Perhaps my point is a very popular implementation is all that is required to give the illusion of a cohesive community.



回答5:

LISP is not nearly as fragmented as BASIC.

There are so many dialects and versions of BASIC out there I have lost count.

Even the most commonly used implementation (MS VB) is different between versions.



回答6:

The fact that there are many implementations of Common LISP should be considered a good thing. In fact, given that there are roughly the same number of free implementations of Common LISP as there are free implementations of C++ is remarkable, considering the relative popularity of the languages.

Free Common LISP implementations include CMU CL, SBCL, OpenMCL / Clozure CL, CLISP, GCL and ECL.

Free C++ implementations include G++ (with Cygwin and MinGW32 variants), Digital Mars, Open Watcom, Borland C++ (legacy?) and CINT (interpreter). There are also various STL implementations for C++.

With regards to Scheme and Common LISP, although admittedly, an inaccurate analogy, there are times when I would consider Scheme is to Common LISP what C is to C++, i.e. while Scheme and C are small and elegant, Common LISP and C++ are large and (arguably) more suited for larger applications.



回答7:

Two possible contributing factors:

Lisp languages aren't hugely popular in comparison to other languages like C/C++/Ruby and so on - that alone may give the illusion of a fragmented community. There may be equal fragmentation in the other language-communities, but a larger community will have larger fragments..

Lisp languages are easier than most to implement. I've seen many, many "toy" Lisp implementations people have made for fun, many "proper" Lisp implementations to solve specific tasks. There are far more Lisp implementations than there are, say, Python interpreters (I'm aware of about.. 5, most of which are generally interchangeable)

There are promising projects like Clojure, which is a new language, with a clear goal (concurrency), without much "historical baggage", easy to install/setup, can piggyback on Java's library "ecosystem", has a good site with documentation/libraries, and has an official mailing list. This pretty much checks off every issue I encountered while trying to learn Common Lisp a while ago, and encourages a more centralised community.



回答8:

My point of view is that Lisp is a small language so it is easy to implement (compare to Java, C#, C, ...)



回答9:

Having many implementations is beneficial, because each implementation is optimal in unique places. And modern mainstream languages don't have one implementation anyway. Think about Python: its main implementation is CPython, but thanks to JPython you can run Python on the JVM too; thanks to Stackless Python you can have massive concurrency thanks to microthreads; etc. Such implementations will be encompatible in some ways: JPython integrates seamlessly with Java, whilst CPython doesn't. Same for Ruby.

What you don't want is having many implementations which are incompatible to the bone. That's the case with Scheme, where you can't share libraries among implementations without rewriting a lot of code, because Schemers can't agree on how to import/export libraries. Common Lisp libraries, OTOH, because of standardization in core areas, are more likely to be portable, and facilities exist to conditionally write code handling each implementation's peculiarities. Actually, nowadays you may say that Common Lisp is defined by its implementations (think about the ASDF package installation library), just like mainstream languages.