Bozhidar Bozhanov

About Bozhidar Bozhanov

Senior Java developer, one of the top stackoverflow users, fluent with Java and Java technology stacks - Spring, JPA, JavaEE, as well as Android, Scala and any framework you throw at him. creator of Computoser - an algorithmic music composer. Worked on telecom projects, e-government and large-scale online recruitment and navigation platforms.

I Don’t Like Scala

Yes, it is my opinion, and yes, it might seem like a hate-post. But I’ll try to address the issues I have with Scala and its surroundings. I have used Scala in a single, relatively small project (currently working in production), so I guess I’m somewhere between “n00b” and “intermediate”.
 
 
 
 
 
 
 

  • there are multiple right ways to do the same thing – there are a lot of tasks that you can achieve with one or two lines in Scala. But often there is more than one way to do it, and there’s no obvious winner. The options vary on the brevity-readability scale, on the functional-imperative scale, and in many other ways. I know what currying, partial functions, partially applied functions, folding, collect, map, apply, etc. do, but given a simple task I can use all of them I don’t know which one. Probably because I’m a beginner – true, and over time I guess I’ll build a preferred set of approaches. Which will likely differ from those of any other co-worker, and the projects will me “messy”. It would be something like having half the project with curly brackets on same line, and the other half – on the next line.
  • it’s cryptic – you can probably be ok with all the symbols flying around after some coding, but I find it plain ugly. It is a high-level language and the use of so many symbols is troublesome. Take a look at this stackoverflow question to see what I mean.
  • binary incompatibilities – I have an error that in a Scala 2.10 project I can’t use a library compiled with Scala 2.9. There are reasons for that, and it will probably be improved or completely fixed in the future, but for now it’s making life harder.
  • not smoothly integrating with existing java frameworks and tools – this is partly due to the different mode of thinking (e.g. you may not need a DI framework in Scala), and there are already a couple of viable Scala alternatives (e.g. ORMs), but sometimes you would prefer to use proven technologies that you are familiar with. And it’s not only frameworks, but tools as well – I found it a nightmare to serialize JSON 6 months ago. All options had at least one thing that isn’t working as I need it, or lack a feature I need (both the java ones, the Java-Scala bridges, and the native Scala ones). I ended up using an abandoned project (jerkson). Luckily, the jackson support is now fixed (at least for my use-cases) and I switched to it. The same probably goes for other libraries as well.
  • random failures – the time I’ve wasted in random things that break during compilation is significant. I only remember the last example, where I extended some Java class and I got an “AssertionError”, with some extra information that I don’t think makes sense to anyone, other than the author of the compiler. This particular example is related to the previous point (as I extended a Java class), but there are some more that I don’t remember, because they were random.
  • irrelevant compiler errors – this isn’t universal, but sometimes you get a compiler errors that are not at all related to the actual problem.
  • slow compilation – I haven’t really experienced that to a significant extent, since the project was small, but worth mentioning – see here
  • IDEs used to be terrible. The scala-ide I’m using is from 6 months ago, and it is practically unusable – refactoring doesn’t work, inspection in debugging doesn’t work, sometimes compilation doesn’t work (while at the same time the maven build runs fine and classes are compiled). I tried IntelliJ back then, and it was slightly better, but I somehow didn’t always compile on save. Now the newest IntelliJ plugin works way better, and I’d say is actually usable. Probably the same goes for the eclipse-based scala-ide. So things are improving indeed, but used to be horrible at a time where you’d expect a technology to be more mature. And no, I don’t want to use vim/emacs/jedit/whatever for a statically-typed language that allows for refactoring, call hierarchies, etc.
  • annotations, enums, reflection – coming from Java, I “cherish” these things. And while if you are in a pure Scala thinking, you may not need runtime retention of annotations, I still haven’t reached that Nirvana, and I also need to use it in conjunction with Java libraries. The workaround is to define java annotations in your project, alongside the Scala classes. Enums – I just don’t like the way they are defined, it’s unnecessarily verbose. And reflection is coming to Scala, but things like @ScalaSignature(bytes) scare me a bit.
  • steep learning curve – even if you are familiar with functional programming, scala introduces a lot of stuff, including the “cryptic” symbols mentioned above. Not only that, but in order to get a full-featured scala project, you may need to learn a myriad or new frameworks and tools, like scalate, scalatest, Squeryl, etc. Partly because the Java-alternatives don’t work well with Scala, partly because the Scala alternatives are taking advantage of Scala features.

