Clojure 1.0

> Ну мало-ли... Если им денег девать некуда то можно и этим занятся.

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

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

А я и не говорю, что человек с улицы убер биллинг писать должен. Есть же конторы, которые по данной тематике специализируются (Amdocs, какой-нибудь).

>> Эээ... А Что ? :-)

А что получится :))

>> А я и не говорю, что человек с улицы убер биллинг писать должен. Есть же конторы, которые по данной тематике специализируются (Amdocs, какой-нибудь).

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

> Даешь scheme на mono!

Автор Clojure до этого писал dotLisp для дотнета, кстати. Ещё сам Clojure какой-то сторонний человек пишет для дотнета, зовётся ClojureCLR.

>И не юникс он хотел написать...

Lol. А windows что-ли? Minix, говоришь?

>There is no tail-call optimization, use recur.

А в Scala асилили.

> Знания С, С++ и Ява хватает на все случаи жизни. Плюс Пролог - и можно отрулить...

Ну, ещё Фортран 2008/Алгол 68/Модула/Ада для публикации алгоритмов, ибо всё приведённое выше для этого непригодно из-за нечитаемости.

>> Эээ... А Что ? :-)

> А что получится :))

А могло получиться что-либо меньшее, чем Linux, a ???

>Ограничения java очень мешает тем, кто занимает автоматической кодогенерацией. Максимально возможный теоретический размер метода 65534 байт.

OMG. Виталик вылез. Давно тебя не видели, Mauhuur, welcome back as always

>Прогрессом движет лень, и между прочим, она тоже идеология. А трезвый расчет

Лень это как раз трезвый расчет, а ни разу не идеалогия. В идеалогиях лени места нет, еще раз, если бы жили по идеалогии, ты бы сейчас поворачивал вспять Енисей и мерз по ночам в вагончике, а не ленился бы возле ЖК монитора

>> А я и не говорю, что человек с улицы убер биллинг писать должен.

Ну биллинг это цветочки, да и потом не каждому банку он нужен. Представь себе масштаб, хотя бы объемом терминальной сети, у крупного банка она может достигать деястка, а то и нескольких десятков тысяч терминалов, один фронт-офис банка с модемным пулом размером я-ля интернет провайдер чего стоит. Плюс к этому база бэк-офиса в несколько сотен терабайт транзакционной информации. И по всему этому добру нужно обеспечить в реалтайме как прохождение 200-300 транзакций в секунду, так еще и постоянную выгрузку отчетности, сверки, зарытия опер-дня, загрузку данных из всяких АБС, плюс нагрузка на криптографическое оборудование (с теми же 200-300 транзакциями в секунду + еще дохрена чего), круглосуточная персонализация карт и тд и тп и все в одном флаконе. Разработка такго софта стоит немеряных денег.

>Поэтому не получится реализовать машину состояний в виде одного большого case.

Тысячи вариаций в одном case? Это что-то в алгоритме править надо. Я бы банальный HashMap, наверное, заюзал :) Как минимум - быстрее бы вышло. Не говоря уже про то, что проще и нагляднее.

> Ну, ещё Фортран 2008/Алгол 68/Модула/Ада для публикации алгоритмов, ибо всё приведённое выше...

Могёт быть, что овечалось выше, не затруднит прочесть? :-) Правда, сиё на предыдущей странице. Ну, да ладно... ;-))

>> А могло получиться что-либо меньшее, чем Linux, a ???

Как бы мог получится совсем не линукс, а нечто POSIX-образное с налетом "Operating Systems: Design and Implementation", ну что-то в этом роде и поучилось, кстати: http://www.kernel.org/pub/linux/kernel/v1.0/linux-1.0.tar.bz2

> Разработка такго софта стоит немеряных денег.

Экспоненциально неприятно будет, когда в таком софте возникнет дедлок из-за ошибки программиста :)

> ...ну что-то в этом роде и поучилось...

Ведь всё-таки получилась, а? Да, сейчас пошёл по ссылке... Много там интересно, а местами - просто глуповато. Но и интересно - то же...

> OMG. Виталик вылез. Давно тебя не видели, Mauhuur, welcome back as always

Я не знаю кто такой Виталик. Возможно Вы с ним о чем-то спорили и спор не закончили, а теперь видите его за каждым ником? Рекомендую найти Виталика и спор закончить.

> Какие особенности нужно знать в Си, чтобы там появилась STM?

Нужно пойти и скачать интелловский компилятор STM C++, недавно вот постил новость.

Нет, я как-то и не задумывался, что ядрышко таковенный путь проделало...(Был знаком только с версии 2.0.2) Нет, слава Линусу!!! :-)

> Нужно пойти и скачать интелловский компилятор STM C++, недавно вот постил новость.

И чего с интеловским компилятором делать на s390, power, sparc? :)

> ...Рекомендую найти Виталика и спор закончить...

Ради Бога, только без кровопролития... :-)

> И чего с интеловским компилятором делать на s390, power, sparc? :)

Горько плакать по поводу своего железа, дающего мало SPEC int за слишком большие деньги.

А если серьезно, то вопрос (и ответ) был про языки.

>>>паралелизм

>>Угу...

>Это где ты там паралелизм надыбал? Я это слово правильно писал еще когда ты под стол пешком ходил

В шапку глянь

>>Поэтому не получится реализовать машину состояний в виде одного большого case.

>Тысячи вариаций в одном case? Это что-то в алгоритме править надо. Я бы банальный HashMap, наверное, заюзал :) Как минимум - быстрее бы вышло. Не говоря уже про то, что проще и нагляднее.

+1024

