Lance Walton on Scala in the Enterprise

1. We’re here at Scala Days 2012 in London and I’m sitting here with Lance Walton; so Lance, who are you?

I am Lance Walton. I work with Underscore Consulting.

2. What’s Underscore Consulting?

It’s a partnership that’s been set up by five companies to serve the needs of Scala developers and organizations in London who want to train and consult in Scala.

3. So what are the needs of people with Scala?

There are a lot of organizations getting into Scala now. We see a lot of investment banks becoming interested in Scala and a lot of developers need training and so on and we have capability of providing training as well as putting people in place to help with teams when they adopt Scala and you know, the first project for people, just to help them along with the Scala implementations.

4. So you see problems with Scala, are you coming in when people already have a Scala code base or are you trying to say, "Scala can solve your problems better."

At the moment we’re seeing mostly greenfield projects because Scala is a relatively new thing; but of course there's also the migration from Java to Scala; so sometimes we’re seeing existing Java code bases that people want to migrate and people need to understand the right path to follow, a good to follow with that.

5. So in your experience, what are the big problem of Scala today; what are the points that people struggle with? Is it the Monads? Is it the Applicatives? Is it just Lambdas?

I think it depends, you know, a lot of developers would come up from the Java side of things are not familiar with the functional programming world; so they will struggle initially with even things like mapping, filtering and that kind of thing but those things are relatively easy to take care of. Suddenly you got the whole world of Monads, Functors, and stuff like that it’s still opaque to a lot of people; not hard just needs to be explained in a way that people can understand and so on but also there are certain aspects of Scala’s type system which is new to most people, Martin’s done a lot of work on that and there are aspects of it which people need to find their way with and need to find the patterns.

6. You mean usage patterns or just understanding error messages?

Usage patterns, a good example is the Cake pattern; the people look at it and think it's complicated and actually it’s not, but because of the way that the type system is used, to achieve that pattern that a lot of people do find it hard when they first look at it.

7. So the Cake pattern is a Dependency Injection pattern?

Lance Walton: Yes.

Werner Schuster: So how does it work, or what does it use?

Lance Walton: It uses a couple of things like the fact that nested types are owned by the instance rather than by the enclosing type and self-typing, for example, is another aspect of Scala which isn’t in Java which you need to be aware of with the Cake pattern and you need to understand how those two things combine to achieve the injection effect that Cake does.

8. So Scala is a hybrid language , I think it’s fair to say, OOP and functional programming? Is that an issue because people have multiple ways of solving problems?

I don’t think so; people have always had multiple ways of solving problems in Java, there's a tendency in some organization or for some people to just use a very imperative programming styles, very procedural styles; and sometimes that makes sense, you know, if you’re coming from a world where you're if you’re transferring data from a database and putting it on screen and then editing and putting it back, that may make sense.

You know, other people will take more of an interest in the object-oriented world and you know, functional programming is one more string to the bow really and the way that they’d been combined in Scala is very clean and very pleasant to work with, you don't really notice the seam between the two; whereas previous attempts to combine the two, you sort of do notice a little bit of fragmentation or you notice the language is designed as an object language and then functional concepts would be bolted on or the other way around and always seems that one has a poor relationship with the other; but in Scala, they seemed to be combined with equal weight and with good effect.

So I think that people will learn to use the functional programming stuff just as you know, they’ll start by doing, for example, migrating Java to Scala in a fairly crude way and then they’ll just start using the functional stuff and learning about it and extending.

In the same the way as 15 years ago, people probably found words like 'polymorphic' difficult to grasp; in ten years’ time, people will be talking about Monads and Monoids and all these things in the same way without worrying about it.

9. So it’s basically about a generation change?

Lance Walton: Yes, I think so.

Werner Schuster: ...wait for the old folks to die off?

Lance Walton: Yes.

Werner Schuster:... all the 30 year olds.

Lance Walton: Yes, I might be one of the old folks, I don’t want to put that out there.

Werner Schuster: You’re an elder and you can teach them.

Lance Walton: Sure.

