Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 58
Неплохо было бы к каждому утверждению привести пример кода для сравнения Scala vs Java.
Это статья скорее о макрооссобенностях разработки, их не раскрыть в небольших примерах. Но я еще планирую написать еще одну статью с примерами.
Если вас интересуют красивые примеры, где сравнивается Java и Scala можете почитать вот
это
это
www.codecommit.com/blog/scala/roundup-scala-for-java-refugees
Имхо лучшее введение в Scala для Java программеров и заодно демонстрация разницы.
Имхо лучшее введение в Scala для Java программеров и заодно демонстрация разницы.
В целом по делу, но вот о минусах не слова ;)
Пишу на Scala, единственный минус — компилится дольше чем Java… но не столько чтоб это раздражало )
И давно пишете? Просто я тоже пишу, все нравится, но недостатков хватает. А тут тишь да гладь, прям идеал какой-то
О каких недостатках речь? Как вы определили что это именно недостаток, а не просто вам не нравится как сделано…
Частично я уже как-то отвечал вот тут habrahabr.ru/post/142356/#comment_4763930
Могу попробовать расписать немного, из того что вспомню.
1. Богатство возможностей приводит к тому, что одно и то же можно сделать очень многими способами. Это сильно затрудняет выработку единого стиля в более-менее большой команде. Безусловно для хорошего программиста мощь языка только плюс, но чтобы достичь этого уровня среднестатистическому java программисту потребуются годы. И постоянный ревью на предмет единого подхода, чтобы код не расползался. Особенно плохо перфекционистам, ибо вариантов «улучшения» кода великое множество.
2. Баги компилятора и IDE. В целом жить можно, но иногда заставит понервничать.
3. Монструозность sbt (стандартное средство сборки). Решается либо привыканием либо мавеном :)
4. Особенности компиляции в байткод. «Хрупкость» (собранные под разными скалы библиотеки могут не дружить друг с другом, одна обновившая библиотека может потребовать перекомпиляции всего проекта и т.д.). Различные проблемы с производительностью в отдельных случаях. И т.д.
И это все не мои личные предпочтения, а признанные довольно многими людьми наблюдения. Странно, что Вы программируя на скале ничего из этого не встречали.
Могу попробовать расписать немного, из того что вспомню.
1. Богатство возможностей приводит к тому, что одно и то же можно сделать очень многими способами. Это сильно затрудняет выработку единого стиля в более-менее большой команде. Безусловно для хорошего программиста мощь языка только плюс, но чтобы достичь этого уровня среднестатистическому java программисту потребуются годы. И постоянный ревью на предмет единого подхода, чтобы код не расползался. Особенно плохо перфекционистам, ибо вариантов «улучшения» кода великое множество.
2. Баги компилятора и IDE. В целом жить можно, но иногда заставит понервничать.
3. Монструозность sbt (стандартное средство сборки). Решается либо привыканием либо мавеном :)
4. Особенности компиляции в байткод. «Хрупкость» (собранные под разными скалы библиотеки могут не дружить друг с другом, одна обновившая библиотека может потребовать перекомпиляции всего проекта и т.д.). Различные проблемы с производительностью в отдельных случаях. И т.д.
И это все не мои личные предпочтения, а признанные довольно многими людьми наблюдения. Странно, что Вы программируя на скале ничего из этого не встречали.
А какие у компилятора есть баги?
См. ниже.
Вы это серьезно? У любого компилятора есть баги, просто у скаловского за счет его сложности и темпов развития они чаще попадаются. Загляните вот сюда например issues.scala-lang.org. Очень много проблем решается полной пересборкой и/или перезапуском fsc. Что касатеся тех, с которыми сталкивался лично: на определенном куске кода компилятор падал с NPE, пересборки не помогали, вытащил часть выражения в отдельный val — заработало. Еще помню были проблемы с оптимизатором байткода, уже в рантайме ругался что метод не реализован, уже не помню как решалось, наверное тоже пересборками.
issues.scala-lang.org/browse/SI-2764 Да вот, например. Фиксили больше двух лет, и то фикс еще не вышел.
Мне кажется что ошибки начинаются уже с заголовка, scala является turing-complete а java нет, так что никакое это не расширение. Не нужно рассматривать scala как очередной груви, scala на корню отличается от java, все что оба языка делят так это jvm-bytecode откуда и идет совместимость.
Теперь по недостаткам. Что бы использовать мувен со scala нужно любить страдания, вообще кто в наши дни добровольно использует maven? Исключения составляют случаи когда выбора нет. Это все равно что говорит лет 10 назад, блин ant корявый какой то, буду пользовать Makefile для java проектов.
Теперь об одном и том же разными путями, тут я с вами не согласен, если для вас например карринг и частичное применеие (вот из стана врагов) одно и тоже то на самом деле это не так. Исключения составляют случаи когда некоторые индивидуумы перейдя с быдло-java начинают пороть что то типа:
Вместо того что бы пользоваться опциональными типами. Или же что то вроде.
На самом деле таких примеров куча. Если вы хорошо знаете scala у вас никогда не возникнет впечатления двойственности реализаций той или иной фичи языка.
Теперь по недостаткам. Что бы использовать мувен со scala нужно любить страдания, вообще кто в наши дни добровольно использует maven? Исключения составляют случаи когда выбора нет. Это все равно что говорит лет 10 назад, блин ant корявый какой то, буду пользовать Makefile для java проектов.
Теперь об одном и том же разными путями, тут я с вами не согласен, если для вас например карринг и частичное применеие (вот из стана врагов) одно и тоже то на самом деле это не так. Исключения составляют случаи когда некоторые индивидуумы перейдя с быдло-java начинают пороть что то типа:
if (v == null) {
.....
return null
}
Вместо того что бы пользоваться опциональными типами. Или же что то вроде.
var list = new mutable.List()
for (el <- anotherList) {
if(el > 20) list.add(el)
}
На самом деле таких примеров куча. Если вы хорошо знаете scala у вас никогда не возникнет впечатления двойственности реализаций той или иной фичи языка.
Про turing-complete это вы наверное про систему типов, просто пропустили слово ;)? С остальным в этом абзаце полностью согласен, собственно ниже я это писал.
По поводу мавена. У Вас наверное с ним что-то личное :) Я бы не сказал что он так уж и плох. Для стандартных задач пригоден вполне. Да многословный, да негибкий, да норовит при каждом удобном случае скачать пол-интернета (но этим и сбт грешит). Но для flex, допустим, особо альтернативы нету. А вот с случае со скалой да, мавен это временное убежище, рано или поздно придется браться за sbt. Что собственно я и сделал, и немного даже уже освоился.
Что касается «одного и того же разными путями», то я совсем не карринг и не option c мутабельным накопителем имел в виду. Хотя и это тоже далеко не сразу постигается. Я про различные способы конструирования DSL, использование implicit, point free style, for-comprehension, оформления кода в конце концов. Ко мне далеко не сразу пришло понимание когда стоит что-то использовать, а когда оно лишнее. И во многих вещах я еще экспериментирую. И разговор тут не о «двойственности реализаций той или иной фичи языка», а о реализации требуемого функционала всеми этими фичами. Чтобы они помогали, а не усложняли код. А ведь на подходе еще макросы с уже практически неограниченной свободой фантазии…
По поводу мавена. У Вас наверное с ним что-то личное :) Я бы не сказал что он так уж и плох. Для стандартных задач пригоден вполне. Да многословный, да негибкий, да норовит при каждом удобном случае скачать пол-интернета (но этим и сбт грешит). Но для flex, допустим, особо альтернативы нету. А вот с случае со скалой да, мавен это временное убежище, рано или поздно придется браться за sbt. Что собственно я и сделал, и немного даже уже освоился.
Что касается «одного и того же разными путями», то я совсем не карринг и не option c мутабельным накопителем имел в виду. Хотя и это тоже далеко не сразу постигается. Я про различные способы конструирования DSL, использование implicit, point free style, for-comprehension, оформления кода в конце концов. Ко мне далеко не сразу пришло понимание когда стоит что-то использовать, а когда оно лишнее. И во многих вещах я еще экспериментирую. И разговор тут не о «двойственности реализаций той или иной фичи языка», а о реализации требуемого функционала всеми этими фичами. Чтобы они помогали, а не усложняли код. А ведь на подходе еще макросы с уже практически неограниченной свободой фантазии…
Ну насчет мавена и scala могу сказать что если вы их используете то вам например самому приходится указывать версию компилятора для библиотечки сделанной на скале а sbt делает это автоматически. За исключением некоторых особенностей возможности sbt и mouven'а эквивалентны. Геноцид в мувене начинается когда вам по той или иной причине нужно расширить спектр возможностей вашего билд-тула, а в sbt с расширяемостью все нормально.
Все равно не совсем понимаю в чем состоит проблема в «реализации требуемого функционала всеми фичами scala». Наверное здесь следует заранее определить соглашения об использовании тех или иных возможностей, например не использовать if() else if() else а по возможности всегда использовать патерн-матчинг или композицию функций вместо подхода fluent-api. Одно верно, язык очень мощный и ваш проект может легко превратится в лифт-сорц где черт ногу сломит.
Все равно не совсем понимаю в чем состоит проблема в «реализации требуемого функционала всеми фичами scala». Наверное здесь следует заранее определить соглашения об использовании тех или иных возможностей, например не использовать if() else if() else а по возможности всегда использовать патерн-матчинг или композицию функций вместо подхода fluent-api. Одно верно, язык очень мощный и ваш проект может легко превратится в лифт-сорц где черт ногу сломит.
Обожаю мавен, использую везде, все остальное кажется не таким удобным за счет отсутствия плагинов в основном.
Для бильда scala тоже?
Нет. Я использую Kotlin, понравился больше чем скала.
Хоть это и не тема здесь, сыроват он еще(m2), я вот его попробовал в связке с mouven-android-kotlin и все закончилось банально как здесь, отчасти вина мувена в этом есть.
1. Ну это меня просто не коснулось. У нас команда 3 человека всего, со стилем нет проблем.
Хотя довелось мне тут исправлять проект, который писал 1С-ник, которому пришлось дописывать проект другого программиста на scala… вот это была жесть вообще )) так что представляю о чем вы… Но точно такие же проблемы я видел и в Java проектах, поэтому не отнес это к проблемам скалы…
2. Ну собственно я совсем не придирчивый… и если IDE (тоже кстати идею пользую) где-то глюкнуло пару раз, то я просто не обратил особого внимания на это…
3. Один грянув на эту хренотень забил на нее сразу. Этож с какой укурки надо было такое изобразить не знаю… ))
Maven все отлично собирает. И кстати, SBT это надстройка над Maven, так что по сути тоже самое… но сперламутровыми пуговицами синтаксическим сахаром
4. Тоже не сталкивался, поэтому прокомментировать не могу. Всегда используем последнюю версию скалы для всего. Когда выходит новая пересобираем проект под него и все. Хотя у нас не 100500 миллионов строк… возможно для больших проектов это действительно большая проблема.
5. Проблемы производительности есть, но в 99% случаев они просто от не знания.
Хотя довелось мне тут исправлять проект, который писал 1С-ник, которому пришлось дописывать проект другого программиста на scala… вот это была жесть вообще )) так что представляю о чем вы… Но точно такие же проблемы я видел и в Java проектах, поэтому не отнес это к проблемам скалы…
2. Ну собственно я совсем не придирчивый… и если IDE (тоже кстати идею пользую) где-то глюкнуло пару раз, то я просто не обратил особого внимания на это…
3. Один грянув на эту хренотень забил на нее сразу. Этож с какой укурки надо было такое изобразить не знаю… ))
Maven все отлично собирает. И кстати, SBT это надстройка над Maven, так что по сути тоже самое… но с
4. Тоже не сталкивался, поэтому прокомментировать не могу. Всегда используем последнюю версию скалы для всего. Когда выходит новая пересобираем проект под него и все. Хотя у нас не 100500 миллионов строк… возможно для больших проектов это действительно большая проблема.
5. Проблемы производительности есть, но в 99% случаев они просто от не знания.
1. В Java гораздо меньше способов натворить делов и они легче отслеживаются, за счет относительной простоты языка более богатых инструментов. Так что проблема плохого кода имхо в скале стоит острее. Если подойти с другой стороны, то скала просто более требовательна к команде. Выше средний уровень, выше уровень тимлида, больше ревью и т.д. И этот уровень появляется не за месяцы, а за хотя бы год. Эту проблему кстати признает и сам Одерски, и обещают над ней работать.
2. Сложный скала код очень часто сносит идейскому спелчекеру башню, ну или я такой везучий
3. sbt это не надстройка над мавеном, это полностью своя система, для получения зависимостей использует не мавен, а ivy. И добавляет совсем не «сахар», а мощную систему сборки где можно подкрутить все, что угодно. Если разберешься :) Я пока еще не осилил, но простые проекты с небольшими нюансами могу делать.
2. Сложный скала код очень часто сносит идейскому спелчекеру башню, ну или я такой везучий
3. sbt это не надстройка над мавеном, это полностью своя система, для получения зависимостей использует не мавен, а ivy. И добавляет совсем не «сахар», а мощную систему сборки где можно подкрутить все, что угодно. Если разберешься :) Я пока еще не осилил, но простые проекты с небольшими нюансами могу делать.
Ага, а ivy откуда зависимости берет? ))
В итоге все равно все во круг мавена вертится…
И да, я так и не понял, для чего надо что-то подкручивать в «мощной системе сборки», чтобы собрать проект…
Мавен пока отрабатывает на 100%…
В итоге все равно все во круг мавена вертится…
И да, я так и не понял, для чего надо что-то подкручивать в «мощной системе сборки», чтобы собрать проект…
Мавен пока отрабатывает на 100%…
Ivy может использовать репозитории мавена, при чем тут сам мавен? Просто они есть, их много, и глупо их не использовать.
Да некоторые простые вещи в sbt делаются для новичка не совсем просто. Но это все скорее детские болезни, typesafe обещают все заполировать. Вы лучше расскажите как, допустим, в мавене подключить все либы из произвольной локальной папки без плясок с бубном? Хотя может, наконец, запили… Или что-то нетривиальное сделать с файлами. В мавен надо искать плагины, разбираться в документации к ним, если она есть вообще, ну или подключать ант и делать им. В sbt просто пишешь на скале все, что тебе нужно было сделать, и вот свой плагин готов.
Да некоторые простые вещи в sbt делаются для новичка не совсем просто. Но это все скорее детские болезни, typesafe обещают все заполировать. Вы лучше расскажите как, допустим, в мавене подключить все либы из произвольной локальной папки без плясок с бубном? Хотя может, наконец, запили… Или что-то нетривиальное сделать с файлами. В мавен надо искать плагины, разбираться в документации к ним, если она есть вообще, ну или подключать ант и делать им. В sbt просто пишешь на скале все, что тебе нужно было сделать, и вот свой плагин готов.
Мне тут замечание сделали, дескать у вас с мувеном что то личное, солвер, а вы пробовали писать эти самые модули расширения для него? Повторюсь, в sbt есть несколько уровней расширений на почти любой вкус и цвет. Тем более что sbt постоянно дополняется и расширяется а мувен лежит бревном уже сколько веков? По большему счету разница между мувеном 2 и 3 в том что последний использует параллельные потоки что бы скачивать половину интернета. А вы знаете почему в мувене используется хмл без атрибутов, потому что когда-то давно Вазилин(Van Zyl) не нашел подходящей либы которая бы работала с атрибутами, ответ из уст со-создателя мувена. Курам на смех.
>> Эту проблему кстати признает и сам Одерски, и обещают над ней работать.
Не иначе с помощью макросов и нового рефлекшена :-)
Не иначе с помощью макросов и нового рефлекшена :-)
Ну, монструозность sbt, наверно, нельзя относить к минусам непосредственно Scala.
Мы в качестве билдтула используем gradle и бед не знаем.
Мы в качестве билдтула используем gradle и бед не знаем.
Для меня минус, частое ограничение JVM на скомпилированный scala код.
Еще некоторые разработчкик откровенно отвратительно используют возможности языка. В последнем стабильном lift'е (2.4) есть implicit преобразования вводяшие компилятор в бесконечный цикл.
Можно по подробней, о чем речь?
При компиляции натыкался, что размер получаемого байткода не умещается во внутренние представление jvm (при использование liftового RestHelper очень легко такое словить).
Вот похожие ситуации:
www.scala-lang.org/node/7289
issues.scala-lang.org/browse/SI-1133
Вот похожие ситуации:
www.scala-lang.org/node/7289
issues.scala-lang.org/browse/SI-1133
Хотите спать крепко и высыпаться не используйте лифт.
Надеюсь к концу года, началу следующего с него слезем.
А на что перелезите, если не секрет?
Мы сейчас активно переписываем все с использованием Rest. Таких либ на scala полно (лично мне нравится unfiltered). Для db у нас сейчас lift mapper и PostgreSql. Планируем на mongo перейти, к нему мне нравится salat.
Вот неплохая библиотека: sockoweb.org/
А чем плох лифт? Пользуемся около полу года, полет нормальный. Ну т.е. без косяков, но в целом впечатление приятное.
Интересный язык, но как-то остановила попытки написать что-то реальное тесная связь с Java, субъективно куда более сильная чем у C с C++.
А мне вот кажется наоборот. По сути они делят только платформу и некоторые элементы синтаксиса. За скалой совсем другая философия и подходы. Именно поэтому я считаю неправильным говорить о скале как о Java++. Да, на скале можно писать как на better Java, но тупиковый вариант. Рано или поздно понимаешь, что большая часть java-багажа тебе не нужна.
Я больше про библиотеки.
Дак это просто прекрасно… вы представляете сколько всего уже написано для java?
А теперь представьте, что все это надо переписать на scala… этож ппц будет… язык никогда не получит популярность. Никто не будет просто так переписывать тысячи библиотек на скалу…
А теперь представьте, что все это надо переписать на scala… этож ппц будет… язык никогда не получит популярность. Никто не будет просто так переписывать тысячи библиотек на скалу…
Зачем ведь байт код то совместим? На худой конец если вы такой эстет то создайте декомпайлер bytecode -> java и радуйтесь жизни. Мы в нашей компании имеет проекты с сотнями тысяч линий кода на java и уже больше года пишем в основном на скале и никогда и ни у когда не было желания все сурцы мигрировать на scala ведь совместимость есть в обе стороны.
Я имел в виду bytecode -> scala
да, разве что иногда стоит писать враппер для Java-либы для использования всяких штук типа Option вместо null и т.д.
Ну дык и я о том же… совместимость это благо.
Ну и про совместимость в обе стороны в конечно лукавите немного…
Если Java -> Scala она 100%, то вот Scala -> Java далеко не 100%
Ну и про совместимость в обе стороны в конечно лукавите немного…
Если Java -> Scala она 100%, то вот Scala -> Java далеко не 100%
Ну насчет из java в scala должен сказать что иногда проблема находится между стулом и экраном, т.е. в проектировке. Если есть хоть малейший шанс того что ваша библиотечка будет использована из java а вы в сигнатурах ваших методов передаете параметры по имени, то можете не удивятся что вам посыпятся письма с угрозами от java пользователей. Но этот факт не отменяет совместимость байткода, только в если вы захотите передать например функцию как параметр из java вам нужно будет поднапрячься.
Смотря как считать.
Я бы сказал, что Scala -> Java тоже 100%, но в некоторых случаях это будет очень не красиво: доступ к реализациям методов в trait, к значениям по умолчанию и к object, impicit параметры.
Единственное, что уж совсем не получится, так это Manifest. Но и тут можно что-нибудь придумать.
Я бы сказал, что Scala -> Java тоже 100%, но в некоторых случаях это будет очень не красиво: доступ к реализациям методов в trait, к значениям по умолчанию и к object, impicit параметры.
Единственное, что уж совсем не получится, так это Manifest. Но и тут можно что-нибудь придумать.
Ну вы опять же как и vba, рассматриваете только ситуацию, когда вы сами пишете библиотеку на Scala, и можете «что-нибудь придумать», что бы работать с ней на Java…
А я говорю про библиотеки вообще. В Scala я могу заюзать любую библиотеку Java… а вот наоборот, только если создатели этой библиотеки подумали на тему «как запустить эту библиотеку на Java»…
Т.е не в 100% процентах случаев…
А я говорю про библиотеки вообще. В Scala я могу заюзать любую библиотеку Java… а вот наоборот, только если создатели этой библиотеки подумали на тему «как запустить эту библиотеку на Java»…
Т.е не в 100% процентах случаев…
>> Так же очевидно что не для всех задач чистый ООП подход является оптимальным, некоторые задачи намного эффективнее выполнять в функциональном стиле.
Поделитесь очевидностью
Поделитесь очевидностью
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Scala как расширенная Java или Java++