После года разработки представлен (https://clojure.org/news/2018/12/17/clojure110) релиз динамического языка программирования Clojure 1.10 (http://clojure.org/), базирующегося на языковых конструкциях Lisp и сочетающего в себе возможности функционального и многопоточного программирования с чертами современных скриптовых языков. Код программ на языке Clojure транслируется в Java байт-код и выполняется на виртуальной машине JVM. Код компилятора Clojure, библиотек и runtime-компонентов распространяется в рамках лицензии Eclipse Public License.
При подготовке (https://github.com/clojure/clojure/blob/master/changes.md) новой версии основное внимание было уделено улучшению средств информирования об ошибках и обеспечению совместимости с Java:
- Выводимые в интерактивном окружении REPL (https://clojure.org/guides/repl/introduction) (Read-Eval-Print Loop) и в Clojure ошибки теперь разбиваются на категории в зависимости от фазы исполнения (чтение, раскрытие макросов, компиляция, выполнение, вывод результата и т.п.), и включают дополнительную информацию о местоположении ошибки в исходном тексте и учитывают контекст. Новый код обработки ошибок включён в состав clojure.main REPL, но функциональность также может использоваться и в других инструментах.
- Проведена работа по обеспечению совместимости с Java 8 и Java 11.
Устранены многие ошибки, связанные с генерацией байткода, прекращена поддержка устаревших API и внесены изменения, связанные с новой модульной системой Java. Для работы Clojure теперь требуется Java 8 или более новая версия.
URL: https://clojure.org/news/2018/12/17/clojure110
Новость: https://www.opennet.me/opennews/art.shtml?num=49802
Lisp в JVM? Очень интересно...
Попробуйте )
Я лучче попробую эликсир в EVM.
Также можно попробовать имплементацию Кложуры для Эрланга - Clojerl.
Уж теперь-то заживём!
Еще бы! Один из лучших языков для разработки. Только 99% хомяков тут что-то отличное от С-подобного синтаксиса не осилит.
хомяки вообще к Си ни ногой))) он сложен ))) и никаких тебе плюшек автопроверки передвыполнением как в питон или переносимости . не не он как раз для нового поколения "программистов" не желающих знать как работает система. хотя выявление ошибокв си заставляет желать лучшего. например выход за пределы массива или бесконечный цикл без останова, питон в этом отношении даже указывает точную строку ошибки с описанием. вот бы си/с++ тоже так мог.
Rust же
я в крайнем случае питоном попользуюсь. рустаманством не страдаю.))
Мне кажется, эти языки (Rust и Python) предназначены для решения немного разных задач.
Есть ещё такая точка зрения:Хочешь нормально писать на ЦэПэПэ - пиши на Си, а лучший способ писать на Си - это генерировать код из ОКамла)) И ведь охранительно работает!
ЛУЧШИЙ ЯЗЫК для разработки это тот с которым ты успешно решаешь поставленные перед тобой задачи. Если ты будешь использовать язык, который не будет на столько эффективен для твоих задач, то ты ИДИОТ. Поэтому не имеет значение на чем писать на Python, C, C++, Javascript, Ruby и т.д. Это как покупать телефон на андроид или iphone и постоянно ебст...сь со своим выбором, потому что ты его сделал под влиянием стороннего мнения.
Я смотрю, Вы разбираетесь в сортах...
Perl наше всё
Я не осилил, вопрос осилившим. Как я понимаю в LISP подобных языках создание типа это довольно редкая фича, обычно данные описываются стандартными типами доступными из коробки (код=данные), и у нас есть миллион функций против десятка типов. Так? Как миллион функции у себя в голове удержать и запомнить какая функция к какому типу данных применима?
Когда я в ООП кодирую я не помню все методы у объекта, ide подсказывает доступные методы у объекта, а в clojure я теряюсь, ничего не могу вспомнить. Я не правильно работаю с clojure?
Можно именовать понятно функции, можно использовать протоколы. Но мне тоже это не нравится в Кложуре. Кривовато реализовано. А вот в ML-like языках OCaml/F# можно программировать типами и иметь непревзойдённую надёжность кода потому что компилятор вообще всё ловит при грамотном проектировании.
> Можно именовать понятно функции, можно использовать протоколы. Но мне тоже это не
> нравится в Кложуре. Кривовато реализовано. А вот в ML-like языках OCaml/F#
> можно программировать типами и иметь непревзойдённую надёжность кода потому что компилятор
> вообще всё ловит при грамотном проектировании.Побольше бы здесь таких поясняющих комментариев.
Да, не правильно. Для освоения кложуры нужен ментор, кто поможет разобраться с мышлением для нее. Можно своими силами, но это дольше.
Несмотря на то, что язык проще, чем все известные языки необходимо сделать самое сложное поменять мышление к подходу разработки. Ну например, что циклы или оператор присваивания не нужны. Прочитайте книгу SICP. Она поможет. В этой книге оператор присваивания дается аж после 240 страниц, в то время как во всех остальных языках с оператора присваивания начинают изучать язык.
Если ответить более конкретно, то есть вообще всего 4 типа коллекций и примитивы. Самый используемый тип вообще один - мапа (hash map). И к мапе применяются функции. Миллион функций помнить не надо. Надо просто разбить вашу задачу на шаги и найти/написать нужную функцию для каждого шага.
Программа на Clojure очень похожа на сборочный конвейер автомобилей. Авто движется всегда в одном направлении. И на каждом шаге происходит атомарное с точки зрения бизнес-логики преобразование.
input-map ->f1 ->f2 -> f3 ->f4 -> output-result. Очень простая цепочка и на каждом шаге видно вход и выход и типы вводить просто не нужно.
Можно и типы добавить. TypedClojure. Можно использовать Cursive для редактирования.
Можно без типов работать. Кому как нравится
..по сути, "по капотом", макросы, а потому "педаль" свои макросы если чего-то не хватает и все "вуаля"...
Иногда полезно посмотреть как это делают well-known апликухи, такие как IMMORTAL или STORM...
https://clojure.org/guides/getting_started> Installation on Windows
> Not yet available - see Leiningen or Boot instead.Увы, не повезло мне выучить этот волшебный грибной язык.
Ставь Ubuntu. Там заработает
Бубунту не признаю.Проще на цыгвина поставить оказалось, минутное дело.
А вообще за такие способы установки, что там описывают, надо спрашивать со всей строгостью. Приходится читать, что в тех скриптах понаписано.
Leningen стабилен и просто ставится на Шиндоус
Leiningen вроде стабильнее Boot-a. Или Boot лучше? Как думаете?
Смотря какие задачи решаете. Я спустя год на буте переехал на lein и стало куда веселее жить, даже компиляция быстрее пошла. Но сейчас все больше склоняюсь к связке с shadow-cljs
Спасибо.
Download lein.bat and put it to a PATH directory. Then open powershell and enjoy.
С такой "юзабилити" инсталляции они ещё лет 20 будут сидеть на задворках Линуксов. И что поражает, так это полное непонимание, что "ковыряться в кишках системы" и "программировать" - это разные вещи. Даже Ди - просто качаешь, ставишь - всё, канпеляй! Нет никаких "смотри другие извраты как почесать правое ухо левой ногой".
> просто качаешь, ставишь - всё, канпеляй!Ляп-ляп и в продакшын!
Я даже не знаю, что вам сказать на это. Если вам 4 пункта - это жуть как много и вы уже не осиливаете - то может вам сменить профессию?leiningen.org
4 пункта инсталляции. Профит.
Нужна Windows - Cygwin, вон, товарищ выше взял и развернул.
Да, еще Java нужна. Но вы-то JVM сможете развернуть на своей ОС. Вы ведь продвинутый пользователь ПК?
..ну как бы чистый stream processing пока только Storm делает... Потому, о каких задворках речь?
> Увы, не повезло мне выучить этот волшебный грибной язык.Так для виндовс редко поддерживают инструменты разработки. Под нее и swift нету.
Под Винду ставится F# - ОКамл (то есть высокопроизводительный, безопасный функциональный язык) на .NET.
Пожалуй лучший функциональный язык сегодняшнего дня.
Спасибо. Я просто интересуюсь в порядке хобби выходного дня, я не зарабатываю этим на жизнь.
Я бы не стал так категорично утверждать. Лучший у каждого свой. А мы на техническом портале.
F# - неплохой язык, произведенный в MS. Идеи функционального программирования - ок. Но кому-то MS не очень нравится.Есть еще Erlang, CommonLisp, Clojure, Scheme
OCaml разработан французским "институтом исследований в информатике и автоматике" (INRIA). Фа диез несколько другой язык, "под Винду", возможно, и лучший.
> OCaml разработан французским "институтом исследований в информатике и автоматике" (INRIA).
> Фа диез несколько другой язык, "под Винду", возможно, и лучший.В многообразии этих ваших функциональных языков и их диалектов без бутылки не разберёшься.
Так что, первым делом читать книжки про OCaml? ;-)
>Так что, первым делом читать книжки про OCaml? ;-)Будь мужиком - учи Haskell!
ЗЫж. Под в-нду есть.(ghc)
>>Так что, первым делом читать книжки про OCaml? ;-)
> Будь мужиком - учи Haskell!Не хочу, мне его название не нравится. В нём явно содержится какой-то харразмент.
«Система типов: полная сильная статическая с выводом типов».Я передумал, такое надо учить.
Хорошо бы в таких топиках знатоки сразу называли правильные книжки для чтения. А то найдёшь некую книжку, начинаешь читать и начинает болеть от неё мозг. Слова вроде все известные, а всё вместе — какая-то шиза. Очень плохие переводы, переводчики не знают ни английского, ни русского. Ну и не только это, а проблематичность самообучения по многим таким книгам.
Взял другую из интернетов (Д. В. Шевченко. О Haskell по-человечески. 2014), автор пишет в предисловии:
> А в самом деле, почему? С чего это я решил написать ещё одну книгу о Haskell?
> Причина первая: меня достало! Достало, что почти все известные мне руководства по Haskell начинаются с демонстрации того, как реализовать алгоритм быстрой сортировки. И ещё что-то там про факториал и числа Фибоначчи. Мне за все годы практики ни разу не приходилось реализовывать алгоритм быстрой сортировки. Поэтому я даже не знаю, что это такое.
> Исторически сложилось так, что большинство из нас начали свой профессиональный путь именно с императивных языков. И вот вместо того, чтобы показать нам красоту функциональных языков в свете их реального применения, нас тыкают носом в числа Фибоначчи и в почти нами забытую математическую нотацию... Естественно, читая подобные материалы, обычный программист начинает чувствовать себя дeбилoм, и это чувство отбивает в нём всякую охоту осваивать эту непонятную функциональщину.
> Именно поэтому я расскажу о Haskell нормальным, человеческим языком, с минимумом академизма и действительно понятными примерами.
> Есть и вторая причина. Все известные мне книги по Haskell слишком объёмные. В них много лишнего. А у нас, программистов-практиков, не так много свободного времени, чтобы проглатывать очередной талмудоподобный труд в 500 страниц. Именно поэтому я расскажу о Haskell по возможности лаконично.
Золотые же слова!
Ну, попробую читать.
А как у OCaml нынче с многопоточностью? Раньше, насколько я знаю, мешали многочисленные locks в стандартной библиотеке.
Блин, я же ещё на версию 1.9 не успел переехать.
А я так и не нашел, что они нового сделали. Трансдьюсеры, макросы кто-то вообще использует?
Да, собственно сам Clojure так точно...
Несколько лет программировал на Clojure (начинал, кажется, с версии 1.1), но теперь больше смотрю в сторону Racket и Guile. После Java освоение Clojure было значительным шагом в программистском развитии, но теперь, когда появился опыт работы с другими лиспами, мне многое в нем не нравится. В целом Clojure кажется каким-то неряшливым и нестрогим, более принадлежащим современной эмпирической культуре программирования (тыкать, пока не заработает), академическая выстроенность Схемы мне ближе.Синтаксис Clojure на первый взгляд выглядит привлекательно, но на самом деле совершенно неразумный. Квадратные скобки означают вектор, круглые — список, у векторов и списков разные характеристики производительности, но в синтаксисе они используются не поэтому, а просто потому что разные скобки и их можно различать, т. е. одно и то же одновременно используется для обозначения совершенно ортогональных вещей. Кроме того, стремление авторов избавиться во многих конструкциях от "лишних" скобок делает Clojure неудобным для структурного редактирования (paredit), т. е. убивает один из главных кайфов от работы с Лиспом. Ключевые слова в Clojure лишены смысла: они используются в качестве идентификаторов и ключей в словарях и структурах, но не имеют никакого специального синтаксического значения, т. е. могли бы быть полностью убраны из языка и заменены символами. Вместо этого имело бы смысл использовать киворды для передачи именованных аргументов, но в существующей ситуации, когда киворды используются для других вещей, возникнет проблема различия киворда, указывающего аргумент, от киворда, который нужно передать как значение аргумента.