LINUX.ORG.RU

Релиз Groovy 1.8

 ,


0

2

После четырех бета-версий и четырех кандидатов в релизы команда разработчиков Groovy объявила о выходе новой стабильной ветки открытого динамического скриптового языка для Java Virtual Machine (JVM) - Groovy 1.8, распространяемого под лицензией Apache license 2.0.

В официальном заявлении руководитель проекта Guillaume Laforge отмечает, что Groovy 1.8 несет на борту огромное число нововведений и улучшений. Данные нововведения, в частности, включают:

  • Новая функция command chain в области улучшения синтаксиса, заключающаяся в возможности записи обращений ко вложенным методам цепочкой без необходимости ставить круглые скобки и точки, что позволяет в ряде случаев писать код в виде вполне понятных предложений
  • Новые директивы компилятора для преобразования AST-дерева, создаваемого компилятором перед переводом текста программы непосредственно в байт-код. Это уменьшает объем обрабатываемого кода за счет включения готовых стандартных решений
  • Встроенная поддержка JSON, удобная при написании и чтении кода, с хорошей реализацией печати данных при отладке
  • Частичная поддержка JDK7, в частности diamond-оператора, упрощающего работу со встроенными типами:
    List<List<String>> myList=new ArrayList<>();
    То есть теперь вам не придется указывать определение <List<String>> с обоих сторон при создании объекта класса. В Groovy 1.9 поддержка JDK7, разумеется, будет более богатой.
  • Увеличенная производительность при работе с целыми числами и при прямом обращении к методам
  • Различные улучшения при использовании замыканий (closure)
  • Включение в состав поставки библиотеки GPars версии 0.11 для одновременного асинхронного выполнения задач работе программ
  • Многочисленные улучшения в плане производительности

В соответствии с планом выпусков, первая бета Groovy 1.9 будет доступна уже в мае, при том что стабильный релиз ориентировочно выйдет в ноябре.

Скачать

>>> Подробности

★★★★★

Проверено: maxcom ()

Ответ на: комментарий от anonymous

>тормозов и детских ошибок в рантайме, присущих динамической типизации

петросян.png

anonymous ()
Ответ на: комментарий от babusha

перл есть, а руби не нужен просто.

anonymous ()

По-моему, весьма показательно, что в треде про груви ни одного адекватного комментария пока не написано.

Zenom ★★★ ()

А как же карринг ? Это то, чего я так долго ждал!

dotbg ★★★★ ()
Ответ на: комментарий от anonymous

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

babusha ()
Ответ на: комментарий от anonymous

Не умничай! Пофиг что там запускается, скрипт в одну строчку отрабатывал четыре секунды, так что закопать!

babusha ()
Ответ на: комментарий от anonymous

>Erlang не нужен - есть Distributed Haskell

а он есть?

anonymous ()
Ответ на: комментарий от BillDver

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

Я писал и на тех и на других. Для быстрой разработки динамические языки мне удобнее. В строгих типизированных языках надо долго думать над типами, если промажешь, то потом не слабый рефакторинг надо делать или костыли. Ну и eval очень помогает.

Casus ★★★★★ ()
Ответ на: комментарий от babusha

Очень даже пора, например на Ruby

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

Casus ★★★★★ ()
Ответ на: комментарий от babusha

Вы смешной. Hello world на любом из языков для JVM будет работать не быстрее. Время запуска вм и окружения же.

buddhist ★★★★★ ()
Ответ на: комментарий от buddhist

Haskell — это всего лишь пародия на APL.

такъ победимъ!

jtootf ★★★★★ ()
Ответ на: комментарий от ArtemZ

А важна ли вообще разница в скорости руби относительно пхп в небольших приложениях? Руби куда приятнее и выразительнее чем пхп. А для серьезного проекта я бы пожалуй взял scala/lift или мот grails, хотя с ним не работал.

podelkin ()

А самое страшное, что их главный об этом в твиттер сначала написал

ins3y3d ★★★★★ ()
Ответ на: комментарий от babusha

>Все тоже.
жесткое 4.2
Запусти повторно из джава класса уже созданный инстанс груви-объекта.
3 секунды - это время создания объекта из исходника груви

OramahMaalhur ()
Ответ на: комментарий от buddhist

Hello world на любом из языков для JVM будет работать не быстрее

$ time java HelloWorld
Hello, world!

real	0m0.075s
user	0m0.064s
sys	0m0.012s

$ time groovy HelloWorld.groovy 
Hello World!
real	0m1.693s
user	0m2.004s
sys	0m0.180s

$ time jython HelloWorld.py 
Hello world!

real	0m1.049s
user	0m2.124s
sys	0m0.056s

$ time booc HelloWorld.py && time mono HelloWorld.exe
Boo Compiler version 0.9.2.3383 (2.6.7 (Debian 2.6.7-5ubuntu3))

real	0m0.597s
user	0m0.576s
sys	0m0.024s
Hello world!

real	0m0.033s
user	0m0.024s
sys	0m0.008s

:)

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

Слабопоказательные штуки) надо чтобы время выполнения было больше полминуты что ли.

buddhist ★★★★★ ()
Ответ на: комментарий от podelkin

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

ArtemZ ()
Ответ на: комментарий от ArtemZ

>хостинг под пхп в таком количестве и по таким бросовым ценам, что руби до этого ещё ползти и ползти

Нищебродная стори, бро.

anonymous ()
Ответ на: комментарий от babusha

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

