Martin Odersky

We Speak Your Language S04 E01

 

Jan

Hello everyone. Welcome to this issue of We Speak Your Language. We are lucky to have Martin Odersky talking with us. Martin is the creator of the Scala language and the author of many influential papers. Over the course of his career Martin has been involved in the companies that have furthered the development of Scala.  Thank you Martin for being on the show. Maybe we could start with the time your spent at the ETH in Zurich with Nicklaus Wirth. I assume that being part of Niklaus Wirth’s sphere of influence pushed you towards programming languages?

Martin

My thesis was a fairly weird thing. It was a way to describe static semantics of programming. What we would use type systems for nowadays. At the time there were type systems, but mostly the standard was really attribute grammars. Personally, I found the indirection of attribute grammars a bit weird.  Essentially you had these environments which were standard attribute and the environment would sort of essentially reflect a lot of what was also in the tree. So what I did in the end was essentially a way to reflect these attribute grammars where attributes could be tree nodes themselves. So essentially you would avoid other attributes such as symbol tables or environments and just point directly to the tree nodes. In my work I showed that this could work reasonably well. I got a TOPLAS paper out of it in the end, and that was it, basically. So it was mostly because the work we did in Zurich was very practical, it was essentially to get some topic that would be theoretically enough to write a thesis on.

 

Jan

And that was with Nicholas Wirth.

 

Martin

Yes.  And now a lot of people from his lab came to do the Graal VM.

 

Jan

Your first papers were on those Zurich languages, and then you switched to functional programming and you started working at IBM in the early nineties. How did that switch happen?

 

Martin

I read early papers from FPCA which was a very influential conference, a predecessor of ICFP, and I found the papers fascinating. So I said I want to work on that. Just as I was about to finish, I had a paper published in a conference and I asked Niklaus Wirth whether I could still get funding to attend, even though it was after my time at ETH. He said, “No. Regulations don’t permit it”, but luckily I had another conference to go to for free. So I choose FPCA, which was in London. That must have been my first functional programming conference. I had discussions with Phil Wadler and the early functional programming pioneers, all still young at the time. Back then everything was new and fresh, and I found it exciting.

 

Jan

From IBM you went to Yale.

 

Martin

Yes, from IBM I went to Yale because IBM didn’t really do that much functional programming. I was a bit odd man out. I went to IBM mostly because IBM (VisualAge) had close connections to ETH Zurich. So that was sort of the connection. Essentially somebody recommended me to join a group at Watson, and that’s what I did, but I was actually working more, so I worked at least for some of the time for Mark Wegman, of SSA fame. I was also working closely with a group of Australians doing constraint logic programming. That was the start of quite a fruitful collaboration with people who were at Watson at the same time as well. So I also have some work in that area, but I was most interested in functional programming because Yale was close Paul Hudak came visiting and we had conversations and I went back and my first POPL paper was actually something that was a fairly small, in retrospect improvement of a paper he had on essentially using abstract interpretation for something like static reference counting and object reallocation.

 

So he had a paper in 89 or 90, and I had a paper at POPL in 91, which sort of was an improvement on that. That was what led to me starting a postdoc at Yale.

 

Jan

Okay, so how was your experience working with Paul?

 

Martin

Paul Hudak was a great to work with and for. He had an interesting personality, warmhearted, supportive. I was quite independent, but essentially the mode for a postdoc was that I was given two PhD students for whom I had to find a topic and it was up to me to work out how they progressed with that.

 

Jan

I was surprised you wrote a paper was on type classes for Haskell with him. Now in Scala, one of the use cases of implicit is type classes. It is interesting that 92 you were already working on type classes.

 

Martin

Yes. They were in Scala from the start.

 

Jan

 Are the use cases in Scala inspired by that work, or was it something that you felt was needed anyway?

 

 

Martin

It was something very familiar to me at the time. It’s funny that at Yale I thought we shouldn’t implement type classes by passing dictionaries. It should be sort of more a global hash of these things. So sort of more like your work on use hashing to dispatch interface method, something like that, but for type class methods.  But then I turned around and said it is the dictionary passing that’s the essence of type classes. That’s basically first-class dictionaries, you could say implicit parameters because that’s what they are, they are first class dictionaries. We also have a paper with Phil Wadler in the meantime called a second look at overloading, which was very early Scala. I think that was independent, but it sort of predated the introduction of implicit parameters in Scala.

 

