Список перспективных технологий

[АццкоМото]

а это вы на аватаре?

да, но очки не продаются!

[Alexandr]

а это вы на аватаре?

да, но очки не продаются!

чорд!

[Alexander Troyansky]

Zorkus,

расскажите про Груви конспективно из каких соображений был выбран язык?
Заранее спасибо.

Попробую, но скажу сразу, вы выбирали слегка субъективно, и не делали полного сравнительного анализа. Ни на какую особую объективность не претендую, делюсь опытом. Описанное применимо к Groovy 1.7.5 - 1.8.* (на двойку мы так и не перешли), Java 1.6.29 или около того, JBoss 4.2.* кажется (не ржать).
...
Для тестов хотелось язык, который:
...
Что мы хорошего получили от Groovy:
...

О, да! Груви -- это весчь. Отличная поддержка многопоточности/многопроцессорности (в отличии от того же Питона), экспрессивность (возможность изложить в 5 строк того, что на Джаве потребовалось бы 20-30) и в тоже время очень похожий синтаксис с Жабой -- всё это очень полезно для моделирования и тестирования.

Вышла версия 2.0 с поддержкой статических проверки типов и компиляции. Хто-нить пробовал?

[dotcom]

Цены бы Groovy не было, если бы этому небрачном сыну Жабы, Питон и Руби, сделали чистый интерпретатор без подъема JVM и библиотек, чтобы можно его было использовать для скриптинга без тормозов на загрузке всего этого барахла на стартапе.

[Zorkus]

Цены бы Groovy не было, если бы этому небрачном сыну Жабы, Питон и Руби, сделали чистый интерпретатор без подъема JVM и библиотек, чтобы можно его было использовать для скриптинга без тормозов на загрузке всего этого барахла на стартапе.

Так груви тем и хорош, что это язык, горсть синтаксического сахара поверх JVM сервисов (GC, JIT, security, memory allocation etc) и с доступом к бесчисленным библиотекам Java.

Без доступа к библиотекам JDK + собственного GDK, кому он особо нужен? Писать скрипты чтобы файлы на диске нумеровать что ли? А с чистым интерпретатором тормозить будет. У Java имхо, самый зрелый и совершенный JIT сейчас, зачем отказываться от него?

[Zorkus]

Zorkus,

расскажите про Груви конспективно из каких соображений был выбран язык?
Заранее спасибо.

Попробую, но скажу сразу, вы выбирали слегка субъективно, и не делали полного сравнительного анализа. Ни на какую особую объективность не претендую, делюсь опытом. Описанное применимо к Groovy 1.7.5 - 1.8.* (на двойку мы так и не перешли), Java 1.6.29 или около того, JBoss 4.2.* кажется (не ржать).
...
Для тестов хотелось язык, который:
...
Что мы хорошего получили от Groovy:
...

О, да! Груви -- это весчь. Отличная поддержка многопоточности/многопроцессорности (в отличии от того же Питона), экспрессивность (возможность изложить в 5 строк того, что на Джаве потребовалось бы 20-30) и в тоже время очень похожий синтаксис с Жабой -- всё это очень полезно для моделирования и тестирования.

Вышла версия 2.0 с поддержкой статических проверки типов и компиляции. Хто-нить пробовал?

Я пока тока статью на dzone кажется читал от Лафоржа, но сам не пробовал надо бы. У нас 1.8.0 кажется сейчас.

[rzen]

Претензии к текущему фреймворку на яве были такие:
- при изменении кода вне того, что разрешает java hotswap (т.е. изменение сигнатур, добавление мемберов в класс etc) приходилось рестартовать JBoss, что есть waste of time

У меня были такие же претензии, пока я не познакомился с JRebel.

Самое крутое в jrebel это иконка на сайте в опции "what we support"

[dotcom]

Без доступа к библиотекам JDK + собственного GDK, кому он особо нужен? Писать скрипты чтобы файлы на диске нумеровать что ли? А с чистым интерпретатором тормозить будет. У Java имхо, самый зрелый и совершенный JIT сейчас, зачем отказываться от него?

Кол-во библиотек на подъеме можно оптимизировать. Для скрипта скорость часто нужна на подъеме. Но это все риторика. Практические проблемы понятны. Груви мне просто симпатичен, как заменитель Питона.

