Groovy inspiration — Feel the difference

[Gotaxe]

Интересный язык groovy, сам игрался с ним немного.
Подскажите, в каких крупных/средних проектах используется Grails?

[sndl]

Можете посмотреть на www.grails.org/Success+Stories
Еще слышал про SAP, они строят на его основе свое решение wiki.sdn.sap.com/wiki/display/Community/Composition+On+Grails.
Вообще, нравится, что он развивается довольно стремительно и уже не сравним со своими старые версиями. Очень жду, когда они пересядут на Gradle, тогда с адаптацией мультимодульных проектов будет значительно проще.

[HeadFore]

Больше половины ссылок в Success Stories, которые я хотел посмотреть, не откываются.

[Taro]

Вам Success Stories или по ссылкам походить? Зашли, посмотрели — хватит. :)

[naryl]

Возможно, никто из ваших знакомвых не трогал, но ABCL, думаю, тоже стоило упомянуть.

[sndl]

Ну тогда и все остальные из этой таблицы en.wikipedia.org/wiki/List_of_JVM_languages#JVM_languages

[bagyr]

Если на скобки потянуло, то лучше Clojure.

[naryl]

На эту тему можно долго и весело троллить, но я не в настроении, поэтому скажу просто.

Сравните результаты запросов в гугл «web application in abcl» и «web application in clojure».

[thevery]

возможно, но зачем?

[naryl]

Зачем что? Зачем никто из знакомых sndl не трогал ABCL?

[thevery]

зачем нужно упоминать имхо совершенно нишевый никому неизвестный «ABCL»?

[naryl]

Django же упомянут.

[thevery]

Django/python на порядок (а то и два-три) известнее ABCL

[naryl]

Давайте статистику. Я вот только сейчас про «Django» услышал. Про Rails слышал, про ABCL-web слышал(интересовался), про «Django» — нет.

Сам и знакомые используют либо Rails, но чаще что-то, в данном обсуждении не появившееся. Какой-то заговор прям для ограждения меня от «Django». -_-

[thevery]

>Давайте статистику.
tiobe, google, google trends, indeed, dice в конце-концов — мало?

[yroman]

Штука хорошая, но вот то же приложение на grails дебажить это просто обожемой. Стек трейсы валит на несколько страниц.

[thevery]

Use the ForceIDEA, Luke:
blogs.jetbrains.com/idea/2010/03/groovy-stacktrace-folding/

[Nikelandjelo]

По-моему вы немного замыкания путаете с функциями. В вашем примере показывается то, что в груви функции — объекты первого класса, т.е. могут быть переданы как параметры и т.д. В джаве конечно можно сымитировать функции при помощи интерфейсов, но да, это будет больше кода.

[sndl]

getStaffWithCriteria — несомненно метод. И все же я настаиваю на том, что конструкция, передаваемая в качастве второго параметра этому методу — ничто иное как замыкание (closure).

[Nikelandjelo]

В замыкании мы же должны использовать какую-либо переменную, объявленную вне этого замыкания.
Если бы у вас было

def averageSalary = 600
println getStaffWithCriteria(staff, {e -> e.salary > averageSalary})

Тогда я бы назвал это замыканием.

[sndl]

for(e in staff) чем тут «e» не переменная вне замыкания?

[CheatEx]

Дело не в том, что она «вне» а в том как код в замыкании получает к ней доступ — как параметр вызова или «заглядывая» в контекст функции которая его породила. В последнем случае такая переменная называется свободной и даёт людям, осилившим лямбда-исчисление, формальное право говорить что мы имеем дело с замыканием :)

[sndl]

— В замыкании мы же должны использовать какую-либо переменную, объявленную вне этого замыкания.
Сошлитесь на источник, пожалуйста. Я не понимаю такого требования.
Провожу аналогию с groovy.codehaus.org/JN2515-Closures: кажется все нормально

[romik]

Closure: closure is a first-class function with free variables that are bound in the lexical environment.

[Nikelandjelo]

На випикедии смотрю
Да, понятнее становится после этого вопроса. Учитывая, что эти понятия часто используется взаимозаменяемо. Для меня ваш пример — именно анонимная функция, а не замыкание.

[CheatEx]

Вы просто пользуетесь академической терминологией. В Groovy (а если мне не изменяет память и в Ruby) замыканиями принято называть все лямбда-выражения.

[egoholic]

