Scala vs Clojure - чья возьмет?

> сильная нига groovy - это grails, вон недавно SAP выпустил Composition on Grails 1.0

Grails - это который на Spring, что начинает по-тихоньку закрываться от сообщества? А composition, это который "It is not a supported SAP product" на главной странице.

В SAP работает много людей и что они только на нетвивере не запускали - и Rails, и Grails... Но пока что ни одного "громкого" применения Groovy/Grails нет.

>Spring, что начинает по-тихоньку закрываться от сообщества?

сорцов никто закрывать не собирается

>А composition, это который "It is not a supported SAP product" на главной странице.

ну оно пока что вообще "under test and evaluation terms only."

>Но пока что ни одного "громкого" применения Groovy/Grails нет.

http://graemerocher.blogspot.com/2008/10/skycom-relaunches-written-in-grails.... - достаточно громко?

> достаточно громко?

2 октября) как раз к нашему разговору подоспели. Да, неплохо.

> сорцов никто закрывать не собирается

Ну тенденция то всё равно не хорошая наметилась.

Как я понял всё это абстракция над Spring MVC, да?. Из очевидных косяков после посещения их сайта:

1) GORM - Hibernate only => надо JPA.
2) Ant... => Maven + архетип для создания модуля в уже существующий проект, и как там кстати с интеграцией в уже существующий контекст?
3) Завязка на Spring => это точно не next-gen _jee_
4) GSP - гораздо круче jsp, но есть куда более интересные wicket&gwt

Вывод: cmf/web абстракция для Spring. Хотя судя по Grails Roadmap "Maybe provide a new plugin that can: Create a standard Spring MVC application without the rest of Grails" - Spring MVC итак облегчился.

Кстати, что у Grails c IDE? Автокомплишн к примеру подскажет мне, что надо написать dbCreate, "create-drop"?

environments {
  development {
    dataSource {
      dbCreate = "create-drop" // one of 'create', 'create-drop','update'
      url = "jdbc:hsqldb:mem:devDB"
    }
  }
... (from grails quickstart)

>Внимание ответ: потому что счетчики количества ответов меняются от рефреша к рефрешу, и желательно отдавать клиенту акутальное количество иначе клиент будет расстроен и сделает свой ЛОР, с бэкджеком и т.п.

Бред по трем причинам:
1. Они не меняются от рефреша к рефрешу - просмотров на порядки больше чем модификаций,

2. кто мешает обновлять эти счетчики в памяти?

3. где вообще связь между счетчиком и количеством ответов? Это оптимизация чтобы не делать лишний каунт? Так эта оптимизацыя нужна только потому что модель такая где каунт дорогой. В случае модели в памячти кауунт - мгновенный и занимает вызов метода проверки длины списка.

>кто-то неосилил настроить кэш в хибернейте?

Кэш в гибернейте ничем не лучше.

> где вообще связь между счетчиком и количеством ответов? Это оптимизация чтобы не делать лишний каунт? Так эта оптимизацыя нужна только потому что модель такая где каунт дорогой. В случае модели в памячти кауунт - мгновенный и занимает вызов метода проверки длины списка.

Пример хороший, дабы попытаться его разложить на косточки.

1. Сама по себе новостная лента (без счетчиков) есть чистая функция от таблицы "новости", поэтому фреймворк/язык мог бы кэшировать ее значения, имей она атрибут pure.

2. С каунтерами:

class NewsItem { Url url; Date date; String text; int numberOfReplies(Table replies); };

и опять numberOfReplies будет чистой функцией пары таблиц "новости" и "реплики".

* int numberOfReplies();

>>Вообще, модель <я единственный в мире, вот только иногда где-то кто-то изредка со мной конфликтует, тогда я защищаюсь мьютексом> мне нравится гораздо больше,

>VisualBasic ? А мне тоже больше гораздо нравится модель <кинул на форму грид кинул ищо адин кинул группу радиобаттонов написал пару обработчиков событий пошел домой пивко попить. завтра продолжу увлекательное занятие программирование>

Кидание на форму виджетов -- это оффтопик.

Вот возьмем форум ЛОРа как пример проги на яве. Тут модель "я единственный в мире" очень даже катит, ибо:

1. у каждой мессаги есть владелец
2. даже если бы мессаги можно было редактировать владельцу и модеру, то столкновенеие двух редакторов маловероятно
3. если же его хочется таки избегать, надо вводить явное понятие лока или ЯВНОЕ понятие копии

> В случае модели в памячти кауунт - мгновенный и занимает вызов метода проверки длины списка.

В случае нормального индекса этот каунт берется из индекса, что опять не дорого.

Вово. А на практике даже в таким вещак как сайт с 99.999% иммутабельных данных фактически все реализовано через явные копии.

Держать *все* ответы в памяти тяжело, но все счетчики ответов -- можно -- но как это красиво записать?

их можно держать по политике on-demand вытесняемого кэша. при чем подоный кэш в состоянии расказывать администратору что мол "шеф нагрузка возросла - пямяти дай а - а я тебе скорости дам". То есть по сути модель поведения - а-ля свап памяти.

> Аргументы? А это http://lambda-the-ultimate.org/classic/message10106.html ?

Ф.В.П. и ленивые вычисления полезны, но когда требуют копировать-все-подряд-лишь-бы-раз-в-год-вызвать-ФВП, то это перебор.

Впрочем, может я неправильно понял иделогию -- тогда сходи на http://clojure.org/state и объясни мне мои ошибки на примерах.

1) хм, кому надо и зачем?
2) мавен оно специально не юзает, ибо grails create-app куда проще чем три строчки непонятных буков создания мавеновоского проекта. Внешняя интеграция кода обеспечивается средствами spring'а, сборки - gant(ant).
3) завязок на спринг так не так много. а какие есть альтернативы-то?
4) ну, gwt - это совсем другое.. wicket - ну не знаю... да и интегрится это плагинами достаточно просто, насколько я знаю.

