LINUX.ORG.RU

Clojure 1.3

 , , ,


1

2

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

Изменения в новой версии:

  • Монолитная система дополнений clojure-contrib.jar заменена на полностью модульную структуру, что позволяет, во-первых, не включать в готовые приложения код неиспользуемых библиотек, а во-вторых, иметь собственный цикл разработки для каждой отдельной библиотеки. При этом для обновления с Clojure 1.2 рекомендуется сначала обновить библиотеки, а затем уже обновиться до Clojure 1.3;
  • Улучшенная поддержка примитивов для арифметических расчетов;
  • Изменения в определении записей (defrecord) и типов (deftype);
  • Улучшена система оповещения об исключениях и ошибках;
  • Несколько новых функций в clojure.core, clojure.data, clojure.pprint, clojure.repl;
  • clojure.java.shell/sh теперь поддерживает в качестве источника данных объекты типов InputStream, Reader, File, byte[];
  • Поддержка Maven для компиляции и развертывания приложений;
  • Улучшения в плане производительности скомпилированных приложений;
  • Множество устраненных ошибок.

>>> Полный список изменений

★★★★★

Проверено: maxcom ()
Последнее исправление: maxcom (всего исправлений: 3)

Ответ на: комментарий от dave

Так и есть. Работает eval, можно загружать код во время исполнения, переопределять функции и переменные. Но есть и AOT-компиляция в байт-код (позволяет уменьшить время запуска, но на производительность влиять не должно).

Fice ★★
()
Ответ на: комментарий от anonymous

>Потому как у школоты компьютеры старые, на до 2 Гб оперативки будет больше тормозить аналогов, но кто же ориентируется на русскую школоту. Вы запустите программку хотя бы на современном 2 ядерном процессоре и хотя бы на 2 Гб оперативки, минимальный стандарт на сегодняшний день и убедитесь что даже такой комбайн, как Eclipse летает.

На нормальном железе и сравнивайте с аналогами. А то если программа за $2000 на java тормозит у школоты, разработчикам до этого не дела ибо не их клиент нищеборот, который и за $500 системный блок себе купить не может.

Дело не в деньгах, дело как говорится в квалификации и в технологии, на кой хрен нужна эта жаба если при «школьном» железе но написанная на Си прога работает быстрее чем эта жаба?

Mojo
()
Ответ на: комментарий от anonymous

> Дотнет всегда был быстрее джавы из-за архитектурных особенностей.

Было бы очень интересно узнать подробности. О каких именно архитектурных особенностях вы говорите? Есть бенчмарки?

Fice ★★
()
Ответ на: комментарий от r

>анекдоты без ссылок такие анегдоты

Хм. где там ты ссылку не нашел?

особенно в Иксах, т.к. там еще и с реализацией 2D проблемы (исправили в JDK7?).


исправили в Иксах?

fxd

Karapuz ★★★★★
()
Ответ на: комментарий от Mojo

> Дело не в деньгах, дело как говорится в квалификации и в технологии, на кой хрен нужна эта жаба если при «школьном» железе но написанная на Си прога работает быстрее чем эта жаба?

В этом и проблема, — почему-то никто не понимает, что у java и Си разные назначения, хоть они оба и универсальны.

note173 ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

> таким образом, не только ява, но даже и скала как языки не спасают от утечек памяти

Сюрприз!

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

Сборщик мусора не спасет, например, от ситуации, когда программист создает список, в который по мере работы программы добавляет элементы, но никогда не удаляет.

Fice ★★
()
Ответ на: комментарий от Fice

Сборщик мусора не спасет, например, от ситуации, когда программист создает список, в который по мере работы программы добавляет элементы, но никогда не удаляет.

Применительно к истории Scala vs Clojure более интересно другое: - неужели Scala использовали такие ламеры, которые за два года эксплуатации системы не смогли найти утечку памяти или выбросить сторонний компонент, в котором эта утечка происходила; - чем Clojure помогла разработчикам написать софт так, что утечки памяти там не было? Какие-то языковые особенности или другие библиотеки?