[Zorkus]

Без доступа к библиотекам JDK + собственного GDK, кому он особо нужен? Писать скрипты чтобы файлы на диске нумеровать что ли? А с чистым интерпретатором тормозить будет. У Java имхо, самый зрелый и совершенный JIT сейчас, зачем отказываться от него?

Кол-во библиотек на подъеме можно оптимизировать. Для скрипта скорость часто нужна на подъеме. Но это все риторика. Практические проблемы понятны. Груви мне просто симпатичен, как заменитель Питона.

Кстати, про скорость на подъем. Клиентская JVM использовала раньше class data sharing для оптимизации загрузки, чтобы не загружать все базовые классы обычным способам, с инициализацией, верификацией и прочим. Я не знаю как сейчас, и тем более не знаю используется ли то в дефолтном груви.

[Интеррапт]

Самое крутое в jrebel это иконка на сайте в опции "what we support"

Хех, точно

[Леонид Ильич Брежнев]

Страустрап не монстр же, а тоже смертный.

Ты это, не накаркай. Мужик же хороший, и еще вполне себе годный.

[Medium-rare]

Ты это, не накаркай. Мужик же хороший, и еще вполне себе годный.

Долгих лет, там, по ссылке, пара выступлений его.

[Alexander Troyansky]

С другой стороны, смотрю на Скалу с их if-then-else вместо привычного ?-: или объявление классов через ж и прочие отличия синтаксиса в отличие от "нормальных" языков. Обкурились, что ли, когда его дизайн делали?

[crypto5]

С другой стороны, смотрю на Скалу с их if-then-else вместо привычного ?-:

это потому что в функциональной парадигме if должен возвращать значение, поэтому ? становится не нужен

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

А что с классами не так?

[dotcom]

С другой стороны, смотрю на Скалу с их if-then-else вместо привычного ?-: или объявление классов через ж и прочие отличия синтаксиса в отличие от "нормальных" языков. Обкурились, что ли, когда его дизайн делали?

Да нет. Просто выпендриваться люди любят. Одерский же из академиков. Синтаксис - шминтаксис. Он несколько лет назад Скалой на всех возможных семинарах народ загружал активно. Мой бывший босс пытался его свести с HP Labs лет 5 тому назад. Те не захотели грех на душу брать. В IBM он тоже бился. Мужик пробивной, надо сказать.

[dotcom]

это потому что в функциональной парадигме if должен возвращать значение, поэтому ? становится не нужен

Это не парадигма. Он с таким же успехом мог ?: использовать.

[crypto5]

это потому что в функциональной парадигме if должен возвращать значение, поэтому ? становится не нужен

Это не парадигма. Он с таким же успехом мог ?: использовать.

Ну ? в больших выражениях менее читабельно чем if

[smikesh1]

Попробую, но скажу сразу, вы выбирали слегка субъективно, и не делали полного сравнительного анализа. Ни на какую особую объективность не претендую, делюсь опытом. Описанное применимо к Groovy 1.7.5 - 1.8.* (на двойку мы так и не перешли), Java 1.6.29 или около того, JBoss 4.2.* кажется (не ржать).

Мы прежде всего искали язык, который бы нам сущестевенно облегчил написание in-container скажем так, полу-интеграционных тестов, которые работают через Cactus (у нас есть конечно юнит тесты, но много сложной логики в области планировщиков продаж можно протестировать только запуская планировщик целиком на некотором строго ограниченном наборе данных, в том числе потому что там много логики в sql / pl sql написано).

Претензии к текущему фреймворку на яве были такие:
- при изменении кода вне того, что разрешает java hotswap (т.е. изменение сигнатур, добавление мемберов в класс etc) приходилось рестартовать JBoss, что есть waste of time
- для того чтобы создать фикстуру теста приходилось писать часто десятки и сотни строк scaffolding кода (это при том, что и так уже несколько тысяч строк кода было написано в базовых классах). Для одного прогона простейшего шедулера в "реальных" условиях надо залить данные в 12-20 таблиц в БД, на каждой выставить по десятку атрибутов
- усугублялось это тем, что в яве, как я уже сказал, нет поддержки на уровне языка коллекций, дат, пропертей (когда имена переменных занимают по 15-20 символов, реально раздражает), перегрузки операторов, простых замыканий, path expressions и прочих ништяков. Т.е. реально интеграционный тест на поддержку какого-то нового режима работы планировщика, это 500-800 строк кода.

