In his talk “Scala best practices I wish someone’d told me about” he is putting “the worst offenders” in the spotlight in order to help Scala developers save time and pain. In advance of the talk, we spoke to Nicolas about his 20-year developer career, what frustrated him most in his work and how he started working in Scala on a dare.
What’s your background and what does your current role involve?
I’ve been a developer for about 20 years now, in fields that range from security and network monitoring to writing and designing video games for large brands.
About 10 years ago, my best friend and I started a machine learning business, ioSquare, which was recently bought by Besedo, an online community moderation company. I’ve been leading Besedo’s developments since then.
My current position has two main areas of responsibilities: specifying and implementing new features in a microservice based moderation platform, and taking 3 teams with widely diverse backgrounds, cultures and technical choices and attempting to unify processes and development practices.
Needless to say, teaching Scala to teams whose main experience is either node.js or the most enterprisey side of Java is an interesting experience.
What’s the biggest highlight of your career so far?
Does “being invited to talk about Scala at Scala Days” count?
This is a tough question. From a purely technical perspective, the thing I’m proudest of is probably my open source work (I’ve a couple of Scala libraries to my name, and a Java midnight commander clone that had a moment of fame years ago).
From a personal perspective, it’s got to be the various people I’ve met, worked with an mentored through the years, and seeing them grow into their skills.
Why did you choose Scala and what kind of problems does it solve for you?
After years of using more mainstream languages (C++, Java, PHP…), I was growing bored with what felt like doing the same thing over and over again, and being frustrated by the same issues again and again. Runtime magic, verbosity, limitations inherent to subtyping polymorphism…
I started Scala almost on a dare – a friend told me that Scala would solve all these issues for me, but that it was a language that was almost impossible to learn. Hard to resist a challenge like that.
Years later, I moved our company’s entire stack to Scala, wrote mildly popular open source libraries in Scala, gave talks at meetups and conferences about Scala, and am part of the team organising the Paris scala meetups… so I guess it kind of took off.
The problems that Scala explicitly solves for me are:
- far less runtime magic thanks to a sane type system
- far less verbosity and duplicated code (although I feel we could go further in that direction)
- I didn’t know type classes were something I needed, but I did so, so bad.
- Scala is making programming fun again for me
- gateway drug to a lot of powerful tools (property based testing, powerful abstractions, refined types…) that I had no idea existed before
What’s the most important challenge that Scala developers are facing today?
I’d say it’s being pushed further and further on the complexity scale before having had the time to master the basics. There’s a wealth of resources on, say, final encoding, but very little on how to represent data in a way that makes illegal state impossible to represent.
In a way, it makes sense – the people who take the time to write or talk about Scala on their own time are the true believers, the people who tend to try and push the language as far as it will go without breaking (and often beyond that).
But I do feel developers should be encouraged to spend more time becoming comfortable with down-to-earth, “boring” features of the language (implicit resolution rules, say, or by-name arguments) before they tackle the really edgy stuff. It’ll take the magic away, which is a good thing – magic is great while it works, but true understanding is the only way to handle things going wrong.
What’s one thing that could address this challenge?
Honestly not sure. Possibly some sort of learning guide? “If you want to learn about C, you need to be comfortable with A and B before”?
I can see that being a nightmare to maintain, but it’s certainly something that, if done well, I’d use extensively.
Who should attend your talk at Scala Days and why?
The talk is intended for people without a lot of Scala experience – most of the points I tackle are, by now, well known and understood by people with a few years behind their belt.
That being said, I’ve had positive feedback from people with more experience than I’m targeting – a large chunk of the Scala community apparently follows some of the best practices I outline because someone, someday, told them that this was the Scala way, without explaining why. This talks attempts to do just that.
Whom would you like to connect with at the conference?
Oh man where to begin. Everyone! Mostly though, the people whose tools, talks or articles have helped me make breakthroughs in my learnings. The Rob Norris-es and Noel Welsh-es of the community.
I just hope they don’t come to my talk or everyone’s going to be in for a disappointing time as I freeze up completely for the duration.