А вообще удивительно: сначала говорят о какой-то сложности — The mapping from half a dozen tables in the database to a flat XML schema was pretty complex and the company had tried a number of solutions with mixed success in the past. — а потом выясняется, что там на Scala кода-то было 1000 строк, а на Clojure вообще 260. Это где там сложность-то спряталась?

eao197 ★★★★★
()
Ответ на: комментарий от Mojo

>Дело не в деньгах, дело как говорится в квалификации и в технологии, на кой хрен нужна эта жаба если при «школьном» железе но написанная на Си прога работает быстрее чем эта жаба?

Ну так и пользуйтесь программой на Си. А хотите более функциональный софт, покупайте соответствующие железо. в чём проблема, то?

anonymous
()
Ответ на: комментарий от eao197

поставьте ей верхний лимит на отжирание памяти и JVM отожрет ровно столько, сколько вы ей скажете

zapruder
()
Ответ на: комментарий от Mojo

На Unmanaged языке не разумно писать такие сложные приложения. Хотя гуй был бы быстрее, кто же спорит. Но лучше тромозное что-то, чем ничего. Вот покажи мне аналог IDEA на C++/C.

dizza ★★★★★
()
Ответ на: комментарий от Karapuz

крылья, ноги, хвосты...

интересно, вот тут пишут как код на clojure получился почти в 3 раза меньше чем на scala (код не приводится) http://www.dzone.com/links/rss/anecdote_clojure_vs_scala.html

а вот тут почти во всех тестах от в полтора раза больше http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=clojure...

а вот тут видно http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=java&am... http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=java&am... что код на java быстрее, потребляет меньше памяти и в половине случаев равен по объему коду на Clouse и не сильно уступает по объему коду на Scala. Кому верить и так ли это важно? ) Лично я больше верю в результат с приведенным кодом.

PS Интересно было бы померить читаемость. Например я некоторые вещи пищу на AspectJ, но только тогда, когда выигрыш не в ОБЪЕМЕ кода в УДОБСТВЕ ПОДДЕРЖКИ этого кода. Мне важно не сколько занимает этот код в строчках кода, а сколько времени уйдет на его написание и сколько уйдет на поддержку. Это тестировать гораздо сложнее и как правило понимание приходит с опытом. Лично мое мнение после прочтения JavaPuzzlers - код должен быть ОЧЕНЬ ПРОСТЫМ,ХОРОШО ЧИТАЕМЫМ и легким в поддержке, все остальное вторично.

Yilativs ★★★★
()
Ответ на: крылья, ноги, хвосты... от Yilativs

Ну на примеры кода с http://shootout.alioth.debian.org ориентироваться тоже не стоит. Там же все мега-оптимизированное. Нужно сравнивать простые решения в лоб, которые пишут нормальные программисты каждый день.

dizza ★★★★★
()
Ответ на: крылья, ноги, хвосты... от Yilativs

> код должен быть ОЧЕНЬ ПРОСТЫМ,ХОРОШО ЧИТАЕМЫМ и легким в поддержке, все остальное вторично

а как же кацкель?

Karapuz ★★★★★
()
Ответ на: комментарий от dizza

Согласен, просто лучше хоть какой-то пример, чем голые слова.

Привели ссылку где говорили о том как лаконично можно писать на clousure в сравнение со scala. Я привел тесты показывающие, что все на оборот.

Признаюсь, scala мне нравится больше чем clousure по идеологии, но большого опыта работы ни с тем ни с другим языком у меня нет. Пока выбор такого языка для написания реальной системы выглядит очень странно. Нет ни нужного количества специалистов высокого класса (значит тех кого наймут на проект будут учится на проекте, к тому же в проекте появятся не заменимые люди, а оно вам надо?!), нету хороших книг (книги которые только хвалят язык нужны только тем, кто этот язык продает), нету приличной открытой IDE.

