I feel that most of (not all) the criticisms are fair, but superficial.
True, the IDEs are poor, for a certain definition of poor. Had I not used IntelliJ for Java, for example, I'd find IntelliJ for Scala amazing. Knowing how much better it can be spoiled me, but frankly, IntelliJ for Scala is not bad. It just could be better.
Also, Emacs has a very robust Scala mode.
True, there's a lot to learn before you can consider yourself fully fluent. You do not need to know everything, however. And once you've started on the path, things tend to flow naturally. For example, implicit conversions are easy to grasp. Once you understand them, implicit parameters and type classes are not much more complicated. Once you know type classes, it opens the door to a lot of functional "design patterns" - functors, applicatives, monads... these are not strictly necessary, but they're fun to learn about. And they teach you algebraic data types, which in Scala means case classes, sealed traits, ... it all sort of flows naturally.
True, it's easy to write absolutely un-maintainable code. While that's true of any language, Scala makes it rather easier than most. It's also very easy to write highly maintainable, legible code, and to avoid complex, ascii art based operators (or at the very least to offer wordy equivalences at 0 cost through `@inline`). I feel that saying "it can be hard to read, if you don't follow basic guidelines" is a bad reason not to use a language. A good reason to be careful, though.
My personal experience is that, once you start feeling comfortable with the language, you get much more productive than with Java. It does require some initial work, though: if all you know is OO, learning how to design your code for composition rather than inheritance takes a while - it takes a while just to realise that it's not a bad idea, let alone embrace it!
Also, ScalaCheck. Man, do I wish there was a good Java equivalent for some of my legacy code (that would not require me to rewrite all of my tests).
Scala does take more work to learn than Java, but I never choose Java over Scala for a new project. Scala is just so much more modern and expressive.
You can write perfectly readable Scala. It just takes some taste and common sense, or alternatively follow guidelines such as: http://twitter.github.io/effectivescala/
We've found IntellJ + Scala to be an excellent combo for our purposes.
I've been using Sublime as my Scala "IDE" for a while now - what it loses in certain 'critical' IDE features like code completion and variable extraction it gains in speed, ease of use and lack of bloat.
I agree that as far as real IDEs go, IntelliJ is the best - but that's not saying much. The rest are pretty awful. They all do many things poorly, whereas Sublime does a few things very well.
I agree that the criticism is fair. It does seem to come from someone with relatively little experience, but if anything, that makes it more valuable. Languages need adoption and new adopters by definition have no experience.
Regarding IDE support, which inevitably comes up when discussing Scala, an honest question: what are good IDEs for Ruby, Python, Clojure, JavaScript, Haskell, OCaml? Is there a good IDE for C++ besides Windows-only Visual Studio? For C?
It seems that Scala always get compared to Java in that domain, but in my experience Java is the exception, not the norm.
(Edit: I assume support for CLR languages is great too?)
Ruby: RedMine/IntelliJ
Python: PyCharm/IntelliJ
Clojure: Cursive/IntelliJ
JavaScript: IntelliJ + all JetBrains IDEs
Haskell: Dunno
OCaml: Dunno
Is there a good IDE for C++ besides Windows-only Visual Studio?: CIDR undoubtedly will be, but it's still in beta right now.
For C: AppCode
If you compare IDE support with those languages, then Scala's IDEs are stellar. I would dare say that IntelliJ IDEA for Scala is better than Visual Studio.
And how long did it take Eclipse to get to that non-perfect-but-good state? Several years. When I checked 6 years ago, C++ support had been already there for a few years and was quite awful. And C++ type system is much less powerful than Scala's, so it should be theoretically much easier to provide good IDE support for.
The C++ template system is turing-complete and partial specializations are more or less equivalent to the way you do type-level programming in Scala with different priority implicits, so I don't see that it would be any easier to support than the Scala type system.
If turing-completeness were the only criterion to judge programming languages, then we'd be all programming in Brainfuck. Indeed, C++ template system is turing-complete, as well as Scala's. But saying they are more or less equivalent is a complete misunderstanding. The main purpose of type-systems is to prove/disprove correctness-related properties of programs. The better the type system, the less frequently it rejects a valid program or accepts an invalid one.
I could go on and list a number of features that Scala typesystem supports natively which C++ does not (e.g. type bounds, path dependent types, variance control, existentials, abstract types...), but there is no need to do that.
There is one much bigger difference between them: C++ templates are not a first-class citizen of the C++ type system. They are just a (turing complete, but quite limited) macro-language bolted on top. Actually the compiler does not perform any typechecking of generic code. All the typechecking happens after macro expansion when generics are gone, and the typechecker needs to understand only concrete types. This is completely different than in Scala/Haskell/F#/C#/Java/OCaml typesystems, which can reason about generic types and can fully type-check generic code.
All true and all quite irrelevant to the problem at hand. An IDE does not need to know which properties a type system makes it easy or otherwise to prove. It just needs to understand the type system. And a useful C++ IDE absolutely does have to understand the template system and the way it interacts with the type system - maybe a compiler can get away with running them as two separate stages, but an IDE needs to do things with incorrect code as well as correct code.
"And a useful C++ IDE absolutely does have to understand the template system"
I've never seen a C++ IDE that could fully type-check template-heavy library code before its actually used beyond just syntax checking and limited type-checking the non-generic types. This is something that can't be done just because of how C++ templates are specified ("duck-typing"), not due to an implementation detail in the compiler/IDE. This is also the reason why good error-messages from templates are so hard to make - type errors are detected at the concrete level (late), not at the generic level (early). This is going to change when C++ finally gets "concepts" and will be able to reason about generic types (but this would be still a very long way to something like Haskell or Scala has).
Once you know type classes, it opens the door to a lot of functional "design patterns" - functors, applicatives, monads... these are not strictly necessary, but they're fun to learn about.
For a certain value of "fun", I guess.
Generally I find in engineering that it's best not to add abstraction (or other forms of complexity) to a system unless there are strong, clear benefits to doing so. The more we learn about Scala, it's just not clear that it delivers those benefits (in proportion to the time investment it demands).
It's not that I don't "dig" abstraction. It's just that I have an infinite list of things to learn about (some fun, some not so fun) in any given development environment. (In general, most of these are in the non-fun category: dealing with dependencies,build tools, and legacy quirks that can never be fixed).
And another infinite list in my own problem domain -- you know, that thing I'm supposed to be, theoretically, directly working on (in the service of which all of these fancy software tools were supposed to be a means, not an end). Plenty of very real and juicy abstractions. More than I can ever hope to get to the bottom of, in fact.
But don't get me wrong. If applicatives and such are your bag, then that's great. Maybe Scala is the right language for you, then.
I agree with you in terms of abstraction; I do believe Scala adds a lot to practical programming as well. I feel the community is tainted by a bunch of type-nerds trying to compile their Haskell, and don't care about writing simple, maintainable code.
We use Scala because it is speedier to push features. I work much quicker in it, and we don't have to worry about a lot of the stuff we would in Java. That said, we don't use a bunch of the most complex features of the language (I am just talking simple pattern matching, map/flatmap/filter/unzip). So far, it's actually the most productive language we've used.
Our dig is the community and things peripheral from the core language: documentation is generally awful (Play, SBT). Dependencies management is awful (SBT doesn't work). Libraries are overly complex (Dispatch). And compile times suck.
I'm a pretty big Scala fan, but I think this post is spot on. A lot of the stuff that's fun is not terribly useful, and I see a lot of people in the Scala community going down that road. The most perfect codebase in the world doesn't mean much if it doesn't do anything.
This is why, despite feeling real weird about it, I'm writing my current personal project in Rails rather than Play. It's one case where worse-is-better kind of benefits me--it forces me to focus on my problem, rather than on all the cool bright-shiny-objects that are not my problem.
(There's also a discussion to be had about the Scala-should-be-Haskell crowd, who I think come from a good place but are led by some of the most overtly poisonous people I've ever had to deal with.)
As I said, they're not necessary and I don't think I've written useful code that explicitely used monads, for example - well, aside from for-comprehensions, but you could argue that it's not explicit.
But they are fun in that, once you start understanding what the fuss is all about, they open your brain to new ways of thinking, which is always good - instead of learning how to be really really good with a hammer, I like to know about screwdrivers as well, for the odd case where that nail is kind of screwy.
I do understand your point about an infinite amount of things to learn in a finite amount of time. What I personally do is focus my study of tedium (build tools, say) and domain-specific concepts for work-hours. These things are required for me to be good at my job, and it seems fair that I improve on them while doing that job.
The other, more theoretical (type theory, functional abstractions, fun data structures...) or less directly applicable (odd languages, new concepts such as reactive programming or actors...) subjects I study on my own time, when I have it, when and if I feel like it.
It means that, for example, it took me a solid year before I felt I had some degree of fluency in Scala, which was frustrating. On the plus side, I now have some degree of fluency in Scala.
Often the argument is that if languages are superheroes, Scala is trying to be one with all the possible superpowers. When you learn how to use them and have control over when to use them (and for good or bad), everything will be a breeze. But the assumption that everyone will spend time learning the right ways and not use in production before achieving zen is impractical.
If you compare Scala other recently released languages (swift, kotlin, ceylon) they're all kindof similar, some claim to be less complex but imho aren't. Functional + OO is becoming the norm: the C# team is considering to add pattern matching and it looks like java 10 may have some twisted form of type classes.
'Scala the language', is imho very nicely designed, the problems arise in the compiler implementation and the core libraries. Scala carries around too much dead weight in it's core libraries. Some poor choices were made while scala wasn't widely used yet and it's very hard to fix that now. If you look at the roadmap for scala it's obvious that they are trying to address these issues.
Clojure is much, much less complex then Scala and it is functional and OO. Many people see clojure as purly functional but clojure programmes are often designed in OO style as well.
OO here meaning polymorphism over types of your data 'object'. The diffrence is that you usally never mutate your object.
It is fair to say however that the emphasis of clojure is functional and your code is expected to be functional style, only when you really need it, you start adding polymorpism but even then protocolls are expected to be a implementation detail quite often. Also, we access our objects the same way we do our hashmaps and even the same function often work on both objects or hashmaps.
Some people might of course dislike this approche where OO is not really not used in the traditional way and is kind of pushed down. So clojure I would say, is techniclly multi-paradigm but culturally its not.
We've had dynamic OO+FP languages for a very long time but only in the last 10 years have we seen them with static type systems. I really like clojure (though I haven't used it in anger) but I think you're wrong when it comes to complexity.
Complexity with dynamic languages grows with the size of the project. I know that because of the focus on purity & immutable data structures clojure mananges to mitigate this problem but I'm afraid it's still there.
The last few years several features have been added to clojure that increased the complexity(/surface area) of the language and the documentation is often a mess. I'm not a clojure hater, just pointing out that the complexity with clojure lies elsewhere.
edit: kinda forgot about Ocaml (~18 yrs old apparently)
> Complexity with dynamic languages grows with the size of the project.
I was talking about language complexity, not how complex the project is.
That said, I have nothing against static typing, my argument was not really about typing at all. It was more about how OO and functional interact in clojure compared to java. Also types by itself dont really make all that good of a documentation, at least not the kind you care about when looking something up in the internet.
I am a fan of schema, and I think the future really is in the combination of schema and core.typed. I dont really like to devlop with pre set types and structures, but you could with schema/core.typed. I prefer to work dynamiclly and once im happy with the shape of my data, I 'set it in stone' by writing the correct schema for it. Then you can just always validate everything during devlopment/staticlly. When you deploy you can turn on validation only for data from the outside. This is how I would like to do it, until schema and core.typed work together I just use schema.
For the most part macros make most code much, much easier to read. The clojure compunity is also really fixed in its way, how and when macros are written.
Take one example, core.match. Now in a language that does not have pattern matching code that can be easly written with pattern matching is very hard to read. In clojure its very easy to read.
Now one might argue that a 'good' langauge should have support for pattern matching. To that I say, the language creators can never have all the features everybody wants, it will slow down devlopment of the language and increase complexity.
I would rather read one or two nice clojure macros that reduce tons of boilerplate as you would need in other languages. The same happens in other languages, for exmaple rust. I really enjoy using macros there as well. Give me a language with macros 100%, it improves read and write ability in the waste majority of cases.
If you really belive that core.typed makes clojure as verbose as Java then you have not looked at it. Also, its not like people use clojure over java because they dont have to write down types. There are tons of other reasons people use clojure.
Also, core.typed can do things that java can not.
> Yes, but it doesn't even have types!
While I understand what you mean, you should write down what you mean. Clojure has types, but not static typing.
... except Scala isn't confident enough to be an instrument. It has to be all of them it once. It's a trumpet with strings taught across the bell (which you can play with or without a bow), and drum skin draped over the leadpipe.
It's a construction set with many pieces which you can combine to make new instruments. Maybe you have a mouldable body which can be made to support one neck and several auxiliary strings... and then you have a harp guitar. Maybe add some tenor strings to that later.
"support one neck and several auxiliary strings..."
And then as you add more and more features suddenly a case class has 22 and the whole thing crashes down but nobody told you about the 22 airity limit because "the ivory tower says thats bad design and I don't care what the real world needs" and although redesign is simple enough, its kinda shocking. I wonder what other silent spinning propellers can be walked into without warning. Maybe none, maybe lots, but I don't look forward to the ensuing ivory tower tongue lashing because I dared to use it in the real world.
Languages shouldn't get in your way. Even if the real world IS doing it wrong, it should at least support you failing with some style and grace.
And as the powerpoint shows, that compiler is possibly the slowest compiler I've ever used for a given complexity of task. Really... my project was an internal use only super specialized vaguely crud app using play framework for weird engineering data, but nothing fundamentally shocking or unusual, and a full compile from clean source shouldn't take 7 minutes and 33 seconds. What is that like one second per line of source?
Those complaints said, everything worked and it was vaguely enjoyable and interesting although a boring CRUD app does not exactly scratch deeply into the language features. Was a fun experiment, probably wouldn't do it again.
You know quite well that the removal of this restriction is brand new and it would be very easy to encounter it in the wild.
Why do you go out of your way to use smarmy tactics to argue against anytime someone who has a legitimate complaint? It would be way more productive to acknowledge the weaknesses and then tell the good story of Scala.
There are valid complaints about Scala, but the complaints from all those HN armchair experts are far removed from it. There is nothing useful to be done except making fun of it.
Are you claiming that there wasn't an arity limit on case classes that you could run into through no fault of your own using the Scala web stack? Or just that if you had to diagnose that problem it shouldn't bother you as it isn't a valid complaint?
What would elevate someone from HN "armchair expert" in your mind, such that their complaints were valid? Is it even possible for someone to mention something they don't like about Scala without you immediately dismissing them as not knowing what they are talking about?
True, the IDEs are poor, for a certain definition of poor. Had I not used IntelliJ for Java, for example, I'd find IntelliJ for Scala amazing. Knowing how much better it can be spoiled me, but frankly, IntelliJ for Scala is not bad. It just could be better. Also, Emacs has a very robust Scala mode.
True, there's a lot to learn before you can consider yourself fully fluent. You do not need to know everything, however. And once you've started on the path, things tend to flow naturally. For example, implicit conversions are easy to grasp. Once you understand them, implicit parameters and type classes are not much more complicated. Once you know type classes, it opens the door to a lot of functional "design patterns" - functors, applicatives, monads... these are not strictly necessary, but they're fun to learn about. And they teach you algebraic data types, which in Scala means case classes, sealed traits, ... it all sort of flows naturally.
True, it's easy to write absolutely un-maintainable code. While that's true of any language, Scala makes it rather easier than most. It's also very easy to write highly maintainable, legible code, and to avoid complex, ascii art based operators (or at the very least to offer wordy equivalences at 0 cost through `@inline`). I feel that saying "it can be hard to read, if you don't follow basic guidelines" is a bad reason not to use a language. A good reason to be careful, though.
My personal experience is that, once you start feeling comfortable with the language, you get much more productive than with Java. It does require some initial work, though: if all you know is OO, learning how to design your code for composition rather than inheritance takes a while - it takes a while just to realise that it's not a bad idea, let alone embrace it!
Also, ScalaCheck. Man, do I wish there was a good Java equivalent for some of my legacy code (that would not require me to rewrite all of my tests).