Насколько стабильный язык Groovy?
Добавьте идентификаторы в массив.
var childDivs = document.getElementById('onlineDrop').getElementsByTagName('button');
childIds = [];
for (var i = 0; i < childDivs.length; i++) {
childIds.push(childDivs[i].id);
}
console.log(childIds);<div id="onlineDrop">
<button id="222222"></button>
<button id="333333"></button>
<button id="444444"></button>
</div>5 ответов
Edit: Here almost four years later and Groovy has become much more solid.
I can wholeheartedly recommend it for production grade projects.
I've been using Groovy to support production applications for a while and for that purpose it is stable enough. As for actually having Groovy in bona fide production code; I don't think I would do that. Groovy does too many surprising things. It has gotten much better in this regard over the past year or so, but every once in awhile I will run into a bug that is a bit difficult to track down because of the generated code (my issues seem to have revolved around scoping).
I have gotten away from Groovy (though the stuff that we use that is simple and solid is still around) and have used Python (jython implementation), which has been far more predictable in my opinion. Also, python trumps Groovy in readability.
You can write some very interesting code in Groovy with closures and operator overloading and whatnot.
These languages are used for convenience and speed on ancillary code...stuff that can be switched out on the fly if need be. None of it is in production. I don't think I would put either in production unless it was as a stopgap to get something critical out of the door in a major hurry or as a proof of concept or prototype.
And in the case of putting it in actual production, it would have to be in the most dire of circumstances and I would assign someone to rewrite it in pure Java for the next release. I am 98% sure that either would be fine in production but that 2% is too much unnecessary risk.
У нас есть несколько производственных приложений, работающих на Grails (используя Groovy в качестве языка). Пока никаких проблем не возникло. Что касается совместимости с JVM, взгляните на то, как мало изменился байт-код JVM за последние 5 лет ... как была добавлена 1 инструкция, и ни одна из них не стала устаревшей.
Будут ли выпущены новые версии Groovy в следующем году? Да. Вы будете обязаны измениться к ним? Нет. Хотя вы, возможно, захотите, 1.6 - огромное улучшение скорости.
Что подводит нас к главному недостатку Groovy, проблеме скорости. Очевидно, Groovy медленнее, чем прямая Java. Текущее число медленнее до 10 РАЗ для определенных действий. Тем не менее, ваш процессор является узким местом в вашем приложении? Для нас это в основном доступ к БД и задержка. Если для вас то же самое, что имеет значение, если процессор тратит 200 мс на обработку запроса страницы вместо 35 мс?
Это единственная проблема с Groovy? Нету. Динамические языки испытывают трудности с рефакторингом, поскольку нигде в коде не обязательно есть полная спецификация класса. Однако это частично компенсируется меньшим размером кода, что облегчает поиск мест для изменения кода.
В любом случае, Groovy - прекрасный язык для производственного использования. Смешайте его с Java для своего «критического» кода, если вы боитесь надежности. Это ЛУЧШАЯ часть Groovy ... как легко она смешивается с классами Java.
В настоящее время я изучаю использование Groovy только для написания юнит-тестов. Это имеет эффект
- Позволяет выполнять утомительную часть написания тестов в синтаксисе, который немного проще, чем Java.
- Сохраняет Groovy-код в производстве.
- Позволяет писать большую часть кодовой базы не на языке Java.
Конечно, мы еще не начали, но это, по крайней мере, мой способ попытаться внедрить альтернативные языки JVM в наши новые проекты (и, возможно, существующие). У меня те же проблемы, что и у вас, и даже больше в отношении производительности, чем стабильности.
Я играл с Groovy около месяца. Простота потрясающая, и динамические языковые возможности тоже действительно классные. Тем не менее, скорость, безусловно, является проблемой. Кроме того, отличная консоль действительно отстой. Вы не можете делать то, что можете, например, в питоне. Время от времени мне приходится перезагружать консоль, повторно импортировать и т. Д. Она также постоянно забывает значения, которые я помещаю в переменные в режиме консоли; как-то мистически они выходят за рамки. (Это из-за JVM? Я не знаю.) Я не могу придумать пример из головы, но поведение, которое я получаю в консоли Groovy, отличается от поведения, которое я получаю в консоли Grails, и отличается от того, что я получаю, просто написав код в скрипте.
Еще несколько предупреждений. Обратите внимание, что Groovy почти, но не на 100% совместим с Java. Например, это не скомпилирует:
public class HelloWorld {
public static void main(String args[]) {
System.out.println( "Hello, world!\n");
}
}
Также взгляните на Как получить classpath в Groovy?
Языки сценариев развиваются «слишком быстро» в аспекте синтаксических особенностей.
Если вы хотите язык для JVM, который останется совместимым для
много лет
Java - ваш единственный выбор;)
Кстати, я не думаю, что читаемость кода обеспечивается скриптовым языком автоматически.