PS Я считаю, что каждый зрелый язык имеют свою нишу.

Из опыта работы с Haskell, Python, Java+AscpectJ, Perl, C

что-то в одну строчку удобнее писать на perl что-то маленькое на подобие скрипта делающего одну задачку(до 1000 строк) удобней писать на Python что-то связанное с математикой (матрицы, алгоритмы сжатия, криптография) - Haskel (только в случае если вам это не нужно использовать из других модулей вашей программы). Java - если нужно написать приложение (а не скрипт или утилиту) С - если нужно выжать максимум производительности из отдельного участка кода.

Yilativs ★★★★
()
Ответ на: комментарий от Yilativs

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

Reset ★★★★★
()
Ответ на: комментарий от Karapuz

> Хм. где там ты ссылку не нашел?

Не от тебя, а от типа по твоей ссылке. Пока там «я написал на скале - е получилось, написл на кложуре - получилось - скала говно кложура рулит».

r ★★★★★
()
Ответ на: комментарий от RedPossum

>дык то же моно, моно медленное, а реализация от ms, ходят слухи, быстра

Тип утверждал что причина в архитектуре (уже одно это демонстрирует - но покормим его). У моно что - другая архитектура?

r ★★★★★
()
Ответ на: комментарий от Fice

>Сборщик мусора не спасет, например, от ситуации, когда программист создает список, в который по мере работы программы добавляет элементы, но никогда не удаляет.

Он может сбрасывать ненужное старье в своп.

AVL2 ★★★★★
()
Ответ на: комментарий от r

Хочешь сказать, что заложенный в архитектуру явный boxing, value types, инструкция CallI и полноценная арифметика указателей не является потенциальным преимуществом? Для JVM компилятор должен быть намного умнее.

anonymous
()
Ответ на: комментарий от anonymous

>Хочешь сказать, что заложенный в архитектуру явный boxing, value types, инструкция CallI и полноценная арифметика указателей не является потенциальным преимуществом?

Во первых ты заблуждаешься по поводу отсутствия некоторых вещей в JVM - от того что там нет арифметики указателей в языке - не проистекает что указатели куда-то делись, есть магический клас Unsafe который позвит отсрелить себе яйца не хуже чем unsafe дотнета.

А во вторых ты хочешь сказать что эти небольшие мелочи делают clr и jvm «архитектурно» разными?

Ну а в третих самый ключевой вопрос - неужеле ты думаешь что это дает такое охрененное преймущество?

r ★★★★★
()
Ответ на: комментарий от r

> от того что там нет арифметики указателей в языке - не проистекает что указатели куда-то делись, есть магический клас Unsafe который позвит отсрелить себе яйца не хуже чем unsafe дотнета

Тупишь, сильно. JIT тебе этот Unsafe в тупой и эффективный код не развернет.

А во вторых ты хочешь сказать что эти небольшие мелочи делают clr и jvm «архитектурно» разными?

Да. Явные value types - это существенное архитектурное отличие. Я уж не говорю о том, что CLR намного проще и тупее, и потому его проще JITить.

неужеле ты думаешь что это дает такое охрененное преймущество?

Я не «думаю», я знаю, потому как имел несчастье копаться в потрохах HotSpot.

anonymous
()
Ответ на: комментарий от Reset

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

Разве что как язык для скриптования жабопрог, но никак не как самостоятельный язык для самостоятельных программ.

Deleted
()
Ответ на: комментарий от anonymous

java - толстая, и в этом весь минус. Десятая секунды на запуск в более тяжелых случаях роли не играет, и жаба заруливает пых в разы.

Deleted
()
Ответ на: комментарий от Reset

Пользовался cmucl и sbcl. Не сказал бы, что они тяжелые. А clisp - так вообще совсем легкий.

А scheme - еще более легкая, но ИМХО не совсем практичная.

Deleted
()
Ответ на: комментарий от Stalin

Ничто. Из всех лиспософтов обычный хомячок может юзать только emacs.

