Зачем использовать Clojure поверх других шепелявых JVM:Кава, Вооруженный Медведь или СИСС?

StackOverflow https://stackoverflow.com/questions/1413390

  •  06-07-2019
  •  | 
  •  

Вопрос

У JVM уже было три шепелявости, прежде чем Clojure появился на сцене: Кава, Вооруженный Медведь и СИСС.

Что делает gap Clojure ( Клоджур ) заполнить то, что осталось от этих Шепелявых?

Это было полезно?

Решение

Kawa, ABCL и SISC - это повторные реализации существующих языков, которые довольно длинные в зубе. Они отлично подходят, если по какой-то причине вы хотите использовать стандартную схему или стандартный Common Lisp в JVM.

Clojure - это новый язык. Он не заполняет пробел . Это добавляет совершенно новые возможности. Это благоприятствует чисто функциональному подходу - Scheme и CL являются мультипарадигмами. Clojure сильно заимствует из дизайна различных языков FP (ML, Haskell).

И да, вы можете добавить поддержку параллелизма к другим Лиспам, но это полностью упускает смысл. Clojure изначально разрабатывался как параллельный язык. Настолько, что написание параллельных программ тривиально в Clojure, а не в ракетостроении, как на нефункциональных языках (Scheme, CL, не исключая). Посмотрите на это так:

Люди говорят, что C позволяет писать быстрые программы по умолчанию.

Ну, Clojure позволяет вам писать параллельные программы по умолчанию.

Другие советы