"create-drop" не подскажет скорее всего, но очень много других штук JetGroovy уже умеет.

1) Ну во-первых не хибернейтом единым - вон на последнем проекте OpenJPA использовали, показал себя быстрее Hibernate в некоторых вещах. Всё же в BEA хорошие программисты были. 2) "три строчки непонятных буков создания мавеновоского проекта" - после этого захотелось перестать дальше отвечать. Ant is dead, особенно на крупных проектах, состоящих из тучи модулей с зависимостями. Maven это не только и не сколько "три непонятных строчки буков" для создания проекта - почитайте книжки. 3) Ну я в общем говорю - есть стандарты: JPA, JSF и если называться next gen jee, то надо в первую очередь их поддерживать. 4) То, что подключить это к грельсам теоретически можно - это ясно.

Я к тому что радикально нового Grails не несёт. Ну упрощает он какие-то вещи, в эпоху Spring без аннотаций и XML-конфигов Hibernate это было актуально. Сейчас - не особо, уж лучше type safe & performance. Хотя для веб-сайтов и интерфейсов, где надо fast&dirty думаю вполне подойдёт.

JetGroovy надо будет глянуть, а под Eclipse у них есть плагин?

1) тем не менее вы признаёте, что хибернейт весьма и весьма неплох, не так ли?
2) ну, зачем нужен мавен я представляю. Вот, кстати, оригинал автора про "многострочек". Там же есть ссылка на Maven Tools for Grails, так что если хочется - то можно юзать и maven.
3) ну если насчёт JPA можно согласиться, то вот насчёт jsf - не очень.

hibernate & typesafe - хм.. да и насчёт перфоманса вопрос спорный - для тяжёлых расчётов код всегда можно в java-класс положить, а для логики groovy с его возможнстями весьма подходит, как мне кажется.

зы очень короткий пример: для отображения полного списка айтемов(с сортировкой и пейджингом) в контроллере по сути идёт одна строка кода - это Item.list(params). А сколько нужно будет в wicket/jsf/gwt+OpenJPA/Hibernate, а?

>JetGroovy надо будет глянуть, а под Eclipse у них есть плагин?

да, его они вроде как даже сами пишут

>Да обоих в биореактор, вот и весь сказ. Вместе с жабой, жвм и прочим хламом.

Дапайте отправи в биоректор все ..java, python, lisp, perl, php, с++ и т.п... оставим древний универсальный ясык С и будем на нем делать все современные приложеения для всех областей .. задача теоретически вполне выполнимая, но вопрос зачем?? .. ЗАЧЕМ отправлять в биоеректор все что вам ЛИЧНО не нужно или вы не ПОНИМАЕТЕ зачем это нужно

> тем не менее вы признаёте, что хибернейт весьма и весьма неплох, не так ли?

И что с того? Я да, другие - нет.

> ну, зачем нужен мавен я представляю.

Видно ссылка не вставилась у вас, правда по гуглу нашлась. Теперь я понял, что и создатель Grails не догоняет в чём суть мейвена). Ему даже в комментариях к посту написали, что вместо 4 строчек может быть просто "mvn grails:create-app name", а lift-овский пример ещё скачает и установит нужную версию lift.

