Using Scala at the BBC — Q&A
👍 For news and articles from Skills Matter, subscribe to our newsletter here.
Tiffany Vitti from Skills Matter sits down to talk with Phoebe Greig and Duncan Walker from the BBC about their experience using Scala within their roles as software engineers.
Phoebe Greig is a Full Stack, React, Node, Scala engineer at the BBC, Co-Founder of Women Driven Development & Co-Director of Lesbians Who Tech London. Follow her Twitter or on GitHub.
Duncan Walker is a Senior Software Engineer at the BBC, follow him on Twitter and GitHub.
Tiffany: Thanks for sitting down with me guys! So, what is your background with Scala?
Phoebe: We were just talking about it yesterday, how before I joined the team, I had never used Scala before. I had never coded in a language that was strongly typed. So when working with Scala for the first time, I thought, this is so verbose. Thus because of it, a bit tedious.
But then I got put on an epic where I got to work with Scala for three months. Now I’m predominately working back on React and instead wonder, why isn’t it more verbose? Where are the type declarations? It does make it a lot easier.
Tiffany: Did you find there was a large learning curve?
Phoebe: I didn’t think it was that hard to learn it. What I found hard was getting your project to run because of the compiling — setting up SBT in visual studio and intelliJ. I don’t use intelliJ and our team find that the best one to use for ‘Java stuff’.
Duncan: Just listening to you describe your route in — I find mine was the complete opposite. I came from Java to Scala so for me I found Scala incredibly terse in comparison to Java. You’ve already got the types but there’s less repetition in Scala, so when I look at Scala code I note how incredibly concise it is; that’s great. That may be part of the problem with the learning curve as well, as you might have a piece of Scala code that’s five lines long but in Java you might have done it as three classes each, which might be 50 lines or 100 lines of code. So Scala is dense with meaning and sometimes it can be overwhelming to look at it and think, what’s going on?
This interview is part of our deepdive into Scala development in the lead up to Scala eXchange London 2018. Check out our interview with The Guardian’s Maria-Livia Chiorean on using Scala as well as our look at the 5 major themes for Scala that have emerged as central to this year’s conference programme.
Phoebe: So, depending what your background is in sense of the language, it’ll probably impact how easy it is to read and to pick it up.
Duncan: It is incredibly expressive. There are things that you can do with implicits and almost making your own DSLs by overwriting operators where you’re able to write code that reads like a natural language, almost.
Phoebe: I think the hardest part is terminology rather than not picking up concepts or readability. When you’re pairing with someone who is a full-time Scala developer or it could be any two people who come from a different language background to use different language terminology — what they would call maps is what I would call objects in JavaScript. It wasn’t particularly hard but you had to adjust to another set of words to describe something that you knew.
Tiffany: Do you find that when you come to learn languages it helps you understand those you already know more?
Duncan: Yeah, it’s the same patterns over and over again. If you’re doing things that are more around opening files and processing texts you can write it like it’s Python and it reads like Python but in other scenarios you can write it like Java if you want, which makes it powerful to be able to do that but also dangerous because you can end up with two teams both writing in the same language in a completely different way.
Phoebe: I found that Scala helped me understand JavaScript more and vice versa. I thought that was one of the supposedly beautiful things — that it can be functional or object-oriented and you can use it in those two very different ways, so one team could write it in completely different ways and people would wonder if it was the same language.
Duncan: Exactly, because when Martin Odersky first did the Coursera course he couldn’t put up one style guide so he put up two: one more science focused and one more business focused. The science-focused one encouraged the use of variables that have simple character names because ‘you’re a scientist and you’re used to writing equations’ but reading that from a Java world you’d think nobody would want to work with you.
Phoebe: Yes, because it isn’t readable.
Tiffany: If you could ask Martin Odersky any question what would it be?
Duncan: I would be interested how he feels about the fact that JavaScript is not a well-designed language but is by far the most successful, while Scala might be perfect but adoption of it isn’t anything like JavaScript. Is it the fact that JavaScript is so limited as a language that it’s more about how you compose it than what the language does, and so is Scala’s scalability and flexibility actually a disadvantage?
I know loads of people where they’re dealing with Java and they want to use Scala but they find the investment challenging and it costs so much to hire Scala developers so hiring managers just don’t want to do it because they are hard to replace.
Phoebe: I had the opposite situation in my last job. Most were originally Java developers but the feedback I got was that if they want to move away from Java, then even with the beauty of Python, Scala is much closer to Java. From my experience, so many teams have moved to Scala because they recognise the benefits and they don’t have to completely retrain developers.
Duncan: I’m still amazed when you can copy and paste something into intelliJ and it asks whether I want to convert it to Scala and I think, of course I do!