Deleted
()
Ответ на: комментарий от anonymous

> отсутствие инструментов для мета-программирования (если сравнить с CL)

Что тебе не так с метапрограммированием в Clojure, клоун?

anonymous
()
Ответ на: комментарий от anonymous

>Явные value types - это существенное архитектурное отличие

интересно, много ли в среднем сайте на asp.net используются VT?

Karapuz ★★★★★
()
Ответ на: комментарий от eao197

> на Scala кода-то было 1000 строк, а на Clojure вообще 260. Это где там сложность-то спряталась?

Что не так?

Мерять сложность задачи количеством строк - явный признак быдлокодера. В твою черепную коробочку не приходило, что сложность может быть не в кодировании? А в том, чтобы сконструировать эффективный алгоритм? А его реализация может занимать хоть 100 строчек, хоть 1000, это без разницы.

anonymous
()
Ответ на: крылья, ноги, хвосты... от Yilativs

> код должен быть ОЧЕНЬ ПРОСТЫМ,ХОРОШО ЧИТАЕМЫМ и легким в поддержке, все остальное вторично.

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

Вообще, только махровые быдлокодеры выбирают язык, основываясь на синтаксисе, внешнем виде кода, так называемой «читаемости» и прочей побочной шелухе. Настоящие Программисты уделяют внимание в первую очередь возможностям языка.

anonymous
()
Ответ на: комментарий от Karapuz

> а как проверить время отклика и что это такое?

Время реакции системы на внешнее событие. Для GUI — задержка между нажатием на кнопку и появлением результата на экране, обычно оценивается субъективно. Оценивать и ограничивать задержки пытаются там, где это критично — в системах реального времени.

Fice ★★
()
Ответ на: комментарий от Karapuz

«Plan to Throw One Away» ©

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

И забыли бы, но кто-то зачем-то запостил ссылку на HN, и началось. Теперь вот и на ЛОРе. Было бы что обсуждать.

Fice ★★
()
Ответ на: комментарий от Karapuz

Какое отношение пруф имеет к clojure?

Deleted
()
Ответ на: комментарий от aho

>> Вот покажи мне аналог IDEA на C++/C.

XCode4, во многом и покруче будет

Может «во многом» и круче, но по количеству платформ, где она запускается - похуже.

P.S. IDEA не пользовал, для моих скромных нужд хватает Eclipse, но что-то у нас тут в компании и под яфон не спешат программировать в хкоде. Пишут в визуал студии а хкод используют для заливки на девайс.

Toll ★★
()
Ответ на: комментарий от Toll

> но по количеству платформ, где она запускается - похуже.

не вина ЯП, а политика Apple

но что-то у нас тут в компании и под яфон не спешат программировать в хкоде. Пишут в визуал студии


вендузятники же, что еще хуже чем маководы

aho
()
Ответ на: комментарий от anonymous

>Ну так и пользуйтесь программой на Си. А хотите более функциональный софт, покупайте соответствующие железо. в чём проблема, то?

Именно так и делаю. У меня нет ни одной программы использующей Жабу. Даже Опен Офис устанавливаю без жабы. Зачем растрачивать ресурсы компа, на эту порнографию?

Mojo
()
Ответ на: комментарий от Mojo

>Зачем растрачивать ресурсы компа, на эту порнографию?

мы рады что ты так холишь и лелеешь свой комп.

Karapuz ★★★★★
()
Ответ на: комментарий от Karapuz

>xcode еще нужно купить, а у них наверняка и VS варезная

Не правильный ответ. Все куплено.

Toll ★★
()
Ответ на: комментарий от aho

>не вина ЯП, а политика Apple

Да, конечно. И dizza явно был опрометчив, когда решил что на С/С++ не найдут схожих по мощности аналогов ИДЕ на жабке.

вендузятники же, что еще хуже чем маководы

Вендузятники, в большинстве своем, конечно. Дык, игроклепатели. По другому и быть не могло бы.

Toll ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.