Warum ist die Lisp-Community so fragmentiert? [geschlossen]

Zunächst gibt es nicht nur zwei Hauptdialekte der Sprache (Common Lisp und Scheme), sondern jeder der Dialekte hat viele individuelle Implementierungen. Zum Beispiel Chicken Scheme, Bigloo usw. mit jeweils geringfügigen Unterschieden.

Aus heutiger Sicht ist dies seltsam, da Sprachen heutzutage dazu neigen, endgültige Implementierungen / Spezifikationen zu haben. Denken Sie an Java, C #, Python, Ruby usw., wo jede eine einzelne definitive Site hat, auf der Sie API-Dokumente, Downloads und dergleichen abrufen können. Natürlich ist Lisp älter als alle diese Sprachen. Andererseits ist sogar C / C ++ standardisiert (mehr oder weniger).

Ist die Fragmentierung dieser Gemeinschaft auf das Alter von Lisp zurückzuführen? Oder sollen unterschiedliche Implementierungen / Dialekte unterschiedliche Probleme lösen? Ich verstehe, dass es gute Gründe gibt, warum Lisp niemals so vereint sein wird wie Sprachen, die um eine einzige endgültige Implementierung herum gewachsen sind, aber gibt es an diesem Punkt einen guten Grund, warum sich die Lisp-Community nicht in diese Richtung bewegen sollte?

Die Lisp-Community ist fragmentiert, aber alles andere auch.

• Warum gibt es so viele Linux-Distributionen?

• Warum gibt es so viele BSD-Varianten? OpenBSD, NetBSD, FreeBSD, ... sogar Mac OS X.

• Warum gibt es so viele Skriptsprachen? Ruby, Python, Rebol, TCL, PHP und unzählige andere.

• Warum gibt es so viele Unix-Shells? sh, csh, bash, ksh, ...?

• Warum gibt es so viele Implementierungen von Logo (> 100), Basic (> 100), C (unzählige), ...

• Warum gibt es so viele Varianten von Ruby? Ruby MRI, JRuby, YARV, MacRuby, HotRuby?

• Python hat zwar eine Hauptwebsite, es gibt jedoch einige geringfügig unterschiedliche Implementierungen: CPython, IronPython, Jython, Python für S60, PyPy, Unladen Swallow, CL-Python, ...

• Warum gibt es C (Clang, GCC, MSVC, Turbo C, Watcom C, ...), C ++, C #, Cilk, Ziel-C, D, BCPL, ...?

Lassen Sie einfach einige von ihnen fünfzig werden und sehen Sie, wie viele Dialekte und Implementierungen es dann hat.