Jan

It’s interesting how these influences can be traced many years back. So after Yale, you went to Karlsruhe  back in 94. And there you continued working on type systems, lambda calculus. On the formal side, the foundational side. Around 95 you started collaborations with Phil Wadler which led to Pizza. That’s not the only thing, but that is definitely one thing that had impact.

 

Martin

The collaboration started on call-by-need. So we did the second look at overloading paper and then the call-by-need lambda calculus. That was most of it. It was theoretical. We were in close contact. One of his collaborators in Glasgow said functional programming is dead. Well, he didn’t say that exactly. He said, here’s this new language which wasn’t even released. It runs on a virtual machine, so it can run anywhere, and it has a garbage collector, which at the time was the domain of functional languages.

He said, “well, what are you going to do about that?” Implying that Java would be a threat to functional programming, which sounds funny nowadays, but at the time it was real. Phil’s idea was to take three things from functional programming and put them into Java or have it run on the JVM. We worked together on that. We discussed all the features together; the actual implementation was mostly my domain.

 

Martin

I thought, first I have to learn Java. At the time there was very few things published, it was pre-released. The best way to learn about Java was write a compiler for it. So that’s what I did. The compiler was called Espresso. I actually had a business writing Java compiler at the time. Espresso is interesting. I was contracted by a company that made the original E language, the capability-based language. I wanted to do something about Java and they needed a compiler, so they paid me a modest amount of money. At the time they were a startup, they couldn’t afford much. When I delivered it, I didn’t really know much about E. Not until Mark Miller’s thesis in 2006. I also did the Borland Java compiler. For Pizza, we took what we had in our implementation for Borland and added these three functional features on it and that basically became Pizza.

 

Jan

Were you involved in the transfer of the generics to mainline Java?

 

Martin

After Pizza, two people from Sun Labs (Gilad Bracha) contacted us and said your generic stuff looks interesting. The rest of Pizza we don’t need. We don’t need closures, we have classes. (Java 17 in 2021 is about to catch up on that vision.) They asked if we could do a version with just the generics and leave out the rest. We agreed. That became one of the candidates to add generics to Java. There was another candidate implementation by Guy Steele that was more ambitious in the sort of runtime support, i.e. to what degree types were verified at runtime. But in the end, our proposal was accepted perhaps because it was simpler to implement. I don’t know the official reason. In the end, they said “Well yeah this generic stuff – fine – but can you please also rewrite our compiler because our compiler is buggy.”

 

Martin

So several years after they were able to throw out the compiler because it was just so hard to maintain. This was between Australia and joining Karlsruhe. For a while generics were disabled rather drastically.  First they were just disabled with the flag but people of course found out about them. At the time Sun was suing Microsoft for adding unauthorized things to the language. One part of my contractual work was particularly painful. I actually had to rip out the whole generic stuff from the compiler, which was done by a preprocessor. So it was still in the code base but not in the release code.

 

Jan

Do you regret now that Scala is living on top of the JVM with generics that are type erased?

 

Martin

No, I think generics should be type erased. It’s important to have a very simple runtime model. In most languages generics are type erased. The only one there aren’t is C# and I think they have somehow admitted that they probably over-invested in generics. Of course it’s very nice to have generics at run-time for specialization, which C# does well: you can essentially automatically specialize implementations of sequences and hash tables and whatever, to primitive types.  That is powerful. But for the type checking, I think it actually goes the other way around because one of the ice things about generics is this theory of parametricity which says we have certain laws that hold because you cannot look inside the types. In fact Scala, in a sense, it lets you do too much with these things. Even the Java models, having things like equality is actually a violation of parametricity and discoverability, while “is instance of “ is a violation of parametricity.

 

Martin

