Sadraskol

Response to Vjeux article on Ocaml

Vjeux works on React at Facebook. He published a small list of things that he feels are bad patterns in Ocaml language. I can't have an opinion on Ocaml itself, since I don't know the language, but I disagree strongly on some point he makes about functional programming.

Naming is the most difficult thing in computer science

This famous quote by Phil Karlton captures a lot of our job: naming things is hard, because it's the only way we have to carry meaning and intentions. Here's the example vjeux uses to critisize a bad style of writing code:

array.map(fn)
array.map(x => fn(x))

I'm gonna stop a moment to make fun of the author: he said some lines before this snippet that:

This means that you end up with a bunch of places with inconsistent names for attributes or even worse, one letter names

The snippet of code is the worst example you could give, in vjeux's own judgement! All names in here are ambiguous, unclear, and completely obscure the argument being made:

The issue is that the poor name does not allow to discuss the main point: passing arguments is more explicit than passing functions. How can x => fn(x) be more explicit than fn? I could say that meanTimesToFinish.map(addToStats) is more readeable than array.map(x => fn(x)), but the poor choice of example does not allow to judge.

Please name things correctly in your examples and we might discuss it in details.

Partial evaluation

When declaring a function with multiple arguments in a functional language, what you really do is declaring a chain of functions. The equivalent in javascript is currying:

let add = (left) => (right) => left + right;
// equivalent to add(left, right) {...}

This is pretty practical when you need to contextualize an operation. For instance:

addInDatabase database left right = in database do left + right
-- somewhere else
let add = addInDatabase database
-- use 'add' without bothering with the database anymore

Although it might be counter intuitive when the only language you know are C like, but partial application (or evaluation) is quite useful when you want to compose functions together. And that's pretty useful when composition is at the core of functional languages.

Of the lack of early return

You can use Maybe, more generally monads to stop computation when it's not needed. For instance, such a construct heavyComputation = doALotOn Nothing, will be compiled as a no operation, skipping the heavy computation.

I'm not sure early return is needed in functional computing, once again the lack of concrete and thorough example does not allow to discuss the idea in depth.

My opinion

Everyone has an opinion, and I'm not blaming Vjeux to give his. I regret that he does not provide any in depth argument and examples to illustrate his points. Sharing ideas is much more interesting when they give room to other people to discuss and eventually respond in a positive way. I feel like he didn't go far in his usage of functional languages. Here, the lack of culture makes the opinions pointless.

It might feel stupid but I feel like this lack of culture and proper documentation is the reason documents like the "google memo" do exist, a combinaison of seclusion and a false idea of sharing idea. For ideas to spread, you need to have an opinion, but not any kind of opinion, a documented one. Otherwise you will not spread ideas, but preconception, biases and false information.