Вышел Groovy 1.7

>1) rails - это для ruby, а не jruby.

глупости.

2) преимущества rails перед grails озвучите?

all you need, none you don't. grails это такой «я его слепила, из того что было», попытка замазать косметикой одутловатое и опухшее лицо жабовских монструозных инструментов. система должна быть проста снизу доверху, лепить еще один уровень абстракции - явно не выход.

итд:

не впечатляет. по ссылкам не ясно, что же они там на грельсах переписали и какого результата добились. вобщем маркетоидные эннаунсы. afaiu в обоих случаях уже использовали spring и hibernate, так что и объем переписанного можно поставить под сомнение.

зы попали как раз те, что повелись на rails hype

нету никакого rails hype. он был создан для того, чтобы разработать конкретное приложение. как и джанго. именно поэтому их и используют молча - они just work, они не музейные экспонаты с выставки «о это дикое современное искусство».

Ладно, мне надоело.

Ильдар, увидимся в следующем руби-треде, спокойной ночи!

groovy-код можно написать так, что он скомпилится java-компилятором

Ано... Это... Зачем, кому-то нужно писать код на груви, чтоб он скомпилялся javac???

так(«в одну сторону») умеют все jvm-языки, иначе они бы не были jvm-языками, но «в обратную сторону» умеет только groovy

Не только. Навскидку Closure, Scala.

>Это... Зачем, кому-то нужно писать код на груви, чтоб он скомпилялся javac???

Ну, мне, например, это понравилось. Хотя только что узнал об этом. Java я знаю, Groovy - нет. Так что я могу начать писать «как бы на Java», понемногу вводя Groovy-функциональность :)

то-то оно работает по-инопланетному и тормозит безбожно..

ДУмаю причина тут в укртелекоме а не в грайлс.

Так что я могу начать писать «как бы на Java», понемногу вводя Groovy-функциональность :)

Я думаю, обычно груви выбирается осознанно, как раз чтобы сразу начать использовать GString, GDK, замыкания и def. Да тот же print в конце-концов. Тем более, для java программистов изучение основ языка сводится к просмотру туториала — это час от силы. После этого часа javaс поднимет лапки кверху.

занятный язык. сейчас качаю groovy in action. посмотрим на что он годен. думаю для напейсания скриптов для десктопа подойдет. кстати вкрапления синтаксиса ruby радуют глаз. perl-кун.

>groovy-код можно написать так, что он скомпилится java-компилятором

такой groovy нах никому не сдался

тормозное овно. Как было, так и осталось.

зачем?

Охохо. Только вчера днем открыл для себя Groovy, так вечером новость.

На данный момент мне этот язык нравится больше всех других. Надо открывать новые горизонты, а то много старья (хотя вполне рабочего) набралось. Реально крутая вещь. Особенно smooth learning curve понравилась. Еще мне Vala симпатична, но пока что это просто не тот уровень. Пилить ее надо днями и ночами.

Был бы он побыстрей, была б славная замена Пистону

Are you insane?!? Нельзя ровнять скорость JVM и скриптоподелие, которым является официальный интерпретатор. Причем хоть с psyco, хоть без, хоть с тремя. Оно не scalable (GI Lock), медленное до ужаса. Это вполне простительно для скрипта, админо-скрипты, гуевины вполне можно, удобно и нужно писать. Но JVM и интерпретатор Питона это разные вещи. А вот если мы говорим о Jython и JRuby, а также IronPython (how about that?), то тут мне очень интересно узнать бенчмарки по сравнению с Groovy и Java

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

поэтому пользователь получает плюшки обоих сортов.

Плюшки, плюшки... Имеется в виду по морде?

Динамическая типизация это, типа, складываем кирпичи с ящиками, умножаем все это на метры и получаем кубические литры?

Ню-ню...

Помница друган в проге месяц ошибку искал. Прога раз 10 нормально отработает, на 11-й лажу выкинет, причем с одними и теми же исходными данными. Оказалось, что он в одном месте переменную S случайно махнул на C. В большинстве случаев, этой неучтенной переменной присваивалось значение 0, но иногда какая-то лажа из места в памяти, куда она распределялась. А сложение строк 3,14 и 1.27 воще прикол :)

