Почему сообщество Lisp настолько фрагментировано?

Ответ 1

Сообщество Lisp фрагментировано, но все остальное тоже.

• Почему так много дистрибутивов Linux?

• Почему так много вариантов BSD? OpenBSD, NetBSD, FreeBSD,... даже Mac OS X.

• Почему так много языков сценариев? Ruby, Python, Rebol, TCL, PHP и многие другие.

• Почему так много оболочек Unix? sh, csh, bash, ksh,...?

• Почему существует так много реализаций логотипа ( > 100), Basic ( > 100), C (бесчисленное количество),...

• Почему так много вариантов Ruby? Ruby MRI, JRuby, YARV, MacRuby, HotRuby?

• Python может иметь основной сайт, но есть несколько немного разных реализаций: CPython, IronPython, Jython, Python для S60, PyPy, Unladen Swallow, CL-Python,...

• Почему существуют C (Clang, GCC, MSVC, Turbo C, Watcom C,...), С++, С#, Cilk, Objective-C, D, BCPL,...?

Просто позвольте некоторым из них получить пятьдесят и посмотреть, сколько там диалектов и реализаций.

Я предполагаю, что Lisp разнообразен, потому что каждый язык разнообразен или становится разнообразным. Некоторые начинают с одной реализации (McCarthy Lisp), и через пятьдесят лет вы получили зоопарк. Общий Lisp даже начался с нескольких реализаций (для разных типов машин, операционных систем, с другой технологией компилятора,...).

В настоящее время Lisp - это семейство языков, а не один язык. Нет даже консенсуса относительно того, какие языки принадлежат этой семье или нет. Могут быть некоторые критерии для проверки (s-выражения, функции, списки,...), но не каждый диалект Lisp поддерживает все эти критерии. Разработчики языка экспериментировали с различными функциями, и у нас было много, более или менее, Lisp -подобных языков.

Если вы посмотрите на Common Lisp, существует около трех или четырех разных активных коммерческих поставщиков. Попытайтесь получить их за одно предложение! Не получится. Затем у вас есть куча активных реализаций с открытым исходным кодом с разными целями: один компилируется на C, другой написан на C, один пытается получить быстрый оптимизирующий компилятор, один пытается получить некоторую среду с родной компиляцией, таргетинг на JVM... и так далее. Попробуйте сказать разработчикам отказаться от их реализации!

Схема имеет около 100 реализаций. Многие мертвы или в основном мертвы. Действуют не менее десяти-двадцати. Некоторые из них - хобби. Некоторые из них - университетские проекты, некоторые - проекты компаний. пользователи имеют разнообразные потребности. Для игры нужна GC в реальном времени, другая нужна встраивание в C, нужны только бобовые конструкции для образовательных целей и т.д. Как сказать разработчикам не взламывать их реализацию.

Затем есть некоторые, кому не нравится Commmon Lisp (слишком большой, слишком старый, недостаточно функциональный, а не слишком ориентированный на объект, слишком быстрый, не достаточно быстрый,...). Некоторые не любят Scheme (слишком академичные, слишком маленькие, не масштабируются, слишком функциональны, недостаточно функциональны, не модули, неправильные модули, а не правильные макросы,...).

Затем кому-то нужен Lisp в сочетании с Objective-C, тогда вы получите Nu. Кто-то взломал Lisp для .net. Затем вы получаете Lisp с concurrency и свежие идеи, тогда у вас есть Clojure.

Это эволюция языка на работе. Это похоже на взрыв кембрия (когда появилось много новых животных). Некоторые умрут, другие будут жить, появятся новые. В какой-то момент появляются некоторые диалекты, которые поднимают состояние искусства (схема для всего, что работает с функциональным программированием в Lisp в 70-х/80-х годах и Common Lisp для всех MacLisp-подобных в 80-х годах) - это вызывает некоторые диалекты (а именно Standard Lisp, InterLisp и т.д.).

Общий Lisp - аллигатор диалектов Lisp. Это очень старый дизайн (сто миллионов лет) с небольшими изменениями, выглядит немного пугающим, и время от времени он ест молодых...

Если вы хотите узнать больше, Эволюция Lisp (и соответствующие слайды - это очень хорошее начало!

Ответ 2

Я думаю, это потому, что "Lisp" - это такое широкое описание языка. Единственное, что я вижу среди всех lisp, которые я знаю, - это в скобках и использует префиксную функцию. Например,

(fun (+ 3 4))

Однако почти все остальное может различаться между реализациями. Схема и CL - это совершенно разные языки, и их следует рассматривать таким образом.

Я думаю, что вызов сообщества lisp, фрагментированного, похоже на фрагментацию сообщества "C like". Он имеет c, С++, d, java, С#, go, javascript, python и многие другие языки, о которых я не могу думать.

Вкратце: lisp больше относится к языковому свойству (например, сборку мусора, статическая типизация), чем к реальной реализации языка, поэтому вполне нормально, что существует много языков, имеющих свойство lisp, как и многие языки имеют сбор мусора.

Ответ 3

Я думаю, потому что Lisp родился и поддерживает дух хакерской культуры. Хакерская культура должна взять что-то и сделать ее "лучше" в соответствии с вашей верой в "лучшее".

Итак, когда у вас есть куча самоуверенных хакеров и культура модификации, происходит фрагментация. Вы получаете Scheme, Общий Lisp, ELISP, Arc. Все это разные языки, но все они "Lisp" одновременно.

Теперь почему сообщество фрагментировано? Хорошо, я буду обвинять в этом время и зрелость. Языку исполнилось 50 лет!: -)