Джошуа Кериевски показал как заменить бльшущий Switch на Map (хэштаблицу) обработчиков (образей проектирования Command). "Селектор" в этом случае может быть строчным. В результате специализированный код сосредоточился внутри обработчиков "селектора", а код выбора сократился с нескольких десятков строк до двух.

Интересно почему JVM а скажем не Parrot?

>Интересно почему JVM а скажем не Parrot?

Потому что нужна интероперабельность с jre. А в парроте с чем интероперабелится?

>> Нет, я как-то и не задумывался, что ядрышко таковенный путь проделало...(Был знаком только с версии 2.0.2) Нет, слава Линусу!!! :-)

Тут не только ему слава, хотя он командует разработкой, большая часть кода в современном ядре написана не им :)

> Горько плакать по поводу своего железа, дающего мало SPEC int за слишком большие деньги.

Думаешь, владельцы Бентли горько плачут по поводу своих машин, дающих слишком мало лошадей за слишком большие деньги? Как же так - заплатили в 200 раз больше, чем за автотаз, а мощность всего в 4-5 раз больше?

Не могу понять зачем еще один язык, когда уже есть Common Lisp? Ну или на худой конец Scheme. Не проще ли написать библиотеку под Common Lisp для работы с джавой, если так уж нужно использовать библитеки джавы?

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

Перл, Питон, Руби и куча других языков

Самое смешное что основной причиной критики Лиспа было наличие там сборщика мусора. Для 80х это казалось бессмысленным расточительством ресурсов

и как руби работает под парротом? Уже не ликает память, как натив? ;)

>Самое смешное что основной причиной критики Лиспа было наличие там сборщика мусора.

Забавно то, что на больших и сложных программах Лисп может конкурировать с С++, С в плане производительности, насколько я знаю из некоторых бенчмарков. Причина банальна - человеческие мозги не очень хорошо справляются с поддержкой и реализацией огромных программ. В результате автоматическая сборка мусора оказывается пригодной для больших программ.

> Знания С, С++ и Ява хватает на все случаи жизни

мощно... ну и жизнь у тебя..

> Не могу понять зачем еще один язык, когда уже есть Common Lisp?
Некоторое время назад тут один человек здорово ругал _реализации_ (а не идею) Common Lisp. Насколько я знаю, сабж, постарался убрать многие недостатки, которые упоминал тот товарищь.

> just for lulz

Да смех уж больно странный получается...

>Некоторое время назад тут один человек здорово ругал _реализации_ (а не идею) Common Lisp.

А что за недостатки? Я не разбирался в общем-то, но кажется, что Clojure делает акцент на функциональном стиле. Если хвостовая рекурсия не оптимизируется, то это уже ни в какие ворота. Кроме того, я думаю, что в практическом смысле функциональным программированием рано заниматься. Зато в Common Lisp есть система макросов (причем двух типов), позволяющая писать эффективный код. Кроме того, для разных имплементаций Common Lisp есть поддержка в emacs через slime. Мне вот eclipse совершенно не нравиться, хоть по работе и вынужден сидеть в этой среде.

> А что за недостатки?
Поищи за этот год поиском. Он еще с mv спорил на эту тему.

> Если хвостовая рекурсия не оптимизируется, то это уже ни в какие ворота.
Так JVM не определяет хвостовой вызов. А без ее поддержки придется таскать рантайм языка. Тот же Common Lisp тоже не гарантирует поддержки.

> Зато в Common Lisp есть система макросов
Она много где есть. В сабже в том числе.

> Кроме того, для разных имплементаций Common Lisp есть поддержка в emacs через slime

И для сабжа тоже есть

>В сабже в том числе.

Да. Есть. Согласен.

>Она много где есть.

Вне систем Лиспа такой нет, насколько я знаю.

>Так JVM не определяет хвостовой вызов. А без ее поддержки придется таскать рантайм языка.

а зачем в JVM? Компилятор должен. Отсутствие обработки данного типа рекурсии - серьезный недостаток. ИМХО.

Библиотеки джавы - стоят сотни тысяч человеко-часов очень хороших программистов. Это оплачено теми, кто пользует явку в реальном энтепрайзе. У лисперов таких ресурсов никогда не было, поэтому ситуация с библиотеками очень плохая.

Даже биндинга к QT до сих пор не сделали, это уже симптом.

ЗЫ про smoke я знаю.

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

И как компилятор определит нужно ли делать хвостовой вызов в этом случае (define (a b c) (b (something c))) ?

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

Есть более другое мнение: "Тормоза явы обеспечены не JIT, а «качеством» стандартных и сторонних библиотек. Большинство из них писаны студентами за еду. Оттуда и результаты: декодер MPEG2 на яве работает с такой же скоростью что и сишный, а среднее GUI-приложение полчаса стартует, уродски выглядит и неработоспособно через терминал (т.к. само растериризует графику, забивая этим канал)"

>И как компилятор определит нужно ли делать хвостовой вызов в этом случае (define (a b c) (b (something c))) ?

А где здесь рекурсия?

>Перл, Питон, Руби и куча других языков

Ага. Интегрироваться с нетипизированным рантаймом - это сказка. Все функции принимают 'обжект' и возвращают 'обжект'.

Не в рекурсии дело. У нас тут b неизвестно, это аргумент функции, который сам может являться функцией или методом. И имеет место быть хвостовой вызов, который, может стать рекурсивным, если b где-то вызывает a.

> Как же так - заплатили в 200 раз больше, чем за автотаз, а мощность всего в 4-5 раз больше?

То ли вы тазики берёте через дыру в заборе завода, то ли цену на бентли видели на аукционе в 1989.

Честно говоря, даже не в курсе, сколько сейчас оба стоят :) Так, примерно прикинул.