Imperative by day and functional by night

The “Scala is too Complex” Conspiracy

They don’t want pragmatic Scala programmers.


The “Scala is too complex for the average programmer” movement is disturbing. It conspires that Scala is too difficult for the average programmer to learn and that it is too academic. Scala is a hybrid programming language that is object oriented and functional. Java is a programming language that is object oriented and imperative. This means that Java programmers have no functional programming power.

This year I read Programming in Scala and practiced some functional programming. I converted some Java code I had lying around to Scala and gained some hands on experience with case classes, pattern matching, lazy evaluation, implicit conversions, lambdas, and closures. I also reduced and folded lists and wrote curried functions. I was pleasantly shocked and surprised!

It is true that moving from object oriented to functional programming requires a shift in mindset. It is true also that many Java programmers are already thinking functionally but are unaware of it. In Java we use immutable objects when programming for concurrency. We use anonymous inner classes to simulate lambdas and closures. We use iterators and predicates to simulate list comprehensions. We recognize these and other functional concepts but implement them in roundabout ways because there is no direct support for them in the Java language.

Fortunately Java 7 is looking to add lambda support to the language so we will soon no longer have to write anonymous inner classes wherever single method interfaces and abstract classes (SAM types) are expected. In the meantime Scala has emerged as a functional language that Java programmers can learn and transition to without sacrificing their object oriented skills and without leaving the JVM platform.

For any programmer who has not looked at Scala or who has been deterred by a “too complex” conspirator, here are some code samples..

Case classes

Lets create a class named Path that accepts a source and destination city as two separate characters and exposes them as public read only properties.

case class Path (origin: Char, destination: Char)

Prefixing a class definition with the “case” keyword automatically exposes constructor arguments as public read only properties. It also adds a factory method to your class so you don’t have to instantiate it with new, so Path(‘A’, ‘B’) will suffice for example. It also provides a toString method that returns a string literal like Path(A,B). You also get a natural implementation of the hashCode and equals methods. You get constructor pattern matching support too. All this for free with a one liner case class.

Factory method with pattern matching

Now lets create a factory method that accepts a string, parses it, and returns a Path instance. For example, passing the string “AB” should return a Path(‘A’, ‘B’) instance whereas passing the string “ABC” should fail.

