The latest expert opinions, articles, and guides for the Java professional.

Scala: Sink or Swim? Part 1

Disclaimer(s): ZeroTurnaround supports eliminating redeploys in Scala development with free JRebel licenses (more info). The author admits to having no Scala code in mission critical production, and would like to mention that he has lots of opinions about many things in which his expertise can be contested ;-)

Super fast intro – Why should I know about Scala?

Scala is a relatively-new, statically-typed programming language that mixes object-oriented and functional programming on the JVM. It has been getting more and more popular, because it is probably the best alternative to Java there is at the moment and has a rich type system which lets you do crazy stuff if you really want. But, as I will explain, there are some drawbacks that can detract from these benefits.

If you are a Java developer and want to get a quick intro to Scala, Daniel Spiewak wrote a good series of posts for you: Scala for Java Refugees.

Stay close to the shallow end?

There have been numerous blog posts during the past year or so that accuse Scala of being too complex or highlighting other issues with Scala adoption. Some of the criticism is fair, but I think some of it could be targeting almost any JVM language out there. Scala seems to get more of the flak because it’s more popular and possibly pulling ahead of the others (despite what TIOBE’s baffling index claims, leaving Scala out of it’s Top 50 languages for mysterious computational reasons).

And also probably because Scala actually is rather complex, but only if you want it to be.

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.

I don’t know why this happens. Maybe it is hard to distinguish the deep end from the shallow end — it’s not quite as simple as having a glance and getting a clear picture of how deep the pool is. Maybe the deep end seems more exciting at first, when you haven’t gotten a true taste of it yet.

Why am I talking about such a dichotomy in the first place?

Because the Scala community is very diverse. It can cater both to newbies and expert type-safe library designers. Some Scala users come from an object-oriented programming background (e.g. Java), some come from a functional programming background (e.g. Haskell).

Scala blends together these programming styles, but still lets you code mostly in an “impure” imperative or mostly in a “pure” functional way. And that’s the main problem, I guess — the very different coding styles enabled by Scala means that a lot of code written by people from a school outside of your own might seem downright illegible.

Each Scala team needs to find a common style that they agree upon, or the result will be a mess. The Scala Style Guide might help with this.

But let me say straight out: This post is mostly for those coming from the Java (object-oriented / imperative) school. Some of the suggestions are very much a matter of taste, background and so on, so I’m not expecting everyone to agree with it. But let’s get on with some thoughts, opinions and comments…

Opinion Time: What to avoid in the Scala ecosystem

These things may be fun to mess with and maybe you will actually find that they are useful to you, but if you are trying to adopt Scala in a team of Java programmers, these things will not help you, and I would say they might even work against you; such as finding yourself inadvertently in the deep end. Specifically, I would avoid:

  1. SBT – Simple Build Tool
  2. Scalaz
  3. Category theory
  4. Libraries that overuse “operator overloading”
  5. Collections Library Source Code
  6. The Cake Pattern
  7. The Kingdom of Verbs
  8. Too Functional or Too Type Safe Code

1. Avoid the SBT

IMHO, the so-called Simple Build Tool (SBT), sucks.

It is not so simple at all and your build descriptors will be a mishmash of a DSL that uses lots of special symbols, poorly structured meta-data, and code. For example, to make my project a web project, I first had to add a plug-in dependency like this in plugins.sbt:

libraryDependencies <+= sbtVersion(v => "com.github.siasia" %% "xsbt-web-plugin" % (v+"-0.2.9"))

And then add this magic line to build.sbt:

seq(webSettings :_*)

This made me puke a little bit in my mouth, and if it has a similar effect for you, just stick with Maven, Ant, or whatever build tool you used before that has Scala support. I use Maven for all my Scala projects and don’t have any big problems with that.

Sometimes you might be more or less forced to use SBT (e.g. if you use Play 2.0). In that case you’re kinda fracked, but maybe not too badly — SBT still has some good ideas inside it. There is hope that it will get better and better, and even support a Maven mode. But at the moment, it leaves much to be desired.

2. Avoid Scalaz
If you are thinking about using Scalaz, stop now while you still have your sanity! And don’t get into arguments with the people who suggest that you use it – it is pointless. These strangers come from a completely different school of thought that values entirely different things than you – pure functional programming with very high-level abstractions represented by obscure symbols like <:::, :::>, <+>, ★, ☆, <=<, and so on – there are HUNDREDS of these.

