Ruby Creator Yukihiro "Matz" about Ruby, Functional Programming and Programming Languages Design

Recorded at:

1. I'm Sadek Drobi, I'm here at QCon with Matsumoto Yukihiro. Matz, can you tell us what you've been up to lately?

Recently, I've been working on the version 1.9, which is the development version of Ruby, which is much faster than the stable version 1.8. We worked together with other guys from Japan and other countries.

2. In your talk today, you mentioned that if you recreate Ruby, you'll include more functions and laziness into the language. Can you talk more about this?

At the time I started designing Ruby, my knowledge about the functional programming was limited to Lisp, the very traditional functional programming language. Actually, it is quite similar to Ruby in concept, not the syntax, but recent functional programming languages like Haskell and OCaml has a lot of advanced functional features. Some of them cannot be introduced without changing the language like for example, returning the lazy evaluation. We need to change the language in a fundamental way. I don't think I'm going to introduce the lazy evaluation like Haskell into Ruby, even if I design the language of the whole, but still, some part of the lazy evaluation is useful in the languages like Ruby.

3. Can you tell us a bit about that part of this lazy evaluation that looks interesting for you for introducing for example in Ruby, if you want to rewrite it?

The functional programming has many good attributes in the programming, but still it's quite difficult to understand to ordinary people like me. So, I'm not going to make my language into the purely functional, but still, in Ruby's method named the Map, we turn as the array right now, so it eagerly evaluates to the end of the list or the sequence. But, if you return some kind of the lazy data structure instead of the array so that you can defer the evaluation until the time when we really need the value of the elements of the list.

4. You are talking about lazy lists, the yield keyword of other languages. Languages like to mix object orientation with functional programming, for example, Scala. There is, at some point, a clash between the 2 paradigms. Sometimes they don't mix really well. What do you think about this? Do they mix well, like treating functions as first class citizens in that language that is object oriented?

To get all the good attributes of functional programming, the language should be purely functional, like Haskell. The hybrid language, the object oriented programming and the functional programming had to be some kind of trade off. Now, I'm thinking about the fact that with side effects we could write some kind of imperative programming, which is not sure for most of the people. I'm thinking about isolating the side effect into a small part of the program, like an actor, so they communicate with the channels without any sharing data is the solution for that.

5. In Erlang, all imperative programming is in actors; that's the kind of thing you are talking about, right?

Actors is still immutable language, but with mutable languages, it can be possible, I think.

6. What are the other programming features that you are really interested in. After you designed Ruby, you thought "Oh, that's pretty cool!"

Actor, as I said, is a quite interesting concept in these days, since we had the buzzwords like "Clouds" and a bunch of cores and computers and many CPUs, so that we can utilize these cores in one program. So Actors and Software Transactional Memory utilize the multiple lines of control or threads will become more and more important in the future.

7. Do you think Actors and STM is a way to go for concurrency in Ruby? Would it be easy actually to introduce them?

I'm not sure yet, but it's quite difficult to integrate the STM into a language like Ruby. I think I'd choose the Actors if I were to do some kind of concurrency.

8. Would you be able to introduce it as a library or do you need to have features (syntax)?

We can cover most of them by libraries. I think we can do something, probably implementation issue, to solve the concurrency problem, but not the language.

9. Is it a product that is going on now or you didn't start such a project?

Some Actors library is available for Ruby and we are working on the multiple VM implementation right now, so that we can run the multiple VM in a process and we can assign these VM threads, the native threads so that we can run many cores in a single program.

10. Several times you mentioned Haskell and you seem to be interested by Haskell. Haskell, as we know, is a statically typed language, one of the most statically typed languages. What do you think of types?

I have some mixed feeling - the type sometimes helps to find bugs earlier and can help to prove the correctness of the software. Basically, they are good things, but still make me think rigidly.

11. So, it's not as flexible as dynamic typing?

Especially for the easy programming language.

12. Don't you think that type inference can add a bit of flexibility?

You can reduce the type, the size of the core, you don't have to declare the types, but the types are still there, complexity is still there and you can satisfy it. You still need to satisfy the type systems underneath.

13. You still have the compiler error problem messages. It's quite interesting. Have you programmed before in Haskell? Have you done any programming in Haskell?

I wrote some sample of programs like a "Hello World", but not real programming in Haskell.

14. Is there anything than laziness that you would like to incorporate in Ruby?

I feel sometimes uneasy by lazy evaluation. You don't specify the execution in a language like Haskell. I describe what I want or what I need, I don't say anything about to which degree I should do or the programming should go or anything like that. That makes me feel uneasy. I sometimes feel like I lost control of the program execution.