object Path {	
  val PathRE = "^([A-Z]{1})([A-Z]{1})$".r
  def apply(pathStr: String): Path = pathStr match {
      case PathRE(origin, destination) 
      	=> Path(origin(0), destination(0))
      case _ 
      	=> throw new IllegalArgumentException(pathStr)

Now we can instantiate a Path as Path(“AB”) in addition to Path(‘A’, ‘B’). Any string that does not contain exactly two characters that are not between A and Z will result in an IllegalArgumentException. So the strings “a”, “1”, “A1”, and “ABC” will all fail construction. As a safeguard we can add an assert statement to the Path constructor to ensure that the source and destination cities are never equal like this:

case class Path (origin: Char, destination: Char) {
  assert (origin != destination, "origin and destination are same")

Implicit conversion

Now lets make it possible to assign the string literal “AB” directly to any Path type anywhere so that we don’t have to call the factory method explicitly. We do this by prefixing our apply(String) factory method with the keyword implicit as shown below:

implicit def apply(pathStr: String): Path

Now the string literal “AB” can be accepted anywhere where a Path instance is expected.

Folding Lists

Now suppose we want to write an application that accepts a list of Path string literals from the command line. We can convert the incoming list of Path strings to a Set of Path instances by using a fold left operation. The following creates a new empty Set and adds to it every Path in the incoming list. Each string in the list is automatically converted to a Path instance through implicit conversion.

def main(args: Array[String]) {
  val pathSet = (Set[Path]() /: args) (_+_)

Lambda expressions

Now lets say we have already written a function named find, that finds all the routes from one city to another based on some route condition. This function accepts two arguments, a Path containing the from and to cities, and a predicate lambda expression. The signature looks like this:

def find(path: Path, predicate: Route => Boolean): List[Route]

We can invoke this function to find (for example) all the routes from city ‘A’ to city ‘E’ having less than 3 stops like this:

val routes = find("AE", route => route.stops < 3)


We can curry the find function by splitting its two argument parameter list into two one argument parameter lists like this:

def find(path: Path)(predicate: Route => Boolean): List[Route]

Now when we invoke the find function with a Path argument we get a second function that we can then invoke with the predicate argument to get the result. We can invoke our curried function like this:

val routes = find("AE")(route => route.stops < 3)

Scala allows us to optionally wrap the sole argument to a single argument function in curly braces instead of parenthesis. So we can also invoke our curried function like this:

val routes = find("AE") { route => route.stops < 3 }

Now our call to the find function looks like a built in Scala construct.

Is Scala too Complex?

If you think that the above Scala code is too complex then I urge you to try and achieve the same in Java with less complexity.

Written by warpedjavaguy

August 2, 2010 at 11:14 pm

Posted in java, programming, scala

82 Responses

Subscribe to comments with RSS.

  1. These are nice examples but they certainly don’t prove that Scala is not too complex, just that it performs well on simple problems that are well suited to functional programming.

    The complexity emerges when you start mixing all these features together, especially with Scala’s Generics (which are more powerful but also more complex than Java’s), and that you do so on code bases in the tens of thousands of lines of code.

    Actually, I would even argue that even Scala’s one liners can be quite hard to read, such as:

    val email = userList flatMap (_.findUser(“bob”)) flatMap (_.email)

    The Fantom equivalent is:

    email := userList?.findUser(“bob”)?.email


    August 3, 2010 at 5:25 am

    • I would like to provide a solution that is more idiomatic:

      case class User(name: String, email: String)

      val userList = List(

      val email = userList.filter(_.name == “Cedric”).head.email

      Note that this is a complete program. Can it be much simpler that that?

      Olle Kullberg

      August 3, 2010 at 11:48 pm

      • I realized that my example above was missing the point. In Cedric’s example the user “bob” might not exist, so we do not want to throw an exception when “bob” does not exist.

        In Scala we use optional values (Option) for this:

        // Get Cedric or None if does not exist
        val optCedric = userList.find(_.name == “Cedric”)

        // Get Cedric’s email or None if does not exist
        val optEmail = userList.find( _.name == “Cedric”).map( _.email)

        Olle Kullberg

        August 30, 2010 at 3:59 pm

    • As another poor Java programmer reading the staircase book and trying to learn Scala, would you mind explaining to me where the findUser function in your example is defined? The only way I’ve been able to get your flatMap example to work is by defining the following class, and the findUser method of mine seems silly:

      case class User(val name: String, val email: String*) {
        def findUser(user: String) =
          if ( user == name ) List(this) else List()


      August 28, 2010 at 4:26 am

      • george, I believe it to be like this:

        case class User (name: String, email: String) {
          def findUser(name: String): Option[User] = name match {
            case this.name => Some(this)
            case _ => None


        August 28, 2010 at 8:36 am

      • WarpedJavaGuy,

        Thanks for the reply. I must be missing something. Here is my complete file:

        class FlatMapEx2 {
          case class User(name: String, email: String) {
            def findUser(name: String): Option[User] = name match {
              case this.name => Some(this)
              case _ => None

        object FlatMapEx2 {
          def main(args: Array[String]): Unit = {

            val userList = List(User(“olle”, “a@x.com”),
              User(“Cedric”, “b@x.com”), User(“Cedric”, “cc@x.com”))

            println(userList flatMap (_.findUser(“Cedric”)) flatMap (_.email))


        And here is the resulting output:
        List(b, @, x, ., c, o, m, c, c, @, x, ., c, o, m)


        August 28, 2010 at 12:04 pm

      • Yes, that is exactly what flatMap does.

        The first call to flatMap invokes findUser(“Cedric”) on each User in the list and returns a concatenation of all elements in all items of the resulting List.

        The resulting list is:

        List(None, Some(User(Cedric,b@x.com)), Some(User(Cedric,cc@x.com)))

        The concatenation of all elements in all items of this list is:

        List(User(Cedric,b@x.com), User(Cedric,cc@x.com))

        So the first call to flatMap returns this list.

        The second call to flatMap invokes email on each User in this list and returns a concatenation of all elements in all items of the resulting List.

        The resulting list is:

        List(b@x.com, cc@x.com)

        The concatenation of all elements in all items of this list is:

        List(b, @, x, ., c, o, m, c, c, @, x, ., c, o, m)

        So the second call to flatMap returns this list. Each email address is a String and each String is a list of characters.


        August 28, 2010 at 4:23 pm

      • Thanks for the tutorial. I made a wrong assumption as to the intent of the line of code from the start.


        August 28, 2010 at 10:17 pm

      • George,

        If we change the User email property to a list instead of a String (like you had in your original sample)..

        case class User(name: String, email: String*)

        Then we get the following more meaningful result:

        List(b@x.com, cc@x.com)

        After experimenting some more, I have found that if we leave the User email property as a String (as I had suggested)..

        case class User(name: String, email: String)

        Then to get the same meaningful result, the second call to flatMap must be changed to a call to map:

        userList flatMap (_.findUser(“Cedric”)) map (_.email)

        It was not immediately obvious to me that the email property should be a list. But with a result like List(b, @, x, ., c, o, m, c, c, @, x, ., c, o, m) though I, should have immediately known something was wrong. Sorry about that. The good thing is that it now makes sense and we have learned something 🙂


        August 29, 2010 at 8:56 am

      • Hang on a second..

        I’ve just learnt what a monad is without being aware of it!


        September 1, 2010 at 10:26 pm

    • Wow, that first example (Factory Pattern) “proves” the point about scala’s difficulty issues. I read it and have no clue as to what it’s supposed to do. I sure hope there is good documentation. It’s funny because you intend it to be a quick example of how “easy” scala is….

      The core assumption to validate the argument is that lambda programming is the only way to program, and if you don’t already know that, you are a pathetic luser.

      I’m working up to learn scala, but the problem I have seen is that all the documentation / books / etc aren’t very helpful because they assume a knowledge, or a quick understanding of lambda and function programming.


      September 3, 2010 at 3:42 am

      • Paul, that particular example shows how simple it is to validate and convert a string to an object in Scala. It does not show how easy Scala is.

        The Programming in Scala book suggests that the best way to learn functional programming is to use no variables (vars) in your code. Try and write code that only uses constants (vals) and you’ll be forced to start thinking functionally. If you get stuck, then do some more reading or take a break and come back to it. Do not program by coincidence. Make sure you understand what every line of code is doing. Do not repeat yourself. Learn how to reuse functions. Invest time in doing this and you will discover lambdas and functional programming.

        That’s what I’ve been doing all this year. I have not delved into Scala’s advanced features yet. I want to first start learning Lift and maybe later write my own DSLs.


        September 3, 2010 at 11:50 pm

  2. Cedric, YMMV but I find the for notation as readable as your Fantom example:

    val email =
    for (
    user <- userList.findUser(“bob”)
    email <- user.email
    yield email


    August 3, 2010 at 6:11 am

    • When I started learning Scala, I used to write “for … yield” constructs. But now, since I had a larger project (5 people), I usually prefer the “flatMap” and “map” style, especially for long blocks (i. e. if { x => … } tends to be long). The incentive for me is chainability.


      August 25, 2010 at 5:48 pm

    • heh heh, you are having the same arguments they always had over in Perl land… You could do it like this, or this is shorter, or maybe like this.

      For the Scala is difficult people, we just chuckle. Sure it has the potential, but it has a huge learning curve and nobody really seems able to describe it to us mere mortals…


      September 3, 2010 at 3:45 am

  3. It is definitely a subjective issue, but the important point is not to wonder what someone already familiar with the Scala syntax will think of that example but rather ask this to a Java programmer who’s never seen Scala.

    I’m betting they will find the Fantom version much more readable.

    This is a point that keeps eluding seasoned Scala developers.


    August 3, 2010 at 6:13 am

    • Cedric – your argument about Fantom’s ? being more readable than Scala’s flatMap is just totally bogus. flatMap is not some syntactic special-case sugar, it’s a powerful library feature from FP and has many uses, not least that the same functions can be used on different monad instances.

      If the “average” programmer can’t get their head around flatMap, stuff ’em

      Chris Marshall

      August 4, 2010 at 12:23 am

      • Chris, your attitude toward people who don’t understand this kind of code is precisely what turns people away from Scala, but let’s leave this aside.

        The problem is *precisely* that flatMap is a library call and not a language construct.

        Syntactic sugar matters and in many cases, it’s what makes or breaks a new language to beginners.

        Fantom’s ?. operator allows the whole operation to appear like a stream of methods called after each other, something that OO programmers are very familiar with.

        In contrast, Scala is mixing imperative and functional calls and it’s a bit hard to tell when you should do one or the other.

        Anyway, as I said, it’s a subjective issue so I don’t expect everyone to agree, but I do expect a minimum of courtesy, and a reaction such as “if you don’t get it, stuff you” is certainly not conducive to a productive debate.


        August 4, 2010 at 12:35 am

      • In this case I agree with Cedric.

        I too think that flatMap is not very readable and should be used with care.

        I too think that you can not say “stuff’em” to a colleague who do not understand your code.

        Olle Kullberg

        August 4, 2010 at 12:52 am

      • Saying “stuff ’em” in this context is not the same as saying “stuff you”. If I were hiring people for example, I’d also prefer the ones who could understand these things quite strongly above those who couldn’t. “Stuff ’em” in this case is just another way of stating this. I’m sure Chris doesn’t go around saying “stuff you” to people. Let’s not make a big point out of this; all in the Scala community that I’ve run into have been very friendly and helpful.


        August 4, 2010 at 1:22 am

      • Cedric – it takes 10 seconds to understand the basics of flatMap. I was happily using it within a week of migrating to scala. I woiuld expect anyone learning a new language to at least *TRY* and get their head around new things (otherwise, why bother?)

        Oh, and I wouldn’t hire a programmer I thought *couldn’t* understand this stuff – they shouldn’t be programming. I expect they are writing awful Java, the only difference being that it appears to compile

        Chris Marshall

        August 4, 2010 at 5:13 am

  4. Who are these conspirators exactly?


    August 3, 2010 at 4:40 pm

  5. In my opinion the problem with Scala is not about complexity, but about excessive flexibility. I can easily imagine two functionally identical pieces of Scala code that will look like written in an entirely different programming languages. I do believe that albeit it can be interesting and inspiring (especially for academic research) but I think that it makes using of Scala in large long-living commercial projects absolutely impractical (not to say more).


    August 3, 2010 at 5:36 pm

    • iskorn, when I first started reading about Scala I too was a bit worried that its flexibility would be too overwhelming. It was not until I started doing some actual coding that I started to feel more comfortable with it. Choosing one way of coding over another comes down to finding the right balance between expressability and readability. Being too expressive can result in code that is too cryptic to read. There is more that one way of coding a solution in any language I think. This is where sensibility must come into play.


      August 3, 2010 at 9:12 pm

  6. @iskorn: well said! One could argue – Scala tends to be “perlesque”.


    August 3, 2010 at 5:57 pm

  7. Agree with iskorn. There are just too many ways to do the same thing in Scala. For every piece of function you can do it with either the functional way or the object-oriented way, or a mix of both. And there’s no definite guideline on when to use what. For any project involving >1 people this is going to be a disaster.


    August 3, 2010 at 7:19 pm

    • There is only 2 ways of doing things in Scala: (1) imperative object-orientation (like Java) or (2) functional object-orientation. The imperative path is readable and understandable for every Java programmer. Therefore only the functional path is difficult for most programmers. But to claim that Scala is too difficult because it allows imperative style is misleading since it IMHO does not come with an extra cost. Imperative OOP, that is the stuff we already know.

      Olle Kullberg

      August 3, 2010 at 10:54 pm

      • For me the main problem is not a choice between functional and imperative styles. I used to program in Prolog pretty much some time ago so the functional style does not scare me at all. Moreover I admit that sometimes it can be more expressive and elegant than the imperative one (although I do believe that some people overestimate the importance of this style for real-life projects). My main concern is the custom operations and an extremely flexible syntax for using them. Imagine a 1M lines’ Scala project which evolves for 10+ years with dozens of programmers with different skills, styles and habits involved at different stages – and you have a good illustration to the Tower of Babel story. Of course an aggressive enforcement of corporate coding standards can help, but people use to move from one company to another. With all the shortages of Java at least there is a wide consensus about the coding style and these rules look pretty natural. I can barely imagine such a consensus for Scala (and not only because of the custom operations).


        August 4, 2010 at 12:28 am

      • @iskorn I think you seem like a smart person, and I understand that you worry about these things. However, from where I stand this is not a problem at all. Let me explain:

        It is like always when you are building a system (Java is no exception), some developers add to much abstraction. Some people want to use full blown ESB inside an application just for the fun of it, so they do. Some developers use all the patterns in the GoF-book just for the fun of it. The same people will use Scala implicit keyword when they should not. So what?

        I see the different techniques for abstraction in Scala just as I used to see frameworks in Java. A sane programmer would not use one if he does not have to, i.e. KISS.

        If you think that a 1M Java system is easier to maintain because it is all for-loops and mutable objects then I simply have to disagree. Junior programmers master the simple building blocks of Java, but they will not make the complex parts of your system work, at least not fully working. Even if there are no complex parts of your system so that Junior programmers could work anywhere (imagine 1M lines of CRUD) then I still think you should use Scala.

        Junior programmers can work with the least complex parts of the system, they would not be let loose all by them selves in a banks core transaction routines anyway, right? if they use Scala for this not so difficult duties they would IMO have a higher probability of success. Scala basics are IMO easier than Java, since there are no primary types and you can always use the == for equality and so on. Most of the strange stuff of Java is removed.

        For the more complex parts: Let’s face it, good programmers will go nuts if they are forced to duplicate code because they are not allowed to use the correct abstraction for the problem at hand. Scala provides many techniques for abstractions, and this is good for solving complex problems. Forcing programmers to use Java in a situation like this will result in a very complex use of design patterns instead, or just heaps and heaps of duplicated low level logic.

        Olle Kullberg

        August 4, 2010 at 8:50 am

  8. Re readability. If the notation is familiar then Java programmers will like it. That Fantom example looked similar to Groovy so I had no problems with it. Of course, others may disagree.


    August 3, 2010 at 8:00 pm

  9. An important point that often gets overlooked is that the functional programming constructs in Scala, such as the flatMap on the monad that Cedric mentions, are familiar to functional programmers. Java programmers are not the only (potential) inhabitants of JVM land, thank god.


    August 3, 2010 at 9:03 pm

  10. Just some thoughts:
    At its core, Scala tends to be less complex than java because it offers one simple way rather than different incompatible:
    -> No primitives
    -> Arrays _ARE_ collections
    -> Operator overload is a well defined feature not language sugar for some objects,
    -> Closures are available. No interface trickery or workarounds needed.
    -> multiple return types exist in the form of tuples
    -> Collections are by default immutable, even though mutable ones are availabe
    -> Strings can be used as collections
    -> Multiple Inheritance is possible an does not need to be emulated
    -> TypeInference is completely avialable and not just in special cases for inner classes and generics.
    -> One namespace for fields and methods. No more thinking about how and why to design “properties”.
    -> Semantics to construct arrays and lists are identical. No syntacthic saccharine for array construction.
    -> No STATIC. Everything is an object.
    -> Implict conversions are not language-internal magic but something the user can easily understand and extend.
    -> Keywords are reserved for logic, not for some custom language stuff. No strictfp, transient, volatile, magic private methods for serialization, …

    The list goes on and on and describes problems which beginners have especially with java, and which tend to bite again and again later.

    Simply put: Because too many people which use it are pros which – IMHO – sacrifice clarity for short code.
    Since it can be hard to understand these short functional expressions, i tend to shy away from operator overload AND use the for-expression where possible. This greatly helps to keep your code understandable.

    In my opinion, having multiple ways is good for algorithms (scala) but bad for language constructs (java)

    Eric Giese

    August 3, 2010 at 9:08 pm

  11. But… it *is* too difficult for average programmers to learn. They’re average. They don’t learn things all that well, and, more importantly, don’t try. That’s why they’re average–by definition. If anything, the skill level ov average programmers has *declined* over the years, because there are a lot more of them, programmer education is (on average) getting worse, and most time is spent on work rather than exploration.

    Above-average programmers explore on their own time, because they enjoy programming. Average programmers don’t, because they’re average.

    Vicious circle. Conspiracy? Of course not, unless you consider being “average” a conspiracy.


    August 3, 2010 at 9:25 pm

    • I think you nailed one interpretation of this. Most “average” programmers I’ve met balk at learning *anything*, even another OO/imperative language like Python or Ruby. Even grasping a basic tenet of FP like higher-order functions represents an unacceptable expenditure of intellectual effort for them, especially since “I can do everything I need to do with [language I already know]”. The for “average” programmer, programming is just a job, approached as something they would cease forever the moment they cashed in that winning lottery ticket.

      On a completely different and more constructive note, the only two parts of Scala that I would say have a legitimate cause for the “too complex” accusations (from *good* programmers) are the grammar and the type system. I find both of these difficult to hold entirely in my head.

      As another commenter said, it’s as if every example of Scala code I’ve seen looks like it’s written in a different language. This characteristic seems subtly different to me than just “flexibility.” For example I’ve written a reasonable share of Clojure code over the last 6 months, which, I think it can be agreed, is an extraordinarily flexible language. But I don’t feel lost on something as superficial as syntax each time I see a new Clojure technique being demonstrated on someone’s blog or mailing list post.

      Kyle S

      August 4, 2010 at 5:43 am

  12. I think basic problem is in IDE. Java have very good support to reduce its complexity.


    August 3, 2010 at 10:58 pm

  13. Your examples are too easy. Watch this presentation titled “High Wizardry in the Land of Scala” and then tell me again that Scala is not complex!


    August 3, 2010 at 11:10 pm

    • That stuff is not for application developers. The name of the presentation suggests as much. My point is that you will never have to look at code that looks like that.

      The Scala code you will see at work will be mostly like the Java code you are used to, but with these exceptions:

      1. No boilerplate: no getters and setters, no constructors.

      2. No equals() or hashCode() implementations in you objects. The case class does this for you.

      3. No troublesome generic code when you create an instance of a collection ArrayList (or whatever). Simply hopeless in Java. The corresponding type declaration is in most cases invisible in Scala.

      4. People _do_ use anonymous functions to fetch data from collections, but hey, Java will have that too soon. Watch out!

      5. People _do_ use the match expressions. These are just great (and easy too).

      Olle Kullberg

      August 3, 2010 at 11:30 pm

      • I think a language that only supported these differences would be quite welcome in Java land. The problem is the rest of the changes, not these.

        Sam Pullara

        August 29, 2010 at 5:28 am

  14. Why do not people realize that Java is too difficult for the average programmer? That is the true purpose of Scala, to escape the complexity of Java code!

    Framework code in Scala, with heavy use of implicit keywords and all kinds of type abstractions, is very difficult. This is correct, but this code is not meant for innocent eyes. You do not use that sort of code when you write an application.

    The question is really if you want to program imperative or functional style:

    1. Imperative style: You use mutable objects with for-loops and mutable data with locks (to synchronize threads) to get something that works… sometimes. It is easy to write, but very hard to get right. If you like this, you can do it in Scala too.

    2. Functional style: If you use immutable objects and actors, you might not get a solution that is riddled with bugs. That is IMO a good thing.

    Scala provides both ways for you, but the whole point of Scala is that it will teach you to walk down the “safe” path..

    Olle Kullberg

    August 3, 2010 at 11:14 pm

  15. Scala means “scalable”. It can be as easy or complex as you like.

    Easy: Have a look at Kojo and the story behind it. Hundreds of Indian
    girls coming from disadvantaged families get introduced to programming using Scala. I would wager that for beginning programmers, Scala is easier to pick up than Java. (because of the functional nature, low ceremony syntax, and the REPL).

    Complex: By using the elaborate type machinery of Scala with abstract types, implicits, structural types, and so on, you get enormous expressive power, which lets you write very high level libraries and DSLs, all of them statically typed. Very few other languages achieve this combination of malleability and safety.

    So Scala is a language that uses sophisticated constructs in libraries
    to make end-user applications easy. Other languages have canned
    constructs instead. For instance Cedric’s example compares built-in
    non-null types in Fantom with library provided option types in Scala. Or often people compare Scala’s collections with built-in collections in other languages.

    Why the library-based approach? Because we should never assume we know all about what constructs applications need. We are about to live a revolution of the way we write software due to parallelism and concurrency. I have no doubt that completely new ways to program will emerge from that. A language that lets you construct your own high-level libraries adapts much better in this world than one which doesn’t.

    Martin Odersky

    August 4, 2010 at 12:44 am

    • Thank you Dr. Martin Odersky ‘The creator of Scala’ for joining this discussion. Your much welcomed presence is positive and inspiring!


      August 7, 2010 at 4:33 pm

  16. I read both the main scala books, looked at code and gave up. The average programmer has many, many things to do and is time-short.
    The good ideas in Scala need to be carried forward in subsequent languages but delivered with the ease of learning and use of Python or Javascript or Erlang (but without the syntactical nightmare of Scala and Erlang). Scala is too ‘academic’ to be a mainstream success, IMHO

    If it takes hold its the next nightmare maintenance language !


    August 4, 2010 at 5:03 am

  17. Before you badtalk “average programmers” too much, keep in mind that they have more time to do other stuff. They might actually:

    * be good at sports
    * see movies other than Star Trek and Avatar
    * not be caffeine addicted
    * make more money than you
    * go to sleep at 11.00PM.
    * have a girlfriend, or two.


    Mikael Grev

    August 4, 2010 at 5:39 am

  18. Martin,

    I concede that my example is not fair and it actually goes against a principle I believe strongly in: that libraries are what makes a language stand the test of time, not its syntax. Java is living proof of that.

    However, in this particular case, I think that Fantom making the decision to support safe invocation at the language level is a reasonable compromise because it’s a pattern that is so prevalent in any language that has to deal with null pointers that any solution besides a syntactic one is guaranteed to add noise. I think Scala is a victim of this, and anyone who thinks that flatMap is easy to read has probably been programming in Scala for too long 🙂

    I’m also aware that Maybe/Option and monadic composition in general solve a broader problem than null pointers, but that wasn’t the point of my post.

    As for the “Scala is too complex” debate, everybody will obviously have a different opinion on it and since it’s extremely subjective, no discussions will ever reach a conclusion. The market will make this decision for all of us.


    August 4, 2010 at 7:10 am

    • Cedric,

      I did not want to criticize null-pointer checking per se – this looks like a good idea, and it’s one of the tings we are evaluating for Scala (we’d need to get good a integration with Option types).

      I also agree flatMap is not the easiest thing to grasp for newcomers. That’s why Scala has for expressions which are equivalent (they translate to map, flatMap, withFilter), and most people find them very easy to understand.

      Martin Odersky

      August 4, 2010 at 7:28 am

      • Martin,

        That’s great to hear, looking forward to seeing what this will look like.

        Can you expand on your comment about `for`? I’m not sure I see what you are referring to.



        August 4, 2010 at 7:30 am

      • Cedric,

        (WordPress does not let me reply to your last comment, so I am writing it here).

        I refer to Michael’s comment (number 2 above). He has shown how to express your code with flatMap as a for expression. The two formulations are equivalent; the for expression will expand to the flatMap that you wrote.

        Martin Odersky

        August 4, 2010 at 7:36 am

  19. Regarding the first sentence of this post I think that if Scala is too complex for the average programmer it is probably because programming is too complex for the average programmer (I couldn’t resist :-). Functional programming has been around for something like 4 decades now and has proven itself to be a powerful tool that most developers should understand. The interesting thing about Scala, and what it should be critiqued on, is how it combines functional and object-oriented constructs with static typing. If Scala is shown to be too complex, the faulty complexity will be in the type system, not the functional constructs. But I’m excited to be learning it.

    Mike Hopper

    August 4, 2010 at 7:16 am

  20. jack,

    oh, that myth about the dump average java developer!

    the average java developer is dealing with noisy inner classes & checked exceptions, generated getters&setters, imperative style collection handling, unusual equality rules, backward compatible but otherwise very confusing generics implementation, complex APIs and frameworks that can be configured with hand-edited XML.

    As far as I am concerned, scala would bring simplicity into even the average java developer’s life

    joe poki

    August 4, 2010 at 7:23 am

  21. I don’t understand the notion of “average java programmer” in so called above average functional circle; that very notion is a conspiracy in itself. They are just average programmers. Surely any average programmer who can fathom massively complex enterprise application will not consider Scala any more complex to say the least. In all seriousness, following salient features of a typical enterprise java app are much more complex than learning Scala’s type system:

    1. “Turing complete” configurations files in XML,
    2. Arcane frameworks,
    3. Forests of dependencies,
    4. Build tools beyond imagination and
    5. App servers with memory blackholes and so on.

    Nirav Thaker

    August 4, 2010 at 9:29 am

  22. I believe the problem is just too many options. People will get used to a set of visual and structural entities that are, in their minds, “correct”. Scala allows too many options, which without a comprehensive set of code style guidances, seems overwhelming to programmings reviewing and modifying existing scala code. Examples:
    – parenthesis vs spaces
    – return keyword is optional
    – return type is optional
    – data types in declarations are optional

    It’s a lot of decisions that need to be made by the programmer which most languages just hide from view (java because you must do those things, dynamic languages because you sometimes cannot do those things).

    Gustavo Hexsel

    August 4, 2010 at 9:38 am

    • I would think that any developer having trouble deciding on issues such as these has bigger problems to worry about.


      August 4, 2010 at 7:45 pm

  23. Under any *objective* measurement that I can imagine
    (i.e. personal “gut feelings” just don’t count),
    Scala *is* less complicated than Java.

    As a case in point, the Scala Language Specification is 191 pages long, Java needs 684

    Kevin Wright

    August 4, 2010 at 8:10 pm

  24. I looked at Scala and my conclusion was “Scala is a language developed by Ph.D. people (for Ph.D. people)”.
    I would distinguish complexity in different part:
    – language complexity (what you mostly describe in your blog).
    You have indeed how people write the code. Try to explain to a 17 years old boy how curring and lambda expression are simple (and fun?).
    – documentation complexity
    e.g. The tour of scala regular expression page starts with “Right-ignoring patterns are a useful feature to decompose any data which is either a subtype of Seq[A] or a case class with an iterated formal parameter, like for instance

    Elem(prefix:String, label:String, attrs:MetaData, scp:NamespaceBinding, children:Node*)”
    and ends with “General RegExp patterns temporarily retracted from Scala”
    Also scala by example: 145 PDF pages, no graphics, no colors.
    No graphical examples, no examples about swing (not even mentioned), no examples on how to read or write a file (who would need it) and I doubt there is any example on parsing XML, reading data from an URL, writing a html page, accessing a database, playing music …
    – Use complexity (also named ease of use). A friend visited me 2 weeks ago who was looking at scala during his holidays. He gave up because of bad IDE support and readability of the documentation.
    Example for improvements could be put simple examples with scala (one using Ant, another one using Maven). This you can’t who with code snippet.
    Your code for example doesn’t have documentation.

    With Java you also say add “@WebServices” to you class and in 5 seconds you’ve created a Web Service

    Anthony Goubard

    August 4, 2010 at 9:40 pm

    • No graphical examples, no examples about swing (not even mentioned), no examples on how to read or write a file (who would need it) and I doubt there is any example on parsing XML, reading data from an URL, writing a html page, accessing a database, playing music …

      These are all just calls to JVM libraries which are all available to scala…

      With Java you also say add “@WebServices” to you class and in 5 seconds you’ve created a Web Service

      As above… in scala say add “@WebServices” and you have a web service.


      September 17, 2010 at 11:16 am

  25. The discussions between Cedric, Michael, & Martin regarding flatMap are interesting. I have found that the following four approaches all yield the same results:

    val email1 = userList flatMap (_.findUser(“bob”)) flatMap (_.email)

    val email2 = userList withFilter (_.name == “bob”) flatMap (_.email)

    val email3 = for {
      user <- userList filter (_.name == "bob")
      email <- user.email
    } yield email

    val email4 = for {
      user <- userList
      if (user.name == "bob")
      email <- user.email
    } yield email


    August 4, 2010 at 10:14 pm

  26. Scala is much more consistent than Java and the constructs are more powerful. This makes it possible to avoid complex workarounds with annotations, reflection, XML config, expression languages and so on. Java is just not powerful enough and thus all the complex beasts were invented.

    The only thing a really dislike about Scala is the use of cryptic symbols like “_”, “<:", ":\", or "<-". It is not worth to safe a few characters at the expense of readability. Python uses keywords like "in" instead of "<-" and a find it much more readable.

    But altogether Scala is the most impressive language I've seen so far.


    August 5, 2010 at 5:50 am

    • Hey! you can read my mind!

      Scala is impressive (modulo “_”, “<:", ":\", or "<-")


      August 27, 2010 at 6:57 pm

    • agreed.


      September 9, 2010 at 7:59 am

  27. “Scala too complex”. This is a ridiculous claim by someone that has never tried it out. On the contrary, Java is too complex, turns things difficult, makes programming a pain.


    August 5, 2010 at 7:01 am

  28. I would really like to see the equivalent Java code for this Path program especially from those that claim that Scala is too complex.

    “Too complex compared to what?”

    I would describe it like this:
    What’s easy in Java is trivial in Scala.
    What’s easy in Scala is doable in Java.
    What’s possible in Scala is impossible in Java.

    Of course a feature in Scala is more complex if doesn’t even exist in Java, but that’s a cheap comparison in my opinion.

    Compared to this chaotic mixture of Java, XML, expression languages, arcane build systems and annotations (what is considered ‘standard’ these days), Scala wins hands down.


    August 7, 2010 at 9:47 am

  29. Hi,

    I think there’s a problem in your Path example: the Path object hides the case class constructor. I get an error:

    error: too many arguments for method apply: (pathStr: String)Path in object Path

    Looks like you need an additional apply method in the object that mimics the case class constructor. (Or there may be a better way… I’m just getting started with Scala.)


    August 10, 2010 at 8:33 pm

    • Hi Richard,

      All my sample code compiles cleanly. What Scala version are you using?


      August 10, 2010 at 10:08 pm

      • I tried 2.7.7 and 2.8.0, and got the error with both:

        $ scala
        Welcome to Scala version 2.8.0.final (Java HotSpot(TM) Server VM, Java 1.6.0_20).
        Type in expressions to have them evaluated.
        Type :help for more information.

        scala> case class Path (origin: Char, destination: Char)
        defined class Path

        scala> object Path {
        | val PathRE = “^([A-Z]{1})([A-Z]{1})$”.r
        | def apply(pathStr: String): Path = pathStr match {
        | case PathRE(origin, destination)
        | => Path(origin(0), destination(0))
        | case _
        | => throw new IllegalArgumentException(pathStr)
        | }
        | }
        :11: error: too many arguments for method apply: (pathStr: String)Path in object Path
        => Path(origin(0), destination(0))

        But I’ve figured it out: if the code’s in a file Path.scala, the file can be compiled without error. It’s just in the interpreter that this doesn’t work.


        August 10, 2010 at 10:17 pm

    • Good to hear that Richard. I wasn’t aware that you were trying to define the companion object in the interpreter. A class and its companion object must be defined in a file and then compiled. Therefore you cannot define companion objects in the interpreter.


      August 10, 2010 at 10:59 pm

      • Ah, thanks for that. Probably mentioned in a “Programming in Scala” chapter that I haven’t got to yet!


        August 11, 2010 at 12:56 am

  30. You can define a class and a companion object in the interpeter.

    Either put them on the same line or put a simple object around both.


    August 20, 2010 at 10:30 pm

  31. […] Scala is too complex? 24 08 2010 There is currently lots of talk about Scala being to complex. Instead of more arguing I implemented the same bit of functionality […]

  32. Read also..
    Simple or Complicated?
    by Martin Odersky.


    August 26, 2010 at 10:48 pm

  33. […] The “Scala is too Complex” Conspiracy by WarpedJavaGuy. […]

  34. I don’t think people should dismiss the criticism. Ignore it at your peril, I would say.

    Scala will look alien to anyone who’s used to Java. That is for certain. When you are bombarded with all these “look, ma, I created this really complex thing in Scala in 5 lines of code”, people are stumped. They look at the 5 lines of code and can’t read any of it. That’s complex to them. Give them 50 lines of Java code and they will read it no problem – that’s simple to them.

    Before someone figures out how to give people a constructive soft landing or a ladder to Scala nirvana, you will be bombarded with “Scala is too complex”. Go back to the drawing board and write blogs about how to do the ABCs.


    August 27, 2010 at 2:55 am

    • Have you sat down and learned Scala? Have you given it a try?


      August 27, 2010 at 6:03 pm

  35. I’ve been programming in Java since 1.1 (1997), and I can’t describe how happy I’ve been since moving to Scala. I’ve already started converting some legacy Java code over to Scala as issues come up and generally I’m cutting my code in half (or more). Now, obviously there’s a danger of making things unreadable by whittling everything down as concisely as possible, but overall I find that judicious use of the higher function support in Scala’s collections combined with pattern matching contributes significantly to both reducing code and increasingly readability.


    August 27, 2010 at 3:45 am

  36. the thought ‘damn, this is complex’ has crossed my mind a lot since i started with scala. my problem (not scala’s problem): basic understanding of FP (i consider myself a junior when it comes down to FP), basic knowledge about the theory of programming languages, too many years of java programming. but i didn’t give up and the more scala i learn, the more i learn about programming.

    i hear some people say that when something is hard to learn, it’s not good. i don’t understand that statement. on the other hand my experience is that most people are rather enthusiastic when you show them tangible examples using map, flatMap, list comprehensions, implicits, factories, …


    August 27, 2010 at 11:36 am

    • If something is hard to learn it takes a lot of investment which needs to have a ‘payoff’ or it’s a waste of time. This is not religion man – software is just a tool. These Scala jokers need to grasp that if the vast majority of Java programmers look at Scala and are baffled – it *is* really hard to learn and that has a real cost. I’d like to take the time to invest in Scala more, but frankly, I know that at my company we will never use it for legacy reasons. Also, there’s no way some of the juniors are going to pick it up. Scala is far more of an academic excercise than these people realize. The Scala people need to spend a lot more time thinking about creating a ‘learning roadmap’ that introduces the concepts in pieces. If a Java programmer can’t make heads or tails of the examples, or at least have an intuition for it up front – then Scala will fail.

      ‘The market has spoken’ and Scala will fail to ever be adopted broadly, it’s just not worth the effort as it stands.


      June 20, 2011 at 2:53 am

      • Hi james,

        You said you’d like to take the time to invest in Scala more. Don’t let your company stop you! There’s never been a better time to learn Scala. There are so many good resources out there. Have a look at the latest slides and videos from the recent Scala eXchange 2011 conference in London. Download the new typesafe stack and have a play. See what they’re saying about Scala on twitter.

        I don’t care what ‘the market’ says. Learning is never a waste of time. Especially when you’re learning about programming.


        June 20, 2011 at 11:06 pm

  37. […] Easier to read (and write), harder to understand? There is a vivid discussion about Scala’s complexity going on for some weeks now on the web even with a […]

  38. […] Over the last weeks there have been heavy argumentation about simplicity vs. complexity of Scala. WarpedJavaGuy’s, Michid’s and Betrand’s Blog Posts flamed discussion and a lot of interesting comments […]

  39. I work at one of the busier websites on the internet (thousands of requests per-second). The original version was coded in PHP and several years back was slowly ported to Java, which made for great increases in performance, readability, etc… We found the code much easier to write, manage, reuse, and pretty much anything else you want from your code.

    In the last six months, we’ve started a similar transition, though this time to Scala. I can’t even tell you how happy we are with this decision. Code that once took up several files and took great pains to understand, extend or refactor is now a fraction of the size and infinitely more understandable.

    Sure, for simple problems perhaps Scala seems a bit too complex, but when you really do need the functionality of Scala, you find yourself exclaiming “I LOVE SCALA!” out loud several times per-day when you realize just how much work it has saved you. It makes safe concurrent programming, protocol implementation, advanced data types and many other things that are quite difficult and verbose in Java very concise and simple to read.

    I often feel like in Scala I basically write the code almost exactly as I picture it in my head.


    September 10, 2010 at 2:46 am

  40. So where does this leave Fantom? I’m scouring the web for reviews and opinions on Fantom and I can barely find any in spite of the fact that the apparent consensus is that Fantom does it.

    If it is easier to read than Scala, provides for functional and imperative and many other modern programmer ‘demands’, why is it that so few bother to even look into it or form an opinion on it?


    October 6, 2010 at 2:17 pm

  41. […] been various discussions, controversy, and gnashing of teeth about whether Scala is a complicated programming […]

Comments are closed.

%d bloggers like this: