Хоччччччччччччччччу

[balu]

Я всегда неровно дышал ко всяким там LISP-ам. К сожалению это не самое популярное семейство языков. В связи с этим с библиотеками как бы напряг. Но недавно появился язык программирования Clojure, который является динамически типизируемым и компилируемым языком общего назначения для JVM и CLR. На НГ автор языка решил сделать подарок и выпустил новую версию. Теперь кроме прочего там есть поддержка примитивных массивов, chunked-последовательности, futures, предназначенные для асинхронных вычислений, promises для обмена данными между тредами, pre- и post условия для функций, продолжения (futures) и много другого
Из свободно распространяемых обучалок есть порт PCL на Clojure и скринкасты про новые возможности.
И вот нашлись 2 очччччччень интересные книжки по этой тематике:
Clojure in Action

и только что анонсированная The Joy of Clojure. Но самая интересная для меня оказалась вот эта красота:

Вот теперь и трясусь - и от того, что жаба, и от того, что некогда... Но, наверное, до лета я на 28 баксов расколюсь. Эх... жалко НГ закончился

Comments

[roman_sharp.livejournal.com]

Вообще мой идеал - даже нечто универсальное, способное компилиться в "родные" исполняемые, без необходимости таскать за собой икс-VM, "коробка", возможность создания как командной строки, так и ГУИ.

Как один из вариантов, xornot предложил QT Creator с IDE и прочими наворотами.

[b-al-u.livejournal.com]

Вообще мой идеал - даже нечто универсальное, способное компилиться в "родные" исполняемые,

Значит ты пока не пришел к необходимости ВМ. Снимает массу головной боли натива и легаси.

QT Creator

QT Creator - это С++ со всеми его подлыми минусами.

[roman_sharp.livejournal.com]

Я понимаю, что снимает - с одной стороны, но с другой - утяжеляет для конечного пользователя. tradeoff. Кроме того, у меня большие, такие большие сомнения, что command line через VM эффективнее работает. Хотя ХЗ.

QT Creator - это С++ со всеми его подлыми минусами.

Да у всего минусы, с какого боку не глянь. "Инфраструктура" - под "старые" языки, новые обещают удобство и крутизну - но под них инфраструктуры нет и неизвестно, будет ли, вдруг так и закуклятся в какой-то нише...

Вот так и мечешься.

[b-al-u.livejournal.com]

Кроме того, у меня большие, такие большие сомнения, что command line через VM эффективнее работает.
Конечно, т.к. неизбежны затраты на старт ВМ.

но под них инфраструктуры нет и неизвестно, будет ли,

Так в том и плюс ВМ, что позволяют вести разработку в многоязыковой среде. Когда старые языки превратятся в помеху, можно продолжить на новых в пределах одной экосистемы. Или наоборот, выбрать язык, который лучше на задачу ложится. Поскольку они все работают в пределах одной экосистемы они прозрачны друг для друга вплоть до вызова функций.

Хотя очень много зависит от типа задачи, т.к. универсальных инструментов не бывает. Где-то лучше классический Юникс Вей, где-то ВМ. Хотя они прекрасно стыкуются вместе.

[roman_sharp.livejournal.com]

2) Юникс вэю не достает понимания удобства и нужности ГУИ для пользователя. Я сначала долго не мог понять, почему каптча так мучает моих читателей и не мучает меня. Потом дошло: они ж слепой английской раскладки, в отличие от меня, не знают.

1) Ну вот это одна из причин, по которой я склоняюсь к Джаве. Ты там Джитон какой-то вспоминал, и другие компиляции в Джаву.

[b-al-u.livejournal.com]

2) Юникс вэю не достает понимания удобства и нужности ГУИ для пользователя.

далеко не всегда. для решения задачи нужон гуй. Есть чисто гуевые задачи, никто не спорит. А вот функционал туда дергать ч-з ЮВ вполне нормальное решение.

Мне, кстати капча тоже проблема. Я часто не могу разобрать ее... Наверное я бот.

Ты там Джитон какой-то вспоминал, и другие компиляции в Джаву.

С жабой мы страдаем от:
1) ВМ Жабы заточена только под один довольно таки ублюдочный язык - жабу.
2) Отсутствия хвостовой рекурсии, каждый вызов по определению потребляет стек.
3) Тормозной и неправильный GC. При ровно той же семантике VM можно было сделать лучше. Жабский GC не приспособлен к ситуации, когда огромное количество мелких объектиков выделяется и сразу же теряет актуальность.
4) Отсутствие чего либо аналогичного .NET-овским делегатам. Для такой простой (и часто нужной) вещи, как передать указатель на метод, требуется плодить отдельный класс. При традиционном подходе к программированию на самой Жабке - не проблема, при реализации других языков - геморрой.
5) Сам язык Жаба: отсутствие замыканий, отсутствие даже минимальных возможностей метапрограммирования, отсутствие нормальных и удобных контейнеров (ну что мешало сделать для списков и хэш-таблиц синтаксический сахар, чем они хуже массивов?), анонимных функций, нормальных генериков. Если все эти претензии разрешить, то Жаба зарулит нипадеццки. А пока, когда есть возможность выбора инструмента для очередного языка, я или натив сразу делал бы, или .NET. Сейчас ситуация чуть получше стала, можно и попробовать, тем более, что все интересные мне языки можно запустить не только под жабу, а и под дотнет.
В частности Житон генерит крайне неэффективный байткод, в отличие от дотнетовского варианта. Хорошие реализации для жабы - это Scala и Clojure. Но это исключения больше. Есть еще JRuby, но он тормоз, как и Jython.