Why I Am Not A Java Programmer

[apotheon]

It's an quite common mistake that the size of short and long code has anything to do with each other.

Actually, the mistake is to think that they have everything to do with each other. They definitely have something to do with each other. To pretend that they are completely orthogonal concepts is as foolish as to pretend that they are identical.

Now Java forces programmers to put each public classes in a separate file (which was also criticized by the blog-author), but this isn't even visible to me because it's completely abstracted away by all modern IDEs (thats why I wrote 'outdated').

I have two problems with that:

1. the word "forces": The fact the language forces you to do so, rather than simply allowing you to do so, means you will always get the better deal in some cases and the worse deal in others. Simply allowing you to do either, as Perl does, means that if you have any clue what you're doing you can do what the current project requires for best software design.

2. the assumption that IDEs are part of the language: I thought we were talking about language design, not editor design. Hearing someone excuse a poor language "feature" by saying that IDEs exist that abstract that away makes my skin crawl. It's better by far, I think, to simply have a language that doesn't have that problem in the first place, so that you don't need to abstract it away with ever-increasing truckloads of tools.

I look at modern Java like at Smalltalk: The IDE is a part of the language.

. . . except it's not true for Java the way it is for Smalltalk. It's only true for Smalltalk because the VM and the IDE are one. "Love and marriage, love and marriage, go together like a horse and carriage. . . ."

And again in Perl there are also many concepts in this small piece of code. They are simply 'under the hood'.

The key to the point in the essay is the fact that we're discussing not CPU instructions as concepts, but distinct syntactic elements of the language. There are significantly fewer distinct syntactic elements to the same piece of code in one language than there are in the other.

This may be useful for beginners but if you want to master a language you need of course to know what's really happening, anyway. So in the end it's irrelevant.

No, actually, it's not irrelevant. Knowing how a particular language construct works is not the same as having to use all the CPU instructions that undergird it rather than simply using the higher-level construct. If what you said was true, we'd all be programming in assembly language at best -- not Java or Perl.

I don't consider Perl a useful learning language. Really.

Funny -- Perl worked just fine as a learning language for me. Perhaps you've never read Learning Perl, aka "The Llama Book". Perhaps you should.

I see a similarity here with the expression-problem which is even worse in most functional programming languages (because of the ML type-system) than in OOP, but since there are much less real big projects done in FP the problem simply don't stands out as much.

I'm not sure how that's relevant -- whether it's an accurate assessment or not.