На сколько я знаю, Groovy произошел под вдохновлением от Ruby. Можете привести какие-нибудь преимущества Groovy над Ruby, в частности интересует скорость работы?

[sndl]

Для себя на данный момент одним из преимуществ я вижу то, что Groovy работает в JVM (о чем было упомянуто в начале поста). По поводу производительности сложно сказать, но по моему мнению, тенденция сводится к тому, что приложения на groovy будут быстрее. Хорошей практикой является написание «критичных», в аспекте производительности частей, на Java. И, конечно, ожидаемый всеми Project Coin для JVM, который должен дать скорость динамическим языкам в jvm, сравнительную с Java.

[egoholic]

спасибо за ответ!

[TEHEK]

М… где-то в инете натыкался на бенчмарк в котором участвовали груви и руби. jruby 1.8 был быстрее (кстати, он был быстрее ruby 1.8).

[thevery]

groovy быстрее.
например, вот: shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=groovy&lang2=yarv (правда он весьма старый).
большим плюсом в плане скорости является также наличие groovy++ — одна строчка кода(аннотация) способна сделать ваш метод/класс статически типизированным и многократно его ускорить.

[u_story]

Для скорости есть groovy++ extension.

[darkdimius]

Я бы больше смотрел в сторону Scala.
И со мной солидарен создатель Groovy пруф: macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for.html

[romik]

Это совершенно разные языки, со своими областями применения. Scala неудобна для написания скриптов, а попытка писать на Groovy большую систему равносильна самоубийству. Кстати, есть ещё довольно интересный своей статической типизацией Groovy++.

[CheatEx]

А чем она неудобна для скриптов?

[TEHEK]

Изучаю Scala на данный момент… Поначалу казалось что все очень здорово и радужно… Сейчас что-то уже страшно. Синтаксис порой просто чудовищен… например, сеттеры для свойств класса:

def property_= = property

Одной из фишек является возможность легкого и быстрого создания DSL. С другой стороны, когда дело дошло до использования этих самых DSL в своем коде, мне стало жутко неудобно… Каждый перефигачивает операторы как хочет, из-за чего код превращается в жуткую кашу…

Изучать продолжаю, но уже не так все радостно… Все больше напоминает Perl, только на JVM :(

[CheatEx]

Уж не с Lift'ом ли вы познакомились?

[TEHEK]

Вообще, начал изучать Скалу как раз чтобы к лифту подобраться. Чуть-чуть пощупал лифт. Сразу же убило то место, где прямо в коде начинается иммитация html / xml, реализованная через DSL.

Если у вас есть опыт, полезные ссылки и книжки, буду очень признателен :) (можно в личку)

[TEHEK]

Ну, кстати, создатель Джавы (Джеймс Гослинг) тоже с вами в чем-то согласен.

[Zorkus]

Да, отличный язык для скриптинга, тестов и ДСЛ. Возможно (экспериментирую) и для остальных вещей.

Добавьте-ка линк: www.asert.com.au/pubs/Groovy/Groovy.pdf

[Mezomish]

>То есть на Java имеем три метода вида:

Хм… (писал прямо тут, так что возможны ошибки, но общая идея должна быть понятна):

abstract class Criteria {
    abstract boolean matches(Employee e);
}

List getEmployeeWithCriteria(List staff, Criteria criteria) {
    List result = new ArrayList();
    for (Employee e: staff) {
        if (criteria.matches(e)) {
            result.add(e);
        }
    }
    return result;
}

println getStaffWithCriteria(staff, new Criteria(){ boolean matches(Employee e) { return e.salary > 600; } });
println getStaffWithCriteria(staff, new Criteria(){ boolean matches(Employee e) { return e.age < 27; } });
println getStaffWithCriteria(staff, new Criteria(){ boolean matches(Employee e) { return e.dept == 'A1';} });

Да, кода всё равно чуть больше, чем в Groovy, но не так драматично, как Вы описываете (три одинаковые функции).

[sndl]

Ага, слукавил :) Спасибо

[CheatEx]

Да, про классический лимит в 80 символов можно забыть…

[Mezomish]

И часто Вам приходится просматривать Java-код на текстовом терминале 80x25? :)

[Mezomish]

Для тех, кто не в курсе: richarddingwall.name/2008/05/31/is-the-80-character-line-limit-still-relevant/

[CheatEx]