Для тестов хотелось язык, который:

- полностью работает на JVM и полно интегрируется с Java
- более-менее близок к языку Java, чтобы джавист мог быстро начать на нем писать
- имеет достаточно синтаксического сахара
- скорость в общем-то не сильно важна, так как мы тестируем код на Java + бд, т.е. testing harness overhead небольшой все равно.

Что мы хорошего получили от Groovy:

- динамическая перегрузка классов через GroovyScriptEngine, в отличие от java hotswap
- сокращенный размер кода раза примерно в 2
- особенно стоит заметить про билдеры. Я догадываюсь, что это вещь специфичная и мы просто ей удачно нашли применение, но тем не менее. В груви, как вы знаете, есть концепция билдеров (http://groovy.codehaus.org/Builders) - по сути, поддержка для построение иерархических вложенных структур данных на уровне синтаксиса, когда вложенность структуры видна визуально сразу в коде. Мы написали свой билдер для создания большинства наших тестовых фикстур, который в сочетании с разумными дефолтами везде где можно, позволил нам сетапить фикстуру так, чтобы ее стоение было видно визуально. На примерах по ссылке видны билдеры, строящие xml документ, например. У нас был билдер, который аналогичным образом строил граф наших объектов в памяти и записывал в базу, автоматически отслеживая из relationships.
- поддержку тестирования на уровне языка - power asserts (очень вкусная вещь), поддержка моков на уровне языка etc.

Свои впечатления я в блоге описал вот тут: http://mantonov.blogspot.com/2011/04/gr ... ion-1.html

1) вот еще одна альтернатива с билдерами...
http://confluence.jetbrains.net/display ... e+builders
только котлин статически типизируемый язык
на скале прям схожу такое не сделаешь, вернее сделаешь но сложно...

2) по поводу тестов... у нас используется фитнесс и кастомный дсл для настройки этих самых фикстур ))

[Zorkus]

Бреслав и компания вообще молодцы. Если запилят типа-груви с статической типизацией и выводом И хорошей поддержкой в ИДЕ - куплю.

[smikesh1]

Бреслав и компания вообще молодцы. Если запилят типа-груви с статической типизацией и выводом И хорошей поддержкой в ИДЕ - куплю.

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

[valchkou]

народ а чем вас java не устраивает помимо Syntactic sugar?
как пример, жава не умеет работать с памятью напрямую

[Zorkus]

народ а чем вас java не устраивает помимо Syntactic sugar?
как пример, жава не умеет работать с памятью напрямую

Ну как, если очень хочется то можно конечно работать через off-heap memory, Unsafe и прочее, но обычно таки да, не нужно. Но! это ограничение платформы JVM, не Java как языка. А мы про язык говорили

[smikesh1]

народ а чем вас java не устраивает помимо Syntactic sugar?
как пример, жава не умеет работать с памятью напрямую

Ну как, если очень хочется то можно конечно работать через off-heap memory, Unsafe и прочее, но обычно таки да, не нужно. Но! это ограничение платформы JVM, не Java как языка. А мы про язык говорили

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

[АццкоМото]

народ а чем вас java не устраивает помимо Syntactic sugar?
как пример, жава не умеет работать с памятью напрямую

Ну как, если очень хочется то можно конечно работать через off-heap memory, Unsafe и прочее, но обычно таки да, не нужно. Но! это ограничение платформы JVM, не Java как языка. А мы про язык говорили

Ммм... И как мне на Джаве как языке обратиться к памяти напрямую?

[valchkou]

народ а чем вас java не устраивает помимо Syntactic sugar?
как пример, жава не умеет работать с памятью напрямую

Ну как, если очень хочется то можно конечно работать через off-heap memory, Unsafe и прочее, но обычно таки да, не нужно. Но! это ограничение платформы JVM, не Java как языка. А мы про язык говорили

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