You misunderstand the technical meaning of the jargon term dead. In a discussion like this one dead means in stasis.

It certainly does not mean "dead" as in "not being used". Such a term -- let's call it "the True Death" -- would be nigh-useless in a discussion of computer languages, because very few successful languages reach that state. The code doesn't rot. COBOL lives. FORTRAN most definitely lives. Lisp is older than everything and it is very much alive. Pascal might be an exception: You really never hear of anyone writing new Pascal code. Perhaps it is approaching the True Death. Or perhaps some of the more obscure assembly languages of decades past are Truly Dead. But I wouldn't be surprised if they weren't. There are people writing Atari 2600 assembly language right now. Maybe even more than there were in 1982.

The discussion is complicated by the evolution of languages and the desire to rehabilitate old trademarks. Applesoft BASIC is far closer to the True Death than "Basic" is, because Microsoft stole the name and applied it to a rather different creature. "Lisp" cannot die, but you could point to one of the thousand dead dialects of Lisp and call that dialect a "Truly Dead language". Eventually you get trapped in a pointless semantic debate, like the one you flirt with here: If the JVM is alive but Java is dead, is Java alive?

At any rate, now that we've established what we mean: Yeah, Java is arguably "dead". It has reached an equilibrium where anything you might do to change the design creates more problems than it solves: It breaks back compatibility, or it creates an impenetrably complex monster that only a relatively small number of people can understand. It's also very easy to argue that Microsoft Windows "died" around the release of Windows XP: Since then, the company has devoted uncounted thousands of programmer-hours to create an OS that much of the market has concluded is no improvement over XP. That's what static equilibrium looks like.

But this doesn't mean that we won't have Java and Windows to complain about for years and years, if not decades and decades. In software the dead do not truly die. They just stalk the earth as vampires. (I originally wanted to say "zombies", but that's wrong. Zombies are slow and stupid. Undead languages, on the other hand, are often amazingly competent and smart despite being technically dead. They've got a lot of experience.)

The two variables are:

* Current usage - how much of it is deployed.

* Growth - how much it's being used for new projects, worked on, written about, etc...

For instance, Cobol is still fairly widely deployed in some environments, but growth is probably negative, as it's being replaced by Java. Java is very widely used, and is still probably growing, although probably not as much as things like Ruby, which have grown a lot; which is easy when you start from a small base.

I am going to be interviewing at a job where there are New Smalltalk Projects

If dead = in stasis, then computer languages are like popular comic book characters. They may die, but someone will eventually bring them back.

Actually, from a friend who actually specializes in COBOL: the number of lines of COBOL in production use are actually increasing due to regular maintainance.

  <pedantism>

12% of that sentence was the word "actually." In all but the shortest sentences, it's strange to see an adverb as the most common word.

Edit: Thought about this more, and some people almost certainly say "like" more than any other word. (Un)surprisingly, your sentence loses little meaning if the actuallies are replaced with likes, commas optional.

  </pedantism>

s/pedantism/pedantry/

It's a word, just an obsolete one: http://dictionary.reference.com/browse/pedantism

Pascal is not an exception. Do you know what language Skype is written in?

No... Is it Pascal? Because that would be pretty weird. I always assumed it was C++.

At least Windows GUI is written in Delphi, that is Object Pascal.

Edit: also, there are many new Delphi/Pascal projects, just check out http://www.lazarus.freepascal.org/ the "True Death" is highly exaggerated.

I read this as "Java is dead" in the sense that it isn't evolving any more in any useful way.

That's why volcanologists make the distinction between "dormant" and "extinct."

"Java has gone stagnant" makes for a much less punchy headline.

How does it need to evolve? Unlike a lot of languages, they got some things right from the start - Unicode for example.

That's what this article was talking about, and the article the author wrote a few years ago (linked in this article) give even more reasons.

I think the article makes sense. But I don't see why inner classes would have to go in the face of closures - they are simply a nested version of a existing structure - not really a new structure.

re SQLAlchemy: How is it inaccessible? Are you referring to the docs which even after a year of using I find frustrating? What does SQLAlchemy it lack compared to Cayanne?

I'm not trolling. I've only used raw SQL and SQLAlchemy so I'm basically orm blind atm. I'd like to know what I'm missing :) tia

I'm confident that SQLAlchemy has the potential to be the best database abstraction layer out there. However, I found the docs impervious and frustrating. Some of the examples are given in a way that's quite unhelpful - they could be constructed to distinguish the way it works from other assumptions you could make and generally they're not. When things break, the error messages are unhelpful.

I eventually got to the stage where I had a product built on top of it, working, but I still didn't feel like I knew the framework fluently. I've never been in that position before. Frustating, because it means if I do more work on that codebase I'll either have to struggle through again or else throw it away and write on top of something else.

ORM is supposed to be good for nailing the right schema and then abstracting it away without a performance hit. That's what I get with Cayenne. I found the opposite with sqlalchemy - it's more difficult than it would have been for me to have just written the queries inline, or rolled my own simple ORM. I think it's because it's just too thick - unusual for a python framework - usually they're the opposite.

It's been a year since I looked at it so I'm a bit vague above, but I gave it a go for over two years on and off.

I am also confident that SQLAlchemy is the best ORM out there (though I'd like to try LINQ). The documentation has been improving rapidly, you should give the .5 branch a try.

I agree that it needs to be improved, but that's largely because the product is so powerful and complex, writing sufficient documentation is a herculean effort in and of itself.

thanks, I agree with you on all your points. I just assumed all ORMs were like that :)

"SQLAlchemy: How is it inaccessible? Are you referring to the docs which even after a year of using I find frustrating? "

If you have significant experience with Hibernate, you can pick up SQLAlchemy very fast. One of my friends wanted to switch from Django ORM to SQLAlchemy but was being frustrated by lack of SA documents. I had him build a couple of throwaway systems (just domain model and databse - no web framework gymnastics - which are very painful in Java) with Hibernate and also read through Martin Fowler's "Enterprise Patterns" book to pick up some of the terminology (e.g:- Unit Of Work). This seemed to work. Just throwing it out there, fwiw.