Option also allows for much more control. Nullable...

# announcements

[Jannis]

Option also allows for much more control. Nullable types are nice but really don't offer anything in itself. Option implements typeclasses like Functor (enables .map), Monad (enables flatMap/bind), and lots more. This is functionality that nullable types can't provide and by using those typeclasses programs tend to become a lot simpler imo

[nfrankel]

i strongly disagree
nullable types allow a lot less boilerplate defensive code
or a lot less NPEs if you don’t write that code

[Bob Glamm]

I assume you meant "*non*-nullable types"

[Bob Glamm]

but regardless real world development problems require dealing with the absence of a value, and Option<T> provides far more flexibility to deal with the possibility of absence than T?

[nfrankel]

ok
to be semantically precise
the differentiation between nullable and non-nullable types

[nfrankel]

@Bob Glamm fun question:
what makes you think that Option<T> is not null

[Bob Glamm]

If we're going that way because it's not Option<T>? - and you can't tell me that T can't be null, because I can show you ways it can be

[Bob Glamm]

If Option<T> (or T) is null the code has bigger problems

[nfrankel]

the initial comment was Option<T> vs T
optionals vs non-nullable types
so if you’ve got both, fine with me 👍

[nfrankel]

If Option<T> (or T) is null the code has bigger problems

that is not an argument...

[Bob Glamm]

Oh. Nullable types are ridiculous. See also Haskell

[nfrankel]

for me, they get the compiler to do work for me
hence, they are unvaluable

[Bob Glamm]

you can believe that but that actually isn't true

[Bob Glamm]

see also Haskell

[Jannis]

I understood the initial question to be Option<T> vs T? o.O and Option<T> is arguably more powerful here.

[nfrankel]

well, if we don’t agree with the question
it’s hard to debate 😅

[Jannis]

true that. Just stating that what I wrote obviously does not apply to Option<T> vs T. Use of option just does not make sense there

[nfrankel]

my point was just:
Option<T> in java is worth nothing
because it can be null itself

[nfrankel]

now in kotlin
since there’s Option<T> and Option<T>?
it does the job

[Jannis]

Ah, well we are talking about arrow and kotlin afaik so that does not really apply here.

[nfrankel]

regarding arrow, i’m afraid i have not enough knowledge to say anything

[Jannis]

If fp interests you in any way I'd give it a shot. Option in arrow is also quite different than Optional from java. The docs do a great way of explaining its uses 🙂

[Jannis]

https://arrow-kt.io/docs/arrow/core/option/ for the docs on Option

[Bob Glamm]

Functional composition/dependency injection via interfaces also seems promising:

https://www.youtube.com/watch?v=CR5h2Wq1yPE▾

[Bob Glamm]

I'm not necessarily a huge fan of the Kind<F,A> syntax but Scala doesn't do much better in that regard

[Jannis]

higher kinded type emulation sucks, hopefully keep 87 can change that

[Bob Glamm]

But the typeclasses and effects available in Arrow provide a nice foundation for reasoning about effectful programming

[Bob Glamm]

@Jannis agreed; I'm looking forward to what is effectively implicit parameters

[nfrankel]

i dived a bit in arrow
but too be honest, the whole fp mania is a bit scary
as much as the oop mania
i’m all in favor of simple readable maintainable code
the rest is just a tool

[Jannis]

that is very true! I am all for using paradigms solely for the purpose of writing good clean and readable code. This is at least for me mostly achieved by abstraction and that is where fp shines. But as you said those are tools and everyone should use what they are most comfortable with, but checking several out at times can lead to new and interesting and maybe even better patterns 🙂

[nfrankel]

yes
expanding one’s knowledge always reveals more options

[ghedeon]

@Bob Glamm "you can believe that but that actually isn't true". Thats a bold statement. Before you baptise other people in Optional<T> nonsense, I highly recommend you first 15min of Rich Hickey's talk (author of Clojure):

https://youtu.be/YR5WdGrpoug▾

. Where he compares optionals in Clojure, Haskell and Kotlin and calls introducing Maybe/Either to Clojure his billion dollar mistake, because it's a language hack and not a true union. He also mentions that Kotlin got it right.

[Jannis]

@ghedeon I don't think I completly agree with that. I think they both have pro's and cons, type unions are amazing to work with and he is right about refractoring with either of those (Maybe and Either). But the common behaviour these union types may have (typeclasses they implement) will be missing. And if you give me the choice between not breaking callers vs having lawful typeclasses then I'd likely choose the latter.
I also think its quite interesting he mentions there are no languages with true union types and yet there is typescript offering those.

[ghedeon]

each to their own, of course, I'd always prefer simplicity and lower cognitive load of my code. I just didn't like the dogmatic tone: "you wrong, look Haskell", like it's all solved and there is no discussion. It's not.

[Bob Glamm]

@ghedon IMO every argument Hickey makes against Optional/Either is terrible, except for Optional/Either not being a proper sum type.

[Bob Glamm]

From a computational perspective there is zero difference between T? and Option<T>. Both represent a universe of values of T plus the non-existent value of that type. The difference comes in the expressiveness of the type: with T? I'm doomed to forever write if (t != null) in order to use it - and I'm stuck with manually converting that value to something else if I need that value in a different container. Option<T> at least gives me combinators and transformational functions to easily interact with other applicative/monadic types.

[Bob Glamm]

Ideally Arrow would be able to provide me with extension methods on the (hypothetical) type *? (maybe Any?) to provide me with the same combinators/transformational functions that are on Option<T>. Unfortunately I am not aware of any lightweight mechanism in Kotlin to efficiently provide those extension methods on every single nullable type - including types provided by other JVM languages.

[Bob Glamm]

So, TL;DR version: Option<T> is far less noisy to write code with than T? IME