Having taken a brief hiatus from Perl, I've discovered a new comfort with Ruby. Most programmers who use Perl religiously :)rather than as a tool are probably pretty comfortable with what Perl has to offer, but for those of you who want to know more about Ruby and Perl here's my examination.
deprecated got part of it right when he said a younger, fresher, prettier language. However, that statement should be qualified: Yukihiro "Matz" Matsumoto has created a programming language that has evolved beyond respectable. He has a created a language that is theoretically cleaner and more pure than its predecessors, including Perl. He has designed a language that makes writing consistent, concise, and flexible code easy. Furthermore, flexibility to Matz is extensibility, which comes from the deep object-oriented nature of his language. That nature has made Ruby code a joy to work with, and easy to interpret, regardless of who wrote the original code. It has made Ruby code transparent.
This all attests to the power of Ruby in the appropriate framework. Unfortunately, by creating a language that makes code maintainable, Matz has made 'ruby hacking' extremely ugly, and gotten rid of some neat idioms (that's only a bad thing to those of us who like to code 'cool' programs). Ruby has become almost too systematic or boring for users who aren't using the language to program professionally, and therefore it has hindered its own growth.
Although it looks to be rather successful in Japan, Ruby's success in America has been limited to knowledgeable programmers. That would seem like a good thing initially, but it has proved to be hurtful to the language. Ruby has not needed to combat bad programming styles like Perl has (that need for Perl has been expressed by one 'Andy Roonie' style critique of Perl), but it has also been unable to gain the mass appeal and audience of and to unknowledgeable programmers possessed by Perl.
So a novice go to Perl before Ruby (I was initially attracted by Perilââ¬â¢s code for that reason compared to even C), and because of the sheer volume of Perl users code gets published at a faster pace. This means that Perl libraries will constantly be ahead of Ruby, and all those programmers that are in love with CPAN will never get comparable results with RAA. The musings laid are part of the greater implications:
The Greater Implications Of Ruby's Successes For Perl:
Perl has a wealth of features it can (and will) draw from Ruby in Perl 6. To me, what Perl needs to draw most from Ruby is its organization. If Perl can make organizing programs as easy as Ruby, it will be a much stronger language. However, the language cannot loose its flexibility and hacking nature. When it comes to programming, in the end it's all about popularity, not theory. From what I've read, this is exactly what's going to happen. People who want Perl to be clean will get clean Perl.
Perl has already decreed its drawing of syntax from Ruby (I expect OO syntax to be very similar to Ruby's, which has proved exceptional.) However, to me, allowing an array of a certain object, hash of a certain object, and scalar value for a certain object is natural. The same is true for Damian and Larry, which is evidenced by the decision to let go of typeglobs. Instead, the symbol table will now be full of $package::'@symbol' or $symbols, depending on whether the item is an array, hash, or scalar, etc. However, I'm skeptical as to how one could accomplish the combination of this new symbol table with the idea of @Array is Array. Doesn't that create objects with immutable types at the most basic level? Isn't that exactly what Ruby's 'an object is an object is an object' mentality tries to prevent? How will the two mesh? I fear the solution could be rather verbose
I trust in Larry and Damian to design a system, which blends the two. There decision may be one of implementing objects internally, and making an externally arbitrary difference between arrays and hash in the symbol table.
The Greater Implications Of Ruby's Failures For Ruby:
For Ruby to grow further, it has to create a repository and resource of code that rivals Perl's. Ruby, as a language, provides tools for development that Perl doesn't have, but Perl has CPAN. Therefore Ruby's ease of use is offset many times by Perl's libraries, many of which one has to create on his or her own with Ruby. I'm not sure how possible this is to fix, because my previous outlining of Ruby vs. Perl has attempted to show, that CPAN is a result of Perl as a language, its flexibility and hackability of novice users contributes to a great archive of code as those users progress. However, if Ruby puts a valid initiative into building an archive of Ruby (or possible of all languages) that has the features of CPAN, and eminent Ruby programmers come out of the woodwork, Ruby should be able to make a valid repository, one which would make Ruby a much more viable alternative to Perl.
for Larry to finally say that CPAN was the 'best thing that ever happened to Perl' and most likely ever will happen to Perl. It's success is largely due to its simplicity and resistance to over-engineering
Jarkko wrote ZCAN primarily to help others like Ruby build their own. FreePAN is also something you might look into.