80 нет, но на ноутбучном мониторе максимально развёрнутая консоль при комфортном шрифте даёт символов 100 с небольшим.

Да и дело не только в консоли. Есть почтовые рассылки, есть блоги, есть не очень прямые браузеры репозиториев, иногда надо пользоваться утилитами для мёржинга (я благодаря им полюбил широкоформатные мониторы, ага). Почти везде можно наткнуться на ситуацию, когда полторы сотни символов в ряд не приемлемы.

В моих проектах обычно по соглашению используется ограничение в 120 строк — иначе с Java и сановским стандартом кодирования никак. Не могу сказать что это радует.

[Mezomish]

Ну так 100 — это уже не 80, верно? Да и о каком стиле может идти речь в примере, который даже не скомпилируется? :)

P.S.: у нас в проекте (и в сопутствующих) принято как раз 100, но за лишние 2-3-5 символов никто убивать не будет.

[javax]

Огромный плюс груви по сравнению со Скалой то, что почти любой соурс на Яве будет валидным соурсом на груви. Т.е. не надо тратить время на обучение группы. Если не помнишь как сделать что то красиво in groovy way — всегда можно по явовски.

[CheatEx]

Если есть валидный сурс на яве — зачем его делать *почти* валидным сурсом на груви?

[elw00d]

Для реализации динамического деплоймента кода в сервер приложений, например.

[CheatEx]

Не понял идеи. Написать скрипт на груви и использовать в стиле CGI? Сервер ведь жалко.

[thevery]

а что вы подразумеваете под «CGI-стилем» в данном случае?

[elw00d]

Допустим у вас есть DAO-классы, которые выполняют некоторые запросы к БД. Для того, чтобы что-то в них быстренько поправить, нужно передеплоить приложение целиком. Ну или перезапускать, если у вас не app server, а десктопный свинговый клиент, к примеру. Это неудобно. У меня на работе коллеги написали автоматический деплоер, который подцепляет скрипты из папочки в рантайме. Очень удобно. Причем код, который деплоится в виде скрипта, можно смотреть эклипсом с полноценной подсветкой синтаксиса и интеллисенсом (поскольку IDE может считать его java кодом). Очень удобно для написания скриптов.

[CheatEx]

В смысле они компилируются и результатом подменяются старые версии? Но это не связано с груви — решение для самой Java будет точно таким-же. Или я что-то упускаю в способе выполнения груви скриптов?

[elw00d]

А разве джава классы можно подгружать динамически без создания classloader'ов и прочей мутотени?

[CheatEx]

Нельзя. Но это связано не с языком, а с самой VM. Мне казалось что для любого языка объём проблем одинаков. Если в груви предприняты какие-то шаги для облегчения процесса интересно узнать :)

[elw00d]

Ну как бэ мы не обсуждаем проблемы языков оторванно от конкретных ситуаций :)
Груви можно просто взять и подгрузить во время выполнения программы — и в этом вся фишка. Понятное дело, что в остальном разницы особой и нет, если программист не использует вещи, специфичные для груви и программирует так же, как бы программировал на Java. В этом случае груви ему, конечно, ни к чему.

[thevery]

на groovy, грубо говоря, будет просто eval()

[elw00d]

Мб, я на самом деле с OSGI не работал, знаю только, что там плагинная система. Но в любом случае написать ручками деплоер скриптов, который периодически сканирует папку и деплоит все что видит, это очень быстро по сравнению с использованием OSGI.

[javax]

я к тому, что можно писать на смешанном стиле" пока выучишь все фичеры языка

[thevery]

имхо для getStaffWithCriteria лучше было бы использовать grep/findAll

[sndl]

Угу, дописал. Не думал, что бывает настольно просто. Спасибо.

[thevery]

ну, если уж упрощать, то можно было б совсем оставить collection.grep {it.salary > 600}

[Foror]

Все эти groovy/scala временное явления, как добавят немного синтаксического сахара в 7-8 версию, они особо и нужны не будут.

И вообще, java это типизированный язык для разработки больших систем, если вам нужны скрипты юзайте заколённый во времени python — потратьте немного времени на изучение и будем вам счастье.

[thevery]

>Все эти groovy/scala временное явления, как добавят немного синтаксического сахара в 7-8 версию, они особо и нужны не будут.

всех фич даже текущего groovy в java7/8 не будет, а ведь в groovy к этому моменту фич станет ещё больше…