> hibernate & typesafe - хм.. да и насчёт перфоманса вопрос спорный - для тяжёлых расчётов код всегда можно в java-класс положить, а для логики groovy с его возможнстями весьма подходит, как мне кажется.

Я не знаю, что вы понимаете под рассчётами и логикой - поэтому затрудняюсь ответить. Половина сайтов в интернете берёт данные от пользователя и кладёт их в базу, потом выводит с "сортировкой и пейджингом" для них это "логика".

> зы очень короткий пример: для отображения полного списка айтемов(с сортировкой и пейджингом) в контроллере по сути идёт одна строка кода - это Item.list(params). А сколько нужно будет в wicket/jsf/gwt+OpenJPA/Hibernate, а?

Такие примеры напоминают мне рубистов со своими блоками, где одна строчка завоёвывает мир. А в ASP.NET перетащить мышкой грид-компонент ещё быстрее и он будет в 5 раз функциональнее Grails. И что теперь? В Spring MVC есть ModelMap - тоже нечто похожее.

Grails по-моему не сильно позже Rails появились, только вот с распространением у них ещё хуже дела обстоят - один Sky.com за 4 года это маловато. Я лично не вижу ни одной причины, чтобы они вдруг набрали популярность. Сейчас с аннотациями и логику писать просто и базы мапить, раньше у них может и был шанс.

>И что с того? Я да, другие - нет.
"на заборе..." я к тому, что альтернатив hibernate'у не так уж и много.

>Я не знаю, что вы понимаете под рассчётами и логикой - поэтому затрудняюсь ответить. Половина сайтов в интернете берёт данные от пользователя и кладёт их в базу, потом выводит с "сортировкой и пейджингом" для них это "логика".

да, я это под логикой и подразумеваю. и имхо всё скорее упрётся тут в быстродействие БД, чем в скорость groovy/grails.

>И что теперь?
когда одной строчкой можно сделать то, что делается Hibernate'ом в 5-10 - это, я считаю, однозначный плюс, но главное-то это то, что всегда можно "откатиться" к хибернейту\спрингу и сделать всё руками. Да и потом, вы ж против спринга были, кажется?

>Grails по-моему не сильно позже Rails появились, только вот с распространением у них ещё хуже дела обстоят - один Sky.com за 4 года это маловато.

1.0 релиз был всего полгода назад. Релиз 0.1 - в 2006. 1.0 релиз рельсов был в 2005, 0.5 - в 2004. На лоре снова запустили машину времени? 0_о
sky.com частично на грельсах был уже давно написан, кстати.
список сайтов на грельсах есть тут: http://grails.org/Success+Stories

>Сейчас с аннотациями и логику писать просто и базы мапить, раньше у них может и был шанс.

ну про одну строчку кода я уже выше написал. опять же в грельсах даже аннотаций не надо. скажем так: да, спринг+хибернейт умеет большУю часть grails, однако grails гораздо проще в настройке и использовании, при этом вся гибкость H/S остаётся доступной, как и, собственно, все фичи и плюсы java-платформы(это камень в огород рельсов, хехехе)

Знаете, ощущение, что вы в Grails пришли с Ruby/PHP только потому что это JAVA => ынтерпрайзно. То, что логикой для вас осталось вытягивание данных из БД явное тому подтверждение.

Такие сайты что в списке историй успеха абсолюно пофиг на чём делать - PHP, Ruby, Python, Groovy: разницы _никакой_. И если вы не понимаете, зачем вместо 1 строчки писать 10, то я думаю вы так же слабо себе представляете, зачем использовать Grails вместо Rails.

>Такие сайты что в списке историй успеха абсолюно пофиг на чём делать - PHP, Ruby, Python, Groovy: разницы _никакой_.

Требую, реквестирую переписать www.linux.org.ru на грельсах, если разницы нет никакой.

>И если вы не понимаете, зачем вместо 1 строчки писать 10,

Зачем же?

>то я думаю вы так же слабо себе представляете, зачем использовать Grails вместо Rails.*

Зачем же?

>ощущение, что вы в Grails пришли с Ruby/PHP
слава богу, на ruby/php не писал и не собираюсь

>разницы _никакой_
а не затруднит ли вас привести десяток сайтов, которых нельзя сделать на grails?

>И если вы не понимаете, зачем вместо 1 строчки писать 10
представьте себе, я действительно не понимаю зачем писать руками десять строк кода на spring+hibernate, когда одна строка на grails в итоге превратится в те же самые 10.

>зачем использовать Grails вместо Rails.
даже если оставить в стороне разные "ынтерпрайзные" фичи j2ee у рельсов есть как минимум несколько серьёзных проблем - mogrel, многопоточность, sql-драйвера итд

