Интересно, не думал наткнутся на книгу одного из моих бывших коллег, которая была переведена на русский язык. Господин Каслдайн выходец из Австралии, активист развития javascript, на данный момент трудится в той же компании которая работает над playframework.
Хоть это и не тема здесь, сыроват он еще(m2), я вот его попробовал в связке с mouven-android-kotlin и все закончилось банально как здесь, отчасти вина мувена в этом есть.
Мне тут замечание сделали, дескать у вас с мувеном что то личное, солвер, а вы пробовали писать эти самые модули расширения для него? Повторюсь, в sbt есть несколько уровней расширений на почти любой вкус и цвет. Тем более что sbt постоянно дополняется и расширяется а мувен лежит бревном уже сколько веков? По большему счету разница между мувеном 2 и 3 в том что последний использует параллельные потоки что бы скачивать половину интернета. А вы знаете почему в мувене используется хмл без атрибутов, потому что когда-то давно Вазилин(Van Zyl) не нашел подходящей либы которая бы работала с атрибутами, ответ из уст со-создателя мувена. Курам на смех.
Ну насчет из java в scala должен сказать что иногда проблема находится между стулом и экраном, т.е. в проектировке. Если есть хоть малейший шанс того что ваша библиотечка будет использована из java а вы в сигнатурах ваших методов передаете параметры по имени, то можете не удивятся что вам посыпятся письма с угрозами от java пользователей. Но этот факт не отменяет совместимость байткода, только в если вы захотите передать например функцию как параметр из java вам нужно будет поднапрячься.
Ну насчет мавена и scala могу сказать что если вы их используете то вам например самому приходится указывать версию компилятора для библиотечки сделанной на скале а sbt делает это автоматически. За исключением некоторых особенностей возможности sbt и mouven'а эквивалентны. Геноцид в мувене начинается когда вам по той или иной причине нужно расширить спектр возможностей вашего билд-тула, а в sbt с расширяемостью все нормально.
Все равно не совсем понимаю в чем состоит проблема в «реализации требуемого функционала всеми фичами scala». Наверное здесь следует заранее определить соглашения об использовании тех или иных возможностей, например не использовать if() else if() else а по возможности всегда использовать патерн-матчинг или композицию функций вместо подхода fluent-api. Одно верно, язык очень мощный и ваш проект может легко превратится в лифт-сорц где черт ногу сломит.
Зачем ведь байт код то совместим? На худой конец если вы такой эстет то создайте декомпайлер bytecode -> java и радуйтесь жизни. Мы в нашей компании имеет проекты с сотнями тысяч линий кода на java и уже больше года пишем в основном на скале и никогда и ни у когда не было желания все сурцы мигрировать на scala ведь совместимость есть в обе стороны.
Мне кажется что ошибки начинаются уже с заголовка, scala является turing-complete а java нет, так что никакое это не расширение. Не нужно рассматривать scala как очередной груви, scala на корню отличается от java, все что оба языка делят так это jvm-bytecode откуда и идет совместимость.
Теперь по недостаткам. Что бы использовать мувен со 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 у вас никогда не возникнет впечатления двойственности реализаций той или иной фичи языка.
Создается впечатление что у этого человека такая бизнес-модель — книжки продавать а что бы они лучше продавались под них можно и фреймворки писать. Я с данным художеством (лифтом) плохо знаком но вы верно пометили очень похоже на спагетти-код из php или asp.net.
Все равно не совсем понимаю в чем состоит проблема в «реализации требуемого функционала всеми фичами scala». Наверное здесь следует заранее определить соглашения об использовании тех или иных возможностей, например не использовать if() else if() else а по возможности всегда использовать патерн-матчинг или композицию функций вместо подхода fluent-api. Одно верно, язык очень мощный и ваш проект может легко превратится в лифт-сорц где черт ногу сломит.
Теперь по недостаткам. Что бы использовать мувен со 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 у вас никогда не возникнет впечатления двойственности реализаций той или иной фичи языка.
public class MainActivity extends com.WazaBe.HoloEverywhere.sherlock.SListActivity { ...А как быть тем кто использует например RoboGuice?