Ruby Creator Yukihiro "Matz" about Ruby, Functional Programming and Programming Languages Design
Bio Yukihiro Matsumoto ("Matz") best known as the chief designer of Ruby, is a software engineer and open source evangelist in Japan. He has worked on several open source products, including cmail, the emacs-based mail user agent, written in emacs lisp.
QCon is a conference that is organized by the community, for the community.The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community. QCon is designed with the technical depth and enterprise focus of interest to technical team leads, architects, and project managers.
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.
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.
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.
Actors is still immutable language, but with mutable languages, it can be possible, I think.
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.
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.
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.
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.
Especially for the easy programming language.
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.
I wrote some sample of programs like a "Hello World", but not real programming in Haskell.
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.
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.
Yes, which is an old one, but a little bit newer than object oriented programming.
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.
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.
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.
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.
Right. Complexity grows exponentially.
Yes, I try to avoid that kind of complexity.
Yes, that's a difficult part of language design.
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.
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.
Not yet, but their reflection ideas are pretty interesting so I watch carefully about that.
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.
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.
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.
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.
Although I'm a part of the book, "Beautiful Code' is a great book. You can skip chapter 29, though.
Link for the book "The Beautiful Call" mentioned
Re: Link for the book