>если вам нужны скрипты юзайте заколённый во времени python — потратьте немного времени на изучение и будем вам счастье.

вас не затруднит рассказать о плюсах python перед groovy?

[Foror]

Зачем еще больше фич в синтаксисе? :) Это уже извращение какое-то тогда получится :) Впрочем, видимо вы ловите кайф, когда в язык чего-то только не напихают, типа C#, там даже подобие SQL умудрились воткнуть в синтаксис. Ну чтоже, на вкус и цвет… :)

Мне нравится больше минимализм в синтаксисе, от того и люблю такие языки как java или недавно вышедший go.

"! о плюсах python перед groov" — шило на мыло, но зачем плодить сущности? Питона, руби (jython, jruby) было мало?

[thevery]

>Зачем еще больше фич в синтаксисе?
для DSL, например: groovyconsole.appspot.com/script/355001
а вообще фичи groovy — это уже давно не только и не столько «синтаксический сахар», например groovy++ вообще на AST построен

>типа C#, там даже подобие SQL умудрились воткнуть в синтаксис.
findAll в groovy вообще всегда был

>Питона, руби (jython, jruby) было мало?
jython вообще мёртв, jruby совершенно не совместим по синтаксису с java и привязан к ruby.

[Foror]

И еще java это множество хороших библиотек и фреймворк, если же каждый начнёт писать на своём любом язычке (groovy, scale, etc.), то в итоге будет зоопарк… Я уже с этим столкнулся, когда хотел посмотреть сырцы EtherPad… для этого я должен идти учить scala… Ну и нафиг мне это надо? Потом кто-то напишет на clojure. И что, мне теперь идти изучать clojure, чтобы посмотреть сырцы?

[sndl]

По моему мнению, основы какого-нибудь языка изучаются куда проще, нежеле очередной фреймворк. Почему Вас тогда не смущает обилие фреймворков в Java мире?.. Взять только веб: Spring MVC, Sling, Struts, GWT, Vaadin и можно продолжать еще долго, при том, что не найдем какой-нибудь де-факто.

[Foror]

Кто сказал, что меня не смущает? Меня смущает GWT — это неверное направление, временная затычка, пока на место JavaScript не придёт новый Ecma стандарт, с блекджеком и шлюхами. Или NativeClient станет популярным.

Еще раз повторюсь — я (и не только я, есть еще куча умных дядек, пишущие умные книги) считаю, что плодить сущности это плохо. Разнообразие фреймворков и затычек типа GWT — это терпимо. Но когда к этому пихают новые надязыки и позиционируют их как мейнстрим (когда они применимы для узкой области и пару тысяч фенов), то это плохо. Потому что мало знающие или не опытные специалисты ведутся на это и теряют затем кучу времени впустую.

[thevery]

>Меня смущает GWT — это неверное направление, временная затычка, пока на место JavaScript не придёт новый Ecma стандарт, с блекджеком и шлюхами.

а что принципиально изменит новый EcmaScript?

>Но когда к этому пихают новые надязыки и позиционируют их как мейнстрим (когда они применимы для узкой области и пару тысяч фенов), то это плохо. Потому что мало знающие или не опытные специалисты ведутся на это и теряют затем кучу времени впустую.

вы считаете что groovy — это сильно нишевый «надязык»?

[thevery]

к слову понять/писать на groovy значительно проще, чем на scala/clojure, и это ещё один из его плюсов

[corpor]

Я тоже питал восторженные чувства о Groovy, когда изучал его. Сейчас пишем проект на этом блядстве! Пасаны, забудьте — а то кошмары снится будут. И речь даже не в том, что на четыре строчки вышеприведенного скрипта — эта хня сгенерит джава класс в 2 сотни строк (по сравнению с которым класс с 37-ю строками вам покажется очень понятным и легковесным), проблема в написании большого кол-ва кода практически в текстовом блокноте, это я уже не упоминаю про потерю типизации при код-ревью. Вообщем используя груви, можно получить нервное расстройство, много потраченного времени и благополучно заваливающийся проект!!! Груви -ГАВНО, или как еще грят — джава на букву Г!

[thevery]

а зачем писать в блокноте, когда даже бесплатная IDEA его прекрасно поддерживает?

[corpor]

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

[thevery]

ну, раз уж так принципиально не хотите использовать IDEA — попробуйте STS: www.springsource.com/developer/sts

[corpor]

