[Stormbringer]

??? I'm not trashing Java. Did you read the article? I was making an analogy between the risk of having a language like Scala, which would mean there was stuff the Java-only people would not understand (which is what the article claims), with the black box auto-generated code produced by early J2EE (which is similarly a no-fly zone).

Believe me, you'll know when I'm trashing Java, because I'll use the g word.

[Semiapies]

"...with the black box auto-generated code produced by early J2EE"

If this comparison were analogous, your point would make no sense, since it would boil down to in the bad old days, we got stuck with code we couldn't understand and lived with it, so now, code we can't understand isn't a problem.

And it's not analogous. We're not talking about black-box generated code nobody on the project understands, but instead people on the project making code that other people on the project don't understand. To harp on the one detail of incomprehensible code ignores huge differences in those situations. So, it's gratuitous to evoke that.

[Stormbringer]

Not to pick on you, but I've worked on plenty of Java projects where there were sections of the code that some of the programmers either didn't understand or didn't want to touch with a bargepole because they were 'too scary'.

Taking the example of J2EE, on a sufficiently large J2EE project (where 'sufficiently large' is 3 or more people) it would be trivially easy for a Java programmer who didn't know J2EE to work on it - since there's usually a lot more to it than just the back end persistence bit. (Front end, middle layer services, business illogic etc)

Or say they are using both an obscure database and hibernate and I spend a significant amount of time trying to get them to agree on how date formats will be read and written (don't laugh, nobody else could figure it out). When I do get it working, does everybody else on the project magically absorb this newfound expertise via osmosis or something? Don't be ridiculous! Only I have the understanding of it, and if the others know what is good for them they will not fiddle with it.†

Naturally I'll liberally sprinkle it with comments like:

// if you want to retain your SAN points, don't mess with this

In fact, this thing of someone working on something that is really tricky and then when they do get it working warning off the other programmers from messing with it is extremely common in larger projects. One of the benefits of OO code is that you can segment the 'nasty stuff' off from the rest of the code so that it can be safely ignored. And this doesn't just apply to senior programmers doing stuff too scary for the junior programmers, it can work the other way too - as a senior member of the team I'm quite happy to let someone junior with lots of 'fire in their belly' tackle the ugly ugly task of getting the config files set up, and if they've done it right I never even have to look at them (don't be outraged, it's called delegation).

If you have to twiddle your ant script every time you want to compile your code, you ain't doing it right.

---

† the corollary of this is: that there is always a fiddler.

But when they break it you're allowed to laugh at them and then tell them to put it back the way it was when they found it

[Semiapies]

"I've worked on plenty of Java projects where there were sections of the code that some of the programmers either didn't understand or didn't want to touch with a bargepole because they were 'too scary'."

And this is undesirable, is it not? Encapsulation aside, sometimes people get shuffled around in projects.

It's one thing to say, "OK, junior developers, don't mess with the tricky stuff in this project." It's another to say, "OK, I've decided to start writing this part of the project in a language the rest of you don't actually know."