Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror

Comment: Re:Why Mirah instead of Scala, Clojure, Groovy, JR (Score 1) 444

by Headius (#35556948) Attached to: Mirah Tries To Make Java Fun With Ruby Syntax

I am definitely looking for help with the project. Currently, the codebase is a bit tough to follow, so I'm mostly trying to refactor and clean it up. If you want to start digging in, getting familiar with the codebase and helping fill out the wiki (on github) would be excellent :)

And make no mistake about the relationship with Ruby; it's purely syntactic. The APIs and class libraries are that of the Java platform. Only Ruby's syntax and some superficial language features are from Ruby.

Comment: Re:Why Mirah instead of Scala, Clojure, Groovy, JR (Score 4, Informative) 444

by Headius (#35555562) Attached to: Mirah Tries To Make Java Fun With Ruby Syntax

The original goal of Mirah was to create a language that looked nice, compiled down to a form as direct and fast as Java, and did not require you to drag a runtime library along with you. You take Mirah code in and get JVM bytecode (in .class files) out. There's no extra dependencies; you're not shackled to an extra jar file just because you wrote "hello world".

Mirah has much of Ruby's syntax only because we liked Ruby's syntax. The Ruby class libraries are not there, and Mirah is not Ruby. It's statically typed, with Ruby's clean syntax and some of Ruby's surface-level features (like simple iteration and closures).

I guess you're right, we need to do a better job explaining why it's useful. I have an article coming that emphasizes that this is simply a "javac" alternative that happens to have Ruby syntax, and hope to clean up the web site too.

Comment: Re:Ruby/Python in JVM/CLR not a Silver Bullet (Score 1) 226

by Headius (#26694077) Attached to: Ruby 1.9.1 Released

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?

Comment: Re:Ruby/Python in JVM/CLR not a Silver Bullet (Score 1) 226

by Headius (#26691403) Attached to: Ruby 1.9.1 Released

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.

"Bureaucracy is the enemy of innovation." -- Mark Shepherd, former President and CEO of Texas Instruments

Working...