Interesting Twitter discussion over Scala macros sparks further debate about the pros and cons of the statically type-checked language
The Scala community is not exactly averse to debate about the benefits and the drawbacks of the language. We’ve seen some Java fanatics speak out about the direction of the language (maybe as a safeguard against their own) but now a new argument has arisen effectively out of a Twitter discussion from three developers with a vested interest in Scala’s ascent.
Coda Hale at Yammer, Twitter‘s Stu Hook and Ted Nyman at (Bank) Simple got talking about Scala’s move towards refining macros. All three work for companies writing production-level Scala code, so all can be considered well-versed with the language. Despite what the TIOBE index may tell you, Scala has made the transition from undercurrent ‘better than Java’ language to a viable option that is attracting enterprises to the dance, through its speed and concise, statically-typed nature.
But alongside all the golden attributes, there’s one problem as Nyman alludes to – it still has this sort of self-centered mentality choosing to focus on linguistic intracicies rather than the bigger picture.
In steps another Scala specialist, LinkedIn’s Jay Kreps with his article “Scala Macros ‘Oh God Why?‘”making a pretty balanced and convincing argument about what Scala is doing right and more importantly, what it is doing wrong.
I think the Scala folks have done a good job of putting together something that is significantly better than Java as a language. It’s fast, concise, statically type-checked, and inherits a lot of the good operational properties of the JVM. But languages aren’t just, well, languages; and they aren’t even runtime environments for that matter. They are platforms and tool chains and libraries and bodies of documentation, and cultures, and practices. And here Scala does not yet do so well.
Nail on the head much? Scala may well be the expert craftsmen’s language of choice, but Scala is lagging behind in creating a self-facilitating ecosystem that provides all the other aspects needed to take off, which Kreps touches upon referring to Scala’s documentation as ’pretty impenetrable. Unlike Java, type signatures in Scala don’t really explain idiomatic usage to mortals very well. Needless to say, the docs don’t have anything so pedestrian as examples.’
Now, granted, Java’s had way more time to do that and has made mistakes along the way. It’s a pretty steep learning curve. Scala Macros isn’t a bad idea – but is it the real problem at this point in development? Yes, we’ve seen the gripes previously, (Kreps provides a list of them for those who missed it).
I still think using Scala was a good decision for a hard, stand-alone piece of software like this, and I am glad we did. Scala fixes all kinds of nastiness in the Java language.
But it isn’t all roses, Scala has all kinds of gaps everywhere else. You end up with very pretty code, but gobs of practical annoyances in trying to write that code. The strong hope I have is that the Scala folks will focus on fixing these bread and butter issues, and those of us who just want to use programming languages will be left with something that is a better all around developer experience.
The excellent blogpost wound its way round Twitter and on Hacker News, instigating further talk of all things Scala. We think balancing innovation and making it useable to all is an incredibly difficult juggling task – and maybe not one Scala has handled that well. It’s not alone in that case in programming history though. Fixing the little problems has to be done at some point: the longer it’s left, the longer the climb Scala will have to take to assume its stance amongst the most popular languages.
Do you think the Scala community is focusing on the important issues or not? Comment below…