Ruby or not Ruby ?
- What is Ruby?
- Ruby vs. Perl
- Ruby vs. Python
- Ruby vs. PHP
- Ruby vs. C++, Java and C#
What is Ruby?
Ruby is an interpreted, object-oriented scripting language. It’s a "pure"
object oriented language; everything in Ruby is an object, no exceptions. It has
an easy, flexible syntax and is generally easy to jump right into. In all, it’s
nothing but fun if you’re an Object Oriented programmer. Here are some of the major
features.
- Dynamic, object oriented
Everything in Ruby is dynamic. It uses "duck typing" (if it walks like
a duck, quacks like a duck, it must be a duck) and new classes can be generated
on the fly at runtime. New methods can even be added to individual objects at will.
In all, there’s very little reliance on knowing the actual class of objects you’re
working on. If it responds to the methods that an array does, then it doesn’t matter
if it’s an actual array or not.
- Everything is an object
No exceptions here. Number and string literals, classes themselves are objects,
procedures and methods are objects, everything is an object. It’s not uncommon to
see things like "5.times do … end" or "10.weeks.ago" in Ruby
code. This is not syntax magic, the Numeric classes can be extended to provide these
methods. On that note, all classes can be extended. No exceptions there either.
- Easy, flexible syntax
Ruby favors a "naked" syntax. If leaving the parentheses off a method
call doesn’t make the syntax ambiguous, the parentheses can be dropped. This is
often used to make things that look like builtin statements, but are really just
Ruby code. For example, "attr_reader :attr1, :attr2" will make getter
methods for the instance variables attr1 and attr2. In a class definition, you might
think that’s just part of the language, but no, attr_reader is just a method itself.
This technique is often called "metaprogramming." Also, skipping back
to the dynamic feature, methods may be called during class definition that add more
methods to the class. attr_reader does just this, add getter methods to the class.
- Mixins
You might not be familiar with mixins, I know I wasn’t until I learned Ruby. Think
of them as interfaces (like in Java) with code. I’ll use the Enumerable mixin as
an example. Any class that includes the Enumerable mixin can be iterated over, sorted,
and all sort of other nifty things an ordered collection can do. To include the
Enumerable method, you only need to write two methods yourself: each (which provides
successive members of the collection) and (the operator that compares two members).
After that, you can pass this object off as any other collection.
- Closures
Closures are something like anonymous subroutines. The only major difference that
I see is the variable scoping. Where anonymous subs introduce their own local variable
scoping, closures do not. Closures are not a side-feature or oddity, they’re used
everywhere in Ruby. They’re enclosed by either the do and end keywords, or curly
braces. They can also take a number of arguments, defined withing pipe arguments
at the beginning of a closure. It’s best if I just show you. The following will
execute the closure 10 times, and remember that times is just a method of the number
which receives the closure as an argument. This is not magic syntax.
10.times do|i|
puts i end
In C, this would be something like:
for( i = 0; i < 10; i++ ) { printf(
"%d\n", i ); }
Ruby vs. Perl
- Points for Ruby
Ruby’s syntax is flexible, but it remains clear. There are entire (long, and non-trivial)
expressions that can be written in Perl entirely in symbols. To some Perl coders,
it’s almost as if it’s some twisted game to make your programs without ever touching
the middle of your keyboard. Ruby’s syntax can be terse, but it’s almost always
clear. Ruby is more expressive. By that I mean it’s easier to say what you want
done in relatively simple terms, and have Ruby do it. I think this point goes hand
in hand with OO. A common example is chaining function calls vs. chaining method
calls. Where function calls make you read inner-to-outer as in "func(10, func(20,
30))", method calls let you read left to right as in "obj.meth(30).another_meth(10)".
Though Ruby doesn’t go out of its way to make this point true, Ruby code often reads
like English and can be understood easily by non-Ruby coders.
- Points for Perl
CPAN is a big plus for Perl. The Comprehensive Perl Archive Network is a gigantic
collection of Perl code you can easily download and use in your programs. Ruby has
an equivalent called rubygems, but it’s young and very small. This might change
in the years to come, especially since Ruby has become very popular in the past
few years and new apps for it pop up every day. Perl is more diverse. There’s no
denying this, Ruby is an OO language and that’s about it. Coders from all backgrounds
can be comfortable in Perl, only OO coders will be comfortable with Ruby. Though
some might say this contributes signifigantly to Perl’s learning curve, it also
contributes signifigantly to Perl’s appeal to a wider range of people.
Ruby vs. Python
- Points for Ruby
Ruby’s flexible, "naked" syntax makes for code that’s easy on the eyes.
I don’t know how many times I’ve looked at Python code and been a little intimidated,
but if you remove all instances of the "self" keyword, the code looks
half the size. Some might say this is a minor gripe, but I’ve literally used the
self keyword six times on a single line doing simple math. For an OO language, they
sure make OO look ugly. Also, I just don’t like the indentation stuff. 95% of the
time, my code is indented as it should be in Python, but that 5% of the time that
I want to bend the rules really bugs me. I also can’t put seemingly simple statements
together on a single line. This also adds to visual code bloat. Ruby’s OO model
is more pure that Python’s. OO was not an afterthough, it’s the entire reason for
the existance of the language. Everything is an object, everything is a method.
You cannot say this for Python, and it leads to inconsistencies. Python also has
no closures, something it would benefit from greatly. It does have lambda, but it’s
a quite a bit more limited.
- Points for Python
Python’s unicode support is better. Ruby’s support is limited and as far as I know,
it stores all strings as bytes. Python has fully unicode support in every aspect,
including the source files themselves. This is a big plus for non-english speakers.
Python’s syntax does work for the better in many cases. The lack of braces all over
the place means source files are clean and tidy. If you’re normally a messy coder,
it forces you to keep your indentation in line. It’s problematic when you try something
like mixing Python code with HTML code (like PHP does), but in a majority of the
cases, it’s a good thing.
Ruby vs PHP
- Points for Ruby
PHP’s toolbox of basic types is lacking. Its sometimes-ordered hashes are confusing
and other than that, it only has a few types: numbers (integer and float), strings,
semi-ordered hash/arrays, classes (quite limited compared to Ruby’s), and resources
(connected to native code). Ruby has three types of numbers (integer, floating point
and bignum), arrays, hashes, structures, classes, regular expressions, etc. The
methods to acts on these types are also more diverse. You have to write less code
in Ruby because of that. Ruby has Rails. I was trying to avoid bringing up Rails,
but since I’m comparing Ruby to a web language, it was difficult to resist. PHP’s
only redeeming feature as a web language is easily mixing PHP code with HTML code.
While mixing output with code is very handy, its charm quickly runs out as your
sites get larger. Ruby has the same thing (called erb, embedded ruby), but its reliance
on it is almost nil as there is also the builder idiom.
- Points of PHP
PHP is very popular. PHP coders are everywhere, and have a wide range of skill levels.
The amount of PHP code on the web is staggering. Documentation, books, articles,
web forums, anything else you can imagine is plentiful. Prospective PHP coders will
have no trouble finding something to read. PHP is simple. It’s the BASIC of web
languages, there is almost no learning curve. You can be up and running in no time.
This, however, can be both a good and a bad thing. Since it’s possible to create
non-trivial things with minimal skills, code quality can be quite low. On the whole
though, this is a good thing. Non-coders should be able to handle PHP pretty easily,
lowering the bar for "modern" web pages.
Ruby vs. C++, Java and C#
I group these three because they’re all static, compiled OO languages. I keep the
discussion about them to generalites only.
- Points for Ruby
Ruby is extremely dynamic, you can even add methods to instances on the fly. It
uses duck typing, so it’s very loosely typed. The compiled OO languages are very
static, and much more strongly typed. There are arguments for both sides. Ruby’s
philosophies lead to a "fast and loose" development style, the compiled
language’s philsophies lead to careful and planned development. Once you stop thinking
about objects "having types" and start thinking about objects "responding
to the right set of methods," all sorts of interesting door open for the Ruby
coder. Ruby is written in C, and will go wherever there is a sane C compiler. You
don’t have to worry about architecture, endianness, operating system or any other
system details with Ruby code. Only (relatively) small amounts of the Ruby language
have code that needs porting, so Ruby can go almost anywhere. Compiled languages
have considerably more to worry about when moving to a new architecture. Of course,
Ruby pays for this in performance, which is discussed below.
- Points for the compiled OO languages
These languages will be faster, that’s a given. Ruby is interpreted, and has no
bytecode or JIT environment. This may change in the future and make the difference
in performance less staggering, but as it stands right now, Ruby is just plain slow.
It’s very CPU-hungry and in the great programming language shootout, it didn’t do
well at all. The compiled languages will almost always be faster. They’re also established.
While there aren’t many Ruby coders around (yet), you’ll have no problem finding
C++ (because it’s been around for so long), Java (same there, plus the hype), or
C# (because it’s a Microsoft product) programmers. There are tons of third-party
libraries out there, public domain code, and compiled libraries for you to use.
Ruby is still (compartively) young, unpopular and obscure.
