Previous, with a comment from the author: https://news.ycombinator.com/item?id=25334248
Why nullable types?
11–20 of 119 posts
Re: Why nullable types?
#12I think dart made the wrong choice here, but I've never used the language personally or professionally. I give the author the benefit of the doubt but Optionals are so much more powerful than what this article covers. You can map, filter, reduce, chain, compose functions that all work with optionals, and lift functions that work on numbers (or any other type) to be functions that work on Optional but none of that is…
I generally agree with you but the one point they make in this article that really matters for Dart is it does not have pattern matching. Dart’s nominative type system makes much of standard FP much harder than you’d imagine. I know Rust is nominal too but Rust has a lot of complexity to support these things.
It is very simple to add a Maybe and Either type to Dart (my code base has variants of these to deal with null issues) but imperative destructing is a pain. You can get most of the benefits of those techniques in user land without the language knowing about it, but I agree it still misses out on some stuff.
If Dart already had pattern matching or was willing to add it first then the ADT version could have been chosen, but without that prerequisite nullable types was the only ergonomic choice.
Re: Why nullable types?
#13I think dart made the wrong choice here, but I've never used the language personally or professionally. I give the author the benefit of the doubt but Optionals are so much more powerful than what this article covers. You can map, filter, reduce, chain, compose functions that all work with optionals, and lift functions that work on numbers (or any other type) to be functions that work on Optional but none of that is…
> You can map, filter, reduce, chain, compose functions that all work with optionals
Maybe they didn't mention it because both approaches can do that, or maybe I'm misunderstanding?
Re: Why nullable types?
#14I think dart made the wrong choice here, but I've never used the language personally or professionally. I give the author the benefit of the doubt but Optionals are so much more powerful than what this article covers. You can map, filter, reduce, chain, compose functions that all work with optionals, and lift functions that work on numbers (or any other type) to be functions that work on Optional but none of that is…
I generally agree with you but the one point they make in this article that really matters for Dart is it does not have pattern matching. Dart’s nominative type system makes much of standard FP much harder than you’d imagine. I know Rust is nominal too but Rust has a lot of complexity to support these things. It is very simple to add a Maybe and Either type to Dart (my code base has variants of these to deal with nul…
Dart is looking at adding pattern matching and "record" types: https://github.com/dart-lang/language/tree/master/working/05...
Re: Why nullable types?
#15I think dart made the wrong choice here, but I've never used the language personally or professionally. I give the author the benefit of the doubt but Optionals are so much more powerful than what this article covers. You can map, filter, reduce, chain, compose functions that all work with optionals, and lift functions that work on numbers (or any other type) to be functions that work on Optional but none of that is…
> I also found the Some(Some(3)) example just plain wrong.
I don't see any such example in the article, and searching for that string yields nothing. What part are you talking about?
Re: Why nullable types?
#16I think dart made the wrong choice here, but I've never used the language personally or professionally. I give the author the benefit of the doubt but Optionals are so much more powerful than what this article covers. You can map, filter, reduce, chain, compose functions that all work with optionals, and lift functions that work on numbers (or any other type) to be functions that work on Optional but none of that is…
I generally agree with you but the one point they make in this article that really matters for Dart is it does not have pattern matching. Dart’s nominative type system makes much of standard FP much harder than you’d imagine. I know Rust is nominal too but Rust has a lot of complexity to support these things. It is very simple to add a Maybe and Either type to Dart (my code base has variants of these to deal with nul…
That's an interesting counter point, though another comment in a different post for this same article[1] pointed out that Dart is considering adding pattern matching too.
Though I have trouble understanding how a nominal type system affects this? Does dart not have generics? That's all you need to support these patterns? I'm having trouble understanding how the type of type system plays a role here.
Also, what's 'imperative destructing'? Haven't heard that term before, is that just pulling out a property from an object like this from JS?
const { foo } = objectWithPropertyFoo;
Re: Why nullable types?
#17I think dart made the wrong choice here, but I've never used the language personally or professionally. I give the author the benefit of the doubt but Optionals are so much more powerful than what this article covers. You can map, filter, reduce, chain, compose functions that all work with optionals, and lift functions that work on numbers (or any other type) to be functions that work on Optional but none of that is…
> You can map, filter, reduce, chain, compose functions that all work with optionals Maybe they didn't mention it because both approaches can do that, or maybe I'm misunderstanding?
The difference I see is, when you work with a nullable type, each function has to do the check
so
const add3 = (val) => val ? val + 3 : null;
const multiplyBy10 = (val) => val ? val * 10 : null
const add3 = val => val + 3;
const multiplyBy10 = val => val * 10;
Re: Why nullable types?
#18I sometimes wonder if the problem is that we don't have enough nulls. null is typically used as a flag value, but the meaning can be ambiguous: maybe it's the absence of a value, maybe an error occured, etc. Sometimes it has more than one meaning for the same type. Maybe types should be allowed to declare multiple nulls (effectively like an Enum in java) for different flag values. Operations on the different nulls wo…
> null is typically used as a flag value, but the meaning can be ambiguous
Languages like Haskell or Rust handle this in a straightforward way by removing the null and using sum types to replace them.
> maybe it's the absence of a value
Option contains a possible value, or nothing. https://doc.rust-lang.org/std/option/
> maybe an error occured
Result contains either a value or an error. https://doc.rust-lang.org/std/result/index.html
> Sometimes it has more than one meaning for the same type.
Result, E> is a result that might have a value.
Re: Why nullable types?
#19I think dart made the wrong choice here, but I've never used the language personally or professionally. I give the author the benefit of the doubt but Optionals are so much more powerful than what this article covers. You can map, filter, reduce, chain, compose functions that all work with optionals, and lift functions that work on numbers (or any other type) to be functions that work on Optional but none of that is…
> I also found the Some(Some(3)) example just plain wrong. I don't see any such example in the article, and searching for that string yields nothing. What part are you talking about?
It was the first bullet point in one of the bullet point sections. The text from the article was
A Some(Some(string)) means the resource did exist on the server, and we have it in the cache now.
Re: Why nullable types?
#20Earlier quoted context omitted.
> You can map, filter, reduce, chain, compose functions that all work with optionals Maybe they didn't mention it because both approaches can do that, or maybe I'm misunderstanding?
The difference I see is, when you work with a nullable type, each function has to do the check so const add3 = (val) => val ? val + 3 : null; const multiplyBy10 = (val) => val ? val * 10 : null So the argument type goes from being val to val? where the calling code doesn't necessarily have type safety since this argument is now optional (it can be a number or null and either is acceptable) instead of the following (w…
Ah, I gotcha, and I had already read another of your comments below. Yep, agree that is nicer in these cases. I still agree with the author that they made the right choice for Dart.