anonymous ()
Ответ на: комментарий от anonymous

> Нищебродная стори, бро.

дай денег мне или завали хлебало ^_^

anonymous ()
Ответ на: комментарий от buddhist

>надо чтобы время выполнения было больше полминуты

Это же время стартапа.

А просто по времени выполнения — смотреть в сторону http://balancer.ru/tech/forum/2008/08/t63003--proizvoditelnost-yazykov-obektn... надо. Правда, давно назрело обновить там всё, но всё некогда :)

KRoN73 ★★★★★ ()
Ответ на: комментарий от anonymous

я не собираюсь под тыщу баксов в год платить за домашнюю страничку. это просто неоправданно только из-за выбора ЯП. Можно выбрать пхп и платить 12 баксов в год.

ArtemZ ()
Ответ на: комментарий от anonymous

>Нищебродная стори, бро.

Ну, как бэ, многие конторы готовы платить сотни тысяч рублей за умеренной сложности проекты, работающие на PHP. Зачем мне от них отказываться и выискивать по крохам что-то под более идеологически верными языками, если мои трудозатраты на PHP итак пренебрежимы? :)

KRoN73 ★★★★★ ()
Ответ на: комментарий от BillDver

можно конкретный пример достоинств динамической типизации

Да нет проблем!
Например, в языке со статической типизацией описано две переменные. Одна имеет тип Кирпичь, вторая тип Ящик. В результате каких-то программных манипуляций получили 10 кирпичей и три ящика. Если мы попытаемся сложить ящики и кирпичи, то компилятор срыгнет все в ошибки, и ни какой работающей программы даже не построит. Чтоб это все заработало, нам надо как-то привести кирпичи и ящики к единому типу - танцы с бубном. В языке с динамической типизацией мы просто берем и складываем кирпичи с ящиками. Запростяк все. Вот только никто не знает, что мы получим - толи кирпичи, толи ящики... ХЗ в общем. И чго потом с этим ХЗ делать? Но главное - сложилось, и никаких бубнов.

vada ★★★★★ ()

почему все друг друга пытаются обосрать: «тот нищеброд, этот мудак, то не нужно, это закапавайте..» Народ, ну Вы чего? и это сообщество?! Если что-то пилится - значит кому то нужно. Обязательно надо насрать? Так тяжело просто идти своей дорогой?

Vernat ★★ ()
Ответ на: комментарий от Vernat

>почему все друг друга пытаются обосрать?

Специфика коммьюнити такая, вот…

KRoN73 ★★★★★ ()
Ответ на: комментарий от vada

>Если мы попытаемся сложить ящики и кирпичи, то компилятор срыгнет все в ошибки, и ни какой работающей программы даже не построит.

Гораздо более интересным примером будет не сложение, а создание массива из 10 кирпичей и 3-х ящиков. Может есть функция, которая принимает массив, а далее с ним работает, или ещё чего. Но только один.

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

anonymous ()
Ответ на: комментарий от vada

Ты путаешь динамическую типизацию со слабой.

anonymous ()
Ответ на: комментарий от anonymous

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

vada ★★★★★ ()
Ответ на: комментарий от anonymous

>Вот тут на статически типизируемых языках начинаются пляски, а в динамических всё нормально.

Кстати, а под JVM водятся нормальные языки, в которых можно и статическую, и динамическую типизацию использовать? Как Boo под .NET?

KRoN73 ★★★★★ ()
Ответ на: комментарий от vada

Ладно, мистер ирония), а чем заменить `elisp' в его (неширокой) области применения? (yi пока не взлетел, да и сомнения терзают).

n01r ★★ ()
Ответ на: комментарий от babusha

это был отличный пример того, что на groovy не получится сделать замену core utils. И что?

drakmail ★★★★ ()
Ответ на: комментарий от ArtemZ

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

babusha ()
Ответ на: комментарий от KRoN73

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

anonymous ()
Ответ на: комментарий от vada

>Особено сильно возбуждает массив содержащий и кирпичи и ящики в котором пытамся найти НДС за прошлый год.

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

Например, надо вывести список «блоков», причем в заданном порядке. Сортируем объекты как нужно, засовываем в массив по порядку, проходя циклом вызываем какой-нибудь render(element).

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

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

anonymous ()
Ответ на: комментарий от anonymous

Даже не пытайтесь убедить меня что геморой это удобно и хорошо. Я:)

vada ★★★★★ ()

Да, программистам и вавилонской башни строить не пришлось.

JustGuest ()
Ответ на: комментарий от KRoN73

А просто по времени выполнения — смотреть в сторону http://balancer.ru/tech/forum/2008/08/t63003--proizvoditelnost-yazykov-obektn... надо. Правда, давно назрело обновить там всё, но всё некогда :)

Я когда-то давно тебе писал варианты этого теста для Perl'а.

Casus ★★★★★ ()
Ответ на: комментарий от vada

Даже не пытайтесь убедить меня что геморой это удобно и хорошо.

Искать НДС за прошлый год надо в 1С, а не среди ящиков и кирпичей. Так что мимо совсем.

Casus ★★★★★ ()
Ответ на: комментарий от vada

А что мешает явно приводить типы при сложении кирпечей и ящиков

кирпичи A1, A2; ящики B1;

A2= (кирпичи)B1+A1;

А использование массивов с разными типами сильно запутывает программу. В результате получаем Write only код соответственно обновлять его или повторно использовать затруднительно.

BillDver ★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.