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

Я то что... А создатели и группы поддержки серьёзного ПО для корпоративного документаоборота и прочих внутрикорпоративных разработок очнь неохотно встречают любое серьёзное изменение, которое может угрожеть совместимости. Ведь в такие приложения вкладывают многие года разработки. И Java(если не юзать JNI) гарантирует работу даже далеко не новых приложений. И не надо держать на одном ПК кучу разных версий JRE/JDK, достаточно иметь последнюю версию. Или другой пример, Python. Версия 2.x давно должна была кануть в Лету. Но эта корявая версия всё ещё самая поддерживаемая и востребованная, и грядёт ли в ближайшие 5 лет победа 3.x над 2.x - не знаю. Дело в том, что совместимость важней удобства. Совместимость и привычность дают человеку уверенность в будушем технологии, а нововведения только нервируют. Постоянно надо что-то ковырять, что-то менять. В C# засунули столько синтаксического сахара и ненужных в обычном ООП-языке «возможностей», что они только путают разработчика. В своё время все это уже проходили, только тогда плюшками нагружали C++. И что, стал ли он от этого лучше? Из ООП-расширения для простого C, язык стал многоголовым и раздутым змеем-горынычем. Язык просто испортили. Теперь из него пора выкидывать всё лишнее. Вот в Apple поняли это, и создали простой и неперегруженный язык. А бездумное наращивание «возможностей» сыграло злую шутку со многими приложениями и технологиями. Надо уметь отсекать всё лишнее, как завещал дядюшка Оккам.

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

Версия 2.x давно должна была кануть в Лету. Но эта корявая версия всё ещё самая поддерживаемая и востребованная, и грядёт ли в ближайшие 5 лет победа 3.x над 2.x - не знаю.

Сейчас вас затроллят. Скажут, что сравнивать Питон с Явою нельзя, Питон не ЪЫнтыръпрайзъ и вообще УГ. Само упоминание того. что на Питоне много полезного софта написано уже может быть расценено как святотатство. Не даром его почти не поминали в этой ветке.

Кстати, я почти готов к переходу на Python3, т.к. уже numpy и scipy портированы, pyQT тоже. Из нужных мне остались только wxPython и matplotlib.

Vudod ★★★★★ ()

Ну продолжайте же (у меня еще пиво осталось).

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

Динамически типизированные поделки не нужны. Scala нужна.

да, да, жги ещё :)

