Анонсирован (http://groups.google.com/group/clojure/browse_thread/thread/...) релиз динамического языка программирования Clojure 1.4 (http://clojure.org/), базирующегося на языковых конструкциях Lisp и сочетающего в себе возможности функционального и многопоточного программирования с чертами современных скриптовых языков. Код программ на языке Clojure транслируется в Java байт-код и выполняется на виртуальной машине JVM. Код компилятора Clojure, библиотек и runtime-компонентов распространяется в рамках лицензии Eclipse Public License.
Новая версия отличается внесением (https://github.com/clojure/clojure/blob/master/changes.md) большой порции мелких улучшений и исправлений. Среди значительных новшеств отмечена возможность использования тегов для более ясного выделения определённых элементов структур данных и проверки соответствия типа. Добавлены литералы для определения времени, даты и UUID, что позволяет отождествлять теги со структурами данных типов. Представлен новый начинающийся с точки синтаксис обращения к полям записей и типов (например: "(defrecord Foo [x]) ;=> user.Foo (
.-x
(Foo. 10)) ;=> 10"). Проведена оптимизация производительности. Улучшена обработка ошибок, связанных с указанием некорректных символов в Unicode-строках.
URL: http://groups.google.com/group/clojure/browse_thread/thread/...
Новость: http://www.opennet.me/opennews/art.shtml?num=33640
Вот не понимаю, и все тут!>Код программ на языке Clojure транслируется в Java байт-код и выполняется на виртуальной машине JVM
Нафига? Зачем? Почему не писать сразу на жабе?
На лиспе писать интереснее.
Потому что жаба - многословная неудобочитаемая хреновина. Добровольно на ней писать далеко не каждый станет.
>многословнаясогласен
>неудобочитаемаякак раз наоборот, минимализм синтаксиса (который порой приводит к увеличению кода) как раз делает код простым и понятным. (При условии что это не индусский код)
Тогда велком в ассемблер.
Большой массив текста "замыливает" глаз и забивает память, читать становится довольно неудобно
Согласен, но моё мнение, что людей, которые не хотят писать на Lisp-подобном языке на порядок меньше. Хотя на самом функциональные штуки могут быть очень полезными.
> Согласен, но моё мнение, что людей, которые не хотят писать на Lisp-подобном
> языке на порядок меньше. Хотя на самом функциональные штуки могут быть
> очень полезными."не" вставил не туда ;-) Т.е. людей, которые хотят писать на Lisp-подобном языке единицы.
Это же не лисп. Там даже половину скобок убрали.
> Это же не лисп. Там даже половину скобок убрали.Если это и так, то их там ещё предостаточно осталось :-D
(defn lazy-seq-fibo
([]
(concat [0 1] (lazy-seq-fibo 0 1)))
([a b]
(let [n (+ a b)]
(lazy-seq
(cons n (lazy-seq-fibo b n))))))
Тоже согласен. Как по мне, идеально - когда язык даёт богатый синтаксис, как Scala, C# или D - тогда с первого взгляда уже по самой конфигурации строки видишь, что за конструкция и что, скорее всего, она делает. То есть если я вижу foreach, к примеру - я сразу знаю, где сомтреть его аргументы и что вообще будет происходить.
>> Нафига? Зачем? Почему не писать сразу на жабе?Почему не писать сразу в машкодах?
В машинных кодах писать долго и еще дольше отлаживать.
А здесь мы имеем все недостатки жабы без ее достоинств.
> В машинных кодах писать долго и еще дольше отлаживать.
> А здесь мы имеем все недостатки жабы без ее достоинств.А ПРИ ЧЕМ тут вообще жаба???
Речь о ВМ, о байткоде, о среде исполнения.
И о тысячал либ, написанных на жабе.
При том, что мы получаем не слишком высокую скорость и повышенный расход памяти, по сравнению с скомпилированным кодом. Это встроенные особенности JVM и Java-байткода. Для Java это компенсируется ясностью кода, продуманной архитектурой и множеством библиотек. А для этого?
И да, как всегда, когда человек выдумывает новый язык программирования, он не грабит, не убивает, не насилует и не пытается свергнуть правительство. И только.
> При том, что мы получаем не слишком высокую скоростьПо отношению к чему? По тестам скорость выполнения Java-байткода не так уж сильно уступает нативным программам, написанным на C++. При этом скорость написания, тестирования и отладки у Java программ раза в три выше, чем у "нативно-ориентированных" языков программирования.
> и повышенный расход памяти, по сравнению с скомпилированным кодом.
Что сравнивали? Писать надо уметь, и память не будет расходоваться!
> Это встроенные особенности JVM и Java-байткода.
JIT-среда, вообще говоря, требует для своей работы чуть больше памяти, чем готовая нативная программа. Это — цена, которую платят за преносимость (возможность работы без перекомпиляции из исходников), безопасность и скорость работы программ, запускаемых в ней.
> Для Java это компенсируется ясностью кода, продуманной архитектурой и множеством библиотек. А для этого?
Для использования всего этого богатства из Лиспа, а не переписывания.
> При этом скорость написания, тестирования и отладки у Java программ раза в три выше, чем у "нативно-ориентированных" языков программирования.и
> Это — цена, которую платят за преносимость (возможность работы без перекомпиляции из исходников), безопасность и скорость работы программ, запускаемых в ней.
Это все совершенно верно для чистой Java. Это именно те плюсы, которые полностью уравновешивают ее минусы.
Но здесь же не просто JVM используется, тут происходит компиляция в Java-байткод! Фактически они просто добавляют дополнительный костыль.Одним словом, пусть уберут свои грязные руки от нашей благородной жабы, под чьей шкуркой скрывается прекрасный принц. :)
> Но здесь же не просто JVM используется, тут происходит компиляция в Java-байткод
> Фактически они просто добавляют дополнительный костыль.Мусье наркоман? Использование JVM = запуск байткода на исполнение. А теперь следите за цепочкой: Java->ByteCode->JVM. Java компилится в байткод! Можно хоть C копилить в байткод и исполнять на JVM. Байткод JVM - это что то навроде ассемблера. Так что ваш пост имеет запах марихуаны.
Так... Попытаюсь объяснить на примере:
Предположим у Вас есть соковыжималка. И Вы делаете сок из яблок, апельсинов и прочего винограда. А теперь Вам захотелось березового сока... Стоит ли засовывать в соковыжималку полено?
Java НЕ компилируется в байткод. Байткод - это просто другое представление языка. Обратное декодирование восстанавливает исходный текст - попробуйте восстановите исходный код на С из программы. Выходит, что они просто переделывают свой лисп в яву а потом выполняют.
Да, и внезапно JVM расшифровывается как Java Virtual Machine.
»» Байткод - это просто другое представление языка????????????? :) :) :) :) :) :) :) :)Байткод — ЭТО ПРОСТО ДРУГОЕ ПРЕДСТАВЛЕНИЕ машкода :)
Вьі его немного недопоняли. Действительно скомпилированньій в байт-код Java код можно переконвертировать назад в Java код (сделать реверс инженирегн), даже читаемьій (имена локальньіх переменньіх будут утраченьі и де вьіглядеть наподобие a1, a2 и т.п.). Ето все не противоречит вами сказанного. Видемо имеллось ввитду если сделать "реверс инжениренг" откомпилированного кода clojure в код на Java, то алгоритм будет запутан очень.
Мусье, давайте я за вас погуглю:http://en.wikipedia.org/wiki/Java_virtual_machine
http://en.wikipedia.org/wiki/Java_bytecode
http://en.wikipedia.org/wiki/Java_compiler
http://docs.oracle.com/javase/1.4.2/docs/tooldocs/windows/ja...
Java - язык не интерпретируемый, она - язык компилируемый.
ЗЫ И да, завязывайте с тяжёлыми наркотиками, а то плохо кончите.
>> При том, что мы получаем не слишком высокую скорость
> По отношению к чему? По тестам скорость выполнения Java-байткода не так уж
> сильно уступает нативным программам, написанным на C++. При этом скорость написания,
> тестирования и отладки у Java программ раза в три выше, чем
> у "нативно-ориентированных" языков программирования.На том же Go/D пишется как минимум не медленнее и не хуже по надёжности, но что касается скорости выполнения - да, разница на многих задачах довольно мала.
>> и повышенный расход памяти, по сравнению с скомпилированным кодом.
> Что сравнивали? Писать надо уметь, и память не будет расходоваться!На шутауте давно были последний раз? По памяти с нативом любые JVM-программы в разы отличаются, если не на порядки
> При том, что мы получаем не слишком высокую скорость и повышенный расход памяти, по
> сравнению с скомпилированным кодомВы опоздали со своим комментарием лет на 5. Повышенный расход памяти уже мало кого волнует, ибо время программиста дороже, чем ещё одна планка на 4Gb. Ну и есть такая вещь как JIT.
*/me ущел гуглить туториал как вставить планку на 4Gb в HTC desire*
Читаем внимательно "...мало кого волнует..." - это значит, что в общем случае это так. Но таки есть области где да волнует, например встраиваемые системы.
И таких областей нынче вагон - потому что, с одной стороны, оператору "облака" вполне важно, сколько он сможет забить на одну физическую железку, с другой - таки куча мобильных устройств, где тоже памяти не вагон, да и батарейка ещё лимитирует. Впрочем, на десктопе у джавы всё совсем плохо - память она по требованию не отдаёт и запускается довольно долго, т.е. если шутрая утилита "на один раз" - тормозит при запуске, а если что-то долгоиграющее - жрёт память и не отдаёт даже если она уже не нужна.
А если все посадочные места заняты планками максимального размера? А если серверу уже лет пять и достать "правильную" планку - проблема, потому что у продавца, с которым договор, нет, и у дистрибьютора тоже, и вообще уже не выпускают, и разве что поискать, может у кого-то есть на складе, и при этом найдётся не 4GB, а только 2?
Если мы уперлись в предел вертикального масштабирования, то самое время сделать упор на мощь и выразительность языка и выполнить горизонтальное масштабирование :)
И уйти на Erlang VM ;-) А если серьёзно - то горизонтально далеко не всё удобно масштабировать.
Ладно, давайте посчитаем. Зарплата Java программиста в Астралии, Канаде и проч. странах развитого капитализма примерно 70-120К долларов в год. Для оптимизации нам нужно нанять ещё одного праграммиста на полную ставку. Сколько стоит хороший сервер? Явно меньше.ЗЫ Примеры России и Украины, где жабабыдлокодеры, не знающие, что такое байткод, работают за еду не приводить, ибо я не в России живу и мне строго пох на быдлопроблемы.
Да вот есть вопросы:
1) а сколько у нас серверов? Может дешевле орду программистов а оптимизацию посадить, и сэкономить на покупке железа, электричестве и прочих прелестях?
2) А что даёт именно жаба? Может какой-нибудь D/Go подошел бы лучше? Тогда и программисты лишние не понадобятся - писать на них проще, чем на жабе, и эффективность работы радует. Ограничением только наличие библиотек может быть, на самом деле.
3) Что мешает нанять программиста из России/Украины? Полно контор та делает, аутсорсинг называется. Результаты обычно вполне хороши.
1. Железо всё равно дешевле человека. Поэтому во многих областях и заменяют людей высокой квалификации автоматикой (те же автопилоты например).
2. Такие платформы как .NET и Java дают неплохую скорость разработки при приемлемом качестве кода и накладных расходах. Да они медленнее нативного кода, но в общем случае это не критично, это же всё таки не Питон.
3. А нафига фирме в Канаде нанимать Васю Пупкина через океан? Где он там сидит и что делает хрен его не знает. Кому эти риски нужны?
Учите матчасть.
>Java НЕ компилируется в байткод.Java таки компилируется в байт-код.
>Для Java это компенсируется ясностью кода, продуманной архитектурой и множеством библиотек. А для этого?
Что угодно скомпилированное в байт-код имеет доступ ко всем Java-библиотекам. Clojure - не исключение.
>Что угодно скомпилированное в байт-код имеет доступ ко всем Java-библиотекамДа, но, как правило, через анус и при помощи костылей.
>Clojure - не исключение.
"Никогда, ты слышишь, НИКОГДА не говори о том, чего не знаешь." (с)
Убогий костыль. Пока у языка нет своих библиотек и он использует Java-либы, любой код на нем будет выглядеть как Java с приподвывихнутым синтаксисом. Поэтому например код на окамле выглядит как окамл, а на F# - как сишарп. А так как свои библиотеки писать никто не будет(нафига? Взять готовые проще, хоть и не очень удобно), то любые попытки писать новые языки под JVM/. NET обречены на провал. Более-менее успешны могут быть лишь порты уже устоявшихся языков с сильным комьюнити, как, например, JRuby. Смирись с этим.
> Убогий костыль. Пока у языка нет своих библиотек и он использует Java-либы,
> любой код на нем будет выглядеть как Java с приподвывихнутым синтаксисом.
> Поэтому например код на окамле выглядит как окамл, а на F#
> - как сишарп. А так как свои библиотеки писать
> никто не будет(нафига? Взять готовые проще, хоть и не очень удобно),
> то любые попытки писать новые языки под JVM/. NET обречены на
> провал. Более-менее успешны могут быть лишь порты уже устоявшихся языков с
> сильным комьюнити, как, например, JRuby. Смирись с этим.clojure - замечательный язык, и чем меньше людей это понимают, тем больше денег мы заработаем ;)
Платят не за понты, а за востребованность.
Платят за решение проблем. На чём - клиента не волнует. С точки хрения наёмного программиста это, конечно, не так.
Не так уж редко хорошо платят как раз за понты и UI с большим количеством свистоперделок.