Also, run away if you hear anyone casually utter words like: applicative, bifunctor, cokleisli, endofunctor, kleisli, semigroup, monad, monoid. Ok, the last two are maybe not so scary, but what I’m getting at is that you should also stay away from #3… >>>

3. Avoid category theory

Category theory is an area of mathematics full of abstractions that apply to programming in interesting and sometimes useful ways, but it will not immediately help you write better programs that are easy to understand. Eventually, you might find something of use there, but maybe it’s better to stay clear of category theory until you are really really sure that you and your team wants to go there and will benefit from it (the same goes for Scalaz, above).

4. Avoid libraries that overuse “operator overloading”

Scala doesn’t have real operator overloading, as most operators are actually methods. But it allows you to use many symbols in method names. This is not bad, because it is useful in places, such as mathematical code, but some libraries take “advantage” of that feature and use easy-to-type symbols (or even not-so-easy-to-type symbols) to mean something entirely different than what those symbols commonly represent.

Again, I’ll mention Scalaz as the main culprit here, but there are many other libraries which’s authors have been a bit overly happy-go-lucky with their use of symbols in all the wrong places. SBT errs here as well, as already mentioned. Some examples:

Periodic table of dispatch operators
Using parser combinators to extract SQL query results (scroll down to “Using the Parser API”)
Applicative example in Scalaz

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), it was mainly for my own use and I haven’t maintained it properly.

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

5. Avoid the Collections Library source code

I wouldn’t suggest digging too deep into the collections library implementation. It is a breeze to use the library mostly, for example:

val (minors, adults) = people partition (_.age < 18)

But the implementation is way more complex than we’re used to in Java-land. The internal complexity pays for power, though, and is probably worth it. If you get stuck, the sources might be closer at hand than docs, but try reading some documentation anyway, before peeking into the source.

6. Avoid the Cake Pattern

When people tell you that Scala doesn’t need dependency injection frameworks because of the cake pattern, that’s poppycock (thankfully, not many people would go quite that far). Not all projects need DI, but where it has worked in Java projects, it can work just as well in Scala projects.

The cake pattern may work fine too in many cases, but it makes your code structure unnecessarily more complex, and may force you to use some of the more advanced features of the type system that you could avoid otherwise. Personally I prefer Google Guice for dependency injection, but Spring works with Scala as well.

7. Avoid getting stuck in the Kingdom of Verbs

If Java is the Kingdom of Nouns, then Scala code can sometimes look like it’s coming from the Kingdom of Verbs. You might see code like this:

Project.evaluateTask(/*args skipped*/)

To be honest, such stringing of methods can happen in Java as well, but seems less likely there. Not everything in the above snippet is technically a verb, but there is a very long chain of methods with none of the intermediate results being named.

If you look at this code without an IDE, it is nearly impossible to understand what is going on because you know neither the types nor the names of the things. Thank god point-free style doesn’t work in Scala, or it could be worse.

Just give names to some of the intermediary results, eh? In other words, your Scala code should be from the Kingdom of Sentences, where both verbs and nouns are in equal standing. It is often possible to even mimic simple natural language sentences without creating a full-blown DSL.

8. Avoid code that is either too functional, or too type safe

This is perhaps the most controversial point I’m going to make, but try not to go too much into the functional side of the language or to achieve maximal type safety. Scala can clearly give you better type safety than Java in many cases, but there is a limit to everything. The type system is complex and if you dive very deep into it, you might just spend a lot of time satisfying the compiler for little gain instead of writing useful code. I love to occasionally play with something like shapeless, but avoid doing it in serious code.

The same is with going too functional. Often it makes sense to use flatMap or map over Option values instead of if-else expressions. But writing a long chain of flatMaps without naming any intermediate results is not a good style.

Overusing higher-order functions in hot code may create performance problems. In some cases, you might even have to revert to more Java-like code with mutable variables and while loops — Scala’s for loops are compiled to higher-order function calls, but while loops are low-level as in Java or C.

Still, functional programming is getting more and more popular for a reason. Concurrency and correctness might be easier to achieve with more functional code. So don’t stay completely on the imperative side of Scala, or you might not enjoy as many of the benefits as you could.

