Tuesday 22 November 2011

Scala feels like EJB 2, and other thoughts

At Devoxx last week I used the phrase "Scala feels like EJB 2 to me". What was on my mind?


For a number of years on this blog I've been mentioning a desire to write a post about Scala. Writing such a post is not easy, because anyone who has been paying attention to anti-Scala blog posts will know that writing one is a sure fire way of getting flamed. The Scala community is not tolerant of dissent.

But ultimately, I felt that it was important for me to speak out and express my opinions. As I said in my talk, if it was just me that had a poor opinion of Scala I would probably keep quiet (or try to figure out why I was out of step). But I perceive considerable uneasiness amongst many that have tried or looked at the language - something that reinforces my concerns.

Before I start I should mention that although I like the Fantom programming language, I also see merit in aspects of other languages - Groovy, Kotlin, Ceylon, Gosu, Xtend and many others. I also respect Clojure. By comparison, I really struggle to find positive feelings for Scala, and what positive feelings I have had have reduced over time. But why is that?

(For those not at my Devoxx talk, I tried to do two things - firstly to show Fantom off and explain how most simple comparisons to Scala rather miss the point, and secondly to point out some of the difficulties I have with Scala. To be clear, I'm not bashing Scala to promote Fantom. I'm bashing Scala because I think its entirely the wrong direction for the future.)

For this blog post Ive picked out a few key areas for discussion. I probably could have written a post 3 times as long as this one, and this one is very long as it is. There is lots to say about Scala, and very little is good.


Scala does not have a module system. By that I mean a deeply integrated system of modules that treats the basic program unit as something larger than a class, with versioning and dependencies. A key test is whether the new language compile modules or classes.

One of the greatest issues with Java is the lack of a module system. This absence has over time cause the platform to gain cruft (like CORBA) and struggle to shed it. The multi-year effort of modularising the JDK is evidence of how complicated this work is to do if not done from the start. And of course the Java platform will always have to support code not written in modules. Beyond the core JDK, most experienced Java developers have encountered the "Jar hell" scenario, where different versions of Jar files are required by different libraries and the ease with which it becomes impossible to assemble the whole application.