I’m not saying you shouldn’t use Scala. And obviously I haven’t listed all the good things about it. But for now I don’t like working with it – I am less productive due to the above problems that I would be in Java, and for me that trumps the productivity benefits that come from the cool language features. Things are obviously improving (both IDEs, the language, the runtime and the libraries), and I certainly don’t regret doing the project in Scala, as this is invaluable knowledge that I’ll possibly use later on.
 

Reference: I Don’t Like Scala from our JCG partner Bozhidar Bozhanov at the Bozho’s tech blog blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

10 Responses to "I Don’t Like Scala"

  1. Ian says:

    I was thinking about this the other day (Scala and other functional languages) and mostly your first point. It seems with functional language in general there are 100 different ways to the same thing. Some see this as a strength, but after using a different functional language (Mathematica) I’ve come to believe definitely this is not a strength. In functional languages, people are discouraged from doing things in a simple procedural loop oriented way. There needs to be more and more ‘functional helpers’ to handle special cases. Over time there comes to be 100 difference functions you can use to iterate over items in slightly different ways.

    In Mathematica for example there is Map, Thread, Select, Cases, Table, Array, NestList, Sow, Reap, Join, Partition, Scan, Split, SplitBy, Gather, GatherBy, Outer, Inner, FoldList, Apply, Riffle as a few examples of the ones whose names I can think of. All this just to avoid doing a slightly more verbose for loop. Mathematica still has For, Do and While though, because it turns out that even with all these specialized functions you still need to occasionally resort to a procedural loop to do exactly what you want. The ‘brevity’ of final code is kind of a lie because it relies on the specific functionality of one of a hundred slightly different functions under the covers. While most procedural loops are usually easy to understand, the resulting shorter code from the ‘functional-way’ is usually incredibly difficult to understand and requires visiting and going over the documentation again and again. It’s an incredible cognitive bottleneck, just to save a few characters of typing.

    • Nepomuk says:

      Well then you can code Assembler as well, as everything you need is just filling and reading registers. It’s true that there maybe more ways to do the same thing, which is in general not a good idea. However you will understand code a lot easier, when the functions are well named. This is IMHO the real problem, as symbolic operators are sometimes used to heavily.

      Consider the following example

      val list = List(1,2,3,4)
      val (even, odd) = list partition(_ % 2 == 0)

      where as using a while loop

      val (even, odd) = (ListBuffer(), ListBuffer())
      for(e <- list) {
      if(e % 2 == 0) {
      even += e
      } else {
      odd += e
      }
      }

      At some point you will start implementing this functionality itself in some kind of library (or using apache commons or guava for this). Another neat example for partition would be file handling:

      val paths = … // List of paths
      val (files, directories) = paths partition(_.isDirectory)
      val (executables, nonexecutables) = files partition(_.isExecutable)

      This is readable, understandable even with less code. Writing will be harder, but you only write once and read code a lot more.

  2. Artie says:

    I’d like to take the time to go through several of your concerns:

    1) multiple ways of doing things – In my experience using scala at two different gigs, I’ve just not really run into this problem that much. You definitely do gain a feel for when to use what functions to use. For example, foreach vs map, you can do everything with map that you can do with foreach, but if the return type is Unit, then use foreach. And I would much rather have the scala collections framework than the java collections framework (Im speaking from a pre-java 8 standpoint, lambdas can make the collections framework in java much better, but it remains to be seen if they will).

    2) cryptic – yes, it can be cryptic but there are improvements on this being made. This isn’t purely a function of the language but also a function of the library and how the standard lib is built. I like having operators tied to functions and I think being able to define new operators gives you an expressive power that’s simply not available in java. Look at Akka’s actors. I find the ! and ? much cleaner than tell or ask. That said, a few good examples of how scala has changed wrt this is scalaz and dispatch. Both of these are moving away from using operations to traditionally named functions. Note that it’s good practice in the scala community to not use operators unless it REALLY makes sense to. e.g. it’s really well know that with Actors ! is fire and forget while ? isn’t.

    3) binary incompatibilities – this is one of the main factors in what has slowed java’s growth and made it an overly bloated API. For example, why in the world has java.util.Calender not been simply replaced with Joda Time? I havent run into many problems with this in my experience. Typesafe has specified when releases will be compatible and when they wont. Im comfortable with this tradeoff that allows the language to continue to improve. Please refer to this post for more details: http://suereth.blogspot.com/2011/12/scala-fresh-is-alive.html

    4) I havent run into any JSON serialization issues. I’ve used lift-json to great effect and haven’t found anything missing from a feature perspective. As far as wanting to integrate with java frameworks, I’ve integrated with jersey, jedis, and a few other frameworks with no issues. That said, I think its supremely important to consider scala a different lang all together. It’s not a cleaner java so let’s not limit ourselves to the JVM. I ask that you share more details on your struggles though.

    5) You’ll need to share more detail here. I havent seen random error’s though when extending java classes

    6) Can you give an example here? I havent seen any compilation errors that dont make any sense

    7) slow compile times – this is a valid complaint however it’s worth considering that the compiler is doing a lot more. there’s a great deal more of code generation and other things that the compiler does when compared to javac. It’s a trade off, but IMO worth it.

    8) You’re being critical of a language based upon the previous state of tooling. I think that’s not really valid.

    9) enums are kinda terrible in scala. annotations are available. as far as reflection, what are you looking for?

    10) you’re complaining about having to learn new frameworks for a new language? again this isn’t valid. there’s great reasons why I would say that tools like squeryl leave hibernate in the dust. I dont see the point in coding in a language that offers a bunch of new tools for expressing and proving programmatic logic and then choosing to limit yourself to a language which doesn’t take advantage of those tools. It makes no sense. You made mention of scala alternatives that don’t work as well. Can you please share? In general, my decision tree for finding a lib/tool is check for a scala way of doing something and if that’s not available fall back to the java way.

  3. Samuel says:

    Creds: Wrote Scala code for about 3 years where it both used and plugged into a large Java project.

    “there are multiple right ways to do the same thing” To some extent this is true, but I think you do a disservice throwing a bunch of names out implying they do the same thing. “currying, partial functions, partially applied functions, folding, collect, map, apply” are used for different things.

    Ian: I don’t know about Mathematica, but Scala’s List-oriented, looping functions are present in many popular, modern languages. Java 8 is supposed to get stuff like this. It certainly seems like many think these functions are nice.

    “it’s cryptic” Are high level languages typically defined as ones that don’t allow symbolic operator/methods? I wasn’t aware of that. While I do agree with the hard-to-search argument, it is easy to find the scaladoc for the cryptic symbols, which are just methods.

    “binary incompatibilities” This is painful, but how far off is the ‘Java is about the only language that doesn’t have this problem’ argument? Regardless, this is scary to someone who is very used to having a large (hundreds) of dependencies.

    “not smoothly integrating with existing java frameworks and tools” As mentioned above, my Scala project both used a huge number of Java dependencies and plugged into a huge Java project (based on Apache ServiceMix). I wouldn’t claim there was never any pain, but it never made me regret using Scala. In my case, Apache Camel caused me some pain. Do you have specific examples?

    “random failures” & “irrelevant compiler errors” Only you know how much these truly cost you. Scala, like almost all software, has some bugs. Hopefully, the Scala contributors are effectively dealing with them. During my years with Scala, the compiler has confused me, but this wasn’t the norm.

    “slow compilation” This is definitely a pain. In my case, our project had a significant amount of Scala code, and it certainly was much slower than the Java code.

    “IDEs used to be terrible.” Pointing to the past when saying something sucks is sort of silly IMO. Regardless, IntelliJ support has been pretty good for quite some time.

    “annotations, enums, reflection” I haven’t used Java annotations much, so I don’t miss them. I have wanted Java enum-like stuff. I haven’t used Scala’s reflection support, but isn’t it touted as superior to Java’s?

    “steep learning curve” You’re repeating stuff from other sections, so I won’t repeat my replies regarding ‘cryptic operators’ and Java interop.

  4. Ian says:

    Samuel,

    Mathematica is also List-oriented. I’ve seen some pretty scary code in Mathematica. It can be very compact and almost impossible to read.

    I only played around Scala a couple of years ago and didn’t like it’s Type system. Often couldn’t do what I wanted without using some hack feature (implicit or something like that). It seemed like a total mess to me. The collection library was also incredibly confusing. Several times I tried to extend make my own special case collection. Wow, beyond painful. I decided not to pursue it further.

  5. Joe Barnes says:

    So is the learning curve steep, or have you simply forgotten how long it took you learn to develop software in Java? I suspect your blog post would have been the reverse if you learned functional programming first rather than imperative programming.

  6. Bozho says:

    I have learned functional programming in university, so the functional aspect was not new to me :)

  7. EECOLOR says:

    I think you are wrongly blaming the Scala programming language. The language does not force you to write stuff in a complicated fashion. It fully supports object oriented and imperative programming. You can very well just use a subset of Scala to make it feel more like Java.

    I you would stick to Java style of programming you would of course only leverage about 1/3 of what Scala let’s you express, but that’s fine! You determine your own learning curve. At first it’s just a few syntactic differences like `def`, `val`, `var`, the ‘weird’ constructor, `trait` instead of `interface`, etc. This is all fine and not complicated at all for an experienced developer.

    One thing I have noticed though is that people tend to miss the actual thing that makes Scala feel complicated: the libraries. Libraries are written by people who tend to learn more and more of what Scala can offer. They (for example) tend return `Option[String]` instead of `String` (or `null`) and by that expose you to an unknown (or new) type. They will probably also introduce functional or type-level programming and force you to do the same! Or… you could just not use their libraries.

    About the ‘weird’ operators, enthusiastic library writers without a lot of experience tend to overuse weird method names, just because they can. There are however two parts of Scala that are legitimately using ‘weird’ names for classes or types: functional and type-level programming. A lot of concepts in those worlds are known as nothing more than a ‘weird’ symbol. Scala exposes you to those new worlds and that might be scary.

    All in all I do not think Scala itself is complicated, it allows for multiple programming paradigms and is (one of) the first languages to do that. Eager developers tend to try, learn and incorporate new knowledge into their programming and thus their libraries. Most of us programmers are well-schooled in one of those paradigms and thus at least 2/3 of the language features are alien for us.

    I personally love the fact that Scala exposes me to other ways of thinking about programming and expressing myself using the language. It pushes me to learn! If being productive is more important for you than learning, I guess Scala is not for you.

  8. javawerks says:

    ~ Bozhidar,

    I like Scala, long crazy story to follow. Yet I feel Scala will forever remain a niche language. And that’s just fine. Why wouldn’t it be? Why must Scala surpass Java or any other language to be successful?

    Your critical observations of Scala, though, are painfully spot on. Of course, that always alienates the hardcore Scala folks. Tough.

    Yet, after 12 years, Scala has failed to conquer the enterprise space, not that it initially set out to do so. At least it’s on the map, not unlike a small town in the Switzerland.;)

    And Rod Johnson’s dream of Scala dominating Java by 2018 will simply not happen. Of course, he must know that, given his deep knowledge of the Java enterprise space.

    Even more worrisome for the Scala community is Paul Phillips’ talks, which are scaring prospective developers away from Scala and making Scala newbies reconsider their decision to use Scala.

    Paul, a Typesafe founder, is a true Scala guru. As for lines of Scala written, no one can compare. Moreover, he speaks the truth, and the the Scala community knows it.

    Yet few in the Scala community want to listen to Paul. It’s even more interesting how they don’t have the technical chops, nor ethics, to challenge Paul. To me that represents a community in denial.

    The major force holding back Scala has always been its deep ties to academics and bleeding-edge uber geeks. And that just doesn’t work in the enterprise space, where making money, with the least amount risk, is absolutely paramount.

    Once again, I think that’s okay. Scala has and always will march to its own tune. So just let it be. It’s found its niche.

    ~ javawerks

Leave a Reply


8 × = thirty two



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close