Подтвердить что ты не робот

Каково ваше мнение о Groovy?

Для ваших проектов у вас был приятный опыт работы с Groovy? Насколько велик проект? Были ли проблемы с языком? Вы рассматривали Jython, JRuby или Clojure?

4b9b3361

ОТВЕТЫ

Ответ 1

Недавно моя команда внедрила небольшую AtomPub с помощью Grails (и подразумевается, Groovy). В целом, это был хороший опыт. Мы кратко рассмотрели чистую Java и JRuby как альтернативы, но не Jython или Clojure. Команда отправилась с Groovy, потому что она была несколько более знакомой, чем JRuby, но предлагала большую гибкость, чем Java.

Вот некоторые из проблем, с которыми мы столкнулись:

  • Меньше поддержки инструмента, чем большинство из нас привыкли (насколько велика сделка, это зависит от конкретного разработчика, о котором вы просите)
  • Ужасные трассировки стека (это может быть больше ошибок Grails, чем Groovy)
  • Благодаря тому, что вся команда изучала язык "на лету", было трудно достичь последовательного, хорошо любимого стиля.
  • Менее идеальная документация для Grails (опять же, не ошибка Groovy); документы быстро менялись, поэтому ситуация, возможно, улучшилась к настоящему времени.

Ответ 2

Мне нравится

  • Затворы
  • Разбойники
  • Чтобы не требовалось типичное избыточное объявление MyType x = new MyType(), которое можно свести к просто def x = MyType(). Тем не менее, набрав аргумент в Groovy (и мне это не нравится).
  • Чтобы вы могли быстро и легко протестировать консоль (хотя, если быть справедливым, вы могли бы сделать что-то подобное с классом Java с использованием метода main (...)).

Мне не нравится

  • Он слабо типизирован. Это влияет на производительность и приводит к ошибкам. Ничто не останавливает вас и даже не предупреждает вас о следующем:

    def x = new MyComplexClass()

// oops! accidentally made x equal to 1, that is, an integer
x = 1

// Many lines later ...

// big fat error. Now x is an Integer, so it doesn't know handle myComplexOperation
println "The result is ${x.myComplexOperation(a,b,c)}"

Он не будет работать во время выполнения.

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

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

    def add(a, b) { a + b}

    может быть потерян другим соображением:

    • Вам нужно решить, приемлемо ли, что "a" и "b" являются строкой, целым числом или созданным вами классом матрицы или что-то еще.
    • Если вы попробуете

    def add (int a, int b) {a + b}

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

Итак, теперь вам нужно добавить какую-то проверку, если вы хотите, чтобы параметры были целыми:

def (Integer a, Integer b) {
   assert a instanceof Integer
   assert b instanceof Integer
   a + b
}

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

  1. Если вызов метода способен "выбросить" ошибку, компилятор не предупредит вас, что вам нужно поставить try-catch или добавить "throws" к вашему основному методу. Если вы не знаете, что метод может генерировать исключение, вы можете бессознательно скомпилировать программу Groovy без ошибок компиляции, пока она не запустится во время выполнения!

  2. Консоль не такая уж отличная, потому что она не содержит таких предложений, как IDE, например Eclipse. Поэтому вам нужно открыть свой браузер или книгу, чтобы просмотреть доступные методы для класса. Существует еще одна небольшая ловушка: вам не нужно использовать "def" для определения переменной в консоли, но вам нужны они в программе. Так что, если вы скопируете и вставьте в свою среду IDE с консоли, но не забудьте def.

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

  4. По умолчанию свойства в Groovy являются общедоступными, а gets и sets создаются автоматически. Вы можете переопределить поведение по умолчанию, но это просто еще одна вещь, которую вы можете забыть, и препятствует инкапсуляции ваших классов. Например:

    ​class Test { String a, b }

class Test2 {
  def t = new Test()
  Test2 (String s) { t.a = s }
  ​}​​​​​​​
}

def t2=new Test2("I am public")
println t2.t.a

Ответ 3

В настоящее время я работаю над небольшим исследовательским проектом с использованием Grails. У меня не было предыдущего опыта использования Groovy, только Java.

До сих пор я очень впечатлен тем, как быстро я могу взломать что-то полезное, а функции Groovy, особенно выражения Gpath, играют большую роль в этом. Я столкнулся с несколькими ошибками в Grails, но никаких фундаментальных проблем на стороне Groovy.

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

Ответ 4

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

Нил Форд отлично провел сравнение между Groovy и JRuby http://nealford.com/downloads/conferences/Comparing_Groovy_and_JRuby(Neal_Ford).pdf

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

"С @CompileStatic производительность Groovy примерно в 1-2 раза медленнее, чем Java, и без Groovy, она примерно в 3-5 раз медленнее. (...) Это означает, что Groovy готов для приложений, производительность которых должна быть несколько сопоставима с Java.

Тест производительности: Groovy 2.0 против Java http://java.dzone.com/articles/groovy-20-performance-compared

Если вы никогда не видели динамических номеров производительности языка, прежде чем вы застряли, ознакомьтесь с результатами тестов с другими динамическими языками и веб-каркасами в реальном использовании (Groovy 1.8 - Grails 1.3.7): http://www.jtict.com/blog/rails-wicket-grails-play-lift-jsp/

Производительность всегда относительно того, что вы хотите сделать. Я использовал Groovy с 2008 года с большим успехом на крупных проектах. Это просто делает работу в нужное время.

Надеюсь, что это поможет!

Ответ 5

Я сделал небольшой проект среднего размера в Grails (и, конечно, Groovy) и наслаждался этим. На этом пути были определенные препятствия. Они включали:

  • Отсутствие хороших инструментов отладки (я решил использовать Netbeans из-за своей основной поддержки Grails, но ему не хватало отладчика... ugh)
  • Ошибки в функциях веб-потока. Grails 1.1 имеет более новую версию веб-потока Spring, который решил многие из этих проблем.
  • Слабая поддержка плагинов jquery. Мне нравится jQuery, но он не совсем поддерживался как прототип (и любая другая библиотека javascript, которая поддерживается из коробки). Тем не менее, материал AJAXy с удовольствием писал с использованием шаблонов.
    • Сложность, связанная с перечислениями и отношениями "многие ко многим" в GORM. Grails 1.1 проделает большой путь для решения этих проблем.

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

Исходя из фона Java, дорога в Grails казалась намного более управляемой, чем запуск с новым языком и набором инструментов для Rails.

Эндрю

Ответ 6

Недавно мы реализовали проект среднего размера с Groovy/Grails, Groovy, который был выбран остальной частью Java-зависимой команды. Как и в случае с Java, все заняло больше времени, чем могло бы быть. Хотя Groovy обеспечивает столь необходимое облегчение из многословного стиля Java, он по-прежнему достаточно похож, что он постоянно натыкается на контринтуитивный синтаксис. Идея HLL заключается в предоставлении инструментов программирования, которые облегчают человеческую мысль, а не требуют, чтобы люди думали точно так же, как компьютеры. Исходя из немного другого фона, хотя он довольно хорошо знаком с Java, другой выбор языка, такой как Ruby, Python или Clojure, обеспечил бы лучшую, более оперативную основу для проекта. Я с Торо, предлагая "упростить, упростить, упростить", вместо усталой Java-мантры "Amplify, усилить усиление". Надежная чистая Java, а не JVM, присоединяется к кучу пыли программирования вместе с COBOL.