
Effective ML - iamelgringo
http://ocaml.janestcapital.com/?q=node/75
======
jallmann
Good list, many are applicable to general hackery and not just ML. "Avoid
boilerplate" == DRY/Don't-Repeat-Yourself.

OT: I really enjoy jane street posts. They got me started with ocaml, just
because I didn't understand half of what they were writing about.

~~~
silentbicycle
No, "avoid boilerplate" really has a different meaning here. In ML, most of
what would be considered boilerplate in Java is either inferred automatically
or completely unnecessary. If you're writing boilerplate, you're adding code
that will get in the way of what you're trying to express with your code,
_and_ doing so in a way where you'll have to change it manually as your design
changes.

The most interesting one, IMHO, is "Make illegal states unrepresentable" -
many, many things can be structured as type constraints, and then the compiler
can exhaustively test them. A fairly cliche example of this is using a type of
"str TaintedString" for unchecked user input, and requiring it to be checked
and unpacked before passing it to the internals. (While it can be done in Java
or C++, it typically necessitates rewriting a lot of stuff all over the
codebase as code changes, so it's often too much trouble. In ML, it takes very
little effort.)

This strikes me as somewhat parallel to O'Keefe's advice in _The Craft of
Prolog_: rather than writing manual runtime checks, let unification itself do
the work. To check if a list is 4 cells long, rather than checking "length(L,
X), X = 4", just check "L = [_, _, _, _]".

~~~
jamii
> A fairly cliche example of this ...

A more practical example is <http://ocsigen.org/docu/1.3.0/XHTML.M.html>

The html type in Ocsigen is only capable of representing valid XHTML.
Polymorphic variants are really useful for this sort of thing.

------
silverlake
Rule #1: An API is an embedded domain specific language. I think most of his
bullet points are sub-elements of this general design idea.

