Yes Virginia, Scala is complicated!

Original author: David Pollak
  • Transfer
To begin with, let me clarify that I have been a great lover and supporter of Scala for 5 years now. I have written books and articles about Scala. I also worked with many companies that started using Scala and Lift and conducted a code review of a huge number of Scala projects. I used to think that Scala is easy. It has been and continues to be a cure for many Java problems. In terms of “complex or even impossible things in Java are pretty simple in Scala,” Scala is a pretty simple language. Working with collections is very simple. Isolation of business logic makes programs much more supported and incredibly simple than if they were written in Java.
So why is Scala complicated? Here is the best I could come up with:

  • Scala is trying to take on too much. This means that you can continue to write Java-style code, which is both a curse and a blessing. But in the long run, I think it's still a curse. There is too much debate about the contrast between OO and FP. These kinds of discussions are acceptable if you are a small team, but they are damn bad when you are trying to learn how to write Scala Java - developers who really do not want to learn or change. Scala's stunning benefits actually begin to show up when you write in FP style, but it's almost impossible to attract OO developers until they themselves want to write in an unusual style. In this case, less language features, like in Java or Ruby, are easier to adapt, narrowing down the range of potential solutions.
  • poor support from the IDE (and always will be). The Eclipse plugin for Scala (or whatever else it is called there this week) is crap. He continues to be so for the past 5 years of my work with Scala. Constantly I hear “it’ll be better,” and yet sucks! IntelliJ's support for Scala is acceptable to me. But those who need templates in their IDE will not find Scala support good enough. Firstly, Scala patterns / patterns are so diverse and fragmented (OO through mixes is the way of ScalaZ) that there really are an incredible amount of them. If you successfully write code in Emacs, Vi or TextMate - everything is in order, and the transition to IntelliJ will seem nice. But if you expect a “goodwill” similar to that obtained from Java IDEs, your dreams will be broken and never come true because of Scala’s all-encompassing power, which will be difficult to implement, requiring a huge amount of investment. And even Typesafe with their 3 million in the account can not guarantee this.
  • The Scala type system is extremely powerful, but from your point of view, perhaps even too much. In ScalaDocs, some signatures can look very intimidating. Take a look at
    flatMap [B, That] (f: (A) ⇒ Traversable[B])(implicit bf: CanBuildFrom[List[A], B, That]) : That

    and now try to tell me that it didn’t blow your mind. Beginners use this method every day, and maybe 20 times a day. Scala documentation needs a library that hides all this complexity. The complexity that makes the flatMap method incredibly powerful. A type system and related documentation require a simpler and more user-friendly display mode.
  • Novice developers who need to support more experienced programs should understand the idioms and patterns in the code. Despite the fact that Scala brings business logic to the forefront (rather than spreading through a bunch of for loops and complex if-expressions), depending on the idioms used, the code is still not obvious and easy to read. And at the end of the day, it would be nice for you to join a team to discuss the code written by Scala along with all the techniques used. This is also true for Ruby on Rails, where hashmaps can virtually replace all programming paradigms. But in the Rails world, the paradigm is uniform (although not based on type checking) and easy to read. In Java, the same patterns are already embedded in the IDE, so developers during their “growing up” learn and become able to define them. But unfortunately,

There are several types of commands for which Scala is definitely a better option than Java, Ruby, or some other language. Twitter is great proof. They need a clear, type-safe, high-performance language and environment. And Scala provided them all with that. Foursquare uses Scala complexity for its filtering mechanism. You must be good enough to be able to master Scala and be successful at Foursquare.
But if you have a team with skills close to average, Scala may not be the optimal choice (it depends on the management ... is it necessary to use Scala's challenging traits to filter and improve the team?) Being an average company, from the point of view of training, Scala will be cost you to abandon existing developers, lack of patterns. You will need a strong CTO or architect to develop patterns, rather than isolating them from books or IDEs. And the number of such medium-sized companies with rather strong technical directors or architects, to put it mildly, is small.
So, how do you find out if Scala is easy to adapt to your organization:
  • Your company has speakers in JavaOne, OSCON, Strange Loop, QCon - Scala will be easy
  • The discussions that are being held contain the criteria for moving from a regular developer to a senior - Scala will be difficult
  • If necessary, your developers will be able to write code in NotePad - simple
  • Your developers are indifferent or say 3 “Hail Marys” when they hear the name “Zed Shaw”: Scala == Hard
  • Developers polls follow on Dean Wampler on Twitter: Scala is simple
  • Your developers come to work at 9.15 and leave until 6, without checking their email - Difficult

Of course, you may have your own thoughts on this subject. But I definitely agree with the statement that Scala is complicated for the average team. And it’s not only complicated, but it may not bring any advantages either in the near or in the future. Those that could bring teams consisting of participants with 95% skill.
And a few more thoughts:
  • Yes, the type system in Scala is very powerful and can lead to great code beauty like in Scala collections.
    Take a look at stackoverflow.com/questions/1722726/is-the-scala-2-8-collections-library-a-case-of-the-longest-suicide-note-in-histo and www.scala-lang.org/docu /files/collections-api/collections-impl.html
    But there is a difference between the needs of language / library designers and mid-sized developers. And the lack of such separation in Scala entails difficulties for the latter. Personally, I don’t think that I could express ideas in Lift so clearly and powerfully in any other language. Therefore, as a library designer, I love Scala. But like me, and many people who do not consider Scala difficult are not average people. And the 11-year-old kid writing on Scala is also not in the middle.
  • Yes, an improvement to ScalaDocs that provides “simple” and “architectural” viewing can be a big win. But this is still just the starting point, but not the end.
  • I unequivocally reject the argument “excellent, then we will find more professional developers”. We should solve the problem of “Scala is hard” by working to improve the competence of developers as a whole (some who can read type signatures, others who can express their programs using mathematical approaches, etc.), but we are moving away from the point. And the bottom line is that Scala is not so suitable for starting a revolution in training, education or hiring, as it is for enhancing the professionalism of the average developer, in order to stop being difficult for him.
  • I doubt that anyone who reads this or my Twitter is an average developer and Paul Snively, you are far from average, and don’t even try!

Also popular now: