Комментарии 36
ФП без HKT — себе дороже.
Кстати, Майк проводит вебинар по ФП и Котлину через две недели:
info.jetbrains.com/Kotlin-Webinar-October2015-registration.html
info.jetbrains.com/Kotlin-Webinar-October2015-registration.html
Начиная с Java 8 «Update 40», так называемое “RTM locking” включено по умолчанию для совместимых процессоровНа сайте oracle пишут
-XX:+UseRTMLockingdocs.oracle.com/javase/8/docs/technotes/tools/unix/java.html
Generate Restricted Transactional Memory (RTM) locking code for all inflated locks, with the normal locking mechanism as the fallback handler. This option is disabled by default
Прелесть Maybe не в опциональности результата, в конце концов тип для этого и предназначен, а в том что это монада.
Монада с точки зрения программирования — это нечто, что можно обрабатывать в цепочке, передавая контекст, не так ли?
Kotlin использует синтаксис из Groovy:
С интересом посмотрю случай когда монадичность Maybe хоть как-то удобнее чем nullability.
Kotlin использует синтаксис из Groovy:
resultFromDB?.do()?.any?.thing()?.you?.want()
. Посмотрите — это в точности монада Maybe. С интересом посмотрю случай когда монадичность Maybe хоть как-то удобнее чем nullability.
foo :: Maybe Int
bar :: Maybe Int
g :: Maybe Int
g = do
x <- foo
y <- bar
return $ x+y
впрочем, так как я не знаком с синтаксисом котлина, пример может оказаться неудачным.
тогда можно будет вспомнить что Maybe это ещё и аппликативный функтор.
Или сделать что-нибудь типа StateT Maybe.
«Maybe это ещё и аппликативный функтор» — это то да, но вот использовать его аппликативность получится только в языке с каррированием. И даже в Haskell не обойтись без приседаний.
Путь Kotlin в данном случае — напролом, т.е. применение функций с несколькими параметрами требует явных проверок. Бинарные операторы это известная боль, но они относительно редки:
Интересно было бы посмотреть как это решается в funKtionale (никогда сам не использовал)
Путь Kotlin в данном случае — напролом, т.е. применение функций с несколькими параметрами требует явных проверок. Бинарные операторы это известная боль, но они относительно редки:
val x: Int? = 32
val y: Int? = null
val g1: Int? = if(x != null && y != null) x + y else null
var g2: Int? = x?.let {y?.plus(x)} // it's the shortest one can get
Интересно было бы посмотреть как это решается в funKtionale (никогда сам не использовал)
Когда один код работает и с Option, и с List, и с Future.
К сожалению синтаксис функций совсем не как в Haskell. Кому-то может показаться сущей мелочью — но поверьте мне: когда я на работе разбираю код в С++ или C# с кучей вызовов функций в одной строке, все эти скобки быстро начинают мешать пониманию, где результат одной функции идет к другой, к третьей; и так тоскливо становится, когда я вспоминаю оператор доллара, и отсутствие необходимости в скобках в Haskell.
Я с вами полностью согласен, проблема скобок при вызове функций (в Haskell) это серьезный фактор читабельности кода. Специально для этого случая в Kotlin есть трюк, позволяющий вместо функций использовать методы на объектах.
Стандартный пример на Haskell:
Приписывается на Kotlin почти дословно:
Стандартный пример на Haskell:
take 3 (reverse (filter even [1..10]))
take 3 . reverse . filter even $ [1..10]
Приписывается на Kotlin почти дословно:
(1..10).take(3).reverse().filter(::even)
Я понимаю, что это дело привычки, но для меня $ и композиция читаемости не прибавляют. Смотришь на какой-нибудь однострочник на хаскеле и вообще не понимаешь с какой стороны и в каком порядке его нужно читать. Все равно при чтении кода приходится в уме скобки расставлять.
Как-то нашел очень доступно к пониманию видео о функциональном программировании(лямбды, свертки и тд) Рекомендую к просмотру www.youtube.com/watch?v=7BPQ-gpXKt4&list=PLlb7e2G7aSpRDR44HMNqDHYgrAOPp7QLr
Выглядит это как недоделанная Scala.
Да и вообще, о каком FP можно говорить в языке, где надо писать return?
Да и вообще, о каком FP можно говорить в языке, где надо писать return?
А что, если в языке есть оператор return, то он уже не может быть функциональным?
Я не могу вспомнить ни одного языка с хорошей поддержкой функционального стиля, где бы он был обязателен.
В том же js, где FP по многим причинам востребовано, наконец то для однооператорных функция его убрали.
Да и другие операторы в FP правильнее заменять на выражения.
В том же js, где FP по многим причинам востребовано, наконец то для однооператорных функция его убрали.
Да и другие операторы в FP правильнее заменять на выражения.
Не очень понимаю, что Вы имеете в виду про обязательность `return`. Можете пояснить? Это Kotlin:
fun log(s: String) = if (loggingEnabled) println(s)
Функция отображает одно множество в другое. С точки зрения FP то что Вы привели в пример функцией назвать нельзя.
Тогда это уже требование «чистоты» (purity) к функциям, которого в Kotlin (пока) нету по принципиальным причинам.
Но согласитесь что `return` (в синтаксическом смысле) для функций не обязателен. А то получается что в JavaScript есть, а в Kotlin нету.
для однострочников в котлине return тоже необязателен.
fun max(a: Int, b: Int): Int = if (a > b) a else b
fun max(a: Int, b: Int): Int = if (a > b) a else b
А как же сопоставление образцу (pattern matching)?
Нету. Есть typecheck + auto typecast. Это увы не PM.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Kotlin ❤ FP