его родимого и юзаем! )))
FYI — это ничто иное как обычная связка eclipse + куча ненужных spring плагинов, groovy плагин — стандартный, там ставится отдельно. Обо всем этом я и говорил!

[vdshat]

Каждому языку — свое применение.
Groovy:
— Низкая скорость (http://stronglytypedblog.blogspot.com/2010/02/java-vs-scala-vs-groovy-vs-groovy.html)
— Больiое потребление памяти…

+ Короткое время входа Java программистов в язык
+ Возможность переиспользования наработаного Java кода

P.S. Намедне пришлось опять Perl'ом заняться. Все то, что ищем в новых языках уже давно написано и используется в Perl-мире: и DSL, и динамика, и ООП… Только все давно оптимизировано и вылизано.

P.S.S. Как раз 19-го «похоронили» Gradle у себя на проекте в пользу Ant+Ivy+AntContrib. Очень сырой продукт. Мы кучу ошибок исправили, что-то обернули… Последней каплей стала модель самого проекта, когда посмотрел исходники. Несмотря на известные проблемы и недостатки модели Maven в качестве модели приняли именно ее. И потом танцуют с бубном, чтобы исправить родовую травму. Думаю, ко 2-й версии можно будет пользоваться в серьезных проектах, если модель пересмотрят.

[thevery]

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

>P.S.S. Как раз 19-го «похоронили» Gradle у себя на проекте в пользу Ant+Ivy+AntContrib.
а расскажите подробнее про грабли gradle, а? почему, кстати, не maven?

[vdshat]

Странно, что за 3 года так и не вышла 1-я версия. А текущая такая сырая.

Про «градли». Как вы яхту назовете, так она и полывет! (с) Капитан Врунгель.
Кстати, предложил к использованию в наших проектах именно я. Но и не без меня его похоронили.

1. Отсутствие полной поддержки EAR-архива. Написали сами.
2. Гора ошибок при использовании кэша вкачестве локального репозитория, чтобы исключить дублирования артифактов и т.д. Когда много артифактов, то проблема места на диске, как ни страно, еще существует. Пофиксили через обертку.
3. Невозможность задания имени проекта. Это на первый взгляд может показаться, что это мелочи, но в динамичеких проектах с количеством подпроектов (не модулей!) за 40 поддерживать это крайне неудобно.
4. Жесткое задание версии продукта. Опять же, когда каждый проект живет своей жизнью, то следить за версиями — отдельная тема. С этим уже не стали бороться — не успели.
5. Отсутствие поддержки в IDE для многих разработчиков стало преградой.
6. Отсутствие поддержи CI системами подпотило впечатление тоже.

Странно, что используя Ivy как основу, разработчики не воспользовались основными его преимуществами.

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

Что касается Maven, лично у меня к нему давняя нелюбовь из-за костности. Я предпочитаю свободу действий, а не предопределенный путь ;-). Для проектов со сложной структурой им пользоваться крайне сложно без собственных плагинов и плясок с бубном. Ошибки плагинов зачатую не дают возможности пользоваться им совсем. Например, release плагин очень нужный и очень глючный.

[jbaruch]

Интересно, как всё меняется :)
Прошло достаточно времени, и ни одного недостатка, из тех, что вы перечисляете, не осталось :)

[thevery]

>Странно, что за 3 года так и не вышла 1-я версия.
имхо не так уж и странно

1. ну, это всё-таки не такой уж и большой недостаток самого gradle
5. ждём JetBrains, в 10.x наверняка будет
6. JetBrains уже поддержали. ну и опять же gradlew никто не отменял.

>Странно, что используя Ivy как основу, разработчики не воспользовались основными его преимуществами.

ну, из ваших 6 пунктов Ivy помог бы в решении только 2, ну может ещё 3-4 частично

[vdshat]

1. Это все же очень частая и логичная операция при сборки J2EE-проектов. И при позиционировании себя как build-tool нужно включать поддержку основных технологий.

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

[sndl]

Что-то я видимо недопонял по 3му и 4му пунктам…
Смотрим API класса Project — www.gradle.org/0.9/docs/javadoc/org/gradle/api/Project.html.
Там есть как имя, так и версия. Поясните, пожалуйста, про жесткое задание версий проекта.

[thevery]

1. далеко не все веб-проекты — это «полноценный» j2ee+ear, зачастую хватает war'а

ну, для чего Ivy нужен я знаю, вопрос-то в другом был