Advertisement

Productivity, Efficiency, and Robustness

Bill Venners: In an article, you wrote, "Ruby's primary focus is productivity." How does Ruby help productivity, and what about efficiency and robustness? Productivity, efficiency, and robustness are all good things. How do you trade those off in Ruby?

Yukihiro Matsumoto: In my point of view, efficiency and productivity are the same thing, because we focus on programming efficiency, not runtime efficiency. I don't care about runtime efficiency. The computer goes faster and faster every year, so I don't really care about performance. Actually, I care about performance when I'm implementing the Ruby interpreter, but not when I'm designing Ruby. The implementer should care about performance, but the designer shouldn't. If you care about performance, you will focus on machines in design instead of on humans. So you shouldn't focus on performance in design.

To help programmers be productive, I focus on making programs succinct in Ruby. I try to make programs compact. I also focus on providing very rich features in class libraries. If you have a library method to do the things that you want to do, you don't need to write much code. In Ruby, we also have blocks, which are nameless functions you can pass to methods. So we can provide in libraries templates of common programming patterns, and you can provide a block to customize the pattern. Blocks are built into the Ruby language, so you can use them very easily. So by providing this rich set of features in the libraries, we help make Ruby programs compact.

As an example, Perl programmers have a technique called the Schwartzian transform, named after Randall Schwartz, who created the technique. You can use the Schwartzian transform if you have a list that you want to sort in an order determined by the result of passing each element of the list to a particular function. For example, you may want to sort a list of filenames in order of increasing timestamp. The list you want to sort are filename strings, but the order you want them sorted in is determined by passing each string to a function that returns a timestamp for that filename. A Perl user would know this is a job for a Schwartzian transform. They would pick up a book and look at a Schwartzian transform example, then apply the sample code to their particular case. But this is kind of a heavy activity for your brain. In Ruby, we have a sort_by function to which you can pass a list and a function. So to do a Schwartzian transform in Ruby, you don't need to look it up in a reference, you just call sort_by. This is an example of conciseness, and it is much easier.

Bill Venners: One of the arguments made by static typers in the static versus dynamic typing debate is that static compile-time type checking helps programmers make robust systems. What is Ruby's attitude about robustness?

Yukihiro Matsumoto: The Ruby language itself doesn't care about robustness. Actually, the implementation of the interpreter, which is written in C, should be robust. No Ruby code should crash the interpreter. So I try to make the interpreter robust, but the language itself in its design does not care about robustness for two reasons. First, you need to test the system anyway to be robust. So we encourage unit testing using a testing framework to help achieve robust systems. The second reason is that programs written in dynamic languages are very easy to run and check. So for day-to-day programs that aren't not as serious as enterprise systems, you don't have to be as robust. It's not worth the cost of declaring types, for example. And because there are so many dynamic checks in dynamic languages, in most cases something very terrible usually does not happen. For example, Ruby checks array boundaries, so you don't have buffer overwrites. Ruby doesn't provide direct address manipulations, so you can't crash the stack space. Therefore in Ruby, I want to enable programmers to get a program ready to test in a short time by making programmers productive.

Next Week

Come back Monday, November 24 for part II of a conversation with Bjarne Stroustrup, the creator of C++. I am now staggering the publication of several interviews at once, to give the reader variety. The next installment of this interview with Yukihiro Matsumoto will appear in the near future. If you'd like to receive a brief weekly email announcing new articles at Artima.com, please subscribe to the Artima Newsletter.

Talk Back!

Have an opinion about the design principles presented in this article? Discuss this article in the Articles Forum topic, Dynamic Productivity with Ruby.

Resources

Ruby in a Nutshell, by Yukihiro Matsumoto, is available on Amazon.com at:
http://www.amazon.com/exec/obidos/ASIN/020161622X/

Programming Ruby: A Pragmatic Programmer's Guide, by Dave Thomas and Andy Hunt, is available on Amazon.com at:
http://www.amazon.com/exec/obidos/ASIN/020161622X/

The Ruby Programming Language, an introduction by Yukihiro Matsumoto:
http://www.informit.com/content/index.asp?product_id=%7BA76D1D1E-AD7D-483E-AB8D-38FB188396C5%7D

An Interview with the Creator of Ruby, by Bruce Stewart:
http://linux.oreillynet.com/pub/a/linux/2001/11/29/ruby.html

Interview with Ruby Create Y. Matsumoto, by S. Ibaraki:
http://www.cips.ca/news/national/news.asp?aID=1224