10. You mentioned you work in London in the City presumably with enterprise companies; there's been criticism about Scala's viability [in that domain], due to problems with binary compatibility and things like that. Do you have an answer for these problems or do you just have to solve them in some way?

I think you do , with a lot of the organizations I work with, they’re quite conservative anyway, and the fact that we’re seeing this drift toward Scala now is a good thing. What I suspect will happen is they’ll settle on a version of Scala and stick with it for quite a while.

You know there are still some investment banks, for example, that are using JDK 1.5 and haven’t yet moved to 1.6 or 7.

So I think we’ll see the same thing with Scala that people will just stick with a version for quite a long time and then upgrade and take the hit; or even sometimes projects just have outlived their usefulness or the code base has outlived its usefulness and then a rewrite happens and then they will adopt and pick a new language; but right now we're at a place where really it’s individual groups within banks are doing work. There are a couple of banks which have decided on mass adoption but mostly it’s individual teams have said, "We’re going to use Scala for this," and have managed to sort of run the gauntlet.

They’ll probably deal with those issues because they are early adopters and they will just deal with them as a natural by-product of doing what they do.

So I don’t think it’s a big issue really.

11. So the solution will be to stick with one version of Scala?

Lance Walton: My tendency is actually to upgrade and just deal with the binary compatibility issues.

Werner Schuster: ...to make it a clean break.

Lance Walton: Yes, exactly, I think that’s a good thing. I mean languages stagnate because of backwards compatibility and all that kind of thing; making the choice to break that compatibility is a brave one and I think a good one.

12. So what’s the tool support for Scala, in particular with what we’d just talked about keeping the past alive?

This is one aspect where developers have a lot of high expectations of tool support these days; and when I started programming, it very much was vi at university and in my first job. So I’m used to working without IDE support and refactorings were done by hand and so younger developers sort of expect Eclipse or IntelliJ Java IDE, out with the language as it appear and the major IDEs are behind Java; but again that will come with time, the way to deal with it is for people to get involved in the initiatives and to submit bugs and to ask for things and the IDE vendors will provide a few years we’re talking about but the fact now that you, for example, I'm talking about IDEs rather the rest of the tools, but the fact that now, for example, you don’t have to write so much codes in Scala as you would in Java means that the need for an IDE is less, I think; the fact that you can express yourself far more concisely and clearly in Scala means that you don’t need as advanced tools.

It has been noted that the massive of code generation that’s done by the IDEs is probably actually a failing of the language in some sense, that fact that you can generate boiler plate like that is an indication that language is more verbose than it needs to be.

13. So obviously Scala is adding features with every release. So what is the one feature, or, maybe two features that you’re looking forward to?

Macros definitely, I very much admired Scheme's macros a few years ago and have wanted them in a language ever since. I’m not entirely sure I know what to do with them once I got them, having said that but it’s one of those thing that I think you’ll spot the opportunities once they’re there, you know, and there are a few places where they're obvious use. But definitely I’m interested in seeing Macros.

There is still a lot for me personally to explore in Scala as it is; you know, there are parts of the type system which I still don’t understand and want to know more about unfortunately there are other people at Underscore who do have that understanding who can convey it but Macros are definitely the thing I’m looking forward to next.

14. So you’re thinking basically of proper Macros, not C Macros?

Yes hygienic macros. I did C for quite a while and suffered from the C style Macros and decided I don’t want to see those again.

15. A text-based preprocessor is never a good thing, particularly IDE developers hate it for obvious reasons.

Yes, well there’s various things that IDE developers are going to hate about Scala Compiler plug-ins, for example, will present challenges to certain types of IDE that aren't there in Java, for example, but these are bright people, they’ll solve these problems and that I definitely don’t want to see C style Macros in a programming language ever again

16. Let’s hope so. So to wrap up, special Scala Days question, Lance Walton, describe yourself as a Monad please.

A lot of the history that I’ve had over the past 15 years been involved in the Agile methods community as well and one thing we like to do in Agile methods is keep choices available to ourselves, so I think it would have to be Option.