4 ms·

It's perfectly fine to use nulls in languages that encode them in their type system, e.g. Kotlin.

junke 10y ago
Exactly. The problem is not that there is a null, it is that it is a valid value for all types (e.g. you can pass null to a function that expects a String). Allowing nulls explicitly, like with a "String?" type, is the way to go in languages where Option is not an option.
- kqr 10y ago
  Isn't it, in practise, basically the same thing though? The theoretical difference is this: 1. Option is a regular data type/object that represents "a collection of at most one value". It's similar to a list, set, heap, tree or whatever other collection types you have, except it can not contain more than one value. 2. With explicit nulls I guess any data type (e.g. Integer) will automatically get a clone of itself (a different type named Integer?) where also null is a valid member. From a purely theoretical standpoint, I like #1 better.
  - greydius 10y ago
    In practice, it's not the same thing. Here's a Java example where I want the type system to enforce that a method in `ClassB` can only be called from `ClassA`. However, the fact that `null` circumvents the type system makes this pattern just wishful thinking. class ClassA { private static final Witness witness = new Witness(); final static class Witness { private Witness() {} } void callClassBMethod(ClassB classB) { classB.onlyClassACanCallThisMethod(witness); } } class ClassB { void onlyClassACanCallThisMethod(ClassA.Witness witness) { // ... } }
  - kmiroslav 10y ago
    The downside of `Option` is that it's a wrapper, and as such, you need to `flatMap` (or similar) whenever you want to access the wrapped value. By encoding `null` in its type system, Kotlin lets you manipulate these values directly which leads to code that is much less noisy and just as safe.
    - airless_bar 10y ago
      Not really. The main strength of the first approach is that Option is only one type out of many error-handling structures. Not every error is handled appropriately by Option/?. If you have a language like Kotlin where they hard-coded one way of handling errors, it feels very unidiomatic to pick a better fitting error handling type, while in languages where errors are handled by library code, it's a very natural approach.
      - kmiroslav 10y ago
        > Not every error is handled appropriately by Option/?. Which is expected since these two constructs are not aimed at handling errors: they manage missing values. > If you have a language like Kotlin where they hard-coded one way of handling errors No, no. `?` is not for handling errors. Kotlin is as agnostic as Scala for managing errors: you are free to use exceptions, dumb return values or smarter ones (`Either`, `\/`, `Try`, ...).
        airless_bar 10y ago
        Yeah, it's just that-if you look at every language ever designed-if the language ships with a built-in construct developers will use and abuse it on every occasion, and every other approach lingers in obscurity. > Which is expected since these two constructs are not aimed at handling errors: they manage missing values. Which is a very small part of handling errors in general. As Kotlin offers special syntax for only this case, developers tend to shoehorn many errors into the "missing-value" design to get the "nice" syntax even if a different approach would have been more appropriate. > Kotlin is as agnostic as Scala for managing errors: you are free to use exceptions, dumb return values or smarter ones (`Either`, `\/`, `Try`, ...). That's not true in practice: Just have a look at funktionale: Despite providing almost the same as Scala's error handling types (partially due to the blatant copyright violations) almost nobody uses it. This is a direct result from having a "first-class" construct in the language: It turns library-based designs into second-class citizens. That's the thing Scala got right, and many of the copy-cat languages got wrong.
  - SatvikBeri 10y ago
    I think Option[String] and "String?" are semantically both a union type–they both effectively add one possible value to the underlying type, along with a constructor for naturally extending functions on that type–Kotlin's "?" operator is equivalent to Scala's map or Haskell's fmap, etc.
    - airless_bar 10y ago
      Option[Option[String]] != String??
      - junke 10y ago
        Option[Option[String]]? Is this a Church Numeral?
      - SatvikBeri 10y ago
        My impression, though I'm not sure, is that Kotlin simply won't allow you to do a double "??". Scala etc. will technically allow Option[Option[Something]], but in practice you would almost never want to use it, and can easily avoid it with flatMap.
        airless_bar 10y ago
        The whole point of this was to show that Scala's types preserve the structure of the computation. It might not be very interesting in the Option[Option[String]] case but imagine Try[Either[String, Int]] or List[Future[Double]]. It's a very important distinction. Collapsing cases is one of the primary thing why exceptions sometimes get a bad rap, and Kotlin (and Ceylon) do the same with ? (and |, &) at the value level.
pjmlp 10y ago
Eiffel was one of the very first ones to have that feature actually, around 2006 when the language was revised for the ECMA standard. https://www.eiffel.org/doc/eiffelstudio/Differences%20between%20standard%20ECMA-367%20and%20Eiffel%20Software%20implementation#Void-safety https://www.eiffel.org/doc/eiffelstudio/Differences%20betwee...

junke 10y ago

Exactly. The problem is not that there is a null, it is that it is a valid value for all types (e.g. you can pass null to a function that expects a String). Allowing nulls explicitly, like with a "String?" type, is the way to go in languages where Option is not an option.

kqr 10y ago
Isn't it, in practise, basically the same thing though? The theoretical difference is this: 1. Option is a regular data type/object that represents "a collection of at most one value". It's similar to a list, set, heap, tree or whatever other collection types you have, except it can not contain more than one value. 2. With explicit nulls I guess any data type (e.g. Integer) will automatically get a clone of itself (a different type named Integer?) where also null is a valid member. From a purely theoretical standpoint, I like #1 better.
- greydius 10y ago
  In practice, it's not the same thing. Here's a Java example where I want the type system to enforce that a method in `ClassB` can only be called from `ClassA`. However, the fact that `null` circumvents the type system makes this pattern just wishful thinking. class ClassA { private static final Witness witness = new Witness(); final static class Witness { private Witness() {} } void callClassBMethod(ClassB classB) { classB.onlyClassACanCallThisMethod(witness); } } class ClassB { void onlyClassACanCallThisMethod(ClassA.Witness witness) { // ... } }
- kmiroslav 10y ago
  The downside of `Option` is that it's a wrapper, and as such, you need to `flatMap` (or similar) whenever you want to access the wrapped value. By encoding `null` in its type system, Kotlin lets you manipulate these values directly which leads to code that is much less noisy and just as safe.
  - airless_bar 10y ago
    Not really. The main strength of the first approach is that Option is only one type out of many error-handling structures. Not every error is handled appropriately by Option/?. If you have a language like Kotlin where they hard-coded one way of handling errors, it feels very unidiomatic to pick a better fitting error handling type, while in languages where errors are handled by library code, it's a very natural approach.
    - kmiroslav 10y ago
      > Not every error is handled appropriately by Option/?. Which is expected since these two constructs are not aimed at handling errors: they manage missing values. > If you have a language like Kotlin where they hard-coded one way of handling errors No, no. `?` is not for handling errors. Kotlin is as agnostic as Scala for managing errors: you are free to use exceptions, dumb return values or smarter ones (`Either`, `\/`, `Try`, ...).
      - airless_bar 10y ago
        Yeah, it's just that-if you look at every language ever designed-if the language ships with a built-in construct developers will use and abuse it on every occasion, and every other approach lingers in obscurity. > Which is expected since these two constructs are not aimed at handling errors: they manage missing values. Which is a very small part of handling errors in general. As Kotlin offers special syntax for only this case, developers tend to shoehorn many errors into the "missing-value" design to get the "nice" syntax even if a different approach would have been more appropriate. > Kotlin is as agnostic as Scala for managing errors: you are free to use exceptions, dumb return values or smarter ones (`Either`, `\/`, `Try`, ...). That's not true in practice: Just have a look at funktionale: Despite providing almost the same as Scala's error handling types (partially due to the blatant copyright violations) almost nobody uses it. This is a direct result from having a "first-class" construct in the language: It turns library-based designs into second-class citizens. That's the thing Scala got right, and many of the copy-cat languages got wrong.
- SatvikBeri 10y ago
  I think Option[String] and "String?" are semantically both a union type–they both effectively add one possible value to the underlying type, along with a constructor for naturally extending functions on that type–Kotlin's "?" operator is equivalent to Scala's map or Haskell's fmap, etc.
  - airless_bar 10y ago
    Option[Option[String]] != String??
    - junke 10y ago
      Option[Option[String]]? Is this a Church Numeral?
    - SatvikBeri 10y ago
      My impression, though I'm not sure, is that Kotlin simply won't allow you to do a double "??". Scala etc. will technically allow Option[Option[Something]], but in practice you would almost never want to use it, and can easily avoid it with flatMap.
      - airless_bar 10y ago
        The whole point of this was to show that Scala's types preserve the structure of the computation. It might not be very interesting in the Option[Option[String]] case but imagine Try[Either[String, Int]] or List[Future[Double]]. It's a very important distinction. Collapsing cases is one of the primary thing why exceptions sometimes get a bad rap, and Kotlin (and Ceylon) do the same with ? (and |, &) at the value level.

pjmlp 10y ago

Eiffel was one of the very first ones to have that feature actually, around 2006 when the language was revised for the ECMA standard. https://www.eiffel.org/doc/eiffelstudio/Differences%20between%20standard%20ECMA-367%20and%20Eiffel%20Software%20implementation#Void-safety https://www.eiffel.org/doc/eiffelstudio/Differences%20betwee...