Советы начинающему скалисту (часть 2)

[time2rfc]

Спасибо.

[Hixon10]

А где в рекомендуемых материалах курсы с курсеры? Или вам они не нравятся?

https://www.coursera.org/learn/progfun1/home/welcome
https://www.coursera.org/learn/progfun2/home/welcome
https://www.coursera.org/learn/parprog1/home/welcome
https://www.coursera.org/learn/scala-capstone/home/welcome
https://www.coursera.org/learn/scala-spark-big-data/home/welcome

[ppopoff]

Большое спасибо что добавили список курсов. Надеюсь что для кого-то они окажутся полезными. Честно скажу, про них я забыл.

[redFoer]

Есть еще neofit guide to scala.Если честно не помню в каком месте мне его порекомендовали.
http://danielwestheide.com/scala/neophytes.html
И есть перевод этой серии статей
https://github.com/anton-k/ru-neophyte-guide-to-scala

[slava_k]

Вам благодарность за то, что написали эту статью.
Было бы здОрово раскрыть тему работы с Option и for как инструмент развертки, также схожие и неочевидные для большинства способы работы с различными типами. Я понимаю, что для опытных это не в новинку, но у многих начинающих с этим часто проблемы.

P.S.: жаль, что в основную ветку языка так и не была принята система «неопределенных» типов с |.

[slava_k]

http://soc.github.io/lessons-learned/implicit-numeric-conversions.html

[ppopoff]

Эта тема достаточно не плохо (правда на английском) раскрыта здесь

[e_Hector]

пока ваши коллеги на радостях не завезли в проект специально предназначенный для борьбы с NPE язык

отсылки к Kotlin`у прекрасны

[wert_lex]

Часть 0. Изучить Haskell, чтобы понимать функциональную магию Shapeless, Scalaz, Iteratee итд.

[ppopoff]

Scala, при всей своей сложности предоставляет достаточно низкий порог вхождения в функциональное программирование. И для многих Haskell будет являть собой именно следующую ступень (а не нулевую :). Безусловно, знание Haskell будет полезным, но не жизненно необходимым для неофитов.

[wert_lex]

У меня немного другой опыт (но на скале я уже два года активно не пишу, до этого писал активно о). Если использовать скалу, как Better Java, то ничего хорошего из этого не получается. А если активно писать в около-функциональном стиле, то выясняется две интересных подробности:

1. для этого надо знать слишком много о том, как работает JVM и во что превращается scala-код
2. стоит только сделать небольшой шаг дальше композиции функций, как тут же возникает огромное количество вопросов, на которые в "продвинутом" скала-сообществе принято отвечать примерами на хаскеле.

[ppopoff]

Если использовать скалу, как Better Java, то ничего хорошего из этого не получается

Не соглашусь. Во-первых, Scala конечно можно рассматривать как Better Java, но ее так же можно рассматривать и как Better Ruby или Better C#. Ситуация не меняется. И да, многие из нас так и начинали. Да, было сложно, да по дороге пришлось разобраться с Haskell. Scala дает множество преимуществ не связанных с функциональщиной, и ради этих преимуществ достойна изучения и дальнейшего использования.

[kvascola]

Отличная статья, легко и интересно читается.
В Scala новичок, проходил курс от Одерски на Coursera и читал Хортсманна (как раз обновлённое издание к актуальной 2.12 вышло, пора перечитывать) http://horstmann.com/scala/.

Вопрос: что за отсылка к зелёным монстрам? Кто это?

[ppopoff]

Спасибо!
В первую очередь, если статья легко читается, то благодарность явно не мне :)

В 2.12 нет радикальных изменений относительно предыдущих версий, однако есть множество deprecations.

По поводу зеленых монстров, я думаю большинство джавистов прекрасно поняли о чем я ;).

[kvascola]

Spring?

[javax]

С приведенным способ делать enum много проблем — нет порядка значений, возникнут проблемы с сериализацией или ORM.

[redFoer]

Привет.Я начинающий scalla разработчик.Сейчас я зависаю над книгами.
Я только недавно прочитал что не рекомендуется использовать тип Either.Мол, отдавайте предпочтение Options,Try.
Я чего то не понимаю? Нужно лучше почитать? Спасибо :)

[ppopoff]

Мне интересно где вы это прочитали :), а еще более мне интересно кто эту глупость написал.

Option не подходит для обработки ошибок
Объективно, Option это пожалуй один из самых худших вариантов. Используя Option вы никак не сохраняете информацию об ошибке и ее типе. Концептуальное назначение Option обозначать возможно отсутствующую сущность, но никак не обозначать наличие ошибки

Теперь разберемся с Either и Try.
Для большинства случаев применим Try. Он удобен, понятен, и главное, сохраняет информацию об ошибках. Тогда вопрос, а зачем нам нужен Either? Начнем с того, что Either появился намного раньше Try. scala.util.Try появился в Scala начиная с версии 2.10. Data.Either существовал в Haskell, чтоб не соврать… очень давно. Но не для всех ситуаций Try будет являться лучшим решением.

Когда нам нужен Either

• Try не является монадой, потому что не соблюдает монадические законы. А иногда, монадическое поведение бывает необходимо.
• Either позволяет переносить более сложную информацию о типе ошибки, где Exception может являться вообще полем класса.

И это еще не все
В scalaz есть Validation, которая оказывается удобнее и Try и Either. В библиотекеfs2 существуют свои способы решать проблемы с исключениями.

Такая тема как обработка исключений требует отдельной и обширной статьи. Надеюсь в этом году у меня найдется на нее время.

[senia]

Я бы поостерегся так сразу рекомендовать scalaz и Validation.

1. На данный момент лучшим вариантом для изучения представляется cats, а не scalaz. Как минимум потому, что проще и популярнее.
2. Без глубокого знакомства в ФП, просто как drop-in replacement для Either, Validation подходит плохо. Просто потому, что не монада нельзя использовать в for. Обилие toEither (или disjunction) в коде будет явным минусом.

[redFoer]

Павел, добрый день(ну или вечер).Просто хотел сказать что вы были правы.
Как я понял, Try нужно использовать на цепочке вычислений «без ответа».Что то типа протокола UDP :)
Сейчас же столкнулся с таким моментом — нужна цепочка вычислений, но в некоторых моментах в случае ошибки нужно пойти другим путем.Тут и пригодился Either :)
Спасибо.