Despite – or perhaps because of – its remoteness, Sweden can claim a place at the forefront of communications technology as the homeland of open source software. Admittedly open source has a long history, one that predates computers with the amateur radio community; and personal computing in Silicon Valley which rose out of the hardware hackers of the Homebrew Computer Club. The Swedes though have had more than their fair share of high profile businesses which work in favour of the anti-market model such as MySQL AB – once one of the largest open source companies worldwide until it was acquired by Sun and then by Oracle.

Ola Bini follows in this proud tradition. A self-taught developer, he has a large interest in programming languages and spends most of his time focusing specifically on languages such as Java, Ruby and his own languages.

As a developer working for ThoughtWorks in Chicago, US, Ola has a strong interest in programming languages and artificial intelligence. He is a core developer of JRuby, creator the Ioke language and author of the well-received book Practical JRuby on Rails Projects.

RM:

How did you learn to program?

OB:

I started programming when I was about 7. My father worked in finance, and had a computer interest on the side. He had an Apple IIc that I taught myself programming on, using Basic. I read the programming manuals that came with it, and created small games. A few years later I got my own PC and started learning first C, then assembler, C++ and Pascal. A little bit later I picked up Lisp, and then Java started becoming large, so I learnt that too.

Between ages 10 and 15 most of my programming was driven by something called the Demo Scene, which is fairly big in Scandinavia. The idea is to create impressive graphical short snippets of code. Kind of like intros to games and other things like that, but these demos were standalone and done for the artistic value of the item itself. The main languages used were C, Pascal and Assembler, which drove what I learned at that time. I still remember the thrill of figuring out how to trick an old graphics card to switch to a 320x400x256 graphical mode to give you twice the number of scanlines. Fun stuff!

RM:

And then, as you got more involved in computers, were there particular people who helped you along the way? Were there important mentors?

OB:

The only important mentor that stands out was my boss during my first five years as a professional programmer, but that was late enough that many of my patterns had already formed. Of course, I learn a lot from a large number of my colleagues at ThoughtWorks. I believe mentorship is almost always a good thing to both give and receive, though – so I guess what I’m saying is that I got along despite not having much mentorship, rather than because of it.

RM:

I think I’m right in saying that you are self-taught in programming? Would you generally recommend people get experience in technology before a qualification in computer science? Or are there disadvantages learning programming academically as well as being entirely self-taught?

OB:

Yes, I’m completely self taught. For me, the big thing about it is mostly just that I was able to start so early – I have been programming for 22 years now. With that amount of time, you learn a lot. I think that if you only learn programming academically, there are lots of things that you will have to pick up another way – things like technique, etc. On the other hand, being self taught means I lack a theoretical basis that I definitely miss from time to time. I can’t say which one I would recommend. Try a bit of both.

RM:

Is there anything you would do differently about how you went about learning to program? Is there anything you wish you had done earlier?

OB:

Not really – I’m quite happy with my progression, actually.

RM:

Are there any programming languages which you don’t enjoy using, or do you get some kind of pleasure out of each one?

OB:

I strongly dislike Perl and C++. Those are probably my main hate languages. For many similar reasons, I actively dislike Scala. In general, programming is almost always a bit of a pain for me, since no language manages to express things as clearly and succinctly as I would wish. I’m currently on a Java project, which is quite terrible.

RM:

Your work gave rise to loke. What problem were you trying to overcome and was it a solution in the end?

OB:

The problem I was trying to solve was really to see what happens with expressiveness in a language if you disregard performance. I have always been unhappy with how far away written code is from our intent when writing that code. This is something that causes no end of problems when doing any kind of programming – it is all about communication: communicating with your team, with your domain experts, with your analysts; even with yourself some time from now. Why do we optimize the final case so much, when it’s so extremely hard to get our implementations to even implement what the business side is interested in? So Ioke is an experiment in expressiveness.

I think I’ve proved quite clearly that you can do some very nice things when you disregard performance, so I would call the experiment a complete success. Many of the things I learned from it are going in to the design of my new language, Seph.

RM:

So what is the major difference between loke and Seph? Has there been anything that you’ve found difficult to work into Seph?

OB:

There are a few core differences. The main one is with philosophy; the goal is that Seph will be pragmatic enough for real world usage. That means acceptable performance as a start. Seph is still prototype based and uses a strict homoiconic model. Ioke embraces mutability, while Seph objects are completely immutable. There are some other things that are quite different too, but these are the main things.

RM:

How do you go about designing a language? What tools did you use?

OB:

