The obsession with building a better screwdriver

I was ever so excited to join a team working on a major Scala codebase for a suite of in-house reporting tools. My only experience with the language up to that point were self-study, hobby projects and a Coursera course. Two years on and I am mainly doing Java again, at my own request I might add. Has the love affair reached its end? Not entirely, but it has cooled.

There is a pretty big gap between the conceptual soundness of a language and the grim reality of building working software with it. However well designed, it can never be a joy to work in without a stable and extensive support system, starting with the IDE through to testing frameworks, proofing tools, etc. No JVM language can match the range and maturity of the tooling we have for Java, especially when you go beyond mere IDE support.

I am still a big fan of Kotlin, another serious contender. As developers we may sing their praise, but Scala and Kotlin cannot bring the gains in speed or quality that are big enough to justify the temporary productivity loss while the team is re-trained, let alone warrant rewriting an entire code base. If it did they would have taken the world by storm, which they clearly haven’t. The adoption must be evolutionary.

That’s why I cannot muster the same level of enthusiasm for languages, tools and frameworks that I can feel for a finished product – or a piece of well-written code, in whatever language.

When I attended the three-day Scala World conference in 2019 I saw 300 people in love with their language. I sensed it in the keynote presentations about Fury and Zio, a new build framework and concurrency library, respectively. I am in no way disparaging the drive with which John Pretty and John de Goes tried to win the favour of the auditorium, but we were looking at early versions of tools that basically did something you could already do in Scala, just radically different this time.

You can innovate by improving upon what is already out there or rebuild it on fresh principles. Take a wild guess as to what developers find more fun… The efforts to redo the Scala support system come from the same motivation that started Scala and Kotlin in the first place: you’re not able/willing/allowed to improve on […], so instead of making it better you make it new and end up with an even bigger toolbox.

No cook can make a fine meal without her kitchen and utensils, but neither can she do so without her knowledge of ingredients, cooking techniques and her skillful handling of the fancy tools of the trade. Software is no different. You apply your skills to arrive at a product, using the best tools for the job. Scala may be the right tool, but it’s just a tool.