Есть ли веские причины не использовать Groovy?

Question

Я занимаюсь разработкой LoB-приложения на Java после долгого отсутствия на платформе (потратив последние 8 лет или около того укоренившись в Fortran, C, smidgin на C ++ и, наконец, .Net).

Язык Java не сильно изменился по сравнению с тем, как я его запомнил. Мне нравятся его сильные стороны, и я могу обойти их слабые стороны - платформа выросла, и выбор множества структур, которые, похоже, делают одно и то же, как друг друга, - это отдельная история; но это может подождать еще один день - в целом я чувствую себя комфортно с Java. Тем не менее, за последние пару недель я влюбился в Groovy, и чисто с эгоистичной точки зрения: но не только потому, что это делает разработку против JVM более лаконичным и увлекательным (и, ну, в общем, «отличным») предложением чем Java (язык).

Что меня больше всего поражает в Groovy, так это врожденная ремонтопригодность. Мы все (я надеюсь!) Стремимся написать хорошо документированный, легкий для понимания код. Однако иногда языки, которые мы используем сами, побеждают нас. Пример: в 2001 году я написал библиотеку на C для перевода сообщений EDIFACT EDI в сообщения ANSI X12. Это не очень сложный процесс, хотя и немного сложный, и я подумал, что в то время я правильно задокументировал код - и я, вероятно, имел - но примерно через шесть лет, когда я вернулся к проекту (и после акклиматизации к C #), я обнаружил, что Я потерял столько C-образного шаблона (malloc, указатели и т. д.), что потребовалось три дня вдумчивого анализа, прежде чем я наконец понял, что я делал шесть лет назад.

Этим вечером я написал около 2000 строк Java (в конце концов, это день отдыха!). Я документировал настолько хорошо, насколько я знаю, но, однако, из этих 2000 строк Java значительная доля приходится на Java-котел.

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

Итак, есть ли причины не использовать Groovy?

Answer 1

Есть две причины, по которым я могу не использовать Groovy (или Jython, или JRuby):

• Если вы действительно, действительно нуждаетесь в производительности
• Если вы пропустите статическую проверку типов

Это оба большие ifs. Вероятно, производительность в большинстве приложений менее важна, чем думают люди, а статическая проверка типов является религиозной проблемой. Тем не менее, одной из сильных сторон всех этих языков является их способность смешивать и сопоставлять с нативным кодом Java. Лучшее из обоих миров и все такое.

Поскольку я не несу ответственности за ваш бизнес, я говорю: «Пойдите для этого».

Answer 2

Если вы используете Groovy, вы в основном выбрасываете полезную информацию о типах. Это оставляет ваш код "Groovy": красиво и лаконично.

Bird b 

становится

def b

Кроме того, вы можете поиграть со всеми вещами метаклассов и динамическими вызовами методов, которые являются пыткой в ​​Java.

Однако - и да Я много пробовал IntelliJ, Netbeans и Eclipse - серьезный автоматический рефакторинг в Groovy невозможен. Это не вина IntelliJ: информация о типе просто отсутствует. Разработчики скажут: «Но если у вас есть модульные тесты для каждого пути кода (хмммм), то вы можете легче реорганизовать». Но не верьте обману: добавление большего количества кода (модульные тесты) повысит безопасность масштабного рефакторинга, но не облегчит работу. Теперь вам нужно вручную исправить исходный код и модульных тестов.

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

Когда вы поймете, что концепция , представленная классом в Java, больше не нужна, вы можете просто удалить ее. В Eclipse, Netbeans и т. Д. Иерархия вашего проекта светится, как рождественская елка, и говорит вам, что именно вы облажали с этим изменением. def thing ничего не говорит компилятору (и, следовательно, вашей IDE) о том, как будет использоваться переменная, существует ли метод и т. Д. И в IDE можно только делать много предположений.

В конце концов, Java-код заполнен «образцом», но после многих рефакторингов он замешан в своей окончательной форме. И для меня это единственный способ получить качественный, читаемый код для будущих программистов, в том числе, когда эти будущие программисты - вы в будущем.

Answer 3

Две причины, по которым Scala может быть убедительной альтернативой Groovy:

• Производительность наравне с Java
• Статическая печать без помех

Answer 4

Одна из самых больших вещей, которую вы теряете, когда используете динамические языки, особенно в большой кодовой базе, - это возможность использовать IDE для перефакторинга. В современных средах разработки IDE языки, которые позволяют динамически добавлять код в объекты, просто не могут быть проанализированы, чтобы обеспечить простой способ рефакторинга, который вы можете получить из Eclipse и т. Д. Для Java, C ++ и т. Д.

Это на самом деле не тот случай, когда «Динамические языки лучше, чем статические». Используйте то, что лучше для вас. В частности, отличная особенность Groovy - вы можете смешивать и сочетать Java и Groovy в одном проекте, и все это работает на виртуальной машине. Да, Scala является еще одним примером.

Answer 5

Я думаю, что самой большой проблемой является отсутствие поддержки IDE по сравнению с Java, однако плагины для Eclipse и Netbeans постоянно улучшаются. Кроме того, если я правильно помню, Groovy не поддерживает анонимные внутренние классы, если они вам действительно нужны по какой-то причине. Я бы лично выбрал Groovy в любое время.