Ruby (programming language)

Ruby is a general-purpose computer programming language made available as an open-source project in 1995 by its creator, Yukihiro Matsumoto (commonly called Matz), a Japanese computer professional with experience in open-source software and familiarity with a wide variety of programming languages. Matz has closely managed Ruby releases in the years since it first appeared, and by 2007, Ruby has been ranked tenth in usage among all programming languages. Furthermore, its use is still growing.

In 2004, Ruby's place in the U.S. computer industry was boosted by the independent release of Rails, a Ruby-based, open-source web application framework created in the United States by David Heinemeier Hansson, a Danish developer. This article is an overview of several often-cited Ruby characteristics, independent of Rails, for which the language is sometimes both praised and criticized.

Ruby Implementations

Like many "newer" programming languages (meaning those created or updated since 1990), Ruby is fully object-oriented and requires the installation of a runtime environment, or virtual machine before Ruby programs can be developed or run.

As of October 2007, ever-improving versions of the official open-source Ruby implementation have been released on several different operating systems. These runtimes are interpreted, rather than compiled, and thus Ruby is not yet considered to be a high-performance platform suitable for some heavy-load, enterprise applications. Ruby implementations have also been developed by other groups, including JRuby (an attempt to port Ruby to the Java platform), and Rubinius (an interpreter modeled after self-hosting Smalltalk virtual machines).

As of 2007, no formal written specification has been provided for validating Ruby implementations. So although Ruby can potentially can be used to create platform-independent programs, Ruby is not currently guaranteed to be identical across platforms, and newer versions are not always upwardly compatible with older versions. Furthermore, a burgeoning number of books, articles and other documentation are not always in complete agreement about the syntax, semantics, and conventions of the language. There is widespread agreement that Ruby would benefit from having a formal specification.

Things people like (and hate) about Ruby

Despite performance and cross-version and compatibility concerns, enthusiasts of Ruby wax eloquent in praising the language, including numerous subjective statements such as "it's fun". Something of Ruby's appeal may be seen in the brevity of this Hello World program:

puts "Hello, world"

But simple as it initially may seem, Ruby is described as having hidden depths, largely as a result of its support for a complex and powerful feature called closures. Peter Cooper, author of a 2007 book about Ruby, introduces the language by stating, "Ruby has more in common with more esoteric languages such as Lisp and Smalltalk than with better known languages such as PHP and C++". Cooper's book, and numerous other sources, list several characteristics of Ruby that may allow programs to be written with more ease, speed and "joy", than with other languages, including:

1. closures
2. a relatively permissive syntax, said to be more like the way people think and talk
3. loose typing
4. good string handling and regular expressions
5. extensive libraries for networking and web services
6. powerful support for making calls out to the native operating system if needful

Closures

Closures are a powerful and complex feature, implemented "in pure form" in only a few programming languages. With all the precision and politeness ubiquitous in the computer industry, even the definition of what constitutes a closure can be debated.

Closures are sometimes described as procedures or blocks of code physically situated inside another procedure. The enclosed procedure can be referenced (called) from outside the enclosing procedure, and if this occurs, the enclosed procedure still has access to any variables within the scope of its enclosing block or procedure despite the outer context in which the call occurs. In some languages, access to these "outer" variables (those in the enclosing scope) may be read-only, whereas in others such as Ruby, it is read-write.

Since the scope rules in languages such as C, C++, Java or C# were traditionally implemented by temporarily growing a stack frame to hold any local, or temporary, variables during a call, these languages typically do not permit what is called a closure, which is another way of saying that (at least usually), procedures may not live inside other procedures. So-called inner classes in Java and C# are a confusing exception; they may seem remarkably like closures in that they can access information in the surrounding class, but in practice, their use is limited mainly to handling events for the enclosing class.

Knowing what is meant by the term closure is one thing; knowing when and how to make use of it--what it can be good for--is trickier by far, and has not, perhaps, been considered required learning by a majority of programmers, to whom closures were usually not available anyway. Closures are accepted as good style in Ruby, and in fact, are encouraged in certain contexts. The often-cited example of a closure use in Ruby is the .each procedure, whose internal design uses a closure and a yield statement. ".each" provides a more convenient way of iterating through collections than conventional loops.

After citing the ubiquitous iteration example, closure advocates often state that closures have many more, powerful uses, but many have trouble explaining, in easily accessible terms, what such uses are. A famous warning from the seminal 1995 Gang of Four Design Patterns book inevitable comes to mind: ""Dynamic, highly parameterized software is harder to understand than more static software."