ReasonML & OCaml
A Reasonable Compromise
A
Persistent
Dilemma
State
A value at a moment in time. This could be UI status, data from endpoints, configuration, user input, or any number of other variables.
Shared state
As complexity grows, so does shared state. Design patterns like OOP and FP are a way to manage that complexity.
OOP
Object-Oriented Programming segregates shared state into object instances with interface methods, allowing each object to manage state independently.
State Intensifies
How to manage state in Object-Oriented code?
- Create more objects
- Group objects into packages
- Make some methods private
- Use more abstract interfaces
- SOLIDly embrace Uncle Bob
Eventually, your code is only expressing a portion of the logic involved.
A
Problematic
Solution
FP
Functional Programming seeks to minimize state and restrict it to carefully controlled portions of your application.
Mathematical!
It embraces strategies from category theory to enable compositional programming. Complex abstractions are built up from smaller, pure operations that can be combined in solid and predictable ways.
Wizardry
In practice, runtime errors and unpredictable side effects are much less of an issue. Complexity remains a constant foe, however, especially in languages with terse syntax and user-defined operators.
Performance
Functional programming was introduced in the 1950s with LISP. It actually came before OOP!
At the time, memory was very expensive. OOP required less memory.
Even today, mutation gives Object-Oriented code a performance advantage while sacrificing predictability.
Enter
OCaml
OCaml...
- ...is a multi-paradigm (FP & OOP) language with an emphasis on expressiveness and safety.
- ...has a sound type system with rich inference, user-defined algebraic data types, and pattern matching.
- ...has a sophisticated module system with support for type-level programming.
- ...has automatic memory management (garbage collection).
- ...surprisingly, has a lot in common with JavaScript!
vs. Haskell
- OCaml has less concurrency support
- OCaml has a less mature standard library and ecosystem
- OCaml's eager evaluation means more predictable performance and memory consumption
- OCaml's modules are simpler than typeclasses
vs. Scala
- OCaml represents OOP in FP, while Scala does the opposite
- OCaml's type system is more reliably sound
- OCaml's type inference is richer, as there are no implicits or overloading to parse
- OCaml compiles much faster
OCaml
For the Masses
ReasonML...
- ...uses a very familiar syntax, similar to JavaScript
- ...targets native platforms like Mac and Windows, and web-based platforms like browsers and React Native.
- ...uses a toolchain that provides an npm-style workflow whether you’re compiling to JavaScript or native platforms.
- ...allows for gradual conversion of JavaScript codebases.
Pattern Matching
"Codify" your domain knowledge as custom types, and use a switch statement to make decisions based on them.
Exhaustive checking ensures you don't miss a case. Type arguments allow you to pass additional data with a variety of uses.
Reason-React
Polymorphic Variants
Custom, flexible types that don't have to be defined and imported in order to be used. The types can be used interchangeably in many situations.
Compositional Programming
The sound type system allows for powerful abstractions based on category theory.
Extension Points
Allows you to pre-process your OCaml code, transforming it before it is compiled.
This
looks
hard.
Why
should
I?
Pay off technical
debt up-front.
- Less time testing and refactoring.
- When things break down, it's often
easy to see false assumptions. - Sound completeness of the type
checker aids in finding bugs. - Code needs to be more thoroughly
thought out before it will type check. - More time needs to be invested
up-front to handle edge cases.