the blog
Back to -Blog

So What’s So Special About Ruby, Anyhow?

And I Don’t Mean Rails ;-)
by Huw Collingbourne
Saturday 10 March 2007.

Judging by the coverage in some computer journals, you might be forgiven for thinking that Rails is the only reason anyone programs in Ruby. Love and marriage, horse and carriage, Ruby on Rails – as the old song goes, “You can’t have one without the other”.

I beg to differ. Not only can you program in Ruby without Rails; there are many good reasons why you would want to program in Ruby without Rails. Don’t get me wrong – I’m not denigrating Rails. It’s a fine framework for developing interactive web applications. But it is not the be-all and end-all of Ruby. In short, while Rails can’t do anything without Ruby, Ruby can do a great deal without Rails.

Let me try to define the ‘special’ qualities of Ruby – the things that, to my mind, set it apart from other languages. Before I start I should say that some of these qualities can undoubtedly be claimed by other languages too – everything from Smalltalk (thorough OOP) to Pascal (clear syntax). But it’s the combination of the whole bunch of these qualities that really sets Ruby apart.

- Terse
Can you get any simpler than a “Hello world” program in one line?

puts “Hello world”

- Clear
It doesn’t look like C! Hurrah! More like Pascal, really, though without all the begins.

while i < arr.length
 puts(arr[i])
 i += 1
end

until i == arr.length
 puts(arr[i])
 i +=1
end

- Type-free
Or, at least, not strictly typed – no type declarations; and a single var name can be instantiated from many different classes.

Here (see the code below) x and y are arrays. Then x becomes a string, then a number. x is appended ( << ) to the array y and its value is finally shown by p y, which prints: ["hello", " ", "world", 200]

x = y = ["hello", " "]
x = "world"
y << x
x = 200
y << x
p y

- Thorough Object Orientation
Well, pretty thorough anyway: Ruby’s OOP is closer to Smalltalk than to C++ or Java.

- Fast to develop
Write then run. No compiling or linking.

- Dynamic Programming
Want to add executable code to a program while it’s still running? It’s this simple…

input = ""
until input == "q"
 input = gets().chomp()
 if input != "q" then eval( input ) end
end

- The Name
OK, maybe that’s not a good enough reason to pick a programming language but I have to say that, to my mind, programming in Ruby sounds a heck of a lot more fun that programming in C++. And, as luck would have it, programming in Ruby really is a lot more fun than programming in C++. (But, then again, what isn’t…?).

Let me be honest, there are also things I don’t like about Ruby. In my view, there are simply too many ways in Ruby of doing the same thing – too many methods, too much alternative syntax; this not only makes a consistent coding style difficult to achieve but also hides a number of potential pitfalls such as the different behaviour of apparently identical constructs: the two ‘ors’ or and ||, for example, or the two types of block – { &#8230; } and do … end.

In fact, when you really get to know Ruby, you will find that some of the claims I made earlier – everything from its simple syntax to its thorough object orientation – are not entirely true. Some bits of Ruby syntax are, to be blunt, a bit gnarly. If you aren’t very careful indeed, “what you see” in Ruby code may not always be “what you get” when you run it. In that respect, it isn’t as clear – as unambiguous – as Pascal. And as for its object orientation – well, as I said, it’s pretty thorough, though there are a few little oddities such as blocks which aren’t objects and imperfect encapsulation (data hiding is not strictly enforced) which might come as a shock to a Smalltalk programmer.

One thing that makes Ruby particularly interesting at the moment is the simple fact that it is not only evolving as a language (Ruby 1.9, 2.0 and beyond) but is also inspiring all kinds of other projects: everything from IDEs (such as Ruby In Steel :-) to compilers such as the Gardens Point Ruby.NET, to alternative Rubylike implementations ranging from the highly Rubylike JRuby to the less Rubylike Groovy. Not to mention frameworks such as Rails and Nitro and CMS applications such as Radiant and Typo.

In short, even though Ruby itself has been around for a decade, there has never been a period of such active development as now. All in all, this is an exciting time to be programming in Ruby…

Bookmark and Share   Keywords:  opinion  ruby
  • So What’s So Special About Ruby, Anyhow?
    11 March 2007

    Most people consider Ruby to be "strongly typed" as well as "dynamically typed". Therefore calling it "type-free" won’t sit well with many.

    • So What’s So Special About Ruby, Anyhow?
      11 March 2007, by Huw

      This is a case of ’for want of a better description’. I am all too keenly aware of the typing issues of Ruby. From the perspective of a C# or Pascal programmer, the lack of explicit typing and dynamic type instantiation may seem to make Ruby a language ’without types’. In fact, type inference has been one of the biggest challenges in the development of Ruby In Steel’s IntelliSense. Obviously, in order to provide correct IntelliSense, we have to determine the actual type of a given identifier within a specific context (scope, position, execution point) of a Ruby program. So, while Ruby is "type free" in the sense that it lacks explicit typing, each object is necessarily instantiated from a specific type or class. This is one of those aspects of Ruby which appear different according to which angle you view it from - the ’front end’ Ruby programmer or the ’back end’ implementer.

      • So What’s So Special About Ruby, Anyhow?
        22 March 2007, by David Koontz

        How is this different from either perspective. As a "front end" user I know that objects have a specific type and references(variables, identifiers) do not. I never for a moment think that I’m dealing with an object of an abstract type nor do I think that my variable is of "type" x. Viewing a variable as having a type is a very "static typing" viewpoint and doesn’t apply to Ruby/Python/Smalltalk/Lisp/. I don’t understand where the lack of a better term comes in either. You have strong typing and weak typing, this refers to how you can coerce data around and if you can just treat a Foo like a Bar even though they are not the same. Then you have static and dynamic typing. These are orthogonal to strong/weak. Ruby is a strong dynamic language, OCaml is strong static. Basic is weak dynamic, C is weak static. The problem is most people have never seen a type system that’s not C or its kin and thus the inexorable linking of strong and static and weak and dynamic.

        • strong v weak typing
          27 December 2007, by Jeff

          Actually, the distinctions are: contravariant v. covariant, and static v. dynamic.

          with strong = contravariant, and weak = covariant. And I really doubt that a covariant dynamic language could be written, as the type system would never know how to coerce the type of one object into another, as in t = "Hello " + 3 (how to add a number to a string: because of the dynamic typing, it can either pretend that the string is a number or the number a string, and I have never seen a dynamic type system capable of doing that, requiring "Hello " + 3::to_s //an alternative syntax in Ruby to 3.to_s().

© SapphireSteel Software 2014