Не. Динамическая типизация не для меня. Может кому и удобно, но шанс «наступить» очень велик.

Еще мне Vala симпатична, но пока что это просто не тот уровень. Пилить ее надо днями и ночами.

Фотку Valы покажи!?

Заценил бенчмарки с Groovy. Скорость JVM - это круто. Но что-то они там наворотили в библиотеке классов. Ну не может быть такая разница в производительности между Groovy и Java если Groovy в основном синтаксический сахар. Или тесты плохие или пилить надо библиотеку классов. И Jython и JRuby быстрее работают намного. Хотя этому нет теоретических предпосылок. Может Groovy там объекты лишние клепает на каждом X.collect(...).each(...)? Чесно говоря его от всяких Pythonов только JVM с крутой оптимизацией и нормальной многопоточностью спасает. Но сам язык понравился мне сильно ))

> Фотку Valы покажи!?

Пока что Vala похожа на твою аватарку... Но со временем можно будет надеятся на лучшее )))

Пока что Vala похожа на твою аватарку...

Красотка :)

Пилить ее надо днями и ночами

Странный вкус :)

>то тут мне очень интересно узнать бенчмарки по сравнению с Groovy и Java

меня больше беспокоит именно Groovy vs. Java, ибо до недавнего на отдельных задачах даже типизированный Groovy сливал Java до 2-х десятичных порядков... Это слишком. Как «shell-скрипт» он не годится - Groovy рантайм грузится ещё на порядок медленнее, чем сама JVM. Разве-что - для быстрого прототипирования перед реализацией на Java/Scala

сабж не нужен, php есть же

Помница друган в проге месяц ошибку искал. Прога раз 10 нормально отработает, на 11-й лажу выкинет

У меня в питоне тоже такое было. Приходится теперь эмулировать при помощи декораторов.

> на отдельных задачах даже типизированный Groovy сливал Java до 2-х десятичных порядков...

Я такое находил. Но как? Просто я не вижу теоретических причин. Ни одной. Компилируется в тот же class, запускается на JVM, пусть есть оверхед, но не в сотни же раз. В каком месте?

>Просто я не вижу теоретических причин. Ни одной.

Это не повод для кривой реализации :)

Наверное слишком много сахара перетащили в рантайм, вместо того чтобы весь «растворить» при компиляции

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

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

А что вы запускали?

Правильно ли я понимаю, что теперь индусам из БангаЛОРа надо будет изучать Груви, кроме, собственно, Жабы?

>> вот ее как раз в продакшене никто и не использует, так, конторки повелись на «rails» в названии, и попали

4.2

http://www.springsource.com/newsevents/skycom-uses-springsource-supported-groo

я же говорю, оно у нас только для мелких проектов. все серьезное на джаве, и большинство из этого старое как говно мамонта (далее куча жалоб и причитаний на суровую легаси жизнь...)

>> Согласен, здесь на вкус и цвет... Просто бытует мнение, что статическая типизация позволяет выловить больше ошибок на этапе компиляции.

Не бытует, а так и есть. Сколько гемору только отлаживать, скажем, >скрипты по работе с сетью — сначала оно к сети присоединиться, потом >покидается пакетами, потом работает-работает, ты сидишь, ждёт, а потом >нате — «AttributeError: 'xxx' object has no attribute 'yyy'» — >мляяяя, опечатался...

Груви не компилируется. Так что такие проблемы у тебя будут все равно.
Статическая типизация это о том, что если переменная типа String, то в ней будут только стринги, а не все что угодно, как в питоне.

А вообще открой для себя юнит-тесты, чувак, pyunit в частности!
Заодно и рефакторить можно смело.

> Груви не компилируется

Как же у меня получилось? Что я курил?

> не впечатляет. по ссылкам не ясно, что же они там на грельсах переписали и какого результата добились. вобщем маркетоидные эннаунсы. afaiu в обоих случаях уже использовали spring и hibernate, так что и объем переписанного можно поставить под сомнение.

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

mp3.walmart.com с нуля был написан на Grails, если Вас sky.com не устраивает. Да и глупо утверждать, что неизвестно сколько переписано и т.п. - Groovy лишь дополнительный инструмент Java-разработчика, а не совершенно новая платформа, как Rails - в этом его и преимущество: гибкость Python/Rails на уже проверенном и испульзуемом Java-стеке.

