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.

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.

However, the rest sounds like a valid criticism of Ruby.

    irb(main):001:0> x = 0; xs = [1,2,3]; xs.each { |x| puts x }; puts x
    1
    2
    3
    3

   ruby-1.9.2-p0 > x = 0; xs = [1,2,3]; xs.each { |x| puts x }; puts x
   1
   2
   3
   0
   => nil

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.

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.

Evidently not everyone has kept up with Moose (released back in 2007, part of the Perl renaissance, can be learned in a few minutes.)

Really. "Core language" is kind of twentieth. Moose is very well-established in the Perl community. That's as core as it gets.

So is DBI, Perl::Critic, cpanminus, perlbrew, Dist::Zilla, Perltidy, and (depending on your version) autodie. That's why my definition of a great Perl programmer includes pervasive use of the CPAN--you're restricting yourself unnecessarily if you avoid it.

I'm not sure I understand why basically having to patch your language to get a feature that others have out of the box is not seen as a weakness of that language.

Now, we can talk about Perl + CPAN and all the jazz you find therein, but that's a different discussion. My point is, taken by itself, the language Perl does not have an especially good Object system, especially if you consider Ruby and Python the competition.

"So is DBI, Perl::Critic..."

What's your point? Database bindings and lint like code checking are not features every developer - or even a good chunk of the developers out there - are going to need, or have use for. By that logic I could point out that Perl still wins no points because Ruby and Python - and just about every other contender out there - has their own equivalents.

I'm not referring to CPAN or the the gobs of stuff in it - I'm referring to the language itself And while we're on CPAN, much of the popular and useful material in CPAN has equivalents in Ruby and Python that are every bit as mature and useful.

* assembly is weak because it lacks pointer arithmetic

* C is weak because it lacks a proper OO

* Java is weak because Clojure is an add-on

* Ruby is weak because Rails is a separate download.

I assume nobody really believes any of this meme-noise.

Compared to C it is. That's why they invented C.

> * C is weak because it lacks a proper OO

Compared to C++ or Java it would be - that's why they invented them.

> * Java is weak because Clojure is an add-on

Not sure I'm following your analogy here.

> * Ruby is weak because Rails is a separate download.

Have I been saying anything about web frameworks at any point?

You're making a bunch of false analogies. Compared to nothing other than itself, Perl is Perl. That's fine. It's axiomatic. Compared to other options, however, it does have some glaring shortcomings.

Not false at all. Substituting FP for OO, the Java install "lacks" Clojure. So extensibility is a weakness? If so, then every gem is a sign of a defect in Ruby The Language (an absurd conclusion).

>>Disclaimer: I have used a great deal of both Perl and Ruby.

You haven't used Perl lately -- then you would have known about Moose. Perl's OO is now arguably much cooler than the OO of alternative scripting languages...

Your point about variable scoping is really strange. Or stupid. Could you elaborate?

(Threading do suck, imho. But so it seems to do for most other scripting languages?)

As far as scoping goes, I shouldn't have to explicity declare a variable lexically scoped - and I can't think of any other language where I do. Only Perl - and only because it's visibly hacked in after the fact, along with a number of other features.

Threading is not great for Ruby or Python either, because they use green threads - but Perl has problems bigger than that with it's threading.

Really? I can think of a few: How about C, C++, Java, Lisp, and Javascript? (Yeah, technically javascript is function scoped if you declare it with "var", but you have to do that to prevent it from being global).

You do realize they all default to lexical variables, and if you want something else, you have to declare accordingly, right?

>Lisp

Is a beautiful language, and primarily a play-toy for academics with a handful of real-world applications. While we're at it, which Lisp? Ansi Common?

> Javascript

I believe it is exactly this quirk in Javascript's scoping that is a major complaint of many developers - although I don't know much javascript and can't speak with authority here.

I don't understand your argument. You have to explicitly declare lexical variables in those languages. Ditto for Perl:

    $ perl -e 'use strict; sub x { $i = 0 }'
    Global symbol "$i" requires explicit package name at -e line 1.
    Execution of -e aborted due to compilation errors.

Sorry, but that is hard to take seriously.

>>I shouldn't have to explicity declare a variable lexically scoped

Are you saying you don't like strict? Without that, you're fscked if you spell a variable name wrong in the same way, twice... (I really don't get that not all scripting languages have strict.)

I've avoided threading in scripting languages as the plague, but I tend to agree with you as far as I've read. :-)

No, my point is that if you compare it to another programming language simply as a language, it is basically missing a major feature. If you take Ruby, Python, and Perl, and line them up next to each other simply as languages, Perl is at the bottom of the pile on it's own merits where OOP is concerned.

> Are you saying you don't like strict?

Even if I use strict, good software development practice would dictate using a lexically scoped variable at all times unless I really need something else. That's one of the reasons lexical scoping is the default in so many languages at this point.

Reminds me of a Larry Wall quote: "I don't really know much about Python. I only stole its object system for Perl 5. I have since repented."

Really, Perl's native OO stuff just lacks syntactic sugar. "Bless" is admittedly weird. And you have to write "new" yourself. If you get over those 2 things, it's really quite the same as everything else.

Perl is extensible by design. Your "point" of refusing to accept that is just strange. If you can't handle it, use something else.

>>good software development practice

As __david__ noted, you're just strange here.

Variables really should be declared, as I noted before, just because of spelling problems. That is good software practice.

Edit: I might be missing the point re "strict", but you can't explain it to either __david__ or chromatic, either. :-) And it seems your "point" about downloadable extensions is that you don't have anything to complain about without that arbitrary limitation.

I think you're missing my point entirely. And I can "handle" it just fine since I've been using Perl for years now.

>Variables really should be declared, as I noted before, just because of spelling problems. That is good software practice.

Again, you're missing my point completely.