Clojure против других Lisps

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

Я прочитал несколько книг по Clojure (Программирование Clojure, Практический Clojure, Радость Clojure и версия Manning Early Access Clojure в действии), и я думаю, что это фантастический язык. В настоящее время я читаю Let Over Lambda, который в основном имеет дело с Common Lisp макросами, и это тоже очень интересный язык.

Я не эксперт Lisp (новичок), но это семейство языков очаровывает меня, как и функциональное программирование вообще.

Преимущества Clojure (и недостатки "других" ):

  • Работает на JVM.

    • JVM - это очень стабильная, высокопроизводительная языковая среда, которая хорошо сочетается с мечтой Sun: "Напишите один раз, запустите [почти] в любом месте". Я могу написать код на моем Macbook Pro, скомпилировать его в исполняемый файл JAR, а затем запустить его в Linux и Microsoft Windows с небольшим дополнительным тестированием.

    • JVM (Hotspot и др.) поддерживает высококачественную сборку мусора и очень эффективную компиляцию и оптимизацию точно в срок. Где всего несколько лет назад я написал все, что нужно было быстро запускать на C, теперь я не стесняюсь делать это на Java.

    • Стандартная, простая, многопотоковая модель. Имеет ли Common Lisp стандартный многопоточный пакет?

    • Прерывает монотонность всех этих круглых скобок с [], {} и #{}, хотя эксперты Common Lisp, вероятно, скажут мне, что с помощью макросов-читателей вы можете добавить их в CL.

Недостатки Clojure:

  • Работает на JVM.
    • Нет рекурсии хвоста или продолжения. Поддерживает ли Common Lisp продолжение продолжения? Я считаю, что схема требует поддержки для обоих.

Преимущества других (общий Lisp, в частности) (и недостатки Clojure):

  • Определяемые пользователем макросы читателей.

  • Другие преимущества?

Мысли? Другие отличия?

Ответы

Ответ 1

Мой личный список причин для предпочтения Clojure другим Lisps (p.s. Я все еще думаю, что все Lisps великолепны!):

  • Работает на JVM - следовательно, получает автоматический доступ к фантастической инженерии в самой JVM (расширенные алгоритмы сбора мусора, оптимизация JS HotSpot и т.д.).

  • Очень хорошая совместимость с Java - обеспечивает совместимость с огромным набором библиотек в языковой экосистеме Java/JVM. Я использовал Clojure в качестве "клеящего" языка для подключения различных библиотек Java с хорошим эффектом. Поскольку я также разрабатываю много кода Java, для меня полезно, что Clojure хорошо интегрируется с инструментами Java (например, я использую Maven, Eclipse с плагином против часовой стрелки для разработки Clojure)

  • Хороший синтаксис для векторов [1 2 3], отображает {:bob 10, :jane 15} и устанавливает #{"a" "b" "c"} - Я рассматриваю эти довольно важные инструменты для современного программирования (в дополнение к спискам, конечно!)

  • Мне лично нравится использование квадратных скобок для связывания форм: например, (defn foo [a b] (+ a b)) - Я думаю, что он делает код более понятным для чтения.

  • Акцент на ленивом, функциональном программировании с постоянными неизменными структурами данных - в частности, вся основная библиотека Clojure предназначена для поддержки этого по умолчанию

  • Отличная реализация STM для многоядерных concurrency. Я полагаю, что Clojure имеет лучшую историю concurrency любого языка на данный момент (см. Этот видео для большей разработки самим Ричем Хики)

  • Это a Lisp -1 (например, Scheme), который я лично предпочитаю (я думаю, что на функциональном языке имеет смысл хранить функции и данные в одном и том же пространстве имен)

Ответ 2

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

Общий Lisp определенно поддерживает функциональное программирование, но также позволяет изменять состояние и императивное программирование.

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

Ответ 3

Имейте в виду, что Clojure - это язык и реализация (обычно на JVM). Common Lisp - это язык с более чем десяти различными реализациями. Итак, у нас есть несоответствие категории прямо здесь. Например, вы можете сравнить Clojure с SBCL.

В общем:

  • версия Common Lisp работает на JVM: ABCL

  • большинство других Common Lisp реализация не

  • большинство реализаций CL имеют возможности многозадачности, библиотека предоставляет общий интерфейс

  • Общий Lisp имеет синтаксис для массивов. Синтаксис для других типов данных может быть написан пользователем и предоставлен различными библиотеками.

  • Общие Lisp не поддерживают ни оптимизацию хвостовых вызовов, ни продолжения. Реализации обеспечивают TCO и библиотеки, которые предоставляют некоторые формы продолжений.

Ответ 4

Здесь хорошее видео с сравнение схемы (в основном, Racket) и Clojure.

Чтобы быть справедливым, Racket имеет синтаксический сахар (дополнительный материал для чтения) для типов данных тоже (#hash, #, квадратные скобки и т.д.)

Плюс, Clojure единственный способ сделать правильный хвостовой вызов - использовать recur, это недостаток компиляции в JVM.

Обратите внимание, что recur является единственной конструкцией цикла без использования стека в Clojure. Нет хвоста оптимизация и использование самозапуска для циклирования неизвестных границ не рекомендуется. recurи его использование в хвостовом положении проверяется компилятором. (Специальные формы).