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.

Thank you!

@bkonkle​