Conference junkie Ted Neward explains to Mark Hazell why he as a Java developer finds value in learning Scala, which has been designed from the ground up to be a functional language. The pair also discuss the Typesafe/Lightbend rebrand and why it benefits the company to change its name, the extraordinary power of pattern matching in Scala, and things Java devs need to let go of to succeed with the language. Filmed at Voxxed Days Vienna. Read the transcript, or scroll down for the video interview.
Voxxed: Yesterday you spoke about ‘The Busy Java Developer’s Guide to Scala: The Basics.’ You’re a Java developer – why bother with Scala?
Neward: I suppose it’s on the same lines as understanding new ideas, new patterns, new idioms, new approaches, etc. Particularly with Java 8 and the introduction of functional rules – lambdas, closures, lots of different things.
There’s a style of programming that a lot of people who are used to classic OO [object-oriented] programming won’t have seen, and this is the functional style of programming. How do I take things and run them through functions as opposed to marrying state and behaviour together in an object?
And as a result, if you’ve been looking at Scala – because Scala’s been out since 2005 or so – if you’ve been working with this language up until this point, if you look at Java 8, you look at the Streams API, you know instantly what to do with it. You know how to use it. You understand things like Map and Filter and all that kind of stuff. If you haven’t, it twists your mind around in some really weird ways.
And, in Scala, no offence to Java, no offence to Brian Goetz – I know that he is trying very hard with the language he has inherited – but Scala was designed from the ground up to be a functional language. A functional object hybrid. And so it’s kind of the same the thing as, why would you go visit another country? You go learn different cultures. You learn different ways of doing things.
Going back to yesterday’s session, the basics – talk us through a little of what you introduced in the session.
Basics means basics man. So really the intent was to give people enough of a leg up – what am I looking at, what am I wrestling with? The idea that Scala, for example, favours expressions over statements, so most of the constructs in Scala will yield a value – if-else is a statement in Java, in Scala it’s an expression. So if I say, if-a, it’s going to have to return some sort of value, which you can then assign to the idea of immutability. The idea that Scala is still resting on top of the Java type system, so it’s all the same byte code that we’re familiar with, but the Scala compiler is actually much smarter than the Java compiler, and as a result, in many cases, you can just let Scala tell you what’s supposed to happen and worry less about the physical details of your code, and think more at a higher abstraction level. That’s a large part of what the Scala developers – Martin Odersky and Jonas Boner, and some of the other developers at Typesafe – now Lightbend – thanks for that by the way guys…
…What do you think about the name change? Have you got an opinion on it?
I think in some respects, it’s a necessary change, because I don’t think Typesafe was a great name to begin with, to be very blunt. I think it pigeonholed them too much as a functional language company as opposed to, if you look at them, they’ve been slowly growing the ecosystem that they’re interested in – Play and Spark, and all this other good stuff – so I think it’s important for them, because it helps them establish more of an, I hate to say it, a non-functional name.
At the same time, it’s annoying, because they’ve spent so much time building up the Typesafe brand, and now they’re going to have to transform that into the Lightbend brand. But at the same time, the jokes they just keep on coming; “Scala lets you bend light, it lets you change the laws of physics!” Which of course, that’s a jokes that’s going to keep on giving for months and years to come.
So aside from ignoring that joke, say a Java developer says, “I’m kind of interested in Scala, I’m going to check some stuff out”…have you got any advice for them to leave at the door?
One piece of advice I gave in the session is that there are a lot of syntactic constructs in Scala that look like Java, but they’re not.
The one that I really focused on, which Twitter picked up, was the notion of the for loop in Scala. It’s not really a for loop – it’s a for comprehension, is the term they use, and it’s actually a different creature entirely from what we’re used to in Java. The other thing that I think a lot of people coming from Java, coming into Scala, will find very powerful is pattern matching. It kind of on the surface looks like a switch case, but that’s kind of like saying a kitten looks like a T-Rex.
There’s a huge order of magnitude more power in pattern matching, to the point where, if you took away every other control construct from me, and just left me with pattern matching, I’d be OK. Because, it can do fls, it can do all this other decision making, etc, etc. It’s an extraordinarily powerful construct.
The last thing you probably need to do is let go of some of the obsessive desire that Java developers have around the physical construction of their code…You shouldn’t really have to worry about some of the physical details, as long as it all works. And so, a Java developer is going to have to, to quote Yoda – which is always a good one to quote – “Unlearn you must.”
There’s going to be certain habits, certain ways in which we Java developers approach things that we may have to leave behind, at least for a short period of time, and sort of experiment with the REPL. Go in and write some code, experiment interactively, and say, “OK, that does what I want it to do,” save off the transcript, clean it up, and that’s what we now compile and ship. It’s a very different way of working to what Java developers are used to.
So there’s a new type of fanaticism to learn?
Well…it is functional programming, and you have to say monad at least three times, or you’re not a real functional programmer.