15. Even Haskellers, they tell about laziness that, when you try to optimize performance, you need to be careful about it. When you design a language, you come out with some features - with a language as the way you imagine it and people try to use it and sometimes use it not exactly in the way you imagine it. Sometimes, it gets some good or bad surprises about the language. Did you have any kind of such things with Ruby after you released it?

Yes, but the Ruby execution model behind the language is very simple and traditional, unlike Haskell, so I don't think Ruby surprises people in that way.

16. Does it surprise you the way people use Ruby?

Not really, but the application field can be unexpected. For example, when I wrote my book about Ruby, my first book on Ruby in 1999, I wrote that Ruby is not good for writing programs running un supercomputers or something like that and a couple of years later, people came in and said "I control my weather forecasting a program with a research program on supercomputer in Ruby" - I was surprised by that!

17. This is a surprising use of Ruby. Ruby is mainly about object orientation and now we mentioned Actors model that could be also a part of Ruby, which is a different paradigm than objects, we talked about functional that could be another paradigm. Do you see other paradigms that you like about programming other than object orientation, functional and actors?

Actors is part of the variation about object oriented programming, in the historical sense. The actor is made by Hewitt, which is driven from object oriented programming. The actor is not really a new paradigm. The object oriented programming started in the 60s. If there was any new paradigm in the future, there should be there by now. I think we won't see any new paradigm of the size of the object oriented programming for the next 30 or 40 years, other than functional programming, of course.

18. Which is an old one, as well.

Yes, which is an old one, but a little bit newer than object oriented programming.

19. The language you mentioned you feel interesting was Haskell. What other languages that you see interesting? You mentioned system transactional memory, what do you think of Clojure, for example?

Clojure is pretty interesting. The model behind the Clojure is Lisp, with STM so it's not really new. I'm a language geek, so I'm not really interested in using it, but I'm pretty interested in studying it. As a language geek, Clojure does not provide a lot of new things, it just came in the specs and the behavior and it was quite a good language, though.

20. Lisp purists don't like Clojure because it has much more syntax than Lisp. What do you think of these debates of purity and all this crazy stuff that we hear from communities?

I don't really agree with the Lisp purists, just because in history there are so many Lisp dialects with so many syntax variations. Clojure follows that history. Some people consider common Lisp as "the Lisp", but prior to common Lisp there were so many Lisps and even the Lisp without the s expression, Lisp with m expression or something like that. I believe that Lisp has a broader range of field than the mere common Lisp or Scheme.

21. In the same way we can talk about Smalltalk. Smalltalk has a lot of dialects and some people like to say that Ruby is almost the dialect of Smalltalk. Do you agree with that?

Partially, but it depends on the Smalltalk image, how much do you consider the image is important for the language. Many people consider the language and the image are inseparable, but it's also the environment, like class browsers, and inspector and something like that, but as a language, the basic concept is pretty much in common with Ruby. If someone considers Ruby as a Smalltalk dialect, I inherited so many concepts from Smalltalk, so I'm proud of being part of the Smalltalk community.

22. What do you think that is success factor of Ruby, if we compare it to Smalltalk? What is the feature that you really think it gives importance to Ruby?

Giving up the image based environment. By that, Ruby is pretty much more lightweight than most Smalltalk. It's quite difficult to implement the small tools like the scripting tool by Smalltalk by the Smalltalk program that usually carries a huge image with the software. It's quite difficult to make up a small script, but Ruby it doesn't have any of the specific environment or the browsers so that it is very easy to do this small task. That makes Ruby easy to understand and easy to accept for the ordinary programmers.

23. Earlier, you mentioned the actor's model could be added to Ruby. Do you think that it will make people use Ruby even more when they have a predefined model for concurrency and imperative programming?

I'm not sure. Concurrency is very difficult to understand, so making Ruby a concurrent language, makes Ruby difficult to accept for many people. There is some kind of trade off, easier language and an efficient language. I have to design very carefully to satisfy both fields. Working concurrently without sacrificing any usability.

24. The problem with the programming language is it starts somehow simple and then you start adding features and the problem is that you cannot delete features. Are you having this problem yet on Ruby or for now everything is under control?

In a complexity sense, Ruby is a very complex language, but I try to avoid what I call the exponential complexity. Adding method or adding simple class is the linear complexity, if they are mutually independent. The concept which is combined with other concepts makes language pretty complex. Imagine the C++ templates: the basic concept is very simple, but the C++ template, combined with any other type systems and other features in the language became very complex, it made the language pretty complex.

