Pull to refresh

Comments 36

Начиная с Java 8 «Update 40», так называемое “RTM locking” включено по умолчанию для совместимых процессоров
На сайте oracle пишут
-XX:+UseRTMLocking
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
docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html
grossws, спасибо за наводку! Я попробовал связаться с Майком, но он никак не реагирует уже сутки, так что источник, откуда он взял эту информацию, остается неясным. Статью поправил.
Прелесть Maybe не в опциональности результата, в конце концов тип для этого и предназначен, а в том что это монада.
Монада с точки зрения программирования — это нечто, что можно обрабатывать в цепочке, передавая контекст, не так ли?

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 в данном случае — напролом, т.е. применение функций с несколькими параметрами требует явных проверок. Бинарные операторы это известная боль, но они относительно редки:
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 (никогда сам не использовал)
В скале для такого каррирование не используется.
scalaz:
1.some |+| 2.some // Some(3)
1.some |+| none[Int] // None
Монада всегда аппликативный функтор. Простой функтор может не быть аппликативным или допускать разные варианты реализации аппликативности.
Когда один код работает и с Option, и с List, и с Future.
К сожалению синтаксис функций совсем не как в Haskell. Кому-то может показаться сущей мелочью — но поверьте мне: когда я на работе разбираю код в С++ или C# с кучей вызовов функций в одной строке, все эти скобки быстро начинают мешать пониманию, где результат одной функции идет к другой, к третьей; и так тоскливо становится, когда я вспоминаю оператор доллара, и отсутствие необходимости в скобках в Haskell.
Я с вами полностью согласен, проблема скобок при вызове функций (в Haskell) это серьезный фактор читабельности кода. Специально для этого случая в Kotlin есть трюк, позволяющий вместо функций использовать методы на объектах.

Стандартный пример на Haskell:
Я с вами полностью согласен, проблема скобок при вызове функций (в 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)
Я понимаю, что это дело привычки, но для меня $ и композиция читаемости не прибавляют. Смотришь на какой-нибудь однострочник на хаскеле и вообще не понимаешь с какой стороны и в каком порядке его нужно читать. Все равно при чтении кода приходится в уме скобки расставлять.
Ну, по моему опыту такое бывает нечасто, и обычно подобный код выглядит приблизительно одинаково трудным что со скобками, что без них.
Огромное спасибо за эти прекраснейшие лекции.
Выглядит это как недоделанная Scala.
Да и вообще, о каком FP можно говорить в языке, где надо писать return?
А что, если в языке есть оператор return, то он уже не может быть функциональным?
Я не могу вспомнить ни одного языка с хорошей поддержкой функционального стиля, где бы он был обязателен.
В том же js, где FP по многим причинам востребовано, наконец то для однооператорных функция его убрали.
Да и другие операторы в FP правильнее заменять на выражения.
Не очень понимаю, что Вы имеете в виду про обязательность `return`. Можете пояснить? Это Kotlin:
fun log(s: String) = if (loggingEnabled) println(s)
Функция отображает одно множество в другое. С точки зрения FP то что Вы привели в пример функцией назвать нельзя.
Тогда это уже требование «чистоты» (purity) к функциям, которого в Kotlin (пока) нету по принципиальным причинам.
Но согласитесь что `return` (в синтаксическом смысле) для функций не обязателен. А то получается что в JavaScript есть, а в Kotlin нету.
Для функция, которые не могут завершиться или всезда возвращающие Unit.
В паскале в свое время для последних было специальное понятие — процедура. Мне оно казалось избыточными, но смотря на сегоднешнюю ситуацию начинаю думать, что что-то в нем полезное было — терминология точнее получалась.
для однострочников в котлине return тоже необязателен.
fun max(a: Int, b: Int): Int = if (a > b) a else b
собственно чего это я, если к return совсем уж религиозная ненависть, то можно без него любой код писать:
fun calc(arg: Int): Int = run {
database.execute()
network.execute()
arg + 10
}
Выглядит привлекательно.
А что означает слово run?
Это просто функция которая запускает лямбду (то что в фигурных скобках).
То есть можно написать так… = { /*тело лямбды*/ }()
но столько видов скобок подряд плохо читается. Поэтому используют функцию run.
То есть на уровне js поддержка есть. Уже хорошо.
А как же сопоставление образцу (pattern matching)?

Нету. Есть typecheck + auto typecast. Это увы не PM.
Sign up to leave a comment.

Articles