<Ол>
  • " Clojure - это Лисп, не ограниченный обратной совместимостью " (это с сайта Clojure). Это новое начало. Это прогресс. Используйте идеи, которые делают Lisp / Scheme мощным, но переосмыслите их на платформе Java .

  • Clojure всегда будет самым последним Clojure. С любым другим языком, портированным на JVM, версия JVM всегда может играть в догонялки. Если вам не нужна платформа Java, зачем использовать SISC поверх другой схемы? Если да, то почему бы не использовать тот Лисп (Clojure), который был разработан специально для него?

  • Разработано с учетом параллелизма.

  • Самый простой ответ, который я могу придумать: Clojure - это не Common-Lisp. Clojure не ограничен историей других Lisps. Это новый язык встроенный для JVM.

    Я просто не знал об этом, что является серьезным преимуществом для Clojure (я узнал, что люди производят достаточно шума). Самое большое, что есть у Clojure, чего я не видел в перечисленных вами списках, это Транзакционная память программного обеспечения .

    Clojure также был разработан для JVM, в отличие от того, чтобы быть слоем для другого языка, так что это немного больше "Java-y" что я думаю, что другие будут, когда вы должны сделать взаимодействие.

    Страница с обоснованием clojure.org гласит:

    Почему я написал еще один язык программирования?В основном потому, что я хотел:

    • Шепелявый
    • для Функционального программирования
    • симбиоз с устоявшейся платформой
    • предназначен для параллелизма

    и не смог найти ни одного.

    Соответствуют ли упомянутые вами 3 языка (Kawa, ABCL и SISC) этим требованиям?Они такие:

    • Шепелявит (либо диалекты CL, либо Scheme) ✓
    • для Функционального программирования ✓
    • симбиоз с устоявшейся платформой (JVM) ✓

    но это не так разработанный для параллелизма (STM);однако, чтобы быть справедливым и полным, есть по крайней мере 2 библиотеки STM, которые я нашел для CL, которые еще не были упомянуты:

    1. STMX
      • Протестировано на ABCL.Находится в активной разработке.
    2. CL-STM
      • Мертв?Последнее изменение произошло в 2007 году.

    Хм...Так зачем же создавать новый Lisp?Главным образом потому, что это библиотеки.Страница с обоснованием clojure.org продолжается (выделено мной):

    А как насчет стандартных лиспов (Common Lisp и Scheme)?

    • Медленное внедрение инноваций / отсутствие инноваций после стандартизации
    • Основные структуры данных изменчивы, а не расширяемы
    • Отсутствие параллелизма в спецификациях
    • Хорошие реализации уже существуют для JVM (ABCL, Kawa, SISC и др.)
    • Стандартные лиспы - это их собственные платформы

    Это разработка языкового параллелизма проблема, как уже упоминали другие.

    Кроме того, зачем останавливаться на JVM? Поддержка Clojure CLR находится в стадии активной разработки.

    Это 2 пробела, которые он заполняет, с моей точки зрения.Вам следует использовать Clojure, если это соответствует вашим потребностям.Не беспокойтесь о потере своих навыков, если Clojure исчезнет с карты.Ваши навыки владения лиспом, но, что более важно, ваш образ мышления, будут перенесены на другие диалекты лиспа.

    Если бы я был циничным, я бы сказал, что у Clojure есть более приятный веб-сайт и более сексуальное имя.

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

    Я подозреваю, что разработчики Kawa и т. д. не так уж сильно поставлены на карту, поэтому не рекламируют свой продукт. Кроме того, что тут шумиха? " У нас отличный язык ... он называется Lisp " Это сложнее продать маркетинг.

    Я думаю, что Java является ярким примером этого. У него были некоторые очень серьезные недостатки, но поскольку он продавался и активно рекламировался, он набрал значительную динамику, что означало поддержку со стороны поставщиков аппаратного и программного обеспечения, производителей инструментов, инвестиции по отраслям и т. Д. В любом случае, он достиг определенной степени успех, хотя я ненавидел программирование в нем. Clojure может достичь такого же успеха, что и другие Лиспы.

    Преимущество Clojure состоит в том, что он дает вам доступ ко всем библиотекам / коду java и многопоточности, поскольку он основан на JVM. Кроме того, он был разработан с учетом параллелизма, что обычно не предназначено для lisp, хотя из-за отображающих примитивов, вероятно, не составит труда разработать lisp, который бы хорошо поддерживал параллелизм.

    Тем не менее, я попробовал Clojure и ненавидел синтаксис и боль в заднем факторе, который, кажется, сочетается с чем-либо связанным с Java.

    Clojure - это "шутка", это не какой-то шумиха, который вы уже знаете. Я провел последний пару дней читаю материал и просматриваю ролики, и я впечатлен. это предпосылка заключается в том, что функциональные программы (основанные на неизменных данных) являются лучшим способом управлять параллелизмом. Clojure реализует систему, похожую на lisp, на основе JVM, чтобы обеспечить ее.

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

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

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

    Я люблю Схему. Это красивый, элегантный язык. Тем не менее, его развитие зависит от комитетов, и, возможно, это иногда замедляло его. В любом случае его цели отличаются от целей Clojure.

    Common Lisp и Scheme имеют такие акценты, как хвостовая рекурсия, которые плохо подходят для эффективности в JVM. Clojure был спроектирован с самого начала, чтобы хорошо отображаться на JVM и хорошо взаимодействовать с Java. (Я не уверен, что это означает в диалектах Clojurescript и CLR.)

    Тот факт, что Clojure был первоначально разработан одним человеком, Ричем Хики, и контролируется им вместе с небольшой командой, не обязательно делает его лучше, чем язык, контролируемый комитетами. Если этот человек принимает плохие решения, Clojure не будет хорошим языком.

    Тем не менее, и это важный момент : Хикки разработал хорошо продуманный, элегантный язык, который с самого начала включал в себя систематически связанный набор функций, облегчающих выполнение много с небольшим. Это касается как базового взаимодействия с JVM, так и остального языка. Люди, которые контролируют Clojure, до сих пор строго придерживаются целей языка.

    Это большая часть того, что мне нравится в Clojure: он хорошо продуман как в целом, так и в деталях. Это означает, что как только вы к этому привыкнете, программировать на нем одно удовольствие.

    Было бы лишь немного преувеличением (или занижением?) сказать, что Clojure обладает силой Common Lisp с элегантностью Схемы. Common Lisp имеет много и много того, что вам нужно встроить в язык, но это беспорядок (я говорю это с любовью), и когда вам нужно что-то большее, чем то, что есть в языке, иногда есть несколько несовместимых библиотек с различными компромиссами. Схема по дизайну невелика, хотя есть библиотеки доступные. Clojure имеет растущий объем стандартных библиотек (в отличие от CL), которые являются более или менее частями языка. Хорошей иллюстрацией этого является проект core.matrix, который предоставляет общий интерфейс для нескольких различных реализаций матрицы. Это важно, потому что существуют разные реализации матриц, которые лучше всего подходят для случайного использования небольших матриц или, например, для широкого использования огромных матриц.

    Ничто из этого не означает, что Clojure лучше Common Lisp или Scheme; это не. Три языка имеют разные достоинства.

    Это новое! Это означает, что не многие старые lispers будут использовать его, поскольку традиционное сообщество lisp хорошо, традиционно, но это также означает, что люди без предыдущего опыта lisp подберут его как новое.

    Имхо, Clojure для старых Лиспов такой же, как Руби для Smalltalk. Не обязательно лучше, но достаточно хорошо. И что наиболее важно, это более приемлемо для вашего работодателя, потому что оно имеет импульс и рассматривается как растущий язык, так же, как когда-то был Руби.

    Лицензировано под: CC-BY-SA с атрибуция
    Не связан с StackOverflow
    scroll top