The Human Factor

Bill Venners: In an interview, you said, "Don't underestimate the human factor. Even thought we are in front of computers, they are media. We are working for human, with human." What do you mean by that?

Yukihiro Matsumoto: Imagine you are writing an email. You are in front of the computer. You are operating the computer, clicking a mouse and typing on a keyboard, but the message will be sent to a human over the internet. So you are working before the computer, but with a human behind the computer. Most of the tasks we do are for humans. For example, a tax calculation is counting numbers so the government can pull money out from my wallet, but government consists of humans.

Most of our tasks are related to humans after all. So in programming, either we ask the computer to work for a human, or we describe our thoughts to a computer in a very unambiguous way that even computer can execute. In the first case, making the computer work for humans, the target is a human through the computer. In the second case, expressing our thoughts clearly enough to be understood and executed by computers, we express intent from our human brains and as a result it is performed by the computers. So in both cases the object here is human.

Bill Venners: What is important about thinking that way? You say, "Don't underestimate the human factor." Why?

Yukihiro Matsumoto: Because computers don't mind if I must make effort to communicate with them or if it is easy to communicate with them. They don't care if I put the numbers of instruction byte sequences in a file and feed it to them to run, or if a very high level language generated the instructions. The computers don't care. We humans care about the effort we pay. Often people, especially computer engineers, focus on the machines. They think, "By doing this, the machine will run faster. By doing this, the machine will run more effectively. By doing this, the machine will something something something." They are focusing on machines. But in fact we need to focus on humans, on how humans care about doing programming or operating the application of the machines. We are the masters. They are the slaves.

Bill Venners: For the time being anyway.

Yukihiro Matsumoto: For the time being anyway, until the age of Terminator.

Principle of Least Surprise

Bill Venners: In an interview, you said "I designed Ruby to minimize my surprise. I was very amazed when people around the world told me that Ruby reduced their surprise and enhanced their joy of programming. Now I'm pretty sure that programmer's minds are alike all over the world." Why the principle of least surprise?

Yukihiro Matsumoto: Actually, I didn't make the claim that Ruby follows the principle of least surprise. Someone felt the design of Ruby follows that philosophy, so they started saying that. I didn't bring that up, actually.

I wanted to minimize my frustration during programming, so I want to minimize my effort in programming. That was my primary goal in designing Ruby. I want to have fun in programming myself. After releasing Ruby and many people around the world got to know Ruby, they said they feel the way I feel. They came up with the phrase the principle of least surprise. But actually, it's often misunderstood.

Bill Venners: How is it misunderstood?

Yukihiro Matsumoto: Everyone has an individual background. Someone may come from Python, someone else may come from Perl, and they may be surprised by different aspects of the language. Then they come up to me and say, "I was surprised by this feature of the language, so therefore Ruby violates the principle of least surprise." Wait. Wait. The principle of least surprise is not for you only. The principle of least surprise means principle of least my surprise. And it means the principle of least surprise after you learn Ruby very well. For example, I was a C++ programmer before I started designing Ruby. I programmed in C++ exclusively for two or three years. And after two years of C++ programming, it still surprised me.

Next Week

Come back Monday, October 6 for part I 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 News & Ideas Forum topic, The Philosophy of 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