An invitation to ReasonML

Peter Deustch once quipped that if you get the data structures and their invariants right, most of the code will just kind of write itself. If I had to pick just one nugget of learning from my career in programming so far, that would be it.

The effects of a poorly designed model cascades across the codebase, forcing us to litter it with special cases. That is probably why Linus Torvalds once claimed that the difference between a bad programmer and a good one is whether they consider their code or their data structures more important. Terry Crowley's article Education of a Programmer makes a similar observation about how important the data flow is in the design of a system:

Jon Devaan used to say “design the data, not the code". This also generally means when looking at the structure of a system, I’m less interested in seeing how the code interacts — I want to see how the data interacts and flows. If someone tries to explain a system by describing the code structure and does not understand the rate and volume of data flow, they do not understand the system.

I decided to learn ReasonML because I wanted to work in a language that revolved around data. I had become dissatisfied with programming in dynamic languages like Ruby and Javascript, and all my code started feeling fragile and rickety as soon as it was written. To build large systems, I needed to have a crisp, confident knowledge of the shape and flow of data across the codebase at all times. But the unpredictability inherent in dynamic languages made this impossible.