Comment Re:Best luck to JRuby team (Score 1) 77
Thanks Jim
Thanks Jim
The Jython team has done only preliminary work on performance, and stands to gain a lot more over the coming months. They've recently undergone a rewrite of much of their code and are now stabilizing back toward a 2.5-compatible release. Performance work will probably come after that. And if they apply the same techniques we're using in JRuby, they'll probably do well.
If you have benchmarks showing V8/TM/SFE perform within an order of magnitude of C on something general-purpose (not a bloody fib benchmark) I'd love to see them as well. I have not seen such numbers in my searching.
I agree that V8/TM/SFE are great JavaScript implementations, but they're largely *just* that, JavaScript implementations. JS is a vastly simpler language than either Python or Ruby, and the performance characteristics will reflect that. In short, JS simply does less "magic" for you behind the scenes. That magic is frequently what makes Ruby and Python harder to optimize, but it's also what makes them more attractive as general purpose languages. So it's a matter of what you can get done with what code; if JS is 10x faster than Python but you have to write 10x as much code to get the same things done, where does that put you?
There's a fundamental difference here: those of us targeting existing VMs have a lot less work to do to go as fast as the C/C++ impls...and then faster. In JRuby, the basic, dumb implementation of Ruby performs around as well as the C impl. In some cases it's faster, and in some cases it's slower. But when we actually start implementing it *well* we get substantially improved performance. And even better, we can make improvements in days that take the C/C++ impls months or years to do, simply by continuing to structure JRuby in such a way that the amazing JVMs out there can optimize it well.
V8 and Tracemonkey do a lot to optimize JavaScript, but there's an important detail missing in almost all benchmarks of them: they make JavaScript less slow, but do not in any way bring it to the performance level of Java.
JVMs like Hotspot are the best hope for fast dynamic languages in the near future.
>>Being bitter is drinking poison and hoping someone else will die
>I like that. Is it original?
Unfortunately not. Friend had it in his mail signature, he saw it (or something like it) somewhere on the net, couldn't remember where.
So in other words... if you want something decent and fast, use Java???
Pretty much, yes. Welcome to the 21st century.
JRuby is an interpreter, written in Java. It does not compile Ruby to Java bytecode.
Incorrect. I certainly DOES compile Ruby to Java bytecode. Read the blogs of Charles Nutter, John Rose and Ola Bini for more information.
I agree. I actually defended Spore here on Slashdot when it was the Great DRM Debate, I thought it was fun. But I got really fed up with it surprisingly quick. Designing creatures remained fun, but the core gameplay was just too...shallow.
I think it really deserved the "most overhyped game" awards it won.
I mean, you get 4 programs on your harddrive for the price of one -
1) SecureROM
2) Games for Windows LIVE
3) Rockstar Social Club
4) An early Beta version of some game
Sounds like a great deal to me.
If anything Perl is just being relegated to what it's _really_ good at, and that's UNIX automation tasks and quick throw-away scripts, and _sometimes_ smallish applications. There's really no better language for these types of things.
I actually prefer Ruby for that sort of stuff, but maybe that's just me.
He's announcing it way too early. He has practically nothing to show. There's only one tiny code example that I can see to gauge its merits.
When he announced it on his blog a couple of months ago it he said it was in progress. He is still experimenting with the syntax and semantics of the language, so I think it is currently mostly interesting for those who want to discuss ideas and experiment themselves.
Ioke is cute, but there's just no really good reason for such a strange syntax
I'm not sure Ioke is the language for me, but I think it is interesting that he is experimenting with syntax and trying out new things. He has blogged about his reasons for using space as the method operator, and the consequences.
People who come up with "l33t" ideas like this need to be put on maintenance programming of code written by others for six months or so.
I've worked with Ola. Trust me, he's done plenty of maintenance programming over the years.
Crichton's point is it doesn't matter how many people *think* he's is wrong about climate change, it only takes one person to *prove* him wrong. Science isn't consensus, and nothing has been proven.
Yet when deciding what to do about potential problems, we have to take consensus into account....exactly for the reasons you state - that we can't know things with absolute certainty.
Now that the Republicans are out of the White House, expect the climate change crisis to conveniently fade away from the public consciousness.
US centric much? This is a global problem, discussed all over the world.
A HACK? Your opinion is wrong. Crichton was thought-provoking and insightful, and he was a gifted story-teller
No, the GP had it right. He was a hack, wrote thinly disguised straight-to-Hollywood scripts, and will soon be forgotten, your fanboy hissyfit nonwithstanding.
"Been through Hell? Whaddya bring back for me?" -- A. Brilliant