[bguthrie]

I agree. Although I enjoyed and got some value from the article once I puzzled through the naming, it would not have killed the author to use more descriptive names, and it would have made the code much more beautiful, at least to me. As it is, it seems needlessly opaque. Clean code communicates intent, and this code made that intent more difficult to puzzle out than it needed to be.

I'm not saying I don't ever use one and two-letter variables names; they're useful where their meaning is unambiguous, as with small inner loops. But when your goal is to educate others, better to err on the side of verbosity. That to me is more literate than the alternative.

[sirclueless]

My philosophy is that the length of a variable or function name should be inversely proportional to the size of the scope it affects. This means that if a name is only local to the current procedure then it hardly matters what you call it.

I have no problem with his use of a procedure with the signature "let rec loop acc s .... in" when it is fundamentally a placeholder recursive control structure. Such a signature is as much a common boilerplate pattern in OCaml as "for (i = 0; i < length; i++) { ... }" in a C-like language.

That said, his top level procedures are named things like "apply" and "updates" which are possibly too generic, but OCaml has a nice module system so the names need only convey meaning unambiguous with relation to each other; there is no global namespace to pollute.

This is a common problem of clean functional languages: their declarations can be unambiguously correct with less specificacy. Function declarations need not specify subject and object of the sentences they represent since these can be inferred, they must only specify the verb. But this means skimming becomes less fruitful: one must read everything to understand anything.