Conventions

• There are so many syntax variations and conventions that the sheer number of syntax options available can be intimidating. Settle on your own conventions.

• Find a way of doing things that works for your team and stick to it. Avoid context switching between syntax modes to start with. That might mean using pattern matching rather than using map to start with. Wait until everyone is comfortable before switching over.

• Review these choices regularly as you don’t want to be held back once you’re up and running.

• Have a look at Twitter’s efforts¹ as an example. They’ve managed to condense their experiences into a really practical guide. Well worth a read.

• Typesafe have a style guide,² which is worth reading over but should be taken with a pinch of salt.

What to Avoid

It’s also great to know what to avoid when you’re first starting out. I wish I knew some of these things before I started.

• SBT can make your life harder. SBT starts off very simple but, if you want to do anything sophisticated, it gets fairly taxing. Be prepared to do some learning; SBT isn’t something that you can get very far with by cutting and pasting examples from the internet. You do actually need some understanding. I think you’ll have bigger things to worry about so my suggestion is to stick with a build tool that you’re familiar with to start with. It’s very easy to support Scala projects in Maven.

• Scalaz is not the place to start. This is the Haskell programmer’s library for Scala. It’s hardcore and if you’ve not been doing purely functional programming for years, just plain avoid it. You don’t need to know what an applicative functor is or why you’d use a Kleisli. At least, not to start with.

• “Fancy” Scala libraries might not help. When Scala first came out, a bunch of open source libraries hit the web. People got carried away and in hindsight would probably admit they went a little overboard with the syntax. As a result, there are lots of APIs that were not designed very well.

  • Dispatch HTTP library is a good example. The method to add a query parameter to a request is <<?. That just doesn’t read as intuitively as addRequestParameter. In fairness, Dispatch offers both variants but the upshot is to be skeptical of libraries that overuse operator overloading.

  • Anorm is another one that offers a parser API to extract SQL results. It basically parses ResultSets but it has such an unintuitive DSL for doing so it makes you wonder what was wrong with doing it manually.

• Java libraries work just fine. You can always use the Java libraries you know and love from Scala.

• Lack of consistency is dangerous. We’ve already touched on this: don’t try and use all the syntax variations at once. Figure out one properly before moving on. Keep things consistent.

Other Challenges

You’ll face plenty of other challenges .

• Compilation speed is slow. It may or may not be something that concerns you but be aware: it’s unlikely to match Java’s speed anytime soon. In part, this is due to just how sophisticated the Scala compiler is; it does a lot of work and that comes at a price.

• Keeping your IDE build configuration in sync with your external build tool can be a challenge. Maven is so mature now that its IDE plugins pretty much handle everything for you, but the SBT plugin for IDEA on the other hand has some problems. There are third-party tools that generate IDE project files but your mileage may vary. The best I can offer is to pick the tools that seem to have the most weight behind them for your IDE.

• We’ve already talked about the functional programming continuum but it’s worth mentioning again that it’s a good idea to be mindful of where you want to be. I recommend aiming for “Functional in the small, OO in the large” to start. You’ll need to continually monitor your progress and embrace the next learning challenge when you feel ready. Push the boundaries and keep learning.