4 ms·
Can't do much FP in Kotlin. Unless your definition of FP is programming with lambdas.
by whateveracct 11y ago
Can't do much FP in Kotlin. Unless your definition of FP is programming with lambdas.
- pron 11y agohttps://medium.com/@octskyward/kotlin-fp-3bf63a17d64a https://medium.com/@octskyward/kotlin-fp-3bf63a17d64a
- hrjet 11y agoI agree. One thing that is sorely missing, for example, is a way to define recursive values. In Scala, to express a recursive parser combinator: val e = p | e You can't define such a thing in Kotlin. Atleast, this was the case the last time I looked at it.
- chrisseaton 11y agoWow can you really write val e = p | e in Scala? How does that work with eager evaluation?
- hrjet 11y agoIt's not eager. The | combinator takes lazy parameters (called pass-by-name in scala). So it essentially gets translated to: val e = operator_pipe(() => p, () => e) Note that the operator_pipe() itself returns a function, which gets assigned as a value to `e`. So there is lots of implicit laziness.
- edgyswingset 11y ago(disclaimer: I think Kotlin is cool) And non-lazy map/reduce/filter. Which I almost see as a deal-breaker.
- icholy 11y agoIt's not that hard to implement your own stream abstraction.
- deleted 11y ago[deleted]
- yole 11y agoKotlin does have lazy map/reduce/filter: those are available through the Sequence interface.
- edgyswingset 11y agoIt's very limited. Many of the functions you use when operating with collections also return lists, not sequences.
- mike_hearn 11y agoSequence has much the same extensions available on it as other collections. I did a tutorial a week or so ago (it's not online yet, unfortunately) on FP in Kotlin. We wrote a little app to do IntelliSense style autocompletion on an n-gram model. The core code was purely functional and used lazyness as well. I suspect "does Kotlin support FP" is one of those questions that's doomed to turn into a no-true-scotsman thing: whatever support is available will be considered insufficient by true FP fans :-) But it's good enough to let you write code in a typical functional style in many cases, with little cost.
- coldtea 11y agoWhich is mostly what used to be, 10 years ago. Closures, map, fold, etc. Before Haskell and Clojure like immutability and extra trimmings became fashionable... In 1995 or even 2000 era LISP discussions you rarely if ever see those other concerns about FP that hipster functional programmers bring forward today. (I guess it's also something that was helped by Moore's Law style speed development slowing down and the advancements in multicores...)
- pron 11y agoFP doesn't even have a definition (though pure-FP does, but it, too, can be a bit ambiguous and depends on how you define effects). FP is mostly accepted to be those patterns practiced by people in the FP community. I heard someone deeply involved with FP say, "FP is more a community than a well-defined programming style".
- pjmlp 11y agoQuite right, back on those days FP was Smalltalk (yes really), Scheme, Common Lisp, Emacs Lisp, Caml Light (no OCaml yet), Standard ML and Miranda (no Haskell yet). Which like you mention is where I point those hipsters to. Then again, all new generations think they know best.
- lmm 11y agoLanguage evolves; "FP" today means something different from what it meant 10 years ago. There's no need for dismissiveness in either direction.