Groovy inspiration — Feel the difference

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

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

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

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

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

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

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

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

>То есть на 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, но не так драматично, как Вы описываете (три одинаковые функции).

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

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

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

Каждому языку — свое применение.
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-й версии можно будет пользоваться в серьезных проектах, если модель пересмотрят.

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

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

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

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

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

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

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

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

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

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