Also you're unable to show the code to a programmer unfamiliar with the syntax, without having to explain each character.

Yeah, well, you're also unable to show French to an English speaker without having to explain the grammar rules and define each word. To use a language, you have to learn it. To read a language, you have to learn it. (Reading is the harder of the two. When you are programming or speaking, you can say things the way you want to. When you are reading or listening, you have to understand the other person's way of speaking.)

Less tokens to say something != always better

I definitely agree with you there. Regular expressions are a good example of this -- way too much optimization for typeability at the expense of readability. It is much easier to read an expression when you have a little bit more verbosity; in the regex domain there are things like rx (Emacs Lisp) or Parsec / PArrows (Haskell). Easy to read, not too hard to write (is "\w+" much harder to type than "(many words)"? no.)

But it is also possible to be too verbose. If you just want to say:

    my @sorted = sort (length $a <=> length $b) @list

you really don't want to have to write:

   // file SortableByLength.java
   public interface SortableByLength implements Sortable, HasLength {}

   // your app code
   List sorted;
   Sorter sorter = new Sorter<SortableByLength>();
   sorted = sorter.customSort( list,
       new SortFunction {
           public Ordering compare(SortableByLength a, SortableByLength b){
               return a.length().compareTo(b.length());
           };
       }
    );

By the time you have written that, you have forgotten what you were actually trying to program. (Upon proofreading this, I realize that the sorters could all be specialized to a concrete type, and that would save a bit of typing. But when you factor out the anonymous class, you will want it to be generic.)

It also worth noting that the extra typing there is not to get type safety; I can get the same type safety with a lot less typing in Haskell:

    sorted = sortBy f list
         where f :: (HasLength a, Sortable a) => a -> a -> Ordering
               f x y = compare (length x) (length y)

Thanks for the examples, and I completely agree about regexps... Personally though, I would be more worried about typos, potential bugs or misunderstandings with the Haskel. For me, the Haskel is too close to regexp land.

If you look at the Java code you've pasted, there's not really anywhere you could typo a character or 2, and it still compile. You'd have to typo a lot, or completely write it in the wrong way for it not to work. It's absolutely explicit and clear what it's doing.

With the Haskel code, you could mistype or misread a single character, and it'd completely change the meaning of the code.

I agree it's more verbose than the Haskel example, but also IMHO more solid/safe.

Have you ever written any ML/Haskell?

It's nearly impossible to get past the type system unless your code is correct, especially for small chunks of code.

No, he is right; however, Java has the exact problem.

The place where this code will screw up is in the logic of the comparison routine. It will be difficult for the types of x and y (or a and b in the Java example) to be wrong, but it is easy to say:

    compare (length x) (length x)

or

    compare (length y) (length x)

instead of

    compare (length x) (length y)

Your tests will catch this, though.