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

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

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

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

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

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

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

Ответ 1

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

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

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

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

Ответ 2

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

Bird b

становится

def b

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

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

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

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

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

Ответ 3

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

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

Ответ 4

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

На самом деле это не так: "Динамические языки лучше статичных". Используйте то, что лучше для вас. В частности, очень хорошая вещь о Groovy заключается в том, что вы можете смешивать и сопоставлять Java и Groovy в одном проекте, и все это выполняется на виртуальной машине. Да, Scala - еще один пример.

Ответ 5

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