"Making Impossible States Impossible" by Richard Feldman

There is no escaping the mapping. It doesn't matter if it is Reason or PureScript, Elm, or Fable - you have to parse the incoming data into a static type if you want to enjoy the benefits of types. The good thing is that you can build the rest of your system with a firm guarantee on the shape and structure of the data. No null checks, no missing keys. If you are careful with your parsing you can raise exceptions or return None if the incoming data is not well-formed (missing keys or even extra keys). Reason/BuckleScript when run on a Javascript runtime also has a `Js.t` type which is basically the Javascript object. You do have to define the shape of it similar to how you'd define a record type, but you don't need to convert it into a native record. JS arrays are also natively supported - it maps 1:1 to BuckleScript's array. I like to convert arrays into lists since they are better suited for value-based programming (pattern-matching over [head, ...tail] inside recursive functions). And if you create your types in a way that invalid states are impossible, you've just reduced the cognitive load needed to work on the system for the rest of its life by an order of magnitude. Here are some resources on this wonderful programming technique: - [link] - [this video] - [link] - [link]

* Learn to think about types first, and the algorithms as a natural consequence of the structure of your data. Richard Feldman: [this video] , * Use a statically typed language that allows fast refactoring. Ideally a typed functional language like Elm, Reason, OCaml, or Haskell. I recently shipped a complex Javascript project (without types) and it is one of the few instances of my decade-old professional career where I had that level of confidence in the robustness of a piece of code I wrote. It remained sturdy in production even in the presence of unforeseen conditions. This was thanks to the habits I picked up from typed FP: parsing and validating all data at the boundaries of the system, better design by modelling data to make inconsistent states impossible, and automatically handling all edge-cases at all times. So even if you don't actively use such a language in your workplace, there really is a payoff to learning it in making you a better programmer overall.

Languages like F# give a nice sweet spot between static typing and dynamic typing. It has Type Providers that "generate" code on the fly as you are typing. You don't need to specify all the types, it will infer many types for you. So, you almost feel like you are writing in a dynamic language but you it tells you if you are writing something incorrectly. I would not consider a language to be modern unless it has Type Providers I consider this to be such an essential feature. I believe Idris and F# are the only languages that have it. People are trying to push TypeScript to add it - who knows if it will happen. Many are saying that if you have a dynamic language you just need to be disciplined and write many tests. With good static typed languages like F# you can't even write tests on certain business logic since the way you write your code you make "impossible states impossible", see [this video]

ReasonML is IMO quite ready for production work if you use it for building server-side applications with NodeJS or rich front-end applications with React (ReasonReact). The target audience for Reason (at least for the moment) are web application developers who want to level up as programmers and want to build elegant, sturdy production systems. Reason and Elm together are democratizing statically typed functional programming and I believe that the next 10 years are going to see a massive change in the programming language landscape, with the practice of typed FP finally finding adoption in mainstream commercial programming. The allure of Reason is in its packaging of OCaml to the web browser (which is made possible by BuckleScript - the actual OCaml to JS compiler doing the heavy lifting), its syntax that is familiar to the vast majority of programmers today, and the large ecosystem of bindings, libraries, and documentation that the team has put out. OCaml is a very pragmatic language; its main pull is its powerful static type system and immutable, functional programming, but the "O" in OCaml stands for "Objective" - it is an implementation of CAML with support for object-oriented programming. But you almost never need objects. OCaml's module system and its idioms allows you to write well-encapsulated code without mutation, and when you actually need to write honest to metal imperative code, you can do it with abandon because OCaml is not a "pure" functional language like Has

Sure, but the point is, a halfway decent type system will eliminate whole classes of errors—consequently eliminating whole swaths of things you would ever need to write tests for. What's more, though, is that a good type system will help you 'Make Impossible States Impossible'[0]—even more behavior you don't have to test because bad behavior is simply not representable in your program. Tests are strictly more powerful in the small, because they can be arbitrarily complex, but I would say a (really good) type system is more powerful in the large, because you get way more leverage in terms of overall program correctness. A lot of my personal projects are in Elm (yeah, yeah, bring on the hate)—the models are really well-defined, but the test suites usually only have a handful of tests of behavior I really want to verify. Haven't even played with the property checker yet, but again, that's something that is strictly more powerful than unit tests, but you can only get it* if you have a type system. [0] [this video] * Okay that's not really true: see clojure.spec in Clojure—but there are so few counterexamples that it's true for most practical purposes