Interview: Miles Sabin, Scala Eclipse IDE Developer

Miles Sabin

Miles Sabin runs a Scala-centric consulting company, Chuusai Ltd, but is perhaps best known in the Scala world for his outstanding contribution to the Scala IDE for Eclipse. Miles has made a business out of providing companies using Scala with the tools, practical advice, development help, training and the general support they need to be successful quickly. He took time out to talk about his early Scala experiences, the type of work he now does and some inside scoop on where the Scala IDE for Eclipse is going.
 

How did you get interested in Scala?

Miles: Well it wasn't really Scala that first caught my eye. Back in 1998 I was a member of the Java Community Process working group which designed the NIO event-driven Network IO API which was introduced in Java 1.4. The team did great work, but there's no denying that fully exploiting it to build high-performance network applications isn't easy in Java. You find yourself bogged down with manually created state machines everywhere and this gets very tedious and very difficult very quickly without corresponding tool support.

My intuition was that language-level support was the way to go, and set out on a long term project to find or invent something appropriate. Process calculi are very relevant here, and in around 2003 I was excited to discover Funnel, a language based on the Join calculus, coming out of Martin Odersky's group at EPFL. It was a very interesting language made even more attractive by targeting the JVM. I was periodically checking in with the project to see how things were developing when in 2004 EPFL announced that work on Funnel was being discontinued and Scala was to be the new thrust of their research.

Although very different from Funnel, I took one look at Scala and it was love at first sight. Not only did it address most of the shortfalls I saw in Java but it also appealed to my sense of programming language aesthetics. I immediately felt at home in the language. At the time I was the Technical Director of Codefarm, a company specializing in distributed constrained optimization and whose technology was firmly based on Java & OSGI infrastructure. Our product included a sophisticated domain specific language, something which Scala is ideal for, and we considered moving to Scala then but felt that in 2004 it was a little too immature to bet the company on. Now things are different and I don't hesitate to recommend Scala to new clients.
 

What was it like to learn Scala?

Miles: Programming languages are a passion of mine, so learning Scala was joy. There was so much in Scala over Java, some things that'd I'd really only seen in the research literature and it was fascinating to see them work out so smoothly in such an elegant practical form: generic types far richer than in Java, dependent and abstract type members, full-blown existentials, even regular expression types. Then there is the incredible power of algebraic pattern matching, case classes, and extractors extending pattern matching to arbitrary types. And I just enjoyed not having to use braces and semi colons. I would have been comfortable with a syntax less like Java's and closer to Haskell's, but I think that what we have represents a very well balanced compromise between readability and conciseness. For all that, having done a lot of rough and ready porting of Java to Scala the most tedious work is turning around the name/type definition order. Although I understand the logic behind the decision, it still remains a chore. And sometimes limitations of the JVM force surprising and awkward code patterns in Scala. Even so, Scala is much more concise and expressive than Java: easily an order of magnitude more pleasurable to work with.
 

What advice would you give to a Java programmer moving to Scala?

Miles: First, that it makes perfectly good sense to start out writing Scala just like you would Java: you don't have to use monads on day one or even ever. Any sizable software project is going to be based on many external components most of which will, for the foreseeable future, be written in Java. You can continue to use those components just as you did before, taking advantage of Scala's features when they're appropriate. This approach makes migration projects much less risky: you can move into Scala steadily at the rate that best suits the team. Oh, and use a good IDE like Eclipse!
 

How did you become involved with Eclipse?

Miles: I'd set up a consulting company and was building up the business with a variety of projects, always keeping an eye on goings on on the Scala mailing lists and looking out for opportunities to apply my love of Scala. A group, part of the energy derivatives trading operation of EDF (Électricité de France) announced that they were migrating a large (around 300,000 lines) Java codebase to Scala. They enoyed working with Scala, but really needed better development support for mixed Java and Scala projects in the Scala Eclipse IDE. The rest, as they say, is history. EDFT has now converted a large part of their codebase and written several new production energy derivative pricing applications in Scala. As a consequence of their support the Scala IDE has improved enormously.
 

What did you do to the IDE?

Miles: Sean McDirmid had broken new ground writing the original version. The team at EDFT wanted more features, but they also wanted it to be a reliable production quality tool. With Sean's work they could see the potential and were willing to invest to get what they needed. I outlined a plan of attack and we got going. The main goal was seamless support for mixed Scala/Java projects and integration with Eclipse's Java tooling: it's clear that a large proportion of Scala projects will start from an existing Java codebase and this seamless integration is absolutely essential to support gradual migration. We wanted to do this whilst at the same time fixing bugs and improving reliability with every release. I think I've succeeded in this, and it has had a generally confidence building effect on the Scala IDE's users. This increase in confidence has led to wider use and more valuable contributions from the community. Over the period of about 18 months I've steadily removed or re-factored redundant or structurally inappropriate code and roughly halved the line count to around 30,000. The code base is now much more accessible to casual contributors too.
 

What can you tell us about the next version of Eclipse?

Miles: There has been a big focus on reliability and users will see a dramatic reduction in bug count as well as performance improvement. Under the hood the mechanisms supporting the semantically driven features like type inferred hovers, semantic highlighting and hyperlinking have been completely reworked. Syntax highlighting has also been reworked and is now reliable even with code that's a long way from compiling correctly. There's also a new and more reliable approach to dependency computation which resolves problems people have been having when refactoring in large complex projects. Maven and Lift users will be relieved to know that they can now specify multiple output directories for their projects. Improved integration with the JDT continues unabated. And if I can squeeze it in in time, support for basic organize imports, rename symbol and move compilation unit refactorings.