Back to the Scala Future

[mydoom]

Судя по отсутствию комментариев, этот комикс, увы, правдив:(

[abatyuk]

Почему же? Просто порог вхождения чуть-чуть выше, чем у джавы, но и продуктивность тоже. По сравнению с ПэХаПэ и джаваскриптом и на джаве никто не пишет…

[eld0727]

Довольно необоснованное высказывание, цифры говорят, что на джава пишут фсе

[eld0727]

Да уж, а все почему? Потому что людей учат писать изначально на pascal, C++, Java и т.д. Они однопарадигмовые и это закрывает умы для других подходов. Вот если бы начинали учить людей с Python или Ruby. То может и разнообразия было бы больше :)

[vaniaPooh]

Всем видимо съел мозг инфиксный вызов методов из Predef.

[ankh1989]

Чувствую, что здесь написано что то очень интересное, но мой ум слишком слаб, чтобы понять наглядные примеры на scala.

Итак я постарался описать монадные функции Future, и лично я считаю, что мне удалось.

Описать то вам может и удалось, но я всё равно ничего не понял :)

[eld0727]

Текст рассчитан на людей, которые уже имеют некоторое представление о Scala и о монадах, и жизнь их натолкнула на scala.concurent.Future.
Вам же предлагаю, а потом еще разок прочитать эту статейку, думаю все встанет на свои места :)

[DimitrKovalsky]

Введение в монады на Scala http://habrahabr.ru/post/209510/

[MuLLtiQ]

Хм, в этом коде:

longComputations1() zip longComputations2() zip longComputations3() map { 
 case ((a, b), c) => a * b * c
}

итог будет иметь тип Tuple2[Tuple2[T, U], S]
А есть ли элегантный способ сделать так чтобы тип был Tuple3[T, U, S]?

[abatyuk]

Если про самый элегантный — то это shapeless. Пример

[dima_mendeleev]

Вообще-то элегантней всего в этой ситуации было бы использовать аппликативные функторы, а это ни shapeless, а scalaz (или — Haskell :-D.

[eld0727]

Боюсь, что без велосипедостроения не получится, так как создатели не предоставили нам zipAll.
Можно написать implicit class, в котором написать zipAll принимающий от 2 до 21 Future в качестве аргументов (так как последний Tuple22). Но мне кажется это уже излишество. Способ с кучей скобочек ни чем не плох (вспомним lisp) :)

[aparamonov]

Не согласен. Необходимо потратить больше времени на парсинг этой кучи скобочек. Ну и код вида zip… zip… zip… zip… zip… вместо 1 вызова zip ничуть не добавляет читаемости.
Мы используем как раз implicit class с методами zip на все возможное количество аргументов.
Представьте лучше пример, где надо зипнуть 5-7 веток выполнения. ;)

[dima_mendeleev]

Можно написать свою (левоассоциативную) «запятую» — extractor для пары.

[eld0727]

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

[dima_mendeleev]

Не придется тратить время на парсинг скобочек.

[eld0727]

А давайте вспомним с чего началась ветка комментов

[dima_mendeleev]

А давайте подумаем зачем

… элегантный способ сделать так чтобы тип был Tuple3[T, U, S]...

[jet-black]

Думаю, элегантнее будет просто использовать List:

val f1 = Future(5)
val f2 = Future(6)
val f3 = Future(7)
Future.sequence(List(f1, f2, f3)) map (_.foldLeft(1)((a, c) => a * c)) foreach println

[eld0727]

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

[jet-black]

Тогда, опять же, Ваш пример с for-comprehensions для меня выглядит привлекательнее.
У Вас там, кстати, небольшая опечатка:

val f1 <- longComputations1()

[eld0727]

У Вас там, кстати, небольшая опечатка

Спасибо, поправил.

Тогда, опять же, Ваш пример с for-comprehensions для меня выглядит привлекательнее.

Ну каждому свое, меня больше устраивает подход: more think — less write, а с for — больше букав :)

[eld0727]

Ну изначально да, эти функции лежат в основе. Но разве специфичные для конкретной монады функции не являются «монадическими»?

[Properrr]

После этой картинки к посту пересмотрел трилогию…