With Python, there is no real pain that alternative implementations can address. The canonical implementation is good enough, and it will remain a monopoly.
With Ruby, providing significantly better performance and reliability may very well unseat the monopoly of MRI, certainly for commercial applications. Since, JRuby actually looks like it may be able to pull that off in the foreseeable future, it's a much bigger deal than alternative Python implementations.
No, no, no and no. I've been able to work just fine with C/C++ libraries. I would use Jython only when trying to extend an existing Java application or when trying to sneak Python into a primarily Java corporate environment.
You will find that a lot of stuff in Java is done only because it has to be (elaborate J2EE app servers being an excellent example). If you just need to grab some records from a database and format them, you don't need all that scaffolding.
I have recently heard people saying Python is too slow and Java is preferred for some thing. Since I'm a bit of a newbie in the python world I'm not sure what to suggest.
The main thing that Python users complain about in CPython is the global interpreter lock, which restricts all the threads in a Python process to one CPU. (Ruby has this too.) So concurrency over multiple CPUs has steadily become more of a concern over the years.
Stackless came up with a solution, but Guido shot it down, and it appears be surviving somewhat in parallel. (No pun intended.) Jython gets rid of the GIL and uses native threads like Java, and is scheduled to come out of its half-decade coma sometime this year. The mainline CPython implementors insist that getting rid of the GIL would cause infinite headache, but they're offering a reasonable substitute in Python 2.6: the multiprocessing module, which has a thread-like API but uses separate OS processes behind the scenes. So, I don't think there will be a mutiny over this.
I watch the python-ideas mailing list and there has been some talk recently of bringing some of the micro-threading ideas from Twisted into the CPython implementation itself. I don't have much knowledge of micro-threads or Twisted so I haven't been following the conversation very closely, but at least that's another data point in the state of parallelism in Python.
Kudos for all the hard work he's put into JRuby. He's very passionate and has obviously put in a tremendous amount of effort into this project. Definitely the spirit of a true hacker!
I avoid JRuby just because I'm never very confident on a non-standard platform. I'm not a bleeding-edger, especially with things that I don't like debugging the hell out of.
Just like I don't swap out OS libraries for fun, I don't replace the underlying bedrock of a language for a giggle either. If I had a compelling reason to use JRuby (for example, to get access to all the great Java code that's been written), then it would be more compelling. Until then...if it ain't broke...
FTFA: "Some of them have been Rubyists longer than anything else (or maybe just longer than anyone else), and see themselves as the purists, the elite, the Ivory Tower, keepers of all that's good in the Ruby world and judge, jury, and executioner for all that's bad. In the end, however, there's one thing these folks share in common.
They think JRuby is a terrible idea."
I've been a Rubyist for about 8 years; I love JRuby!
And Headius rules. (As does Tom and the rest of the JRuby team. #jruby on freenode rocks.)
Agreed. Writing such a wrapper also introduces the possibility of someone later implementing the same library for Ruby itself. As long as the wrapper's interface makes sense and the library is worthwhile, there is no compelling reason that the Java bits underneath couldn't be replaced by a C library and some glue code.
Python is intentionally simple to parse. The whitespace thing (if that's what you're referring to) goes like this: if a line is indented one more level than the previous line, that span of indentation becomes an <indent> token, applied for the rest of the indented block. So to figure out scope level for a given line, look at the number of leading <indent> tokens. That's it. Google knows more.
If I've said it once I've said it a thousand times: Python cares about indentation not whitespace. You can format your code any way you please, but it turns out that arguments about where to place curly braces don't actually contribute to getting real work done, and Python people don't miss them.
Java, Ruby, and everything else are all the same at some level. They let you type in instructions for the computer to execute. A VM is an execution strategy. Why does the front-end to that strategy make a difference to you? (Or rather, why do certain front-ends make you feel "dirty"? I think it's because you have no idea what you're talking about.)
I think the OP is trying to say that all dynamically typed, interpreted languages are implemented in statically typed, compiled or JIT languages. If you like the discipline of the latter, you might resent the former.
Hasn't Java had a JIT compiling VM for a while now? And in the times I've used it, it has certainly seemed statically typed and compiled (to Java bytecode) to me.
With Ruby, providing significantly better performance and reliability may very well unseat the monopoly of MRI, certainly for commercial applications. Since, JRuby actually looks like it may be able to pull that off in the foreseeable future, it's a much bigger deal than alternative Python implementations.