We are trying to work out how we could have even more abstract types that don’t let you do that in order to regain parametricity. One thing in Scala 3 is opaque types, which are types that are implemented as some other type but are completely different and the type system needs to distinguish them.  Now, that abstraction can be broken by a clever type based pattern match or is instance of or things like that because then you can discover what the thing is. We want to have ways to actually avoid that and we put that into the language. For that reason I think we think that no type shouldn’t be reflective, meaning the aesthetic abstraction of behavior.

 

Jan

The language, other than C#, that has non-reified generics is Julia. Julia uses the full generic information for dispatch. So as you were saying, specialization on the kind of contents.

 

Martin

Yes, that’s what the advantage definitely is there.

 

Jan

So, if we come back to the historical track about the time Pizza was done, was that when you went to Australia?

 

Martin

Yeah.

 

Jan

What led you to Australia? It’s far!

 

Martin

Lifestyle mostly. I wanted to try out something from my time at Watson. We had good friends in Australia and I suppose also the weather isn’t too bad!

 

Jan

So, you spent a few years in Australia and then in around 2000 you joined EPFL.

 

Martin

Yes, that was in 1999.

 

Jan

Looking at the papers you published at that time, clearly one of the topics you that interested you were functional nets.

 

Martin

Yes.

 

Jan

How does that fit into your own personal evolution?

 

Martin

Well, from my trajectory I was dipping into different language communities. With Wirth it was classic procedural, then functional programming. My Java work exposed me to object-oriented programming. I’ve been following Smalltalk, but I wasn’t working with it until Java. Then with functional nets, I had this idea to say we want to have a grand unified design that can combine all these paradigms, but I wanted to do it with strong formal foundations.  I came across Join Calculus by Fournet and Gonthier, which looked really nice because it was a more focused version of π-calculus. So essentially it could do concurrency, but there was also a locus where things happened, while π-calculus is smeared all over the place. But in the join calculus, you could attach a location to things. It looked like objects, there was very little missing.

Essentially, what I did was a slight generalization of join calculus, that looked a lot like Petri nets. We did  a research language, a minimal language called Funnel working on functions. It had a very small base, it was essentially just the calculus and it was relying on a lot of encodings to get records and objects etc. onto the simple calculus.  I spent a couple of years spent working on that, and decided this  encoding approach didn’t work because newcomers were baffled by it and experts were bored by. One thing I could have done, but I didn’t at the time, was to add a powerful macro system. However, I wasn’t sufficiently up to speed with macros, so it didn’t enter my head.  But this made us realize that we had roughly the correct theoretical approach, which seemed to work through encoding. So putting these two pieces together, we thought the best idea would be to design a language that connects these two in a more elaborate manner, meaning that it would have more user facing abstractions which can be used directly – and finally this became Scala.  Scala was a direct outgrowth of functional nets and the thing that got dropped in the end was actually the core of functional nets. This joined local synchronization was just one of many possible synchronizations that it can actually be done in a library or very close at least. So, in the end the thing that gave us the depart, got dropped.

 

Jan

Scala merges your functional programming background and that somewhat accidental foray into Java. It’s interesting how all of this converges and ended up with you working on Scala. When did the Scala begin? Do you have a rough time frame?

 

Martin

It was around 2002 when we switched from Funnel to Scala. The first release was in January 2004 and first internal usage was 2003 in spring. I remember this clearly because that was the year I took over the functional programming course at the EPFL. I decided to do it in Scala, and we didn’t have a compiler yet, so we were really rushing to have a compiler and to keep up with what the students needed each week. It was really a race, and the students surprisingly enjoyed it – even though, of course, the software was extremely rough, they enjoyed being part of something brand new.

 

Jan

One thing that is interesting about Scala is that it stands at the boundary of so many things. In my mind it’s the boundary between all object-oriented programming and functional programming, it’s the boundary between theory and practice and it’s the boundary between academia and industry. It straddles all of these boundaries, and there are very few, there’s a very small number of academic projects that manage to become very successful and used by millions of people, and so what I’m curious and I wanted to ask you about is how you managed these various boundaries. For instance, from your university standpoint, how do you deal with the constraints of working with a production language that major companies rely on? How does that affect your work?

 

Martin