Not many. The most important tool is probably the JVM. I test-drove the design of the language, and every feature of it – which means Ioke has a complete test suite of its design. I used Antlr for the initial lexer and parser, but I’ve since replaced that with a hand written implementation. I used some libraries from different places and Emacs to write it all in.

RM:

That all sounds pretty agile. So the fundamental rule is write the code that uses the API before you write the code that implements it because otherwise you may be wasting your time writing implementation code that won’t get used?

OB:

It’s not only about not writing code that won’t be used. The more important aspect is simply that doing things that way leads me to a better design. It leads me to consider how I might use language features and also figure out where I’m missing something the language needs to have. I strongly believe in pragmatic agile as a way of doing development, and I’ve let that influence a lot of the work I’ve done, both with JRuby and Ioke, and many other projects.

RM:

You wrote Practical JRuby on Rails and obviously care about writing. Do you find writing prose and writing code to be similar mental exercises?

OB:

I actually think writing prose and code are two extremely different activities. Programming languages and natural languages are very different and how you structure and make mental models is completely separate. I definitely think writing prose helps you write more legible and understandable code, and a capability of finding the right word for concepts also help a lot, but that’s really where the overlap ends.

RM:

Do you refactor to keep the internal structure of a code coherent? Or do you just have a very good sense at the beginning how it’s all going to fit together?

OB:

Both, actually. I generally have a very good feeling of the overarching structure of the implementation of something when I start, but I usually refactor a lot within the confines of that structure. I do try very hard to get naming right the first time, and I’m not a huge fan of automated refactorings. When I refactor, I like doing it manually.

RM:

What languages influenced your design of loke?

OB:

In rough order: Io, Common Lisp, Ruby, Smalltalk.

RM:

Were there any languages that negatively influenced it, in the sense that ‘I don’t want it to be anything like that’?

OB:

Most languages! But not any specific language, except I know about specific mistakes or misfeatures I didn’t want to replicate. For example, I think class based OO is a big problem, and I didn’t want to fall down that path. I wanted a core library that is very liberal and easy to work with, which was one of the objections I’ve always had with Ioke.

RM:

OO is a funny thing. Do you think the OO people can lay claim to modularity?

OB:

They/we can definitely lay claim to part of it. But so can the functional part. Maybe the concatenative languages are the most modular though – take a look at how general the libraries for Factor are, and you will be very impressed. At the end of the day, there are many ways of structuring things for modularity. If that modularity is about abstraction, functionality or data locality is less relevant.

RM:

In general do you think languages are getting better over time?

OB:

It’s hard to say. In some cases, languages are getting very much better. Scala and Haskell are very impressive showcases of many advanced language features, while many central things coming in new languages are really things that have been in Lisp or Prolog or Smalltalk for a long time.

RM:

To what extent should programming languages be designed to prevent programmers from making mistakes?

OB:

Almost not at all. A language should not encourage mistakes, by most babysitting features that stop you from making mistakes also constrain expressiveness. My personal philosophy leans strongly towards enabling programmers, not constraining them. Take static typing – I think it’s a fantastic thing, but it shouldn’t be a feature of a programming language. It should be a tool I can use to verify certain properties of my program or parts of my program. The connection between static typing and dynamic execution is completely arbitrary – I would like to see languages that have skinnable type systems, custom type systems, composable type systems – and all of this outside of the core language, so I’m not constrained by the static types, but enabled by them. I wish my languages had this feature, but I don’t think I’m smart enough to do it.

RM:

What about the role of the language in making it impossible to make mistakes? Some people will say ‘if we lock this language down enough it will be impossible to write bad code.’ Then others will say ‘ That’s a doomed enterprise, so we might as well just leave everything wide open and learn it to the programmers to be intelligent and use it as they wish.’ What side of the argument do you come down on?

OB:

The problem then becomes what actually constitutes a mistake. Most mechanisms today focus on syntactic and static features. These aren’t the big problems plaguing our industry. The big problem is getting the semantics right, understanding what the business value actually is, and how to implement it correctly – and that’s something no programming language can stop you from getting wrong. Seeing as the cost of static type systems is so high, I just don’t think it’s worth it in most cases. It’s like full program proofs – you can do it, it’s terribly expensive and takes years to get right. But if you really need it, you can do – but most problems don’t require that kind of rigor, so it’s only used for airplane software, ambulance programs and things like that. This also brings to mind the old quote from Knuth: “Beware of bugs in the above code; I have only proved it correct, not tried it”. At the end of the day, we need testing much more than we need static verification systems.

RM:

Do you feel that programming is a young person’s game?

OB:

I still count as a young person, so it’s hard to say. Ask me again in 30 years.