1. 19
  1.  

  2. 2

    Described features like sum types are cool and useful, but once you get language with static types, it’s all going down the rabbit hole: eventually, to express your domain model, you’re going to need ad-hoc polymorphism, higher-kinded types, GADTs, existential types, etc. Or to think how to overcome lack of some of these features in language.

    It would be interesting to read about experience in building “real-world” applications with reason/ocaml and how it feels to use language without ad-hoc polymorphism and some other features. If going from plain JS, everyone is accustomed to using overridden methods and just plain duck typing, which is a form of ad-hoc polymorphism, but with Reason, there’s no such feature. It would be interesting to hear how to deal with that.

    1. 8

      OCaml has (multiple) inheritance, you can pass records of closures if you want, and you can parameterize modules over other modules. There are a lot of options here already. Reason doesn’t really advertise the class based features so much but it’s still supported.

      1. 5

        …but once you get language with static types, it’s all going down the rabbit hole: eventually, to express your domain model, you’re going to need ad-hoc polymorphism, higher-kinded types, GADTs, existential types, etc. Or to think how to overcome lack of some of these features in language.

        One isn’t required to express the whole domain model with types, just because the language has them. There is a middle way.

        1. 2

          In a language without ad-hoc polymorphism, you’d write a map function for each type instead of an instance of Functor for each type, etc. It would be mostly as simple as that.