Ich denke, Lisp ist vielfältig, weil jede Sprache vielfältig ist oder vielfältig wird. Einige beginnen mit einer einzigen Implementierung (McCarthy's Lisp) und nach fünfzig Jahren haben Sie einen Zoo. Common Lisp begann sogar mit mehreren Implementierungen (für verschiedene Maschinentypen, Betriebssysteme, mit unterschiedlicher Compilertechnologie, ...).

Heutzutage ist Lisp eine Sprachfamilie , keine einzige Sprache. Es besteht nicht einmal Konsens darüber, welche Sprachen zu dieser Familie gehören oder nicht. Möglicherweise müssen einige Kriterien überprüft werden (S-Ausdrücke, Funktionen, Listen, ...), aber nicht jeder Lisp-Dialekt unterstützt alle diese Kriterien. Die Sprachdesigner haben mit verschiedenen Funktionen experimentiert und wir haben viele, mehr oder weniger Lisp-ähnliche Sprachen.

Wenn Sie sich Common Lisp ansehen, gibt es ungefähr drei oder vier verschiedene aktive kommerzielle Anbieter. Versuchen Sie, sie hinter ein Angebot zu bringen! Wird nicht funktionieren. Dann haben Sie eine Reihe aktiver Open-Source-Implementierungen mit unterschiedlichen Zielen: Eine wird in C kompiliert, eine andere ist in C geschrieben, eine versucht, einen schnell optimierenden Compiler zu haben, eine versucht, eine mittlere Grundlage für die native Kompilierung zu haben, eine zielt auf die JVM ... und so weiter. Versuchen Sie, die Betreuer anzuweisen, ihre Implementierungen fallen zu lassen!

Das Schema umfasst rund 100 Implementierungen. Viele sind tot oder meistens tot. Mindestens zehn bis zwanzig sind aktiv. Einige sind Hobbyprojekte. Einige sind Universitätsprojekte, andere Projekte von Unternehmen. Die Benutzer haben unterschiedliche Bedürfnisse . Man braucht einen Echtzeit-GC für ein Spiel, ein anderer muss in C eingebettet werden, man braucht nur Barebone-Konstrukte für Bildungszwecke und so weiter. Wie man den Entwicklern sagt, dass sie ihre Implementierung nicht hacken sollen.

Dann gibt es einige, die Commmon Lisp nicht mögen (zu groß, zu alt, nicht funktional genug, nicht objektorientiert genug, zu schnell, nicht schnell genug, ...). Einige mögen Scheme nicht (zu akademisch, zu klein, nicht skalierbar, zu funktional, nicht funktional genug, keine Module, die falschen Module, nicht die richtigen Makros, ...).

Dann braucht jemand ein Lisp in Kombination mit Objective-C, dann bekommt man Nu. Jemand hackt Lisp für .net. Dann bekommst du etwas Lisp mit Parallelität und frischen Ideen, dann hast du Clojure.

Es ist die Sprachentwicklung bei der Arbeit . Es ist wie bei der kambrischen Explosion (als viele neue Tiere auftauchten). Einige werden sterben, andere werden weiterleben, einige werden neu erscheinen. Irgendwann tauchen einige Dialekte auf, die den Stand der Technik wieder aufnehmen (Schema für alles mit funktionaler Programmierung in Lisp in den 70er / 80er Jahren und Common Lisp für alles, was in den 80er Jahren MacLisp-ähnlich ist) - was dazu führt, dass einige Dialekte größtenteils verschwinden ( nämlich Standard Lisp, InterLisp und andere).

Common Lisp ist der Alligator der Lisp-Dialekte. Es ist ein sehr altes Design (hundert Millionen Jahre) mit kleinen Veränderungen, sieht ein bisschen beängstigend aus und frisst von Zeit zu Zeit einige junge ...

Wenn Sie mehr wissen möchten, ist The Evolution of Lisp (und die entsprechenden Folien) ein sehr guter Anfang!

Ich denke, das liegt daran, dass "Lisp" eine so breite Beschreibung einer Sprache ist. Die einzige Gemeinsamkeit zwischen allen Lisps, die ich kenne, ist, dass die meisten Dinge in Klammern stehen und die Präfixfunktionsnotation verwenden. Z.B

(fun (+ 3 4))

Fast alles andere kann jedoch zwischen den Implementierungen variieren. Schema und CL sind völlig unterschiedliche Sprachen und sollten so betrachtet werden.

Ich denke, die fragmentierte Lisp-Community zu nennen, ist wie die fragmentierte C-ähnliche Community zu nennen. Es hat c, c ++, d, java, c #, go, javascript, python und viele andere Sprachen, an die ich nicht denken kann.

Zusammenfassend: Lisp ist eher eine Spracheigenschaft (wie Garbage Collection, statische Typisierung) als eine tatsächliche Sprachimplementierung. Daher ist es völlig normal, dass es viele Sprachen gibt, die die Lisp like-Eigenschaft haben, genau wie viele Sprachen Garbage Collection haben.

Ich denke, das liegt daran, dass Lisp geboren wurde und den Geist der Hacker-Kultur bewahrt. Die Hacker-Kultur besteht darin, etwas zu nehmen und es "besser" zu machen, entsprechend Ihrem Glauben an "besser".

Wenn Sie also eine Reihe von Hackern mit einer Meinung und einer Kultur der Modifikation haben, kommt es zu einer Fragmentierung. Sie erhalten Schema , Common Lisp , ELISP , Arc . Dies sind alles ziemlich unterschiedliche Sprachen, aber sie sind alle gleichzeitig "Lisp".

Warum ist die Community nun fragmentiert? Nun, ich werde Zeit und Reife dafür verantwortlich machen. Die Sprache ist 50 Jahre alt! :-)

Schema und Common Lisp sind standardisiert. SBCL scheint das defacto Open Source Lisp zu sein, und es gibt viele Beispiele für die Verwendung. Es ist schnell und kostenlos. ClozureCL sieht auch verdammt gut aus.

Das PLT-Schema scheint das defacto-Open-Source-Schema zu sein, und es gibt viele Beispiele für dessen Verwendung. Es ist schnell und kostenlos.

Der CL HyperSpec scheint mir so gut wie der JavaDoc zu sein.

Was die Fragmentierung der Community angeht, hat dies meiner Meinung nach wenig mit Standards oder Ressourcen zu tun. Ich denke, das hat viel mehr mit einer bis vor kurzem relativ kleinen Gemeinde zu tun.

Ich denke, Clojure hat gute Chancen, The Lisp für die neue Generation von Programmierern zu werden.

Vielleicht ist mein Punkt, dass eine sehr beliebte Implementierung alles ist, was erforderlich ist, um die Illusion einer zusammenhängenden Gemeinschaft zu vermitteln.

LISP ist bei weitem nicht so fragmentiert wie BASIC.

Es gibt so viele Dialekte und Versionen von BASIC, dass ich die Zählung verloren habe.

Selbst die am häufigsten verwendete Implementierung (MS VB) unterscheidet sich zwischen den Versionen.