So, I have a clear sense that proper modularistion is a Good Thing, with all the versioned goodness that comes with it. (Managing change of a large application over time remains one of the largest problems faced by most large development shops, and one I don't see Scala tackling.) Over time, Java has evolved the Maven, Ivy and OSGi approaches to modules. Each has some benefits, but none are integrated into the platform itself, which is a significant disadvantage.

Yet, in a recent thread on modules, Scala aficionados claimed that Scala does have modules. In fact the opinion was clear - "see the object keyword", "Scala objects and path dependent types encode ML-style modules", "Also see http://www.mpi-sws.org/~rossberg/" (an academic paper). On further prompting, the ML view (standard source code can be used to express modules) was expanded on, before eventually the Scala approved way of using Maven/Ivy and the sbt tool was finally explained. There wasn't any real sense that this was a problem for Scala - so long as it integrated with the Java solutions that was fine.

I claim that integrating with Maven/Ivy is not fine. It misses huge opportunities to make life better on a topic where developers face real productivity issues in the field. Hence I commented that "Scala focuses on the wrong issues".

I also noted that backwards compatibility has been a constant problem of the Scala libraries. Modules are a tool for managing versioning and compatibility issues and would almost certainly have helped Scala evolve.

Finally, I noted that modules allow an application to find all the classes in the classpath/modulepath. This allows an application to find all the classes that implement an interface or annotation easily, which allows applications to be easily assembled from their parts. Java and Scala can achieve this, but only via complex and slow classpath scanning tools, like scannotation.


Scala makes a big deal about concurrency. About how the functional approach will aid the creation of safe multi-threaded code.

Except its really a bit of smoke and mirrors.

The big problem in concurrency is shared mutable state. It turns out that us developers are pretty bad at reasoning about it and using the tools at our disposal (synchronized, locks, java.util.concurrent) to manage that state. You'd expect that Scala would have tackled the concurrency problem at source - the shared mutable state - but it doesn't.

Scala (the language) does not know whether a class is immutable or not, nor does it provide a way to check is an object is immutable (Scala's libraries might help, but the language doesn't). As a result, it is perfectly possible to have a "static" (shared-thread) variable, or a "static" value of a mutable object. Its also possible to pass a mutable object to an actor and shared mutable state that way.

object Foo {
  var bar = "Hello"        // this is shared mutable state
  val baz = new Mutable()  // so is this

Tackling shared mutable state is not easy in language design. It involves designing the language to know about immutability, to track it, and to only allow immutable objects to be passed by reference to another thread/actor (mutable objects can be passed by copy). Done right, it eliminates the potential for concurrency issues from shared mutable state.

Scala relies on library design and discplined behaviour from developers to get this right (whereas Fantom builds this into the language, such that code equivalent to the example above will not compile). This is of course part of Scala's design approach - to give developers the power and trust that they will not abuse it. For me, this is simply another case of Scala failing to tackle the root cause of a big developer productivity issue.


Scala has a loud and vocal community, especially amongst those on forums and twitter. Some of these developers have gone on to create libraries based on Scala, in all manner of areas, from web frameworks to database access. This can have the effect of making Scala appear to be the "upcoming destination" where other developers think they should invest their time.

Unfortunately there are some aspects of the community that are much more negative. Scala appears to have attracted developers who are very comfortable with type theory, hard-core functional programming and the mathematical end of programming. Frequently, there is the sense of a brainiac competition, and an awfully large amount of argument of whether solution A, B, C or D is the right one when in reality they all do exactly the same thing (Scala typically offers many ways to achieve the same end result, something that Java sought to avoid, and something that tends to create more heat than light in debates).

There is also a sense that many in the Scala community struggle to understand how other developers cannot grasp Scala/Type/FP concepts which seem simple to them. This sometimes leads Scala aficionados to castigate those that don't understand as lazy or poor quality developers, as being second class citizens. This can easily lead into derogatory comments about "Java Joe" or worse.

My experience is that most developers are perfectly clever people, and perfectly capable of understanding many things if they are explained correctly. The classic example is variance in Java generics, where ? extends is needed. I find that it is perfectly possible to explain the issues to a developer, who will pretty quickly grasp why a List of Integer cannot just be assigned to a List of Number. However, what I find is that once the discussion is complete, and the developer solves their immediate problem, the explanation will tend to slip away. The problem is not that the developer isn't smart enough, its that the complexities of the type system isn't important enough to care about. Understanding the issue at hand, management priorities, the problem domain and the architecture/design of the large system they are working on are much more significant issues.

The Scala community is also infected with modern societies desire for more, more, more without considering the consequences (more gadgets, faster car, bigger TV, more money, more spending, yet bankrupt people and countries). Scala goes all the way with its language features - everything is about maximum power. And the community revels in that power, finding and exploiting every corner case that the power grants, without truly considering the harm it does.

Type system

Every time I look at Scala it feels rather like the type system fits the phrase "if all you have is a hammer, everything looks like a nail". Whatever the problem, the type system is bound to be part of the solution.

The trouble is that a big type system is inevitably a complex type system. The concepts added to support the type system have their own terminology which is instantly inaccessible without significant learning, from high kinds to type constructors to dependent types... Its all just a baffling mess of type theory that provides no meaningful connection to actual work that needs doing.

The trouble is that despite the pleading of aficionados, method signatures like this abound:

 def ++ [B >: A, That] (that: TraversableOnce[B])(implicit bf: CanBuildFrom[List[A], B, That]) : That

If you don't know Scala, you wouldn't have a hope of attempting to understand the code. In fact this is the equivalent to Java's addAll() on a list. (Its so complex that Scala tries to hide it from you in the documentation by giving you a simpler form instead.)

Oh, and by the way, I do get the idea that the humongous type system is there to prevent compile errors and pre-check your code. But applying that logic in the opposite direction would imply that no-one gets any real work done in languages with dynamic type systems. For me, Scala's type system is way way beyond the point of sensible returns for a language feature.

Steve Yegge's analysis was perhaps the most fun:

The... the the the... the language spec... oh, my god. I've gotta blog about this. It's, like, ninety percent [about the type system]. It's the biggest type system you've ever seen in your life, by 5x. Not by an order of magnitude, but man! There are type types, and type type types; there's complexity...

They have this concept called complexity complexity<T> Meaning it's not just complexity; it's not just complexity-complexity: it's parameterized complexity-complexity. ... I mean, this thing has types on its types on its types. It's gnarly

Steve uses Scala to argue for dynamic type systems. I disagree, and consider a static type system to be useful for documentation, communicating intent in a team and for basic error checking. But I don't need the world's most complicated type system to do that - I just need something simple and effective.

In essence, Scala's type system is giving static typing in general a bad name.


Scala's syntax is very wide open. It is the case that given a small piece of code (the kind that developers look at all day long) it is frequently difficult to reason about what that code does.

Scala has a big focus on flexible syntax with the aim of allowing a user to create a DSL in almost any form without having to write any parsing code. Instead, the developer just has to write a "normal" API, and use the language's syntactic flexibility to enable the ultimate end user to write in the desired style.

Take implicits, a technique that seems perfectly sensible to allow type conversions and object enhancements in a type safe way. Well, it may be type safe, but its also silent and very deadly. You can look a piece of code and not have any idea what is being converted. Unless you understand every import, every active implicit, their scope, their priorties and much more, you really don't have a clue what your code is doing. But thats OK, you didn't want to be able to understand Scala code did you???

Or take the fold operators and placeholder _, which produce delightful code like this:


Thats practically the very definition of line noise. (And I've not even shown any scalaz examples, or similar unicode weirdness)

By the way, if you're looking at Scala, you may come across conference presentations, blog posts and forums that show small snippets of code in Java and Scala and show how much less code you have to write in Scala, and how much simpler it appears to be. This is a clever trick. The real complexity occurs when you start mixing each of the seemingly simple features together in a large codebase, on a big team, over a period of time, where code is read far more than it is written. That is when you start to appreciate that some of Java's restrictions are there for a reason.


When evaluating a language, its important to get a sense of the quality of the implementation. This is useful for determining how easy it will be to maintain the current language and extend it in the future.

For this, I turn to the analysis by the core Scala committer, Paul Phillips, in a Scala podcast in June 2011 (selected elements):

The compiler is, and the libraries and language as a whole, its awesome but the number of places where features interact is astronomical. In order to really get the lid on that many feature intersections we need a massively comprehensive test suite, that we simply don't have.
[Question:] Its been suggested that you are skeptical of community involvement because there is no test suite? You're afraid that if anyone touches it but you the whole world will break.
[Answer:] I, unfortunately, continue to be bitten by extremely subtle bugs that come out because of the inadequecy of our test suite.
[Question:] Where do you want the test suites?
[Answer:] Collections
[Question:] Anywhere in particular?
[Answer:] All of them. There's no reason that many many many of the bugs we've seen in the collections over the last couple of years should ever have happened because they should be exhaustively shown not to exist by virtue of the tests that we have, but don't have yet.
[Question:] And what about the compiler?
[Answer:] An exhaustive test suite for the pattern matcher would certainly aid me in the process of finally really fixing it. It would be very very helpful actually.

An incredibly complicated language with very few tests? Sounds like a poor foundation to build real world applications on to me.

Specifically, note this line - "the number of places where features interact is astronomical". This is a key aspect of Scala. That each language feature is orthogonal and flexible. Implicits mean that code can be inserted almost anywhere (which slows the compiler, listen to the podcast). The ability to drop method invocation dots and brackets for parameters (to achieve DSLs) makes the meaning of code non-obvious, and leaves no spare syntax space for future enhancements. And these things combine to make a good IDE a very difficult challenge.

(If you're evaluating Scala for adoption by your team, I strongly recommend listening to the whole 40 minutes of the podcast. It will help you understand just what the real issues are with Scala, the quality of the implementation, and how difficult the language is to evolve.)


The EJB 2 spec was in many ways the nadir of Java EE, where huge amounts of boilerplate, XML and general complexity were foisted onto the Java industry. The spec was widely adopted, but adoption was followed by criticism. Developers found that while EJB 2 sought to reduce complexity in building an enterprise application through an abstracted higher level API, in reality it added more complexity without providing the expected gains. Documentation, best practices and tooling failed to solve the basic design issue. Spring was launched as a greatly simplified alternative, and eventually the much simpler EJB 3 was launched, a spec that had little to do with EJB 2.

As a data point, I attended a formal weeks training course in EJB. At the end of the course I knew that this was a very bad technology and that I would recommend against its use at every opportunity. Scala has exactly that same feel to me.

So, at Devoxx I said that "Scala feels like EJB 2 to me". The language is a well-meaning attempt to create something with a higher abstraction level. But what got created is a language that has huge inherent complexity and doesn't really address the true issues that developers face today, yet is being pitched as being a suitable replacement for Java, something which I find to be bonkers.

At the moment, Scala is at the stage of thinking that better documentation, best practices and tooling will make a huge difference. None of these helped EJB 2.

In fact one might argue that Java's biggest flaw down the years has been the architectural over-engineering of solutions, when something simpler would have done the job. Again, Scala feels very much in the mold of that strand of the Java community, over-engineered rather than YAGNI or 80/20.

Of course, neither Spring nor EJB 3 are perfect, but the core concept of injection appears to be easy to grasp and the basic mechanism of linking them simple. In particular, having easily cut and pasted sections of documentation proved very valuable. Having code that is easy to grasp where problems can be tracked down without needing a PhD in type theory is a Good Thing, not a bad one. Having code where you can work out what it does without needing to know every last detail of the "astronomical" number of language feature intersections is a Good Thing, not a bad one.

Of course the upside for Scala of my EJB 2 comparison is that EJB 3 is a lot better. Thus, it is conceivable that Scala could reinvent itself. But I would point out that EJB 2 and 3 are essentially utterly different approaches, happening to share a common name. I would say that Scala would need a similar reinvention from scratch to solve its problems.


I don't like Scala. And that dislike is increasing. Specifically, I do not want to spend any of my future working life having to write code in it.

Had Scala stayed as a remote language, for highly specialist use cases (like Haskell or Erlang) then I would have far less of an issue. But it is being sold as the solution for mainstream development, and for that it is as utterly unsuited as EJB 2 was.

Update 2011-11-24: Rather than respond to all the comments inline, I penned a response blog.


  1. > The Scala community is not tolerant of dissent

    In my experience this is completely inaccurate, dissent is constant in the community. What is not tolerated is stupidity, unthink or fud. The Scala community contains amongst it a very bright set of individuals who do not let even confirmed Scala enthusiasts get away with the slightest exaggeration and will passionately debate many a sacred cow.

    Being called for talking rubbish is a humbling experience, and one that many do not wear well, especially people who are used to being "experts" in their field. I have been humbled many a time in my interactions with the Scala community, but I am extremely enriched by the experience – and have learnt a lot from it.

    1. There is a difference.

      What you describe is my favourite kind of engineering environment. That kind of informed, challenging, and passionate community creates a playground for the mind. A critical element though is the the social convention to "attack the idea and not the person". In addition, it is not just about debating other people's sacred cows but about being excited when somebody questions your own.

      The environment you describe is much as the scientific community should work. Dissenting ideas are either an opportunity to advance your own understanding or a chance to display your intellectual prowess (depending on if the dissent proves well founded or not). Unfortunately, personal attacks and self-evident truths are a big part of the arguments that I have seen Scala fans wage.

      > The Scala community is not tolerant of dissent

      In fact, it is much worse. Many Scala fans will not even tolerate the peaceful promotion of competing technologies. As an outsider, it feels as though the Scala community is very frustrated that the rest of will simply not shut-up and drink the Kool Aid and is getting impatient waiting.

  2. I must say I find it hard to reconcile this passionate hatred of Scala and any rational explanation for it. While all your reasons are are refutable in details and some are plain wrong, some are definitely in the ballpark.

    In particular, the fact that Scala is not an opinionated language, that it doesn't make you conform to one paradigm or style or another, that it is a big powerful beast, can be a problem. It means that people can write bad, very bad, Scala!

    It also means that people can write some beautiful, extraordinarily powerful code in Scala – code that cannot be written in most other languages.

    1. So what you're saying is that Scala is freedom but not freedom from responsibility? The argument that a language should force all programmers to write code in exactly the same fashion is absurd. It is a hail-back to 1984; what I mean by that is Apple's 1984 commercial designed to undermine the monotony of the way people solved problems in that era. It would be like regressing back to those days before the Apple revolution.

      That is fundamentally insane!

      If we cannot trust each other to write code responsibly, we cannot trust each other to do anything responsibly. So then say hello to your new fascist dictators, and if you don't like it then off to room 101 with ye.

      For every time this criticism is leveled against Scala I demand the acknowledgement that JavaScript is worse, otherwise I consider the argument invalid.

  3. ++ is not Scala's equivalent to List.addAll in Java (appending a collection of elements to a mutable list). That would be ListBuffer.appendAll which, thanks to declaration-site variance, has a simpler definition than in Java:

    def appendAll (xs: TraversableOnce[A]): Unit

    The ++ method for immutable collections has no equivalent in Java because it is not possible to express this concept in Java in such a generic way.

    1. Yes I'm a Scala newbie, I only discovered it less than five months ago and I'm struggling to see what is complicated about:
      val coll2 = List(1, 2, 3) ++ Set(3, 4, 5)
      //result: List[Int] = List(1, 2, 3, 3, 4, 5)
      Set(1, 2 ,3) ++ List(3, 4, 5)
      //result = Set[Int] = Set(5, 1, 2, 3, 4)
      That strikes me as the height of simplicity. I think the signature above is to enable something slightly more generic like:
      List[Car](FordEscort, Porsche911] ++ Set[Truck](MercedesAxor, VolvoFH)
      gives result: List[Vehicle](FordEscort, Porsche911, MercedesAxor, VolvoFH)
      But again what could be simpler to use than that?

    2. I hear you.

      I am a Scala newbie as well, and before Scala I was a complete FP virgin. But I feel it took me no more than 2 hours to ramp-up and become productive FP in Scala whereas many of my peers struggle to grasp the language and FP in general. What I notice is that when I step-in to assist, they keep polluting their approach in Scala with imperative styles and it always seems to be the source of confusion.

      If you try to force Scala into your Java paradigm of course you're going to hate it.

      One thing that may have helped me is that over the past five years I developed a keen interest in mathematics and in-particular vector calculus as a hobby apart from my career. Applying that mindset to learning FP may have eased the learning curve. Another thing that helped me was reading-up on Alonso Church.

  4. Nice article, but be wary, the flame war is about to begin. Good luck with zealots!

  5. It looks like Scala is ultimately attempting to give us the benefits of Haskell on the JVM.

    And the only problem at the moment is that you basically have to read a book on Haskell in order to fully appreciate these benefits.

    So far they're looking fairly compelling to me, and I can see them becoming mainstream, once the right books start to appear.

    1. > It looks like Scala is ultimately attempting to give us the benefits of Haskell on the JVM.

      Actually it would more be Frege which aims to do that.

  6. There are many comments you make here regarding scala which resonate. The analogy with EJB2 is not one of them. I recollect the horror of EJB1 and EJB2 even as I went through those routines and then at the first available opportunity threw them away. EJB1 and EJB2 was just weight and boilerplate. The benefits they promised were really questionable in the first place (eg. why would one want to have entity beans all remotely accessible?) and the scalability they promised actually slowed down the web app even as it was starting up.

    Scala actually has many many benefits. Too many to really start recounting here. It is a struggle weighing these benefits with some of the costs you mention and some that you don't. But I would imagine the result is not as one sided as one might imagine. Scala is really like flying an aircraft while java would allow you to drive the car. Large benefits compared to large learning curve. EJB just put you into a hummer with a cockpit like interior and then took you down a dirt road and just guzzled up gas like crazy.

    There is another comment you mentioned resonates with me quite a bit. "There is also a sense that many in the Scala community struggle to understand how other developers cannot grasp Scala/Type/FP concepts which seem simple to them." This used to bother me. Now I realise the scala landscape is made of both kinds of people, some of them very helpful. Best to ignore the parts where some wonder why others find scala difficult to learn.

    1. > Now I realise the scala landscape is made of both kinds of people, some of them very helpful. Best to ignore the parts where some wonder why others find scala difficult to learn.

      This is a helpful comment and important to keep in mind. Sadly, the "everybody else is an unworthy idiot" will push many people away. From where I sit, it is striking how much less defensive and hostile the Clojure community is for example. So, it appears this is not just a functional programming community thing.

    2. I do not fully agree to the points about the complexity - you like other non-Java languages, but at some point you appreciate that Java kept things simple. They kept things so simple that Java codebases are infested by boilerplate accessors which people have to avoid to get to the real code.

      Just a brief point about the community harshness:
      > So, it appears this is not just a functional programming community thing.
      Clojure is (IIRC) dynamically (not statically) typed, and I believe that makes a big difference. This attitude seems present in the Scala, but much less than in the Haskell community.

      The reality is that "hard-core functional programming" in strongly typed languages like Haskell has a really steep learning curve but also amazing benefits - in essence, it's mathematics (category theory in particular). Unlike in OOP, abstractions can be much more general, and much more generally applicable. However, the process of abstraction _is_ somewhat hard - and it just takes time to get it. Moreover, I've seldom seen that coding style in untyped languages, and I strongly suspect that it's because it wouldn't work well.

      However, Scala does not require you to get to that point. You can program in a simpler style. If that's your choice, I guess you want to stay away from Scalaz - also because they seem to target experienced Haskell programmers anyway since they have little documentation.

  7. I think if Java veterans with their sense of entitlement for life-time employment safety feel so threatened about another language that they have to resolve to such FUD tactics, the language is on the right track.

    Great that the future language actually tries to solve problems instead of choosing the "programming is hard, let's go shopping" strategy.

    1. Hmmm... I'm no apologist for the OP, but this response addresses is unhelpful. It acknowledges and addresses none of the points made. It's lazy to serve arrogance, rudeness and blanket black-and-white opinion, where only explanatory content could help the Scala cause. This seems to me textbook reinforcement of the OP's point about some in the community.

      Maybe the OP has some degree of misinformation and biases and is not getting an objective picture out? But it's legit to have concerns and raise questions, seeking answers. He deserves the assumption that he's objectively trying to understand the strengths and weaknesses and is not an entrenched Scala 'hater'.

      One of the most important, if not the most important, traits in achieving success in any grand and complex team endeavour is the ability and willingness to objectively self assess, critique and address weaknesses. Another is the ability to communicate well the available features, nuances, approaches and best practices to help all on the journey and grow numbers and capability. Think about it. The subject matter raised, does have the potential to negatively impact. He cross-references cases where this has happened elsewhere. This is not trivial stuff, that can be swept under the carpet.

  8. I find scala to be overwhelmingly complex, perhaps that is my limitation but I firmly believe that a language be simple. If something "powerful" can be used for good or for evil, it will serve the evil path more often than not. Hey even the GOTO statement can be used for good; but there are not many engineer advocating it nowadays, for good reasons.

  9. Life is complex, software development is to. Why do people believe that a simple tool exists to solve complex problems? If you use a less powerful language to solve a complex problem the solution will NOT be simple. Take a look at Greenspun's tenth rule. ;-)

  10. There are many valid points, some like the fixation on type theory can also be found in my "Scala is unfit for serious development" rant from last year


    But as one who was an EJB2 user, I think your comparison falls flatt on logic.


  11. The only reasonable reaction I've read so far is pointing out the used method signature is not comparable with addAll in Java.

    The rest of you should do a bit better to point out which parts are wrong and admit which are right. For example I find the issue with Scala being backed by a poor test suite to be very alarming.

    Otherwise I don't have a preference for Scala or anything else. But I do know Stephen is a proven, competent developer. I also know that when I listen to some Scala guys *cough* Martin *cough* then I am annoyed with him not practicing TDD.

  12. I have no belief in languages like Scala and Haskell. People get mesmerized by the powerful expressions and the cleverness of it all, but forget how long time they spent learning it and that most developers are not going to bother spending that much time on a language. I think Clojure is a much better alternative. It is powerful and cleverly designed while at the same time being fairly quick to learn. But it is hard to predict the future. I think if Clojure fails it will be because of the alien syntax. Scala probably has more immediate appeal in the familiarity of the syntax.

    For new developers it is easy to fall into this trap. As a new developer I thought C++ seemed much simpler than Objective-C, because the syntax seemed more similar to C. It took many years before I realized how wrong I was and that Objective-C was a much simpler language despite the weird syntax. But that happens because on only uses a language in a very superficial manner when one is novice. I think Scala vs Clojure is a bit like C++ vs Objective-C. Scala might win despite its complexity but years down the road people will bang their head in the wall when they realized the mistake it was to go with Scala.

  13. This criticism makes a lot of sense. There is a large movement in the programmers world to make things simple. CoffeeScript and Dart being prime examples of this. Both languages I picked up within the hour cranking code with it. Scala is still a big gibberish, even after writing code in it for a few days and reading about 1K loc.

    From this perspective, KISS > correctness. (you may make that a few more >>>>> )

  14. "If you don't know Scala, you wouldn't have a hope of attempting to understand the code." This statement holds for pretty much every language. If I come across a sentence written in Chinese I will have no hope of understanding it without learning Chinese. What does this say about the language? Nothing, it just says something about me not understanding it because I didn't learn it.

    This article is stuffed with ignorance. There seems to be a point in a programmers life where he or she seems to think that there is nothing new to learn. I recall that when I started programming at a young age I had problems with grokking for-loops. However, I did learn how they worked and how to benefit from them. 16 years after that I encountered Haskell, I was totally baffled and couldn't get anything done. The way of thinking just seemed completely different to what I knew. However, I started learning what it was all about and it made sense. It was a humbling experience, something that helped me to evolve as a programmer, a profession that I enjoy like nothing else. I now write code that is more concise, maintainable and reusable. My co-workers (most of then aren't functional programmers) enjoy reviewing it and adapt some of these techniques.

    Bottom line: If you don't care about evolving, that's fine. Just quit whining that others care about learning. If you were a horse breeder in the end of 19th century you'd probably get mad about the invention of the automobile. Progress happens, enjoy adapting or perish.


  16. I started with scala after java because it was the only statically typed JVM language that offered conciseness of syntax (type interference), and closures, and a large community.

    Now I also use Options, Either the nice pattern matching + regex, for-comprehension etc... and learging this really starts to pay off. All the 'astronomical' number of language features actually do fit together.

    It seems that forming a company makes the language creators even listen more to java.joe: now scala will also get string interpolation.

    The type system on the other hand is complex and I understand if people are intimidated by it. The argument of "don't use it if you don't like it" fails because most people really want to know the ins and outs of the tools they use every day. On the other hand, many tools in java land also have a vast complexity: AOP, spring, seam @in @out ....

    I think there is no way around complexity.

    My only issue with scala at the moment is the slowness of the compiler (which got faster in recent releases) and maybe some members of the community. While often providing valuable insights, they communicate this in a rather rude way, maybe to motivate, but it actually turn people away.

  17. Its the same as the Ruby community. The worst of the dynamic typers left Java and stayed in Ruby and that extremely toxic community. The same is true of Scala and its toxic community. Scala tied the scripting superbowl this year by trying its very best to not be like Scala, a fact Martin himself cannot bring himself to fully accept. I just hope the Scala people leave the JVM community completely and never come back.

  18. Smart languages are smart tools for smart developers.

  19. Well, it's just a little silly to make statements like these. As i see it, Java is a "enterprise software" de facto standard labguage. Scala is difficult and mixed-paradigm language that has by it's deffinition smaller user base and target domain. Some tools are harder to learn, some simpler. I have used (for my paid job) Lisp (Clojure), Java, Scala, C, C++, Javascript, Python, Ruby and PHP. And for some hobby projects also a bit of Haskell. I would not criticize any of them in a manner like this. Of course, some of them are simpler to learn and some are more cumbersome and so on. Lisp is just stupid simple, compared to any other language, but can quickly get unmanageable like other dynamically typed languages. Java is verbose, linear and often cumbersome but it is basically only language option for big "enterprise" applications, because of loads of libraries/tools and available developers. PHP is just weird DSL/frontend for thousands of compiled C functions with a additional translator/compiler hack for OOP capabilities. C++ without extensive use of all kinds of smart pointers, is basically suicidal (dont get in there :D) :) Haskell has best type system, that i have ever used, but is really (i mean really) hard to grasp in the beginning (type system and especially concepts behind pure fp). Scala is compromise between Haskell and Java. And i often miss it's functional capabilities when developing yet another Java "enterprise" application. I would not replace Java with it, but there are areas, where java looks verbose and stupid compared to funcional language. For example when dealing with collections (all kinds of sorting, grouping, filtering etc.). At the same time i would not use Scala as API language for internal or external components. I would use it behind API-s for tasks, it is better suited, than Java.

    A tool for one problem domain can not be criticized, using arguments from other domain.

  20. Stephen -

    can you please, for the sake of full disclosure, tell us what actual experience you have using Scala? Is it "Hello, World"? A tutorial? A web app? Your team's prototype? A real app in production? Or is this (as I fear) armchair analysis, with no basis in experience? All of us can form opinions on things we have only read about, and never tried. What have you actually used Scala for? And what have you actually used Fantom for?

    I say this because when I asked you last year, around the time of the Devoxx 2010 conference, what your practical experience with Scala was, my recollection is that you answered, "None." Perhaps I mis-remember, or you've done work in Scala since then.


  21. I'm a Scala aficionado, so I disagree with a lot of what you've said above, but there are things I do agree with.

    The comparison to EJB is silly. EJB made you implement like a billion interfaces and boilerplate to get anything up and running, and then it had to be deployed inside of an EJB container which were only offered (at first) at premium prices by large software vendors. Scala does not suffer from that, and really does an amazing job of eliminating boilerplate. In fact you praise Spring for oustering EJB - well, Scala eliminates the need for Spring. I used to love Spring for the same reason you do, but now it feels like boiler plate to me. Scala is so expressive you can do all of your dependency injection with constructs in the language, have you get compile time checks for free! http://jboner.github.com/2008/10/06/real-world-scala-dependency-injection-di.html

    You suggest that Scala doesn't solve the concurrency problem but that Fantom does by offering immutable collections and the actors pattern. Scala offers both of those, and their collections library is amazing. And that said, the actors pattern still suffers from deadlocks and race conditions. I also find the actors pattern a difficult paradigm for building complex systems if you want to avoid deadlock and race conditions - async is hard! I'm much more in favor of using STM in most situations where a concurrency control is needed. Also, Fantom offers Java interop, so I doubt you can avoid mutable state entirely, something Scala and Clojure both suffer from.

    That said, yeah the type system is hard. It took me about 6 months to really grok it. That said, I was able to get a lot of work done anyway. You kind of chose a straw man with the method you chose. You don't need to know what any of that stuff means to get things done in Scala, but once you do know it, you can really exploit it. Static typing is powerful, and I really think it's worth using as much as possible. If you're not into using the type system to it's fullest, I think Clojure is a great alternative. Choosing a language that's in the middle, like Fantom? Maybe? Maybe that's alright as long as the community is big enough, but I'm not convinced it is.

    There are some things that annoy me about Scala. It takes forever to compile. That drives us all a bit nuts, but sbt solves some of that. Also binary incompatibility is pretty annoying. If you want to be an early adopter of the newest version of Scala, you're going to have to wait until your dependent libraries upgrade, or do the upgrades yourself.

  22. Aklını alırım len senin. İt herif sen kimsin JVM de istemiyon bizi. A.q'rum richard başgan!

  23. I'd really like to see the people who like Scala refute the points made in this post, instead of simply calling it FUD. Are the code examples really crazy? Are they exaggerated?

    Personlly, I have been programming professionally for over 10 years and I picked up a couple of languages on the way, among them Perl, Java, C#, some Scheme and Ruby. Ruby, for example, was a great experience. I love that language, even though I came to the conclusion that statically typed languages are more for me. I tried to like Scala and failed. When I compare the way Scala presented itself to me and how Ruby presented itself to me, well, there is really no contest in my eyes.

    In short, the burden of proof that Scala is great language, indeed lies with the people who use it and love it. Show us what cool things you can do. Show us how cool the language really is.

    Me, I am not convinced and I am inclined to agree with Stephen.

  24. @Norbert
    see http://www.reddit.com/r/programming/comments/mlbna/scala_feels_like_ejb_2/

  25. @Norbert
    There's not much to refute, other than some strawman arguments he sets up, like this:
    def ++ [B >: A, That] (that: TraversableOnce[B])(implicit bf: CanBuildFrom[List[A], B, That]) : That

    You don't need to know what everything does in that statement. In practice It looks like this,

    scala> val listOne = List(1, 2, 3)
    listOne: List[Int] = List(1, 2, 3)

    scala> val listTwo = List(4, 5, 6)
    listTwo: List[Int] = List(4, 5, 6)

    scala> val listThree = listOne ++ listTwo
    listThree: List[Int] = List(1, 2, 3, 4, 5, 6)

    And that's totally understandable, and not needing any explanation. As you move along in your Scala development and become more familiar with the type system, you start to understand the type declaration in the method signature, but that knowledge is not necessary to get things done, just as it isn't in Java.

    Also is fold Left example can be rewritten as below if you prefer it to be more verbose for readability:

    scala> val l = List(1, 2, 3)
    l: List[Int] = List(1, 2, 3)

    scala> (0/:l)(_+_)
    res14: Int = 6


    scala> l.foldLeft(0)( (accumulator, num) => accumulator + num)
    res13: Int = 6

  26. After writing my previous comment, some other issues came to my mind, that I would like to warn beginners of scala:
    a) functional code can be slow, when what you want to do is looping over primitive arrays (and yes, I have to do this a lot). then one has to use while loops, because there is no real for loop in scala (and break is a library construct).
    b) sbt is even less documented than maven 1.x was and plugins break even more often. And having a real language for configuration does not help - but its a rather new project, so given time... and I start to like it now.

    Having said that, people that like static typing and are allowed to experiment should really give it a try.

  27. @Dustin:

    >> Also is fold Left example can be rewritten as below if you prefer it to be more verbose for readability:
    >> scala> (0/:l)(_+_)
    >> //rewritten
    >> scala> l.foldLeft(0)( (accumulator, num) => accumulator + num)

    His point is not that it cannot be rewritten to be more easy to understand, his point is that Scala allows things to be written in such a hard to understand syntax in the first place. Not many people want to deal with code that looks like the first version.

  28. FP is a different programming paradigm and not for non-lambda ultimate types. The "Fantom Programming Language"will excite developers who write code in crayons on walls. You re-iterating what Martin echoed long time back.. Scala is not that simple to be understood by any Java Joe developer (pun intended). Making the syntax simple does not solve "problems"

    Concurrency explanation of yours is CompSci 101 (IMHO). Fantom is not solving a dang thing either.. Fantom is solving the concurrency issues by using a magic wand and a fuckoconcurrendum charm... oh no.. wait.. the Actor Model (Which is the what is implemented in Scalal)...

    From Fantom site:
    Tackle concurrency with built-in immutability and actor model."

    The comparison of EJB2 is just too childish.. that is like comparing a Spaceship to a Car and saying ... stupid spaceship.. so complex.. useless on the road.. does not even have good fuel economy...cannot understand a dang thing.. as useless as an old goat.. I will build a bicycle with one wheel (Fantom) to fly to space and then will ride it on road.. who knows some one will come out with a submersible version which will allow me to drown myself one day.

    Please take a look at Play 2.0 framework to understand why Scala like languages are required to solve problems for the new web.

    Loads of people including twitter, foursquare use scala.. in fact twitter replaced ruby with scala... while fantom is being used to build .. wait.. nothing... he is just a Fantom fanboy who talks nonsense when Fantom is trying to do exactly what Scala is doing...


    1. > "FP is a different programming paradigm and not for non-lambda ultimate types"

      ... and then ...

      > "Making the syntax simple does not solve problems."

      Heard of Lisp, FP noob? Sounds like you haven't made it out of CS 101 yet yourself.

  29. @Dustin Thanks. Actually, you are showing me how easy it is to use the ++ operator, but not how easy it is to decipher the declaration of the operator. Which was Stephen's point of criticism, I think. It's easy to use though, I agree.

    As for the folding operation, the point is, that in larger teams you'll always have people who prefer ultra-verbose code compared to the style you showed as a more readable example. Heck, I know that some of my old Perl code I would have a hard time reading nowadays. Are you are claiming that this is not a problem?

    @Anonymous I'll check it out.

  30. Sorry. I meant "ultra-concise", of course. :)

  31. I've only evaluated Scala at the surface, but simply want to back up Stephen in agreeing with the subjective scary feel of the language. I can think of no other languages where I've scanned examples and documentation, and wanted to run away as I have with Scala. This is in stark contract to i.e. Fantom, C# and even F#.

    My gut instinct tells me that the elite developers (that you be most people going to Devoxx and the bulk of the people reading this blog entry) have already moved on from Java and adopted the first apparent superior language in sight. It's interesting how busy Scala developers are with removing code and cooking uncritically with the complex type-system, almost to the point that it resembles kids getting a new toy.

    My hat off to Stephen for speaking his mind. And please, can we not consider this FUD just because some people don't share your enthusiasm towards a language?! Now who I'd really like to hear evaluate the language from an expert view, are neutral pragmatic people who have experience beyond academics, like Anders Hejlsberg, Gilad Bracha, Bjarne Stovstrup etc.

  32. @Norbert @Anonymous The point is you can write hard to read code in any language. You mentioned Ruby which is also a very flexible and powerful language. Metaprogramming? Monkeypatching? syntax a la ruby poetry? Ruby hooks? http://hasno.info/ruby-gotchas-and-caveats etc?

    This does not mean that ruby is a bad language just that it represents a tradeoff (ie flexible syntax, powerful metaprogramming etc.) which might appeal to some and might be a big turn off for others.

    @Stephen: I found it very sad that you want to be taken seriously while showing only a one sided argument and advocating another language.

    Scala represents a tradeoff and yes (surprise), it has its own issues but to say that there is nothing to like about it is certainly dishonest.

    Case in point, influence on java: in the java 8 devoxx talk we heard about traits, parallel collections, closure syntax (very similar to scala) and type inference.

    Anyway, if anything your post just shows that Scala must be onto something if you bothered to express so much hatred without even trying to be objective.

  33. Sigh: Obviously, Steven is not an old twat, just like disagreeing with him won't make me one.

    I agree with a number of the points,
    - Lack of module system, like Java
    - Binary incompatibility is a problem
    - Too few tests in the compiler (although a lot of advanced compiler modules are extras, that you'd have to turn on to get in trouble with)

    -- however, I think comparing it with EJB2 is unfair. I can see how such a comparison would be catchy in a presentation, but I gather that those who've adopted Scala has done so because it suited their needs, not because the vendor told them it was the new big thing. EJB2 was not evolutionarly refined like Scala was, it was what the commitee could agree on.

    The marketing behind Scala is not pushing Scala as a Java replacement (but something which works well on the JVM), and Scala isn't necessarily the "next destination" for Java developers - that's predictably Java 8 (provided it keeps its schedule) simply because it's Java, and so has the lowest cost of switching. Nobody is forcing anybody to use Scala. And nobody is forcing you to use implicits, and other crazy stuff, in your code.

    I've found Scala to be a fairly welcoming language and its community equally so, but I fully understand how the "Scala is too complicated"-mantra becomes a nuisance if it is primarily chanted by people (not Stephen) who've just read blog posts about some of the advanced things you can do with the e.g. the type system (Monads, Typeclasses, stuff in scalaz, whatnot) instead of going the sane "Getting started" route:
    That would be like calling Java complicated because you've read an article on byte code enhancement, and tried to apply that(directly) to the Petstore sample, and got something backwards through lack of understanding.

    For those who are curious how the language alternatives work for you and your team: Try them out, and make up your own minds, read the constructive or comparative language reviews -- you can tell them by that they have less senational value.

  34. btw - I think Joda Time is awesome

  35. @Carl Thomas You are making a lame argument. Of course, you can write convoluted hard to read code in *any* language. The question is, does Scala invite you to write clean, easily readable code? Well, maybe it does for you. Probably it does for Martin, Lex and other Scala gurus, but by and large, when you work on a team, where people are learning as they go, does Scala help in this respect? You have probably more experience than I do, so you tell me.

    As for accusing Stephen of expressing hatred, being dishonest and one-sided, I think, that's a classic ad-hominem argument. He did not start calling people bad names, but expressed his impressions of a progamming language. Arguing in this way does not help your cause.

  36. @Norbert If you have experience with Ruby (I think you mentioned that), the experience is very similar (powerful language, flexible syntax). For bigger teams the key really is to provide proper guidelines.

    Not sure what kind of proof or answer you would find helpful. There are serious enterprises (big and small) successfully using scala with diverse groups of developers. To be honest it sounds like as if you already made up your mind and that's fine as I do not think scala is perfect (far from it) but neither you nor Stephen is forced to use it.

    As for my comment being an ad-hominem. The only thing I was criticizing is the tone of the post which is very one-sided (I do not like Scala, there is nothing good about it, I do not want to use it). How is that ad-hominem? Along the same way, you called my argument lame, was that a comment on my character? Seriously, the only thing I was missing was some technical depth (you know, explaining the tradeoffs for example).

  37. I've been using Scala with various projects and have had very, very good experiences with it. I think the language design is brilliant. Sure that method signature presented above looks intimidating ... but that comes from the fact that many of the language 'constructs' are provided as libraries rather than built into the language itself. This makes for a very flexible and extensible language. The down-side is that developers get to see details that, in most languages, are buried inside the language runtime. That method just adds two collections together in a type-safe way AND returns the appropriate type of the collection (List, Seq, etc). Here's an example:

    // concatenate 2 lists of integers; return a list of Ints
    scala> List(1, 2, 3) ++ List(4, 5, 6)
    res0: List[Int] = List(1, 2, 3, 4, 5, 6)

    // concatenate a list of integers with a list of Strings; return a list of Any (i.e. Object)
    scala> List(1, 2, 3) ++ List("A", "B", "C")
    res1: List[Any] = List(1, 2, 3, A, B, C)

    // Concatenate a Seq with a List; return a Seq
    scala> List(1, 2, 3).toSeq ++ List(4, 5, 6)
    res2: scala.collection.immutable.Seq[Int] = List(1, 2, 3, 4, 5, 6)

  38. This comment has been removed by the author.

  39. @Norbert, it's easy to be pulled into an ad hominem battle when your opponent leads with an ad hominem attack: "The Scala community is not tolerant of dissent."

    Now, to counter his arguments instead of him as a person!

    1. Modules. No JVM language besides Fantom is trying to address this. It is not a weakness of Scala but a strength of Fantom. What a strange coincidence!

    2. Concurrency. Scala handles concurrency better than any other JVM language right now. On the other hand, the only languages I know of that track purity are Haskell and DMD. Once again, Scala is pretty much state of the art here and the "weaknesses" he points out really aren't weaknesses.

    3. Some prominent members of the community are from the Haskell world. So what? If they think its fun to encode Haskell constructs in Scala, let them do it. The author shows himself to be a follower of the Scala mailing list and community by quoting from it. Did he bother to quote how Martin Odersky refuses to add IO monads even though the Haskellites want it? Did he quote where Martin says that scalaz is on another planet entirely, inferring that he doesn't expect normal Scala use to have anything to do with it? Did he quote where Martin publicly asks library writers to stop using symbolic names unless they have external real-world meaning? In reality, the vast majority of Scala users are not from Haskell and do not use it that way.

    4. Type system. Yea, it's complicated. It's also amazing. There is a tradeoff here and not everyone is going to be happy with it. If I'm going to have to be shackled by a type system, however, I'd rather have a good one Like Scala's rather than Fantom's.

    5. Syntax. Scala's syntax is specified by a relatively small number of well-defined rules. Once you learn those rules, it is easy to read. In the end, readability is a subjective thing, but I think what he is saying is just FUD, and I've learned a lot of programming languages to get an idea of readability.

    6. Quality. Scala still has some rough edges, but no more than any of the other languages and runtimes that are of a similar age as Scala. This is again a tradeoff over using a more mature technology like Java, and, yet again, the author is being very unfair to Scala.

    It's a shame when a prominent blogger uses his position to spread bad information like this. I appreciate that he prefaced the post by explaining that this was mostly his opinion and that he is biased. However, I would have tolerated it better if he were more honest or showed a better understanding about why Scala does what it does and what the tradeoffs are.

    1. "The Scala community is not tolerant of dissent":

      Well, the comments herein provide some fair evidence towards this.

      Scala is going through a phase of being new kid on the block, trying to setup for an advanced future. That's very tough, with challenges to get right across spectrum of areas. It's reasonable, nay *great*, to ask challenging questions. Many of the 'answers' here are fanboy/flame 101. The OP should be thanked for writing and reasoning to the extent he did. The onus is on the community to answer - which, properly done, should probably take 10 times more reasoned content... Anyone? Please?

  40. With all the hype behind Scala I curiously looked at it and then put it away. Now, that I see all these negative comments from the zealots, I'm glad I did. I think the OR is trying to put together an objective criticism, and instead of trying to see it from his perspective you are burning him as if he spoke against god in the middle ages. If you guys represent the scala community, then no thanks! I don't want anything to do with your language or your community. I'm sure you're all bunch of smart guys and rest of us are not good enough for you to begin with.

  41. "Modules. No JVM language besides Fantom is trying to address this. It is not a weakness of Scala but a strength of Fantom. What a strange coincidence!"

    In fact, Fantom, Kotlin, and Ceylon are all addressing this problem.

  42. @Gavin: Until Kotlin and Ceylon are actually released they aren't addressing any problem.

  43. If scala has its own VM, things gonna be better. Modules, Immutable, and simpler type system.

  44. I want to clarify one thing. When Scala people say that Scala has a rich module system they're right. When Stephen says Scala does not have a module system he's right. What gives?

    The phrase "module system" is heavily overloaded and different communities mean different things by it. Scala people mean something like the SML module system, Stephen means something more like OSGi or Jigsaw. Neither is particularly more correct usage of the phrase - both have a lot of history behind them.

  45. "@Gavin: Until Kotlin and Ceylon are actually released they aren't addressing any problem."

    I was responding to the statement that "No JVM language besides Fantom is trying to address this." Which is clearly incorrect. Two languages are trying, and it's highly likely that they will succeed.

    I'm not sure why you felt it necessary to take a cheap shot.

  46. "The phrase "module system" is heavily overloaded and different communities mean different things by it.Scala people mean something like the SML module system, Stephen means something more like OSGi or Jigsaw. Neither is particularly more correct usage of the phrase - both have a lot of history behind them."

    Yes, James is absolutely correct on this.

  47. "If scala has its own VM, things gonna be better. Modules, Immutable, and simpler type system."

    Actually I think it's the Java SDK, and the need to interoperate with it, that is the problem, not the VM itself. I think if you drop or pare back the requirement for interop with the SDK, the things listed above become *much* more manageable.

  48. @Gavin
    "If scala has its own VM, things gonna be better. Modules, Immutable, and simpler type system."

    Actually I think it's the Java SDK, and the need to interoperate with it, that is the problem, not the VM itself. I think if you drop or pare back the requirement for interop with the SDK, the things listed above become *much* more manageable.

    What about Menifest, @tailrec and trait incompatible problem and null?

  49. Too much feeling and not enough thinking. You seem to start with a conclusion guided by what Scala "feels like", and then rationalize that conclusion so that you can be comfortable with it. Fortunately none of us have to take your feelings seriously in order to get our work done.

  50. I agree the type system can be daunting at times but you don't need to understand all of it to be productive in the language. It does truly scale to developer needs. The problem is we have a lot of well-meaning blog posts and articles that are basically treatises on type theory and IMHO they detract from mainstream usage of the language.

  51. "I'm not sure why you felt it necessary to take a cheap shot."

    A 1000 apologies, no cheap shot intended. I was just pointing out that if my boss came and said "We need a module system", I couldn't use Kotlin or Ceylon; they're not even released yet. Hopefully someday.

    Anyway, personally, I'm excited about all the new languages being developed on the JVM. Bringing new ideas and techniques to the JVM benefits the entire JVM community. Scala collections benefited from ideas from Clojure. The JRuby group (among others) helped with 'invokedynamic'. In my work, I've found Scala, as well as Groovy, to be incredibly useful for solving problems. However I find this post to be just another case of the inflammatory "my language is better than yours". Maybe it's time to update the diagram at http://lukewelling.com/wp-content/uploads/2006/08/programmer%20hierarchy.pdf :-)

  52. "What about Menifest, @tailrec and trait incompatible problem and null?"

    - While I would never say that tail call optimization or the lack of support for multiple inheritance are not problems, I guess I don't see them as constituting *enough* of a problem to justify a whole new VM. At worst, we could try improving the JVM.

    = I don't know what you mean by "Manifest".

    = I don't believe null to be a problem, except insofar as people need to stop designing languages where null is an instance of Bottom. I could rant for hours about that but I won't.

    The current pre-release Ceylon compiler is already an existential proof that there is a typesafe way to handle null on the JVM.

    I believe that Fantom also proves this, though I think null/optional might still be some kind of primitive thing introduced by fiat in the language spec in Fantom. Which if true is something I don't very much like.

  53. "A 1000 apologies, no cheap shot intended. I was just pointing out that if my boss came and said "We need a module system", I couldn't use Kotlin or Ceylon; they're not even released yet. Hopefully someday. Anyway, personally, I'm excited about all the new languages being developed on the JVM."

    Ok, cool, sorry, I didn't read it that way.

    FYI, we're all working really hard, and the Ceylon M1 release will be coming real soon:


  54. IMO there are a couple of good points here (e.g. community). Some of it is opinions (unfortunately stated in a way that is somewhat suggestive, as if this is the one proper opinion), such as syntax and type system - do you want a strict language without much flexibility but clear readability, or an open one ? Take your pick. Unfortunately what seems to dominate, at least to me, is the bad-breakup kind of writing "I hate my old language, it sucked at X, my new language is much cooler", which - regardless of whether it really sucks at X, doesn't not make for a good informative read. Articles like "Scala's module system is broken, and here is why" etc. would be much more useful. As it is, lots of people will just cry FUD and nothing will be gained.

  55. @Carl Thomas I did call your argument(!) lame and that's exactly what I meant. I respect your position, actually. And I do get your point that sometimes powerful capabilities of a programming language (or environment) lead to misuse. I will not argue that Scala is a bad or complex programming language, it's just not a language that appeals to me.

    So, you are right in assuming that I am biased against Scala, though and that, in a way, I have made up my mind. Again, for the record, I tried using Scala, but I was not impressed by the stuff I could do with, rather how it challenged my aesthetic perception of how clean code should look like in my very humble opinon. If you do like Scala, that's great. I was trying get the excited Scala developers to defend what they like in an manner for guys like myself (who are clearly not as excited), so that I'd be enticed to give it another shot. But I realize in this context that it is asking a lot... :)

    @sreque Well, a community is not a person. Stephen is, so there is a slight difference. But I appreciate your point-for-point responses. Let me just ask you: If the inventor of a programming language calls out for the developers in the community to stop using certain capabilities (symbolic names) of the language, doesn't that confirm Stephen's impressions? I know too little Scala and have not been part of the discussions you mentioned, but what you say sounds like Scala would make it easy for really, really smart people to write code that is hard to read (especially for newbies).

    Your point about syntax and readability I don't understand at all. How can you know how other people read code and what they find readable? That's a rather subjective experience, I'd say. In this post, Stephen actually explained what I find a compelling explanation on why Scalas (or Kotlins) syntax is, at very least, not easy getting used to. http://blog.joda.org/2011/07/reversed-type-declarations_4524.html

  56. "= I don't know what you mean by "Manifest"."

    Oh actually, I do know what you mean. You mean that thing that Scala hacks in because it doesn't have fully-reified types.

    Well, that's not a problem with the JVM, it's a problem with Scala.

  57. Don't know what names Stephen Colebourne may be called, but there's *certainly* one he can't be called: spreader of fud. People calling him that should take care not to do exactly what they accuse him of...

    I've done a few experiments on my own with Scala. And honestly I would welcome the occasion to use it at work. But I have to admit the documentation is scaring ! And my questions about that were not exactly replied with much diplomacy. The same goes when asking what I should do when the compiler crashes. Typically for pattern matching. So I can't tell Stephen is wrong there. Unfortunately.

    But as extensive Scala might be, just like for JEE, use what you need and safely ignore the rest. It's gigantic but luckily you don't need to know it all in order to do sometjing useful with it. Scala is nowadays used by big companies. So I guess it's not that unstable. Is it ?

  58. Funny how in the Java world, it takes years to build a module system, while for many years Ruby has had its gems, python has eggs, perl has CPAN, javascript has npm, ...

  59. "Funny how in the Java world, it takes years to build a module system, while for many years Ruby has had its gems, python has eggs, perl has CPAN, javascript has npm, ... "

    It's only funny in the way all embarrassing tragic disasters are funny.

  60. "But I have to admit the documentation is scaring !"

    Just so everyone can judge for themselves, here's some links to Scala documentation:
    Documentation Site => http://docs.scala-lang.org/
    API Docs => http://www.scala-lang.org/api/current/index.html#package
    Scala School by Twitter => http://twitter.github.com/scala_school/
    Free Book => http://www.scala-lang.org/downloads/distrib/files/website/doc/ProgrammingInScala.pdf

  61. no pain no gain. leave the comfort zone and expand your mind.

  62. Although the reasons of horror are totally different for EJB1/2 and Scala, the result remains the same. It is uneasy to work with the language (tooling and
    compiler speed, plus binary incompatibility etc.) as it was uneasy to work with EJB 1 or 2 containers (well, the container did suck even more than the spec and all the boilerplate sometimes ...). Tooling, and scalability of development is a main concern this days. It doesn't matter if one can write stuff in 10 times less code, if it needs 100 times more time to explain to the substitute developer, or even more if a developer on maintenance has to find out by himself what the code does. This makes Scala projects outside the education/free software world expensive, which prevents getting lots of momentum.

  63. I love Scala & I love you!

  64. raichoo said:
    '"If you don't know Scala, you wouldn't have a hope of attempting to understand the code." This statement holds for pretty much every language.'

    This is not true. A lot of languages are very readable. Ruby and Groovy have a very concise syntax and high expressive power, yet they are a lot more readable than Scala. Any decent programmer should be able to read most of it. Just like Java and C# are readable by any idiot (though very verbose).

    Mind you, there's a lot about Scala that I love. The intrinsic pattern matching and case classes and objects make for a very powerful combination. Same for the built in Actors. But when I look at the bizarre type hoops that libraries have to jump through, I pray it's also possible to code without that crap.

    I'm sure the type system is genius, but I'd prefer if it was sensible genius instead of mad genius. I like my sanity.

  65. As a Scala beginner to intermediate programmer and not a Zealot of any kind (you have to make clarifications such as these nowadays to pre-emptively avoid trolling), I would like to say that your opinion on the matter is wholly incorrect. Scala CUTS DOWN boilerplate. EJB2 on the other hand INTRODUCES MORE boilerplate. So, the comparison is incorrect.

  66. [Manifests]
    "Oh actually, I do know what you mean. You mean that thing that Scala hacks in because it doesn't have fully-reified types.
    Well, that's not a problem with the JVM, it's a problem with Scala."

    I don't really know what you mean by this. Manifests are a convenient library feature to inject runtime type information where it usually not available in the JVM (as is the case with Java). I can't see how that is a hack, and I can't see why it is a problem with Scala. How does Ceylon do it?

  67. "I don't really know what you mean by this. Manifests are a convenient library feature to inject runtime type information where it usually not available in the JVM (as is the case with Java). I can't see how that is a hack, and I can't see why it is a problem with Scala. How does Ceylon do it?"

    Ceylon will have fully reified generic types like C#. You're not exposed to "manifests" at the code level because it will be handled under the covers by the compiler.

  68. Neat. Certainly easier when you are starting from scratch though huh? :)

    Of course, as an API consumer, you are not (or at least, don't have to be) exposed to Manifests in Scala either.

  69. "Certainly easier when you are starting from scratch though huh? :)"

    Exactly. You need to make a *lot* of ugly compromises if you want totally seamless interop with the existing Java SDK.

    "Of course, as an API consumer"

    I'm primarily a library developer. And I don't agree with the people saying that it's not important that library functions don't have clean, simple, easily understandable signatures. On the contrary, to me, it is one of the *most important things*.

  70. Spectacular failure. Thanks for the giggles!

  71. Great post, thanks. Though yeah, you'll be dissed for it, as indeed the defenders of scala are an active bunch ;-)

    Years ago, I was pretty excited about it. I saw lots of things Java couldn't do, and that would make my life easier. But then more features. And more. But I think that even before I got totally turned off by the language, I got turned off by the community first. It felt very elitist and unwelcoming to people who may be just interested in a language to 'get things done' instead of one you can put on your resume and earn an immediate 'smart like hell' badge with.

    Fantom is pretty close to what the basis of an ideal language could be. I love the pragmatism, focus on simplicity and frankly elegance (but that's often in the same corner as simplicity is anyway). The unfortunate thing with Fantom imho is that it doesn't get sold very well. You may disagree, but I think it is important that a language gets a broad base of users and support before it gets to be a viable choice for main stream development. I've been very close to proposing to adopt Fantom at my workplace in the past, but currently am hesitant to do so, because well, it just doesn't feel like it's going big places. Not a very technical argument I agree, and I should probably take a look again.

  72. Disclaimer - I am clearly a strong advocate of Scala but I hope I'm not going to be one of those morons who don't at least,give you a civil reply. Whatever else you may be, I believe that your dislike of Scala is genuine and not the product of some subversive mission.

    > "The trouble is that despite the pleading of aficionados, method signatures like this abound"

    I may possibly be one of the aficionados of which you speak, being the author of this Stack Overflow question (http://stackoverflow.com/questions/1722726/is-the-scala-2-8-collections-library-a-case-of-the-longest-suicide-note-in-hist). (I may not be, but I think that this is what you are referencing as I've never heard anyone else plead about it very much).

    But you are mis-representing my opinion; in that question, I note that "The library is eminently useable: in fact it's fantastic". Hmmm - doesn't sound like I'm pleading with anyone to get rid of the signature. I was merely musing about whether the surface-level complexity of the signature would put people off. Evidently it has. It's not a criticism of the library or language at all - merely an observation that it may have been unwise commercially.

    I am going to take issue with one other statement you make:

    > "There is also a sense that many in the Scala community struggle to understand how other
    > developers cannot grasp Scala/Type/FP concepts [leading them] to castigate those that
    > don't understand as lazy or poor quality developers [...] "Java Joe" or worse."

    This is absolutely, 100% factually wrong. In fact, it's worse than wrong, it is the *diametric opposite* to what is going on in the community, which is this: the people *who are not FP-advocates*, complain to the FP-advocates that Java-Joe is too stupid to understand FP. The FP advocates reply to these people that they are projecting their own unwillingness to learn onto this putative "Java Joe", who, say the FP advocates, would actually probably not have a problem with the FP stuff. *Because it is not hard*.

    In this debate, it is *you* who are on the side of the non-FP guys. That is - it is you and only you who are denigrating Java Joe and telling everyone that FP is hard, when it is not, in fact, hard at all. You will not find a single instance of any FP advocate responding to a question which says "I am finding this difficult" with anything other than encouragement and help.

    They respond differently to people who say the equivalent of "your library looks strange to me, ergo it is incomprehensible to the average developer" because they believe that this sentiment is harmful. I do not always agree with the method or tone of their responses.

    By the way - I never did Comp Sci or LISP and, to me, Clojure looks like gobbledegook. But I do not project that impression onto others as some kind of objective fact. Because that would be grossly incorrect.

  73. http://programmers.stackexchange.com/questions/117561/whats-the-difference-between-scala-and-red-hats-ceylon-language is a good page for explaining how Scala already does everything Ceylon does and more, and Ceylon hasn't even been released yet. Beyond that, I don't see how Ceylon can hope to compete for several reasons. First, it will be harder to migrate to Ceylon than Scala because Scala has better Java interopability. Second, If people are unwilling to take the time to learn Scala, they are probably unwilling to take the time to learn Ceylon as well.

    No one is going to use Ceylon over Scala because it's marginally easier to use Ceylon's reified types than Scala's manifests or because it takes less characters to type Type? vs Option[Type].

  74. "is a good page for explaining how Scala already does everything Ceylon does and more, and Ceylon hasn't even been released yet."

    Um, yeah, OK, to me it looks like a bunch of speculation by people who had seen a few leaked slides from a presentation to a small conference in China. Seems pretty clear that none of these commenters had read the language spec or even the tutorial. You probably shouldn't believe everything you read on the internet.

  75. for me - it's simple - I am a professional coder. I write in C#, C++ and Java. I work with other developers using existing systems and libraries. C# is great - it's a dream language. Java is constantly painful - every day we but up against limitations that mean we write much more code than we need to, and consequently have many more bugs. It hurts.

    Then, like a ray of light comes Scala - allowing you to use the same libraries, the same projects, not to need approval for an n-year rewrite of the system, but promising to take away the chains that come with java. If nothing else, I'd make the switch just to be able to use extension methods, so I could get linq (lamdaj doesn't really cut it)... but it brings so much more.

    It's quite likely that there are many better languages out there - but in a business environment you don't get to just start again - you have to work with what you have - Scala allows you to just start writing it tomorrow into your existing java projects and ide's... it has enough "cred" that you can convince your management to allow you to do it... and it fixes many of the real problems that exist in java. It seems disingenuous to suggest (such as the module system) that it's bad because there are still some features it _doesn't_ fix. Java doesn't have a module system either - so you don't _lose_ anything. I basically consider it Java++

    what's not to like? It's not that it's a perfect language. It's that
    a) you can start using it now in a corporate environment on existing systems (and the languages that fulfill this comprise a _very_ small list)
    b) it's just hands down better than Java. Java hasn't changed significantly since generics - and it's been seven years - in computer years that's several lifetimes.


  76. This comment has been removed by the author.

  77. Well, Gavin, until I see otherwise I have no reason not to believe what I read, do I? I don't see, after a quick glance, for instance, how Ceylon's modules do anything that couldn't reasonably be implemented as a Scala library if it becomes popular enough, or what advantage integrating the concept in the langauge really brings. That's the great thing about Scala. For instance, people in the Scala community liked what they saw in Clojure's STM, so they implemented it, as a library, of course!

    Why should I not believe these people when they say Scala is capable of everything Ceylon is and more beyond?

  78. I wrote too much, so I turned it into a blog: http://retroprogrammer.blogspot.com/2011/11/scala-gripes-not-here.html

    I like Scala very much. I find I can accomplish so much more in the same amount of time than I could in Java. It's so helpful in fact, that it is also rapidly becoming my "native tongue" - If I have to write Java, I often prototype difficult algorithms in Scala before then translating back to Java, because it is so much easier to see what I am trying to accomplish without all the syntax cruft you get in Java. It allows you to concentrate on business logic, rather than having to just through hoops to satisfy the compiler.

  79. "Why should I not believe these people when they say Scala is capable of everything Ceylon is and more beyond?"

    If you're trying to bait me into a Ceylon vs Scala flamewar, I'm really not interested, sorry.

    By the way, I'm anyway not one of those who believes that "bigger language"="better language". A language is not measured by how many features it has. It's how they fit together that counts. For example, Smalltalk and ML, which are among my favorite languages, are really quite "small" languages compared to the ones we're discussing here.

  80. "If you're trying to bait me into a Ceylon vs Scala flamewar, I'm really not interested, sorry.

    By the way, I'm anyway not one of those who believes that "bigger language"="better language". A language is not measured by how many features it has. It's how they fit together that counts. For example, Smalltalk and ML, which are among my favorite languages, are really quite "small" languages compared to the ones we're discussing here."

    Well, then, you're smart enough not to get baited into a discussion you know you'll lose! :) This is reminding of language discussions I have with Perl advocates, whereupon when you point out the flaws in their language, they have no direct response, but simply change the subject to something along the lines of "Perl is a language written for human beings!"

    I'm a huge fan of minimalism in languages myself. This is another area where Scala shines. Scala defines a relatively small number of language features, but these features are so well designed and fit together so well that the language gives you the ability to write very powerful, yet efficient and readable, code. In fact, if you took away the complexity of the type system, there wouldn't be that much left! This simplicity is illustrated by the fact that there already is an alternative implementation of the entire language spec running on the Mozart VM!

    If you told me Ceylon's supposed minimalism is its strength vs Scala, then I'd simply point you to http://lamp.epfl.ch/~odersky/blogs/isscalacomplex.html.

  81. "Well, then, you're smart enough not to get baited into a discussion you know you'll lose! :)"

    So when I address the topic Scala fans accuse me of negative attacks. When I refuse to address the topic they accuse me of cowardice. Can't win, can I?

  82. Great post Stephen.

    I agree to most of this, although I'm not sure the EJB-2 comparaison is the best one.

    Scala is not a bad language, but I've worked on large code base that have been around for a long time, like the other 90% "working" developers that aren't prominent bloggers, because they have work to do.
    And I absolutely believe that simplicity and readability are extremely important features and pretty much directly transalate to maintainability and also often reliability.

    Believe me businesses much rather have stability & maintainability than "less verbose" or "cooler" or "[insert some academic concept here]" ... and why most still use java despite the cruft nowadays.

    - Who wants to maintain perl or scala code that was done by somebody else, in the past ?
    - The more code is readable the less likely a dev will misunderstand and introduce a bug later

    While I know some companies do use scala in production, It's obvious most scala proponents are academic and maybe mostly spend their time "playing with" and doing experiments and then move on to the nest thing, scala sure is exciting for that stuff.

    But to me that's different from what your typical dev is doing at their day job, which is writing reliable boring business code, and I really dont think scala is a good pick for that, especially for long term maintainability.

    Many of the new JVM languages are good, Fantom chooses to be simple & pragmatic (while still powerful), not sexy, but smart and reliable.

    I wish Fantom was more widely used as @chillenius said, but just as Scala attracts the academic types, who often also have time to blog a lot, Fantom mostly attracts the pragmatic types who want to get stuff done.

  83. Interesting read :)

    Thanks for sharing your opinion.

  84. I've used scala on a fairly large project spanning a timeframe of about 1.5 years and find many points in this blog post which I agree with.

    How much time have I wasted trying to make scala's broken type system happy?

    How much time have I wasted waiting for the god awful slow compiler to finish?

    How much do I loath the rat's nest of actor code that my co worker created?

    What's not to love about it? It IS an alluring trap with those pleasant but not realistic code examples. I am or was a fairly proficient lisp /fp developer and everyone commenting here about FUD or whatever other nonsense is totally full of shit and trying way too hard to look smart when anyone who has enough knowledge to know better can see right through all of your insecure comment ranting. End of line

  85. @Scala, @Fantom, @Ceylon, advocates,

    Not surprising there is a fun little flame war going on... For me personally, I'm excited about Scala, Clojure, Fantom, Ceylon, Kotlin, etc. In every new language, we learn something about what works and what doesn't (checked exceptions, null, closures, raw types, mutability, module systems, type systems, inference, expressiveness, OOP, FP,...). Anyway, to all you language guys keep doing what you're doing. Keep coming up with ideas. Even if I don't want to use YOUR language YOUR language will teach us something. A new language(s) will win in the enterprise (Java is now wearing adult diapers) and will have been influenced by the languages that came before it. The worst thing we could do is say "screw it lets all work on one language". Sometimes you need a clean slate to come up with truly interesting ideas. And of course healthy competition breeds innovation...

    To make another example (which may get me in trouble), one of Scala's criticisms was/is IDE support. So I think it is fair to say that anyone creating a new general purpose language will think about IDE support early on (if they want to succeed).... This is also a point made by the Kotlin team where IDE support is too damn difficult in Scala (their words not mine).

    And for the record, I think Scala is a interesting language! Didn't I say that already once ;-)

  86. I do a fair amount of work in Scala as a consumer of its library, and while I admit that some of the type declarations are baffling, it never stopped me from using the library effectively. It's pretty nice that an operation on an ArrayBuffer yields another ArrayBuffer and not merely some collection interface, and that a similar operation on a String (as a collection of characters) yields a String. You get what you pay for, I suppose.

    Sure, there is a small but vocal fraction of the Scala community that understands the theory much better than I will and is not shy about sharing that fact. But generally, when I asked a practical question, I got a practical and thoughtful answer. Which is more than I can say about some communities.

    Personally, I'd tweak this or that Scala feature if I was the BDFL, but that's how I feel about every language that I ever used. Who doesn't? Ultimately, it makes sense to use Scala if there are useful Scala libraries and frameworks. Apparently, lots of people are creating and using these libraries, much to the consternation of the "Scala is complicated" crowd.

    As to "Scala is EJB2", I don't get it. EJB2 was excessively verbose. Scala is pretty terse. EJB2 made you write lots of boilerplate. Scala is militantly anti-boilerplate. EJB2 uses a blizzard of XML for configuration. In Scala and Scala tools such as sbt, one uses (gulp) Scala for configuration.

  87. Two things to mention: The spectrum of features that Scala offers is suitable for a range of developers so long as you decide what part of that range you're comfortable in and stay within it. That said, overall Scala is not a suitable replacement for Java. The core features are inherently more complex than Java and it's more suited for above average and/or highly motivated developers. I don't see that as a good or bad thing, it just is.

    I personally like most of the language. I agree with Stephen that implicits create a nasty situation, but from what I recall implicits are a mandatory part of giving Scala its power in other areas.

  88. The only thing you see here is emotions. "I feel" this etc etc.

    The points raised here might be valid to some people, but they are nothing more than perspectives of ignorance. Syntax means *nothing* the only thing that really matters is data. If your tool of choice makes it simpler to manipulate the data then its a good fit.

    If you spend your time writing lines after line of syntax to achieve a marginal gain, you are fooling yourself and nothing more but feel free to continue. People complain about "type system complexity" all the time, be it in Haskell or what ever but they are empty statements that are based on no understanding and only on emotions and / or ignorance.

    The point is that if you want to use a new tool, you have to understand it before you can make your mind up about it. You can not superficially observe something from afar - otherwise you will just rip your foot off with a new jackhammer.

    Its the same with the current vaporware being sold by Ceylon / Kotlin / etc. I look forward to seeing the final implementations but I will not make a decision until then. Currently, the one big disadvantage Scala has is that it exists and people can use it right now - be it correctly or wrongly.

  89. Anonymous wrote: "His point is not that it cannot be rewritten to be more easy to understand, his point is that Scala allows things to be written in such a hard to understand syntax in the first place. Not many people want to deal with code that looks like the first version."
    Nearly all languages allow to write one-letter variable/function names and abuse syntax flexibility.
    Hey, even in Java, I can probably write: while(x=z()==-1?a(x):r())w(x);
    But if I see that outside decompiling obfuscated bytecode, I would ask the developer to rethink his code!
    And on the reverse, I saw quite readable Perl code... :-)

    Likewise, the foldLeft example is among the kind of things that probably pulled me out of Scala the first time I saw it. Then I came tangentially to it, via a ScalaTest intro and the JavaFX DSL example. Yes, the internal DSL allows to write very readable and easy to maintain code...
    But the (_+_) funny Ascii art quickly becomes familiar to those dealing with the language, so it is no longer an issue. Code is mainly made to be read by those knowing the language, or willing to learn it and to research stuff.

    Personally, I would have written it with real name (l looks too much like 1) and spaces, as I think they help with readability: (0 /: listOfThings)(_ + _) and I actually would have used foldLeft instead of the symbolic version, although the latter has merits (logical order of arguments).

    (PS.: Too bad that the blogging platform hosting many programmer's blogs accepts an 'i' tag but not a 'code' one...)

  90. @sreque:

    > Concurrency. Scala handles concurrency better than any other JVM language right now.

    No, not "better". Better is subjective. You can say that Scala attempts to enforce immutability, but even that would be wrong since the language does nothing more than Java to that goal (rather, it's Scala libraries, such as Akka, that put the focus on immutability).

    As far as I can tell, Java has a fairly strong track record of handling concurrency very, very well. Both on a practical level (most of the very busy web sites and servers you use on a daily basis are running Java) and also theoretical one (ju.concurrency, fork/join, etc...).

    > It's a shame when a prominent blogger uses his position to spread bad information like this.

    It's a blog, he's a blogger. Bloggers post opinions on their blogs. That's just how it works.

    And I don't think he's spreading bad information. Some is factual (and backed up with facts) and some is subjective and more open to criticism, but overall, it's certainly not "bad" information.

  91. @Cay:

    > As to "Scala is EJB2", I don't get it.

    I don't want to put words in Stephen's mouth, but I think the comparison was more metaphorical than literal.

    EJB 2 seemed like a good idea at the time but when it began to be used, developers started realizing how needlessly complicated and unsuited to its function it really was. Nowadays, it's seen as a spectacular failure of "what the hell were we thinking?" proportions.

    Interestingly, EJB 2 gave way to EJB 3 which is pretty much one of the best implementations and spec in the domain that the Java ecosystem has ever created (and in no small part thanks to Gavin, by the way).

  92. Yes, thanks for the post, that's exactly my feelings about Scala. While I like Groovy (in Rails context, of course, by itself groovy to me is very slow java with no refactoring), Scala seems too complicated, and by reading documentation and going through sample codes on their website I really didn't understand what problem it is trying to solve and why it can be useful to my day-to-day both enterprise and hobby development. I am not interested in "look in my one-liner", and I could not identify any other noticeable things around poor Scala.

  93. Good points. As someone who has played around with scala, I agree with all points made. Scala is good and all if you are trying to prove to everyone how clever you are.. but the ground reality is that scala code is very difficult to understand and debug and so maintenance becomes a real nightmare.

  94. @Gavin:
    << "Funny how in the Java world, it takes years to build a module system, while for many years Ruby has had its gems, python has eggs, perl has CPAN, javascript has npm, ... "
    >"It's only funny in the way all embarrassing tragic disasters are funny."

    Maybe those module systems are not enterprisey enough for you, but they are the perfect solution for millions of people out there. They are easy, work just fine and are live, while Java modularity is fragmented or has been in the status of "specification" for years. Can i run

    jigsaw install hibernate

    in my shell and solve the problem right now? No? Too bad. I favor worse-is-better-working-right-now to perfect-solution-to-be-released-someday anytime.

  95. With "scaring documentation" I mean the ScalaDoc. Something people usually read to understand the capabilities of certain classes and objects. But some function signatures are complicated to grasp. Examples of frequent usages would be very helpful !

  96. About the signature of '++'. Lets assume a dynamic language:
    class Traversable {
    def ++(other)

    what does ++ return? You have no idea. You have to either read the documentation, or check the source code. If you are reading documentation, you can do the same in Scala, where the comment will clearly define what ++ does. If you don't like reading documentations, then in Scala, if you know the language, you can at least figure what the argument types and return type is. In dynamic languages you have to dig into the source code of the method.

  97. Most of your points are unfair (module system) or just wrong (community).

    However, one thing is a good point: people writing tools and libraries should really stop using random symbols for method names. There are good cases for it, but these are few. Personally, I'm glad the possibility is there -- a way to avoid new BigDecimal(...).plus(...) is a must.

    I may have made that mistake as well... In my own SHTTPC library, I used symbolic methods too: 'http.get(apisite / "x.php" ? Map("urlParam" => "1")).asJson'. I still think that is one of the few cases where it makes sense, but maybe I'm just as bad as the others in thinking this.

    I recently tried sbt and was really baffled by what people put up with as descriptors of their projects/builds. Maven's xml is very verbose, but at least it's structured, and it's data. But 'seq(webSettings :_*)' to denote a web project? Then 'libraryDependencies <+= sbtVersion(v => "com.github.siasia" %% "xsbt-web-plugin" % (v + "-0.2.9"))' to add a plug-in dependency which depends on another value (note the %% instead of % for some reason)? Insane.

  98. Another analogy:
    Lego Duplo is far simpler than Lego Technic. It has far simpler constructs, it's easier to understand, it's easier to learn... it's so nice to build a nice pile of blocks.

    But when you need to build a robot or a car, which of those Legos is easier? This is when Lego Duplo starts to get complex, you will need a lot more pieces, workaround, duct tape...

  99. I developed with Scala for about a year. I learn a lot and got to work with some smart people. However, then I had to maintain code and, oh boy, it was like being forced onto a diet of live insects.

    When I voiced a concern on the Scala group I was attacked and derided. I don't and won't program with Scala anymore. After licking my wounds I'm using Clojure and find it makes more sense to me than Scala ever did.

  100. "Maybe those module systems are not enterprisey enough for you, but they are the perfect solution for millions of people out there."

    Grandfatha, in case it's not clear, I'm a big fan of the CPAN/gems style module systems. It's Java's *lack* of anything similar that I find to be a tragic disaster.

  101. Scala can get hard if you try to understand everything at once. But the good thing is, that you can use some great stuff first - like pattern-matching - and stay first more java-like and then start-off adding more and more Scala. Sure, in the beginning you will have some throw away code, but as much as I know from my experience of learning new languages, it will take time especially if it is something like a language trying to combine two dev paradigms like object-oriented and funtional programming. I am learning and using Scala for almost 1 year and getting better and better and still there is a lot to learn. Anyhow, meanwhile I wrote a complete DSL, BPMN-Server and JavaFX-2-Gui and do not regret it at all. And if you admit to yourself that you still not at the peak of the language level you will design your code, so you are able to come back later and do refacture it without having to throw away everything, it simply improves.

    AND all languages promising at the begining how amazing and great they are, ALL of them have their drawbacks and complexities and you have to stick with them for a while to realy get to know them.

    I guess there are many out there hoping to sit down, read one day some language specs and docs and get production ready code out of it.

    I think Scala is great and its better to go step by step AND you do not have to know the type system in its whole complexity right away.

    Cheers, Rob.

  102. These are some quite strong points against Scala, but I also think Scala has some nice features like the mix-ins and the actor model. I would like to see a blog from you considering also the positive sides of Scala, it will be much more constructive than the present blog.

  103. @Cedric - re support for immutability in Scala, I would point to these features:

    - case classes
    - immutable collections
    - method parameters are immutable by default

    in addition to val vs. var.

  104. I think there are two audiences that use Scala:
    * Need for a better syntactical Java with Mixins (aka Traits).
    * Hard core Type theory FP programmers.

    Scala meets both needs quite well and has libraries for each camp. For example if you want a FP dorky Web App framework then Lift or Unfiltered would be your choice. If you want something more mainstream then Play 2.0. (Clearly Martin is going for the less dorky cause he chose Play 2.0)

    Scala is trying to be many things for many people ("Being All Things to All People"). Many people think this approach is bad. I disagree. For a better language to hit mainstream we need the academics and the pragmatics to count as a whole.

    I will say the lack of testing is disturbing.

  105. Hi guys, Joe Java here. Been doing java for a few years, mostly spring/hibernate/gwt/camel on enterprise apps, whatever that means.

    Been interested since a while by learning FP but I am still stuck at Java at work, can't wait for Java 8.

    As an average programmer let me give my two cents on my attempt to learn Scala and FP. Two years ago tried reading Programming in Scala and couldn't make it past the first chapters, complete brain short circuit.

    I understood I clearly was missing fundamentals on FP and went back to blogs, etc. , beginner books like Functional Programming for Java Developers, Devoxx new JVM languages sessions etc., so did not blame it on Scala.

    After one year went back to Programming in Scala, and made it fairly to around chapter 20, the book is actually quite good but still I am far from understanding it fully. I think I now need some hands-on experience writing a medium size program.

    My impression is that Scala is learnable by any developer as far as the necessary time and effort is put in. The amount of time and effort needed to learn Scala is similar to the one that took many of us to really learn Java.

    My question is, for my daily work is it worth it to continue learning Scala? Probably not, I personally find it difficult to read. Ceylon and Kotlin look really appealing, they both give the same feeling I had when I saw Java the first time in the late 90,s.

    Conclusion Ill probably spend my FP learning budget elsewhere as soon as Ceylon/Kotlin are made available, or just wait for Java 8.

  106. I also read Richard Vowles comment that "Scala tied the scripting superbowl this year by trying its very best to not be like Scala". As the Scala representative in the scripting bowl, I can tell you I did nothing of the sort.

    The clue here is in the name of the panel: the Scripting bowl. Clearly I am not going to dive into a discussion of higher kinded types in 5 minutes of scripting bowl time, but what I demonstrated was three different and very relevant aspects of the Scala language and platform that are useful to developers right now.

    The first was interactively scripting a real world project (actually the code base I work on every day) to try out ideas in the Scala shell. I demonstrated talking to a third party API (confluence), reading data, and parsing the XML out using only the standard scala libraries. I used a for comprehension, the xpath XML features and more.

    The second was a demonstration of Kojo, a scripting and learning environment for kids. I did this to take on the notion that Scala was inherently over-complicated (thanks to the numerous comments from Scala detractors for the idea by the way, it made it really easy to choose a theme). Kojo is like Logo but in Scala, and is used by several people I know for teaching programming to high-schoolers. It is *absolutely* standard Scala, you define methods and use custom control structures and not a type system concept to be seen in the process. Just because it doesn't fit with your idea that Scala is to complicated, Richard, it doesn't mean you can just throw out there that it isn't real Scala. It is.

    Finally I demonstrated the real crowd pleaser, a DSL that literally takes:

    A long time ago in a galaxy far far away

    and returns a String result. This is a reasonably advanced domain specific language, and again needed nothing more complex than string types and a single object to write.

    Back to Stephen: in short, I am glad you seem confident enough in your opinions to share them in blog posting, but are you confident enough in them to invite people to try it out for themselves? I am! Please, if you are reading this, don't believe either of us but give it a go yourself. Learning Scala will not taint you in some indescribable way that will prevent you from ever programming again. Indeed, if you are interested in the coming crop of languages like Ceylon and Kotlin, Scala will introduce you to many of the concepts you will see in those languages so you can get a head-start on learning them. Chances are though, some of you will like Scala and continue to use it.

  107. As the guy who represented Scala in the scripting bowl at JavaOne, as well as a Scala practitioner for over 3 years working on real world projects for which Scala is an ideal match, I feel the necessity to weigh in on the discussion.

    Firstly, comparing Scala to EJB 2 is, of course, an attention getter, as it is supposed to be, but as several people have pointed out here, falls apart on anything greater than a casual glance (from the comments, even the Scala detractors don't seem to agree with that one). If you are going for headlines, Stephen, you have them, but the risk with statements like this is that they will reflect more poorly on you than on your subject, and may even perversely boost the interest in the subject.

    I share the sentiment with several other people in the discussion that I would like to know what, and how much, experience you have with Scala to make these kind of judgement calls. If you are telling the world not to use Scala (which it sounds like you are, and with which I have a whole other set of issues), at least that position should be backed up by some kind of description of real world experience you have had trying to use it. I would not comment negatively on Fantom since I have only dabbled with it, I don't believe it has enough to interest me or make me want to invest the time into learning it more deeply, but then I certainly wouldn't tell other people how much I dislike it or recommend that they don't use it.

    Coming back to that subject, I am also confused by your aim here. Are you attempting to just tell the world you don't like Scala, or are you trying to discourage the rest of the world from even trying it out? Surely if you have the courage of your convictions, your position would be the same as mine: why not give Scala a try for yourself and see what you think. After all, people should care less about what you or I think and more about making up their own minds. I did, three years ago, and I am very happy with the decision to use Scala as my primary development language. At the same time I do not feel the need to put down other languages with negative comments and glib comparisons to technologies that really bear little resemblance.

    In fact I was unable to make it to your Fantom is light years ahead of Scala talk at Devoxx, because I was talking about a subject that matters to me: Courage in software development. The core messages behind that talk are that people should care less about what "celebrities" think, and should do more thinking for themselves, also to get out of their comfort zone a little more.

    If someone tells me a technology should not be learned, my natural reaction is to move that technology further up my interest list. If it's bad, I can eliminate it quickly enough, but I was raised to think for myself rather than to take someone (anyone) else's word for something that might interest me.

    You started the article on a negative note as well, practically challenging the Scala community to deluge you with negative comments (really, why all the negativity?). In reading the comments, I would say in my opinion that the negativity scales are tipped more to the Scala detractors than the Scala fans.

  108. I had to split my comments up for the last two as they were just too darn long to fit in one go, and they got reversed by the blogging engine, but please read them in the reverse order and hopefully they will hang together a bit better.

  109. I once considered making Scala the functional language I was going to learn. However a number of discussions on a very active Java related google news group that i contributed to introduced me to the darker side of scala that I'd never experienced before.

    The zealot.

    In short the discussion at hand did not matter, for the answer to every question was 'do it in scala'. One particular individual - who fared less than well when he was unable to find the errors in his own code during his devoxx presentation last week - put me off scala for good with this kind of myopic view of the world. Sorry Kevin, but you put the cause of scala back several years last week. And gave some credibility to the then-gestating blog post we've all read here.

    I'm sure there are many good and genuine scala fans (Dick wall is an excellent ambassador with an open mind and balanced point of view), but when a scala consultant can't find the errors in his (scripted) demo code at one of the biggest jvm-centric conferences of the year - I'm afraid you've just shot yourself and your language in the foot.

    In short - my summary of functional jvm languages to my boss on Monday? Stick with Grails - even the scala experts have trouble reading the code they've just written...

  110. The majority of corporate Java developers have problems in explaining the generics and haven't even looked into what's new in Java 7, someone who thinks that Scala will be popular to some extent on that market is very very naive... That's why EJB was evil, and that's why Spring team has a crazy market share these days...

  111. With such a large volume of comments (overall of a notably high quality - thank you!), I decided to leave this space open for debate without me butting in every two seconds. My response to some of the points above is in a new blog post - http://blog.joda.org/2011/11/scala-ejb-2-feedback.html

  112. One of the alternatives to the plain old Java or awkward Scala must be to use a few good Java libraries to get some of the benefits of modern-day programming. Even without having programmed in Java for so long (I tried yesterday and failed at getting a sample up after having it done in Ruby, Dart and Go), I think if I had made use of things like the Guava collections for Java and such cool libraries I would have progressed better and maybe some of you too. Java with some libraries must be fast enough to compile and well-supported enough by IDEs and such.

  113. This is POJO Person, with c.tor and accessor methods:

    case class Person(name:String, age:Int)

    This is defining an Actor:

    class MyActor extends Actor {
    def receive = {
    case "test" => ....
    case _ => ...

    This is doing a POST with path "node" and request entity Person

    "node".POST[ClientResponse] <= Person(name="me", age=40)

    This is a transaction scope, creating graph db nodes an add relation "foo" in between

    withTx {
    implicit neo =>
    val start = createNode
    val end = createNode
    start --> "foo" --> end

    Scala is concise, elegant and allows beautiful code.
    It is a good idea to use it.

  114. Chris, it's not important, but in Scala your MyActor class should have been written as:

    class MyActor extends Actor {
    def act() {
    receive {
    case "test" => ....
    case _ => ...

  115. The only argument that I can think of for starting a post with two obvious fallacies ("...if it was just me that had a poor opinion of Scala I would probably keep quiet" and "...a sure fire way of getting flamed") is this: you want many negative reactions from the Scala community. They would (again fallaciously) prove your point that the community is a problem.

    The actual points you make are much more palatable, but because you got your wish and a lot of stupid and negative reactions, sensible discussion here has become harder than it needed to be. Congratulations on the high page rank I guess...

  116. Hi Anonymous(23 November 2011 23:54)!
    Here another Anonymous. Please do your self a favour and recognise the strange arguments you make up. First lets try find your (from my point of view) wrong thinking.
    1. You say Dick Wall has a balanced point of view
    2. Kevin from devoxx could not find a bug in his scripted scala code
    3. Your conclusion from this is to tell your boss to stick with grails

    Now looking at these 3, why don’t you follow Dicks advice and try scala yourself? Rather then blaming it on someone who screwed up a presentation.
    you cannot seriously expect to make an informed decision based up on this? How many messed up python, java, C or PHP presentations have you seen? Do you stay away from these programming languages too? Please correct me if you find my reasoning wrong or incomprehensible.

    On a side note: yes I read java pose occasionally too, and yes Kevin is a often taken a bit to far away by his excitement about scala. But if you are a professional you shouldn’t be distracted by this if you need to make a decision (IMHO)
    thx sincerely Anonymous

  117. EJB and scala is almost opposite in terms of philosophy! When I first heard about the compare I thought this is another shallow blogg clarion making noise ...

  118. Maybe they are opposite in terms of philosophy but very similar in terms of confusion they cause in the head of a poor developer when you have a fresh innocent look at them.

  119. "In fact this is the equivalent to Java's addAll() on a list"

    I'm sorry, but that is completely wrong. In response, I've blogged about the ++ operator here:

    My point in the blog post is that certain design goals will lead to the complexity you observe, but it's not really that complex at all if you understand the reasons behind the implementation.
    I'm curious about what Kotlin/Ceylon collection APIs will look like if they intend to avoid the complexity.

    Disclaimer: I have no formal education in compilers/type systems/etc and I am not a Scala committer so you might find some errors in the post. The main point should still be valid regardless of errors.

  120. I just can state from personal experience that the type system isn't "getting in the way" all too often. Most of the time it's a helpful guide to catch errors early.

    And in those circumstances where I don't want to fuss with overly complicated types (mostly recursive structures which can be unpleasant to type) I just cast the fuss away. It's always an option.

    With the collection library it's the same: there is nothing wrong in using it without having all the gory details of its type signatures in mind all the time. If I am getting it wrong the compiler will tell me. Most of the time I don't even care - I put my statements in the REPL (the scala "interpreter" shell) and test if I got something right (not aiming at the types but the intended functionality).

    In summary (and I am no PhD developer) I am a lot faster with scala than I am with Java, C# (disregarding GUI development) or Perl. It hit's a sweet spot combining the sloppyness of scripting with the rigor of type safety.

    But I agree in two points:

    If someone want's to show you that you are a dumb coder not worth your salt that person can do so with scala. The language allows arcane things which are not easily understood with java / OO background.

    I think there are some scalaist which are very explicit about their point of view and vilify people which do not share their mind set.

    I just chose to disregard both.

    So scala fits my bill - which does not imply that it has to fit yours, which it obviously doesn't.


  121. I agree to all of what Stephen outlined in his post. I am a seasoned Java programmer and started experimenting with Scala recently. I was just curious about other languages in the JVM and Scala seemed promising. The moment i saw operator overloading, it reminded me of C++. Isnt there a good reason why Java avoided it?

    Its expressive for the seasoned programmer but intimidates the average Joe. I read about 13 chapters of the Martin Odersky Scala book. The type system is way complex and the feature set is bigger than C++. Read again, "bigger than C++". Thats a red flag.

    I still liked it or i should say i was bored with Java. I went on to create a web application using Scala. The frameworks are immature and the most popular framework in Scala Lift is for programmers from a different world.

    I told myself i would use Java frameworks and write Scala code. It didnt scale. I couldnt use Scala's features fully and i have to make use of conversions to make Scala play well with Java frameworks.

    Each Scala library kinda has its own DSL, you know with operator overloading and custom constructs etc. This makes the code hard to read. If you are writing mission critical applications, you would end up using multiple frameworks and the learning curve is huge.

    Scala scares me. I would rather use Java's imperfect type system than learning the Scala's cumbersome and complex system.

  122. As a Java web developer, I delivered 4 projects and failed at 2. As a PHP web developer, I delivered 30+ projects and never failed. Using Java EE and studying its specs, I believe that Java people and promoters were stupid perfectionists. PHP may be quick and dirty, but delivers. And it does so without any huge corporate powertrain behind. In rare cases where you need more than PHP, one can use C++ or Java as a standalone console application - there is no need for containers, servlets, EJB, object mapping, JMS, etc. Integration can be done with pipes or webservices. Message queues can be replaced by SMTP and POP, or just a DB table to hold the job list. There is no need for threads - just spawn another process. Connection pooling can be replaced by process pooling.

    What makes things simple in this architecture is the absence of so many layers and complex, integrated APIs. You basically receive the request and respond to it. Caching is on your own. Talk to the database the way you like. 90% of your code is automatically stateless and sandboxed, and there is no need to complex setup or slow loading. Now compare it to Java EE - to respond to a simple request first you need to load a huge container into memory, and that reads lots of configurations. After some warmup (because almost everything is lazy-loaded, due to slow loading), your request can be handled reasonably fast. Then there is servlet, JNDI, context, connection pool, object mapping, EJB, JVM, etc, plus application server "features" like clustering and high availability - all of which must be correctly configured. 2% is your code, 98% is code from someone else that needs to be integrated. If something goes wrong (or goes slow, as often happens), there 98% of chance that it will be on some layer. Then somebody will tell "you didn't code using the recommended patterns". So you must add more boilerplate to make it work.

    Fortunately I work mostly at in-house development, so I don't need to listen to stupid IT manager requirements such as "80% of solution must run on JVM", "must run on ABC Application Server", etc. Hence, I really don't care about Scala in the Java EE world. I think Scala doesn't solve the urgent problems in Java EE. The language can allow smaller programs, but while these programs run or require a fat set of layers under it, loaded, configured and warmed-up, a better language won't help.

    When comparing Scala to Java language itself (forgetting Java EE), then to me Scala documentation and promoters resemble some stupid perfectionism or at least some excessive optimism. I particularly don't like Scala syntax, but this might be biased from years of C/C++, Java and PHP. Kotlin and Gosu seem to be more reasonable replacements than Scala if you need too many algorithmic programming (that PHP can't handle). It's a shame that JetBrains decided to invent Kotlin instead of uniting to Gosu - the motivation behind Kotlin and Gosu is 90% the same, but still that yielded quite different languages.

    1. Two years later and inbound from Google, one must wonder how this approach is working out for you. From my perspective, this is exactly the kind of snark that lowers the dialogue, and it persists today, not to mention how out of place throwing PHP into a discussion of static languages is.

      "Message queues can be replaced by SMTP and POP, or just a DB table to hold the job list."

      No, no and thrice no. For posterity's sake. No one in their right mind would would give up the fault tolerance and sanity checks afforded by solutions like AMQP on RabbitMQ just to cut a corner and fly by fire-and-forget SMTP, especially when virtually every language has an an option available at this point and the development overhead is virtually nil. Solutions like SQS make implementation trivial. Where using such a pay-for service is impractical, celery backed by MongoDB can give you virtually the same fault tenacity and entirely for free. What you're suggesting here is a trade for no gain.

      For a guy who throws the invective term "stupid" around so much (and about entire language specs at that!) one could have a choice term for what the stack you advocate. Maybe you could do for some of the insight those "perfectionists" you chagrin so much could offer. Keep an open mind, perhaps?

  123. Much theory here. Started to read *the* Scala book a few days ago and put my hands on the keyboard. Regarding my 10+ years Java background, I'm very impressed with Scala.
    I studied computer science and got in contact with ML and Lisp. Never thought functional aspects would go mainstream. But looking at Scala and it's elegance it seems so much natural to me!
    I love what I've seen so far and would recommend everyone to give it a try.

  124. I 100% agree with the author.
    Scala is too complex even for experienced developer who had never worked with functional languages. And there are 90+% of such people.
    But imagine that I need to introduce junior dev into big Scala project. I simply feel a big FAIL here.

  125. Wow... I'm late to the party.
    As someone who has programmed professionally in many languages (but in the last 16 years primarily Java) and in multiple distributed paradigms (RPC, Sockets, CORBA, EJB 1/2/3, SOAP, ReST... god i'm old...) I see what Stephen is saying. He's not making a technical comparison of Scala to EJB2, he's using the analogy of the distaste of EJB 2 by the Java community at the time to a distaste he has and sees with using Scala as a general use programming language.

    All of the posts contrasting Scala to EJB that I just read (I got tired of reading the replies) are correct. But again I believe Stephen wasn't trying to compare the two as technologies but it was an analogy of how EJB 2 did a lot but it's inherit complexity for even the simplest things made it unpopular. If you think about it, if you are pointing out the differences between Scala and EJB you are picking apart all of the differences between a computer language like Scala and a specification. He wasn't trying to say Scala is like EJB he's talking about the negative aspects that both brought/bring to many users. If you are focusing on how is comparison of the two technologies differ then you are simply not seeing the forrest for the trees... I think he's just saying: "This inherit complexity, lack of testing, rich but computationally-explosive type/collection mechanism provides the same distaste for using Scala (to him and others) that EJB 2 did for those of us programming in server-side Java at the time."

    For the record, 2 years ago I was a team lead on a project and approved the use of Scala to augment our Groovy and Grails implementation for it's concurrency. It was more efficient for us to use Scala to multi-thread our request processing than doing it in Java. It wasn't that we couldn't do it in Java, but that we had been looking at Scala off-and-on for a while and felt this one particular need would be more efficiently soled in Scala.

    I'm not anti-Scala but I TOTALLY get what Stephen is saying, I just agree at a lesser extent. Scala has it's place, it just doesn't feel to me that it's place is to replace Java for the meat-and-potatoes programming, even though it is technically capable.

  126. Modularity

    Afaics, the discussion about ML modules versus Scala is research about the most composable paradigm for the separation of interface from implementation. That is not central to the allegation that Scala is bad because it is alleged to not have modularity.

    Modularity (i.e. separate compilation, SOLID principles, Expression Problem, declarative programming, etc.) is fundamentally about separating interface from implementation (and sufficiently expressive typing for denotational semantics). If an interface changes, give it a new name-- afaics versioning hell would disappear. A key point is separating implementation (changes) from the abstract interface declarations (which should change more infrequently). Afaics, there is no need for a special orthogonal syntax for versioning, just change the name of the interface (append a version number).

    The ability to compile implementation separately from interface, is what matters in terms of those asking to be able to compile 'modules' and not classes. The pertinent issue is not that the unit of 'class' is too low-level, rather it is that 'class' shouldn't be first-class, i.e. one should never be able to reference and operate on a class (input and operate on an interface instead). Afaics, the modularity paradigm of the critics is apparently wrong, thus they want something which isn't modularity.

    Afaics, Scala suffers no more than any other language (e.g. all of the popular languages) that allow mixing implementation in an interface declaration and/or that allow referencing a non-interface as a first-class type. My current thinking (subject to change with experience) is I would choose to separate a Scala 'trait' into 'interface' and 'mixin', where the former is an abstract signature and is first-class, and the latter is implementation and not first-class.

    The loading of modules dynamically is mostly an orthogonal issue. Google "Java classloaders". Afaics, the main point for modularity is dependency injection employing interfaces, since implementation wouldn't be first-class and thus couldn't be referenced in my proposal. Afaics, this can be emulated in Scala manually (not enforced by the compiler), but can't be emulated in languages (most of them) which don't have mixins and sufficiently powerful typing.

    Afaics, Fantom destroys modularity by throwing away typing:


    Reflection and dynamic typing is not modularity. Perhaps your experience is greater than mine, but afaics wide-scale modularity doesn't exist without powerful typing.

    I am very interested in counter examples to my points.

  127. Concurrency

    Scala has the 'val' to declare immutability. It is lacking the ability to declare functions (and methods) as 'pure'.

    No real world program will have entirely immutable data. In addition to immutability, concurrency also requires atomicity and acyclical propogation of data flow, which can never be guaranteed in open, distributed systems.

    In short, concurrency will always be non-deterministic and exhibit random semantics (i.e. bugs a/k/a semantic noise) in the open, distributed scenario. There is no theoretical way for a compiler to prevent it, due to the Halting theorem (inability to trace all potential code paths) for Turing-complete machines. See my links above for more on that.

    Perhaps Scala could benefit from the ability to declare functions as 'pure'. My impression is the author is too harsh by not recognizing the existence of 'val' and by implying that immutability is a concurrency panacea.

  128. Complexity

    I agree in principle that we want to eliminate complexity that doesn't fulfill the 80/20 rule (Paretto Principle).

    I'm aware of the Yammer and Steve Yeggie criticisms.

    I empathize with the allegation that Scala is a "write-only" language, given for example 9 ways to write a method function. I am pondering ideas that may or may not succeed in reducing complexity, yet retain the robust static typing that I claim is necessary to have true modularity. Even the extra (as compared to Java) binary compatibility complexity of Scala is somewhat due to the conflation of interface and implementation, also the multiplicitous syntax enabled by type inferencing.

    As I explore modularity, afaics so far I could not (without boilerplate inefficiency, code rot, and semantic non-determinism rot) implement the necessary paradigms without the robust type system, including implicits, higher-kinds, etc.. I am exploring that perhaps it will be possible to hide this complexity in a language that is custom-tailored to do some key features. If successful, it might still indicate that the power of Scala was necessary to implement such a compiler efficiently.

    So far, I am undecided if the use of implicits in the standard library was the correct way to go.

    I think none of us have a complete enough picture of how to get a handle on the complexity of the exponentially exploding world of software, and whether the power of a Scala type system is necessary, or what could be simplified. There are going to be some growing pains as the Comp Sci world figures this out.

    Let's keep in mind for example that neither Java nor Haskell can do diamond multiple inheritance, which causes major problems for modularity.

    There is no free lunch. There is much experimentation going on to find the key advantages that are going to replace Java, because we are overdue on the decade cycle of having a new mainstream language.

    We have to ask ourselves, what is the key feature that will drive the next language? For Java, it was garbage collection and the VM.

    Apparently the shift to dynamically-typed languages has abated (see chart near bottom) and is either stagnate or reversing.

  129. Is this Richard Richards speaking?

  130. Everyone has issues with any language they use, and even Scala aficionados have issues with certain aspects of Scala. But I've lost a lot of respect for the author for expressing his ideas in this manner. My objections have been covered by other people in other comments so I won't repeat them.

    But I encourage anyone to try Scala out and come to your own conclusion. Even if you decide that Scala is not the right language for you I think you can still gain a lot from learning it. I can honestly say that my Java code has gotten better from learning Scala.

  131. There's an element of truth in most of Stephen's points, and I think, despite OP's obvious bias against the language, it's still a valuable critique.

    Modules - would be nice, but it doesn't make much sense at the moment to develop such a system with project Jigsaw on the horizon.

    Concurrency - compiler checks for immutability would also be nice, but it's really not a big deal in practice.

    Community - the vast majority of members are very helpful, intelligent, and friendly in my experience. Since Scala has roots in academia it's only to be expected that some people are concerned with exploring the limits of what's possible. So you don't understand cutting-edge research-level topics - is that surprising? Should people not discuss them?

    OP comments "This sometimes leads Scala aficionados to castigate those that don't understand as lazy or poor quality developers, as being second class citizens". I am fairly certain that this refers to the outbursts of just one individual, who has made great contributions but perhaps has difficulty dealing with people. It's unfair to make out that this is representative of a whole community since I've never seen such a sentiment expressed by anyone else.

    Why not instead say something closer to the truth, e.g. "Scala aficionados are passionate about their language and are always eager to show you the ropes. Sometimes their explanations will fly over your head, but if there's something you don't understand, they're more than happy to explain." Don't focus needlessly on the negative. Personally, I've learnt almost everything I know about the language from the fantastic community.

    I've run out of time to address the other points. :)

  132. > (0/:l)(_+_)
    > Thats practically the very definition of line noise. (And I've not even shown any scalaz examples, or similar unicode

    I actually like this terse style, it's part and parcel what draws me to Scala. I don't understand why other devs have a problem with this approach and seem to feel that a heavily verbose alternative is better. For me it is quite the opposite: the more verbiage, the harder it is to follow.

    And with respect to the "unicode wierdness" link you posted, there is nothing wrong with that either. We're not talking about abusing operator overloads, he is implementing very mature 19th century De Morgan's laws consistently.

    Is this unicode wierdness or is this your lack of familiarity with De Morgan's laws?

    Programming should reflect mathematics not resist it. Mathematics has been the most successful in describing the nature of things than any other language. It is the most efficient, the most simple, the most concise language for describing the nature of things. It is the universal language, and first contact with extra-terrestrials would only be achieved via mathematics.

    To resist mathematics is to regress. And as such I find your criticism of Michid's union types implementation disappointing.


Please be aware that by commenting you provide consent to associate your selected profile with your comment. Long comments or those with excessive links may be deleted by Blogger (not me!). All spam will be deleted.