Matz on Craftsmanship

A Conversation with Yukihiro Matsumoto, Part IV

by Bill Venners

December 29, 2003




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 Part II: Dynamic Productivity with Ruby, Matz discusses morphing interfaces, using mix-ins, and the productivity benefits of being concise in Ruby.

In Part III: Blocks and Closures in Ruby, Matz discusses two kinds of nameless functions in Ruby, blocks and closures.

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. 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

CIPS Connections interview with Ruby Create Y. Matsumoto, by S. Ibaraki:

http://www.cips.ca/news/national/news.asp?aID=1224