3 ms·

> Instead of Haskell we should be thinking of programming language research and how to get the best ideas into our mainstream languages. I see a lot of this ha

by cies 6y ago

> Instead of Haskell we should be thinking of programming language research and how to get the best ideas into our mainstream languages. I see a lot of this happening in Kotlin and Rust (not too mainstream, but clearly more mainstream than Haskell). Also FB putting it weight behind Reason/OCaml clearly shows the movement. To be fair: sdiehl did mention in the preso that copying these concept over to other languages takes 10-20 years. > How do we make immutability easy and ergonomic and get rid of nulls in C#? The problem here is: you dont. To some extend you have to get these things right from the start. The father of null, Tony Hoare, now considers it his $1B mistake. Why? Because this is hard to fix. > Can we have guarantees in our program. Sure you can. C# gives you some typing guarantees. Now pattern matching switch statements (with exhaustivity checking) combined with sum types are coming: this will help! But the guarantees that Haskell (and Idris/Elm/PureScript) bring are next level, and impossible to replicate in a language that does not encode purity in the type system nor has type classes.

lmm 6y ago
> I see a lot of this happening in Kotlin and Rust (not too mainstream, but clearly more mainstream than Haskell). But only at the most superficial level. It was heartbreaking to hear Kotlin ignore decades of Haskell and Scala experience when it couldn't be condensed into a 10-line example. They've adopted a fundamentally broken approach to representing absence and they'll regret it in 10 years, but it's already too late to fix it. Heck, look at Go ignoring Java's experience with not having generics.
- cageface 6y ago
  What do you see as the deficiency of kotlin's handling of nulls?
  - lmm 6y ago
    Nested nullable types collapse to the same type, meaning it's very easy for generic code to contain really subtle bugs. If you have some generic code that has a T? and assumes that whenever it is null it is not T, this assumption will be almost correct and very easy to miss during testing. Also, it's very common to have option-style code and as your code evolves you need to refactor it to either/result-style code (that includes a reason why something was not present) - indeed I'd say this almost always happens in code that lives long enough. In kotlin this is unnecessarily difficult because it's impossible to write code that works with both nullable types and an either/result-like type, and since null has special language-level support you can't even use the same syntax.
    - mwcampbell 6y ago
      For me, there are two killer reasons for Kotlin to handle nullability as it does: smooth host platform interoperability and zero overhead. The existing huge mass of JVM libraries use null, so by embracing that rather than adding a new wrapper object like Scala's Option (or even JDK 8+'s Optional), Kotlin works smoothly with all those libraries. And with some annotations, Kotlin's nullability support can be applied to those existing libraries. As for zero overhead, an Option or Optional is another object, and the overhead of that object can't be completely optimized away by the JIT. And both of these concerns apply to all of Kotlin's target platforms.
      - cies 6y ago
        I agree Kotlin has a sweet spot in JVM language design.
      - lmm 6y ago
        > The existing huge mass of JVM libraries use null, so by embracing that rather than adding a new wrapper object like Scala's Option (or even JDK 8+'s Optional), Kotlin works smoothly with all those libraries. Recent JVM libraries have (rightly) moved away from null. Using e.g. JDK8 streams from Kotlin is very cumbersome (noticeably more cumbersome than using them from Scala). The special treatment of interop also creates a bunch of special cases in the language that break your usual assumptions: extracting a common method call won't always work, adding explicit types can change behaviour. It's one of those things that looks like a good idea in the small but creates more problems in the large. > And with some annotations, Kotlin's nullability support can be applied to those existing libraries. Again this is a case of Kotlin refusing to learn from history. Look at what happened with the JSR308 checker and adding nullness annotations to existing libraries. Someone adds the annotations and everything seems great, then other people make changes to the library and don't maintain the annotations and they become lies. > As for zero overhead, an Option or Optional is another object, and the overhead of that object can't be completely optimized away by the JIT. People who care about zero overhead wouldn't be using Kotlin in the first place. The raison d'etre of the JVM is safer programming with fewer crashes, even if that means a little performance overhead some of the time. (For the record you're wrong: in the cases where the JVM stack-allocates an option or optional the memory pattern is exactly the same as if you'd used a nullable value instead. But that's not the point).
davedx 6y ago
Well nulls are gradually getting pushed away with newer C#. It's definitely something MS and .NET shops are investing in.

by cies 6y ago

lmm 6y ago

> I see a lot of this happening in Kotlin and Rust (not too mainstream, but clearly more mainstream than Haskell). But only at the most superficial level. It was heartbreaking to hear Kotlin ignore decades of Haskell and Scala experience when it couldn't be condensed into a 10-line example. They've adopted a fundamentally broken approach to representing absence and they'll regret it in 10 years, but it's already too late to fix it. Heck, look at Go ignoring Java's experience with not having generics.

cageface 6y ago
What do you see as the deficiency of kotlin's handling of nulls?
- lmm 6y ago
  Nested nullable types collapse to the same type, meaning it's very easy for generic code to contain really subtle bugs. If you have some generic code that has a T? and assumes that whenever it is null it is not T, this assumption will be almost correct and very easy to miss during testing. Also, it's very common to have option-style code and as your code evolves you need to refactor it to either/result-style code (that includes a reason why something was not present) - indeed I'd say this almost always happens in code that lives long enough. In kotlin this is unnecessarily difficult because it's impossible to write code that works with both nullable types and an either/result-like type, and since null has special language-level support you can't even use the same syntax.
  - mwcampbell 6y ago
    For me, there are two killer reasons for Kotlin to handle nullability as it does: smooth host platform interoperability and zero overhead. The existing huge mass of JVM libraries use null, so by embracing that rather than adding a new wrapper object like Scala's Option (or even JDK 8+'s Optional), Kotlin works smoothly with all those libraries. And with some annotations, Kotlin's nullability support can be applied to those existing libraries. As for zero overhead, an Option or Optional is another object, and the overhead of that object can't be completely optimized away by the JIT. And both of these concerns apply to all of Kotlin's target platforms.
    - cies 6y ago
      I agree Kotlin has a sweet spot in JVM language design.
    - lmm 6y ago
      > The existing huge mass of JVM libraries use null, so by embracing that rather than adding a new wrapper object like Scala's Option (or even JDK 8+'s Optional), Kotlin works smoothly with all those libraries. Recent JVM libraries have (rightly) moved away from null. Using e.g. JDK8 streams from Kotlin is very cumbersome (noticeably more cumbersome than using them from Scala). The special treatment of interop also creates a bunch of special cases in the language that break your usual assumptions: extracting a common method call won't always work, adding explicit types can change behaviour. It's one of those things that looks like a good idea in the small but creates more problems in the large. > And with some annotations, Kotlin's nullability support can be applied to those existing libraries. Again this is a case of Kotlin refusing to learn from history. Look at what happened with the JSR308 checker and adding nullness annotations to existing libraries. Someone adds the annotations and everything seems great, then other people make changes to the library and don't maintain the annotations and they become lies. > As for zero overhead, an Option or Optional is another object, and the overhead of that object can't be completely optimized away by the JIT. People who care about zero overhead wouldn't be using Kotlin in the first place. The raison d'etre of the JVM is safer programming with fewer crashes, even if that means a little performance overhead some of the time. (For the record you're wrong: in the cases where the JVM stack-allocates an option or optional the memory pattern is exactly the same as if you'd used a nullable value instead. But that's not the point).

davedx 6y ago

Well nulls are gradually getting pushed away with newer C#. It's definitely something MS and .NET shops are investing in.