A Java to Mirah translator would be great! Currently there's a Mirah to Java compiler, for tools that must have Java source. But if it were possible to convert Java code directly to Mirah, it would definitely make migration faster.
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.
Mirah is statically-typed, like Scala or Java, so there's no late binding. That was an explicit goal in designing the language. The fact that after looking at examples you didn't realize Mirah's statically typed makes me smile, since it shows the syntax truly does cover up the typing.
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.
Re:Ruby/Python in JVM/CLR not a Silver Bullet
on
Ruby 1.9.1 Released
·
· Score: 1
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?
Re:Ruby/Python in JVM/CLR not a Silver Bullet
on
Ruby 1.9.1 Released
·
· Score: 1
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.
With two devs, perhaps not. But there's far more than two devs working on Jython, and they've made great progress this past year. Plus I'm going to do what I can to help them reuse work we've done on JRuby, so they can focus more on compatibility and Python features they're missing.
The reason Sun hiring Frank is important is because it provides a full-time developer to help anchor the OSS work that's already happening on Jython. And that's the right way to do things, since it's the community members that make projects like Jython work.
It's unfortunate that you won't be one of those community members, but it sounds like you've got what you need already. I hope you'll consider helping out if the JVM or Jython again become attractive options for you.
You're probably half right. I think it stems from a realization that Java doesn't have to be the only tool on the JVM. And to that end, we're working hard to improve the ecosystem for language development in a number of ways. Heck, some of the most interesting parts of JRuby aren't even written in Java anymore...they're generated programmatically. Java is just one way to create JVM bytecode. We need both better tools for creating bytecode for many languages, and a better way to make the JVM's dynamic underpinnings serve many languages. We're working on both.
Generics are basically no help at all to dynamic languages, so I think that's a red herring. And in fact, it makes implementing interop with dynamic languages much more difficult, since it's an additional class of types you have to be able to deal with and recognize. Ask the IronPython and IronRuby guys about the syntax they've had to come up with to support manipulating generics from within Python or Ruby.
The only problem the JVM has, as far as I can see, is that it's got this whole "Java" thing wrapped around it. The JVM itself is much better suited to all sorts of languages, if only we can punch a hole through the Java exterior. And that's exactly what we're going to do, by adding dynamic invocation support in (hopefully) JDK7 and a host of other features like tail calls, tuples, value objects, continuations, and so on in OpenJDK subprojects like the Multi-Language VM.
If anything, the CLR is a much more difficult platform to develop dynamic languages for due to its strict static-typed nature. You have to do some really unpleasant tricks to get the CLR to run a dynamic language fast, and that costs a lot of development time and hassle. DLR hopes to make some of that happen across all languages, but at the end of the day the CLR is just not as advanced a VM as the JVM.
At any rate, it's going to be an interesting couple of years.
It's difficult, but it's certainly not impossible. And we're working to make it easier by exposing the JVM's underpinnings. You see, the JVM is already a dynamic language VM; it just has this cumbersome static-typing wrapped around it.
JRuby itself uses only about as much memory as Ruby does for most apps we test. But we do pay a one-time cost for the JVM itself, which adds 25-30MB to the process. However on a server deploying Rails, this is insignificant compared to the memory eaten up by Ruby runtimes, and we're smaller there by most measurements.
Startup...yeah, it's an issue. But JRuby 1.1 will ship with Nailgun as part of the release, which enables you to run JRuby in a background persistent process and execute command-line scripts with startup times in the hundredths of a second range. Quite acceptable.
This is very useful. It's worth noting, also, that removing all "allowed" popup events doesn't completely kill your ability to use sites that need popups...it just causes Firefox to warn you that it has blocked something, allowing you to adjust settings for that site.
I'd gladly pay a buck or two per BSG episode. I already bought the miniseries DVD, and that's the best I can do to assist them without getting cable or satellite (which I will not do). There should be alternative ways to watch and support shows we want to continue seeing without forking over bigger bucks to cable and satellite providers for 50-500 channels I'll never watch.
If the information was so credible and so easily corroborated, there's no reason the Wiki entry needed to link to your personal site on Geocities. How do you answer a charge that this is simply grab for attention when instead of providing these supposedly corroborating sources you continue to battle to have the link to your personal site restored? I don't really see how you can. This is posturing, plain and simple.
Your logic suffers from a serious flaw: you say you know the information is authentic, and therefore you feel you're able vouch for its validity without providing third-party corroboration of any kind. That does not work; you can not vouch for yourself.
Of course, you'll come back with some clever way to justify this behavior, but I and others like me will not be fooled. If the information is authentic and credible, present alternative sources. Otherwise, you are just making noise.
Ruby does not run bytecode, at least not until the new VM is completed (sometime in 2005). I don't know about python.
Ruby is strictly interpreted in C Ruby. In Java Ruby we try to boil it down to an AST, but it's still strictly interpreted. It will be interesting to see how the Ruby folks come up with a more advanced VM; I'm sure we'll piggyback on their research.
Re:Why reimplement Ruby?
on
RAD with Ruby
·
· Score: 1
You hit the nail on the head. While a Java implementation like JRuby isn't able to implement the full set of POSIX methods provided by Ruby, it is able to provide an entirely different VM. While JRuby still needs work in plent of areas, it already provides things like JVM/native threads for Ruby threads, integration with standard Java code, and easy access to the full J2SE library set.
We've also started the process of (helping with) standardizing the "Rubicon" suite of unit tests that defined the Ruby "specification", as well as flushing out a couple inconsistencies in Ruby core. Competition is always good, especially when the two competitors aren't necessarily going to be used in the same domains!
JRuby and RDT
on
RAD with Ruby
·
· Score: 5, Informative
As long as we're dumping Ruby links, I must plug a project I work on and a project I work with daily:
JRuby is a 100% java implementation of Ruby 1.8. The most recent release is pretty old, but the version in CVS is shaping up nicely and is getting quite stable. I joined development over a month ago, and work has been rapidly ramping up.
The Ruby Development Tool aims to bring a full Ruby develop/test/debug environment to the Eclipse platform. It is also rapidly maturing, and may in the future use portions of JRuby for parsing and debugging. While using or developing JRuby, the RDT is a welcome companion, allowing me to stay within Eclipse when developing both Java and Ruby.
I would also recommend tracing back to previous Ruby posts on/. for more information and links.
Interesting that you mention Trails, since Rails is so named because it fills a similar gap as Java's Struts (Rails...Struts...get it?). Struts, naturally, is pretty godawful now, and shows its age. Rails took the good ideas from Struts, added a few of its own and a beautiful language, and there you have it. I hope Trails can do something similar (Groovy anyone?)
Posting my comment from the other "extinction" article here...
These judgement day scenarios are based on a big fallacy I haven't yet seen addressed:
The market for software developers is not standing still; it's growing tremendously. We're just not seeing it because a lot of new development is going overseas. However, there's no sign that the demand is going to slow down, and there's not an infinite number of tech workers overseas.
Already Indian workers are concerned about having their own tech bubble, as other countries start coming online with cheaper workers. China, Phillipines, and others are starting to take work away from India.
Further, despite claims to the contrary, it's not just as easy to move programming jobs overseas as it is for manufacturing jobs. Indian programmers aren't just plucked from the trees...they've gone through years of training and education just like we have. It costs a lot more time and money to train a programmer than to train an assembly-line worker. Again, there are not infinite resources available. It just seems that way because India has been building up a highly-trained workforce for a long time--without work to give them.
Our own tech boom and bust resulted in scads of untrained, unskilled workers getting paid too much to do too little. Reality check: there's no such thing as an HTML programmer. Writing VB is not going to earn you $50/hr. If you don't like what you're doing, you're not in the right line of work. The lion's share of jobs lost to offshoring are jobs that were filled by wannabes during the.com years. I personally know at least 5 administrators and programmers that refused to ever accept a lower-paying job when things went bad. They lost their cars, their houses, and their dignity as a result, and all for a job none of them liked doing in the first place.
Finally, as other posts have noted, the cost of paying a programmer is not the largest portion of developing software. Gathering requirements, testing, working with customers and clients, managing change, administering systems; all enter into it and have similar contributions to the overall cost. In the case of offshoring, almost all of these become more expensive...in some cases much more expensive.
Slashdot Mirror
A Java to Mirah translator would be great! Currently there's a Mirah to Java compiler, for tools that must have Java source. But if it were possible to convert Java code directly to Mirah, it would definitely make migration faster.
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.
Mirah is statically-typed, like Scala or Java, so there's no late binding. That was an explicit goal in designing the language. The fact that after looking at examples you didn't realize Mirah's statically typed makes me smile, since it shows the syntax truly does cover up the typing.
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.
JRuby already does compile Ruby to JVM bytecode. Mirah is an entirely separate language that's statically typed, but borrows some syntax from Ruby.
This would almost be funny, except that it's not forks, it's chopsticks...and you can eat perfectly well with ONE FUCKING FORK.
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.
With two devs, perhaps not. But there's far more than two devs working on Jython, and they've made great progress this past year. Plus I'm going to do what I can to help them reuse work we've done on JRuby, so they can focus more on compatibility and Python features they're missing.
The reason Sun hiring Frank is important is because it provides a full-time developer to help anchor the OSS work that's already happening on Jython. And that's the right way to do things, since it's the community members that make projects like Jython work.
It's unfortunate that you won't be one of those community members, but it sounds like you've got what you need already. I hope you'll consider helping out if the JVM or Jython again become attractive options for you.
You're probably half right. I think it stems from a realization that Java doesn't have to be the only tool on the JVM. And to that end, we're working hard to improve the ecosystem for language development in a number of ways. Heck, some of the most interesting parts of JRuby aren't even written in Java anymore...they're generated programmatically. Java is just one way to create JVM bytecode. We need both better tools for creating bytecode for many languages, and a better way to make the JVM's dynamic underpinnings serve many languages. We're working on both.
Generics are basically no help at all to dynamic languages, so I think that's a red herring. And in fact, it makes implementing interop with dynamic languages much more difficult, since it's an additional class of types you have to be able to deal with and recognize. Ask the IronPython and IronRuby guys about the syntax they've had to come up with to support manipulating generics from within Python or Ruby.
The only problem the JVM has, as far as I can see, is that it's got this whole "Java" thing wrapped around it. The JVM itself is much better suited to all sorts of languages, if only we can punch a hole through the Java exterior. And that's exactly what we're going to do, by adding dynamic invocation support in (hopefully) JDK7 and a host of other features like tail calls, tuples, value objects, continuations, and so on in OpenJDK subprojects like the Multi-Language VM.
If anything, the CLR is a much more difficult platform to develop dynamic languages for due to its strict static-typed nature. You have to do some really unpleasant tricks to get the CLR to run a dynamic language fast, and that costs a lot of development time and hassle. DLR hopes to make some of that happen across all languages, but at the end of the day the CLR is just not as advanced a VM as the JVM.
At any rate, it's going to be an interesting couple of years.
It's difficult, but it's certainly not impossible. And we're working to make it easier by exposing the JVM's underpinnings. You see, the JVM is already a dynamic language VM; it just has this cumbersome static-typing wrapped around it.
JRuby itself uses only about as much memory as Ruby does for most apps we test. But we do pay a one-time cost for the JVM itself, which adds 25-30MB to the process. However on a server deploying Rails, this is insignificant compared to the memory eaten up by Ruby runtimes, and we're smaller there by most measurements.
Startup...yeah, it's an issue. But JRuby 1.1 will ship with Nailgun as part of the release, which enables you to run JRuby in a background persistent process and execute command-line scripts with startup times in the hundredths of a second range. Quite acceptable.
Young punks.
This is very useful. It's worth noting, also, that removing all "allowed" popup events doesn't completely kill your ability to use sites that need popups...it just causes Firefox to warn you that it has blocked something, allowing you to adjust settings for that site.
Seems to have fixed all those new popups for me.
I'd gladly pay a buck or two per BSG episode. I already bought the miniseries DVD, and that's the best I can do to assist them without getting cable or satellite (which I will not do). There should be alternative ways to watch and support shows we want to continue seeing without forking over bigger bucks to cable and satellite providers for 50-500 channels I'll never watch.
Are you actually saying you'd prefer buying a PC over the Mac mini?
As a long-time PC user who's wanted an OS X Mac for simply years, I must ask: Why?
If the information was so credible and so easily corroborated, there's no reason the Wiki entry needed to link to your personal site on Geocities. How do you answer a charge that this is simply grab for attention when instead of providing these supposedly corroborating sources you continue to battle to have the link to your personal site restored? I don't really see how you can. This is posturing, plain and simple.
Your logic suffers from a serious flaw: you say you know the information is authentic, and therefore you feel you're able vouch for its validity without providing third-party corroboration of any kind. That does not work; you can not vouch for yourself.
Of course, you'll come back with some clever way to justify this behavior, but I and others like me will not be fooled. If the information is authentic and credible, present alternative sources. Otherwise, you are just making noise.
Ruby does not run bytecode, at least not until the new VM is completed (sometime in 2005). I don't know about python.
Ruby is strictly interpreted in C Ruby. In Java Ruby we try to boil it down to an AST, but it's still strictly interpreted. It will be interesting to see how the Ruby folks come up with a more advanced VM; I'm sure we'll piggyback on their research.
You hit the nail on the head. While a Java implementation like JRuby isn't able to implement the full set of POSIX methods provided by Ruby, it is able to provide an entirely different VM. While JRuby still needs work in plent of areas, it already provides things like JVM/native threads for Ruby threads, integration with standard Java code, and easy access to the full J2SE library set.
We've also started the process of (helping with) standardizing the "Rubicon" suite of unit tests that defined the Ruby "specification", as well as flushing out a couple inconsistencies in Ruby core. Competition is always good, especially when the two competitors aren't necessarily going to be used in the same domains!
The Rubicon tests are on rubyforge
As long as we're dumping Ruby links, I must plug a project I work on and a project I work with daily:
/. for more information and links.
JRuby is a 100% java implementation of Ruby 1.8. The most recent release is pretty old, but the version in CVS is shaping up nicely and is getting quite stable. I joined development over a month ago, and work has been rapidly ramping up.
The Ruby Development Tool aims to bring a full Ruby develop/test/debug environment to the Eclipse platform. It is also rapidly maturing, and may in the future use portions of JRuby for parsing and debugging. While using or developing JRuby, the RDT is a welcome companion, allowing me to stay within Eclipse when developing both Java and Ruby.
I would also recommend tracing back to previous Ruby posts on
Interesting that you mention Trails, since Rails is so named because it fills a similar gap as Java's Struts (Rails...Struts...get it?). Struts, naturally, is pretty godawful now, and shows its age. Rails took the good ideas from Struts, added a few of its own and a beautiful language, and there you have it. I hope Trails can do something similar (Groovy anyone?)
Ewen McGreggor is an actor.
Posting my comment from the other "extinction" article here...
.com years. I personally know at least 5 administrators and programmers that refused to ever accept a lower-paying job when things went bad. They lost their cars, their houses, and their dignity as a result, and all for a job none of them liked doing in the first place.
These judgement day scenarios are based on a big fallacy I haven't yet seen addressed:
The market for software developers is not standing still; it's growing tremendously. We're just not seeing it because a lot of new development is going overseas. However, there's no sign that the demand is going to slow down, and there's not an infinite number of tech workers overseas.
Already Indian workers are concerned about having their own tech bubble, as other countries start coming online with cheaper workers. China, Phillipines, and others are starting to take work away from India.
Further, despite claims to the contrary, it's not just as easy to move programming jobs overseas as it is for manufacturing jobs. Indian programmers aren't just plucked from the trees...they've gone through years of training and education just like we have. It costs a lot more time and money to train a programmer than to train an assembly-line worker. Again, there are not infinite resources available. It just seems that way because India has been building up a highly-trained workforce for a long time--without work to give them.
Our own tech boom and bust resulted in scads of untrained, unskilled workers getting paid too much to do too little. Reality check: there's no such thing as an HTML programmer. Writing VB is not going to earn you $50/hr. If you don't like what you're doing, you're not in the right line of work. The lion's share of jobs lost to offshoring are jobs that were filled by wannabes during the
Finally, as other posts have noted, the cost of paying a programmer is not the largest portion of developing software. Gathering requirements, testing, working with customers and clients, managing change, administering systems; all enter into it and have similar contributions to the overall cost. In the case of offshoring, almost all of these become more expensive...in some cases much more expensive.