Maybe before ML appeared in 1973... after that it's just Bondage and Discipline to repetitively declare non-machine types.

Note, I did not say never. But don't give me a line about how you use it all the time. You don't. If you think you do, go grep over your code; you may think you do but I still bet you don't, it's probably a perceptual bias where you notice the exceptions out of proportion to their actual occurance. If you still pass that test, congratulations, I was wrong, you're one of the five people who do it all the time. You should probably stop, as something is probably very wrong with your design.

Meanwhile, optimizing the syntax for this case is a terrible optimization decision. That's the real problem, forcing literally millions (conservatively) of type annotations that are totally redundant.

"I've seen some brilliant code written in Java (If you steer well clear of 'enterprise' etc)."

You don't see the brilliant code that was never written because Java doesn't offer you the ability.

I also point to the "brilliant code" that isn't Java code at all, but compiler and bytecode hacks, which I suspect had you taken the time to mention some examples of "brilliant code" would have been in the list. That's not brilliance you can credit to Java, it's simply stuff that was so desirable it had to be done despite the fact Java didn't permit it.

Shape foo = new Shape();

is often written separately:

Shape foo;

// Further down

foo = new Shape();

So in that instance it's easy to see in both places what foo is.

If you do have issues with the duplication, it wouldn't be crazy hard to just write a pre-processor to insert the Types on the left if you haven't specified them, before compilation.

I simply don't buy the notion that you can't write great code in language X. Language is largely irrelevant to how great the code is or isn't. Also irrelevant to how well you can scale, how successful your startup will be, etc etc

Great coders write great code. Languages are just ways of communicating that great code with machines, and other people.

Some people have managed to put out the necessary incentives, so such code does exist, but seeing a putatively great coder reach for Java as their first choice without such incentives is like seeing a putatively great coder reach first for Cobol... it pretty much proves they aren't a great programmer. Even if you want the JVM libraries, there are better ways.

Yeah, it's an opinion, but it's one from someone with the aforesaid experience in a lot of languages. It's like saying a great marathon runner can run a marathon in concrete shoes. Yeah, maybe they can, but seeing them choose it of their own free will would say an awful lot about their wisdom in shoe choice. Java is a language that simply loathes great code.

Besides, you seem to have missed the core point that optimizing the language for a case that doesn't come up often is a misfeature, no matter how you slice it. Optimize the language for the case that occurs most. "var X"-type syntaxes cover that. "var X" still works in your example, too; there's no reason that a smart compiler can't deal with that sort of separation between declaration and initialization.

Personally it seems like some programmers at some point dislike being restrained by anything and become slightly high and mighty about the whole subject - the whole "Unless you use lisp, you can't understand why lisp is the best language" BS.

Why is "var X"-type syntax better? Why does that create better code :/ Sorry, I don't buy it. "var X" would be less precise, and less useful than specifying the explicit type you want.

FWIW, I just checked for fun my own comet server written in Java against tornado (Python). Very similar functionality, except the Java one is a smaller codebase. It's as verbose as you want it to be.

Of course we all know that Lisp is just a semi-imperative hack. Real programmers use something more pure like Clean or Haskell nowadays.

Anyway, I just wanted to applaud you two for the civility ouf your discourse. It was an informative read.

Well, I know it prevents me from writing good code. I start writing it and it becomes so repetitive that I just get bored and do something else. I can't see progress quickly, and doing simple things involves a lot of work. (A new test case in Perl is one line in a file. In Java, it's an entire new file.)

I've also noticed that I can cleanup legacy Perl codebases very quickly, but legacy Java codebases are often a total loss. There is often Just Too Much slightly-tweaked editor-written boilerplate, instead of actual abstraction. It hurts to look at.

There is a reason that lots of smart people don't use Java and it's not because they hate popular languages.

Right, but everyone is different. It depends on how you think and your personal taste. Some people look at 'public void foo()' and apparently recoil in horror. I look at significant whitespace, or foo => |something| etc type syntaxes and recoil in horror.

Lots of people also claim that no one can be productive writing in pure assembly language, and while that may be true for many programmers, it's certainly not true for everyone.

I don't think you can really say which language 'smart people' use. Obviously there's a lisp/functional bias here on HN, but I'd be very surprised if 'smart people' congregate toward any one particular language.

I still think good programmers are defined by the code they write, rather than which language they choose to write it in.

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 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.

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

   // 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());
           };
       }
    );

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)

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.

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

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)

    compare (length y) (length x)

    compare (length x) (length y)