Комментарии 26
Судя по отсутствию комментариев, этот комикс, увы, правдив:(
![image](https://habrastorage.org/r/w1560/getpro/habr/comment_images/4bd/f64/4f8/4bdf644f87d8419440deb5a2e1419e25.png)
![image](https://habrastorage.org/getpro/habr/comment_images/4bd/f64/4f8/4bdf644f87d8419440deb5a2e1419e25.png)
+12
Почему же? Просто порог вхождения чуть-чуть выше, чем у джавы, но и продуктивность тоже. По сравнению с ПэХаПэ и джаваскриптом и на джаве никто не пишет…
-2
Да уж, а все почему? Потому что людей учат писать изначально на pascal, C++, Java и т.д. Они однопарадигмовые и это закрывает умы для других подходов. Вот если бы начинали учить людей с Python или Ruby. То может и разнообразия было бы больше :)
+1
Всем видимо съел мозг инфиксный вызов методов из Predef.
0
Чувствую, что здесь написано что то очень интересное, но мой ум слишком слаб, чтобы понять наглядные примеры на scala.
Описать то вам может и удалось, но я всё равно ничего не понял :)
Итак я постарался описать монадные функции Future, и лично я считаю, что мне удалось.
Описать то вам может и удалось, но я всё равно ничего не понял :)
+4
Введение в монады на Scala http://habrahabr.ru/post/209510/
0
Хм, в этом коде:
итог будет иметь тип
А есть ли элегантный способ сделать так чтобы тип был
longComputations1() zip longComputations2() zip longComputations3() map {
case ((a, b), c) => a * b * c
}
итог будет иметь тип
Tuple2[Tuple2[T, U], S]
А есть ли элегантный способ сделать так чтобы тип был
Tuple3[T, U, S]
?0
Боюсь, что без велосипедостроения не получится, так как создатели не предоставили нам zipAll.
Можно написать implicit class, в котором написать zipAll принимающий от 2 до 21 Future в качестве аргументов (так как последний Tuple22). Но мне кажется это уже излишество. Способ с кучей скобочек ни чем не плох (вспомним lisp) :)
Можно написать implicit class, в котором написать zipAll принимающий от 2 до 21 Future в качестве аргументов (так как последний Tuple22). Но мне кажется это уже излишество. Способ с кучей скобочек ни чем не плох (вспомним lisp) :)
-1
Не согласен. Необходимо потратить больше времени на парсинг этой кучи скобочек. Ну и код вида zip… zip… zip… zip… zip… вместо 1 вызова zip ничуть не добавляет читаемости.
Мы используем как раз implicit class с методами zip на все возможное количество аргументов.
Представьте лучше пример, где надо зипнуть 5-7 веток выполнения. ;)
Мы используем как раз implicit class с методами zip на все возможное количество аргументов.
Представьте лучше пример, где надо зипнуть 5-7 веток выполнения. ;)
0
Можно написать свою (левоассоциативную) «запятую» — extractor для пары.
0
И что у вас все равно будут теже Tuple2 только доставать вы берете при помощи другого экстрактора, что по сути тоже велик.
0
Думаю, элегантнее будет просто использовать 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
+2
Для конкретного примера, да. Но прикинем что все аргументы имеют разный тип и нам нужно сделать что-то сложное с ними, пожалуй тут уже без зипов будет совсем не красиво
0
Тогда, опять же, Ваш пример с for-comprehensions для меня выглядит привлекательнее.
У Вас там, кстати, небольшая опечатка:
У Вас там, кстати, небольшая опечатка:
val f1 <- longComputations1()
0
НЛО прилетело и опубликовало эту надпись здесь
После этой картинки к посту пересмотрел трилогию…
-1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Back to the Scala Future