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)

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

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

я рад, что ты все понял

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

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

Это потому что ты racket не видел. В нем есть всё :)

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

>Я уж не говорю о том, что CLR намного проще и тупее, и потому его проще JITить.

Пока я не вижу подтверждающих результатов на шутауте.

r ★★★★★
()

И зачем нужно это поделие?

ПионЭры, не сдавшие экзамен по Джаве могут погнкть пальцЫ перед себе подобными?

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

> Сюрприз!

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

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

www_linux_org_ru ★★★★★
()

>предоставляя вам все преимущества функционального программирования.
Как глубоко укоренилось это заблуждение... Или это троллинг?

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

> А какого это перепугу Вы решили, что XCode на C/C++ написан? Смешной, однако.

Вы такой серьезный - наверное, знаете, на чем XCode написан? Поделитесь.

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

> какой смысл поверх ненужной жирной системы костылей и подпорок городить город-сад функциональщины?

Ну, может, для того, чтобы жабакодеры могли помацать функциональщину за разное. А там, глядишь, и более другими языками заинтересуются, тем же Haskell-ем, к примеру.

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

1.Да, вы правы, там V - от Virtual. Что-то я не то напечатал. 2.Ну, разработчики, ответственные за дизайн виртуальной машины. Те, кто её спроектировал, а не просто код лабал.

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

В сервер-режиме потребление памяти возрастает на 400-500%. И то, что занимает сотню метров в памяти, начинает занимать пятьсот:) Просто в этом режиме виртуальная машина сохраняет в память кучу промежуточных результатов компиляции, и производит над ними немало преобразований для оптимизации результата, то есть нейтив-опкода. А при нехватке памяти VM вынуждена терять часть результатов своей работы(промежуточных результатов), и из-за этого делать одну и ту же работу по несколько раз. Чем меньше у VM памяти, тем больше преобразований приходится выполнять, а так как у PC нет специализированных аппаратных Java-процессоров, то нагрузка на CPU возрастает в зависимости от количества доступной памяти. Что касается java-софта, так самое ценное из него - это IDE, корпоративное ПО и сервлеты, крутящиеся в контейнерах вроде Tomcat. который намного приятней апача. И в серьёзных проектах - более эффективен. Но в SOHO-сегменте явно не оправдана такая тяжелая артиллерия.PHP, апач и MySQL для SOHO - лучшие.

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

С чего бы это? Моя любимая среда разработки - Eclipse. И Java мне нравится, но ей необходимо динамичное развитие. Взять VM от Android, позаимствовать идеи от .NET и (самое главное) различных Lisp'ов. А вообще любимый ЯП у меня JavaScript:) Ну и очень Scheme нравится. своей мощью и чистотой. А вообще любая технология хороша - в своей среде. Не стоит тащить жабу туда, где ей не рады. И плюсы туда, где жаба идеально подходит. Например писать 1C Бухгалтерию на нейтив-ЯП - форменное преступление. На Западе такое сильно удивило-бы клиентов компании-производителя. Ведь ПО для корпоративных нужд, и финансовой сферы надо писать на Java. Это позволяет использовать кучу готовых решений и технологий для бизнес-приложений, запускать приложение на любой ОС. И гарантировать, что при смене платформы не будут потеряны инвестиции в IT. Представьте, что в один прекрасный момент MS просто испарится(природный катаклизм поспособствует, или рыночная коньюктура). И все, кто инвестировал в 1С определённые деньги, просто их потеряют. Или Microsoft Office. Был бы он на Java - его бы покупали пользователи других платформ. Это лучший офисный пакет.

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

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

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

>Ну какой смысл поверх ненужной жирной системы костылей и подпорок городить город-сад функциональщины?

Каким образом сия метода хотя бы в теории могла бы привести к успеху?

+

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

> Лисп опять проиграл скале в 1,1...8 раз

Думаю, людям, которым нужен именно лисп, пофиг.

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

> Те, кто её спроектировал, а не просто код лабал.

Чего-чего? Расскажи ка нам про разработку Dalvik. Очень познавательно.

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

Что не так?

Экспорт данных из пары десятков таблиц в XML, занимающий 1000 строк на Scala и 260 строк на Clojure не тянут на сложную задачу.

Или основная сложность была в том, чтобы в течении двух лет эксплуатировать систему, которая регулярно падала с Out Of Memory?

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

Ну понятно, настоящие анонимные Ъ-программисты подтянулись. Очевидно, вам не составит труда привести пример сложной задачи, реализация которой на Clojure будет занимать в 4 раза меньше кода, чем на Scala. Все ж таки Clojure не с plain C сравнивается.

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

