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.
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… Read more »
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) {… Read more »
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… Read more »
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… Read more »
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.
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.
I have learned functional programming in university, so the functional aspect was not new to me :)
Oh really? Well that nullifies a lot of my points in my response blog post.
http://proseand.co.nz/2014/01/27/the-learning-curve-of-scala/
Good post, BTW… even tho I disagree. The discussion is always welcomed IMO.
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.… Read more »
~ 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… Read more »
Thanks a lot for writing this – it’s exactly my feelings (although my experience with Scala is much smaller than yours – but whenever I approach it I hit many of the frustrations you mention here). I think a big difference in opinion (people saying “Scala is a solution to all your problems and more” vs people like you, saying “Scala introduces its own problems”) often comes from environment you work in. As it’s been mentioned here, Scala’s background is very academic. It probably works well where you have a small group of very talented people, communicating well with each… Read more »
Scala is just for hipsters. You cannot use it for real/industrial projects because : – The frameworks and IDEs are not really market ready. You cannot set breakpoints, the errors you receive are like ‘Error it does not work please take a look at your project’ – It is weakly typed so you can add 1 + 1 and have the surpise that you get 11. – Being not robost and weakly typed, it is hard to get a compiler error or even a runtime error so most of the time a code, where a bug is introduced, just behaves… Read more »
> add 1 + 1 and have the surpise that you get 11
WTF you are talking about? Drop scastie