Summary
Yukihiro Matsumoto, the creator of the Ruby language, talks with Bill Venners
about becoming a better programmer through reading code, learning languages,
focusing on fundamentals, being lazy, and considering interfaces.

Yukihiro Matsumoto, or "Matz," as he is known online, is the creator of the Ruby programming language. Ruby is an
object-oriented language suitable for writing day to day scripts as well as full-scale applications. Matz began
work on Ruby back in 1993, because he wanted a language that made him productive while being fun to use. Initially
popular in Japan, Ruby has been finding its way into the hearts of programmers all over the world.

On September 24, 2003, Bill Venners met with Yukihiro Matsumoto at the JAOO conference in Aarhus, Denmark.
In this interview, which is being published in multiple installments on Artima.com,
Yukihiro Matsumoto discusses Ruby's design philosopy, the features of the Ruby language, and becoming a better programmer.

In Part I: The Philosophy of Ruby, Matz waxes philosophic about design imperfection, the danger of orthogonality,
granting freedom with guidance, the principle of least surprise, and the importance of the human in computer endeavors.

In this fourth and final installment, Matz talks about
becoming a better programmer through reading code, learning languages,
focusing on fundamentals, being lazy, and considering interfaces.

Reading Source Code

Bill Venners: In an interview with CIPS Connections, you
said, "I read a bunch of open source software source code, for example, Perl, Python, and
many flavors of Lisp interpreter. I know they were needed to write Ruby." What benefit
do you think programmers can derive from reading source code?

Yukihiro Matsumoto: Programmers can get a lot of benefit from
reading source code. You can't simply tell people how to be good programmers. You can offer
them some principles of good programming. You can describe some good design
experiences you've had. But you can't give them a real knowledge of how to be a good
programmer. I believe the best way for that knowledge to be obtained is by reading code.
Writing code can certainly help people become good programmers, but reading good code
is much better.

Bill Venners: Why?

Yukihiro Matsumoto: Because being a good programmer is a matter of
experience. Code is an expression of the thoughts, attitudes, and ideas of the programmer.
By reading code, you can not only figure out what particular task the programmers were
trying to accomplish and understand how they did it, but you can also gain insight into
how they were thinking. This is the reason that reading code makes programmers better.

And besides that, if you want to know how to accomplish something in code, you can
open a computer science textbook. The textbook will explain the algorithm. But if
you want to understand the algorithm very quickly, reading code is the best way.
Moreover, you can execute code that implements theh algorithm. You can use a
debugger to watch the code as it performs the algorithm. And this is much better than just
reading a textbook.

Learning Languages

Bill Venners: In the CIPS Connection interview, you gave
ten tips for programmers. One of them was, "Learn more than one programming language,
preferably many different styles, like scripting, object-oriented, functional, logic, etc."
What is the benefit of learning multiple programming languages?

Yukihiro Matsumoto: Every language or system has its own culture. In
the background of every language or system are some central ideas. Most of these ideas
are good, but they are different. By learning many languages and systems, you get
exposed to different ideas—and that enhances your point of view.

If you don't know Prolog, for example, you may not know the power of goal directed
programming—programming by describing the problem to solve through specifying rules
to apply. This is a very interesting concept. It is a very different way of thinking.
And if you don't know Prolog, or the predicate logic, it's very difficult to discover this
way of thinking by yourself. Knowing other systems and paradigms expands the world
inside your brain. That's why I advise learning multiple languages.

Focusing on Fundamentals

Bill Venners: You also said in your ten top tips: "Don't focus too
much on tools. Tools change. Algorithms and basic fundamentals don't." What did you
mean by that?

Yukihiro Matsumoto: That was partly about focusing on humans
instead of machines. Humans change very slowly, but systems change rapidly. 100
years ago, people were mostly the same as they are in the
present time. 100 years ago we
had no computers. 50 years ago we had computers, but they were very primitive. 20
years from now, I can't imagine how computers will be. But I can imagine how people 20
years from now will think.

Another example is mathematics. Mathematics has a very long history. It's a very mature
science, but computer science is not. So it's good to retrieve ideas from mathematics.

Tools change very easily as time passes. If you focus too much on present-day tools,
your efforts will give you only short-term returns. If you want benefits that will endure,
you need to focus more on fundamentals. Focus on mathematics and human psychology.
Focus on established sciences and established ways of thinking.

Being Lazy

Bill Venners: You also mentioned in your ten top tips: "Be lazy.
Machines should serve human beings. Often programmers serve machines unconsciously.
Let machines serve you. Do everything you can to allow yourself to be lazy." Why
should I try to be lazy?

Yukihiro Matsumoto: You want to be lazy. You want to do anything
to reduce your work. I work hard to reduce my work, to be lazy.

Bill Venners: I believe that.

Yukihiro Matsumoto: I work very eagerly to be lazy.

Considering Interface

Bill Venners: You also mentioned in your ten top tips: "Be nice to
others. Consider interface first: man-to-man, man-to-machine, and machine-to-machine.
And again remember the human factor is important." What do you mean by, "consider
interface first?"

Yukihiro Matsumoto: Interface is everything that we see as a user. If
my computer is doing very complex things inside, but that complexity doesn't show up
on the surface, I don't care. I don't care if the computer works hard on the inside or not. I
just want the right result presented in a good manner. So that means the interface is
everything, for a plain computer user at least, when they are using a computer. That's
why we need to focus on interface.

Some software people—like weather forecasters, the number
crunchers—feel that the inside matters most, but they are a very limited field of
computer science. Most programmers need to focus on the surface, the interface, because
that's the most important thing.

Bill Venners: You also mentioned machine-to-machine interfaces, so
are you just talking about interfaces for users or also for machines?

Yukihiro Matsumoto: It's not just user interfaces. When machines are
talking to each other via a protocol, they don't care how the other is implemented on the
inside. The important thing is the proper output getting passed correctly via the proper
protocol. That's what matters.

If you have a good interface on your system, and a budget of money and time, you can
work on your system. If your system has bugs or is too slow, you can improve it. But if
your system has a bad interface, you basically have nothing. It won't matter if it is a work
of the highest craftsmanship on the inside. If your system has a bad interface, no one will
use it. So the interface or surface of the system, whether to users or other machines, is
very important.

Next Week

Come back Monday, January 5 for part III of a conversation with Ward Cunningham.
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,
Matz on Craftmanship.