25. Do you mean accidental complexity?

Right. Complexity grows exponentially.

26. You are not for functionalities that mix?

Yes, I try to avoid that kind of complexity.

27. It's very hard to figure out to add only functionalities that don't mix, right?

Yes, that's a difficult part of language design.

28. Today, there are several implementations of Ruby - on .NET, on Java and even others. Are you satisfied with these implementations?

Yes, it's quite interesting and I wish we communicate and share the technology and innovation. Sometimes I feel like if we went together into the single program, the progress of the Ruby might be much quicker, but the diversity is very important in the open source field, so this is very important for us to progress in certain fields, like the JVM, .NET or some other platforms. So, yes, I'm pretty happy with it.

29. Do you see some things that added by other implementations, you would like to put in your own implementation?

The people behind Rubinius are working pretty hard. My Ruby has a history in gradual improvement, but the Rubinius people have the Ruby design and they started to choose the optimal implementation choice on the language. I watch carefully about the experimental implementation that, if the ideas prove right, I'd be happy to merge the ideas into the standard implementation.

30. Are there any ideas in that you took?

Not yet, but their reflection ideas are pretty interesting so I watch carefully about that.

31. What about the J Ruby and Iron Ruby? Did you see anything interesting in the implementation of these?

I personally don't follow the Iron Ruby yet, but I follow J Ruby somewhat and the technology is very interesting. At least they have a much better garbage collector.

32. Sometimes designing for performance gets against usability sometimes. Did you have this kind of issues "I should go rather performance than usability"?

I always choose the usability over performance. Ruby is a slow language, but it's OK for most of the use cases. I always choose the usability in the language design.

33. With Ruby being integrated with other platforms, on the JVM or on .NET, people tend to use things from these platforms, which makes the program not very portable, right? What do you think of that? It gets you really specific to some VM, which means you can't use any of the implementations.

Yes, but write once and right everywhere is not the keyword for the Ruby language, it is for a different language. I think that's OK for the programs that depend on specific platforms. Even on my Ruby, the C Ruby, some program runs on Linux and it does not run on Windows that's the natural way about the programming language. Unless the platform vendor spends a lot of money and a lot of effort to keep the compatibility along the platforms.

34. What was the hardest feature to implement in your Ruby?

Continuation. By continuation you can easily jump out of the function and get back into the execution point. It can break a lot of existing code. A lot of bugs are found related to continuation, but it was quite tough.

35. Ruby is a dynamic language and there are a lot of dynamic languages out there like PHP, Python, JavaScript. What do you think about these other dynamic languages?

Let me put the PHP aside. JavaScript and Python and Ruby and other languages share pretty much things in common, but they have different design priority. JavaScript is focusing on being embedded in browsers, so the core data model in the syntax should be kept small. Python has a very stable design choice. The people behind the Python are pretty professional and I respect them. They are equally important in the field of programming. Aside of the maturity and the richness of the libraries and the add-ons, the core language is equally powerful and descriptive. Actually the taste is most important to choose between these dynamic languages, aside from outside factors like the boss chose that specific language or something like that. With Python and Ruby, it is pretty interesting - some people love Ruby, some people love Python and it's just like a dog people and cat people.

36. It's a matter of identity, like where you find yourself best.

Do I choose which language to program in? Yes, I use Ruby. The PHP is very optimized to web. Ruby and Python and others are general purpose languages and the PHP is web language, so it's quite different in that sense.

37. When you design a language, you have this line, where on the right you get add in syntax and on the left everything is libraries. Ruby is somewhere in the middle. When you make decisions about what to put in a library and what to put in a syntax, how do you reason about them?

One of my beliefs is that syntax should not be done with the wind. When you see the Ruby program, you understand what they are going to do without knowing other files or other libraries. In Lisp, you don't understand the interpretation of expression without knowing the macro definition, but in Ruby the syntax is fixed. This line is an invocation of the method, so this line is called method in some class. You don't have any ambiguity so you don't have to worry about the meaning of the syntax. That's my design decision. To implement that decision, the Ruby syntax should be a little bit richer than Lisp or other languages. If the feature can be implemented by class or out of a library, I'm happy to make it up to the library.

38. Just enough to make the syntax familiar or the program familiar for everyone. I will ask you the last question, which is what's your favorite programming book? Or your favorite book.

Although I'm a part of the book, "Beautiful Code' is a great book. You can skip chapter 29, though.