That is a good question. The object-functional boundary was per design, clearly so that was the whole point. The thesis of the experiment was that we can combine object-oriented and functional, in a fusion where the things are actually really merged and not just side by side. With the industry, we sort of stumbled into it. The original motivation was just that we want to show it’s practical. We didn’t intend for widescale industrial adoption. When you’re an academic you don’t really dare dream of that. It is so rare, like you said.

Fairly early on, we had maybe five users or ten users that used it for their startups, but there wasn’t really that much happening. Then somebody picked it up in San Francisco, which of course helps because that’s where everything happens. This guy then convinced some other people to use it and it sort of grew from there. Then we had user conferences. The first one I went to I think was in 2007, and there were maybe 50 people there, so that was already pretty good, and then it suddenly exploded when Twitter picked it up.

 

Martin

Twitter, you have to understand, was a company with 25 employees at the time. What they told me is they had ran into problems with their programming. They had a previous implementation in Ruby and they had problems with the garbage collector and memory leaks and things like that.

So, they had to reboot quite often. That’s why they had this friendly looking whale which was the fail whale that came when it was rebooting again and again at the time.

It was a venture funded company and the investor said no, you can’t do that anymore, you have to rewrite your stuff on something more solid, and one thing they insisted on I think was Java and the JVM. But Twitter, at the time, had quite a few language enthusiasts who found the idea of rewriting Ruby stuff in Java quite unappealing. So, they said well there’s this new language and that looks better and we probably can sell it to our investors because it’s running on the JVM, which means we can pretend it’s Java. And that’s how we basically got into Twitter. At the time it was still another deal. It was a fairly small company but then of course Twitter grew a lot and with it; Scala jumped on the scene and a lot of other companies followed suit.

 

Martin

Then I think the next big booster was probably the open-source libraries like Spark and ACA that were developed in it. At the time it was Spark but now it is Data Bricks which is a huge company, but back then it was just a couple of grad students at Berkeley who picked it up.

 

Jan

To come back to the point which I was curious about is how did that success, the fact that you were working with the industry affect your university research and development. Was that a lot of pressure?

 

Martin

Yes, that was a difficult thing to address. There were a lot of tensions there. After Scala became successful in 2009/2010, the new development slowed down and we formed the company Typesafe to essentially take care of the further development of the language.

Initially, Typesafe was essentially a generation of grad students from EPFL who did the Scala work with some outside people who also already contributed together in this company. But there were other things such as the Akka framework from Sweden which was a very important part. The company did the main work and at the same time I had an ESC advanced grant on specialization, lightweight modular staging and that used a branch of Scala called Virtual Scala.

We essentially forked the language, and we had a research branch. That wasn’t always easy, because it turned out that Virtual Scala fell back fairly quickly behind the mainline Scala and was never as robust as the mainline compiler. It just adds stuff to make a point in research, or to define whether you spend a lot of time tuning things and fixing bugs and things along those lines. So, at the time we essentially had two branches; the virtualized Scala and the main Scala that Lightbend  produced. Once that was wrapping up, I was getting ready to make the decision to move onto the next version of the next big version of the language without constraints, and that’s the reason why when I started a completely fresh code base which was dotty, that is essentially there still are completely different code bases which now are Scala Two and Scala Three.

For a long time I wasn’t sure whether the new version of the language should be called Scala at all, because it’s really quite different, but it happens to be mostly backwards compatible, so you can port programs from two to three fairly easily and it’s binary compatible.

In the end I called it Scala Three which personally I thought was a good compromise, but in the end it wasn’t. When I called it Scala Three, what I had in mind was the difference between Modula II and Modula 3. Modula II two was a language designed in Zurich and Modula 3 was designed by people at DEC was a completely different language. It was inspired by Modula II but it was quite different, I though Scala Three was sort of the same thing, it’s inspired by Scala Two and it’s interoperable but it’s actually quite different in that sense. But now it’s sort of the main line of Scala and it’s quite a big jump.

 

Jan

So now, let me ask the same question but from the industry point of view. If you think about Lightbend or Typesafe, how difficult was it from their point of view to deal with the fact that the core of the language was done by researchers and grad students? Did that cause issues?

 

Martin

