To be fair, some of that space was spent writing map, which you didn’t have to do in your SML analogue (one could argue that such a natural and useful function should be a standard part of any language, but, whatever), and straightforward line counts are a bit misleading, when a slightly different brace-style would’ve removed quite a few of them from the Java. That’s the problem with trying to measure simplicity through brevity. The problem with this clunky code isn’t that it’s eleven lines long; the problem with this clunky code is that… it’s clunky.
(I agree with you on the sheer fear with which I imagine setting up, say, a usefully curried version of map along these lines)
Rysto: My point about MapReduce was that the functional paradigm is extremely useful. The fact Java doesn’t support it cleanly (which your own example serves to illustrate) tells you something rather nasty about Java.
I could get really nasty and ask you to whip up ML-style pattern matching in Java like I can in Common Lisp. But I won’t, because I know that Java really can’t do it without reimplementing the entirety of the Common Lisp macro system, something equivalent to writing a complete and arbitrarily extensible Java compiler in Java which outputs Java source code. (It’s extra nasty because writing a Java compiler is orders of magnitude more complex than writing a Common Lisp compiler.) However, I shouldn’t have to convince you that being able to write code like this:
(defun exists? (elt lst)
(match lst
(:nil nil)
((:cons x xs) (if (eq x elt) t (exists? elt xs)))
(:t (error "~A is not a list" lst))))
in a language with no ‘native’ support for pattern matching after only a few minutes’ trivial work is a huge credit to the language.
And, before you ask, macros are wonderful for condensing and making readable very large and nontrivial programs. Implementing control structures isn’t the half of it.