Сам Grails практически весь написан на Java, что делает его очень производительным - на Groovy по сути пишется только бизнес-логика. А based on Spring & backed by SpringSource без проблем открывает ему дорогу в Fortune 500.

Scala - язык хороший, но в Java 7 мы получаем first class functions, function types & lambda expressions. Generics в Java 5 мы кстати тоже получили из Scala. Мейнстримом она не станет, но для тех кому надо более сильное ФП - пожалуйста. Может со временем ещё какие фишки из неё перейдут.

Clojure - всё же Lisp, хотя то, что надо отметить, что диалект довольно трендовый и привлекает много Lisp-еров на Java платформу, что есть большой плюc.

Среди динамических языков под JVM лидирует(по вакансиям) - Groovy. Спросом ещё пользуется Jython, но среди администраторов IBM WebSphere & Oracle WebLogic, где он используется в качестве скриптового. JRuby спросом не пользуется, несмотря на недавнее его продвижение компанией Sun. Groovy позволяет быстро прототипировать, играться с API через @Grape, и при необходимости «дописать» код до Java, а не переписывать с нуля как в случае с Python/Ruby в силу синтаксической схожести.

Вообщем ниша всех языков под JVM и их переспективы - вполне очевидны.

так, простенький скриптик набросал. ходит по директориям, работает со строками. оценить хотел на глаз применимость groovy для написания скриптов для повседневных задач. я полагаю что он больше подходит для написания приложений которые запускаются не часто но работают много(те же серверные приложения, ide например). кстати, а кэш для скомпилированных классов у groovy есть?

>Scala - язык хороший, но в Java 7 мы получаем first class functions, function types & lambda expressions.

Не «получаем», а «может быть получим», ну или хоть «получим», ибо пока не реализовано :(

Clojure - всё же Lisp ... что есть большой плюc.

:) Хотя в некоторых местах таки и он начинает «педалить» :(

>да ну, за jruby больше народу, фреймворк нормальный, а не эти >монструозные жабовские поделия. в конце-концов, есть scala.

ну кому нужен этот недоязык? он же ни для чего не приспособлен. когда >к jvm по рукам и ногам привязан - есть же дофига всякого разного >вкусного.

его даже в продакшене нигде не используют.

А jruby значит не жабовская поделка?

А в груви вполне себе используют в одном из 5 крупнейших банков мира, почти как стандарт при написании премочных тестов.

И я знаю,по крайней мере, об одном проекте на grails который сейчас в разработке, который если не уже, то вот-вот будет в продакшене там же.

Другое дело, что я не обычно не встечаю задач, в которых бы жаба не справлялась настолько, чтобы мне нужен был груви или питон. Вот мост в сишную(++) либу иногда - это да.

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

> жабабыдлокодер детектед.

Кто-то среднеинтеллектуальный создал миф. Теперь школьники повторяют это на форумах

>>тем более что критичную математику можно без проблем перевести (ускорить) в java

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

критичную математику можно ускорить с помощью асембле^W математиков

Фиксить нужно не язык, а алгоритмы.

>Ано... Это... Зачем, кому-то нужно писать код на груви, чтоб он скомпилялся javac???

компилябельность javac'ом - это только пример. смысл-то тут в максимальной близкости синтаксиса, что даёт flat learning curve, cross-language рефакторинг и более очевидную/простую интеграцию

Не только. Навскидку Closure, Scala.

нет. по синтаксису с java максимально совместим только groovy, даже «родной» javafx совсем другой.

>> жабабыдлокодер детектед.

Кто-то среднеинтеллектуальный создал миф. Теперь школьники повторяют >это на форумах

Если что это была ирония,я про себя так говорю.

да жабакодер с 10-летним опытом в жабе.

Просто в моей работе на кодирование приходится дай бог 10% времени, и тут не важно какой там синтаксический сахар у языка, а все остальное время занимает, понимание предметной области, придумывание алгоритма работы, сложность интеграции с внешними системами и создание полноценных автоматических премочных тестов (не путать с юнитами они входят в 10%).

Так что мне хватает синтаксического сахара idea, все неудобное можно шаблонизировать.

А все эти «быстрые разработки», динамические языки, прочие вкусности, имхо, нужны либо для говносайтов(собирательное понятие - сам такие делал) либо для лабороторных работ в универе(кругозор расширить - что полезно)

Преимущество груви вижу в тесной интеграции с жабой и что код фактически можно заменить в рантайме, что сильно проще чем cglib.

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

неа, «считово». Просто в groovy почти вся математика идёт через весьма небыстрый BigInteger/BigDecimal, что и решается java'ой. Си-модули - это решение другого уровня.

>если Groovy в основном синтаксический сахар.

это только на первый взгляд и снаружи. В тестах отставание будет в первую очередь из-за отсутствия целочисленной математики и боксинга/анбоксинга(в groovy всё - объект). Ну и GroovyObject гораздо тяжеловеснее java.lang.Object, плюс динамический вызов методов и всё такое. Ждём invokeDynamic, ага :)

