Java and coolness, a discussion

Jack Shirazi posted this somewhat amusing discussion.

"I guess we just move in very different circles.". Bingo... the people you know and trust think Java is 'cool,' whereas the people I know and trust think its 'uncool.' Therefore, I see people leaving in droves, whereas you see people coming. So the question boils down to, which group is more reliable in making that judgement? Probably neither... but I'm still going to rant a bit more.

I guess this is related to Graham's Hackers meme. It was almost impossible to argue against Java a couple of years ago, now it is 'officially' uncool...

Which goes to show you that language coolness is much more about community and buzzwords than it is about real language features, right?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

"Acedemic"

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?

I wonder..

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

7,000 classes commonplace in Java projects?!

The article states
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).

Is OOP the reason?

Most of the programs I've seen written in COBOL don't need to be maintained; they were written to run forever.

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

Cobol 97 (aka OO Cobol)

Maybe these paragons were written in OO Cobol ;-)

Do you mean COBOL++

aka ADD 1 TO COBOL

Re: 7,000 classes commonplace in Java projects?!

"Most of the programs I've seen written in COBOL don't need to be maintained;"

The number of applications of software which can be written once and never maintained is (roughly) the class of problems that never change. This class is small. Almost nothing that software can currently do remains exactly the same over time. The degree of this time-variability is roughly proportional to the 'applied-ness' of the application (along with well-designed-ness of the implementation).

Justification: the practical problems people face are changing and more and more rapidly (this includes the problems that people use software to solve).

Comments?

It's all economics

In my experience, the class of problems that never change is actually quite large. A lot of programs are written, pressed into service, and then never looked at again. They just go on working until the hardware burns out and replacement parts are no longer available.

It's one of those perverse economics things. As long as the cost of change remains high, there's a strong disincentive to not change things. So management writes off a change as impossible, and the program keeps on working.

Ironically, this means that the less maintainable a program is, the less it will need to be maintained. If you create a write-only COBOL or Perl program, then management will never ever want to touch it once it works. The reason COBOL doesn't need to be maintained is that it can't be; the reason OO languages and good design lead to higher maintenance costs is that suddenly improvement projects that weren't feasible before now are.

If it weren't for competition, we'd never need to maintain any code. Unfortunately, some competitor is bound to rewrite the legacy code so it works better, and so we get maintenance headaches. This is also why there's a big tendency to rewrite code from scratch; the longer a program goes unmaintained, the more expensive it'll be to update, while the cost of a complete rewrite remains constant or even drops with improved technology.

7000 really IS commonplace

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. Classes and interfaces are the coin of the language. It's like getting used to Lisp applications - they are filled with 5-line functions. I have some undergraduate students (!) working on a project that's now about 500 classes and climbing. We have a lot of small but very useful classes and interfaces that make it possible to craft a lot of behavior. By the time we're done, it might get close to 7000 classes - or at least in the same order of magnitude.

Java no longer cool - I agree. So what. But it's very useful for building big systems. And even useful to get students to deal with some interesting concepts they can use later. Another COBOL - I hope so. Not many languages have lasted a fraction of the time FORTRAN or COBOL have been around.

Now if someone would please come up with a JVM that can do real tail-call optimization...

a couple years ago

"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?

New COBOL programms

Well, those five billion new lines of COBOL have to end up somewhere, don't they?

Predictable and sound

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.

Software Maintenance and Language Choice

First off, I apologize for conflating change with progress. IOW I should have omitted the statement "Is that progress?" and replace it with "Aaaargh!" or "Yikes" or some such.

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?

Big and lumbering or small and nimble?

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?

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.

If the system is well-designed and refactored, you should be able to understand a unit of behaviour without digging all the way down, and each class should be small enough to easily digested with a brief inspection.

Personally I'm much more concerned when I find a large system with a few do_everything procedures that are hundreds of lines long. (And very difficult to figure out.)

yet more classes (and night frights)

I apologize to xeo for piling on the depression, but a lot of enterprise products are that big and bigger. To manage these systems you DO have to have some sort of serious IDE that manages the classes. Also, in the case of J2EE projects, there is a sort of meta-language defined by the J2EE standard. Programmers create the meat of the application and the IDE does all of the wrapping and bell-festooning needed to make it work. And as our other commenter points out (sorry, I'm off the page where I can see the name), you don't have to know the 7000 classes to start working. If you did, it would be a pretty sad architecture (like Windoz). Even with my students, they only really get to know parts of the product and that's only about 500 classes.

I suppose the real depressing point is that the world these applications work in really IS that complicated. On the other hand, there's some level of job security in that...

Oh, just to help you Halloween dreams, for about half of all those billions of lines of COBOL running each night, the source code is missing...

Missing COBOL source code?

Jerry Boetje says:
about half of all those billions of lines of COBOL running each night, the source code is missing...

No need to worry: COBOL may have more decompilers written for it than any other language. In fact the abundance of decompilers serves as a reminder to developers who might otherwise believe that compilation protects their code from prying eyes.

And perhaps decompilers and decompilation are more appropriate topics for LtU than users' choices of development language?

Decompiling n-stage metaprograms

And perhaps decompilers and decompilation are more appropriate topics for LtU than users' choices of development language?

Yes, and to make it more challenging I propose to discuss decompilation of n-stage (meta)programs ;-)

In addition to the complexity of many classes...

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

The C++ FAQ's take

The C++ FAQ has an interesting take on language choice, supporting the view that technical matters are insignificant:

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

I suppose that's true, but as I have no problem with being labeled as a techie weenie, I don't much care :)

"A purely technical manner"

It's probably true that arguing in favour of one language over another in a purely technical manner is a mistake, as there are indeed other issues involved. But I don't agree with this separation of "business issues" and "technical issues": technical issues are also business issues, inasmuch as bad technical decisions can be harmful to business. To say that "business issues dominate technical issues" is to say that business issues of a non-technical nature should dominate business issues of a technical nature; and that's actually a recipe for making consistently bad business decisions.

In any case, it's just a long-winded way of saying "shut up and go away" to anyone who's unhappy with C++ (or Java, or whatever) from a technical perspective. It sounds to me like a way of avoiding accountability for the business implications of inept technical decisions. Whatever your PHB eventually gets fired for, it won't be for choosing C++ - even if it should be.

As a person who's been on the other side of this rule...

Ok, I've had answer 6.4 shoved in my face at my business.
... oops. rest of comment censored since I'm using my real name and my current employer...