Ruby-Is it Prettier than Perl?

Kailden asks: "I've run across several references to Ruby, a scripting language that claims to be a hybrid of Perl and Python. Supposedly, this language has taken Japan by storm. I'm looking for Slashdot's verdict before jumping in. Has anyone outside the Ruby site used this language? What advantages/disadvantages have you found?"

Comments

It had to happen

[drix]

I'm not too shocked. It's not really a big secret that Perl OO is pretty ugly as it stands now; it's much like C++ is to C in that OO support was kind of welded onto the side as an afterthought. Someone looking to satiate the PHBs of the world who think OOP is the greatest thing since sliced bread had to do it sooner or later. But whether it's a good idea or not remains to be seen.

My issue with ruby is this: OOP just doesn't work for a lot of Unix programming situations. It's not a conincidence that 95% of all Unix apps are still written in C, despite it's successor having been around for 20+ years. Procedural programming is a lot less convoluted, requires a lot less time, and, despite what a lot of people claim, for me it's more intuitive than OOP.

Object orientation was really designed for massive, distributed software projects, where you aren't going to be familiar with every variable, and aren't going to know what should or should not be touched. And the paradigm really does lend itself well to GUI environments, where you can treat windows and such as objects. For that stuff, OOP works. Almost all of today's really big software and GUI apps are written in C++.

But Perl doesn't power too many really big projects, and it certainly isn't going to be used to write Gnome or KDE apps anytime soon. It's mainly used for parsing text. Does the "Practical Exctraction and Reporting Language" really need to treat all the text it's slicing through as objects? I don't think so. Perl is the quickest and dirtiest language of them all. Only in Perl can I do something like

#!/usr/bin/perl
use Time::CTime;
print(ctime(localtime));

and have a prayer of it compiling without any warnings or errors. Most every Perl app I have ever written or seen has been to do really simple things - e-mail form data to me, prune my directories, etc. etc. In such cases, OOP is complete overkill. Off the top of my head, I can't think of a Perl app that could really use OOP. In some of the larger CGI apps that I have written, e.g. a shopping cart w/CC verification & inventory control and lots of other goodies, I gave Perl OO a try and didn't like it at all. Maybe I'm a poor OO programmer? Dunno. But I found it to bee too much work for a language whose motto is TMTOWTDI.

The authors of Ruby want to replace Perl. It's in the faq: "matz hopes that Ruby will be a replacement for Perl ;-)" I'm not sure if this is a good idea. Perl got to where it is today precisely because it is ultrasimple. Why muddle it with lots of OOP complexity, no matter how elegant it may be?



--

Re:It had to happen

[Carnage4Life]

For "real" OO, one must go to high-level languages like Smalltalk and Lisp

The above comment just defeated any hopes of you being taken seriously by anyone with a clue. Lisp is a function al programming language and not an object oriented language. Functional langauges emphasize a lack of state (no global variables or assignment operations) and referential transparency (functions always do the same thing if passed the same parameters) which is in conflict with Object Oriented programming concepts. The chances of Lisp being mistaken for an object oriented language by anyone who actually knows about Object Oriented Programming is zero.

Personally I hate SmallTalk. As the first post to this article indicated OOP's forte is solving large scale problems, primarily because it turns out that C becomes very difficult to maintain past 50,000 to a 100,000 lines of code. The typelessness of smalltalk (as exemplified by Squeak) makes one rely on the documentation practices of other programmers way too much. Typelessness means that if one does not choose variable names that are highly indicative of the the type purpose of an object as well as comment the code properly it will be difficult for maintainers to update the code. In programs with a high degree of coupling this can be extremely aggravating. Several times while trying to write applications in Squeak I hit my head against the brick wall when trying to find out what types a function accepted or what types it returned simply by looking at the code for the function. Sometimes it would take looking through methods in 4 to 6 classes before I could figure exactly what type had been passed to a function and what it returned, of course by then I would have forgotten why I was looking in the first place. Imagine reading a man page with all the types Xed out. AAAARGH.