> Требую, реквестирую переписать www.linux.org.ru на грельсах, если разницы нет никакой. Зачем переписывать то, что уже работает? PHP занял довольно плотно рынок веба: все 2.0 сервисы на нём, куча программистов, удобен в деплойменте, друпал, вордпресс и прочие готовые продукты. Ruby, Python, Groovy сколько не пыжаться - всё равно не догонят.

Хотя я лично питон активно использую и в простых сайтах на django и скриптах. Кстати, кто-нибудь в курсе как 2.6 с tkinter'ом на osx завести?

> Зачем же? Почитайте про коллекции в Java: сколько они занимают памяти, какая скорость доступа к элементам. Хотя для сайтов, где всё кешируется и обновляется раз в минуту - это действительно не принципиально, никто не спорит.

> Зачем же? Ну разве что learning curve для java-разработчиков меньше. Но тут и область применения скромнее по сравнению с ruby/python.

>PHP занял довольно плотно рынок веба: все 2.0 сервисы на нём, удобен в деплойменте, друпал, вордпресс и прочие готовые продукты.

спасибо, поржал :D

>а не затруднит ли вас привести десяток сайтов, которых нельзя сделать на grails? Да сайт можно сделать хот на ассемблере. Другое дело, что для PHP есть куча готовых решений и фрилансеров. А с Grails даже не ясно куда обратиться, на том же grailscrowd из россии 2 человека.

>представьте себе, я действительно не понимаю зачем писать руками десять строк кода на spring+hibernate, когда одна строка на grails в итоге превратится в те же самые 10. Превратиться это если использовать LOP & Generative Programming. Я хоть и с Jython одно время работал, но о магии внутри динамики на JVM представление имею.

>даже если оставить в стороне разные "ынтерпрайзные" фичи j2ee у рельсов есть как минимум несколько серьёзных проблем - mogrel, многопоточность, sql-драйвера итд монгрели там уже никто не пользует - есть mod_passenger, deployment не сложнее PHP. в остальном - JRuby.

>есть mod_passenger
это только подтверждение того, что проблем у рельсов хоть отбаляй. Судя по сайту, кстати, оно(mod_rails) ещё бета.

>deployment не сложнее PHP. в остальном - JRuby.
я как бы про деплоймент ничего не говорил даже. у JRuby проблем тоже хватает, кстати.

>Превратиться это если использовать LOP & Generative Programming. Я хоть и с Jython одно время работал, но о магии внутри динамики на JVM представление имею.
честно говоря, вашего комментария не понял.

> Другое дело, что для PHP есть куча готовых решений и фрилансеров. А с Grails даже не ясно куда обратиться, на том же grailscrowd из россии 2 человека.
а никто и не отрицает, что "специалистов" и "готовых решений" на php на порядки больше, чем на groovy. Однако слова groovy/grails всё чаще встречаются в вакансиях, это раз, и для специалиста по S/H осилить groovy/grails не составляет особых сложностей.

ждем ебилдов ;)

>Почитайте про коллекции в Java: сколько они занимают памяти, какая скорость доступа к элементам.

Что с ними не так? Какая там скорость, неужели быстрее, чем у PHP? Йа не удивлюсь

вместе с F# ;-)

> Ведь не даром Луговски убеждал нас 5 лет подряд, что ФП рулит, не?

то, что микрософт втягивает кучу подходов из ФЯ в C#, а также то, что F# войдет в следующую студию - вполне себе подтверждает это :-)

> Спецы делают на том, на чем нужно заказчику.

Заказчику нужно, чтоб работало. Заказчику плевать, на чем это сделано.

> И всеравно на чем, так как владеют разными средствами одинаково хорошо.

Это невозможно, дебил. Как бы хорошо ты ни владел молотком, а вырыть канаву всё же быстрее лопатой. А ещё быстрее - таджиком с лопатой. Так что инструмент надо выбирать под задачу, как бы не визжали об обратном особо убогие, не осилившие достаточно широкого диапазона инструментов.

Они там на иммутабельности настаивают из эгоистичных побуждений - так им проще concurrency изобразить. Слабаки. Путь, по которому пошли разработчики Erlang, гораздо прямее и понятнее. Нельзя функциональщину принимать слишком уж буквально, она как алкоголь - полезна малыми дозами (в любых количествах).

> А если он большой?

Читай Криса Окасаки, он расскажет, как эффективно работать с чисто функциональными структурами данных.

Это бывает полезным - получаем на халяву транзакционность памяти.