Interview with Ola Bini

I always wanted to interview people that I admire for great ideas and code. Here comes one with Ola Bini. For those who live under a frogs butt Ola Bini is a JRuby developer at ThoughtWorks Studios. He is working on an exciting new language, Ioke. The interview is originally made for the Hungarian developer community site, Weblabor, but I keep this as reference. So here it goes, unedited, juicy :)

JH: As far as I know you have no formal education in computer science. How do you see the advantages and/or drawbacks of this?

Ola Bini: No, I dropped out of high school, so no formal education at all. There are both pros and cons, of course. The good side is that I've gotten lots of work experience during these years. I haven't felt that I actually needed the education. I've been able to pick those things up by reading a lot and so on. But right now I'm at a stage with my own language and so on where I feel it might have been useful to know more about how to navigate academia to find out what I need and so on.

The big negative is that I have no papers on the knowledge I have. Starting out, it's probably not a good career choice, but now I've managed to do enough things that I don't need the papers as proof anymore.

I would say that the world of blogging and open source makes it possible for people to show that they are good without going through education - but it's definitely not a route I would recommend to anyone.

JH: What is your daily job? Is it related to your programming passions?

Ola Bini: Yes. Nominally I'm a consultant, and I do a bit of consulting around JRuby and so on. I've also been on pure delivery projects in different technologies (I'm pretty much effective in both Java, .NET and Ruby).

But most of the time I actually get to spend it on doing things related to my passions. Working on JRuby itself is part of my job, and so is speaking at conferences. Ioke is not really something that ThoughtWorks benefits directly from, but indirectly there are some benefits to allowing me to work on that too. I also spend some time with Language Workbenches (such as Intentional).

Currently, the main goal I'm working towards is a Swedish ThoughtWorks office, and I'm really doing anything necessary to make that possible.

JH: You tend to describe yourself as a "language geek". Could you please share us your experiences with the languages you use(d) and fond of? And a related question: Do you like learning (or even invent) natural languages as well or formal ones only?

Ola Bini: Yes, I'm a language geek, but mostly in terms of programming languages. (Programming languages aren't necessarily formal languages, btw). I'm not very good at natural languages, restricting myself to Swedish and English, but I am interested in natural languages at the meta level - so I read books about that subject.

When it comes to programming languages, I enjoy learning new ones. But I've dipped my toes in most of the larger ones, and many smaller ones too. That is what pushed me in the direction of creating my own language.

JH: What is your recommendation to start to learn a programming language from zero, especially Ruby?

Ola Bini: Well. It is really trite, but it depends on who you are. The best general advice I would say is to just do something in the language (a real project, nothing toy). Of course, that isn't necessary for everyone either. I learn very well from reading, for example. But do stuff in the language. Adopt it as your general scripting language for a few weeks, for example. It will be painful at first, but you will be forced to learn quickly how to actually achieve things.

JH: Beyond hype, what can be the advantages of the marriage of JVM and Ruby (or any other scripting language)?

Ola Bini: I dislike the term scripting language. Ruby is a general purpose programming language, that has several features that make it useful to use for scripting - but definitely not restricting it to that.

At this stage of programming, most language implementors don't have time to implement really good GC or threading schedulers or just in time compilers. At the end of the day, you want to have an expressive programming language that still allow you to achieve things. And you doesn't necessarily ONLY want to use that language. So the benefit of a VM like the JVM is threefold. First, it makes it possible to implement a language with much smaller resources compared to the traditional way. Secondly, it makes it possible to interoperate with other languages on the same VM, which allow true polyglot programming (meaning, using the right language for a task, and mixing them when it makes sense). Thirdly, being on an established VM gives access to a large amount of libraries that you don't have to reinvent from scratch, or write C bridges to work with.

JH: Some Ruby apps and libraries need thread safety. How did you manage, if so, this issue in JRuby?

Ola Bini: Well. The internals of JRuby is thread safe, but we still need to mimic the salient aspects of Ruby itself, which includes all the little annoying threading tricks happening. If a Ruby app or library needs thread safety, they should use the thread library - it gives access to mutexes and semaphores and so on. These work very well on JRuby - and are more necessary since JRuby has real threads.

JH: Do you see new possibilities in the future versions of JVM that might be helpful for language implementors?

Ola Bini: Yes. Definitely. JSR 292 (I'm part of the expert group) is all about making changes to the JVM that will improve the situation for alternative languages. The main changes involved in this JSR is invoke dynamic and method handles. But we're experimenting and looking at lots of other features that might or might not make it into the JVM.

So the Java platform is definitely evolving in ways that will help it fill the needs of alternative languages.

JH: How do you see the future of JRuby? What directions can it go?

Ola Bini: That's a good question. I haven't thought much about it - of course, more speed is always nice. Charles is working on a Ruby2Java compiler that will make it possible to generate static structure from Ruby classes. I also think that JRuby is an excellent choice for people that want to experiment with the Ruby language - maybe changing it in smaller ways.

JH: Do you think about GAE/J can be a good platform for people using JRuby? What do you think about GAE/J in general?

Ola Bini: Yes, GAE/J is a good platform for JRuby, and I believe that GAE/J is in general very interesting for several reasons. Seeing as it opens up the AppEngine concept to the whole ecosystem of alternative languages on the JVM, people from many different communities can come together and do interesting things on top of it.

The limitations of the platform are also totally understandable, and not very problematic once you get used to them.

JH: I understand you are the inventor and maintainer of Ioke, a new language for the JVM. What were your motivations to create "yet an other language for the JVM"?

Ola Bini: My motivation was to try out some ideas I didn't see in any other language. And Ioke is not just another language for the JVM. It runs on the CLR too, and will be ported to other platforms. Starting out on the JVM was a very pragmatic decision, based on all the things I get for free by running there.

In general, I think that the attitude against creating new languages is a problematic one. I want people to create MORE languages. Creating a language is a good thing to do, and even if no one uses it, you will learn much from doing it.

JH: Could you please introduce us the basic concepts of Ioke?

Ola Bini: That's a longer answer than there is place for here. In short, it's a prototype object oriented, dynamically strongly typed programming language. It embraces mutability and macros. The main goal of the language is to explore expressiveness without giving any regard to performance. More information can be found at http://ioke.org

JH: As of Ioke you state you prefer expressiveness over performance. What does it mean in the everyday programming practice?

Ola Bini: No, I don't state that I prefer expressiveness over performance. I state that when developing Ioke, that is the philosophy I follow. Every task is different and every task has different requirements and tradeoffs between expressiveness and performance.

Thanks for your time!