I believe that the overall compiler quality was actually quite reasonable from the start and got better over time. So, I don’t think that the version that Typesafe or Lightbend had was in any way worse than, let’s say, the early versions of Swift or Kotlin or any other languages. It was about the same maturity trajectory and they had the advantage that Scala had already been developed for a while already.

It has to be said that before we started the company, for some years we were already quite a bit more conservative in not accepting arbitrary contributions or things like that.

What did slow down was essentially adding new features – that just didn’t happen that easily or quickly anymore. That was good because I think it was a bit of a crazy time before. In terms of that, I think Scala Three is mostly a step back. There are quite a few things that we don’t do anymore, that we dropped completely and overall the goal is to essentially simplify things and make things harder to misuse. For programming languages. I thought that initially it was very important to be small in the feature count and at the same time expressive, and you achieve that through regularity and orthogonality etc. but there’s actually also a social dynamic behind it, that you want the language to discourage people making it overly complex, making the libraries overly complex and that’s not the same thing. Language complexity is not the same thing as encouraging library complexity.

For instance, in terms of feature count, a very complex language is C# so if you look at the size of grammar and things like that, C# beats everyone hands down. But a similar library complexity actually hasn’t happened because essentially despite all the features C# has, it lacks some of the things that allow other people to create their own abstractions, things like higher kind of types or macros etc. But often even though maybe it doesn’t even add that much to the language footprint, it encourages communities to create things that in the end become very complicated.

 

Jan

I hear what you’re saying, but I have the feeling that even in languages that are not as rich, for instance, Java, you can create very complex software just by dogmatically applying design patterns. I’ve been looking at this code base where everything is an abstract factory and it’s parameterized in all directions, and the result is that you get code that is very hard to disentangle. I do think that discouraging complexity is something we should do also at the educational level, and if the language can help, that’s even better.

 

Martin

Yes.

 

Jan

We taught generations of kids to use all of these design patterns, but they’re not always necessary and using them when they’re not needed makes the software harder to understand.

 

Martin

Yes, of course. That’s the problem, we don’t really have a good measure of complexity. Complexity is a very subjective thing. I believe people have a natural tendency to go for more complexity, sometimes for very selfish reasons: if you do something complex it makes you look more important. If it’s simple, people will look down on you and say “anybody could have done that”, but not if it’s complex.

I think there’s a drive to do complexity, and in traditional engineering sciences you often have a counter drive, which is cost, which can deter people from complexity because it can be really expensive, but in software we don’t have that problem so much.

 

Jan

I agree, also we teach kids to engineer for reusability, but that’s essentially pushing them towards overengineering their system, simply because they don’t know how it will be reused. Then they will put many ways to parameterize it which perhaps may never be used, or used once and for just that once you didn’t need all of that machinery.

I have a last question related to those boundaries: if we take the point of view of PhD or graduate students coming to a large project that has a big implementation component (which is certainly the case of Scala, but I’ve done similar things with Java Virtual machines), what is the contract that a student gets when they start on that project? Often we say, “You’re here to do research, you’ll publish, you’ll publish.” If you have an implementation component, it’s not as simple. Its not the same as being able to do what you want, do the research you want, because you have to also contribute to the infrastructure. So from the point of view of students, how do you see that? Did it affect their trajectories? Was it positive?

 

Martin

Yeah, it’s definitely a challenge. In my group, the most students choose to join a group they self-select. I think we got a fair share of students who joined the group, because we do practical work, because we do large scale implementation work, which they were very happy to get into.

We also have other students who were more theoretically inclined and excelling in theory, and that’s also okay. So, essentially we had all sorts of student profiles, not everybody contributed to the code base in any large way. There are some tasks which are shared, but they are often very lightweight. Some students are more implementation-based and can be trusted with the core parts of the compiler, while other students are more focused on their project, then when they help out, they do things which are maybe not as core, and some stick much more to the theory side. I think the real challenge is for the students who are more on the implementation side to also publish enough to finish. So that’s definitely a struggle to some degree so far.

 

Jan

You alluded to this when you were talking about your own thesis. I think you mentioned that you had to find something that was theoretical enough within the Niklaus Wirth sphere that could be a thesis topic. I think that’s always true, right?

 

