This is not intended as an attack, but a genuine question: what does Dart offer over any other language? Why would I choose Dart?
Why nullable types?
101–110 of 119 posts
Re: Why nullable types?
#102I think saying that Option types are different from nullable types is not true. They differ at the semantic level, around how you can interact with them (one requires you to case on whether or not the value is there, the other requires you to do that with an if statement), but at the type level the describe the same construct. I think saying something is not the same as something else, when evidently the difference c…
The article mentions unions vs discriminated unions and then mentions nesting nullable being different than nesting optional, but it doesn't really tie the knot. Imagine (sorry for pseudocode): type Option T = Some T | None type Nullable T = T | null The difference here is that Option "tags" each part of its union, which guarantees that the parts are disjoint. In Nullable, the parts of the union are disjoint only if…
I think I'd put it even more on the syntax. Option requires you to explicitly deal with the fact that it is an Option. For nullable types, frequently the syntax doesn't require you to acknowledge that it is nullable at all, and will allow you to continue forward on the assumption that the object doesn't contain null.
Re: Why nullable types?
#103Earlier quoted context omitted.
> I'm not sure what you mean by "compose". The simplest illustration is the ability to have multiple levels of semantically meaningful optionality: Option > is a meaningful type, and None, Some(None), and Some(Some(1)) are all meaningfully-distinct values. int? doesn't compose to int?? and has no good way to differentiate what Option > represents as None and Some(None).
Ironically the main advantage of Monads is that Option > has a natural transformation to Option .
The reason Option> isn't a problem is because it's a monad, so people will naturally transform it into Option while writing their programs.
There is no irony there. If it wasn't a monad, the GGP would be incorrect, and ad-hock solutions would be very valuable.
Re: Why nullable types?
#104I 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. In those scenarios, typically you just use chain (aka flatMap) instead of map I think you misunderstood. The point here was that you can represent different things using nested Options: 1. Some(Some(3)) = I checked it and the value is 3 2. Some(None) = I checked it and there is no value 3. None = I haven't checked it It's very useful when building a cache, an…
> I have to do explicit null checks and then the compiler/interpreter just "knows" that code in certain places is null-safe through flow analysis.
You need to do it anyway or you got a crash. Because remove null from a existing language completely is nearly impossible.
And now the compiler is able to know something went wrong in your code instead of happily see you use `null` as a object and crash the whole program.
Besides that, that also benefit the library users that the compiler/ide will tell them `you can't pass null here`
Re: Why nullable types?
#105Earlier 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…
That is where you use optional chaining + extension method. And that is basically identical to Optional.map or whatever method in those language with Optional type
in kotlin
func add3 (val: Int?) = val ?.let { it + 3 }
Unfortunately, there is no such method in js currently, so it looks half baked.
Re: Why nullable types?
#106I 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…
If you are starting from scratch and designing a brand new language then ADT's are a clearly better choice than allowing null. However Dart is not a brand new language. It's a preexisting language that already has null. Given that context nullable types are the only option that doesn't break compatibility with previous languages and allows code to be made null safe. If you already have to have null values because of prior decisions then ADT's don't add null safety. There may be other reasons to want them that aren't about handling null safety. But you'll still have the problem that values can be null and you won't have given developers a tool to handle those potentially null values safely.
Re: Why nullable types?
#107I 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…
If you are starting from scratch and designing a brand new language then ADT's are a clearly better choice than allowing null. However Dart is not a brand new language. It's a preexisting language that already has null. Given that context nullable types are the only option that doesn't break compatibility with previous languages and allows code to be made null safe. If you already have to have null values because of…
This comment is answering post’s title more honestly than the author.
Less words too.
Re: Why nullable types?
#108Earlier quoted context omitted.
Ironically the main advantage of Monads is that Option > has a natural transformation to Option .
The reason Option > isn't a problem is because it's a monad, so people will naturally transform it into Option while writing their programs. There is no irony there. If it wasn't a monad, the GGP would be incorrect, and ad-hock solutions would be very valuable.
In a language with Haskell's guarantees, you can mechanically get from the standard "bind" function to prove that "m (m a)" can be converted to "m a" [1]. That function is called "join", and is a lesser-well known way to write monad implementations which is equivalent to the more famous bind function.
(IMHO, join is a better way to understand the typeclass intuitively. The standard bind is better to program with in general use, but much harder to grok.)
So, in Haskell, it's more than just "the APIs would tend to encourage not nesting the types"... having a valid monad implementation means they really are equivalent.
[1]: https://stackoverflow.com/questions/3382210/monad-join-funct...
Re: Why nullable types?
#109Is it me, or is the real answer: it's hard to retrofit optional types into a language, but you can add nullable types.
Nah, I was in early on both Swift and nullable dart - at the end of the day, Dart is preferable because it's using flow analysis to know when operations are safe, avoiding the noise of if...let and guard... (Yes, those are nice too, Dart is better! It feels much more ObjC-y)
Re: Why nullable types?
#110This is not intended as an attack, but a genuine question: what does Dart offer over any other language? Why would I choose Dart?
Had wondered this for a bit myself - I'm a bimobile developer, ObjC, Swift, to Java, to Kotlin over the last decade, now on Dart.
Dart is by far the most fun I've had in a language because it has an extremely simple surface area, and they really optimize for that, ex. here. But, Flutter is the revolution - utterly paradigm-shifting tool. Much like ObjC, you probably use Dart because it's what Flutter does, but not like ObjC, the simplicity, ease, and clarity of thought it allows is a benefit, as well as Swiss he army knife way the language can be deployed (Android app? Web app? Linux CLI tool? Windows 10 app?)