Comments 37
С подключением:)
Как называется тема подсветки кода на картинке?
Кажется сам создатель грува говорил как то, что если бы в то время когда он наколякал свой псевдо-язык существовала бы scala то он бы этого не делал. Груви выглядит аппетитно особенно для людей кто вынужден годами терпеть отсталость java, но стоит заглянуть под капот и посмотреть как выпилен груви то становится тошно, особенно если знать тот факт что сам этот псевдо-язык задумывался для «скриптования» под jvm. Популярность языка в том или ином индексе ни очем не говорит, 10 лет назад в топ 10 входил кобол. Не обольщаейтесь прелестями груви они обманчивы, выбирайте scala за ней будущее.
Довольно часто упоминаемая цитата при обсуждении Groovy vs Scala:
Scala as the long term replacement for java/javac? by James Strachan.
Вольный перевод:
I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy.
Scala as the long term replacement for java/javac? by James Strachan.
Вольный перевод:
Честно говоря, если бы мне показали книгу Programming in Scala в 2003 году, то я бы не создал Groovy.
Да, фразу эту можно часто услышать. Только вот создатель Груви (Джеймс Стрэчен) уже давно не ее автор. Поглядите на фичи, которые были добавлены после его ухода (2007) от разработки. Это совсем другой язык.
То что Стрэчену нравится Скала, не говорит что Groovy плох. Лично сам ничего не имею против Скалы, но счастлив что у меня есть выбор.
И еще посмотрите на Gradle — как он помогает жить и как он набирает популярность. Это Groovy.
То что Стрэчену нравится Скала, не говорит что Groovy плох. Лично сам ничего не имею против Скалы, но счастлив что у меня есть выбор.
И еще посмотрите на Gradle — как он помогает жить и как он набирает популярность. Это Groovy.
Насчет Gradle, у scala есть sbt. И за груви давно тянется душок связанный с просто феноменальным отставанием в быстродействии по некоторым алгоритмическим задачам, такие своего рода кратеры на ровном месте. А так же шарм и магия груви до сих пор не позволяют запускать его под Android, хотя попытки ведутся и скажем так с большим боем, но что толку бить об стену горохом.
Да я и не спорю что Scala хороша. Просто каждый выбирает что ему подходит. Мы выбрали Groovy и довольны.
С удовольствием почитаю статью про Scala + JavaFX.
Думаю мысль там будет та же — «зачему мучаться и есть кактус, когда можно сделать все быстро и весело».
С удовольствием почитаю статью про Scala + JavaFX.
Думаю мысль там будет та же — «зачему мучаться и есть кактус, когда можно сделать все быстро и весело».
Еще отмечу, что для нас главный минус Scala был — плохая поддержка в IDEA и шикарная (!) поддержка Groovy.
Выучить язык можно. И как бы все клёво. Но писать нужно на инструменте.
Может ошибаюсь на счет поддержки в IDEA? Может что стало лучше?
На Скалу поглядываю и то что для мобильной разработки можно использовать это действительно огромный плюс.
Порою тут побольше. Спасибо.
Выучить язык можно. И как бы все клёво. Но писать нужно на инструменте.
Может ошибаюсь на счет поддержки в IDEA? Может что стало лучше?
На Скалу поглядываю и то что для мобильной разработки можно использовать это действительно огромный плюс.
Порою тут побольше. Спасибо.
Поддержка в IDEA не идеальна, но хороша, на мой взгляд. Хорошо работает даже с implicit-ами, достаточно простыми.
Есть мелкие нарекания. Вроде того, что все еще самый удобный способ создания проекта — sbt gen-idea.
Не справляется с path-dependent types, сложными выражениями с использованием shapeless и scalaz, но если вы используете такое, то поддержка IDE для вас не главное.
Есть мелкие нарекания. Вроде того, что все еще самый удобный способ создания проекта — sbt gen-idea.
Не справляется с path-dependent types, сложными выражениями с использованием shapeless и scalaz, но если вы используете такое, то поддержка IDE для вас не главное.
1) sbt до Gradle очень далеко.
2) Scala требует огромных финансовых вливаний в профессиональную подготовку программистов. Она сложна и это плохо для маленьких проектов.
2) Scala требует огромных финансовых вливаний в профессиональную подготовку программистов. Она сложна и это плохо для маленьких проектов.
Не соглашусь с вами по первому пункту, так как это очевидно субъективное мнение человека не очень хорошо знакомого с sbt, я кстати сказать не пытался донести до вас идею что gradle далеко до sbt. По второму пункту не соглашусь с вами, но соглашусь с создателем lift который в одной из своих статей пришел к выводу что есть есть две категории программистов, те которые адаптируют scala и те которые не способны этого сделать в виду определенных ограничений. Ведь scala несет в себе двойную парадигму, где нужно не просто менять язык но и подход а груви ничего такого не несет так как был задуман как скриптовый псевдо-язык.
К сожалению, создатель lift использует не совсем честные аргументы, мол скала только для опытных/умных/..., разумеется, опытный программист сможет писать на любом языке. Сложность скалы должна где-то окупаться, лучше начать с этих примеров.
К сожалению опыт к успешному освоению скалы имеет второстепенное отношение. Ведь как я уже говорил выше, скала это не просто другой язык но это и совершенно другой подход и стиль. Тут все зависит от мотивации обучаемого. Точно такая же ситуация с js, есть упрямые люди которые рассматривают его как обычный ООП язык и пишут на нем как курица лапой а ведь js это прежде всего ПОП (не путать с бородатым дядькой с кадилом). Про сложность языка я бы промолчал, так как такой величины для инженера не существует. А про окупаемость могу лишь сказать что закон Мура не работает уже пару лет, делайте выводы сами.
Разделение сложности языка и сложности стиля/подхода тоже не совсем честное, ведь раз мы пишем на скале, значит нужно использовать соответствующий поход. И, как вы сами написали, для инженера это должно быть проблемой. Остается вопрос зачем? Инженер может писать код точно так же на яве, имея сравнимое быстродействие. Если говорить о многопоточных приложениях, то какие конкретно преимущества дает скала?
Яваскрипт бы оставил для других дискуссий, но подходы имеют место быть разные, классы вполне себе появятся в es6 и я не думаю, что это случайность.
Яваскрипт бы оставил для других дискуссий, но подходы имеют место быть разные, классы вполне себе появятся в es6 и я не думаю, что это случайность.
Когда вы пишите на скале никто не обязывает вас быть FP-only хотя это рекомендовано. Не знаю знакомы ли вы с презентацией презентацией Bret Victor about the future of programming. Кстати я склонен полагать что именно из за всеобщей любви к ООП мы до сих пор топчемся на месте. Так вот в принципе инженер может писать и на эссемблере и на кобыле (cobol), имея при определенном опыте неплохую продуктивность но это нисколько не означает что его программы будут более устойчивы к ошибкам, более читаемы, менее подвержены возникновению багов и поддерживаемость такого кода будет гораздо более сложной. Абсолютно такая же проблема возникает с java vs scala & c# vs f#. И еще проблема java в том что язык почти не развивается с релиза в6. Про JS я начал ради примера неверного использования подходов.
Да не все так уж и сложно в Scala, если люди осилили Groovy, то проблем со скалой быть не должно — идеологически они весьма схожи
Соглашусь что сакала нисколько не сложнее грува в освоении. Но не соглашусь с вами насчет идеологической схожести. При взгляде сверху они наверное схожи, наверное знаете как говорят Тюменская область по очертаниям похожа на Францию, больше на Францию она ничем не похожа. Груви задумывался как динамический скриптовый псевдо-язык а вот скала это строго типизированный язык, дальше больше.
Попробуйте аннотацию @CompileStatic к методам, раз вы все равно не используете динамику.
Как вариант кроме Scala можно было бы еще Flex/Air использовать: компилируемый, строгая типизация, есть байндинги, замыкания, хорошая поддержка в Idea, есть мощные визуальные компоненты для таблиц и окон, работы с удаленными сервисами etc.
Это вы сейчас шутите или действительно советуете попробовать Flex/Air команде которая уже кучу лет разрабатывает IDE для Flex/Air?
А, сорри, не в курсе новых IDE для флекса. Это скорее были размыления о выборе сферической платформы для создания UI в космосе. Впрочем, «Eating your own dog food» было бы вполне уместно в данном случае. Почему бы не писать IDE для флекса на флексе? Не верю, что оно работало бы медленее чем на groovy. Если есть привязка к JVM, то я бы выбрал Scala — синтаксис схожий с groovy, а все-таки компилируемый и typesafe и куча продвинутых фреймворков.
1) Groovy тоже компилируемый
2) Groovy тоже мягко говоря имеет кучу продвинутых фреймворков
3) AIR для IDE убог чуть более чем полностью. Поясню:
3.1) Нет наработанной базы кода для таких вещей как у JVM.
3.2) Сам язык (а пишу я на AS уже давно и много:)) очень слабый для таких вещей, отсутствие Generic-ов, типизированных лямбд, enum-ов, грамотных коллекций и ещё кучи всего
3.3) Работать будет очень медленно при таком объёме кода
3.4) Весь IO в AIR реализован на несколько порядков хуже JVM
4) по поводу Scala. Groovy — это better Java, можно писать старый добрый Java код, и периодически начинать использовать фишки Groovy. В Scala тебя сразу же с ходу заставляют писать монстра на непривычном синтаксисе. AFAIK в Scala такая конструкция не пройдёт (поправьте если я не прав):
2) Groovy тоже мягко говоря имеет кучу продвинутых фреймворков
3) AIR для IDE убог чуть более чем полностью. Поясню:
3.1) Нет наработанной базы кода для таких вещей как у JVM.
3.2) Сам язык (а пишу я на AS уже давно и много:)) очень слабый для таких вещей, отсутствие Generic-ов, типизированных лямбд, enum-ов, грамотных коллекций и ещё кучи всего
3.3) Работать будет очень медленно при таком объёме кода
3.4) Весь IO в AIR реализован на несколько порядков хуже JVM
4) по поводу Scala. Groovy — это better Java, можно писать старый добрый Java код, и периодически начинать использовать фишки Groovy. В Scala тебя сразу же с ходу заставляют писать монстра на непривычном синтаксисе. AFAIK в Scala такая конструкция не пройдёт (поправьте если я не прав):
onAction: { t ->
ProjectDialogs.newAsProjectDialog(scene, false)
} as EventHandler<ActionEvent>
Насчет Groovy vs ActionScript убедили,
а насчет пункта 4: Scala is better Java too :)
На Scala можно писать в привычном для Java стиле, просто это быстро становится не нужно и неудобно.
В Скала тоже есть лямбда функции и блоки; каллбеки похоже выглядят. Их можно комбинировать, чейнить и пр.
см. например docs.scala-lang.org/overviews/core/futures.html
а насчет пункта 4: Scala is better Java too :)
На Scala можно писать в привычном для Java стиле, просто это быстро становится не нужно и неудобно.
В Скала тоже есть лямбда функции и блоки; каллбеки похоже выглядят. Их можно комбинировать, чейнить и пр.
см. например docs.scala-lang.org/overviews/core/futures.html
Если `onAction` — метод, принимающий `EventHandler[ActionEvent]`, то в Scala есть несколько способов организовать следующий синтаксис для вызова этого метода:
Тип указывать не надо, так как статически типизированный язык в курсе типов.
onAction { _ -> // здесь t заменили на _ чтоб подчеркнуть, что параметр не используется
ProjectDialogs.newAsProjectDialog(scene, false)
}
Тип указывать не надо, так как статически типизированный язык в курсе типов.
Нашел интересную картинку: dou.ua/lenta/articles/language-rating-jan-2013/
Индекс удовлетворенности языком — процент людей, которые работают на данном языке и выбрали бы его же в следующем своем проекте
Scala — 0.85
Groovy ~ 0.42
Интересно от пользователей Груви услышать комментарии…
Индекс удовлетворенности языком — процент людей, которые работают на данном языке и выбрали бы его же в следующем своем проекте
Scala — 0.85
Groovy ~ 0.42
Интересно от пользователей Груви услышать комментарии…
Примерно также можно еще на Kotlin'е. Тоже очень лаконично (можно и DSL еще более удобно читаемую сделать). Динамические методы чуть чуть по другому добавляются и еще некоторая разница по мелочи. Зато строгая типизация (типы в большинстве случаев автоматически выводятся).
Для того, чтобы язык пошел в люди, одного его мало… даже если он на JVM.
За груви есть Grails и Gradle, за Scala- akka, play, счас вот spray включили в typesafe stack.
А что есть у Kontlin?
За груви есть Grails и Gradle, за Scala- akka, play, счас вот spray включили в typesafe stack.
А что есть у Kontlin?
У Kotlin есть все, что есть у Java и Scala — это раз. Тот же Netty, Akka и Spray пробовал использовать — все ок. Мы, например, Grizzly используем.
А так есть уже Kara (http://karaframework.com/), Wasabi (https://github.com/hhariri/wasabi/). Exposed (https://github.com/cheptsov/Exposed) и некоторые другие вещи. Плюс и своя стандартная библиотека потихоньку растет — уже много удобного.
Мы еще через несколько месяцев свой вариант над Grizzly опубликуем (особенно классно получились DSL для html и css — вдохновлялись у Kara, но сделали еще лучше).
А так есть уже Kara (http://karaframework.com/), Wasabi (https://github.com/hhariri/wasabi/). Exposed (https://github.com/cheptsov/Exposed) и некоторые другие вещи. Плюс и своя стандартная библиотека потихоньку растет — уже много удобного.
Мы еще через несколько месяцев свой вариант над Grizzly опубликуем (особенно классно получились DSL для html и css — вдохновлялись у Kara, но сделали еще лучше).
Чтож, буду рад если взлетит… Хотя конкуренция большая. У Scala (см. ниже) — тоже есть недостатки. Но продвигают они технологию- курто. Посмотрите например на их typesafe.com/activator
Недовно был сильно вдохновлен возможностями Scala, поучился у www.coursera.org/course/progfun, сделал небольшие приложения на play и spray. О плюсах не буду, их много и они очевидны. Хотелось бы узнать мения от профи на те трудности с которыми столкнулся:
1. SBT:
— sbt далеко не интуитивен.
— настороить по локальный репозиторий maven (чтоб не дублировать скачку, использую maven) не удалось.
— зависимость sbt и проекта от различных версий scala
— зачем на 1 модуль делать \target, \project\target и \project\project\target?
2. Scala
— местами сыровата (например наткнулся на баг работы с json github.com/playframework/playframework/issues/1189)
— чужой код (особенно фраймворковский) очень сложен для понимания
— очень плохо дебажится (особенно фраймворки)
— implicit фреймворка (например в spray) начинают в trait пересекаться с моими именами (например delete, get, create)
— обнаружил зависимость от порядка объяления в trait — моя ошибка при инициализации, но достаточно запрятанная
— уже совсем субъективно- specs2 в стремлении к сделать жизнь проще больше запутывает, чем помогает
3. Playframework-шаблоны (смесь javascript c синтакисом шаблонов play)
— IDEA никак не поможет в нахождении ошибки в javascript, т.к это не javascript
— никак не отдебажить из IDE по той же причине
Понимаю, что к некоторым отосбенностям (например sbt) надо просто привыкнуть, как обходятся с остальными?
1. SBT:
— sbt далеко не интуитивен.
— настороить по локальный репозиторий maven (чтоб не дублировать скачку, использую maven) не удалось.
— зависимость sbt и проекта от различных версий scala
— зачем на 1 модуль делать \target, \project\target и \project\project\target?
2. Scala
— местами сыровата (например наткнулся на баг работы с json github.com/playframework/playframework/issues/1189)
— чужой код (особенно фраймворковский) очень сложен для понимания
— очень плохо дебажится (особенно фраймворки)
— implicit фреймворка (например в spray) начинают в trait пересекаться с моими именами (например delete, get, create)
— обнаружил зависимость от порядка объяления в trait — моя ошибка при инициализации, но достаточно запрятанная
— уже совсем субъективно- specs2 в стремлении к сделать жизнь проще больше запутывает, чем помогает
3. Playframework-шаблоны (смесь javascript c синтакисом шаблонов play)
— IDEA никак не поможет в нахождении ошибки в javascript, т.к это не javascript
— никак не отдебажить из IDE по той же причине
Понимаю, что к некоторым отосбенностям (например sbt) надо просто привыкнуть, как обходятся с остальными?
Не профи, но хочу попытаться ответить на часть вопросов.
Дело вкуса. Для меня он оказался наиболее интуитивным из всех систем сборки.
Можно взять нужную версию sbt. Можно указать версию sbt в файле `project/build.properties`.
Конфигурация sbt — программа на scala. Со всеми теме же правилами для сборки. То есть сначала надо собрать конфигурацию, а потом собрать проект. Если для упрощения конфигурации требуется подключить сторонние библиотеки, то требуется конфигурация для конфигурации.
На мой взгляд весьма удобно, что не надо изучать отдельный не логичный язык для конфигурирования проекта и можно использовать тот же, что и для проекта.
Макросы еще не признаны стабильными, но их используют. Иногда бывают проблемы. Баги везде бывают. Этот проявился в период крайне бурного развития макросов.
Спорный вопрос. Зависит от опыта. Моего опыта уже хватает чтобы код playframework казался простым, логичным и понятным.
Порядок `val`? Куда же без него… Тема поднималась многократно и многократно разобрана. В качестве решения можно везде использовать lazy val, хотя это решение явно перебор.
JetBrains пилят поддержку playframework в IDEA. Не все же сразу.
— sbt далеко не интуитивен.
Дело вкуса. Для меня он оказался наиболее интуитивным из всех систем сборки.
— зависимость sbt и проекта от различных версий scala
Можно взять нужную версию sbt. Можно указать версию sbt в файле `project/build.properties`.
— зачем на 1 модуль делать \target, \project\target и \project\project\target?
Конфигурация sbt — программа на scala. Со всеми теме же правилами для сборки. То есть сначала надо собрать конфигурацию, а потом собрать проект. Если для упрощения конфигурации требуется подключить сторонние библиотеки, то требуется конфигурация для конфигурации.
На мой взгляд весьма удобно, что не надо изучать отдельный не логичный язык для конфигурирования проекта и можно использовать тот же, что и для проекта.
— местами сыровата
Макросы еще не признаны стабильными, но их используют. Иногда бывают проблемы. Баги везде бывают. Этот проявился в период крайне бурного развития макросов.
— чужой код (особенно фраймворковский) очень сложен для понимания
Спорный вопрос. Зависит от опыта. Моего опыта уже хватает чтобы код playframework казался простым, логичным и понятным.
— обнаружил зависимость от порядка объяления в trait — моя ошибка при инициализации, но достаточно запрятанная
Порядок `val`? Куда же без него… Тема поднималась многократно и многократно разобрана. В качестве решения можно везде использовать lazy val, хотя это решение явно перебор.
JetBrains пилят поддержку playframework в IDEA. Не все же сразу.
Спасибо! Есть позиции которые с опытом уйдут. Есть — которые пилятся и уйдут. Одноко есть и те (например дебаг, множественный имплисит) которые- принципиальные.
По дебагу да, пока не очень радостно, хотя уже есть проекты, пытающиеся улучшить ситуацию (например вменяемое отображение стектрейсов). Честно говоря я пока по дебагу не скучал в scala — хватает покрытия тестами и конструкций Writer и Validation.
Множественные implicit — тут обычная проблема конфликта имен. Я свои имплиситы называю пострашнее (в духе intIsNumeric). На мой взгляд delete, get и create в качестве имен имплиситов — явный косяк, достойный багрепорта.
Множественные implicit — тут обычная проблема конфликта имен. Я свои имплиситы называю пострашнее (в духе intIsNumeric). На мой взгляд delete, get и create в качестве имен имплиситов — явный косяк, достойный багрепорта.
Груви, напомню, кто не знает, позволяет обращаться к методам доступа (геттерам, сеттерам) без приставки set/get. То есть если в классе есть метод setText — то его вызов производится через простое присвоение значения — text = «Add». Плюс при компиляции Groovy классов, публичным полям добавляются геттеры и сеттеры автоматически. Поэтому из груви не прянято вызывать метод set/get если для этого нет реальной необходимости.
Достаточно спорно. Что если у меня в классе имеется 2 поля с именами Text и text? И для обоих нужены геттеры и сеттеры?
Да и геттеры\сеттеры по умолчанию для публичных полей… Смысл паблика как раз в том, что бы можно было на прямую получать к ним доступ (вопрос наследования опустим). Зачем оверхед, пусть и не большой?
Sign up to leave a comment.
Groovy vs Java для JavaFX