4 ms·

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. T

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.

CookieCutter2 11y ago
To clarify: Option/Maybe solves the problem of things either being there or not (from databases, domain modelling, ...). As a side effect this solves NPEs. Non-Nullable Types is there to solve (accessing non initialized variables) NPEs.
- mplatvoet 11y ago
  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.
  - CookieCutter2 11y ago
    Without proper Option deconstruction and map()/flatMap() syntacic sugar Option code beside map() is not very pleasent to read or understand to my eyes :-(
- mike_hearn 11y ago
  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.
  - CookieCutter2 11y ago
    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.
    - mshafirov 11y ago
      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.
doomspork 11y ago
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. Since Kotlin can leverage JVM libraries, why not use Google Gauva? https://code.google.com/p/guava-libraries/wiki/UsingAndAvoidingNullExplained#Optional https://code.google.com/p/guava-libraries/wiki/UsingAndAvoid...
- CookieCutter2 11y ago
  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.
mike_hearn 11y ago
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).
- CookieCutter2 11y ago
  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 val MyValueObject(a,b,c) = myObject

CookieCutter2 11y ago

To clarify: Option/Maybe solves the problem of things either being there or not (from databases, domain modelling, ...). As a side effect this solves NPEs. Non-Nullable Types is there to solve (accessing non initialized variables) NPEs.

mplatvoet 11y ago
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.
- CookieCutter2 11y ago
  Without proper Option deconstruction and map()/flatMap() syntacic sugar Option code beside map() is not very pleasent to read or understand to my eyes :-(
mike_hearn 11y ago
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.
- CookieCutter2 11y ago
  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.
  - mshafirov 11y ago
    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.

doomspork 11y ago

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. Since Kotlin can leverage JVM libraries, why not use Google Gauva? https://code.google.com/p/guava-libraries/wiki/UsingAndAvoidingNullExplained#Optional https://code.google.com/p/guava-libraries/wiki/UsingAndAvoid...

CookieCutter2 11y ago
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.

mike_hearn 11y ago

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).

CookieCutter2 11y ago
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 val MyValueObject(a,b,c) = myObject