Martin

Yes.

 

Jan

It’s one of the challenges of being more applied. From what I have heard of your students, they have all found good jobs. So it’s not at all that it has hindered them, but it is something that I often wonder: are students aware when they start working on a big project that it will have an impact on what kind of research they get to do? Do you have conversations with them about this or do they just self-select?

 

Martin

I explain to them how with this lab is different compared to other groups. I let them know that their work will most likely have a really big impact, and with impact comes responsibility. So, they will have to work harder on the actual implementation that they might expect. But on the other hand, afterwards there are so many more people using this their work from this which translates, of course, into job prospects.

 

Jan

Job prospects, absolutely. And I know quite a few have stayed with Scala and that’s definitely a sign that they were happy with the experience, right?

 

Martin

Yes.

 

Jan

So, to close this interview, we do this Proust-like questionnaire. So the idea is very short answers to funny questions. So if you’re okay with this lets go ahead.

 

What do you think you would be doing if you were not involved in programming languages?

 

Martin

I would probably be retired by now because I would have been an engineer in a company where my stock options would be super high by now and I would probably be somewhere on the beach.

 

Jan

Honestly, I can’t imagine being on the beach for years. So how old were you when you wrote code for the first time?

 

Martin

I was quite old. I was 19, I guess it was at the University and it was in ALGOL 60. It was the introductory course for mathematics students. I studied mathematics and we fed the computer ALGOL 60 with paper tape for teletypes. It was things like polynomial evaluation etc. At the time, I didn’t find programming very fascinating, I have to say from this first course, it was pretty brutal. Then I was an exchange student in Oxford the year after in 1980, and there we programmed in BASIC on a shared mini computer with actually a screen and a keyboard, and I think that was the event that hooked me finally. But I knew that I didn’t want to continue in BASIC – that’s how I got into compilers and programming languages.

 

Jan

Okay, what software project would you have loved to be part of other than Scala?

 

Martin

I suppose when I read about it I would say Smalltalk, I guess that sounded completely fascinating.

 

Jan

What do you think is the most important quality for somebody in our line of work?

 

Martin

Creativity and persistence.

 

Jan

I agree that one or the other is not enough. What do you think is your most important flaw that you have, if you have one?

 

Martin

By nature, I’m not very exact. So in the early days of, let’s say computing with C++ or LaTex, by now, both are probably much better than they were then. But I found that I never really got the hang of using them, because there were too many silly mistakes you could make and I was making them all the time because I didn’t really have the self-discipline to eradicate mistakes. So, in a sense it’s better now because I think software is more forgiving, and there are back buttons and things like that for everything, but initially it was very difficult that way. People who were sort of more exact, more precise definitely progressed faster.

 

Jan

So, now you’re building tools for people to prevent those mistakes.

 

Martin

Yes, of course, that’s right. It’s part of the motivation to say if you make mistakes too often, then try to find a way to make them impossible.

 

Jan

If there was one language you wish never existed, or that you could erase from the planet, which language would you choose?

 

Jan

Oh my God, I don’t know.  I don’t think I have any antipathy towards any languages.

 

Jan

They’re all tools.

 

Martin

Yes, they’re all tools.

 

Jan

There’s not one that you had to use that you felt like, ‘God, why?’

Martin

Well, I guess when I was at IBM, I briefly used C++ and I found it at the time thoroughly frustrating because it was so brutally showing my inadequacy. I was not getting anything done with that language, but that was the only one.

 

Jan

And the last question is what would you like to be remembered for?

 

Martin

That’s difficult. I don’t really know.

 

Jan

I mean, Scala wouldn’t be bad.

 

Martin

Sure, but it’s so obvious.

 

Martin

I think I would like to be remembered as someone who showed that programming languages as a research field could have applications in industrial programming.

 

Jan

I think that out of the people that I know, there’s a few people who have straddled these two boundaries as well as you have. Some of the work is really foundational, which is proved in the papers you’ve published. And then on the other hand, you’ve built actual compilers and there are very few people who can do both of these things.

Well, thank you very much Martin, it’s been wonderful to chat and thanks a lot for your time.

 

Martin

Thanks! It was great to chat.