> Это потому что ты racket не видел. В нем есть всё :)

Именно по этому когда я пытался собрать одну из его версий он при компиляции чего-то относящегося к IDE выжрал 3 гига RAM и весь своп, после чего был прибит OOM-killer'ом ?

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

> У тебя с руками что-то. Ни разу такого не наблюдал.

Нормально у меня с руками. Это был стандартный emerge dev-scheme/racket. Так только haskell когда-то память жрал при сборке.

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

Значит в генте что-то сломано. У меня 5.1.2 и 5.1.3 нормально собирались, память не жрало.

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

> Ну какой смысл поверх ненужной жирной системы костылей и подпорок городить город-сад функциональщины?

http://clojure.org/rationale

Каким образом сия метода хотя бы в теории могла бы привести к успеху?


Учитывая, как быстро (для Лиспа) Clojure приобретает популярность, успех уже можно засчитывать.

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

>Субъективно, GUI на IBM J9 показался более отзывчивым, чем на Hotspot.

Такое же ощущение

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

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

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

Есть системный архитектор, тот кто отвечает за архитектуру приложения. И шарит в UML и прочих мудрёных технологиях. Разве я похож на такого уникума? Мне нечего рассказать. Мне до них как ползком до Китая:)

lucentcode ★★★★★
()

Аналитики с ЛОРа такие аналитики.
> Clojure - не Lisp
Повторяйте про себя дважды перед сном. Так даже лучше - у Clojure будет шанс избавиться от наследия стереотипов, связанных со словом Лисп.

> Clojure - тяжелый, а CL/Схемка - лёгкие
Зато Clojure имеет прямо здесь и сейчас все возможные библиотеки, которые были когда-либо написаны под JVM. Все инвестиции, которые идут в JVM, автоматически вкладываются и в Clojure.

> На этой херне ничего не написано
Storm - распределенная система обработки данных реального времени, написана по большей части на Clojure только на 20%, но разработчик заявил, что это самая тяжелая часть программы. Используется Твиттером.
Animatoon - сервис для создания HTML5-анимации. Clojure используется в бек-энде.
Trakr - приятный issue tracker.
http://dev.clojure.org/display/community/Clojure+Success+Stories - компании, которые используют Clojure в продакшене.

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

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

Неправильно выразился по поводу Storm. Большинство Java-кода в нём сгенерировано. Если отбросить его, то Storm написан преимущественно на Clojure.

«Is Storm mostly written in Java?»

If you look at the languages graph on Github, it says that Storm is «64% Java». However, this is inaccurate because those numbers include the Java code generated by the Thrift compiler. If you exclude the generated code, you'll find that Storm is over 50% Clojure in terms of line count. In terms of functionality though, Storm is around 98% Clojure. The Java code I wrote is mostly interfaces and small classes that a user of Storm would encounter in the public API (Java is, ahem, verbose).
Источник

Если у кого-то есть желание попробовать Clojure, можете начать с Clooj. Clooj - это IDE для Clojure написана на самом Clojure. Не верх функциональности, но чтобы посмотреть на язык хватит.

unlog1c ★★★
()

>динамического языка
динамические языки не нужны. Это только создает кучу проблем и двусмысленностей при написании кода, ведет к невозможности создать нормальную IDE (хотя бы потому что автоподстановка нереализуема в принципе), соответственно очень сильно замедляет разработку и усложняет поддержку и проч и проч. Да, а за создание javascript вообще надо руки оторвать, имхо. Самый убогий, неудобный, нелогичный язык + различное поведение в различных средах просто убивает.
(то ли дело в джаве - идеальный язык, идеальные IDE, идеальные инструменты для написания кода/дебага/сборки/тестирования/разворачивания/документирования, работает везде одинаково, поведение в любой ситуации описано стандартом и т.д.)

функционального программирования

Нужно в очень узком круге специализированных задач. ООП как парадигма разработана для создания приложений имеющих отношение к реальному миру, так как by design обеспечивает легкую конвертацию бизнес-процессов в код. А большинство решаемых задач в программировании имеют отношение к реальному миру, а еше точнее - автоматизирует некоторые процессы, которые ранее выполняли люди.

собственный цикл разработки для каждой отдельной библиотеки.

это они очень зря. Codebase Должен быть единым, достаточно просто было сделать несколько артефактов на выходе. Замучаются они с этим.

удобства скриптового языка

а можно хоть одно удобство, для примера?

Вывод: вышла очередная версия очередной поделки, представляющей исключительно академический интерес, которую никто не использовал в бизнесе и не будет.

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