Язык — объектный, так как все есть объект.
А программирование на нем — это как получиться, пишем тоько процедуры — будет процедурное, строим иерархию классов — будет ООП, используем везде лямбду будет(правда очень своеобразное) функциональное программирование. От программиста вобщем зависит:)
Ну и в чем достижение? Просто кодировалка/читалка QR кода?
Тогда к чему все эти пафосные слова про «зажравшихся буржуев монополистов»?
Ктому же в рунете уже есть такие проекты. На той же википедии можно посмотреть.
Все равно не понял:) Зачем каждые полгода выпускать изменения для языка?
Наоборот, один раз хорошо продумали синтаксис, а дальше изменения на уровне сторонних библиотек и фреймворков.
Вон у си самый используемый стандарт C99, по вашей логике си отстой?:)
А что не так с монгрелом?
Если я делаю маленький сайтик, то я пускаю рельсы через fcgi под lighttpd например.
А если это высоконагруженная система — то кластер монгрелов, в чем тут проблема?
Меня должно смущять что драйвер частично написан на си? Почему?
>Да и вообще просто глупо спорить, что библиотеки у java лучше и их больше.
Ага? прямо так все больше и лучше?:) А конкретные примеры?
Мавен, это не репозитарий библиотек, а тулза для сборки приложений если я не ошибаюсь конечно.
Покажите например как вы jdom например поставите с помощью мавена?
Проведите, интересно будет посмотреть:) Но как не крути, этот оверхэд всеравно остается. Что для небольших проектов совсем не хорошо.
>куда удобнее/безопаснее нативного кода
Какое-то странное заявление, только если тем что сломать чтонибудь нативным кодом проще? Ну дак можно извернуться и через JNI также сделать:)
Про (1-3) понятно, это больше про JRuby чем CRuby.
>2. Проще портировать в обратном направлении для улучшения производительности
Там же один и тот же байткод. Или груви компилятор менее оптимизированный?
>Я бы не называл Groovy в качестве конкурента Ruby.
Я бы даже сказал что для людей из империи Java Ruby бессмылен, и точно так же Groovy, для тех кто не на Java:)
Хотя, когда Rails набирал популярность, очень много именно Java программеров перешли на Ruby.
>итого «юзабельного» развития языка нету
не понял как вы пришли к такому выводу:)
>второй — это проблемы с «хостингом»
Разве есть такая проблема? Всмысле с шаред хостингом? Покажите мне шаред хостинг для Groovy:) У Groovy гораздо больше проблем с этим:)
>Или давайте вспомним библиотеки под ruby, драйвера к бд итд.
С какими драйверами и библиотекаи там проблимы?
Это кстати еще один плюс руби, что все библиотеки лежат в репозитарии, и устанавливаются автоматический пакедж менеджером. Нужен драйвер для mysql? Пожалуйста:
gem install mysql
И у нас после этой простой комманды появился драйвер для myql:)
А в Groovy?
>съело 28 мегабайт
Ага, пустое приложение, а на CRuby 4м уже работающее.
>относительно java/groovy плюс это с большой натяжкой, скорее минус
Почему? Только не надо ссылаться на бенчмарки типо «Java 2 times Faster then C++»:)
Хм, когда писал на Java, использовал только InelliJ IDEA, нк тормозило и норм работало.
А RubyMine я даже не смотрел, меня вполне gedit устраивает:)
Но очень странно что у RubyMine такой регресс по сравнению с IDEA…
>а много ли не веб приложений написано на руби, если уж на то пошло?
Его большей частью как скриптовый язык используют, потому как очень просто встраивать.
Например в Google SketchUp.
Вобщем большая часть отличий — именно синтаксические, для тех же самых фич.
Только вот про Symbols не понял, это аналог :asdf или что то другое?
Кстати, а чем вам unless не нравиться?:)
А насчет Java-код = валидный Groovy-код
Практическое применение этому есть? Или только как облегчение перехода Java программистов.
>1.9 не предназначена для продакшена.
Естественно, это эксперементальная ветка.
Я и не говорю что нужно с CRuby на JRuby переходить, это если не устраивает скорость например. Скорость обычно основной аргумент не в пользу руби. Но это и не его задача.
Просто как я уже писал, Java платформа не во всех задачах нужна, например я пускаю Java приложение (будь то просто Java, Groovy или JRuby), на своем маленьком VDS с 256м памяти, и JVM половину(если не больше) этой памяти откушивает, а CRuby — 2-5м на ту же функциональность.
А если я пишу на Groovy, никуда я от JVM не денуся.
Enterprise только в больших задачах(я бы сказал даже в очень большиз) нужен.
Про серьезные проблеммы там не сказанно(опять же кроме скорости).
А если нашли bottleneck то можно написать для этого сишное расширение, или с помощью inline-ruby прямо сишный код в теле метода.
Кстати это еще один плюс руби, сишные расширение пишутся очень просто.
К томуже в конце статьи автор смотрит в сторону Sсheme, правда я бегло просматривал, может не так понял, но может у него вообще неудовлетворенность императивными языками а не руби в частности?:)
Развитие языка сейчас идет следующим образом, эксперементальная ветка 1.9, которая впоследствие станет стабильным релизом 2.0, затем JRuby, и виртуальная машина Rubinius.
Но с Rubinius и вправду сейчас глухо, там в связи с кризисом половину разработчиков поуволняли.
Первая мысль истинного рубиста — проплаченная статья!:)
С аргументами не в пользу рибивского интерпретатора я согласен. Идеальных инструментов к сожалению не бывает.
Но над исправлением этого и работают в версии 1.9. И не все с ним так мрачно как показанно в статье.
Ну вот, вы указали на минусы интерпретатора СRuby, ну а теперь, Groovy то чем лучше?
Не хотите CRuby используйте JRuby, там нет таких проблем.
А «and just isn’t… well… fun, anymore» — это уже личное мнение, и к вопросу плох руби или хорош большого отношения не имеет:)
Вобщем статья честно говоря напоминает какое-то унылое нытье что руби это уже никруто, притом совсем без аргументации.
Не путайте. Ветка 1.8 не развиваеся, в ней только багфиксы(раз так долго 1.8.7 небыло, значит мало багов?:))
Основной упор сейчас на эксперементальную 1.9. Там кстати уже и виртуальная машина появилась, так что скоро руби ускориться:)
На 1.9 происходит обкатка идей, которые потом войдут в новый стабильный релиз 2.0
А 1.9 очень даже хорошо развивается.
А программирование на нем — это как получиться, пишем тоько процедуры — будет процедурное, строим иерархию классов — будет ООП, используем везде лямбду будет(правда очень своеобразное) функциональное программирование. От программиста вобщем зависит:)
Тогда к чему все эти пафосные слова про «зажравшихся буржуев монополистов»?
Ктому же в рунете уже есть такие проекты. На той же википедии можно посмотреть.
Вот этот доклад:
www.rubyconf2008.confreaks.com/future-of-rubyvm.html
А они нужны?
>у мавена также есть зеркала с либами
Это не репозиторий языка Groovy, а дополнительная фича системы для сборки проектов:)
Наоборот, один раз хорошо продумали синтаксис, а дальше изменения на уровне сторонних библиотек и фреймворков.
Вон у си самый используемый стандарт C99, по вашей логике си отстой?:)
А что не так с монгрелом?
Если я делаю маленький сайтик, то я пускаю рельсы через fcgi под lighttpd например.
А если это высоконагруженная система — то кластер монгрелов, в чем тут проблема?
Меня должно смущять что драйвер частично написан на си? Почему?
>Да и вообще просто глупо спорить, что библиотеки у java лучше и их больше.
Ага? прямо так все больше и лучше?:) А конкретные примеры?
Мавен, это не репозитарий библиотек, а тулза для сборки приложений если я не ошибаюсь конечно.
Покажите например как вы jdom например поставите с помощью мавена?
Проведите, интересно будет посмотреть:) Но как не крути, этот оверхэд всеравно остается. Что для небольших проектов совсем не хорошо.
>куда удобнее/безопаснее нативного кода
Какое-то странное заявление, только если тем что сломать чтонибудь нативным кодом проще? Ну дак можно извернуться и через JNI также сделать:)
>2. Проще портировать в обратном направлении для улучшения производительности
Там же один и тот же байткод. Или груви компилятор менее оптимизированный?
>Я бы не называл Groovy в качестве конкурента Ruby.
Я бы даже сказал что для людей из империи Java Ruby бессмылен, и точно так же Groovy, для тех кто не на Java:)
Хотя, когда Rails набирал популярность, очень много именно Java программеров перешли на Ruby.
Итератор — это просто пример использования блока.
не понял как вы пришли к такому выводу:)
>второй — это проблемы с «хостингом»
Разве есть такая проблема? Всмысле с шаред хостингом? Покажите мне шаред хостинг для Groovy:) У Groovy гораздо больше проблем с этим:)
>Или давайте вспомним библиотеки под ruby, драйвера к бд итд.
С какими драйверами и библиотекаи там проблимы?
Это кстати еще один плюс руби, что все библиотеки лежат в репозитарии, и устанавливаются автоматический пакедж менеджером. Нужен драйвер для mysql? Пожалуйста:
gem install mysql
И у нас после этой простой комманды появился драйвер для myql:)
А в Groovy?
>съело 28 мегабайт
Ага, пустое приложение, а на CRuby 4м уже работающее.
>относительно java/groovy плюс это с большой натяжкой, скорее минус
Почему? Только не надо ссылаться на бенчмарки типо «Java 2 times Faster then C++»:)
А RubyMine я даже не смотрел, меня вполне gedit устраивает:)
Но очень странно что у RubyMine такой регресс по сравнению с IDEA…
Я больше пишу под CRuby.
>неужели всё сразу и всё заработало при переходе CRuby->JRuby?
Все рубивское и на CRuby нормально работало:)
а под итератором я имел ввиду функции типо Array.each, которым в качестве параметра передается блок.
>бОльшая понятность кода.
Всмысле для Java программиста?
Его большей частью как скриптовый язык используют, потому как очень просто встраивать.
Например в Google SketchUp.
Только вот про Symbols не понял, это аналог :asdf или что то другое?
Кстати, а чем вам unless не нравиться?:)
А насчет Java-код = валидный Groovy-код
Практическое применение этому есть? Или только как облегчение перехода Java программистов.
Естественно, это эксперементальная ветка.
Я и не говорю что нужно с CRuby на JRuby переходить, это если не устраивает скорость например. Скорость обычно основной аргумент не в пользу руби. Но это и не его задача.
Просто как я уже писал, Java платформа не во всех задачах нужна, например я пускаю Java приложение (будь то просто Java, Groovy или JRuby), на своем маленьком VDS с 256м памяти, и JVM половину(если не больше) этой памяти откушивает, а CRuby — 2-5м на ту же функциональность.
А если я пишу на Groovy, никуда я от JVM не денуся.
Enterprise только в больших задачах(я бы сказал даже в очень большиз) нужен.
Про серьезные проблеммы там не сказанно(опять же кроме скорости).
А если нашли bottleneck то можно написать для этого сишное расширение, или с помощью inline-ruby прямо сишный код в теле метода.
Кстати это еще один плюс руби, сишные расширение пишутся очень просто.
К томуже в конце статьи автор смотрит в сторону Sсheme, правда я бегло просматривал, может не так понял, но может у него вообще неудовлетворенность императивными языками а не руби в частности?:)
Развитие языка сейчас идет следующим образом, эксперементальная ветка 1.9, которая впоследствие станет стабильным релизом 2.0, затем JRuby, и виртуальная машина Rubinius.
Но с Rubinius и вправду сейчас глухо, там в связи с кризисом половину разработчиков поуволняли.
С аргументами не в пользу рибивского интерпретатора я согласен. Идеальных инструментов к сожалению не бывает.
Но над исправлением этого и работают в версии 1.9. И не все с ним так мрачно как показанно в статье.
Ну вот, вы указали на минусы интерпретатора СRuby, ну а теперь, Groovy то чем лучше?
Не хотите CRuby используйте JRuby, там нет таких проблем.
А «and just isn’t… well… fun, anymore» — это уже личное мнение, и к вопросу плох руби или хорош большого отношения не имеет:)
Вобщем статья честно говоря напоминает какое-то унылое нытье что руби это уже никруто, притом совсем без аргументации.
Основной упор сейчас на эксперементальную 1.9. Там кстати уже и виртуальная машина появилась, так что скоро руби ускориться:)
На 1.9 происходит обкатка идей, которые потом войдут в новый стабильный релиз 2.0
А 1.9 очень даже хорошо развивается.
Нет конечно. Я про то что синтаксически например блоки и итераторы на Ruby и Groovy практически идентичны.
>java-код=валидный groovy-код
В чем плюс для интеграции? То что мы можем использовать Java код в Groovy интерпретаторе не компилируя в байткод?
Да и не только для начинающих, например глава про сишные расширения.