LINUX.ORG.RU
 
ins3y3d

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 для компиляции и развертывания приложений;
  • Улучшения в плане производительности скомпилированных приложений;
  • Множество устраненных ошибок.

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

ЗАСТАВЬ КОМПЬЮТЕР ПОЛИВАТЬ ОГОРОД

автоматизация своими руками: электроприборы под контролем компьютера
beware of programmers who carry screwdrivers!
http://www.unicontrollers.com/products/unc01x

[#] Ответ на: комментарий от Toll 26.09.2011 20:14:06  
aho

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

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

()
[#] Ответ на: комментарий от franchukroman 26.09.2011 18:36:33  
Reset

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

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

***** ()
[#] Ответ на: комментарий от anonymous 26.09.2011 18:15:02  
r

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

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

***** ()
[#]  
Bioreactor

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

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

*** ()
[#] Ответ на: комментарий от Fice 26.09.2011 13:04:36  
www_linux_org_ru

> Сюрприз!

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

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

**** ()
[#]  

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

* ()
[#] Ответ на: комментарий от aho 26.09.2011 19:39:29  

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

anonymous ()
[#] Ответ на: комментарий от anonymous 26.09.2011 22:35:52  

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

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

***** ()
[#] Ответ на: комментарий от AVL2 25.09.2011 23:49:33  

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

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

* ()
[#] Ответ на: комментарий от shty 26.09.2011 3:28:51  
lucentcode

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

** ()
[#] Ответ на: комментарий от dizza 26.09.2011 3:34:03  
lucentcode

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

** ()
[#] Ответ на: комментарий от anonymous 26.09.2011 8:14:34  
lucentcode

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

** ()
[#] Ответ на: комментарий от lucentcode 26.09.2011 23:45:53  
dizza

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

*** ()
[#] Ответ на: комментарий от AVL2 25.09.2011 23:49:33  
Hexs

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

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

+

()
[#] Ответ на: комментарий от Karapuz 25.09.2011 12:06:57  
pitekantrop

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

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

*** ()
[#] Ответ на: комментарий от Karapuz 25.09.2011 12:06:57  

> Лисп опять проиграл скале в 1,1...8 раз > Пруф http://ff.im/-LRNeR

Сколько уже раз нужно, вам тупым, повторять, что Clojure - не лисп!

anonymous ()
[#] Ответ на: комментарий от lucentcode 26.09.2011 23:32:52  
pitekantrop

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

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

*** ()
[#] Ответ на: комментарий от anonymous 27.09.2011 10:30:20  
pitekantrop

> Сколько уже раз нужно, вам тупым, повторять, что Clojure - не лисп!

- Доктор, меня все игнорируют!!!

- Следующий.

*** ()
[#] Ответ на: комментарий от anonymous 26.09.2011 18:53:07  
>>-----Цитата---->>

Что не так?

<<-----Цитата----<<

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

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

>>-----Цитата---->>

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

<<-----Цитата----<<

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

* ()
[#] Ответ на: комментарий от Reset 26.09.2011 20:52:17  
Darkman

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

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

** ()
[#] Ответ на: комментарий от Darkman 27.09.2011 11:11:51  
Reset

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

***** ()
[#] Ответ на: комментарий от Reset 27.09.2011 11:14:32  
Darkman

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

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

** ()
[#] Ответ на: комментарий от Darkman 27.09.2011 11:33:12  
Reset

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

***** ()
[#] Ответ на: комментарий от pitekantrop 27.09.2011 10:35:46  

fuck off

anonymous ()
[#] Ответ на: комментарий от AVL2 25.09.2011 23:49:33  
Fice

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

http://clojure.org/rationale

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


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

** ()
[#] Ответ на: комментарий от anonymous 27.09.2011 12:36:41  

Эка антону попку порвало

anonymous ()
[#] Ответ на: комментарий от Fice 26.09.2011 12:39:24  

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

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

***** ()
[#] Ответ на: комментарий от dizza 27.09.2011 0:45:57  
lucentcode

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

** ()
[#] Ответ на: комментарий от pitekantrop 27.09.2011 10:31:44  
lucentcode

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

** ()
[#]  
unlog1c

Аналитики с ЛОРа такие аналитики.
> 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 27.09.2011 21:39:45  
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. Не верх функциональности, но чтобы посмотреть на язык хватит.

* ()
[#]  

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

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

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

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

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

*** ()