Die Tatsache, dass es viele Implementierungen von Common LISP gibt, sollte als eine gute Sache angesehen werden. Angesichts der relativen Beliebtheit der Sprachen ist es bemerkenswert, dass es ungefähr die gleiche Anzahl kostenloser Implementierungen von Common LISP gibt wie kostenlose Implementierungen von C ++.

Zu den kostenlosen allgemeinen LISP-Implementierungen gehören CMU CL, SBCL, OpenMCL / Clozure CL, CLISP, GCL und ECL.

Zu den kostenlosen C ++ - Implementierungen gehören G ++ (mit Cygwin- und MinGW32-Varianten), Digital Mars, Open Watcom, Borland C ++ (Legacy?) Und CINT (Interpreter). Es gibt auch verschiedene STL-Implementierungen für C ++.

In Bezug auf Schema und Common LISP, obwohl zugegebenermaßen eine ungenaue Analogie, gibt es Zeiten, in denen ich Schema für Common LISP als C für C ++ betrachten würde, dh während Schema und C klein und elegant sind, sind Common LISP und C ++ groß und (wohl) eher für größere Anwendungen geeignet.

Zwei mögliche Faktoren:

Lisp-Sprachen sind im Vergleich zu anderen Sprachen wie C / C ++ / Ruby usw. nicht sehr beliebt - das allein kann die Illusion einer fragmentierten Community hervorrufen. Es mag eine gleiche Fragmentierung in den anderen Sprachgemeinschaften geben, aber eine größere Gemeinschaft wird größere Fragmente haben.

Lisp-Sprachen sind einfacher zu implementieren als die meisten anderen. Ich habe viele, viele "Spielzeug" -Lisp-Implementierungen gesehen, die Leute zum Spaß gemacht haben, viele "richtige" Lisp-Implementierungen, um bestimmte Aufgaben zu lösen. Es gibt weit mehr Lisp-Implementierungen als beispielsweise Python-Interpreter (mir sind ungefähr 5 bekannt, von denen die meisten im Allgemeinen austauschbar sind).

Es gibt vielversprechende Projekte wie Clojure, eine neue Sprache mit einem klaren Ziel (Parallelität), ohne viel "historisches Gepäck", einfach zu installieren / einzurichten, kann auf Javas Bibliothek "Ökosystem" huckepack nehmen, hat eine gute Seite mit Dokumentation / Bibliotheken und hat eine offizielle Mailingliste. Dies überprüft so ziemlich jedes Problem, auf das ich vor einiger Zeit gestoßen bin, als ich versucht habe, Common Lisp zu lernen, und ermutigt eine zentralere Community.

Viele Implementierungen sind von Vorteil, da jede Implementierung an eindeutigen Stellen optimal ist. Und moderne Mainstream-Sprachen haben sowieso keine einzige Implementierung. Denken Sie an Python: Die Hauptimplementierung ist CPython, aber dank JPython können Sie Python auch auf der JVM ausführen. Dank Stackless Python können Sie dank Mikrothreads eine massive Parallelität erzielen. usw. Solche Implementierungen sind in gewisser Weise kompatibel: JPython lässt sich nahtlos in Java integrieren, CPython hingegen nicht. Gleiches gilt für Ruby.

Was Sie nicht wollen, sind viele Implementierungen, die mit dem Knochen nicht kompatibel sind. Dies ist bei Scheme der Fall, bei dem Sie Bibliotheken nicht für Implementierungen freigeben können, ohne viel Code neu zu schreiben, da Schemers sich nicht darauf einigen können, wie Bibliotheken importiert / exportiert werden sollen. Aufgrund der Standardisierung in Kernbereichen sind OTOH-Bibliotheken (Common Lisp Libraries) eher portabel, und es gibt Einrichtungen zum bedingten Schreiben von Code, der die Besonderheiten jeder Implementierung behandelt. Tatsächlich kann man heutzutage sagen, dass Common Lisp durch seine Implementierungen definiert wird (denken Sie an die ASDF-Paketinstallationsbibliothek), genau wie die gängigen Sprachen.

Mein Standpunkt ist, dass Lisp eine kleine Sprache ist und daher einfach zu implementieren ist (vergleiche mit Java, C #, C, ...).

Hinweis: Da viele kommentieren, dass es in der Tat nicht so klein ist, verfehlt es meinen Standpunkt. Lassen Sie mich versuchen, genauer zu sein: Dieser Boll bis zum Einstiegspreis. Das Erstellen einer VM, die einige bekannte Mainstream-Sprachen kompiliert, ist im Vergleich zum Erstellen einer VM, die sich mit LISP befasst, ziemlich schwierig. Dies würde es dann einfach machen, eine kleine Community um ein kleines Projekt herum aufzubauen. Jetzt können die Bibliothek und die Spezifikation vollständig implementiert sein oder nicht, aber das Wertversprechen ist immer noch da. Schließen Sie es ein typisches Beispiel, wo der R5RS sicherlich nicht im Umfang ist.