Addison-Wesley:
Why did you decide to try the Ruby programming language?
Ruby Authors:
We were actively looking for a programming language that was pure
OO, without excuses, and lightweight--we wanted to be able to write what was in
our heads without getting bogged down in low-level details. We spend a fair
amount of time researching for tools that will help us be more effective.
Normally, we find something, try it out, and leave it on the "interesting, but
not compelling" pile. Ruby was different. Within an hour, we knew we were on to
something that was radically better than its alternatives.
AW:
What language does Ruby compare to most closely, and what are the
main differences?
RAs:
Ruby is somewhat like a cross between Smalltalk and Perl. It's
fully OO, like Smalltalk, but is more conventional to use. For example, in
Smalltalk, expressions are evaluated strictly left to right, so 1 + 2 * 3
equals 9. Ruby uses conventional precedence rules. Ruby programs are readable
by anyone familiar with a modern programming language.
Ruby keeps the convenience of Perl, but adds full object
orientation. Everything is an object, so there are no special cases. Unlike
Perl, classes and objects are trivial to write and use, so you find yourself
using them more. As a result, the programs you produce are better structured
and easier to maintain.
AW:
Why is Ruby so popular in Japan? Is there something going on over
there that is particularly suited for Ruby?
RAs:
Ruby excels at text processing, and, since it can easily handle
multibyte character sets, the Japanese have found it very useful. But there's
nothing magic about Japan in this regard--users worldwide can reap the benefits
of programming in Ruby. There's something of a chicken-and-egg story, too:
because of its popularity, Ruby has a very active user community, always
willing to help newcomers.
AW:
Is Ruby related to "Best practices," "Pragmatic Programming," or
"Extreme Programming"?
RAs:
Ruby can be very effective in XP. One of the XP principles is
DTSTTCPW, and Ruby programs allow the simplest expression of any particular
algorithm or program. We've used Ruby on projects as production code without
problem. As befits XP, if Ruby turned out to be unsuitable for some area of a
project, you optimize that one portion by coding it in a different language.
The idea is simple:
(1) express the requirement using Ruby
(which turns out to be a very natural and easy thing to do), (2) execute the
resulting requirement, and get feedback from the customer, (3) fix what needs
fixing for functionality, and (4) implement outside of Ruby things that turn
out to have a performance impact.
We don't want to give the impression that Ruby has poor
performance: it tends to benchmark somewhere between Perl and Python. The real
point is that the Ruby internals are so clean, extending Ruby is a trivial
exercise. Adding functionality to increase performance is a simple thing to
do.
AW:
Will Ruby displace any of the media-popular OO languages, such as
C# or Java?
RAs:
C# is a single-platform tool; both Java and Ruby are
cross-platform tools. Ruby is also open source and freely available. Given the
potential explosion of alternate computing platforms (PDAs, cell phones,
set-top devices, etc.), it doesn't seem prudent to commit to a single
architecture.
Ruby won't kill Java; neither will C#. But, if you want to write
well-structured, dynamic programs, and want to do it fast, you won't be as
competitive unless you use a tool such as Ruby.
AW:
What background and expertise did you bring to writing this book?
Why did you feel compelled to write this book?
RAs:
As we explained in the preface, we didn't set out with the
intention to write a book. We'd just finished The Pragmatic
Programmer
, and were just getting back into the habit of sleeping
nights. But, when we came across Ruby, we realized that we'd found a language
that would let us do many of the things we'd talked about in Pragmatic
Programmer
, and do them elegantly.
Ruby won't kill Java;
neither will C#. But, if you want to write well-structured, dynamic programs,
and want to do it fast, you won't be as competitive unless you use a tool such
as Ruby.
We wanted to write a book about using Ruby as a
rapid-development tool, but realized that, before we did that, we'd have to
write about the Ruby language itself. What started out as a simple tidying of
the existing Ruby documentation grew into a major project.
In order to write the book, we basically had to reverse-engineer
the language. There was no existing documentation covering all the features of
Ruby and its libraries, so we rolled up our sleeves and read the code. Just to
make things interesting, "Matz" [Matsumoto] was in the process of adding new
features for the 1.6 release, so we got pretty good at rolling with the
punches. All this was possible only because Ruby is so well written.
AW:
What one thing do you want programmers to walk away with after
they read your book?
RAs:
We, as an industry, make programming harder than it needs to be,
and it's plenty hard to start with. We need to do away with many of the
distractions that current languages burden us with, and program closer to the
application space. The closer you program to the user's world, the less you
have to change when the world changes. Think of it as low-inertia
development.
AW:
What are your plans for future projects and books?
RAs:
1. Sleep.
2. Help people adopt Ruby with tutorials and seminars.
3. Look at putting together notes for Rapid Development
with Ruby
.
4. Sleep.
AW:
What are your predictions for Ruby in the U.S. market?
RAs:
1. Ruby will experience explosive growth during 2001-02.
2. Sometime in late 2001, someone will release a Ruby browser
similar to VisualAge and the Smalltalk browsers.
3. Ruby will be used increasingly for "live modeling," in place of
UML or other static techniques.
4. Ruby will be embedded as a scripting language within other
products, as Python was intended to do.
5. Ruby will overtake Python within four years.