Ответ 4

Схема и общий Lisp стандартизированы. SBCL кажется открытым исходным кодом defacto Lisp, и есть много примеров того, как его использовать. Это быстро и бесплатно. ClozureCL также выглядит довольно чертовски хорошо.

Схема PLT выглядит как схема с открытым исходным кодом defacto, и есть много примеров того, как ее использовать. Это быстро и бесплатно.

CL HyperSpec выглядит так же хорошо, как JavaDoc для меня.

Что касается фрагментации сообщества, я думаю, что это мало что касается стандартов или ресурсов. Я думаю, что это гораздо больше связано с тем, что было относительно небольшим сообществом до недавнего времени.

Clojure Я думаю, у меня есть хороший шанс стать Lisp для нового поколения кодеров.

Возможно, моя точка зрения - очень популярная реализация - это все, что требуется для иллюзии сплоченного сообщества.

Ответ 5

LISP не так фрагментирован, как BASIC.

Есть так много диалектов и версий BASIC, там я потерял счет.

Даже наиболее часто используемая реализация (MS VB) отличается от версий.

Ответ 6

Тот факт, что существует много реализаций Common LISP, следует считать хорошей. На самом деле, учитывая, что существует примерно одинаковое количество бесплатных реализаций Common LISP, поскольку существуют свободные реализации С++, замечательно, учитывая относительную популярность языков.

Свободные общие реализации LISP включают в себя CMU CL, SBCL, OpenMCL/Clozure CL, CLISP, GCL и ECL.

Свободные реализации С++ включают g++ (с вариантами Cygwin и MinGW32), Digital Mars, Open Watcom, Borland С++ (наследие?) и CINT (интерпретатор). Существуют также различные реализации STL для С++.

Что касается схемы и общей LISP, хотя, по общему признанию, неточной аналогии, бывают случаи, когда я рассматриваю Схему как Common LISP, что C является С++, т.е. в то время как Scheme и C являются маленькими и элегантными, Общие LISP и С++ большие и (возможно) более подходят для более крупных приложений.

Ответ 7

Два возможных фактора:

Lisp не очень популярны по сравнению с другими языками, такими как C/С++/Ruby и т.д. - это само по себе может дать иллюзию фрагментированного сообщества. В других языковых сообществах может быть одинаковая фрагментация, но у более крупного сообщества будут большие фрагменты.

Lisp легче, чем большинство из них. Я видел много, много "игрушечных" реализаций Lisp, которые люди сделали для удовольствия, множество "правильных" Lisp реализаций для решения конкретных задач. Существует гораздо больше реализаций Lisp, чем, например, интерпретаторы Python (я знаю о.. 5, большинство из которых, как правило, взаимозаменяемы)

Есть многообещающие проекты, такие как Clojure, который является новым языком с четкой целью (concurrency), без значительного "исторического багажа", простой в установке/настройке, может комбинировать библиотеку Java "экосистема", имеет хороший сайт с документацией/библиотеками и имеет официальный список рассылки. Это в значительной степени проверяет каждую проблему, с которой я столкнулся при попытке изучить Common Lisp некоторое время назад, и поощряет более централизованное сообщество.

Ответ 8

Моя точка зрения заключается в том, что Lisp - это небольшой язык, поэтому его легко реализовать (сравните с Java, С#, C,...)

Ответ 9

Наличие многих реализаций выгодно, потому что каждая реализация является оптимальной в уникальных местах. И современные современные языки вообще не имеют одной реализации. Подумайте о Python: его основная реализация - CPython, но благодаря JPython вы также можете запускать Python на JVM; благодаря Stackless Python у вас может быть массивный concurrency благодаря микропотокам; и т.д. Такие реализации будут в некотором роде совместимы: JPython легко интегрируется с Java, в то время как CPython этого не делает. То же самое для Ruby.

То, что вы не хотите, - это много реализаций, которые несовместимы с костью. Это случай с Scheme, где вы не можете делиться библиотеками между реализациями, не переписывая много кода, потому что Schemers не могут договориться о том, как импортировать/экспортировать библиотеки. Общие библиотеки Lisp, OTOH, из-за стандартизации в основных областях, скорее всего, будут переносимыми, и существуют средства условной записи кода, обрабатывающего каждую особенность реализации. На самом деле, в настоящее время вы можете сказать, что Common Lisp определяется его реализациями (подумайте об установке библиотеки пакетов ASDF), так же, как и обычные языки.