Интересует, есть ли тут народ, который использует Scala для разработки? Какие остались впечатления?
Я так понял, что у Скалы есть три основные проблемы:
1. Байт-кодовая совместимости разных версий.
2. Трудно найти разработчиков.
3. Сложность. Типа, чтобы писать качественный код на Scala надо ее хорошо знать или что-то в этом роде.
У меня опыта на скале нет, так, что все проблемы почерпнуты из разных статей и могут быть вовсе и не проблемы. Хотелось бы услышать людей, которые наступали на грабли.
Здравствуйте, StanislavK, Вы писали:
SK>Добрый день,
Пишем на скале совсем недавно, но своё мнение выскажу
SK>Интересует, есть ли тут народ, который использует Scala для разработки? Какие остались впечатления? SK>Я так понял, что у Скалы есть три основные проблемы:
SK>1. Байт-кодовая совместимости разных версий.
Наверное да, пока не столкнулись.
SK>2. Трудно найти разработчиков.
Как мне кажется для нормальных джавистов перейти на скалу не проблема. К тому же, упоминание в вакансии скалы по-моему только привлечёт хороших спецов. Так что средний уровень кандидатов окажется выше, хотя они наверное и денег просить будут чуть больше.
SK>3. Сложность. Типа, чтобы писать качественный код на Scala надо ее хорошо знать или что-то в этом роде.
На скале можно писать java-подобный код без особых усилий. А вот использовать её эффективно надо учиться, это точно. Помогает чтение исходников библиотек
SK>У меня опыта на скале нет, так, что все проблемы почерпнуты из разных статей и могут быть вовсе и не проблемы. Хотелось бы услышать людей, которые наступали на грабли.
Ещё из проблем:
4. Неидеальная поддержка в IDE. С одной стороны intellisense нужен меньше из-за склонности скалы к коротким именам. С другой стороны после java всё равно немного непривычно. Лично мне пришлось ради скалы пересеть с Eclipse на IDEA, в последней поддержка чуть лучше.
5. Довольно медленная компиляция. Есть всякие SBT и FSC. Первый не очень удобно использовать из IDE. Вторым пользуюсь, но довольно часто инкрементальная компиляция обламывается и приходится делать rebuild.
Здравствуйте, RomikT, Вы писали: RT>Ещё из проблем: RT>4. Неидеальная поддержка в IDE. С одной стороны intellisense нужен меньше из-за склонности скалы к коротким именам. С другой стороны после java всё равно немного непривычно. Лично мне пришлось ради скалы пересеть с Eclipse на IDEA, в последней поддержка чуть лучше.
RT>5. Довольно медленная компиляция. Есть всякие SBT и FSC. Первый не очень удобно использовать из IDE. Вторым пользуюсь, но довольно часто инкрементальная компиляция обламывается и приходится делать rebuild.
Посмотрите последний релиз scala-ide. Не такой мощный, как в IDEA, но уже вполне адекватный. Я с радостью вернулся на нее после IDEA. Главное — компиляция происходит мгновенно.
Здравствуйте, StanislavK, Вы писали:
SK>Интересует, есть ли тут народ, который использует Scala для разработки? Какие остались впечатления? SK>Я так понял, что у Скалы есть три основные проблемы:
0) Нет нормальных инструментов.
И это самое главное, на самом деле. Даже с медленной компиляцией всё не так плохо, но вот переходить на глючные Scala IDE после нормальной IDEA совсем нет желания.
Здравствуйте, LeonidV, Вы писали:
RT>>5. Довольно медленная компиляция. Есть всякие SBT и FSC. Первый не очень удобно использовать из IDE. Вторым пользуюсь, но довольно часто инкрементальная компиляция обламывается и приходится делать rebuild. LV>Посмотрите последний релиз scala-ide. Не такой мощный, как в IDEA, но уже вполне адекватный. Я с радостью вернулся на нее после IDEA. Главное — компиляция происходит мгновенно.
Смотрел пару недель назад, да. Компиляция действительно мгновенная. Только этот scala-ide у меня почему-то любит по Ctrl+space поудалять все типы из исходника. Он наверное думает, что если тип заимпортировать, то его можно больше вообще не писать Может починили уже.
Вообще, пока у нас исходников мало и время компиляции в 5-10 секунд не сильно напрягает. А IDEA даже просто попробовать хотелось, ведь не спроста она кому-то нравится
Здравствуйте, RomikT, Вы писали:
RT>Только этот scala-ide у меня почему-то любит по Ctrl+space поудалять все типы из исходника. Он наверное думает, что если тип заимпортировать, то его можно больше вообще не писать Может починили уже.
У меня багов в scala-ide не возникает. Поэтому не понял, о чем речь
Здравствуйте, StanislavK, Вы писали:
SK>Добрый день,
SK>Интересует, есть ли тут народ, который использует Scala для разработки? Какие остались впечатления?
Писал небольшой компилятор, впечатления очень хорошие, кейс-классы и паттерн-матчинг позволяют в некоторых задачах писать очень короткий и выразительный код.
Использовал Idea с fsc-режимом компилятора, компилировалось всё очень быстро, впрочем проект был не очень большой. этот компилятор периодически почему то завершал работу, надо было раз в пару часов тыкать кнопочку на тулбаре, не особо напрягало. Ещё Idea не осиливала все премудрости скаловского фреймворка для парсинга и подсвечивала красным некоторые места, которые прекрасно компилировались. Это всё было в начале этого года, возможно поддержка улучшилась, новые версии плагина для Scala выходят очень часто.
Язык не показался сложным, точнее в нём есть много вещей, в которых я даже не пробовал разбираться, всякие implicit преобразования, traits тоже не особо понял, но в целом я в дебри и не залезал, в простом режиме проблем практически не возникало.
Единственная проблема, с которой столкнулся — в стандартной библиотеке не нашёл нормального связного списка, чтобы он был быстрым и можно было быстро конткатенировать такие списки. Может быть плохо искал, или ещё чего, у них там какой то супернавороченный фреймворк для построения своих классов коллекций, я его тоже не осилил и в итоге плюнул и на коленке за 2 минуты написал простейший связной список, который в итоге решил все мои проблемы. Вообще показалось, что с коллекциями они перемудрили, разобраться в том, как они работают, достаточно сложно, миллион наследований всяких, в джаве в этом плане проще. И есть такое ощущение, что эти коллекции в итоге получились очень неэффективными. Но может быть не прав.
Здравствуйте, RomikT, Вы писали:
SK>>Добрый день, RT>Пишем на скале совсем недавно, но своё мнение выскажу
А что вас к этому сподвигло?
SK>>1. Байт-кодовая совместимости разных версий. RT>Наверное да, пока не столкнулись.
вот тут прочитал: http://lift.la/scalas-version-fragility-make-the-enterprise
В общем, из-за этой штуки использовать Скалу для продакшн приложений как-то не срастается. Как-то не забавно (или забавно, на любителя) будет перекомпилировать библиотеки под ту версию скалы которая используется в продакшине.
SK>>2. Трудно найти разработчиков. RT>Как мне кажется для нормальных джавистов перейти на скалу не проблема. К тому же, упоминание в вакансии скалы по-моему только привлечёт хороших спецов. Так что средний уровень кандидатов окажется выше, хотя они наверное и денег просить будут чуть больше. SK>>3. Сложность. Типа, чтобы писать качественный код на Scala надо ее хорошо знать или что-то в этом роде. RT>На скале можно писать java-подобный код без особых усилий. А вот использовать её эффективно надо учиться, это точно. Помогает чтение исходников библиотек
Про служность и разработчиков вот тут: http://blog.joda.org/2011/11/real-life-scala-feedback-from-yammer.html
Суть поста можно уловить просто посмотрев на фразы в болд-шрифте.
SK>>У меня опыта на скале нет, так, что все проблемы почерпнуты из разных статей и могут быть вовсе и не проблемы. Хотелось бы услышать людей, которые наступали на грабли. RT>Ещё из проблем: RT>4. Неидеальная поддержка в IDE. С одной стороны intellisense нужен меньше из-за склонности скалы к коротким именам. С другой стороны после java всё равно немного непривычно. Лично мне пришлось ради скалы пересеть с Eclipse на IDEA, в последней поддержка чуть лучше. RT>5. Довольно медленная компиляция. Есть всякие SBT и FSC. Первый не очень удобно использовать из IDE. Вторым пользуюсь, но довольно часто инкрементальная компиляция обламывается и приходится делать rebuild.
В итоге получаются одни недостатки. А достоинства-то где?
Здравствуйте, StanislavK, Вы писали: SK>В итоге получаются одни недостатки. А достоинства-то где?
Вы всегда начинаете знакомство с технологиями с критических статей? Я думаю, про Java тоже писали не мало критического 15 лет назад (на вскидку — бедный язык, медленная платформа, нет возможности использовать привычные в C++ приемы работы и т.п.).
Здравствуйте, StanislavK, Вы писали:
SK>У меня опыта на скале нет, так, что все проблемы почерпнуты из разных статей и могут быть вовсе и не проблемы. Хотелось бы услышать людей, которые наступали на грабли.
Первая, она же основная, проблема Scala в том, что это сырой язык. Конечно, сырой только по сравнению с Java. Это проявляется буквально в всем: Невнятные сообщения об ошибках, куцая документация, отсутствие литературы сравнимой по уровню с Thinking in Java или Java pitfall или Bitter Java, отсутствие наработанных best practicies, глючность инструментов, таких как статические анализаторы кода, плагины к IDE, анализаторы code coverage, профайлеры и т.п.
Вторая проблема в крутой learning curve. Сам по себе синтаксис Scala довольно птичий поэтому поначалу непросто понять что делает реальный код. Только на освоение синтаксиса уходит около месяца. Но это только начало, потому что писать на Scala в синтаксисе Java можно, но не приносит профита. Scala требует функционального подхода, поэтому еще год начинающий программист на Scala занимается тем, что изучает функциональные паттерны и воюет с языком. Борьба с языком усугубляется еще и тем, что система типов Scala достаточно сложна, многие ли Java программисты имеют представление о ко- и контрвариантности типов? Все это усугубляется тем, что категорически неясно как писать правильно, т.е. безопасно, читаемо, расширяемо и эффективно. Книжек посвященных этому еще не написано, а спросить не у кого. Те кто давно использует Scala в промышленном программировании не слишком рвутся делиться опытом.
Третья проблема в том, что Scala это достаточно тормозной язык. Черт с ней с компиляцией, хотя то что hello world компилируется по 10 секунд это неправильно. Scala генерирует не слишком эффективный байт-код, если не по производительности, так по памяти. Это издержки того факта, что байт-код JVM не заточен под Scala. Время оптимизаций еще не пришло, пока что разработчикам языка было интереснее возиться с новыми фичами.
В результате у Scala довольно узкая область применимости: DSL, работа с данными, API, импорт/экспорт, межнодовое взаимодействие в кластере, и прочие технические вещи. Бизнес логику же проще писать на Java. За последний год, у меня было всего несколько задач, которые имело смысл делать на Scala. Остальные проще было писать на Java и Python.
Здравствуйте, LeonidV, Вы писали:
LV>Здравствуйте, StanislavK, Вы писали: SK>>В итоге получаются одни недостатки. А достоинства-то где? LV>Вы всегда начинаете знакомство с технологиями с критических статей? Я думаю, про Java тоже писали не мало критического 15 лет назад (на вскидку — бедный язык, медленная платформа, нет возможности использовать привычные в C++ приемы работы и т.п.).
Да, а почему нет? Зачем мне наступать на грабли, на которые уже наступали другие? Конечно про все можно написать, что это говно, не работает и т.д. Я об этом прекрасно знаю, помнимаю, что это все субъективно, с горяча и все такое. Сюда же написал в надежде, что может кто-нить тут скажет, что мол, не, все не так плохо, зато там есть что-то такое, что все проблемы перевесит и будет, пусть не счастье, но что-то хорошее.
Пока получается, что язык неплохой, интересный, но писать что-то серьезное на Scala не стоит. Может попозже.
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, StanislavK, Вы писали:
M>Первая, она же основная, проблема Scala в том, что это сырой язык. Конечно, сырой только по сравнению с Java. Это проявляется буквально в всем: Невнятные сообщения об ошибках, куцая документация, отсутствие литературы сравнимой по уровню с Thinking in Java или Java pitfall или Bitter Java, отсутствие наработанных best practicies, глючность инструментов, таких как статические анализаторы кода, плагины к IDE, анализаторы code coverage, профайлеры и т.п.
Не согласен. Есть несколько хороших книг, самая главная — Programming in Scala от Одерски. Вполне сравнима с Thinking in Java 4ed и Хорстманном. С другими источниками тоже все более чем прилично. Начиная от сайтов http://scala-lang.org и http://docs.scala-lang.org и заканчивая IBM Developers и Stackoverflow. Фактически не было такого, чтобы я не нашел ответа на поставленный вопрос.
M>Вторая проблема в крутой learning curve. Сам по себе синтаксис Scala довольно птичий поэтому поначалу непросто понять что делает реальный код. Только на освоение синтаксиса уходит около месяца. Но это только начало, потому что писать на Scala в синтаксисе Java можно, но не приносит профита. Scala требует функционального подхода, поэтому еще год начинающий программист на Scala занимается тем, что изучает функциональные паттерны и воюет с языком.
Просто использование Scala (без написания своих библиотек) не вызывает каких-либо сложностей. Работа с замыканиями и прочем — все ok. Говорю по своему опыту и по опыту студентки, которая со мной работает. Подготовки в функциональном программировании в обоих случаях — 0. Скорость выражения своих мыслей возрастает напорядок.
Известно же, что мощные Java IDE это следствие простоты(убогости?) языка:
а). Просто написать анализаторы и прочее;
б). Без мощных IDE писать на Java было бы очень неприятно.
Текущего состояние scala-ide мне вполне хватает для разработки проекта с такой же эффективность, как при использование JDT.
M>В результате у Scala довольно узкая область применимости: DSL, работа с данными, API, импорт/экспорт, межнодовое взаимодействие в кластере, и прочие технические вещи. Бизнес логику же проще писать на Java. За последний год, у меня было всего несколько задач, которые имело смысл делать на Scala. Остальные проще было писать на Java и Python.
Где-то читал, что как раз бизнес логику очень удобно на Scala реализовывать. Сам сейчас далек от задач автоматизации бизнеса, поэтому спорить не буду.
C>0) Нет нормальных инструментов.
C>И это самое главное, на самом деле. Даже с медленной компиляцией всё не так плохо, но вот переходить на глючные Scala IDE после нормальной IDEA совсем нет желания.
C>Так что ждём Kotlin от JetBrains.
почему тогда не groovy? у него и с инструментами и с совместимостью все ок.
Здравствуйте, insighter, Вы писали:
C>>0) Нет нормальных инструментов.
C>>И это самое главное, на самом деле. Даже с медленной компиляцией всё не так плохо, но вот переходить на глючные Scala IDE после нормальной IDEA совсем нет желания.
C>>Так что ждём Kotlin от JetBrains.
I>почему тогда не groovy? у него и с инструментами и с совместимостью все ок.
Уж у groovy-то и с соместимостью проблемы бывают, а инструменты под него в принципе нормально сделать нельзя из-за динамической типизации. Да и работает он достаточно медленно. Зато компилируется быстро.
Вообще мне groovy нравится, но на роль основного языка он как-то не тянет.
Делал вот фреймворк для веба и писал на нём блог-платформу. Язык сам по себе — очень нравится. Ненавязчиво позволил мне освоить азы ФП. Система типов достаточно мощная, чтобы в неё можно было прошить изрядное количество правил бизнес-логики, что даёт хороший прирост к надёжности. Рефакторить можно размашисто и нагло, огромными итерациями, не боясь ничего поломать. (Правда после возврата на PHP на работе эта разгильдяйская привычка немедленно привела к кровавому поносу.) Книга Одерски "Programming in Scala" (2е издание) — рекомендуется, отличная работа. Хотя на поверку, при простоте ядрового синтаксиса, с сахаром они малость переборщили, иногда возникает ощущение тяжести языка; уточнить не смогу, не помню.
С документированием библиотек — гораздо хуже. И в scala team даже нет консенсуса относительно необходимости эту документацию развивать: один товарищ из scala team в рассылках с пеной у рта доказывал, что мол если ты не знаешь математическую основу ФП и т.п., то и нефиг лезть. Я, в частности, срезался на акторах (ньюансы процесс остановки актора, но тут мне просто желания/необходимости не хватило доразобраться) и на scala combinator parsers в части совместного использования лексера и парсера (хотя идея там вроде простая — Parsers[Char, Lexem] + Parsers[Lexem, AST], но как-то опять не срослось).
IDE — сущий кошмар. Я юзал Idea Community с настроенным fast compiler, потому что старый eclise plugin был вообще уродцем за гранью добра и зла. На днях они зарелизели scala eclipse plugin 2.0, хз чё за зверь. Летом были видео с сабантуйчика "scala exchange 2011", где Одерски рассказывал на тему этого нового плагина, и там мне сильно не понравилось, что компилятор цепляет только открытые файлы. Т.е. если в исходнике есть зависимости из нескольких разных файлов, их все надо открыть в редакторе, чтобы компилятор на них не ругался. Это настолько дикая дичь, что хочется верить, что они её-таки исправили. Но, повторюсь, я сам не щупал.
Инкрементальная компиляция на большом проекте тупо глючила падала, поэтому fsc нифига не помогал. Приходилось бить проект на кучу мелких модулей, что не добавляло. Я правда юзал scala 2.8.3 ЕМНИП, что-то у меня там при попытке перехода на 2.9 с полгода назад сломалось (регрессия в компиляторе), с тех пор не пробовал. Может, сейчас нормально.
В целом, глюки они, надеюсь, вычистят, а хорошая вещь останется.
Здравствуйте, insighter, Вы писали:
C>>И это самое главное, на самом деле. Даже с медленной компиляцией всё не так плохо, но вот переходить на глючные Scala IDE после нормальной IDEA совсем нет желания. C>>Так что ждём Kotlin от JetBrains. I>почему тогда не groovy? у него и с инструментами и с совместимостью все ок.
Нет статической типизации -> в морг.
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, StanislavK, Вы писали:
M>Вторая проблема в крутой learning curve. Сам по себе синтаксис Scala довольно птичий поэтому поначалу непросто понять что делает реальный код. Только на освоение синтаксиса уходит около месяца. Но это только начало, потому что писать на Scala в синтаксисе Java можно, но не приносит профита.
1. val и вообще вывод типов
2. однострочные свойства вместо кучи бойлерплейтного кода с геттерами-сеттарами
3. замыкания
3.1 функциональный стиль работы с колекциями
4. case-классы и паттерн-матчинг по ним
Сами по себе фичи очень простые в освоении, но делают программирование намного приятнее в сравнение с Java.
Здравствуйте, StanislavK, Вы писали:
SK>Интересует, есть ли тут народ, который использует Scala для разработки? Какие остались впечатления?
Мы используем. Полтора месяца как один продукт запустили и оперируем, предшествовало 8 месяцев разработки силами 5 человек, для нас это был первый проект на Scala, для большей части команды — первых проект на JVM вообще. Результат понравился, будем продолжать использовать, в том числе передаем платформу внешней команде
Ощущения: неплохая задумка, но несколько "путанное" исполнение. Многие вещи ИМХО стоило сделать иначе, а некоторые — не делать вообще. Скверное качество scala-библиотек, т.к. Java-библиотеки доступны в полном объеме без ограничений или неудобств — не проблема, но нужно быть готовыми.
Кое-где лезут академические корни в виде расхлябанности и незавершенности.
Но кода реально меньше, пишется он быстрее и получается более понятным. Если предметная область ляжет на какие-то из предоставляемых фичей — может выпасть бинго — для нас это были линеаризация трейтов и матчинг на кейс-классах, существование которых сэкономило много времени, а код получился проще по структуре и более читабельный.
Резюме: наиболее оправданное применять для средних по размеру проектов (3-18 месяцев командой из 3-7 человек). Для маленьких не окупится время въезжания. Для крупных — вылезут косяки незрелой инфраструктуры.
SK>Я так понял, что у Скалы есть три основные проблемы:
SK>1. Байт-кодовая совместимости разных версий.
Слышал, но не видел. Теоретически да, на практике используются Java-окружение, и единственных Scala-код — это код непосредственно проекта.
SK>2. Трудно найти разработчиков.
Хороших разработчиков вообще найти трудно =) Из нашей практики хороший C++ или Java разработчик начинает писать код примерно через неделю и еще через две — делает это хорошо. Ну правда мы наработали определенные неформальные практики, которых и придерживаемся, не скатываясь в ребяческое "Ууу! Смотрите какой новый блестящий молоток!"
SK>3. Сложность. Типа, чтобы писать качественный код на Scala надо ее хорошо знать или что-то в этом роде.
Да, правильные практики применения не наработаны. Поэтому при отсутствии гуру, который расскажет и покажет "как нужно" — лучше идти маленькими шажками, начиная с "пишем как на Java, только на Scala" — даже в этом виде определенный выигрыш будет.
SK>У меня опыта на скале нет, так, что все проблемы почерпнуты из разных статей и могут быть вовсе и не проблемы. Хотелось бы услышать людей, которые наступали на грабли.
"Британские ученые скрестили слона со слоном. Без всякой определенной цели. Просто позырить."
M>В результате у Scala довольно узкая область применимости: DSL, работа с данными, API, импорт/экспорт, межнодовое взаимодействие в кластере, и прочие технические вещи. Бизнес логику же проще писать на Java.
Вот не соглашусь. Как раз технические вещи, которые пишутся один раз и потом используются как платформа — выигрыш минимальный. А как раз в логике — где важнее гибкости, ясность выражения логического конструкта в код и скорость написания — вот тут Scala дает выигрыш.
Здравствуйте, doarn, Вы писали:
D>Здравствуйте, Miroff, Вы писали:
M>>В результате у Scala довольно узкая область применимости: DSL, работа с данными, API, импорт/экспорт, межнодовое взаимодействие в кластере, и прочие технические вещи. Бизнес логику же проще писать на Java.
D>Вот не соглашусь. Как раз технические вещи, которые пишутся один раз и потом используются как платформа — выигрыш минимальный. А как раз в логике — где важнее гибкости, ясность выражения логического конструкта в код и скорость написания — вот тут Scala дает выигрыш.
Я склонен полагать, что выигрыш будет огромным и там, и там. Либо в банальном количестве букв, либо в плане кодирования логики фреймворков в систему типов, что даёт недостижимую в жаве защиту от ошибок неправильного использования фреймворка прикладным программистом. И кстати, насчёт DSL — я бы побоялся бога называть минимальным выигрышем тот же squeryl (LINQ-like DSL for Scala). Не говоря уже о тех же Combinator Parsers, код использования которых выглядит ровно как BNF, не требует никаких препроцессоров, жёстко контролируется типизатором и имеет при этом вполне достойную производительность.
Здравствуйте, dimgel, Вы писали:
D>Я склонен полагать, что выигрыш будет огромным и там, и там. Либо в банальном количестве букв, либо в плане кодирования логики фреймворков в систему типов, что даёт недостижимую в жаве защиту от ошибок неправильного использования фреймворка прикладным программистом. И кстати, насчёт DSL — я бы побоялся бога называть минимальным выигрышем тот же squeryl (LINQ-like DSL for Scala). Не говоря уже о тех же Combinator Parsers, код использования которых выглядит ровно как BNF, не требует никаких препроцессоров, жёстко контролируется типизатором и имеет при этом вполне достойную производительность.
Я немного о другом — как правило когда пишется какой-то общий код — в разумных пределах не очень важно сколько конкретно времени он пишется. Вот даже взять парсер, с ANTLR то же самое было бы написано ну пусть за вдвое больший срок (на самом деле я так не думаю, но гипотетически предположим) — и пофиг, эта неделя размажется на годы использования. Я хочу сказать — польза есть и если есть возможность — можно пользоваться, но качественного изменения картины от этого не получить.
А squeryl — редкостная гадость, за пределами "hello world" — прыжок на месте — попытка улететь. Замах интересный, но реализация — бяка.
Здравствуйте, doarn, Вы писали:
D>Я немного о другом — как правило когда пишется какой-то общий код — в разумных пределах не очень важно сколько конкретно времени он пишется. Вот даже взять парсер, с ANTLR то же самое было бы написано ну пусть за вдвое больший срок (на самом деле я так не думаю, но гипотетически предположим) — и пофиг, эта неделя размажется на годы использования. Я хочу сказать — польза есть и если есть возможность — можно пользоваться, но качественного изменения картины от этого не получить.
Не согласен, но спорить лениво — это будет очередной срач на тему статика/динамика.
D>А squeryl — редкостная гадость, за пределами "hello world" — прыжок на месте — попытка улететь. Замах интересный, но реализация — бяка.
Одерски летом 2011 говорил, что в их планах собственное LINQ-like двигло к языку прикрутить. Т.е. squeryl и прочие пойдут после этого лесом. Лично для меня у squeryl два существенных недостатка:
1. В лучших традициях scala DSL он интенсивно юзает implicits, в результате IDE ацки тормозит и глючит. Да и компилятор тоже.
2. Для динамической генерации запросов приходится такие дикие пляски устраивать...
В общем, затея ScalaQL с плагином была концептуально вернее: возможность прикручивания трансформации/оптимизации запросов, в частности. Но то был чисто proof of concept, развивать его оказалось никому неинтересно. Посмотрим, чего Одерски родит.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, insighter, Вы писали:
C>>>Нет статической типизации -> в морг. I>>вот и сделали статическую компиляцию в груви: http://docs.codehaus.org/display/GROOVY/2012/05/07/Static+compilation+in+the+new+Groovy+2.0+beta I>>это должно прибавить ему очков в противостоянии со скалой ) C>Скала — это вчерашний день. Котлин рулит — это реально удобный язык, в отличие от Скалы.
А можно поподробнее, на тему собственного опыта? Прочитал ихнее "comparison to scala", но окромя толковой null safety ничем особо не впечатлился.
Здравствуйте, dimgel, Вы писали:
C>>Скала — это вчерашний день. Котлин рулит — это реально удобный язык, в отличие от Скалы. D>А можно поподробнее, на тему собственного опыта? Прочитал ихнее "comparison to scala", но окромя толковой null safety ничем особо не впечатлился.
Я пишу на нём планировщик. Пока нравится.
Из плюсов:
0) НОРМАЛЬНЫЙ null-safety. В Скале его банально нет, так как Option'ы писали кретины. Банальный Option(1) == 1 будет false, так как Option не "самораспаковывается" ради никому не нужных вложенных Option'ов.
1) Сильные generic'и. Nuff said.
2) Интересная система ко/контравариантности — проще, чем в Скале.
3) Планируется интеграция со стандартными библиотеками контейнеров вместо написания своих.
4) Нелокальный выход — так что цикл for в Kotlin работает так же быстро, как и while, поддерживая нормальный break/continue.
5) Скорость компиляции.
6) Поддержка IDE.
Ну из минусов — это сырость, понятное дело. Его активно развивают, много ещё чего не сделано.
Здравствуйте, Cyberax, Вы писали:
C>3) Планируется интеграция со стандартными библиотеками контейнеров вместо написания своих.
А это точно плюс? Жавовские контейнеры рядом со скаловыми — это ссаные ясли. Без map/filter/fold жить было бы тошно. И всяких мелких, но приятных рюшечек там 100500. Из последнего, помню, порадовало, что в 2.9 появился Map.getOrUpdate() или как-то так, работающий с synchronized-коллекциями. И parallel collections опять же (хотя мне пока не пригождалось — веб же ж).
C>5) Скорость компиляции.
Гы, про слона-то я и запамятовал.
C>Ну из минусов — это сырость, понятное дело. Его активно развивают, много ещё чего не сделано.
Я только что читал вот это обсуждение. Понятно, что всяк кулик своё болото хвалит. Но мне понравился пойнт одного чувака на тему простоты: говорит, пишет парсеры регулярно, и только со скаловским DSL ему стало хорошо; а возможны ли такие средства на простых языках? Хотя среди перечисленных тобой плюсов простота вроде не фигурировала.
Здравствуйте, dimgel, Вы писали:
C>>3) Планируется интеграция со стандартными библиотеками контейнеров вместо написания своих. D>А это точно плюс? Жавовские контейнеры рядом со скаловыми — это ссаные ясли. Без map/filter/fold жить было бы тошно.
map/filter/fold уже добавлены с помощью методов-расширений.
D>И всяких мелких, но приятных рюшечек там 100500. Из последнего, помню, порадовало, что в 2.9 появился Map.getOrUpdate() или как-то так, работающий с synchronized-коллекциями. И parallel collections опять же (хотя мне пока не пригождалось — веб же ж).
И всё это несовместимо с Java, что делает всё это бесполезным примерно для тонн legacy-кода.
C>>Ну из минусов — это сырость, понятное дело. Его активно развивают, много ещё чего не сделано. D>Я только что читал вот это обсуждение. Понятно, что всяк кулик своё болото хвалит. Но мне понравился пойнт одного чувака на тему простоты: говорит, пишет парсеры регулярно, и только со скаловским DSL ему стало хорошо; а возможны ли такие средства на простых языках? Хотя среди перечисленных тобой плюсов простота вроде не фигурировала.
Возможностей для DSL в Котлине достаточно. Причём мне лично парсеры что-то не приходится писать каждый день.
Здравствуйте, Cyberax, Вы писали:
D>>И всяких мелких, но приятных рюшечек там 100500. Из последнего, помню, порадовало, что в 2.9 появился Map.getOrUpdate() или как-то так, работающий с synchronized-коллекциями. И parallel collections опять же (хотя мне пока не пригождалось — веб же ж). C>И всё это несовместимо с Java, что делает всё это бесполезным примерно для тонн legacy-кода.
Нуууу, если так рассуждать, то прогресс бы вообще на месте топтался бы. Java несовместима с тоннами legacy-кода на C++.
А с другой стороны, скала тоже чудненько интегрируется с жавовскими коллекциями. Даже есть имплиситы, перегоняющие одно в другое. А не хочешь перегонять — юзай java-классы из скалы. Не вижу проблемы.
C>Возможностей для DSL в Котлине достаточно.
Ок, возможно.
C>Причём мне лично парсеры что-то не приходится писать каждый день.
Ну это так себе аргумент. Кому-то не приходится делать ничего сложнее формоклёпства, ну и пусть он значит юзает дельфЮ. Пойнт в том, что чем проще язык, тем он сложнее для сложных задач. Т.е. простое сделать проще, а как только появляется человек со своей спецификой (парсеры, или что ещё) — он тут же огребает геморрой. Меня вот несколько вымораживает факт существования implicits. Но с другой стороны я понимаю, что без них не было бы ни scalatest, ни squeryl. Оно конечно я хз зачем этот "human-like syntax" в scalatest (мне с головой хватало влоб-тупого JUnit), но вот squeryl — это аргумент.
Здравствуйте, dimgel, Вы писали:
C>>И всё это несовместимо с Java, что делает всё это бесполезным примерно для тонн legacy-кода. D>Нуууу, если так рассуждать, то прогресс бы вообще на месте топтался бы. Java несовместима с тоннами legacy-кода на C++. D>А с другой стороны, скала тоже чудненько интегрируется с жавовскими коллекциями. Даже есть имплиситы, перегоняющие одно в другое. А не хочешь перегонять — юзай java-классы из скалы. Не вижу проблемы.
В Скале объективно неудобно использовать Java-коллекции. Нужно постоянно их преобразовывать.
C>>Причём мне лично парсеры что-то не приходится писать каждый день. D>Ну это так себе аргумент. Кому-то не приходится делать ничего сложнее формоклёпства, ну и пусть он значит юзает дельфЮ. Пойнт в том, что чем проще язык, тем он сложнее для сложных задач. Т.е. простое сделать проще, а как только появляется человек со своей спецификой (парсеры, или что ещё) — он тут же огребает геморрой. Меня вот несколько вымораживает факт существования implicits. Но с другой стороны я понимаю, что без них не было бы ни scalatest, ни squeryl. Оно конечно я хз зачем этот "human-like syntax" в scalatest (мне с головой хватало влоб-тупого JUnit), но вот squeryl — это аргумент.
А в Java есть QueryDSL, который достигает бОльших результатов без выноса мозга в squeryl.
Здравствуйте, Cyberax, Вы писали:
C>В Скале объективно неудобно использовать Java-коллекции. Нужно постоянно их преобразовывать.
Вот тут поподробнее пожалста. Что жава может делать со своими коллекциями такого, что не может скала? Вообще без преобразований.
Или же, если тебе для чего-то необходимо преобразовывать, то для чего именно? Т.е. какие такие scala api ты используешь, которые отсутствуют в java, что ты не можешь без них обойтись и вынужден преобразовывать коллекции туда-сюда?
Здравствуйте, dimgel, Вы писали:
C>>В Скале объективно неудобно использовать Java-коллекции. Нужно постоянно их преобразовывать. D>Вот тут поподробнее пожалста. Что жава может делать со своими коллекциями такого, что не может скала? Вообще без преобразований.
Речь идёт не о том, что Java может делать уникального (хотя неблокирующиеся коллекции в JDK пока что лучше, чем в Scala), а в том, что при работе с legacy-кодом Scala откровенно неудобна.
D>Или же, если тебе для чего-то необходимо преобразовывать, то для чего именно? Т.е. какие такие scala api ты используешь, которые отсутствуют в java, что ты не можешь без них обойтись и вынужден преобразовывать коллекции туда-сюда?
Вещи типа преобразования списка cons-списка (:) в колеекции, к примеру.
Здравствуйте, Cyberax, Вы писали:
C>Речь идёт не о том, что Java может делать уникального (хотя неблокирующиеся коллекции в JDK пока что лучше, чем в Scala), а в том, что при работе с legacy-кодом Scala откровенно неудобна.
Вот я и пытаюсь понять, в чём неудобство-то. Если java-классы она вполне себе юзает.
D>>Или же, если тебе для чего-то необходимо преобразовывать, то для чего именно? Т.е. какие такие scala api ты используешь, которые отсутствуют в java, что ты не можешь без них обойтись и вынужден преобразовывать коллекции туда-сюда? C>Вещи типа преобразования списка cons-списка (:) в колеекции, к примеру.
А зачем тебе cons-список, если ты с java-коллекциями работаешь? В жаве (и тем более в легаси-коде на жаве) cons-списков нет.
Здравствуйте, dimgel, Вы писали:
DD>Или же, если тебе для чего-то необходимо преобразовывать, то для чего именно? Т.е. какие такие scala api ты используешь, которые отсутствуют в java, что ты не можешь без них обойтись и вынужден преобразовывать коллекции туда-сюда?
Есть две вещи: во-первых, очень часто используется большинство функций отсюда. А во-вторых что бы передать коллекцию куда-то дальше в скала код её обычно тоже требуется привести к скаловскому виду.
Впрочем, я не считаю что написать .asScala или .asJava это ужасно сложно, да и делать это обычно приходится лишь в ограниченном количестве мест — только на стыках java-библиотек и scala-кода.
Здравствуйте, dimgel, Вы писали:
C>>Речь идёт не о том, что Java может делать уникального (хотя неблокирующиеся коллекции в JDK пока что лучше, чем в Scala), а в том, что при работе с legacy-кодом Scala откровенно неудобна. D>Вот я и пытаюсь понять, в чём неудобство-то. Если java-классы она вполне себе юзает.
Как мне в Java работать с Option'ами, к примеру? Мне хочется банального, чтобы map.get(key) показывала, что может вернуть null.
Нужно городить огород с implicit'ами. В Kotlin я просто делаю класс-дублёр, где помечаю аннотациями nullable-методы. Всё.
И таких мелочей много.
C>>Вещи типа преобразования списка cons-списка (:) в колеекции, к примеру. D>А зачем тебе cons-список, если ты с java-коллекциями работаешь? В жаве (и тем более в легаси-коде на жаве) cons-списков нет.
А в Скале есть, и хочется с ними работать. Аналогично, хочется делать такое:
Здравствуйте, Cyberax, Вы писали:
C>Из плюсов: C>0) НОРМАЛЬНЫЙ null-safety. В Скале его банально нет, так как Option'ы писали кретины. Банальный Option(1) == 1 будет false, так как Option не "самораспаковывается" ради никому не нужных вложенных Option'ов.
Ну, и слава богу, что в Scala сделано именно так, как есть сейчас. Такой же подход используется в F#, Ocaml и Haskell с точностью до названия.
Здравствуйте, dsorokin, Вы писали:
C>>Из плюсов: C>>0) НОРМАЛЬНЫЙ null-safety. В Скале его банально нет, так как Option'ы писали кретины. Банальный Option(1) == 1 будет false, так как Option не "самораспаковывается" ради никому не нужных вложенных Option'ов. D>Ну, и слава богу, что в Scala сделано именно так, как есть сейчас. Такой же подход используется в F#, Ocaml и Haskell с точностью до названия.
В Haskell Option(1)==1 вызовет ошибку типа. В Скале оно вполне скомпилится.
Здравствуйте, Cyberax, Вы писали:
C>В Haskell Option(1)==1 вызовет ошибку типа. В Скале оно вполне скомпилится.
Может быть, я не так понял. Если проблема в недопустимости самого сравнения, то здесь согласен. В общем плохо, что можно так пытаться сравнить в Scala значения разных типов.
Здравствуйте, dsorokin, Вы писали:
C>>В Haskell Option(1)==1 вызовет ошибку типа. В Скале оно вполне скомпилится. D>Может быть, я не так понял. Если проблема в недопустимости самого сравнения, то здесь согласен. В общем плохо, что можно так пытаться сравнить в Scala значения разных типов.
Это требуется самой идеологией Java — типы-то все полиморфные, а equals находится в корне типов.
Здравствуйте, Cyberax, Вы писали:
C>Это требуется самой идеологией Java — типы-то все полиморфные, а equals находится в корне типов.
Но решение было за Одерским. Если не ошибаюсь, в F# сравнить можно только значения одного типа. Да плюс еще там какое-то подобие классов типов похожих на Eq и Ord. В общем, Java была не помехой.
Здравствуйте, dsorokin, Вы писали:
C>>Это требуется самой идеологией Java — типы-то все полиморфные, а equals находится в корне типов. D>Но решение было за Одерским. Если не ошибаюсь, в F# сравнить можно только значения одного типа. Да плюс еще там какое-то подобие классов типов похожих на Eq и Ord. В общем, Java была не помехой.
Сам F# делали как можно ближе к OCaml, а не C#, отсюда и такие решения. Scala планировали сделать более-менее совместимой с Java.
Здравствуйте, Cyberax, Вы писали:
C>Аналогично, хочется делать такое: C>
C>first :: second :: third :: tail = list;
C>
C>Где list — это LinkedList. А нельзя.
Ну в общем примерно понял. Тебе мечтается seamless integration. А scala, в отличие от kotlin, не позиционирует себя как примочка к java; им эта интеграция просто как трамплин для быстрого старта самостоятельной платформы.
А вот про какой-то упомянутый тобой QueryDSL на java — это что вообще? Если отдельный препроцессор, который нужно отдельно запускать — то фи. А если нет, то чёт не верится, что средствами языка можно сделать что-либо существенно приличнее, чем JPA Query API — на который без рвотных позывов и не взглянешь.
Здравствуйте, Cyberax, Вы писали: C>Скала — это вчерашний день. Котлин рулит — это реально удобный язык, в отличие от Скалы.
Также смело можно утверждать, что это Котлин вчерашний день. Поэтому и понятней Java программисту, т.к. Java это вообще позавчерашний день.
Здравствуйте, LeonidV, Вы писали:
C>>Скала — это вчерашний день. Котлин рулит — это реально удобный язык, в отличие от Скалы. LV>Также смело можно утверждать, что это Котлин вчерашний день. Поэтому и понятней Java программисту, т.к. Java это вообще позавчерашний день.
Я понимаю, что N2 круче и всё такое. Но мне надо работать сейчас, и с JVM.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, LeonidV, Вы писали:
C>>>Скала — это вчерашний день. Котлин рулит — это реально удобный язык, в отличие от Скалы. LV>>Также смело можно утверждать, что это Котлин вчерашний день. Поэтому и понятней Java программисту, т.к. Java это вообще позавчерашний день. C>Я понимаю, что N2 круче и всё такое. Но мне надо работать сейчас, и с JVM.
Насколько я понял из материалов jetbrains, Kotlin сейчас еще не предлагается к промышленному использованию. А стабилизация API так вообще планируется не скоро.
Здравствуйте, LeonidV, Вы писали:
LV>>>Также смело можно утверждать, что это Котлин вчерашний день. Поэтому и понятней Java программисту, т.к. Java это вообще позавчерашний день. C>>Я понимаю, что N2 круче и всё такое. Но мне надо работать сейчас, и с JVM. LV>Насколько я понял из материалов jetbrains, Kotlin сейчас еще не предлагается к промышленному использованию. А стабилизация API так вообще планируется не скоро.
С текущей скоростью развития — уже к следующему году можно будет использовать.
API там вообще минимальный — он паразитирует на стандартном Java API, что есть очень правильно.
Здравствуйте, StanislavK, Вы писали:
SK>Добрый день,
SK>Интересует, есть ли тут народ, который использует Scala для разработки? Какие остались впечатления?
Использую сейчас, потихоньку читаю про всякие премудрости(бо их там хватает) — сам новичек в скале пока, но нравится.
SK>Я так понял, что у Скалы есть три основные проблемы:
SK>1. Байт-кодовая совместимости разных версий.
Пока не столкнулся.
SK>2. Трудно найти разработчиков.
Готовых — безусловно. Но джависту, вобщем, не так сложно в ней разбираться. Плюс, можно писать на скале "как на джаве", если пока не шаришь, как реализовать по-другому.
SK>3. Сложность. Типа, чтобы писать качественный код на Scala надо ее хорошо знать или что-то в этом роде.
Есть такое, если сравникать с простой как столб джавой. С другой стороны, можно забыть про громоздкие джавовские конструкции — в скале неплохо это все обдумано.
SK>У меня опыта на скале нет, так, что все проблемы почерпнуты из разных статей и могут быть вовсе и не проблемы. Хотелось бы услышать людей, которые наступали на грабли.
Из граблей пока — только некоторая недопиленность Идеевского плагина для скалы, все остальное вполне ок.
Еще компиляция долговата, но это уже придирки.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E__>Из граблей пока — только некоторая недопиленность Идеевского плагина для скалы, все остальное вполне ок.
Попробуй Eclipse — среда говно, но плагин родной от команды. По крайней мере не подсвечивает ошибки там, где их нет, в отличие от.
E__>Еще компиляция долговата, но это уже придирки.
Гыгы, нуну. Готовься бить большие проекты на кусочки.
Здравствуйте, dimgel, Вы писали:
D>Здравствуйте, Eugeny__, Вы писали:
E__>>Из граблей пока — только некоторая недопиленность Идеевского плагина для скалы, все остальное вполне ок.
D>Попробуй Eclipse — среда говно, но плагин родной от команды. По крайней мере не подсвечивает ошибки там, где их нет, в отличие от.
А какую систему сборки использовать лучше, чтобы можно было и на сервере в командной строке собрать, и в IDE работала, со всеми зависимостями.
Здравствуйте, vsb, Вы писали:
vsb>А какую систему сборки использовать лучше, чтобы можно было и на сервере в командной строке собрать, и в IDE работала, со всеми зависимостями.
Например, я использую maven. Его проекты pom.xml понимает Идея, даже вложенные.
Только в последнее время я все чаще стал использовать Emacs вместе со scala-mode вместо тяжеловесной Идеи. Просто набираю в консоли "maven clean compile", и вуаля — жарники собраны. Для одного небольшого десктопного приложения я еще прогоняю жарники через ProGuard. Набираю "maven clean package" и получаю готовый жарник с включенной в него библиотекой Scala, из которой выкинуто все лишнее. Сейчас у меня на библиотеку Scala в сжатом виде приходится килобайт 500, не больше, но я и не так много использую — в основном коллекции.
Здравствуйте, vsb, Вы писали:
vsb>А какую систему сборки использовать лучше, чтобы можно было и на сервере в командной строке собрать, и в IDE работала, со всеми зависимостями.
Я maven юзаю. В комьюнити принято юзать sbt (и eclipse-плагин на него опирается), но у меня главный аргумент против — не умеет оно аналога `mvn site` делать, а мне это существенно.
