3 ms·

People build less unions because these languages fail them. Just add sum types or something similar, it's a disgrace to not have them in 2021. Static typing goe

by c-cube 6y ago

People build less unions because these languages fail them. Just add sum types or something similar, it's a disgrace to not have them in 2021. Static typing goes wonderfully well with them, allowing for exhaustiveness checks and all that. The "people use fewer unions in Java" argument is like saying people used fewer lambdas in Java 1.6. Build it, and they will use it.

munificent 6y ago
> Just add sum types or something similar I think you're confusing union types and sum types, which are very distinct features. SML, Haskell, and Rust don't have union types. OOP languages can model sum types already. It's mostly a question of how much the surface syntax encourages that style.
- c-cube 6y ago
  I'm not confusing them :-) I think _closed_ union types (the syntax `a | b | c`) are almost as good as sum types, since they bring exhaustiveness checking to the mix. They also act as documentation. Crystal is a good example of a language leveraging this feature. The OO model of just subclassing a common class is quite poor by itself. Scala and Kotlin have a 'sealed' modifier to at least recover the exhaustiveness check. Both also have ways of safely doing the case switch on the object's class and simultaneously downcasting (Java too with its recent `match` construct, afaik). Does Dart have anything like that?
  - munificent 6y ago
    > The OO model of just subclassing a common class is quite poor by itself. Scala and Kotlin have a 'sealed' modifier to at least recover the exhaustiveness check. The natural OOP way to model an operation that must exhaustively be supported by a set of types is by making it an abstract method on a shared superclass. For problems where it's natural to keep the operations textually near each type, that works great. Otherwise, yes, you'd ideally have some notion of a sealed family of types so that you can do case analysis with exhaustiveness checking. That lets you ensure all operations are covered when you program either in OOP or FP style. Something I find odd is that FP folks often criticize OOP languages for not supporting exhaustiveness checking, but I rarely hear them admit that most FP languages don't have support for the other style that OOP does well, which is abstract methods.
    - c-cube 6y ago
      As far as typed FP languages go: - Scala has the whole OOP stuff - F# as well - SML: you probably need to do it by hand, with a record of closures, or something like that. It's ugly but it works. - OCaml has objects (it's in the name), first-class modules, or records-of-functions; all of which can replace abstract methods successfully. - Haskell can rely on typeclasses to do the virtual dispatch, I think. Not an expert on that. So I'd say it might not be as ergonomic, but the capability is still 100% there.

by c-cube 6y ago

munificent 6y ago

> Just add sum types or something similar I think you're confusing union types and sum types, which are very distinct features. SML, Haskell, and Rust don't have union types. OOP languages can model sum types already. It's mostly a question of how much the surface syntax encourages that style.

c-cube 6y ago
I'm not confusing them :-) I think _closed_ union types (the syntax `a | b | c`) are almost as good as sum types, since they bring exhaustiveness checking to the mix. They also act as documentation. Crystal is a good example of a language leveraging this feature. The OO model of just subclassing a common class is quite poor by itself. Scala and Kotlin have a 'sealed' modifier to at least recover the exhaustiveness check. Both also have ways of safely doing the case switch on the object's class and simultaneously downcasting (Java too with its recent `match` construct, afaik). Does Dart have anything like that?
- munificent 6y ago
  > The OO model of just subclassing a common class is quite poor by itself. Scala and Kotlin have a 'sealed' modifier to at least recover the exhaustiveness check. The natural OOP way to model an operation that must exhaustively be supported by a set of types is by making it an abstract method on a shared superclass. For problems where it's natural to keep the operations textually near each type, that works great. Otherwise, yes, you'd ideally have some notion of a sealed family of types so that you can do case analysis with exhaustiveness checking. That lets you ensure all operations are covered when you program either in OOP or FP style. Something I find odd is that FP folks often criticize OOP languages for not supporting exhaustiveness checking, but I rarely hear them admit that most FP languages don't have support for the other style that OOP does well, which is abstract methods.
  - c-cube 6y ago
    As far as typed FP languages go: - Scala has the whole OOP stuff - F# as well - SML: you probably need to do it by hand, with a record of closures, or something like that. It's ugly but it works. - OCaml has objects (it's in the name), first-class modules, or records-of-functions; all of which can replace abstract methods successfully. - Haskell can rely on typeclasses to do the virtual dispatch, I think. Not an expert on that. So I'd say it might not be as ergonomic, but the capability is still 100% there.