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.