Look for more in Part 2…

In Scala: Sink or Swim? Part 2, we will look at the good parts that should actually make you consider using Scala in the first place, plus some things in Scala that you can’t really avoid, but must live with nevertheless. Please leave me comments below, or write to me at Thanks for tuning in!

Responses (56)

  1. Avatar  

    Kaupo Parmas

    March 19, 2012 @ 10:55 am

    Nice post, looking forward to the next one. Haven’t come around to using Scala yet, trying out Groovy first and then maybe come over to scalaland as well.

  2. Avatar  


    March 19, 2012 @ 10:59 am

    can an absolute beginner start learning scala before java ?!

  3. Avatar  

    Erkki Lindpere

    March 19, 2012 @ 11:10 am

    I don’t see why not, but I don’t know whether there are good learning materials for that.

  4. Avatar  

    Eric Parnell

    March 19, 2012 @ 1:55 pm

    Very good post. Unfortunately, a lot of newbies feel they must get into the items you mention in order to master the language and this opinion is fostered by the experts in the language.

  5. Avatar  


    March 19, 2012 @ 2:26 pm

    Of possible interest: “Scala for the Impatient” has just been finished. An excellent book on Scala. Part of the book can be downloaded for free on

  6. Avatar  

    philip andrew

    March 19, 2012 @ 2:49 pm

    Its the same for C++. Its best practice to avoid the hard areas such as operator overloading.

  7. Avatar  

    Erkki Lindpere

    March 19, 2012 @ 3:09 pm

    Sounds great. I’ll just put a link to it here:

  8. Avatar  

    Tony Morris

    March 19, 2012 @ 3:58 pm

    Thanks for the giggles. Thinking is fun, try it.

  9. Avatar  

    Erkki Lindpere

    March 19, 2012 @ 6:40 pm

    Don’t worry, I think at least once every two weeks :)

  10. Avatar  

    Markus Jais

    March 19, 2012 @ 7:31 pm

    Very good post in Scala and I agree with many things here. It is good to keep it simple at first.
    When I learned Ruby many years ago, I didn’t start with all the meta programming on the first day.
    And a Java Programmer shouldn’t start with all the details of Generics on his/her first day.

    Looking forward to part 2.


  11. Avatar  

    martin odersky

    March 19, 2012 @ 8:16 pm

    That’s very insightful and helpful advice. I really liked your level-headedness. Thanks! — Martin

  12. Avatar  

    Mauricio Scheffer

    March 19, 2012 @ 8:55 pm

  13. Avatar  

    Richard Wallace

    March 19, 2012 @ 9:29 pm

    This is by far the funniest thing I’ve seen since SIP-18.  The laughs just keep coming!  Keep it up Scala community!

  14. Avatar  

    Josh Suereth

    March 19, 2012 @ 10:54 pm

    tl;dr; – Decent post.  A bit on the extreme, which I hope is trying to swing people away from the other extreme as opposed to how you really feel.

    My thoughts:

    It’s pretty sad to see SBT on the top of your list, but it does ring true with the idea that SBT is more geared towards build *designers* than users at this point.  TBH, as a maintainer of both maven plugins and SBT plugins, I sincerely hope maven will diaf, and very soon.  There’s no comparison in terms of how nice SBT is to write complex build interactions vs. maven.  In fact, there’s much in SBT that’s possible which I can’t dream of how to accomplish in maven.  
    Now, as far as users are concerned.  Well, the mark is missed.  Users don’t care if there’s a huge wall to scale to write build plugins, as long as learning + writing a build can be done in 5 minutes.  This is why there’s so few maven plugin authors out there, in my experience.  Almost every SBT user is also a plugin author.

    What’s surprising to me is that Maven documentation has been, and continues to be terrible.  Yet it’s familiar.  About 5 years ago, you heard nothing but how complex maven was compared to Ant and how terrible it was, and how hard to create build files.  Yet now, it’s a de-facto standard of java shops, thanks to features and plugins that are easy to use.  *I* was the one introducing Maven, just as I’m now introducing SBT, and it was the same battle.  In 5 years, your mind may be different.

    This gives me a lot of hope for SBT.  SBT makes it so easy to write a plugin for anything under the sun, that hopefully once the User API is fixed, (like when maven switched from 1.x to 2.x), then you won’t see any more blog posts like this.


    Note that category theory is *just* a design pattern in FP.  You can’t really avoid it.  That’s like saying “don’t use for expressions” in Scala.   I guarantee, everyone using Scala is using a bit of CT, whether or not they realize it.   Learning it merely helps you use it better.   Same as any old design pattern, like decorator, iterator or visitor.   

    What’s *wrong* is when you use your knowledge of patterns, FP, or category theory to lord over other developers in your team, bellittle them, and get your way.   This is an all-too-common occurence in an industry that accepts the Primma Donna.  Abusing any language feature or design pattern is bad.  Don’t do it.

    When Scala experts recommend learning these things (scalaz, FP, etc.), it’s to make you a better programmer.   Part and parcel to that is knowing where they apply.  I think more useful advice, rather than avoid category theory, would be “Don’t use category theory until you understand it”.

    The same can be said of many things in Scala.  My short list of things to avoid:

    (1) val/var in traits  (well, any sort of OO initialization requirements are terrible)
    (2) implciit views
    (3) non-method-local vars

    Which are all missing from your list.  Anyone who’s used scala for non-trivial code should be *very* aware of trait linearization issues.  It’s the *worst* complexity in the whole language.  Implicit views should be second.  Hardest thing for new-comers is knowing where the magic comes from, or what’s available.  Finally, non-method-local vars cause no end of bugs in real life code.   THOSE, more than anything else, cause issues in Scala code.

    If you’re using Scala effectively, you should have a ton of one-expression methods that are easy to maintain.  If your methods are longer than a few expressions, you should think about refactoring.  Most likely, you’re missing some kind of re-use.   The verb-focused attitude is actually a boon here.  Your SBT example is rather poor code in general.  I hope you don’t find that too often in the ecosystem as I’d yell at the author.

  15. Avatar  

    Jeremy Mawson

    March 19, 2012 @ 11:35 pm

    Yes, I think they should.

  16. Avatar  

    Alex Kravets

    March 20, 2012 @ 12:08 am

    Umm… that’s a little condescending no ? Thinking is fun, as long as it’s not the only activity :-) One also needs doing sometimes :-)


  17. Avatar  

    Lachlan O'Dea

    March 20, 2012 @ 12:11 am

    Personally, I think this is a crazy approach. I read this as basically, “Scala is great! Just stay away from anything remotely unfamiliar or innovative.” But you are expressing a common viewpoint, that’s for sure. I think you really want one of the many “better Java” languages: Ceylon, Kotlin, Xtend, Fantom.

    I’ll stick with Scala because it pushes me to learn genuinely new things instead of doing old things slightly better.

  18. Avatar  

    Alex Kravets

    March 20, 2012 @ 12:15 am


    I run a fairly large project with multiple developers and we are not using SBT because honestly we don’t really wanna learn another DSL to configure our project dependencies.  Instead we use IntelliJ’s GUI dialog (gasp !) with their multi-module projects you get 90% of what you get with a real dependency tracking system like sbt but with only 10% of brittleness and headaches :-)


    P.S. There *is* a way to rescue SBT from its impending oblivion due to non-use (IMHO) and that is for you guys to think real had about *defaults* i.e. it’s not how many options one can give the user (just think about all the -X options for the JVM ) it’s about shipping with human-friendly defaults … 

  19. Avatar  

    Tony Morris

    March 20, 2012 @ 3:02 am

     Hahahaha, yeah it’s darn amusing innit?!

  20. Avatar  

    Tony Morris

    March 20, 2012 @ 3:06 am

    If you choose to take my advice to think as condescending, then that is for you to decide. This post is nothing more than a product of fear of learning. This fact is transparent, but you’re free to turn it into a controversy if you like — after all, that’s what anti-thinking is all about, especially from the Scala community.

  21. Avatar  

    Greg Turnquist

    March 20, 2012 @ 3:33 am

    I don’t understand why people are put off by this post. It seems to discuss how to “wade into the pool.” I have tinkered with some of these tools, and if my team was gearing up to use scala, we would probably start without SBT. I know there will be learning issues with scala code. Why add learning issues with SBT on top of it? After getting nicely warmed up and cranking out some useful releases, then might be a good time to see what benefits come from using SBT? It’s the same reason I look at whether to continue using maven, or migrate to gradle. There is a lot of maven answer on stackoverflow to get moving, but one day, you need do something that exceeds maven’s built-in stuff, and gradle is great at letting you insert a chunk of code without having to dig into the plugin APIs.

    For that matter, I don’t see this post declaring that you never learn scalaz or category theory. It says don’t start there! Since probably 90% of the people reading this have an imperative programming history, this makes sense. Listen to Dick Wall on the Java Posse, and see that he tip toed in imperatively, but after about 6 months, his brain shifted, and immutable, functional programming made a lot of sense.

  22. Avatar  

    Daniel Sobral

    March 20, 2012 @ 4:37 am

    A simple SBT project doesn’t need any configuration *at all* to support compilation, testing and running. And you get publishing just with credentials. So… what defaults do you want?

    As for SBT going into oblivion due to non-use… well, just graph sbt questions on Stack Overflow over time.

  23. Avatar  


    March 20, 2012 @ 6:28 am

    Thanks, great post, mostly what I figure after a year of Scala.

  24. Avatar  

    Erkki Lindpere

    March 20, 2012 @ 8:17 am

    Thanks for the comments everyone. I’ll reply to a bunch here instead of doing it one by one.

    As Josh guessed, the post may come off as more extreme than my actual opinions on each one of those things. But I think it’s a good rule of thumb that someone who has mostly programmed in Java should “ease into” Scala, not jump straight at the hard stuff. There are subsets of Scala that might fit different people, and it’s a good idea to start with something small.

    Surely there are some things missing from the list, as Josh pointed out, and perhaps I should have focused more on some of the issues he mentioned, but I didn’t want to go too much into language details here. The post is already in three parts (coming within a week or so), so keeping it shorter was also an issue. I’ll see if I can address those in the next parts.

    I haven’t been very active in the Scala community — seldom read the mailing lists and so on, but it makes me sad to see many smart people being turned off from Scala. I think some of it is because judging by blog posts and such, a louder part of the community seems to be focused on theoretical stuff, experimenting and perfecting things moreso than simply getting things done. And to me, Scala is mostly a language for getting shit done. So another goal of this post is to bring some balance into the discussion.

    As for SBT, I think it has some great stuff in it, but the current DSL and the mental model is not geared towards end users enough.

  25. Avatar  


    March 20, 2012 @ 8:28 am

    Very insightful. Where can I learn more about 1) and 2) ?

  26. Avatar  


    March 20, 2012 @ 10:59 am

    All advice to keep things simple and pragmatic is good advice. But some people don’t seem to understand that. I’ve been using Scala for the past 2 years and loving it, even without SBT and Scalaz :)

  27. Avatar  


    March 20, 2012 @ 11:49 am

    Good response. I look forward to the rest of the series. I can definitely understand using strong language to make a point, and the idea of gently wading into scala is a good one.

  28. Avatar  


    March 20, 2012 @ 4:48 pm

    It took me months of using Scala professionally to realize that I do not need to use SBT. Far too many issues. And I also avoid the Cake Pattern, yet another mess. Spring/Guice works, that is good enough for me.

    Sadly, most people hacking away at Scala are tackling academic issues (oh look, a Monad!) and not issues that professionals need to solve.

  29. Avatar  

    Gustavo Hexsel

    March 20, 2012 @ 5:38 pm

    (disclaimer: I’m at best an intermediary-level scala programmer, close to beginner more likely)

    As much as I think SBT is promising, I still find there’s a lot of redundancy for simple tasks on sbt, compared to gradle/ant.  Don’t take me wrong, all build tools for scala seem to have downsides. 

    There are too many concepts you must understand to do simple things like package your app into a zip/tar file, for instance.  Also, the split between the simple (and more attractive) configuration style and the full configuration is painful, and too often you don’t know which one you need until you have to rewrite one into the other (and thus, learn both).

    A few suggestions I would love to see:
    – make the “simple configuration” flexible enough to replace the full configuration and deprecate the full config
    – make the mapping of project settings into values less verbose (my builds always had to map 4 or 5 of those into a single task, it was very ugly to read)
    – remove the empty line requirement for the simple build format (make parsing smarter)
    – make the documentation for the settings better, lots of time it’s a guess to find out whether you need to declare a scope and which scopes are valid for each setting

  30. Avatar  

    Jevgeni Kabanov

    March 20, 2012 @ 7:09 pm

    @google-ecb3fe71bcf25bd76ea0cd29eba9471f:disqus I wrote production apps in Haskell, taught advanced FP and type theory, published a paper on category theory and still think that Scala is over-complicated, a bastard child of OO and FP with some XML thrown in for reasons unknown. Don’t get me wrong, it’s better than anything else you can get on the JVM, but the article is spot on — it’s not a pragmatical language and you need to deal a lot with over-abstraction complexity due to the code culture.

  31. Avatar  

    Gustavo Hexsel

    March 20, 2012 @ 10:53 pm

     Hm as much as I love IDEA, I don’t think it replaces a build system:
    – it’s slow to compile (fsc integration used to beyond brittle)
    – it doesn’t really manage the dependencies easily (upgrading a library version? Dozens of manual steps to download all upgraded deps)

    If you don’t like SBT and you have a little maven experience, try maven with the JRebel plugin (they seem to be hosting the blog for that reason), it is free for scala development…

  32. Avatar  

    Tony Morris

    March 21, 2012 @ 2:18 am

     Jevgeni, I could almost agree with the points you just made. After I revise your comments a little such that I agree, and assuming you would also agree with those minor revisions, the result would be not what this article says in any way at all. Just like your comment, without revision, is not what this article says.

    This article is a product of fear and ignoorance, not coherent analysis. It would be quite easy (though not constructive) to demonstrate this. I’d just prefer to giggle.

  33. Avatar  

    Ravindra Jaju

    March 21, 2012 @ 2:24 am

    Slightly off…
    But here’s the irony. Most projects are *not* simple. Fun projects can use the zero-config build.sbt-s but as soon as you want to do anything beyond the trivial, SBT starts rearing it’s fiery head. It’s not just the operators (which is a huge issue) – but the fact that it’s hard to search for help using only those operators as your clue since you have no idea of their English equivalents.
    The SO graph you say? What’s the spread of the people actually answering SBT questions?
    It’s good to know that there are so many helpful people in the Scala community, but it really doesn’t help much because of the (perceived) complexity.
    In the end, perception comes from familiarity, and not most programmers are familiar with the deep theoretical notions and notations that Scala brings into the real world from those books…

  34. Avatar  

    Jevgeni Kabanov

    March 21, 2012 @ 2:48 pm

    Almost all of the warnings in the article are about language and library over-abstraction that stands in the way of solving problems rather than facilitates that process. 

    Yes, my points were more from a high level observation, but these are the issues that cause the troubles “in the trenches” as outlined in this and other articles. For me it’s all the same issue as I saw in Haskell — language designers and community apply abstractions indiscriminately, forgetting that this introduces enormous complexity for understanding, maintaining and debugging the code.

  35. Avatar  

    Jevgeni Kabanov

    March 21, 2012 @ 2:50 pm

    For me shift/reset was the beginning of the end. SIP-18 is exactly the ghc extensions, revisited.

  36. Avatar  

    Jevgeni Kabanov

    March 21, 2012 @ 2:53 pm

    We host the blog because it’s our blog :) Erkki is one of the engineers working on JRebel and we let our engineers post whatever the hell they like, as long as it’s not outright offensive to our customers.

  37. Avatar  

    Gustavo Hexsel

    March 21, 2012 @ 4:51 pm

     That is misleading: the post is about SOME, mostly external and/or optional, libraries having abstractions, syntax and concepts that are alien to Java (or, more generically, OO/procedural) programmers.  The post itself does not mention those are being permanent recommendations, but rather ways to avoid frustration when you begin to program in Scala.

  38. Avatar  

    Tony Morris

    March 22, 2012 @ 12:51 am

    Like I said, thanks for the giggles :)

    Willing to help out anyone dedicated to learning the subject matter so as to make informed decisions — just contact me!

  39. Avatar  

    Jevgeni Kabanov

    March 22, 2012 @ 7:35 am

    Fair enough.

  40. Avatar  


    March 23, 2012 @ 2:18 am

    FWIW the post made Scala more appealing to me as an average programmer. While there is useful and interesting stuff in the advanced topics I’m sure, there is something in the programming culture for instance about using symbols instead of words that is not very approachable. Nobody talks about these things, they just move on…

  41. Avatar  

    Josh Suereth

    March 23, 2012 @ 5:26 pm

    What’s funny about that comments  is doing *complex* things is what SBT really excels at.  I’ve been able to script together some really really intensive builds that do some crazy stuff I would have never tried in other build systems, especially in Maven.

    I’m building MSIs, DEBs, RPMs, ZIPS, JARs, running tests, etc. on multiple platforms.  The build language hasn’t gotten any more complciated than when defining a simple project.

    Again, that’s the issue.  Your learning curve is a wall. Once you’re over it, *everything* is pretty easy, but getting over that wall is tough.

    SBT doesn’t rear its ugly head on difficult tasks, this is where it excells and why I continue to use it.  None of my builds are simple, but SBT makes life a lot easier for these.

  42. Avatar  

    Josh Suereth

    March 23, 2012 @ 5:28 pm

    I make no claim that SBT’s learning curve is not huge.  That’s its biggest failing currently.  However, the simplicity of doing things in SBT is there.  It’s pretty amazing what you can accomplish with a few short lines of code.  I know the difference between it and other builds tools, having done a *lot* of builds over the years, and it’s still IMHO the best tool for any complex build.  It’s the intermediate (not dead simple and not complex) part where people get frustrated, because the learning cliff is steep.

  43. Avatar  


    April 18, 2012 @ 8:13 am

    Thank you for saying it out loud… SBT SUCKS!!! I was strugling with it for a while and it is really hideous, but always though it is something wrong with me for not liking it :). Glad to see someone that shares my opinion. I use buildr now and am the happiest Scala chap :).

  44. Avatar  

    Nicholas McCready

    January 17, 2013 @ 2:23 pm

    I agree with most of your thoughts, but not SBT. SBT is tough to figure out, but it is a very valuable tool. I think if you want to stay in the “shallow end” on SBT, you need to stay away from the .sbt file as your main Build.sbt. Instead use Build.scala with-in intellij, at least then you will get scala intelli-sense to help you figure out where you have gone wrong. Another pointer would be to use g8 to get a person up and running with a SBT template. Either way using Gradel, or SBT so that you are not storing off project files in GIT is amazing!

  45. Avatar  

    Nicholas McCready

    January 18, 2013 @ 6:46 pm

    Another point on getting your feet wet is using frameworks like Play! . They basically did most of the legwork up front ont he SBT end. All you have to do is use a PlayProject and make your custom features, or override theirs. So to learn SBT even more you can look at Play20 github page and follow their sbt configuration code to learn.

  46. Avatar  

    Igor Petrouk

    February 14, 2013 @ 4:59 pm

    Agree with most points, except Cake Pattern. Putting Spring into project is something you should think 10 times about before actually using it. Guice is a wonderful framework, however looks plainly ugly in Scala code. Cake pattern is something that works like a charm. Just build your code convention. Speaking in Spring term *Component is context, *ComponentApi is public interface to context, then any “def” there is a bean. Use lazy val if you can.

  47. Avatar  

    Felix Palludan Hargreaves

    April 15, 2013 @ 6:07 am

    Scala is currently number 29 on tiobe :-D

  48. Avatar  


    May 7, 2013 @ 2:52 pm

    Reading this, I’m really disappointed that you’d actually write a blog post telling people, relatively innocent people that they should stay essentially ‘In the Cave’ (Plato’s Allegory, but kinda in the flintstones sense as well), I’m specifically referring to the Avoid category theory, avoid type level programming, avoid scalaz & shapeless. It’s not a matter of your not having the right to say whatever it is that you think, but thinking- what I’m considering real thinking’ would seem to suggest that to express these judgements is ultimately self indulgent and potentially negative to any reader. Sure these things should be entered into with caution, but most things should; enthusiasm is best tempered with caution.

    To anyone that reads this IGNORE this man’s remarks about category theory and functional programming, it will make your programs and your programming, and beyond that your thinking better. Don’t you think it Strange that there are hundreds, no thousands of different ways to do what amounts to the same thing, design and implement reasonable (as in able to be reasoned about) architectures, and dynamics, and that the majority of these redundant crafts and methodologies actually cost in terms of semantic investment and or introduce layer upon layer of complexity? Well if you DO think that’s strange or if you even have noticed at all, there’s CATEGORY THEORY and LOGIC, and really quite a whole lot more which exists for the express purpose of reasoning about structures and dynamics in a provable constructive manner. Scala actually allows for really very Interesting constructions and implementations. Sure ‘Impilicits’ and Chaotic Verbose Type and functional semantics are something of a Tar-pit, but the whole point of functional programming is clarity and simplicity. So stay those juvenile mammoth hormonal drives to dive in to the nearest Exciting Ideological tar-filled swimming hole and Look carefully at what Category Theory, Logic, Algebras, Game-Theory, and dare I say it?… N-Category Theory, Topos theory, Topology, and Merotopology have to offer, its a — ton more than you’ll ever get from reading some guy’s blog even if it says his job is fancy.

  49. Avatar  

    Mathew de Detrich

    July 8, 2013 @ 3:38 am

    SBT is ridiculously complicated for what it does, compare it to something like rake. It reeks exactly of the issue of whats being discussed in the article, it has extreme operator abuse and its API is so complicated and over-abstracted that attempting to do your own build tasks for even the most trivial of matters is annoying

  50. Avatar  

    Mathew de Detrich

    July 8, 2013 @ 3:41 am

    The thing is, shorter code != simplicity.

    SBT is a very powerful build tool, but its anything but simple from the end user perspective.

  51. Avatar  

    Balázs Mária Németh

    August 23, 2013 @ 10:16 am

    Being mainly a java developer myself, I can only agree with most of the points.
    Especially the cake pattern. It’s by far the most disgusting thing I’ve ever seen. Too complex and the creation of n*3 traits and classes just for the sake of the pattern itself is beyond me, it’s not justified by any business requirements. You hear scala being more concise but this is the King of Boilerplates, makes otherwise readable code look like one on a hacker’s screen in a Z category movie.

  52. Avatar  

    Stephen Boesch

    October 29, 2013 @ 1:04 pm

    Nice list: I agreed with – and had already had essentially same ideas as – eight of nine of your points.

  53. Avatar  


    October 30, 2013 @ 9:30 pm

    scalaz and sbt are one of the few tools i actually enjoy working with and really appreciate

  54. Avatar  


    November 16, 2013 @ 8:18 am

    I think he is speaking to people who may look at Scala for productivity reasons, People like me who is writing a back-end for online Sex Shop. While I enjoy learning new things and explore in my free time, (I actually have a lot of fun with haskell) I’m yet to find a place where a Monad is useful in my everyday. Maybe I’m just to stupid to figure it out how to sort a product category with a monad instead of humble class/model, or maybe my job is lame.

    Either way I consider this article spot on with the said focus, while I may fool around with Scala on a week end, I wouldn’t ask my boss to even consider it. If so this article make me even more curious about Scala. I see no reason for outrage.

  55. Avatar  


    March 14, 2014 @ 11:10 am

    Project.evaluateTask(/*args skipped*/)

    This is bad code for you? write it in java and see how nice it looks.

    Avoid SBT ? better pom.xml than compiled sbt files, well maybe make is a better option don’t you think so?

    Avoid type safety and functional code and operators like functions suck, why the heck one would choose scala at all then? for the fast compiler ??

    Scalaz (category theory) is not ok because everybody is stupid and can’t understand what a functor/applicative/monad/arrow is?

    So spring is great, no complexity at all while cake pattern is complex?

    You should probably stick to java, fp and scala doesn’t seem the right choice for you.

  56. Avatar  


    April 4, 2014 @ 10:00 am

    Working on an issue with our SBT build for a couple of hours now, slowly going nuts. As a result, I now feel SBT is lost beyond all hope. Can we *at least* drop the ‘simple’ part from ‘simple build tool’, because seriously, it’s anything but simple. Perhaps it’s ‘smart build tool’, but not ‘simple build tool’. And it’s not the sort of cleverness I’m looking for. I suggest everybody involved to pick up a copy of “Don’t make me think” (Steve Krug) and find Joshua Bloch’s “Bumper Sticker API Design”.

RSS feed for comments on this post.

Leave a comment