В каких случаях лучше использовать Clojure?

Ответ 1

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

Другим большим плюсом Clojure является его очень полированная поддержка concurrency, имеющая около 3 различных вкусов. Если у вас есть вычислительная, параллелизуемая задача, Clojure может упростить задачу. Ну, проще.

Обновление: еще один аргумент. Clojure довольно функциональный, поэтому он плюс, если вы хотите заставить себя думать и писать функционально.

Ответ 2

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

Для меня синтаксис и имена функций в Clojure эстетически приятны. Некоторые библиотеки Java неоценимы для того, что я делаю для сбора данных, а также для веб-программирования и графического интерфейса. Функциональное программирование является сложным и приятным. Clojure недостатки неважны и перевешивают его преимуществами в моих глазах. Определенные недопустимые недостатки в других Lisps "фиксированы" в Clojure, потому что они новы, и они могут игнорировать обратную совместимость. Он имеет новый и, возможно, мощный подход к concurrency. Сообщество Clojure является ярким и приветливым и удивительным. Все это говорит обо мне и о том, что я ценю, как о Clojure или других Lisps.

Существуют библиотеки для CL и Scheme, которые не существуют в Clojure или Java. Есть люди, которым не нравится, как Clojure использует слишком большой синтаксис, например [] и {}, и хочет использовать парсеры повсюду. Если вы хотите ООП в стиле CLOS или множество изменяемых структур данных, другой Lisp, возможно, лучше. JVM - тяжеловесный, может быть, слишком тяжелый и слишком большой багаж для некоторых людей. Многие Java утечки в Clojure (по дизайну), и это оскорбляет некоторые чувства людей. У STM и неизменяемых структур данных есть накладные расходы, которые делают определенные вещи (например, числовые хруст) более медленными или менее элегантными. Clojure является новым и все еще грубым в определенных областях, все еще быстро меняющимся и развивающимся в других. Clojure должен пройти тест времени, тогда как другие Lisps уже есть. Clojure не является "стандартным", и некоторые люди считают, что язык, определенный реализацией, неприемлем. И так далее. Ничто из этого не имеет значения для меня, но они могут вам.

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

В принципе, все, что заставляет вас чувствовать себя теплым и нечетким. Изучите их все, а затем сделайте осознанный выбор на основе ваших собственных вкусов и используйте то, что вам больше всего нравится. Они все хороши.

Ответ 3

Когда? Как можно больше. Зачем? Неизменяемые структуры данных - они действительно так хороши. Существует много других причин.

Ответ 4

Clojure следует использовать, когда

• вам нужно работать с существующим Java-кодом.
• вы работаете с людьми, страдающими аллергией на lisp ( "босс, я бы хотел использовать библиотеку java concurrency, называемую clojue vs. Мне хотелось бы переписать это в схеме" [1]
• вы будете программировать для многопроцессорной системы.

Схема лучше, если:

• вам нужно доказать, что ваш код верен. Clojures (вызов java) препятствует, но не мешает этому.
• вы работаете с людьми, страдающими аллергией на java.
• Вы разрабатываете платформу, в которой нет (достаточно новых) JVM

[1] да, это плохая плохая причина. таков мир, в котором мы живем...

Ответ 5

ABCL (Armed Bear Common Lisp), а также несколько реализаций Схемы (KAWA, SISC,...) также работают JVM.

Обычно общий Lisp доступен в разных "ароматах" - ABCL является одним из них. Другие компиляции с C, на собственный код, имеют обширные среды разработки или специализированные расширения, такие как логические языки или базы данных.

Clojure OTOH - это новый диалект Lisp с акцентом на ленивое функциональное программирование и параллельное программирование. Его автор (Rich Hickey) - очень опытный разработчик программного обеспечения (он также написал Java и .net-интерфейсы для Common Lisp) и отлично справился с Clojure. Несмотря на некоторую шумиху вокруг языка, стоит проверить - это, безусловно, один из лучших диалектов Lisp, разработанных в последние годы (по сравнению с Newlisp или Arc).

Ответ 6

Есть много причин, о которых говорилось выше. Мой прием:

• Существующие библиотеки. Это такая польза. Я просто не могу похвалить эту функцию.
• Язык более приспособлен к доступное оборудование (многоядерные) и разработки парадигмы, используемые сегодня. Гораздо проще рассуждать о concurrency. Функциональные аспекты также приятнее. Конечно, вы можете выполнять функциональное программирование в Lisp, но очень легко нарушить парадигму неосознанно, невольно и непреднамеренно.
• Кросс-платформа. Я запускаю одинаковые программ в Linux, Windows и Макинтош Есть много родных Lisp которые работают на разных платформах, но поддержка всех функций на всех платформы немного пятнистые, и вы постоянно должны быть начеку для вещей, которые отсутствуют на одном платформу или другую. Аналогичным образом, библиотеки, которые вам нужны, не всегда последовательно поддерживается платформ. ABCL и некоторые из В реализациях JVM Scheme это а также поддержку, но я по-прежнему предпочитают Clojure из-за пункт 2.
• Характер языка сообщества. Давай посмотрим правде в глаза, много время общего сообщества Lisp просто противно бороться. То есть не в случае с Clojure. Легко получить полезную помощь без снисходительность и подлость, которые часто приходит ответ от Общее сообщество Lisp. Поскольку у меня есть узнал для себя несколько раз, нет сомнений, настолько глупо, что вы не получите вежливый и полезный ответ от сообщества Clojure.

Если бы мне пришлось найти одно, на что жаловаться, это была бы поддержка IDE. Может быть, это вопрос изучения новых привычек, но мне все же легче справиться с механикой разработки Java, чем Clojure. Я пробовал и использовал Clojure Box, enclojure на NetBeas, La Clojure на Intellij IDEA и против часовой стрелки на Eclipse. Все они отлично работают, если вы работаете в основном из REPL, но для компиляции и выполнения файлов классов все они все еще немного неуклюжи.

Ответ 7

Подмножество Clojure также может компилироваться в javascript

Ответ 8

Clojure работает на JVM (и на CLR), поэтому есть.

Ответ 9

Clojure дизайн связан с безопасным размещением нескольких стилей параллельного программирования, преднамеренно затрудняющим ошибочно писать опасный, шаткий и часто нарушенный код concurrency -tolerant на других языках. Если ваш проблемный домен включает параллельное программирование, массив встроенных инструментов для управления concurrency может быть лучше, чем библиотеки, специфичные для реализации, или библиотеки с самым низким общим знаменателем, доступные в других Lisps и схемах.

Ответ 10

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

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

Clojure.

Ответ 11

Я всегда стараюсь изучать новые языки, поэтому я заинтересован в обучении Clojure. Но, не являются ли SBCL и некоторые другие Common Lisp реализаций намного быстрее, чем Clojure? Вам не понадобится значительно больше 4 процессоров (и разумно параллелизуемая задача), чтобы компенсировать разницу в производительности между приложением Clojure и даже однопоточной версией SBCL того же приложения?

Ответ 12

Как правило, я предпочитаю Clojure над другими языками в случаях, когда любой из них соответствует вектору: (1). Модель домена имеет тенденцию выглядеть очень рекурсивной и/или графически подобной. (2). Там есть возможность использовать многоядерную среду JVM (например, эластичный бобин) (3). Там есть нечеткий барьер между данными и кодом (подумайте, что калькулятор RPN, где узлы могут быть операторами или номерами)

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