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.
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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.
30. Are there any ideas in that you took?
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.
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.
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.
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.