You can try using irb. The following is paraphrased from Goto Kentaro (Gotoken), and originally appeared in ruby-talk:444.

If the readline extension module works with your interpreter, it makes irb a lot more fun to use.

There is also a simple program, eval, in the samples/ directory of the Ruby distribution. It lets you enter expressions and view their values. You can copy eval into the site_ruby directory in the Ruby tree, and then invoke it using:

Of all the scripting languages, Ruby is probably the easiest to extend. There are no problems with reference counting and variable types, and very few interfaces to learn. In fact, C code used to extend Ruby often ends up looking surprisingly like Ruby code itself.

First, get the Ruby source distribution and read README.EXT. This is a good document, not only if you're writing an extension library, but also if you want to understand Ruby more deeply.

Next, have a look at the source of the interpreter itself, and at the various supplied extensions in the ext/ directory. You'll also find good examples under contrib/ on the Ruby ftp sites.

There are two interfaces to Tcl/Tk included in the standard distribution. One is under ext/tcltk/ and loaded with require "tcltk". The syntax is very close to that Tcl, which is passed to Tcl interpreter. Unfortunately, the description for this library is written in Japanese.

The other is under ext/tk/ and loaded with require "tk". Its syntax closer to the style of the Tk interface provided by the Perl and Python interfaces.

You'll find ruby-gtk-x.xx.tar.gz and ruby-forms-x.x.tar.gz under contrib/ in ftp sites.

Two standard extension library modules are provided: require "date", which is simple and uses the English calendar, and require "date2", which is more general purpose.

Also see sample/cal.rb.

Assuming that the file ends in a linefeed, the following code may give the fastest result.

They act with $ , and return the start index and the end index of the matched data ($0) in the original string. See an example in tab expansion.

Rather than solve the specific problem, let's solve the general case. The first thing we'll do is produce a method that will iterate over an Enumerable object and collect a single result. Smalltalk calls that method inject, so we will too:

Notice how we've added the method to Enumerable. This means that anything that includes Enumerable can now use inject. But how do we use it? It takes a single argument `n' and a block. For each element in the thing being enumerated, it calls the block, passing in `n' and the element itself. The result of the block is assigned back to `n'. So, to define sum, we could write:

Ruby's continuations allow you to create an object representing a place in a Ruby program, and then return to that place at any time (even if it has apparently gone out of scope). Continuations can be used to implement complex control structures, but are typically more useful as ways of confusing people.

In [ruby-talk:4482], Jim Weirich posted the following examples of continuations:

Python and Ruby are both object oriented languages that provide a smooth transition from procedural to OO programming styles. Smalltalk, by contrast, is object only - you can't do anything until you understand objects, inheritance and the sizable Smalltalk class hierarchy. By providing procedural training wheels, Python and Ruby ``fix'' one of the features that may have kept Smalltalk out of the mainstream. The two languages differ by approaching this solution from opposite directions.

Python is a hybrid language. It has functions for procedural programming and objects for OO programming. Python bridges the two worlds by allowing functions and methods to interconvert using the explicit ``self'' parameter of every method def. When a function is inserted into an object, the first argument automagically becomes a reference to the receiver.

Ruby is a pure OO language that can masquerade as a procedural one. It has no functions, only method calls. In a Ruby method the receiver, also called self, is a hidden argument like ``this'' in C++. A ``def'' statement outside of a class definition, which is a function in Python, is actually a method call in Ruby. These ersatz functions become private methods of class Object, the root of the Ruby class hierarchy. Procedural programming is neatly solved from the other direction - everything is an object. If the user doesn't grok objects yet, they can just pretend that ``def'' is a function definition and still get useful work done.

Ruby's OO purity provides a number features that Python lacks or is still working toward: a unified type/class hierarchy, metaclasses, the ability to subclass everything, and uniform method invocation (none of this len() is a function but items() is a method rubbish). Ruby, like Smalltalk, only supports single inheritance, but it does have a very powerful mixin concept: a class definition may include a module, which inserts that module's methods, constants, etc. into the class.

Ruby, again like Smalltalk, provides closures and code blocks and uses them to the same good effect. The Ruby collection classes and iterators are outstanding, much more powerful and elegant than the ad hoc solutions that Python is sprouting (lambdas and list comprehensions).

Ruby's syntax and design philosophy are heavily influenced by Perl. It has a lot of syntactic variability. Statement modifiers (if, unless, while, until, etc.) may appear at the end of any statement. Some key words are optional (the ``then'' in an ``if'' statement for example). Parentheses may sometimes be elided in method calls. The receiver of a method may usually be elided. Many, many things are lifted directly from Perl. Built in regular expressions, $_ and friends, here documents, the single-quoted / double-quoted string distinction, $ and @ prefixes to distinguish different kinds of names and so forth.

If you like Perl, you will like Ruby and be right at home with its syntax. If you like Smalltalk, you will like Ruby and be right at home with its semantics. If you like Python, you may or may not be put off by the huge difference in design philosophy between Python and Ruby/Perl.

Ruby is much more complex than Python but its features, for the most part, hang together well. Ruby is well designed and full of neat ideas that might be mined for P3K. I'm not sure how many Python programmers will be attracted to it though - it hasn't won me over (yet). But it is worthy of serious study and could be a real threat to Perl.

Posted by John Dell'Aquila in comp.lang.python, 11/17/2000. Reproduced with permission.