“Ruby is much better at actually focusing on what we need to solve and reducing complexities.”

Q> People often categorize languages into programming language, scripting language, and lately the expression languages. So how do you differentiate?

I was never too fond of the word 'scripting languages'. The way I think about languages, I think about them in two different axes. I think about them as depending on how statically typed they are. So something that is very dynamically typed like Ruby or something that is very statically typed like Haskell, and then we have something like Java that is kind of fussy in between. And then I also think about how much complexity you need to add to the program in order to describe the essential properties of the system. So this is the essential versus ceremonious stuff that you need to tell the compiler, or the stuff you need to do that doesn't really contribute anything to the program. And this is the place where Java, for example, is fairly high up in ceremony, while the reason we like Ruby is because it is very low on ceremony and is much more essential and when you write a program you usually describe what you actually want to do. This is a place where static typing is a totally different thing. Because Haskell, for example, is very succinct and very essential. There is no ceremony in Haskell, but it is also a very statically typed language, while Java is a quite statically typed language, but is also very ceremonial.

Q> Ruby is often perceived as a scripting language, how do you change the mindset?

Yeah, that's a good question. I think that logically, people started seeing Ruby as a scripting language because it was kind of born out of a heritage. It came from Perl & Python communities and the first few years Ruby was mostly a scripting language in how it was used. But nowadays most people do use Ruby for scripting and usage is much more. Most of the things that it has now is only if you are doing application development, like JRuby is a perfect example of this. So the only thing that is slow in JRuby right now is startup time, because you have to spin up between JVM and stuff like that. That means that it is not a very good environment to write scripts in, because scripts, you want them to start instantaneously. So JRuby is an example of something that is explicitly for doing real applications. Long running enterprise applications that need to run really fast for weeks without having memory leaks or anything of those sorts, then what you require is something like JRuby for. And the fact we have those things in the community and something like JRuby is being accepted enough. I have seen a big shift in how big enterprises are seeing this. Like at ThoughtWorks, I have seen many large companies in both US and Australia, and at least 10 or 15 of these really large corporations that use JRuby internally. So I don't think it's as much of a problem anymore that people view Ruby as a scripting language. That's kind of been proven wrong, and I don't hear it as much anymore.

Q> Talking about the future prospects, where do you see Ruby as a better contender to Scala, and in what scenario would Ruby be better, and where can Scala or any other programming language have an upper hand to it?

I think that right now we are seeing Ruby exploding into lots and lots of new companies and lots of new enterprises, and I think that's really powerful. Ultimately I think that languages like Ruby, not necessarily Ruby itself, but Ruby-like languages are going to be the way we write most of the enterprise software in the future. I think that many of the ways we write things right now using things like C# and Java, it's fundamentally too low level and the languages don't make it easy for us to actually express what the program is doing, so we end up with programs that are full of complexities instead of actually solving the problems we are trying to solve. Ruby and Ruby-like languages are much better at actually focussing on what we need to solve and reducing complexities. So I don't think there is necessarily a specific point where you don't use Ruby. I think that for most applications Ruby is going to be the choice.

Q> Please speak about Ioke since you have been involved with its development for so many years?

Ioke is a project that I created. It's a language, it's an experimental language where I just tried to see where I would come if I don't care about performance at all. What kind of expressiveness can I get in a language if I just totally disregard performance, and just try to focus on doing things that no other language would be doing because it's just not performant enough. So it's a language experiment, it's not a language that anyone is supposed to use. It's just a way of seeing what would happen.

Q> Do you agree that India has a very strong Java developer community? So how can Ruby leverage this strong Java community and what initiatives do they have for growing the Ruby developer community in India?

Yes, India does has a very strong Java developer community, but firstly, I think that when you talk about Java, you really have to separate Java the language from Java the platform, where Java the platform is the JVM, is with platform libraries. I think that Java the language is basically COBOL of our day, and its legacy and vision brightens your systems in Java. So where does that leave all the Indian developers who are really strong in Java? Well, they still have all the knowledge about the platform, and I would suggest that if you have that knowledge, you should just try to learn one of those languages that run on the JVM, like using JRuby, for example, on top of Java, because then you can get both the benefits of Ruby while running and utilizing all your knowledge about Java that comes from your class libraries and so on. But there are other languages that are making large waves in the community right now, like for example, Clojure and Scala. I would say that the future is in these alternative languages. The Java language is going to be relegated to something we only do when we have to, and that's not very often and that's never for business applications. In terms of talking about how to... I mean, when it comes to creating more Ruby developers or teaching people Ruby... I mean, so this conference is a typical example. We try to host Geek Nights. We try to throw these kinds of functions. But at the end of the day, the way you learn a language is really to actually work with it and use it. At some point you need to sit down and actually use it. But it definitely helps to have conferences where you can learn from each other and so on. But most of the people who have come to a conference like this are already Ruby developers, so they might learn how to become better Ruby developers, but you won't see lots of Java developers showing up here, eager to learn Ruby. And I think that is still something we have to do.

Q: Coming down to the Indian developer community, what do you think, what sort of challenges do they face, or what sort of limitations are the Indian developer community having compared to others?

I would say, in terms of limitations, it seems to me that one of the biggest limitations for the Indian developer community is the economic circumstances of how software development happens in India. The whole idea of India right now, in the eyes of the West world, is basically a place where you can get cheap developers. But from the other side of that, it means that there isn't really that much leverage in terms of time for Indian developers. So, Western developers have an easier time, getting spare time or getting time from their employers to be able to learn other things. The impression I have got is that the Indian developer community doesn't really have the luxury of learning or having time to learn that way. So something that is happening in the West like picking up Clojure or something like that can happen very quickly. But if that happens, then it will take some time for the Indian community to catch up in some places, and I think that's a problem. But, the more of an internal market India gets, the less India is dependent on offshore development, the more that problem is going to be solved by

itself.