6 ms·
I read an article on slashdot about eight years ago (antitrust trial era after the first major ruling against) that Microsoft was dead. This reminds me of that.
by cturner 18y ago
I read an article on slashdot about eight years ago (antitrust trial era after the first major ruling against) that Microsoft was dead. This reminds me of that. I'd like to believe but this guy make a poor case.
Java is everywhere, and the VM is high performance. Its library range is the best, except for C in some settings. The operating system wars are long over and the language ones are becoming irrelevant - it's about VMs now and JVM is a strong contender. One of the links off here: http://www.malhar.net/sriram/kilim/ http://www.malhar.net/sriram/kilim/ show it nuking erlang under high loads for similar concurency patterns.
I wish it were dead. I've moved myself out of the core development team at work in order to avoid dealing with the frustrating lethargy of developing with it. What development I now do is tooling which I do entirely in python, using django, web2py and base libraries when I need web stuff. Python allows me to prorgam with all the power of the unix platform even though my C is weak and unpracticed.
But Java still has outright strengths. When support issues come up for the main product our java source code is very readable, the team thrives in spite of being distributed, the product is stable, those customers who need library compatibility with us can get it with Java. Some of the python libraries are in the lead across the board, but others are weak. Nothing in the python world comes close to cayanne for combining simplicity and power for object relational modeling (most of the offerings are less powerful and more difficult to install, sqlalchemy is extremely inaccessible).
I'm expecting the classy rollout of Python 3 to kill off the other mainstream scripting languages. But it still has large flaws. Twisted is magnificent, but if you need to do threading python stinks even more than standard java. Also, the 'self' problem and syntactic separations that prevent you from creating functions inline point to a weaknses in the settlement. I think iolanguage is the next step in the right direction. There are some areas I don't think even that could challenge Java though - java wins when you have teams working on a project.
- ConradHex 18y agoI read this as "Java is dead" in the sense that it isn't evolving any more in any useful way.
- thomasmallen 18y agoThat's why volcanologists make the distinction between "dormant" and "extinct."
- silentbicycle 18y ago"Java has gone stagnant" makes for a much less punchy headline.
- axod 18y agoHow does it need to evolve? Unlike a lot of languages, they got some things right from the start - Unicode for example.
- jmtulloss 18y agoThat'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.
- michaelneale 18y agoI 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.
- dazzawazza 18y agore 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
- cturner 18y agoI'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.
- dazzawazza 18y agothanks, I agree with you on all your points. I just assumed all ORMs were like that :)
- jmtulloss 18y agoI 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.
- mechanical_fish 18y agoYou 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.)
- deleted 18y ago[deleted]
- davidw 18y agoThe 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.