The examples that you list above don't really matter. Whitespace, "public static void main", sigils on variable names, and so on may look weird when you aren't used to them, but they don't detract from the programming experience.

What matters is how many tokens you need to say something simple. Say you have a list of words, and you want to sort it by length. That's one line of code in Perl, Python, Ruby, Common Lisp, Haskell, etc. It is not one line of code in Java.

When every simple concept in your program requires a new class with a new file, it just becomes unmanageable, even with the best tools. That's why I can't be productive in Java. (Java also doesn't allow quick hacks; private is private, so fuck you. This means that prototypes have to be "as good as" the real implementation, which simply means that you don't prototype. The resulting software sucks accordingly.)

But anyway, I know you have a pretty good app written in Java. I would like to hear more about how you deal with it sometime.

I think foo => |something| does detract from the programming experience. Special characters that have different meanings depending on context are a PITA. Also you're unable to show the code to a programmer unfamiliar with the syntax, without having to explain each character.

I don't really subscribe to the "Less tokens to say something = always better". As long as it's easy to see what's happening... I do agree collections, and specifically sorting is one area Java is slightly lacking, but it's not a big deal really.

Hopefully I'll release the comet server open source sometime. It's similar to tornado in functionality, but slightly smaller codebase. I think it'd surprise a few people about how you can write Java code if you choose to.

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.