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 com

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 = [_, _, _, _]".