Re:It had to happen

[Carnage4Life]

Um... what have you just proved? Simply because you can use hacks and kludges to simulate objects in Scheme does not make it an OO language. The fact that I can write recursive C code without assignments or global variables does not make C a functional programming language. Neither does that fact that I can create structs with function pointers make it an OO language.

Re:It had to happen

[X]

Actually, parametric polymorphism handles this as well. A good example of this would be ML.

Re:It had to happen

[X]

Having the ability to access a language's meta-acces-protocol to make the language behave differently is not an indication that a language follows a particular philosophy. Perl is actually a great example of this. Are SCOS and CLOS really Scheme and Lisp or are they languages in their own right?

Secondly, I think you misunderstand the notions of OOP. OOP doesn't necessarily involve message passing. Certainly, that is how Smalltalk works, but it's not a requirement for OOP. Even in Smalltalk, all messages have a "receiver", which is a single object. Smalltalk code typically uses a mechanism called "ping-pong" to allow two objects to "talk amongst yourselves" as you describe.

In C++ you could define the behavior of the "=" operator outside of either class, and that would be basically what you're talking about. It sounds to me like in this case you really want to use a "function object" to implement your "equals" behavior. This is entirely possible in almost every OOP I can think of. Sure, the syntactic "=" is not implemented this way, but you can create your own Equals class which handles this.

Misc. Tangents

[Anonymous Coward]

Wow. It's hard to follow up an excellent comment like the first one posted.

I have to admit I've hardly ever used Perl. I started learning it once, but like so many of my projects, it was interrupted by Real Work, and never really finished.

What I have used fairly extensively is Python. I've used it for web development work, and general personal scripting, and I've found it quite decent. How it does differ from the Perl I've used, however, is its syntax-- it's much more stringent in terms of producing readable code. What it comes down to is asking yourself: Do I have time to waste writing this code, and will I ever have to look at it again? If the answer is no, use Perl.

I wish I had looked at Perl some more, so I could make some more educated judgements. I realize I haven't even touched on Ruby yet. :)

I've just briefly glanced at Ruby. I have found that roughly equivalent scripts run (slightly) faster in general. I'm not sure why.. I've heard that Ruby has better garbage collection, but maybe it's just in the design of the interpreter.

All three languages look at least passable. But there are tons of considerations when choosing which language to use. How fast can I code in it? How easy is it to extend an existing project? Can I find people who know the language to help me? Is it truly cross-platform? Do its basic libraries let me take the grunt-work out of my coding, leaving me to focus on my objective? Are there additonal modules available (for example, XML parsing, cross-platform GUIs)? Will my target audience (end-user/server) likely already have an interpreter installed?

etc., etc.

Really, I doubt you can go wrong with any of these languages if you're not looking to create huge projects. Good luck.

Ruby vs. Perl code shoot-out

[baldur]

