After Dianne Marsh’s OSCON presentation on Sneaking Scala Through the Back Door, we were eager for her to share those best practices with our community. Before Dianne became Director of Engineering for Cloud Tools at Netflix, she owned a software consulting company and she has been a Scala advocate for some time now (she and Bruce Eckel co-wrote Atomic Scala). Her consulting experience gave her significant opportunity to practice the art of integrating new technology into an organization. Below, she reflects on “Do’s” and “Don’ts” for introducing Scala.
Typesafe: What is your background in programming languages? When did you start learning Scala and why?
Dianne Marsh: I started experimenting with Scala around 2007. I was in search of a “better Java” and came upon Scala. Type inference was a pretty big draw for me and I was intrigued by functional programming concepts. I had always appreciated algorithms in the Standard Template Language (with C++) and had always been disappointed that there wasn’t an analogous language feature in Java. Functional programming satisfies that need for me.
TS: What are some of the challenges you encountered learning Scala? What was your experience learning the functional elements of the language?
DM: The early adopters of Scala were very generous with comments and suggestions, which is great, but also intimidating. They also tend to like to expose “cool” parts of the language, where sometimes cool means “terse.” I suffered a bit reading some of the perl-like Syntax, and really appreciated some verbosity in my Scala.
When we first started writing Atomic Scala, we considered breaking it into 2 volumes: Object-oriented and functional. As we progressed through the book, we realized that was *our* bias, and that we were sending the wrong message that functional is harder than object-oriented, only because we learned object-oriented programming first. We backed off and realized that the object-oriented and functional aspects are characteristics of the language, and new programmers may not have that same bias, so we backed away from that early idea.
TS: How is Netflix using Scala?
DM: I can’t speak for Netflix as a whole. The freedom and responsibility culture at Netflix means that individual teams are free to decide what programming languages they use, and are responsible for integrating them into the larger environment. My team uses a variety of languages, including Groovy, Python, Java, and Scala.
TS: You recently presented at OSCON, Sneaking Scala Through the Back Door - can you share some helpful tips from this talk?
DM: An entire generation of developers have used only one language, to date, in their careers. This has not been the case in the past. Our developers are out of practice learning new languages, so be aware of that. Speak to the business value of bringing in a new language in order to convince them to put forth the effort and for management to accept the risk in light of those advantages. There are many ways to bring Scala into your organization. You can use it in non-production code (testing, internal apps) until your team feels productive. But mostly -- don’t be pedantic about the language. Let your team grow functional programming skills naturally, with the language, rather than forcing it. If you insist on functional perfection, you may frustrate your team and squash their enthusiasm. And while “writing C code using a C++ compiler” was a harsh criticism 20 years ago, writing Java-like code in Scala is still better than writing Java!
TS: In your talk you mentioned leveraging existing Java code - for those not present at your talk, could you expand?
DM: There’s a wealth of JVM libraries out there, and you probably have existing Java resources. Build thin wrappers on top of your Java code or call directly from your Scala. Resist the urge to rewrite all of your Java code in Scala. Much of that code may never be needed -- don’t waste your programming time!
TS: Since getting feedback on the contentious parts of your presentation, will you change anything before you present it again?
DM: At the end of the talk, I invited others to describe bringing Scala into their environments. Their input ranged from, “I reached too far and had to back off” to “Don’t ask, don’t tell.” Their interaction was quite enjoyable. I really love Open Spaces conferences and I think that it would have been great for the entire talk to be more collaborative, leaning on the collective knowledge of the group!
TS: We recently interviewed Bruce Eckel on the Atomic Scala book and organizing tech conferences... What inspired you to write a book with Bruce?
DM: I was frustrated by the seemingly constant messaging that “Scala is hard” and convinced that programmers were just out of practice of learning new programming languages. I approached Bruce for his advice and, to my surprise, he suggested that we write the book together! It was an amazing experience, as Bruce is great at explaining things, and we both settled into the idea that we wanted a book with “no forward references” and “no Java prerequisite.” I think that the book met our goal of expressing the simplicity yet expressiveness of the language.
TS: Thanks Dianne for your time! For anyone who needs help getting Scala into their organization, don’t hesitate to reach out to us for help!
