I’ve always loved programming. My first language was Basic on the Commodore 64. Later I picked up VBScript, VB, Javascript, ABAP, Ruby, and a bit of Java.
At Relay Graduate of Education, where I was CTO from 2013 to 2015, we used PHP, and specifically the Symfony framework. The conventions of Symfony coupled with its MVC pattern eliminate some, though not quite all, of the chaos and noise endemic to PHP.
I learned a lot at Relay. One important lesson I learned was that especially in smaller organizations like Relay CTOs really must allocate some of each week – I’d estimate 20% is about right – to hands-on development. CTOs shouldn’t expect they’ll be able to “out code” full time developers who spend all day coding. But for myriad reasons – not least of which is credibility – CTOs must be able to code in the languages and frameworks of the organizational tech stack.
I came to Relay right from Deloitte, and while my experience delivering large scale programs at Fortune 500 technology and media companies had taught me a lot, it had been a long time since I had done much hands-on development, and I had never developed in PHP anything but “Tinkertoy” practice projects. While reading our code, evaluating data structures, was never an issue, writing PHP code was not an area where I could lead by example. I was keenly aware of this deficiency. My team, I’m sure, picked up on my lack of sure footedness. I regretted this and I think I was a less effective leader as a result.
So after I left Relay, believing (as I do now) that those who will do best in this economy are those who are at once deep technologists AND deep strategists, I committed to filling what I thought were gaps in my formal computer science education.
Through my ongoing work in CS Education I had become aware of the popular CS50 MOOC from Harvard University offered through Coursera. But rather than take the free Coursera version, I elected to enroll directly through the Harvard University Extension School, which cost me a couple thousand dollars in tuition, but also earned me 4 graduate credits in CS and access to the professor and TAs like any other Harvard CS student. After successfully completing CS50 in May 2016, I decided to continue on and take CS61, a deep systems programming class in C and x64 Assembly in which I did projects like building my own shell and developing a virtual memory page allocation routine.
After CS61 I still had a taste for something more and decided to take CS51, “Abstraction and Design in Computation”, which probably could be just as aptly titled “Functional Programming in OCaml”. CS51 was a complete flip from CS61. CS61 was deep down in the guts of the computer, dealing with registers and low level I/O. CS51, by contrast, seemed in the ether of math and higher order functions. And OCaml presented a totally foreign syntax, at least at first.
But once I started to tune in, once I opened my mind to a new way of approaching coding, the combination of succinctness and expressiveness blew my socks off. Here, for example, is the idiomatic solution to Euclid’s algorithm in OCaml:
let rec gcd a = function
| 0 -> a
| b -> gcd b (a mod b);;
The essential idea in functional programming is that everything is an expression and expressions evaluate, via substitution rules in line with the Lambda calculus, to values. That made a ton of sense to me. So too did the did ideas like map, filter, reduce, immutable state, currying, etc. Perhaps most importantly my exposure to OCaml left me convinced that static typing is the way to go — as Yaron Minzky of Jane Street, the largest institutional user of OCaml (though Facebook is catching on fast) says, a whole class of errors just go out the window with a type system like OCaml’s.
Back to Relay for a moment – one of the last projects during my tenure was a bake off between the two most dominant Javascript frameworks, Angular and React. We ultimately chose Angular but I liked what I saw in React and kept abreast of it in the time since, developing some projects of my own using React. During that time React’s popularity has grown a ton.
So when as I was doing my final project in CS51, a meta-circular OCaml interpreter, and heard about ReasonML, “a new syntax and toolchain” for OCaml that makes OCaml a bit more accessible syntactically to developers coming from languages like Javascript, I was intrigued. But when I really got excited was when I learned it was some of the same team building ReasonML that work on React. Thanks in large part to a transpiler from OCaml to Javascript developed at Bloomberg called Bucklescript, ReasonML is now a great way to build React applications as among numerous other benefits, ReasonML brings to React the full power of the OCaml type system. And as context, React was originally prototyped in a cousin and antecedent to OCaml, so this – React using OCaml (ReasonML) – is full circle and back to its roots for React.
There are numerous videos and tutorials out there about both ReasonML and using ReasonML with React (and React Native). If you’ve developed apps in React, I suggest you give it a try. There’s a learning curve at first for sure, but soon enough you’ll get the hang of it, and the OCaml type system coupled with capabilities like match (renamed “switch” in ReasonML) will make you a convert.
If you’re already pretty comfortable in FP, especially OCaml, and have some React in your bag, this YouTube video of a recent lecture by Jacob Bass is great. If you need a more gentle introduction, check out this ReasonReact tutorial by Jared Forsyth. Also check out the official ReasonML and ReasonReact documentation of course too. And the support from the ReasonML community on Discord is incredible.
ReasonML is still new and there are still rough spots here and there, especially when using it for production class systems. But it’s gaining momentum fast and has big companies behind it, along with a whole bunch of developers who know of course that Javascript is the lingua franca of the browser but would like to have an alternative with static typing for front end development in particular. ReasonML, which can be compiled down to Javascript via Bucklescript, is just that.
Here’s to Reason!