I'm just starting to try Ruby out, and I haven't used it for anything big or important yet, but it seems to me that its main advantage is being rather more readable and probably more maintainable than Perl (which I still haven't stopped loving anyway...). Here is a small sample, lifted directly from the cgi.rb module:

def CGI::parse(query)
params = Hash.new([])
query.split(/[&;]/n).each do |pairs|
key, value = pairs.split('=',2).filter{|v| CGI::unescape(v) }
if params.has_key?(key)
params[key].push(value)
else
params[key] = [value]
end
end
params
end

Now, a more or less "literal" translation into Perl would look like this:

sub CGI::parse {
my $query = shift;
my %params;
foreach $pair (split(/[&;]/, $query)) {
my ($key,$value) = map { CGI::unescape(\$_) } split(/=/,$pair,2);
if (defined($params{$key}) {
push @{$params{$key}}, $value;
else {
$params{$key} = [$value];
}
}
%params;
}

Despite superficial differences, you are able to tell from this example that the strongest influence on Ruby has been Perl. The examples are essentially the same. Someone with a background in Perl (like myself) has a much easier time learning Ruby than, for instance, Python.

What I like about Ruby:

• Less punctuation than Perl and hence more readable. (This applies to braces, parentheses and semicolons, and maybe also the Perl vartype-symbols $, @ and % - though I'm of two minds about those, as I also think they contribute to clarity in most cases).
  
• You don't have to use local or my to get local/lexical variables. Variables in Ruby are local (not lexical) by default. (When I'm writing Perl, about 95% of the variables I use are lexical. That's a lot of my's!)
  
• The way you can easily string methods after each other using dot notation: variable.method1.method2(/regex).method3
  
• The way you can easily act on a reference rather than return a value, using "!", as in str.gsub!(/\"/n, '"'). (Although this particular example would be a bit more compact in Perl: $str=~s/\"/"/g).
  

What I don't like about Ruby:

• The iterator syntax (array.iterate{|v|, do_something(v)}), which admittedly is quite logical but for some reason gets on my nerves.
  
• No use strict.
  
• No CPAN (though The Ruby Application Archive is a good start).
  
• No poetry... at least not yet.
  

So, on the whole I think Ruby is quite nice. I'll follow its further development with great interest. But for now, I'm too attached to Perl to make the switch.

OO being misrepresented

[X]

A few misconceptions:

• Objective-C is as much a "grafted" OO language as C++. Admittedly C++ has lots of other things which have nothing to do with OO.
• Java is not a language with OO "grafted" on to it. Just try writing a program without using a class. Try writing a program that does anything useful without using an object.;-)
• Lisp is not an OO language, it's a functional language. CLOS is, but of course, that's a case of grafting.
• There is nothing that's inherently wrong with using a VM to execute a program. Indeed, Transmeta's approach suggests it's even of benefit to the hardware guys.
• Sun's Hotspot VM is based on a project that did type infrencing to improve performance. The results were much more impressive for Smalltalk, and were quite easy to achieve.
• The GNOME project using a Corba ORB to bundle up bits of code into objects. Given that most of the GNOME team is writing code in C, they seem to be demonstrating a fair degree of comfort with objects while being procedural programmers.

Ok, now that we've cleaned up all that stuff, a few comments. First off, there is no question that OO programming is a different way of thinking than procedural programming. That being said, most good procedural programming follows basic OO techniques (i.e. in C this is done using structures which include pointers to functions). Indeed, the Linux kernel has tons of examples of this. So it's really just that OO programming is structured to leverage good design skills. Indeed, once you have some experience doing OO, most skilled developers find it much faster to put together a prototype with say, Smalltalk, than with a non-OO approach.

Re:OO and massive projects

[ywwg]

I find that Java forces me to think about structure when I program. Sure, it means you can't rattle off a quicky program, but sometimes quicky programs become "mission critical" and turn in to big hulking mounds of spaghetti. Java forces you to create the most efficient code possible: what data do I need? who should have access to it? Where should I leave room for extensions?

Case in point: I wrote a software program that decodes satellite data and parses the output. I was able to add a whole host of features by touching a single class for each case: support for multiple data formats in one file, extensible support for any future data format, cleaner file handling routines, new ways of gathering data. I never had to go back and rework major portions of code. This assumes you design the program well to begin with :)

Another feature that goes untouted in Java is error handling. The "try{} catch()" method of trapping errors is pure genius. I can effectively trap and collect any errors and find out where they occured in the stack trace. Because all of the errors are caught in one place (the catch statements), I don't have to clutter my code with error checking. EOF? Don't worry about it, if it happens I can catch it later!

Lastly, having a main() function for _every_ class makes testing a piece of cake. If I create a main() function that tests the class, and it passes, I know I never have to debug that class and I can use its interface without worry. If something goes wrong in a class I can go back to the main function and play around with it until it works.

Oh yeah, and I need not deal with pointers or memory management :)