Always looking for something more simple than (my current) Scala.
- Argued with the developers, they have not clue about Option/Maybe and what it's good for. They offer non-nullable type which solves just one - minor - problem with Null
- No deconstruction
- Their documentation in the beginning mixed features and planned features without discrimination. Spend a lot of time to find out trying to make them work that the features they've described in detail were fantasies.
- With deconstruction I would give it a try in a project.
The development team has always been very friendly and welcoming. I suspect that they didn't have time for someone who was interested in "arguing" with them.
I was not 'arguing with them' but when asked what was missing I offered deconstruction for nicely using Option/Maybe for which I was told there are non-nullable types. Rest see above.
I personally would listen instead of attacking me.
The question is, why should this be part of the language or standard library? This can easily be achieved by a library.
The Kotlin type system does help though/is essential to correctly implement Option types where other languages like C# can not.
The essential part is you can/should define an Option type with a non-null upper bound. Otherwise you would have a Some() that still might contain a null value. So the side affect of solving NPEs you speak of is only there if a language actually supports non-null upper bounds.
Without proper Option deconstruction and map()/flatMap() syntacic sugar Option code beside map() is not very pleasent to read or understand to my eyes :-(
Non-nullable types aren't just about uninitialised vars, where did you get that idea? Consider that function parameters can also be nullable although you cannot help but initialise them. Nullable types (nonnull is the default) solve the issue of optionality: something that might be there sometimes but also may not be.
This is hard to explain and I didn't understand it either, after programming Java for 15 years. After 5 years of Scala I can't think of not using Option.
If you allow null as a return type you need to check for null if you want to use it or not. If you return Option[_] people e.g. just use map() on the return value and then map().map().map().map() on that etc. With Option your code usually does not care to check until the very last moment. Sorry my English is not good enough to make the point :-( And I know, saying "You need to use Option (and Applictives etc.) some years to grok" sounds arrogant and unsatisfactory. But I would not go back to a language without Option (and Applicatives etc.) usage in it's culture.
In Kotlin there's a bunch of null-handling operators, which allows you to really treat null as None. Like x?.y()?.z().
Moreover, you can define extension functions on nullable types, which covers Option's map and much more.
How is option different from proper nullability in the type system? In every case I've seen an option type be used, it was always a less efficient way of approximating how Kotlin does it.
Kotlin has deconstruction:
val (a,b,c) = myDataObject
Their documentation did indeed commit this sin when I first started using Kotlin last year. It's been cleaned up considerably and this is no longer an issue (except, I think, for the mysterious modules which appear to be an IDE specific concept).
1. Option solves a long list of programming problems (mostly around things being there or not, but others as well) while non-nullable types only solve NPEs.
2. Sorry, wording is vaque, often deconstruction is
The Phantom F4 had no main gun because everyone thought there were no dogfighst but only missle fights. Reality was different and they added a vulcan gun.
The F35 is not designed for dogfights but long range missle fights and stealth.
But unlike F4, F35 has a main gun, and I think that demonstrates the dogfight doctrine still has its way. Unfortunately that gun has its own problem [1].
- Argued with the developers, they have not clue about Option/Maybe and what it's good for. They offer non-nullable type which solves just one - minor - problem with Null
- No deconstruction
- Their documentation in the beginning mixed features and planned features without discrimination. Spend a lot of time to find out trying to make them work that the features they've described in detail were fantasies.
- With deconstruction I would give it a try in a project.