Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.
See all our reports

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*/).get.toEither.right.get.map(_.data.toURI.toURL).toArray

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 erkki@zeroturnaround.com. Thanks for tuning in!

  • http://twitter.com/kparmas Kaupo Parmas

    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.

  • Xyassine

    can an absolute beginner start learning scala before java ?!

  • Erkki Lindpere

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

  • http://twitter.com/eaparnell Eric Parnell

    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.

  • Eduardo

    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 typesafe.com.

  • philip andrew

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

  • Erkki Lindpere

    Sounds great. I’ll just put a link to it here: http://typesafe.com/resources/scala-for-the-impatient

  • Tony Morris

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

  • Erkki Lindpere

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

  • http://www.markusjais.com/ Markus Jais

    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.

    Markus

  • martin odersky

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

  • Mauricio Scheffer
  • Richard Wallace

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

  • Josh Suereth

    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.

    NEXT

    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.

  • http://twitter.com/badgerhunt Jeremy Mawson

    Yes, I think they should.

  • Alex Kravets

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

    Cheers…

  • Lachlan O’Dea

    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.

  • Alex Kravets

    Josh,

    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 :-)

    Cheers…

    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 … 

  • Tony Morris

     Hahahaha, yeah it’s darn amusing innit?!

  • Tony Morris

    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.

  • Greg Turnquist

    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.

  • Daniel Sobral

    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.

  • Ma

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

  • Erkki Lindpere

    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.

  • Th3rac25

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

  • hbatista

    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 :)

  • Anonymous

    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.

  • Tim

    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.

  • Gustavo Hexsel

    (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

  • http://zeroturnaround.com Jevgeni Kabanov

    @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.

  • Gustavo Hexsel

     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…

  • Tony Morris

     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.

  • http://twitter.com/jaju Ravindra Jaju

    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…

  • http://zeroturnaround.com Jevgeni Kabanov

    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.

  • http://zeroturnaround.com Jevgeni Kabanov

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

  • http://zeroturnaround.com Jevgeni Kabanov

    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.

  • Gustavo Hexsel

     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.

  • Tony Morris

    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!

  • http://zeroturnaround.com Jevgeni Kabanov

    Fair enough.

  • Hmm

    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…

  • Josh Suereth

    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.

  • Josh Suereth

    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.

  • Chibo

    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 :).

  • http://twitter.com/nmccready Nicholas McCready

    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!

  • http://twitter.com/nmccready Nicholas McCready

    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.

  • Igor Petrouk

    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.

  • Felix Palludan Hargreaves

    Scala is currently number 29 on tiobe :-D

  • KASPAAR KASPAAR

    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.

  • Mathew de Detrich

    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

  • Mathew de Detrich

    The thing is, shorter code != simplicity.

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