4 ms·

> Optional or Maybe is just “type or null” which is the implicit type of every language with nullable by default types. It’s worse in every way to null. This

> Optional or Maybe is just “type or null” which is the implicit type of every language with nullable by default types. It’s worse in every way to null. This is completely backwards, and it's much more basic than ebingdom's explanation. Although, I don't think they're necessarily wrong, but I don't think you need functors specifically or category theory in general to explain this. When your language allows the presence of null values, then by default you are asserting that null is a member of every type in your language. This means that any value can possibly be null. When using Optional or Maybe or $My_Language's_Name_for_a_Some_Value_or_No_Value_Type, with a language having a half-decent typechecker, for any potential place where you may have a `Nothing` or what-have-you the typechecker will enforce that you are addressing that. In a language that doesn't provide the ability to distinguish between null values and anything else via static analysis, you are forced at runtime to explicitly check every possible place that a null value could occur (I have used dynamically-typed languages for the better part of two decades professionally; nobody does this), or you can keep the entire logical structure of your application in your head perfectly such that you know where any nulls could occur and thereby skip writing as much code (no one can do this, and anyone who believes they can is either a junior or a junior) or acknowledge that you are a human and write a bunch of tests to try to mitigate potential failures (you will still have a microservice crash and spend a day or two putting out fires when that null slips through, because something something tests don't prove absence of bugs, thank you Dijkstra). On the other hand, with a sufficiently sophisticated type system, you are able to write programs that let you flexibly target where optional values are present and where they are not with a minimum of boilerplate, and you never have to worry about this particular--but rather _significant_ when it comes to tolerating incessant firefighting--class of errors at runtime. This is better in every way to null.

Spivak 4y ago
How do you feel about Kotlin where nulls are present but by default all types are not nullable? This is pretty much my ideal balance between unwrap hell and safety. You only have to acknowledge the nulls on nullable types.
- ddellacosta 4y ago
  > How do you feel about Kotlin where nulls are present but by default all types are not nullable? I have to ask--how is that different from an option type?
  - KMag 4y ago
    I think the GP is probably thinking about Java's Option<T>, which adds an extra layer of indirection and is in some ways the worst of both worlds. In Java, the Option<T> could be null, or it could wrap null. The clue here is that the GP is talking about extra boxing/unboxing related to Option<T>, which you don't get in languages with better Option<T>/Maybe<T> implementations.
ebingdom 4y ago
> it's much more basic than ebingdom's explanation Just to contextualize my explanation, I took it as a given that we were talking about the two _safe_ ways to handle missing data: a type system which has a notion of nullable/non-nullable types (e.g., Kotlin) vs. a type system which has Option<T> and no primitive notion of nullability (e.g., Rust). I thought it was obvious that one would want this to be tracked in the type system _somehow_ (to prevent the billion dollar mistake), and that we were just discussing different approaches to achieving that goal.
asddubs 4y ago
I like the way PHP does it, where the return type of a function can be Object, which does not allow null, or ?Object, which does allow null. Although I would probably still consider using an Optional<Object> type if PHP had generics (of course you can still write an Optional-pattern using a mixed return type, but then you lose type guarantees), just so you cannot access the value at all without being reminded that you do need to check that type, even if you never look at the return type

Spivak 4y ago

How do you feel about Kotlin where nulls are present but by default all types are not nullable? This is pretty much my ideal balance between unwrap hell and safety. You only have to acknowledge the nulls on nullable types.

ddellacosta 4y ago
> How do you feel about Kotlin where nulls are present but by default all types are not nullable? I have to ask--how is that different from an option type?
- KMag 4y ago
  I think the GP is probably thinking about Java's Option<T>, which adds an extra layer of indirection and is in some ways the worst of both worlds. In Java, the Option<T> could be null, or it could wrap null. The clue here is that the GP is talking about extra boxing/unboxing related to Option<T>, which you don't get in languages with better Option<T>/Maybe<T> implementations.

ebingdom 4y ago

> it's much more basic than ebingdom's explanation Just to contextualize my explanation, I took it as a given that we were talking about the two _safe_ ways to handle missing data: a type system which has a notion of nullable/non-nullable types (e.g., Kotlin) vs. a type system which has Option<T> and no primitive notion of nullability (e.g., Rust). I thought it was obvious that one would want this to be tracked in the type system _somehow_ (to prevent the billion dollar mistake), and that we were just discussing different approaches to achieving that goal.

asddubs 4y ago

I like the way PHP does it, where the return type of a function can be Object, which does not allow null, or ?Object, which does allow null. Although I would probably still consider using an Optional<Object> type if PHP had generics (of course you can still write an Optional-pattern using a mixed return type, but then you lose type guarantees), just so you cannot access the value at all without being reminded that you do need to check that type, even if you never look at the return type