One nice thing about ruby is that it has quite a few viable implementations floating around. MRI or YARV are probably what you have installed on your computer by default, but if multithreading and sane garbage collection are concerns of yours, JRuby is the right implementation to target. I'm not sure what's wrong with ruby's variable scoping, but I haven't used it for a while, so my memory of the ugly details of the language is a bit dim :)
"One nice thing about ruby is that it has quite a few viable implementations floating around."
That's not nice all in my opinion.
I don't want "choice" concerning what implementation of my language to use. Unless I have some strange, specialized need, I want one implementation that is guaranteed to work. I mean, the point of a garbage collected language is ... I don't have to worry about the garbage. If I have to make special study to find which implementation has " sane garbage collection", then this purpose been lost.
The various versions are forks and for forking to work, the winner needs to be picked really quickly to allow us to move on.
The thing about C++ is GCC is good enough almost everywhere and any other implementation is going to have to be as good as that.
There are good things about Ruby but dueling implementation breeding uncertainty is not one of them.
We definitely have different points of view then. I see single-implementation languages as things to fear. Software projects die, sometimes suddenly. The genius in charge might get hit by a bus, a particular implementation might violate the wrong company's patents, or the owner of an implementation might see an opportunity for profit. When you have options for language implementations, these risks are at least mitigated.
Unless I have some strange, specialized need, I want one implementation that is guaranteed to work.
I'd love guarantees of perfection too, but I've never seen one. I'm guessing that if I ever did see a guarantee of perfection, I wouldn't be able afford the software it was attached to. Software Engineering, like every other field of engineering, is about tradeoffs. Sometimes they're difficult tradeoffs, but it's your job as a professional to inform yourself and make the best decision you can.
I mean, the point of a garbage collected language is ... I don't have to worry about the garbage. If I have to make special study to find which implementation has " sane garbage collection", then this purpose been lost.
The point of garbage collection is that it allows you to focus on other things first, and then come back and look at your memory use. Even in a language running on a really advanced GC, like the Oracle JVM, you can't ignore your garbage. You need to close files when you're done with them or you will run out of file handles unnecessarily. You need to keep track of your heap use or your program will thrash and your GC will have problems. There's no silver bullet, but being informed about the details of your platform will help you.
The various versions are forks and for forking to work, the winner needs to be picked really quickly to allow us to move on.
Forks are based on common code. We're talking about separate implementations, with different teams and different goals. Nobody working on YARV cares whether ruby interacts well with java libraries. JRuby developers do care. Different teams, different focus. I don't think a winner is going to pop out, and I don't see why one is needed. I do think a better GC for non-JVM ruby would be really good, and somebody probably will make a compliant ruby implementation that has one, but that won't hurt anything. If it's an overall better implementation people will move to it, and YARV will probably go into the background.
The thing about C++ is GCC is good enough almost everywhere and any other implementation is going to have to be as good as that.
The thing about C++ is that it's a standard, not a piece of software. There are dozens of active implementations focusing on the embedded space, windows, solaris, and other platforms. No one implementation is the best for all purposes, and a professional chooses the correct tool for the job.
There are good things about Ruby but dueling implementation breeding uncertainty is not one of them.
Is anybody really feeling uncertain about ruby's future because it can run on the JVM as well as running in a less dependency-encumbered environment? I can see people being unhappy about the most common ruby implementation having a crap GC and really bad threading support, but having people working on their own ruby implementations is only going to improve the situation.
I see single-implementation languages as things to fear.
Well indeed, the point isn't some much single-implementation languages as language in which I, the naive user, do not have to choose between implementations.
>> Unless I have some strange, specialized need, I want one implementation that is guaranteed to work.
> I'd love guarantees of perfection too..
Hold up. I would hope my language doesn't imply 'perfection' but "least-common-denominator-works". I was too strong with "guaranteed" but works in the "fairly normal" use-cases is good.
Even in a language running on a really advanced GC, like the Oracle JVM, you can't ignore your garbage.
Wait, who's "you" here. I the poster stand by the claim that I, the naive developer producing something really simple like a GUI to, say, move one file really shouldn't worry about GC. I the advanced developer producing something like an object-database indeed have to worry about GC.
- I would note with a Ruby instance copying one very large file from one to place another, you do have to worry about the GC, since MRI never gives memory back to the system, EVER. One of the founders of Twitters personally described to me discovering this to his horror, WELL into Twitter's period of trouble. Not at the start... and this was someone dealt DAILY with the system. DAILY...
Forks are based on common code. We're talking about separate implementations, with different teams and different goals.
I call BS here. What common code exists between Rubinius, YARV and company????? Seriously, I've been slackly following Rubinius for a while and unless they've added something recently, they have no common code. Rubinious has been trying to create a common test framework but that doesn't imply any common code. My impression is Rubinious doesn't even use the YACC code from YARV/MRI. Prove me wrong, it's happened before...
In a lot of ways, Rubinious' common test interface highlights the dead end of Test Driven Development as well as it's negative impact on Ruby. Software tests can't in themselves prove SHT, I mean they can't prove the equivalence of anything.
The thing about C++ is that it's a standard, not a piece of software.*
Well, that is indeed a good point. But the point highlights the problems of Ruby, which has nothing like a common standard.
I found Ruby's variable scoping to be quite clean: local by default, unless prefixed to be an instance variable (and a few conventions for statics and constants, I think). I wish Perl had similar scoping rules instead of the layered on later techniques of "my" and "the blessed hash". But I still like Perl :-)
However, the rest sounds like a valid criticism of Ruby.
I'm curious as to what your issue with Ruby's variable scoping is? It seems very straightforward and intuitive to me. Especially compared with Perl's mix of dynamic and lexical scoping.
Ruby's variable scoping relies on the compiler guessing the programmer's intent, as its syntax fails to distinguish between "Introduce a binding of this name within the current scope" and "Assign to the variable bound to this name".
Ambiguity seems, to me, to conflict with the desire for clarity and reliability. Any language which allows a typo in an assignment statement to create a new variable name binding silently is insufficiently safe for my purposes.
I don't claim that Ruby and Python have security holes form this behavior, but people rightly criticize PHP's register_globals for similar reasons.
"Any language which allows a typo in an assignment statement to create a new variable name binding silently is insufficiently safe for my purposes."
Um...Perl has exactly this problem. The only difference is that it's worse because the variable in question gets created as a global variable of the local package - which is naturally visible to anything else that wants to see it, btw.
This is exactly why they created "use strict", and underscores the "Perl philosophy" in an elegant nutshell - instead of fixing the underlying problem, just create a hack around it and expect everyone to "know" that they should use it as a best practice.
We fixed it in Perl 6, and I created a patch for Perl 5 to make strict default. I wish it had been the default behavior, but at least strict is available (and has long been a recommendation in every credible tutorial and online forum).
Note also that ECMAScript has recently introduced a similar strict mode.
