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.
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 will write my comments on each of your “hating” section 🙂
*there are multiple right ways to do the same thing* – this is a problem because there are multiple paradigms supported in the language. The thing is that if you ask 10 people to map a list in c++ they will give you at least 3-4 different solutions. But this is indeed a problem if the project grows in size and more importantly people – everyone writing in their own style :(.
*it’s cryptic* – I think you will get used to this. I am actually more scared by the precedence of operators which is somewhat related to this.
*binary incompatibilities* – This is the biggest problem actually. And it becomes more apparent when you start using more libraries each compiled for different version. I think this should be much better now with cross compilation(I think they call it this way) in SBT. But it sad to see artifacts with metadata like ::_ in maven central… When people start using this convention there is a huge problem.
*not smoothly integrating with existing java frameworks and tools* – This is a problem for every JVM language that I know of. They always write wrappers or just reimplement something(like the json parser) and of course it buggier and slower.
*random failures* – I haven’t had that problem(my code compiles from the first time (rofl)). No really – there were a lot of reports about this.
*irrelevant compiler errors* – cannot comment on this
*IDEs used to be terrible* – I use vim with ctags for scala and it was ok for my toy projects :). Of course this is a no go if I am doing real work.
*annotations, enums, reflection* – Not sure why they don’t like the idea of annotations and enums as they are defined in java – maybe they try to be different, not sure… Reflection is a real pain and it is a hard to solve problem because a good API support will require introspection of added fields/methods by the compiler(imagine a case class retrospection)
*steep learning curve* – yep. This is because there is not only functional programming added to scala – they add currying, traits, ref types, implicit conversion, implicit parameters, maybe a lot more I don’t know about. If you want a simpler functional language look at clojure if you don’t mind the braces 😀
My biggest concerns:
* Stacktraces are a HUGE issue – just run *jstack* on your scala process pid and watch all those cryptic names. First google result from “AssertionError scala” is http://stackoverflow.com/questions/3661411/scala-sbt-assertionerror-on-build. “xsbt.Analyzer$Compat$.linkedClass(Analyzer.scala:225)” is just not professional and those things matter in production.
* I am scared from the HUGE interfaces and traits in the standard library – I think that Joshua Block said the same once.
* Don’t like languages which create load of objects behind my back – compare streams in java8 and scala collection APIs for a chain of operations.
* Some people in the community(mostly the language zealots) write and recommend code that requires major degree in computer languages.
More or less I agree with your comments. The most problematic things at least for me are:
1. Too many alternatives to do the same things. In big team you will need a very strict code convention, so everybody could read someone else code. You can twist the code in so many ways, that it may start to look like that more than one programing language is used.
2. The incompatible changes between the versions. I think that it is time for language developers to break this practice and start to develop stable compatible language releases if they want Scala to be used for serious productive projects.
3. Too many work is done behind the curtain. I, as a Java developer find this very disturbing – more or less I feel that I am losing control over the VM when using some high-level constructions. Actually when I am learning some new language syntax sugar in Scala, I always try to find how it is implemented using Java/bytecode in order to feel safe to use this feature. From one point it is good, but it could be time-consuming, or eventually I might get lost because of the complexity.
Anyway I still believe that Scala language provides some nice features and paradigms and in general I like it. But honestly I rather use Scala for some side-project (fun, research) than in productive landscapes.
Java is very simple, with some weird things. Scala is very complex, with some cool things.
Most of the time, simple beats complex. Simple is beautiful 🙂
Java is lingua franca.
I agree with your points. Programming languages always get more complex over time, and if a relatively new language is already at this level of complexity, I wonder how Scala will look like in ten years.
The multiple ways of doing the same thing wouldn’t be so bad if one of them were preferred, or simpler, and the others were deprecated or meant for special situations. But, as you say, most often there is no obvious winner. Method 1 has some advantages and some disadvantages. Method 2 has other advantages and other disadvantages. If you are learning, how can you choose if don’t know the language very well yet? You need to become a Scala guru to know for sure whether you can omit parentheses…
Another problem is the memory consumption. Nothing in Scala eats up less than 1 GB of memory.
Yes, there are multiple ways to do the same thing. This is a great thing for a language to be highly flexible. You can moan and complain about how there’s too many options, but that’s a negligible complaint compared to the benefits it provides when you start coding more complex scenarios.
Scala can definitely be cryptic, but it’s up to the discretion of developers to manage that. If you’ll notice, the Scala language itself isn’t very “cryptic”. You have a few basic concepts you need to learn and then it’s pretty simple and very few special characters. There is definitely a problem with several frameworks making confusing syntax in their code, but this is trouble with great power. 😉
Binary incompatibilities, again, I think is a bigger benefit than negative. Scala can do a lot of internal optimizations and changes to the API from release to release and you end up having to recompile, but it keeps the language from getting stale and hideously ugly with backwards compatibility like Java has.
Most of your other complaints come mostly from ignorance of how to use the system. Yes, there is a bit more of a learning curve with Scala than most of the new languages today, but for the last time in this response I’ll say, it’s a positive thing. Scala was architected to be a great language without compromising itself to “easily learn for Java developers”, or bring in a bunch of ideas so it feels like other languages. They took the time to create a great language that is powerful and useful. At the end of the day I would much rather have a language that I have to take some time to learn and then I can soar with it, than an easy-to-learn language that I’m going to be hindered by down-the-road because they compromised the capabilities in order to make it easier for the weak minded. 🙂
All of this being said I’ll give you a little background on myself. I run a software development company and I have been primarily working in Scala for the past two years now, although I frequently still write Java, JavaScript, ActionScript, Perl, C++, and a slew of other languages as needed. In my spare time I’ve been mentoring two teenage girls that I have been teaching Scala. They have been rapidly picking it up and recently even wrote a game with it. If a couple of young girls who have no programming background can pick up Scala so easily I think you should re-evaluate how complex it really is. 🙂
In parting I’ll say that your perception of complexity I believe has more to do with your presuppositions of coding standards than with the inherent complexity of the language.
– Matt Hicks
“there are multiple right ways to do the same thing” – Then, you will *love* Java 8’s new Streams API 🙂
You can learn an illiterate to read, but don’t expect them to appreciate poetry (right away).
Why I believe Scala won’t succeed is the syntax. From the syntax (syntax, not semantics) point of view Java is more similar with C++ rather than Scala. Think about Java success: it greatly copied C and C++ syntax since it wanted to steal C++ programmers. Now Scala wants to steal Java programmers, but changed the syntax.
First thing to notice is how typed variables are declared: instead of “int x” like in C and Java you use “x: Int”. This is different in three ways from Java:
1. Changed order; instead of [type variable] as in C, C++, C#, Java now is [variable: type].
2. Added a new semantics for “:” operator
3. Changed code convention: is not int nor Integer, it’s Int.
I have only scratched Scala at the surface, but I am sure examples as the above are multiple.
IMO, a language should be simple enough so that any sufficiently experienced programmer can see what’s going on simply reading the code, after a few hours of study.
For example, the programmer should be able to read: “here’s a function call, then a temporary object is returned and another call is made, then we pass an anonymous function, then it iterates, then…”
If the resulting code is complex, it’s not the language’s fault.
On the other hand, if a sufficiently experienced programmer (not a newbie, not a scala guru either) reads something and exclaims: “WTH is going on? How can I even search for this construct on the internet???”, then it certainly is the language’s fault…
Though I am not Scala lover, but I think it has got something real to offer, especially succinct, concise code, mix of functional and oops, lot of built-in best practices and all. If you also don’t hate Scala and want to learn it, you can take help from these FREE Scala book.
Scala isn’t a very complex language in my opinion. From a Java / C++ perspective it is strikingly different which gives the appearance of complexity for programmers used to it. I’ve been a Java programmer for years and it took a bit to wrap my head around the language, but it wasn’t because of language complexity, but rather just paradigm differences.
Scala *can* be complex because of cryptic decisions programmers decide to use or because of complex topics (that aren’t even possible in Java), but at its core I think Scala is more simplistic (primarily because of consistency) than Java.
@Someone:
I think the non-C style typing of Scala was one of it’s best decisions. Other new languages, like Kotlin, took that over. (BTW: Scala is not the first and only language to use such style).
Why is it so? The C style typing was invented in a language where you had to always put in types and no generics existed. Now with functional languages with generic types on one hand and type inference on the other, this style causes more and more readability problems.
* with a leading return type, a method name runs more and moree to the right, or -when left out- jumps to the left. Its hard to tell.
* same for long variable types vs. inferred ones.
Try in Java8 to write a method which takes a function from String, String to Integer and returns a Function from String to function of String to Integer. This is an FP standard called currying.
Now write the signature.
Dart e.g. makes it even worse for function types as parameter.
And BTW, Scala’s way to write types is usual for enterprise developers who are used to UML.
Regarding the int/Integer vs. Int: I see it as advantage that my code is freed from the raw vs. Wrapper boxing/unboxing debacle!
That is a technical detail my algos should not be bothered with.
to be sacrastic – scala is the academic attempt to write an cypher for even the simplest algorithms…ever seen the ++ operator be used on sql ddl stmts for different entities and next to it its again the simple increment…ever seen that spagetti rest routing of another library…and we see what reactive programming and functional approach gives us headaches in the callback hell…this is what all the cool kids think is awesome until they get their pay back 5 years later when they have to maintain this…
For help with stacktraces you might use: http://stackifier.takipi.com/scala.html
For help with reflection you might use: https://github.com/fwbrasil/smirror
Yep the fact that there is a scala service to make sense of your stacktraces is rather cool… NOT.
Imagine that you had a need for such a service each time you had a problem in production.
Telling us that you learned two girls to code doesn’t make the language better or easier. I can learn statisticians to code in R in two days(at least the syntax) but that doesn’t make the language less cryptic, hard to maintain and hard to understand.
Also the syntax is not the problem here. Syntax doesn’t really matter to me – I just want to have a clear, maintainable system and this is hard in complex scala projects. This is actually one of the things that made yammer switch back to JAVA.
There’s no shortage of Scala bashing, but judging from the immense popularity of the Coursera courses around Scala, I can only conclude that Scala is a very popular language.
As for the known shortages of Scala (binary compatibility, compile times, etc.), I must say that in my experience the situation has improved a lot, and continues to improve.
I am a happy Scala user. So are the other developers in our team. We use Scala 2.10 in production for rather complex data manipulation (nothing fancy). We use Scala mainly for its excellent Collections API, and would not want to go back to Java (including Java 8, when it comes out). Using a functional OO style, we are quite productive, and deliver software that has a low bug count. Several Java developers that came to our team quickly became productive with Scala, and we have no problems maintaining each other’s code.
Our management is happy with the results of our team, and wants to increase the use of Scala in our company.
I am just one (otherwise) silent but happy Scala developer, probably among many. Given all Scala bashing, I thought it was appropriate to speak up about our positive experiences with Scala.
While I don’t agree with all your points (e.g. binary incompatibility is one of the most requested things of Java of late since it has so much legacy crap in there and generics were badly implemented because of it), I do also understand your frustration in the other points.
What I will say is if you expect learning to program Scala as easy as learning Groovy or Ruby you’re mistaken. I’d even go so far as to say its harder than Clojure. But if you had to learn say Haskell I think you’d find a similar level of difficult getting “back up” to your Java proficiency levels.
Its easy to forget as Java developers we’ve spent hours and hours crafting our skills, usually as part of paid work. To expect the same after only several hours a week for a few months is in this authors opinion a little egotistical unless you are a genius or Sheldon Cooper.
I’m particularly fond of Scala but agree the pro-Scala camp can be overly vociferous and dismissive of any perceived criticism. Its just passion expressed badly.
I have had gud experience with scala for a lot of non production thow away codes. Specially that was used for load testing and simulation. I found it handy. Though learning curve was really steep and after 6 month of reading scala I still dont feel very comfortable.
Your opinions counts 🙂
Hi Bozho:
I started following your blog a couple years ago because I liked your answers on Stack Overflow (I come from a Spring/Java background).
I’ve been using Scala for the last four years and I really like it. I am a lot more productive and having more fun. Going back to Java now when I have to is tedious.
Here’s my comments on your issues:
– Cryptic: Scala allows you to use symbols and some libraries (especially older ones) went crazy with them. My advice is to avoid these libraries. The best practice in Scala now is to not use symbols unless they have a commonly understood meaning (like +). And to always provide a non-symbolic alias for the method.
– Binary incompatibility: to be honest this hasn’t been a real issue for us. Our projects don’t use a lot of Scala-based libraries and by the time we switch to the next version of Scala the ones we do use have been upgraded. That said, the Scala team is working on improving the binary compatibility situation.
– Integrating with Java frameworks and tools: We use *tons* of Java libraries. The interoperability is very good, especially calling Java from Scala. I’ve used Hibernate/JPA, Spring, CXF, etc. I wouldn’t judge interoperability based on the JSON serialization issue. Ps. I know you’ve got Jackson working but also try spray-json or lift-json. Really sweet stuff.
– Runtime retention of annotations: yeah, I really want this too (for JSR-303) and I’m bummed that it’s not supported but I’ve gotten over the fact that I just have to code these in Java. (See https://issues.scala-lang.org/browse/SI-32)
– Enums: yes, the existing Enumeration class sucks but there are workarounds – we use case objects (http://stackoverflow.com/questions/1898932/case-classes-vs-enumerations-in-scala) and they work fine for most cases (no pun intended). Also coming soon there will be enums that are on par with Java enums (see SIP-E: https://docs.google.com/document/d/1mIKml4sJzezL_-iDJMmcAKmavHb9axjYJos_7UMlWJ8)
– Reflection: Java reflection is fully supported – you may not need to go any further. Scala reflection that is in 2.10 is incredibly rich and it should be non-experimental by 2.11. @ScalaSignature is the way the compiler provides the metadata to the runtime – it’s not intended to be seen by humans.
– Compile time: agreed, compile time sucks – this is one of the top priorities of the Scala team for 2.11. In the meantime make sure you have Intellij set up to use the Compile Server – that will make things way faster. With the compile server running typical things like changing one file and recompiling is almost as fast as Java.
– Learning curve: For a Java developer coming to Scala I would recommend staying away from things like scalate, Squeryl, sbt and instead continue using the Java equivalents that you are used to (say Spring MVC, Hibernate and Maven). Basically jump into the shallow end of the pool. Then gradually start experimenting with other things. Scalatest is a good place to start. Same thing with code – start by writing code just like you would in Java. Then gradually start trying out other styles (eg. functional) and other more complex Scala features.
My overall advice is – give it some more time. It can be overwhelming at first, just like learning any other new language/ecosystem. But with the right approach you’ll start on a journey that will be very rewarding. I’m still learning new things and having a great time.
Thanks for the extensive comment. I think that the purpose of the such “rants” as mine is not only to point out the weaknesses of a language or library, but also to spark discussions, which ultimately influence the development of the language. So, if everyone agrees that the cryptic symbols are bad (which obviously has happened), than the convention becomes not to use them, and eventually they’ll go away.
Incidantelly, I’ll be involved in a scala project at my new job very soon, so we’ll see how things will unfold.
Hi Bozho!
My suggestion to you or anyone else with misgivings about Scala is if you haven’t done it already you should do the free Functional Programming with Scala. Actually hearing about Scala from Martin Odersky himself is a great experience. I would say this is one of the best computer science courses I have taken in my life. Some of the exercises are tough but it’s worth doing all of it, not just watching the lectures. Martin has a great way of explaining things and this will reassure you that Scala is not something academic, it’s something that has been born from Martin’s extensive experience, and once you get it, it’s really liberating – and I am saying this as a hardened cynic of many new technologies!
That’s not to say Scala can’t be used in horrible ways. It clearly can, just as Java can. However you have to be forgiving for a bit because they are all sorts of things that feel alien to the Java programmer (e.g. case classes / objects versus enums, traits vs interfaces vs inheritance) but the way things are done in Scala is different.
Some pretty knowledgeable people did the Scala course like Dean Wampler too.
However, having done the Reactive Programming Course, I definitely don’t feel the same way about Akka! Akka is clearly very still much under development, despite all the hype.
And you are right – the compile time is a real problem. Although Python programmers say that about Java 🙂
I enjoy what you guys are usually up too. This type of clever work and reporting!
Keep up the terrific works guys I’ve you guys to blogroll.
Greetings! This is my 1st comment here so I just wanted to give a quick shout out and say I really
enjoy reading through your articles. Can you suggest any other
blogs/websites/forums that cover the same subjects?
Thanks for your time!
I don’t like the syntax, the sugar and the decision to use metacharacters with ambiguous meanings. Take underscore for example. _ means too many things. import scala._, def f[M[_]], _+_, _=> 5, etc… This is akin to using RegEx symbols for operators… Ugly.
In my personal experience with Scala, I didn’t like it at the beginning and I started liking it after two three months working with it. (I also did first Martin Oderski course in coursera website). I had to create a code generator (generate sql, hbm.xml and java files) based on some xmls definitions. Pattern matching and use of functions as parameters, among other things save my life. I think the same project in java would have taken way more coding.
In my opinion Scala is hard to learn because we are used to program in java for so long. I wonder what would thing a person that started programming in scala, without knowledge of java. After five or six years of experience, ask him to switch to java. He will feel like java is not powerful enough and a pain in the ass too.
Scala reminds me of Perl. Write once and never readable after that. I see the power of scala, the complexity of problem it can tackle but it is a hard sell as a common development platform. I like my scala code but not that of others.
On the contrary, a language optimized for science and math that depends on English words in lieu of symbols to express mathematical and higher-order concepts is troublesome. English is a broken language, extremely poor and clumsy, riddled with ad hoc exceptions, and a very poor choice for expressing functional and mathematical concepts of a highly uniform nature.
English:
define x as a function taking two input variables a and b, now the definition is as follows: a vector of order three with elements seven, eight, and two respectively dot product with a vector of order three with elements two, one and nine respectively, now separately, take the cross product of two vectors with elements a, seven and b and the other vector having elements 9, b times a, and 3. Now multiply the result of the former dot product operation by the result of this cross product operation.
Cryptic:
x(a,b) := ( . ) * ( X )
Are you really going to tell me that the wall of text is easier to read?
Expand your lexicon and get acquainted with the “cryptic” symbols and you’ll find the FUD will evaporate.
P.S. Notice x ~ X, one more reason to steer clear of the alphabet.
@Jorgen Consider my new programming language, in which the space character represents the function you’ve described above. Here is the program:
Since this language is so succinct and requires so few characters, it must clearly be the least cryptic of all languages, because as we all know brevity is directly correlated with clarity. Consider here an implementation of quicksort:
34
See how obvious and clear the meaning is?
I’m not a big fan of Java, because it is verbose and not very expressive, but yeah it’s a sunny day compared to weeding through a Scala project.
I feel like they got 80% through developing the language they wanted, then threw a lot of non-intuitive kludges and punctuation at making it work.
I had to revisit a graph processing library I wrote in Scala a year ago, and I literally couldn’t understand it after even after considerable effort. Why? Because I forgot about the operators and some of the implicit magic that’s going on. So I basically had to relearn Scala.
This codebase is considered “idiomatic Scala”.
We happen to have the same library in Java (from which the Scala port is based) and I could understand it on first read.
I know my IQ, I had it measured when I was young and insecure. It’s 130. It’s not stellar in the coding community, but don’t you think it should be be enough to understand 250 lines of code I wrote only a year ago?
For mere mortals with an itch for maintainable code, Scala is a flawed language.
I ran away from Java to Scala after having realised that I was wasting my life on such a terrible idea as OOP. That’s the only thing I wish I never tried in the first place (well, that and drugs).
Scala was all nice and dandy at first (what isn’t after Java?). But after working for a year in Scala I realized that there’s too much OOP compromise (in order to attract Java developers, I guess). That duality of Scala makes it conflicted about its own nature. It’s not uniform. Code is all over the place. It’s a mish mash.
A year ago I started using Clojure and IMHO, there is no better language out there. Totally refreshing, functional with immutable data structures (you won’t find MutableMap there, no sir).
When you learn the standard library once, all other code somehow falls into place. It’s beautifully uniform and consistent, once you go over the initial hurdle.
The code is data – that’s why everyone squints when they see a lisp for the first time, but that is actually very powerful (macros).
I invite you to watch this Rich Hickey’s talk. It has a life-changing implications if you’re Java or Scala developer and you listen with open mind. Give it a chance: http://www.infoq.com/presentations/Value-Values
Stop being a prisoner!
I agree with Ed’s comment about the overloading of the “_” character. In fact, for the life of me I can’t imagine designing a language that requires the use of a shift+_ to create any important symbol in a language. If I have to take my hands off the home row it should be for a damned good reason like a very seldom used key combination – say for modulo or bitwise operation that isn’t used much. But to overload an obscure metacharacter is ridiculous.
Ironically I like the language a lot and look forward to using it more in the future. But sometimes I wonder if the people inventing these languages type with two fingers.
Just came here to say that I’ve programmed in Scala for 4 years. I think a lot has improved since you wrote this post (especially on the IDE front).
WRT to random failures, I’ve encountered a few times when doing really advanced type inference, but not enough to make it a serious complain. Just put on a type declaration and move on. The worst (the infamous higher-kinded-type unification error that happened when inferring from a covariant type with different n type parameters) was will be solved in Scala 2.11.9 and Scala 2.12!
I come from background of using C++, C#, PHP, JavaScript for different projects. I have also tried some Java and Objective-C for some months or so. Some projects were coded by me, some – by my colleagues and some – by third parties.
The problem is that we have to maintain those projects for long time and I have to switch among them to fix bugs for a few days or so. Thus for me (and also many project newcomers) a crucial thing is mental switching both among paradigms and syntax.
It is easy to switch among C-like languages (except JavaScript and Objective-C for their very unique concepts, such as prototypical OOP ) and still feel mostly at home and be able to understand even badly written pieces of code without any comments.
Of course, after lots of switching your code starts losing language specifics and becomes some kind of “common ground” among all the languages you are using, but it gets things done and is easy to understand for beginners, which is great for large scale projects.
And then a few months ago I was assigned to maintain a Scala project. It was seemingly written by people who enjoy and leverage all the power of Scala but do not add any comments because for them, most probably, the code was “very much readable” as such. But my mind and eyes were completely boggled by those map.map.map.fold, Option, Some, Any, _, _.1, _.2 ….
It just takes so much more mental effort to untangle and debug a complex piece of Scala code that sometimes I preferred to rewrite it in Java – it worked and it was easy to read for everyone.
Sorry, Scala, you are just too awesome and complex for programmers who don’t want (and are not paid) to become true Scala experts and have to maintain many projects in multiple C-like languages.
Totally agree with you, scala is the single most horrible language I have ever tried. Totally wasting time … I will never touch it again in my life.
I wonder how Bozho feels these days about Scala?
Are the above reservations still valid?
@Nick I haven’t followed Scala closely in the past few years, but the general reservations are still valid, I think