I think of Scala as a swimming pool; there is a deep end and a shallow end, it seems that many people who haven’t learned to swim yet jump straight into the deep end. Inevitably, after splashing about for a while are surprised to find that their legs don’t quite reach the floor, or that they sank to the bottom and are startled by not being able to breathe under water.

This is a decent metaphor.

Avoid the SBT

What? No. That is not avoiding the deep end, it is avoiding the pool. Almost every Scala open-source project worth using is built with sbt. If you refuse to use sbt, you can not contribute fixes, enhancements, or tests to any of them.

For example, to make my project a web project, I first had to add a plug-in dependency like this in plugins.sbt …

Listen, it’s not 1997. There are ways to write web applications that don’t require a servlet container. But if you wish to use a servlet container, you could start with a template project. That’s what we make them for.

This made me puke a little bit in my mouth…

“Meh.”

4 . Avoid libraries that overuse “operator overloading”

This is going to be fun.

But sometimes you may have no good choice of a library that doesn’t overuse symbols. Although I wrote a HTTP client wrapper for Scala that is mostly symbol-free (except for / and ? for constructing URLs)

For a second I thought there was a principle here.

it was mainly for my own use and I haven’t maintained it properly.

There’s the rub.

On the other hand, Databinder Dispatch, which does use symbols a bit much (as seen from the periodic table above), is quite well maintained.

They said the same thing about chemistry.

~~~

I don’t actually care about the linked post very much one way or the other. It is a regrettable attempt to attract attention by courting controversy, without offering new information. My hopes were high with the pool metaphor, but then the swimming advice was something like “wear a helmet”.

If I have a warning to Scala beginners, it’s to use libraries that are reliably cross-published if they ever plan on upgrading the library or the language. (Cross-publishing is a key feature of sbt, so you know.) With libraries that are only published for one version of Scala, you may have to upgrade your Scala version to get fixes or features in the library, or upgrade the library to get fixes or features in Scala. That would be acceptable if upgrades never introduced bugs of their own.

And if people want to pontificate about Dispatch, they could at least be up to date. I went to some trouble to write about the future of the library in this three-part series { 1, 2, 3 } and practically nobody read it. Why? There was no bullshit controversy.

Since nobody uses RSS or reads boring old “lots of words” posts on tumblr, the only remaining distribution mechanism is to write something silly and hope everybody links to you from their personal shouty stumps. This is most effective if popular convictions are uplifted or ridiculed, and you simply can not go wrong by declaring that a particular departure from convention goes too far or not far enough. The only thing you will fail to do, with such empty debate, is change minds.

Now. If your hunger for polemic is sated and you have a more than superficial interest in Scala library design, allow me to refer you to a series I once composed on the subject…