1. В Java гораздо меньше способов натворить делов и они легче отслеживаются, за счет относительной простоты языка более богатых инструментов. Так что проблема плохого кода имхо в скале стоит острее. Если подойти с другой стороны, то скала просто более требовательна к команде. Выше средний уровень, выше уровень тимлида, больше ревью и т.д. И этот уровень появляется не за месяцы, а за хотя бы год. Эту проблему кстати признает и сам Одерски, и обещают над ней работать.
2. Сложный скала код очень часто сносит идейскому спелчекеру башню, ну или я такой везучий
3. sbt это не надстройка над мавеном, это полностью своя система, для получения зависимостей использует не мавен, а ivy. И добавляет совсем не «сахар», а мощную систему сборки где можно подкрутить все, что угодно. Если разберешься :) Я пока еще не осилил, но простые проекты с небольшими нюансами могу делать.
Про turing-complete это вы наверное про систему типов, просто пропустили слово ;)? С остальным в этом абзаце полностью согласен, собственно ниже я это писал.
По поводу мавена. У Вас наверное с ним что-то личное :) Я бы не сказал что он так уж и плох. Для стандартных задач пригоден вполне. Да многословный, да негибкий, да норовит при каждом удобном случае скачать пол-интернета (но этим и сбт грешит). Но для flex, допустим, особо альтернативы нету. А вот с случае со скалой да, мавен это временное убежище, рано или поздно придется браться за sbt. Что собственно я и сделал, и немного даже уже освоился.
Что касается «одного и того же разными путями», то я совсем не карринг и не option c мутабельным накопителем имел в виду. Хотя и это тоже далеко не сразу постигается. Я про различные способы конструирования DSL, использование implicit, point free style, for-comprehension, оформления кода в конце концов. Ко мне далеко не сразу пришло понимание когда стоит что-то использовать, а когда оно лишнее. И во многих вещах я еще экспериментирую. И разговор тут не о «двойственности реализаций той или иной фичи языка», а о реализации требуемого функционала всеми этими фичами. Чтобы они помогали, а не усложняли код. А ведь на подходе еще макросы с уже практически неограниченной свободой фантазии…
Вы это серьезно? У любого компилятора есть баги, просто у скаловского за счет его сложности и темпов развития они чаще попадаются. Загляните вот сюда например issues.scala-lang.org. Очень много проблем решается полной пересборкой и/или перезапуском fsc. Что касатеся тех, с которыми сталкивался лично: на определенном куске кода компилятор падал с NPE, пересборки не помогали, вытащил часть выражения в отдельный val — заработало. Еще помню были проблемы с оптимизатором байткода, уже в рантайме ругался что метод не реализован, уже не помню как решалось, наверное тоже пересборками.
Частично я уже как-то отвечал вот тут habrahabr.ru/post/142356/#comment_4763930
Могу попробовать расписать немного, из того что вспомню.
1. Богатство возможностей приводит к тому, что одно и то же можно сделать очень многими способами. Это сильно затрудняет выработку единого стиля в более-менее большой команде. Безусловно для хорошего программиста мощь языка только плюс, но чтобы достичь этого уровня среднестатистическому java программисту потребуются годы. И постоянный ревью на предмет единого подхода, чтобы код не расползался. Особенно плохо перфекционистам, ибо вариантов «улучшения» кода великое множество.
2. Баги компилятора и IDE. В целом жить можно, но иногда заставит понервничать.
3. Монструозность sbt (стандартное средство сборки). Решается либо привыканием либо мавеном :)
4. Особенности компиляции в байткод. «Хрупкость» (собранные под разными скалы библиотеки могут не дружить друг с другом, одна обновившая библиотека может потребовать перекомпиляции всего проекта и т.д.). Различные проблемы с производительностью в отдельных случаях. И т.д.
И это все не мои личные предпочтения, а признанные довольно многими людьми наблюдения. Странно, что Вы программируя на скале ничего из этого не встречали.
А мне вот кажется наоборот. По сути они делят только платформу и некоторые элементы синтаксиса. За скалой совсем другая философия и подходы. Именно поэтому я считаю неправильным говорить о скале как о Java++. Да, на скале можно писать как на better Java, но тупиковый вариант. Рано или поздно понимаешь, что большая часть java-багажа тебе не нужна.
Наверное надо было указать, что это не просто умные очки которые умеют фоткать, а очки «дополненной реальности». А то, похоже, что многие из комментирующих не в курсе.
Рад был помочь :) Ну вот, стало гораздо симпатичнее и по скаловски. Разве что имхо «val что» лишнее, и так понятно что это параметр. Ну и смысл сканера-пускателя для меня не очевиден. Мне кажется лучше в одном месте явно прописывать какой сервлет куда замаплен.
И, кстати, scalatra не требует sbt, просто демка сделана на шаблонизаторе для sbt. В общем зря Вы на «15 мин» акцент сделали, лучше больше времени на изучение, чем тяп-ляп.
2. Сложный скала код очень часто сносит идейскому спелчекеру башню, ну или я такой везучий
3. sbt это не надстройка над мавеном, это полностью своя система, для получения зависимостей использует не мавен, а ivy. И добавляет совсем не «сахар», а мощную систему сборки где можно подкрутить все, что угодно. Если разберешься :) Я пока еще не осилил, но простые проекты с небольшими нюансами могу делать.
По поводу мавена. У Вас наверное с ним что-то личное :) Я бы не сказал что он так уж и плох. Для стандартных задач пригоден вполне. Да многословный, да негибкий, да норовит при каждом удобном случае скачать пол-интернета (но этим и сбт грешит). Но для flex, допустим, особо альтернативы нету. А вот с случае со скалой да, мавен это временное убежище, рано или поздно придется браться за sbt. Что собственно я и сделал, и немного даже уже освоился.
Что касается «одного и того же разными путями», то я совсем не карринг и не option c мутабельным накопителем имел в виду. Хотя и это тоже далеко не сразу постигается. Я про различные способы конструирования DSL, использование implicit, point free style, for-comprehension, оформления кода в конце концов. Ко мне далеко не сразу пришло понимание когда стоит что-то использовать, а когда оно лишнее. И во многих вещах я еще экспериментирую. И разговор тут не о «двойственности реализаций той или иной фичи языка», а о реализации требуемого функционала всеми этими фичами. Чтобы они помогали, а не усложняли код. А ведь на подходе еще макросы с уже практически неограниченной свободой фантазии…
Имхо лучшее введение в Scala для Java программеров и заодно демонстрация разницы.
Могу попробовать расписать немного, из того что вспомню.
1. Богатство возможностей приводит к тому, что одно и то же можно сделать очень многими способами. Это сильно затрудняет выработку единого стиля в более-менее большой команде. Безусловно для хорошего программиста мощь языка только плюс, но чтобы достичь этого уровня среднестатистическому java программисту потребуются годы. И постоянный ревью на предмет единого подхода, чтобы код не расползался. Особенно плохо перфекционистам, ибо вариантов «улучшения» кода великое множество.
2. Баги компилятора и IDE. В целом жить можно, но иногда заставит понервничать.
3. Монструозность sbt (стандартное средство сборки). Решается либо привыканием либо мавеном :)
4. Особенности компиляции в байткод. «Хрупкость» (собранные под разными скалы библиотеки могут не дружить друг с другом, одна обновившая библиотека может потребовать перекомпиляции всего проекта и т.д.). Различные проблемы с производительностью в отдельных случаях. И т.д.
И это все не мои личные предпочтения, а признанные довольно многими людьми наблюдения. Странно, что Вы программируя на скале ничего из этого не встречали.