The fundamental difference is that Perl doesn't think itself beautiful. There's plenty to hate specific to Perl: sigils for types, noisy syntax (not even the #$@%, just the structure is ugly), nested lists always being flattened silently (as a design choice, Larry is crazy).
I never end up using Perl, the niche it occupies between shell and python is empty for me. I never have a problem with a shell script where I'm wishing for more control structures or builtins. The few times I've written long-running resource-intensive shell scripts (like brute-forcing an MBR partition scheme), reducing the number of forks wouldn't make them more than a few percent faster.
The major ray of light shining down on Ruby is that it is a Perl that people want strongly to write better looking code in. That's a pretty big accomplishment, I think. It seems like a lot of the classic Perl webdev shops are moving to Ruby, and I think that's pretty great.
But seriously, anyone know if Parrot is a realistic vehicle for this?
It's just puzzling to me that with all the demand for a better interpreter, there really aren't any available options that are going to satisfy the community at large, and there's no visible light at the end of the tunnel. Is this because Ruby is a particularly difficult language to implement? Is it because there is no formal spec? Lack of leadership (compare with Guido and Larry)? All of the above?
Parrot is never going to be viable -- 'flexible' platforms are only so when there are piles of diverse users. Specifications do not make reality.
Ruby has a huge advantage over Perl in that there are a number of groups successfully working to reimplement, specify, and reform it. There are visible lights at the end of the tunnel, they're just for specific communities -- JRuby and MacRuby. Hopefully Rubinius (or a successor project) succeeds in replacing MRI, but it's a pretty damn hard problem.
All of the above = a huge bag of hurt that presents some damn near insurmountable problems (leadership, on its own, is a huge issue).
To be honest, I don't know how one would get past those things without first deciding, with a clear conscience, to hijack Ruby from Matz. I know that sounds malicious, but even Dave Thomas is calling for a fork of the language. Seems to me that forking is not quite what we need, as it keeps the language rooted in the past, bringing the performance baggage with it (you're still having to re-implement the loose idea of the Ruby spec, which as you pointed out, presents some really hard problems).
No, maybe we need someone smart, loud, and with balls big enough to arbitrate their way through whatever gray areas are left with Ruby's loose idea of a spec, perhaps make some tough calls on what language features can reasonably be supported, decide what needs to be cut, and break compatibility with existing Ruby code if necessary. To top it off? This person forms a foundation around it, a la Python.org, to ensure that the language is left in good hands, gets proper funding for new development, patches, etc (hell, I would love to donate to Ruby development if I knew the money would be put to good use. I don't have that confidence now).
Of course, what I'm talking about now is not Ruby, but a new thing. This new thing could be quite awesome. Whatever this new thing would be is still years out, even if someone decided today that they would do it.
There's a massive gulf between Matz and Guido as far as decision making, even when you only look at the Languages and not their imperfect Implementations. Just for example, look at how executable objects work:
* Guido made a hard+pragmatic decision that there are only Functions. Methods and Class Methods are functions that take their binding as an explicit argument (which is inferenced when called with the . selector). Lambdas cannot contain statements and simply yield to a Function. Functions are recursively defined as objects with a __call__ method.
* Matz tried to make everything hugs all around and the result is that there's no straightforward Function type -- there are Methods, Blocks, Procs, Lambdas (1); which yield into one another bafflingly and retain scope in untoward ways. This makes some simple use cases very straightforward, but at a terrible cost.
(1). Are there more? The lack of certainty with which I can answer this question is alarming.
Crisis driven collapse & revolutionary reform which is a lot like flipping a coin and ending up with either a small democratic government or even more fascism.
If you end up with the first, you're still not safe as it tends to grow over time. Think of fascism as the highest entropy state of society.
I have to second the headphones idea. And if you don't think you like techno or trance music, you might change your mind after you code while listening to it (which is about the only time I listen to it).
Stuff with a white-noisy background and a steady, brisk rhythm tends to block out the din of the workplace and helps me stay focused for longer periods of time. Was the only way I could cope with the loud, obnoxious sales staff sitting nearby. Oh, and avoid music with lyrics.
Similarly, jazz and classical work beautifully as working music. I code most often to Gould, and my favorite music for mental jams is to put my Thelonious Monk collection on shuffle.
Read up on setuptools and the Python Package Index, aka the Cheeseshop. Setuptools hasn't yet been adopted as the one true packaging format by all library creators, but it gaining acceptance.
Ok, awesome. And that's the same story as RubyGems. I've noticed that Python peeps are pretty big on "show me the code" anyway, but I think a lot of untapped potential is lost by not having a dead-simple distribution mechanism, as good as Python libs tend to be overall.
That's one thing I do like about Ruby; it wasn't always this way, but RubyForge + GitHub (Oh, GitHub!) + RubyGems combine to make for a very fluid feedback mechanism and make good use of The Cloud.
The result is that new libs get announced, distributed, tested, and improved by rabid Rubyists rather... rapidly.
