Option-тип очень удобная вещь но в плане java на сцену выходят его generic ограничения. Тут автор предоставил простой пример с использованием double но как только вы начнете работать с иерархией типов то читаемость вашего когда моментально снижается. Попытка конечно хорошая но давайте признаем тот факт что java уже давно морально устарел для такого рода функционала и для всеобщего удобства нужно или сменить язык или модернизировать сам java.
Я думаю что автору не следовало ставить еще и на хромбуке в начале и конце заголовка. На мой взгляд из всех десктопных ос федора одна из самых стабильных. Убунту, хромос и винда нервно курят в сторонке.
Повторю слова одного Человека, с большой буквы, который презентовал гит на конференции у гугла в 2007- «Если вы используете svn то ваше место не здесь а в психушке». Прошло почти 5 лет и ie и svn остаются популярными, куда катится этот мир…
Ну начнем с того что у меня нет проблемы с логикой а есть проблемы с ленью. Лень было все досконально читать, ибо было много. Коллатерально закон о защите детей касается и школ, ведь если на определенную программу (например gimp) наложить штамп +16 то по закону о защите детей, ее — программу нельзя будет использовать в школьных учреждениях. Я где-то ошибся или моя логика не верна? Теперь вернемся к юбунту и его пресловутой рекламе от амазон, скажите кто сможет нам гарантировать что данная реклама не выходит за рамки +6?
Да пользуйтесь на здоровье убунту вашей, нравится вам глюконат и реклама амазон в списке программ, только вот не нужно решать чем должны пользоваться дети в учебных заведениях, ладно?
Я считаю что чинуши правильно сделали что заблокировали юбунту, с его убогим unity, в печь всякую гадость. Давно пора переходить на Fedora или Arch. Перефразируя одного известного активиста из мира линуха скажу — юбунту, Фuck u. Простите за срач.
Интересно, не думал наткнутся на книгу одного из моих бывших коллег, которая была переведена на русский язык. Господин Каслдайн выходец из Австралии, активист развития 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. Одно верно, язык очень мощный и ваш проект может легко превратится в лифт-сорц где черт ногу сломит.
Все равно не совсем понимаю в чем состоит проблема в «реализации требуемого функционала всеми фичами scala». Наверное здесь следует заранее определить соглашения об использовании тех или иных возможностей, например не использовать if() else if() else а по возможности всегда использовать патерн-матчинг или композицию функций вместо подхода fluent-api. Одно верно, язык очень мощный и ваш проект может легко превратится в лифт-сорц где черт ногу сломит.