Arrow + coroutines + null types what a great combination! It really feels like the pieces have all fallen together to give us this super convenient developer experience.
@@test9828alpha Sorry what I should've written instead was "Typed nullability". The fact that the type itself can provide us with information about whether something can be null or not. Basically what helps us not have to use `Optional`.
I agree with this talk that many FP techniques aren’t applicable in Kotlin, appreciate the well-prepared examples and visualizations, and acknowledge that the speaker offers some practical insights (e.g. “good code should reflect domain”). But this talk sends the wrong message, and spreads misinformation on multiple levels. First, the talk mentions “best” and “rest” as if they were inherent in functional programming. What needs to be clear (even with the obvious context that this is a Kotlin conference) is that “best” here means “which Kotlin can express”, and “rest” means “which Kotlin doesn’t have the abstraction power for”. Like any language, Kotlin comes with tradeoffs (Whether the trade-offs are reasonable or informed is a separate discussion). The problem with trying to express an idea in a language without the abstraction power for it is that it becomes a pattern, or even an encoding: instead of being named once and instantiated for uses, it comes with boilerplates that only make sense to people who already know what it’s about. As the speaker remarks, the noise can quickly crowd out the signals. Expressing monads in a language without higher-kinded types is cumbersome, because the interface cannot be programmatically stated once and enforced elsewhere. (The higher-kinded types “language feature” is not a complexity, at least to the programmer. It’s a simplification that generalizes and unifies existing understanding, similar to how one accepts negative numbers in grade-school math, or higher-order functions in programming. The complexity coming from the lack of higher-kinded types isn’t a sign that monads are inherently impractical as a programming concept; it simply means they aren’t a good trade off in some languages, which should be made clear). Kotlin’s design seems to be about throwing in ad-hoc language features to address specific needs (e.g. nullable, `suspend`, `@Composable`) instead of having a small core that generalizes well. This talk is about informing the audience of idiomatic Kotlin when it works well for their use cases, and practical compromises when it doesn’t. Second, the monad explanation is wrong, because the speaker tries to make sense of “A monad is a monoid…” without having ever picked up category theory. This is a ChatGPT-level BS "explanation". The “monoid” discussed in the talk is the more specific and well established classic “monoid on sets”, from abstract algebra, which predates category theory. The “monoid” from category theory is short for “monoid object in monoidal category” (look it up), which is a vast generalization. When it’s a monoid in the category where objects are sets and arrows are functions, you recover classic monoid. When it’s a monoid in the category where objects are endofunctors and arrows are natural transformations, you get a monad. CLASSIC MONOID CANNOT BE USED TO EXPLAIN MONAD AS A SPECIAL CASE; it’s at best an analogy. The `empty` and `combine` operations discussed are not at all part of a monad’s definition. If you want an analogy with classic monoid, the associative `combine` is analogous to the fact that if you have a triply-nested monad `m`, then using `join` to collapse it would result in the same `m` whether you collapse the outer nesting or the inner nesting first. And the `empty` in classic monoid is analogous to the `pure` operation in monad where you inject a value into an effect-free monadic action, which the speaker completely omitted when describing monad. Finally, it’s worth noting that “A monad is a monoid in the category of endofunctors” originates from the joking blog post “A brief, incomplete, and mostly wrong history of programming languages”: It wasn’t used by any computer scientist as a serious explanation to programmers. In fact, bringing up category theory’s monoid is not at all a practical way to explain monads to programmers, which the joke is about. Third, this talk is plagued with name-dropping (e.g. “semi-group”) and brief nonsensical statements (e.g. “monoid extends applicative, …, there’s also small nuances, but for now, …”), seemingly to project the image that the speaker has studied these topics extensively and is now in the position to distill things for the audience. The comment “Monad transformers are kind of a dirty trick” is particularly odd. Monad transformers have problems, but they are a generalization to make monads composable, not a hack that only “works for two levels” (???). Higher-kinded types are central to expressing monads (in a typed language, at least), but here it is brought up as a specific language feature to enable comprehension syntax, which is a really weird discussion. While this talk has practical tips and takeaways relevant to Kotlin, the statements on more general topics are either wrong or too vague to refute. The speaker appears to suggest that he has been anywhere near “the mountain peak” (whatever that is) and is coming back to give insightful “functional common sense” advice, but I’m not convinced he’s picked up any category theory, or any other mathematics underlying programming and abstractions. This could have been a decent talk had it been framed as “what’s sensible for Kotlin”, as opposed to “what’s sane and what’s not from functional programming”.
>> In fact, bringing up category theory’s monoid is not at all a practical way to explain monads to programmers, which the joke is about. too funny! and spot on
Overtime I have naturally shifted from an imperative style programming to a more expressive style through the composable artifacts that Kotlin natively offers and I have seen improvements in code readability, maintainability, pace and a better “way” of approaching code. But to my dismay, I have never been able to explain to my coworkers why such a shift in style improves code and what actually is fundamentally different about the two approaches. As this speaker presumed, the mathematical labeling, like monoids, has always confused me. I am so grateful of this beautiful talk as it now makes me able (I feel) to explain to others the benefits of say, higher order scoping functions and why & when to use them, and when not to. Great presentation. Thank you!
One of my favourites from the conference. Up until recently Arrow has felt like a different world than Kotlin, but it’s great to see that it is finding the sweet spot of working with the language.
At around 4:33 (Imperative Programming vs Expression Oriented programming), the imperative style is doing many different task to find the best dev. Normally one would or could do the following (by breaking down different sub task into its own function. ) fun findBestDev(lang: String): Developer? { try { val devs = client.getAll() val filteredDevs = filterByLanguage(devs) maxByExperience(filteredDevs) } catch (ex: Exception) { null } Note: The "filterByLanguage" can be made more reusable. eg: filterBy(list, comparator) and same goes for "maxByExperience" Doing this way, from my perspective, the code is easier to read (even for beginners) than the one with expression oriented programming. My personal experience with RxJava was nightmare with lots of methods chained together. It made it easy for the person actually doing the coding but was nightmare for the third person to understand the code by just looking at it.
One of the very best talk out there about Kotlin and FP, hands down. Just a small note: Result doesn't offer .flatMap out of the box without the help of Arrow core helper functions.
Not sure how the video chapters came to life (AI?), but "Monads" and "Monad comprehension" are shown as "Monets" and "Monet comprehension" for me... 😄 And at 30:20 I believe with context receivers the bind() calls would also get obsolete since the other functions like getDevByName would most likely be callable with the same EffectScope context, no? Great talk!!
In the example about the scope functions at 07:50 I find it actually much more difficult to read. One main drawback is that the code is getting very nested.
FP is different from OO, not saying OO is bad, but you have to put some time in re-wiring your way of thinking, blaming another language is unfortunate. So far, I have seen nothing that couldn't be done with ease in vanilla Scala with less ceremony. Future has its own error channel in Scala as well and nesting monads are a sign of generally bad programming. Either[Optional] for ex. can be modeled as domain specific type with 3 cases but more likely is Either redundant. Keep monads at the outer fringes of the application. And a better way to layer your app is vertically not horizontally benefiting from functional composition as illustrated here Scott Wlaschin - Designing with capabilities th-cam.com/video/RqlnWv6NZos/w-d-xo.html And if you need the ? operator, it can be implemented in Scala 3 as well.
Nope, you'll see plenty of references to javain the tutorials, and many guides are written on the basis of an existing java dev learning kotlin, but there are pure beginner tutorials out there.
Arrow optics is great when working with gradle 42:11 , but I have my doubts about using it with maven which is still much more popular for backend services. So far I’m using the Dyescape plugin in my experimental projects and their team has been excellent in providing support, but Kotlin still updates faster than what they can keep up to. This poses a problem to many non-android based companies that use maven.
Arrow + coroutines + null types what a great combination! It really feels like the pieces have all fallen together to give us this super convenient developer experience.
why nulls? how is it better
@@test9828alpha Sorry what I should've written instead was "Typed nullability". The fact that the type itself can provide us with information about whether something can be null or not. Basically what helps us not have to use `Optional`.
@@GakisStylianos Kotlin has typed nulls `T` vs `T?`, but they aren't monadic (e.g., you can't map them).
I agree with this talk that many FP techniques aren’t applicable in Kotlin, appreciate the well-prepared examples and visualizations, and acknowledge that the speaker offers some practical insights (e.g. “good code should reflect domain”). But this talk sends the wrong message, and spreads misinformation on multiple levels.
First, the talk mentions “best” and “rest” as if they were inherent in functional programming. What needs to be clear (even with the obvious context that this is a Kotlin conference) is that “best” here means “which Kotlin can express”, and “rest” means “which Kotlin doesn’t have the abstraction power for”. Like any language, Kotlin comes with tradeoffs (Whether the trade-offs are reasonable or informed is a separate discussion). The problem with trying to express an idea in a language without the abstraction power for it is that it becomes a pattern, or even an encoding: instead of being named once and instantiated for uses, it comes with boilerplates that only make sense to people who already know what it’s about. As the speaker remarks, the noise can quickly crowd out the signals. Expressing monads in a language without higher-kinded types is cumbersome, because the interface cannot be programmatically stated once and enforced elsewhere. (The higher-kinded types “language feature” is not a complexity, at least to the programmer. It’s a simplification that generalizes and unifies existing understanding, similar to how one accepts negative numbers in grade-school math, or higher-order functions in programming. The complexity coming from the lack of higher-kinded types isn’t a sign that monads are inherently impractical as a programming concept; it simply means they aren’t a good trade off in some languages, which should be made clear). Kotlin’s design seems to be about throwing in ad-hoc language features to address specific needs (e.g. nullable, `suspend`, `@Composable`) instead of having a small core that generalizes well. This talk is about informing the audience of idiomatic Kotlin when it works well for their use cases, and practical compromises when it doesn’t.
Second, the monad explanation is wrong, because the speaker tries to make sense of “A monad is a monoid…” without having ever picked up category theory. This is a ChatGPT-level BS "explanation". The “monoid” discussed in the talk is the more specific and well established classic “monoid on sets”, from abstract algebra, which predates category theory. The “monoid” from category theory is short for “monoid object in monoidal category” (look it up), which is a vast generalization. When it’s a monoid in the category where objects are sets and arrows are functions, you recover classic monoid. When it’s a monoid in the category where objects are endofunctors and arrows are natural transformations, you get a monad. CLASSIC MONOID CANNOT BE USED TO EXPLAIN MONAD AS A SPECIAL CASE; it’s at best an analogy. The `empty` and `combine` operations discussed are not at all part of a monad’s definition. If you want an analogy with classic monoid, the associative `combine` is analogous to the fact that if you have a triply-nested monad `m`, then using `join` to collapse it would result in the same `m` whether you collapse the outer nesting or the inner nesting first. And the `empty` in classic monoid is analogous to the `pure` operation in monad where you inject a value into an effect-free monadic action, which the speaker completely omitted when describing monad. Finally, it’s worth noting that “A monad is a monoid in the category of endofunctors” originates from the joking blog post “A brief, incomplete, and mostly wrong history of programming languages”: It wasn’t used by any computer scientist as a serious explanation to programmers. In fact, bringing up category theory’s monoid is not at all a practical way to explain monads to programmers, which the joke is about.
Third, this talk is plagued with name-dropping (e.g. “semi-group”) and brief nonsensical statements (e.g. “monoid extends applicative, …, there’s also small nuances, but for now, …”), seemingly to project the image that the speaker has studied these topics extensively and is now in the position to distill things for the audience. The comment “Monad transformers are kind of a dirty trick” is particularly odd. Monad transformers have problems, but they are a generalization to make monads composable, not a hack that only “works for two levels” (???). Higher-kinded types are central to expressing monads (in a typed language, at least), but here it is brought up as a specific language feature to enable comprehension syntax, which is a really weird discussion.
While this talk has practical tips and takeaways relevant to Kotlin, the statements on more general topics are either wrong or too vague to refute. The speaker appears to suggest that he has been anywhere near “the mountain peak” (whatever that is) and is coming back to give insightful “functional common sense” advice, but I’m not convinced he’s picked up any category theory, or any other mathematics underlying programming and abstractions. This could have been a decent talk had it been framed as “what’s sensible for Kotlin”, as opposed to “what’s sane and what’s not from functional programming”.
>> In fact, bringing up category theory’s monoid is not at all a practical way to explain monads to programmers, which the joke is about.
too funny! and spot on
Thank you. This might just be the best comment I've ever read on TH-cam.
Overtime I have naturally shifted from an imperative style programming to a more expressive style through the composable artifacts that Kotlin natively offers and I have seen improvements in code readability, maintainability, pace and a better “way” of approaching code. But to my dismay, I have never been able to explain to my coworkers why such a shift in style improves code and what actually is fundamentally different about the two approaches.
As this speaker presumed, the mathematical labeling, like monoids, has always confused me. I am so grateful of this beautiful talk as it now makes me able (I feel) to explain to others the benefits of say, higher order scoping functions and why & when to use them, and when not to.
Great presentation. Thank you!
One of my favourites from the conference. Up until recently Arrow has felt like a different world than Kotlin, but it’s great to see that it is finding the sweet spot of working with the language.
I'm glad I watched the whole thing, that nullable comprehension is a life changer! 😂
Very biased opinion, FP seems incomplete without HKT and the Tagless Final pattern. There'll be just a lot manual hooks here and there.
At around 4:33 (Imperative Programming vs Expression Oriented programming), the imperative style is doing many different task to find the best dev. Normally one would or could do the following (by breaking down different sub task into its own function. )
fun findBestDev(lang: String): Developer? {
try {
val devs = client.getAll()
val filteredDevs = filterByLanguage(devs)
maxByExperience(filteredDevs)
} catch (ex: Exception) {
null
}
Note: The "filterByLanguage" can be made more reusable. eg: filterBy(list, comparator) and same goes for "maxByExperience"
Doing this way, from my perspective, the code is easier to read (even for beginners) than the one with expression oriented programming.
My personal experience with RxJava was nightmare with lots of methods chained together. It made it easy for the person actually doing the coding but was nightmare for the third person to understand the code by just looking at it.
> was nightmare for the third person to understand the code by just looking at it.
SKILL ISSUE
One of the very best talk out there about Kotlin and FP, hands down. Just a small note: Result doesn't offer .flatMap out of the box without the help of Arrow core helper functions.
Not sure how the video chapters came to life (AI?), but "Monads" and "Monad comprehension" are shown as "Monets" and "Monet comprehension" for me... 😄
And at 30:20 I believe with context receivers the bind() calls would also get obsolete since the other functions like getDevByName would most likely be callable with the same EffectScope context, no?
Great talk!!
Cool! Now we only need to teach business people how *not* to think in imperative, they always think in terms of mutation procedures. :D
In the example about the scope functions at 07:50 I find it actually much more difficult to read. One main drawback is that the code is getting very nested.
Awesome Talk. Thank you a lot
13:24 periodic table in chemistry right ?
Great talk though thoroughly enjoyed
Great talk!
FP is different from OO, not saying OO is bad, but you have to put some time in re-wiring your way of thinking, blaming another language is unfortunate. So far, I have seen nothing that couldn't be done with ease in vanilla Scala with less ceremony. Future has its own error channel in Scala as well and nesting monads are a sign of generally bad programming. Either[Optional] for ex. can be modeled as domain specific type with 3 cases but more likely is Either redundant. Keep monads at the outer fringes of the application. And a better way to layer your app is vertically not horizontally benefiting from functional composition as illustrated here
Scott Wlaschin - Designing with capabilities
th-cam.com/video/RqlnWv6NZos/w-d-xo.html
And if you need the ? operator, it can be implemented in Scala 3 as well.
best lecture
It really pointed out how relevant functional programming is
What is FP wo monad do syntax?
Xebia Functional is pretty much dead now, right?
I wanted to learn kotlin, do I need to learn Java?
Nope, you'll see plenty of references to javain the tutorials, and many guides are written on the basis of an existing java dev learning kotlin, but there are pure beginner tutorials out there.
this presentation is the best!
Arrow optics is great when working with gradle 42:11 , but I have my doubts about using it with maven which is still much more popular for backend services. So far I’m using the Dyescape plugin in my experimental projects and their team has been excellent in providing support, but Kotlin still updates faster than what they can keep up to. This poses a problem to many non-android based companies that use maven.
17:50
great talk