И Jython и JRuby быстрее работают намного

тесты в студию

> Если что это была ирония,я про себя так говорю.

Я понял. Просто популярная фраза на форумах.

для лабороторных работ в универе(кругозор расширить - что полезно)

Вот для этого я groovy и буду использовать

> тесты в студию

гугл, пальцы, клава в студию

отсутствия целочисленной математики

Не понял смысла. Вы дизассемблировали?? Думаю что пристатической типизации такого нет. А динамическую нужно пользовать когда действительно нужно. Или они бенчмарки сделали на Groovy def против Java int? Сам сорцы не смотрел, но если да, то у них нет ума.

>гугл, пальцы, клава в студию
ок, почти первая ссылка:
Headius, главный по jruby(http://blog.headius.com/2008/05/power-of-jvm.html): «Groovy 1.6 has drastically improved, and even surpasses JRuby for most of those benchmarks.»
Вот потому и прошу конкретные тесты

Не понял смысла.

http://groovy.codehaus.org/Groovy+Math
+в groovy всё - объекты

Читаем сдесь.

http://blog.dhananjaynene.com/2008/07/performance-comparison-c-java-python-ru...

JPython лажанул. Но крапленными картами они играют, это да. одни defы. А если мне нужна производительность, то я просто забью на них и буду статически типизировать. И еще буду использовать суффиксы их той статьи, которую вы привели в пример. А если что, то напишу рядом класс на Java с int, float, double. В том то и плюс Groovy перед другими скриптовыми языками.

> Просто в моей работе на кодирование приходится дай бог 10% времени, и тут не важно какой там синтаксический сахар у языка, а все остальное время занимает, понимание предметной области, придумывание алгоритма работы, сложность интеграции с внешними системами и создание полноценных автоматических премочных тестов (не путать с юнитами они входят в 10%).

А нам препод говорит, что в большинстве задач так и надо и это нормально. А те, кто кодит больше - обезъянки, работающие за еду, или быдлокодеры.

/me торопливо спрятался в танке:)

Порадовал последний пример.

http://groovy.codehaus.org/Swing+Builder

Скинул в groovyConsole, запустил, порадовался. Где вы Qt'шники?

Единственное, что мне не нравится в groovy, это то, что closure (callback-и) при использования слова return выбрасывают из closure, а не из метода (что сильно уменьшает мощь их использования по сравнению в ruby). Вот если бы из блока closure выбрасывало из метода, тогда была бы полноценная замена ruby. А так разве что python может заменить, где лямбда-функции не так критичны.

Нафига? Все оно правильно делает - замыкание это тоже функция и return к ней и относится.

Хорошая новость - груви активно используется у нас для скриптинга.

P.S. Превед любителям пЫтона, рубироидам и прочим мученикам!

>А если что, то напишу рядом класс на Java с int, float, double. В том то и плюс Groovy перед другими скриптовыми языками.

Это справедливо почти для всех не-Java JVM-языков :)

>http://groovy.codehaus.org/Swing+Builder

Скинул в groovyConsole, запустил, порадовался. Где вы Qt'шники?

Для такого всё-же лучше JavaFX =)

> Это справедливо почти для всех не-Java JVM-языков :)

Да!

Для такого всё-же лучше JavaFX =)

Да!