Lambda the Ultimate

Let's move on to your 'J2EE is in a thousand successful commercial applications and cannot be considered acedemic'. But you didn't really address the question there. J2EE is woefully academic - they focus far too much on what is RIGHT, as opposed to what makes sense from a practical standpoint.

So "acedemic" means "not in use in successful commercial applications" and "focussing far too much on what is RIGHT". How much focussing on what is RIGHT is too much, I wonder? And just how unsuccessful do you have to be?

Prior to hanging out in this place, I thought Java was pretty cool. Now, not so much.

A 7,000 class project in Perl would never be feasible. A 7,000 class project in Java is commonplace.

Surely the second sentence is an overstatement. And if not, surely the first statement is incorrect.

Another quote from the article:

The most insightful comment I saw on this subject was on Slashdot, where somebody said with all sincerity, that Java will be the next COBOL. Not that Java isn't a better language, but it will be what a lot of overly complex business apps will be written in, for better or worse... and they'll always need to be maintained.

Is that progress? Most of the programs I've seen written in COBOL don't need to be maintained; they were written to run forever. Given that fact and the reputed proliferation of 7,000-class Java projects, I would sooner conclude that COBOL is the new COBOL (e.g., COBOL.NET).

"It was almost impossible to argue against Java a couple of years ago, now it is 'officially' uncool..."
hmm, I remember I could argue against Java as much as 5 years ago and people weren't avoiding me socially.

"Most of the programs I've seen written in COBOL don't need to be maintained;"
So people looking for COBOL programmers want them just to write new programs in COBOL?

I don't see what the issue is. Java only exists as a political object. At one point it favored various agendas to get things like garbage collection into the mainstream. Now its use is as a punching bag. Not only is this predictable, but a correct strategy.

Especially since from physics we know that the friction of a moving object tends to be lower than that of something at rest. This analogy seems logical in the context of market adoption of programs like programming languages.

Ehud Lamm asks

Aren't you really implying that OOP is the reason the Java code is less maintainable?

No, nor do I have any desire to pursue that line of argument. What I was stating is my experience with existing COBOL codes. Most I've seen was written 10s of years ago by seasoned developers (now long gone) who apparently captured the problem areas at an appropriate levels of abstraction. Most problems with change are captured in tables. The users handle any changes other than OS maintenance.

Alex Tibble raises an interesting issue about software maintenance. I once had the pleasure of working with a fine developer noted for his extremely fast programming ability. His motto was "Software that doesn't require maintenance is not being used." He was constantly updating his systems to add new classifications, categories and date ranges! When I looked over his shoulder awhile, I realized that most, if not all, his effort could have been eliminated had he stepped back and enlarged the problem domain to encompass his maintenance. And that is my primary contention: capturing a process at the appropriate level ensures minimal maintenance.

In a job interview with the head of the (former) Enron IT division, I asked how they handle the changing requirements of the SEC, FERC and their various customers. The fellow replied that their software base was virtually rewritten every 3 months and, as a consequence, the IT division was very busy! I then asked what would happen should the SEC ask them about transactions occurring say, 18 months ago. He replied that they would set up a server, load the old software and data from backups and perform the inquiries. Some types of inquiry, e.g., comparing business properties across IT system upgrades, could not be done within the existing system.

I suggested that possibly Enron's business models could be captured at a higher level, perhaps by a rule-based system. This flummoxed him, since he was neither familiar with that technology, nor did he readily accept the notion that Enron's constantly-changing business situation could ever be captured in any software model. My conclusion was that Enron IT was "thinking too small"; they were so busy coding software that they had no time to correctly characterise appropriate solutions. I declined their offer.

We know today that Enron's business situation was complex, perhaps intentionally so. Years later, after Enron's collapse, I spoke to one of the persons auditing the firm. He verified that, despite the abundance of IT systems and data, determining what Enron was doing after the fact was well-nigh impossible. Perhaps this supports the "Good software requires maintenance" school of though, but I prefer to think it supports for the "Good software captures the problem domain" school of thought.

Jerry Boetje's statement depresses me:

Coming out of industry and now in academia, yes - 7000 is not only commonplace but a bit on the small side. One company (whose product isn't all that big) has about 12,000.

but maybe that's just my personal problem. I find it difficult to believe that such a situation is commonplace. Possible, yes; commonplace, no. Of course perhaps I'm merely on the losing end of a "Mine is bigger than yours" argument!-)

And am I the only one who thinks that a even a seasoned developer walking into a new job would be overwhelmed when informed that the system has 7,000 classes? And, were he to leave and go to another firm, that the 7,000 classes he knew would become much less useful, to be replace by another different 7,000 classes? At what point would one not step back and design a class-manager and a metalanguage to generate Java code?

Florian Hares, you're scaring me! Halloween is approaching - perhaps I should offer tribute to the goddess COBOL to ensure my safety. On a more serious note, I'd be curious to see how much of those 5 million new lines of COBOL code are new development and how much are maintenance.

Given the apparent complexity of Java and the continued growth of the COBOL code base, perhaps the new Java is COBOL?

what about the underlying database structure of such systems? Undoubtedly these systems are forged atop relational databases which have the ability to enforce referential integrity (RI) rules, constraints, stored procedures and triggers to protect the data. The task of ensuring data integrity and the consistency of database rules with "business rules" (as captured in Java objects) would, it seems, be beyond human ability, but well within the grasp of appropriate tools. So who writes those tools?

Or is the relational database merely used as storage, with referential integrity being disabled, constraints, stored procedures and triggers lying unused and all data validation and rule enforcement maintained in the business rules?

Or heck, maybe data is merely written to files:

"Relational databases? Relational database? We don't need no stinkin' relational databases!"

And to Marc Hamann who stated:

You are assuming that each of those 7000 classes must be learned to do useful work with the system, and that they are complicated enough to NEED to be learned.

I agree in general. But there is a caveat: you must understand completely what lies within the objects you use. As someone once said (about OOP in general and operator overloading in particular, not Java per se):

"When adding two numbers together can result in sending an email to Cairo, you must understand your software."

[6.4] Is C++ better than Ada? (or Visual Basic, C, FORTRAN, Pascal, Smalltalk, or any other language?)

This question generates much much more heat than light. Please read the following before posting some variant of this question.

In 99% of the cases, programming language selection is dominated by business considerations, not by technical considerations. Things that really end up mattering are things like availability of a programming environment for the development machine, availability of runtime environment(s) for the deployment machine(s), licensing/legal issues of the runtime and/or development environments, availability of trained developers, availability of consulting services, and corporate culture/politics. These business considerations generally play a much greater role than compile time performance, runtime performance, static vs. dynamic typing, static vs. dynamic binding, etc.

Anyone who argues in favor of one language over another in a purely technical manner (i.e., who ignores the dominant business issues) exposes themself as a techie weenie, and deserves not to be heard. Business issues dominate technical issues, and anyone who doesn't realize that is destined to make decisions that have terrible business consequenes — they are dangerous to their employer.