6 ms·

I don't see a reasons for null to exist in a new language in 2015.

• asterite 11y ago
  How do you model a "zero or one" relationship without null? Maybe your answer is "with Optional" (or Option, or Maybe). We just choose to use union types and have "Nil | T" (Nil or T) be the same as "Option(T)" in other languages.
  • raindev 11y ago
    Yes, Maybe (Optional) is the way to go. The difference is, with nil you basically make every type optional allowing it to have nil as a value.
    • asterite 11y ago
      Well, in Crystal Nil is a separate type that can be combined with others. But, say, a String is always a String, it doesn't implicitly have the Nil type. Same goes with every other type. Maybe you are thinking of Java/C#, where reference types can also be null, but this is not true in Crystal. It's also in a way similar (but not quite) to Swift, where optional types are different than types that can't be null.
      • vanderZwan 11y ago
        Do you have a technical write-up of how Crystal does that? Or otherwise some links/papers that explain the principle in a language accessible for someone who is basically self-taught and lacks a formal CompSci education?
      • wtetzner 11y ago
        It's a nice approach, I like it. There is a difference between Option[T] and (T | Nil) that's worth mentioning, however. Option[T]'s are composable. For example, let's say we have a "get" method to get the value for a given key, whose type looks like: get :: String -> (T | Nil) If we were using Option[T]'s, it would look like: get :: String -> Option[T] So let's say we have a map, and want to lookup a key (syntax is made-up): let m: Map[String,(Int | Nil)] = make_some_map() let result: (Int | Nil) = m.get("some-key") If result is nil, was the value of the key nil, or was the key not in the map? With Option[T]: let m: Map[String,Option[Int]] = make_some_map() let result: Option[Option[Int]] = m.get("some-key") Here result will either be None, in which case the key wasn't in the map, or Some(None), which means the value of the key was None. So there is an observable and potentially useful difference between (T | Nil) and Option[T].
      • lobster_johnson 11y ago
        Sounds exactly like union types in Ceylon (http://ceylon-lang.org/documentation/1.1/spec/html/introduction.html#unionandintersectiontypes http://ceylon-lang.org/documentation/1.1/spec/html/introduct...), which is an interesting approach.
    • raindev 11y ago
      I find the distinction important as it allows to establish a contract without falling into defensive programming. Null pointer analysis is great, I admit, but how it would help to write a library function without checking explicitly if its parameter is nil?
    • zak_mc_kracken 11y ago
      It's ONE way to go. There are others. Sum types supported in the language such as in Ceylon is another one. And yet another one is safe dereferencing operators (?.) such as in Kotlin.
  • tel 11y ago
    And to be honest, (T | Nil) is pretty difficult to distinguish from (Maybe a = a + 1). Complaints feel difficult to motivate to me anyway.
    • bjeanes 11y ago
      They both accomplish the same thing: no unexpected null. The exact mechanism was never the interesting part. Maybe being monadic does offer some other benefits but the killer advantage is the responsible handling of nil. Crystal doesn't seem to have a foundation in monadic programming so the type unions seem like a reasonable approach there.
      • lmm 11y ago
        The advantage of the monadic approach is that it's easy to abstract over, because it's just an ordinary type in the language. So e.g. in scala I can call the same "sequence" method on a List[Option[Int]] as I do on a List[Future[Int]] or a List[ErrorMessage \/ Int]]. Unions seem like more of a language-level feature, so I'm not sure you could abstract over them in the same way.
        • bjeanes 11y ago
          I totally agree. Ridding yourself of nils via the Maybe monad offers incredible abstraction potential, but would feel out of place in Crystal's Rubyishness without deeper thought into bringing other monads into play too. Nonetheless, I am thrilled that we are seeing more and more languages that don't have implicit nullability on any type.
        • bjeanes 11y ago
          I re-read my initial comment and can see some ambiguity in my phrasing "Maybe being monadic ...". That wasn't me saying "maybe it is true that being monadic..." but rather "the fact that Maybe is monadic..."
      • tel 11y ago
        That just depends upon whatever type abstraction capabilities Crystal grows. It probably won't be getting higher-kinded nominal types so generalizing over Monad is sort of dead in the water anyway.
  • Dewie3 11y ago
    > How do you model a "zero or one" relationship without null? With something that leaves "Nullpointer analysis" obsolete/useless.
    • seanmcdirmid 11y ago
      To be replaced with an analysis that finds unmatched cases (like None when you assumed Maybe)?
      • Dewie3 11y ago
        Why would a constructor be confused with a type constructor? I guess I just don't have any experience with this particular approach to "sums". Untagged variants?
    • asterite 11y ago
      A tiny observation here: we don't do "null pointer analysis". We do this kind of analysis for every type: if you invoke a method on a type and that method doesn't exist, you get a compile error. In the case of a type union, all types must respond to that method. "Nil | T" is just one particular type union, but you can also have "Int32 | String", etc.
      • Dewie3 11y ago
        Thanks, that clears things up. I assumed that Nullpointer analysis was a special case.
  • deleted 11y ago
    [deleted]
  • deleted 11y ago
    [deleted]