let rec d f x = match f with
   | `Var y when x=y -> `Int 1
   | `Int _ | `Var _ -> `Int 0
   | `Add(f, g) -> `Add(d f x, d g x)
   | `Mul(f, g) -> `Add(`Mul(f, d g x), `Mul(g, d f x));;
abstract class Expr
  case class Lit(f: Int) extends Expr
  case class Var[T](x: T) extends Expr
  case class Add(f: Expr, g: Expr) extends Expr
  case class Mul(f: Expr, g: Expr) extends Expr

  def d[T](f: Expr)(x: T): Expr = f match {
    case Var(y) => if (x==y) (Lit(1)) else (Lit(0))
    case Lit(_) => Lit(0)
    case Add(f, g) => Add(d(f)(x), d(g)(x))
    case Mul(f, g) => Add(Mul(f, d(g)(x)), Mul(g, d(f)(x)))
  }
shty ★★★★★ ()
Ответ на: комментарий от shty

> уже описание переменных на языке 2 толще

Честно говоря, не очень впечатляет. Ну, можно на языке 1 ввести конструкторы без отдельного описания, и что? Более того, непонятно, какое это отношение имеет к динамика vs статика - язык 1, насколько я понимаю, Ocaml.

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

Честно говоря, не очень впечатляет.

а должно?

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

ничего, просто немного лишней бесполезной работы на ровном месте, но из таких вот мелочей складывается образ языка и образ scala не всегда безупречен

непонятно, какое это отношение имеет к динамика vs статика - язык 1, насколько я понимаю, Ocaml.

эхм :) это я ночью работаю, за 2-мя зайцами погнался и прослоупочил конечно же

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

>> Ну, можно на языке 1 ввести конструкторы без отдельного описания, и что?

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


В реальности было бы что-то вроде:

type 't Expr =
Var of t
| Lit of int
| Add of t*t
| Mul of t*t;;

так что в комактности Скала проиграет только за счет использования ключевых слов вместо спецсимволов.

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

В реальности было бы что-то вроде:

type 't Expr =
Var of t
| Lit of int
| Add of t*t
| Mul of t*t;;

почему?

так что в комактности Скала проиграет только за счет использования ключевых слов вместо спецсимволов.

компактность здесь не более чем побочный продукт работы системы вывода типов

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

> почему?

В реальных трансляторах на Ocaml было так. Наверное, есть в этом профит.

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

> по сравнению с Java жуткий тормоз. Всего в три раза. Примерно во столько же, во сколько ява медленнее плюсов. Не серьезно.

Но синтаксический сахар делает язык более сложным. Постоянное добавление фичей делает язык очень раздутым

Поэтому var не нужен, и писать развесистые типы дженериков с каждой стороны = это клево? Поэтому dynamic не нужен, ведь все можно сделать через рефлексию? Поэтому нам не нужны лямбды и делегаты, ведь их можно сэмулировать с помощью анонимных классов? Поэтому нам не нужен linq даже для простой работы с коллекциями, ведь есть foreach. Ой, а ведь это тоже сахар относительно классического for.

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

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

> Интересно, почему в яве так поздно появились дженерики, Гослинг считал, что это приведет к излишнему усложнению языка?

Ну вообще-то «появились» они раньше чем в С#. А глобально - потому что жаба была очень распространена с сотнями реализаций - из этого проистекает что тамошние ынтырпрайзеры очень переживали о совместимости всего и вся. Микрософту об этом переживать не надо было - кто там на то время тем дотнетом пользовался. Да и сейчас:

«Therefore unless an application is tested against 4.0 (in which case it has supportedRuntime=v4.0.*), it is better not to run it on 4.0 rather than taking the chances and failing the app later because of the breaking changes.» (C) Karel Zukmund, Microsoft.

Если б Сан такое отмочил, его бы ногами избили в подворотне.


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

> компактность здесь не более чем побочный продукт работы системы вывода типов

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

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

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

Что касается .NET-а никто не мешает запускать старые приложения на старом рантайме, тут никаких проблем нет.

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

> Постоянно надо что-то ковырять, что-то менять.

Покажи конкретно, что тебе пришлось переписать при переходе с одной версии C# на другую.

В C# засунули столько синтаксического сахара и ненужных в обычном ООП-языке «возможностей», что они только путают разработчика.

Не осилил так и напиши.

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

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

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

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

Если бы в первом абзаце после let rec еще что-то можно было понять. да и второй тоже труднопонимаемый

ну так чтобы понимать надо упереть анус в стул, и запилить пару проектов на F#/O'Caml и Closure и тогда проблема снимется

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

>Путь вечной обратной совместимости это путь в никуда

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

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

Рантайм окамля не тредсейфный и использует один большой лок аля питон

The Caml run-time system is not reentrant: at any time, at most one thread can be executing Caml code or C code that uses the Caml run-time system. Technically, this is enforced by a “master lock” that any thread must hold while executing such code.

http://caml.inria.fr/pub/docs/manual-ocaml/manual032.html

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

> переживали о совместимости всего и вся

Да я-то как раз не против.

Суть в том, что отсутствие плюшек в яве и их присутствие в C# связано не с тем, что эти плюшки - никому не нужный сахар, а со вполне резонными соображениями совместимости.

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

Рантайм окамля не тредсейфный и использует один большой лок аля питон

может Вас ещё и green threading смущает?

и да, если всё так плохо, то почему у меня работает mldonkey и хлеба не просит? :)

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

> может Вас ещё и green threading смущает?

Green threading это как раз хорошо.

Но в ocaml-е из-за большого лока все потоки выполняются по очереди, т.е. всё упирается в производительность одного ядра.

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

Но в ocaml-е из-за большого лока все потоки выполняются по очереди, т.е. всё упирается в производительность одного ядра.

ну так и зелень тоже на одном ядре обычно вертится

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

Совсем не обязательно.

В ghc например можно выбирать между однопоточной моделью и гибридной.

В гибридной модели M потоков операционной системы (например M = количество ядер) выполняют N зеленых потоков.

anonymous ()

>Новая функция command chain в области улучшения синтаксиса, заключающаяся в возможности записи обращений ко вложенным методам цепочкой без необходимости ставить круглые скобки и точки, что позволяет в ряде случаев писать код в виде вполне понятных предложений

Обезьяны открывают для себя конвейерные операторы! И да, не сравнивайте ваши скриптовые мочеподелки со скалой.

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

Для бизнес-процессов важна стабильноть и совместимость. В некоторых конторах специализированный софт работает уже несколько десятилетий по графику 24/7 с остановкой только на профилактику. И переписывать то что работает, внося в работу предприятия риск простоев и проблему потери данных, и денег - это не правильно. Деньги и данные важнее прихоти служебных лошадок, исполнителей под названием программисты. И решать стабильной должна быть технология или фичастой должны люди ответсвенные(начальники IT-департаментов и менеджмент компаний). а не рыцари клавиатуры с горящими глазами, для которых новые фичи - это главное. Деньги и информация приносящая деньги - вот единственная ценность, которую должны почитать и защищать работники крупных компаний. MS проявила гениальную прозорливость десятилетиями сохраняя совместимость основных Win32 API. Я писал на Win32 API приложения, которые работали во всех версиях Win9x и WinNT. И это было правильно с точки зрения корпоративных клиентов компании. Мало того, многие подобные приложения без труда запускаются и под OS/2. Вот это было круто, если учесть что приложения пятилетней давности под другие ОС обычно не работают из-за смены рантаймов и их API. Меняя что-то, чем люди пользуются всю жизнь, надо помнить главное правило медицины: не навреди! К сожалению многие разработчики думают только о новых фичах, и крутых маркетинговых ходах. А на Java завязано столько всего, что если сломать совместимость - страшно даже подумать о последствиях.

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

Я C# не изучал, винду дома не держу и попробовать это счастье не могу. Слишком много денег за такой убогий продукт как Windows хотят получить его производители. На эти деньги можно купить новое железо, или новенькую игровую приставку. Я привык платить только за реальные вещи, не за воздух. Поэтому лучще куплю себе Play Station 3, очень люблю продукцию Sony, чем диск с IT-помоями за те же деньги. А вот PAINT.NET в своё время пытался на Linux под Mono собрать. Не вышло. Нашёл потом специальный Mono-порт этого приложения, но в отличии от оригинала он работал не стабильно. А многие WinForms приложения у меня вообще отказывались собираться. Языка я не знаю, переписать эти приложения для Mono не мог. В результате я понял одно: везде работает без перекомпиляций и правки кода только Java. Python-приложения не всегда работают, так-как некоторые сторонние библиотеки для Python написаны только под Unix-like приложения. Писал я как-то на PyGTK и Cairo одно приложение для Windows и Linux(только для личного пользования). И из-за либы librsvg огрёб проблеммы под Windows. Просто не было тогда librsvg-биндинга под Windows. Теперь то уже всё есть, всё работает. А тогда не было. А .NET как прилолжения на Qt-вроде должно работать везде, а на практике приложения иногда юзают какие-то платформозависимые вызовы, и прощай кроссплатформенность. Жёсткая позиция Sun/Oracle насчёт сохраниния обязательной соместимости и одинаковой работы на всех платформах заслуживает уважения. Ведь это основная идея всей платформы. А .NET на самом деле не гарантирует работу ващего приложения на разных платформах, наоборот - она привязывает вас к одному производителю. Сколько в мире реализаций Java? А в мире .NET есть только один производитель, ведь Mono не является полноценной реализацией этой платформы. То есть, де факто у нас есть только одна платформа под одну ОС, и одну аппаратную архетиктуру. Сравнивать после этого .NET и Java просто не корректно. Они постороенны на разных идеях, и .NET не может заменить Java(он просто не заведётся на куче разных аппаратных платформ и различных ОС) на её рынке, а Java не может заменить .NET на рынке приложений для платформы Windows. Эти технологии различаются в своей идеологии, и их даже сравнивать не корректно. Сравните ещё С и SQL, или XQuery:)

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

>> и попробовать это счастье не могу

Моно.

В результате я понял одно: везде работает без перекомпиляций и правки кода только Java.

Что, и JNI? Ты правда никогда не видел написанных на яве программ, которые только на винде пускаются?

Они постороенны на разных идеях, и .NET не может заменить Java

В энтерпрайзе - нет. На десктопах - уже.

он просто не заведётся на куче разных аппаратных платформ и различных ОС

Хык-хык. Для моего гламурного айфона можно писать на сишарпе, а на яве нельзя.

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

>>Для бизнес-процессов важна стабильноть и совместимость. В некоторых конторах специализированный софт работает уже несколько десятилетий по графику 24/7 с остановкой только на профилактику. И переписывать то что работает, внося в работу предприятия риск простоев и проблему потери данных, и денег - это не правильно. Деньги и данные важнее прихоти служебных лошадок, исполнителей под названием программисты. И решать стабильной должна быть технология или фичастой должны люди ответсвенные(начальники IT-департаментов и менеджмент компаний). а не рыцари клавиатуры с горящими глазами, для которых новые фичи - это главное. Деньги и информация приносящая деньги - вот единственная ценность, которую должны почитать и защищать работники крупных компаний. MS проявила гениальную прозорливость десятилетиями сохраняя совместимость основных Win32 API. Я писал на Win32 API приложения, которые работали во всех версиях Win9x и WinNT. И это было правильно с точки зрения корпоративных клиентов компании. Мало того, многие подобные приложения без труда запускаются и под OS/2. Вот это было круто, если учесть что приложения пятилетней давности под другие ОС обычно не работают из-за смены рантаймов и их API. Меняя что-то, чем люди пользуются всю жизнь, надо помнить главное правило медицины: не навреди! К сожалению многие разработчики думают только о новых фичах, и крутых маркетинговых ходах. А на Java завязано столько всего, что если сломать совместимость - страшно даже подумать о последствиях.

Что касается .NET-а никто не мешает запускать старые приложения на старом рантайме, тут никаких проблем нет.

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