Like the author, I've been using Scala more and more as of late (mostly after finding it to be a viable alternative to Java on Android). Perhaps the biggest thing that I've had to get over is the "feature freedom" of the language after being walled in by Java on Android. I know I'm not too far off in saying it, but it's like Martin Odersky created it in direct response to the nanny-like restrictiveness that Java has, but perhaps went too far in some areas (as the article describes a bit). He did write the current java compiler, so he's well familiar with how Java is. I just sometimes get the feeling someone pressed accept to every feature enhancement to the language at some point as just about any feature you can think of in a modern language has found its way into Scala. Generally, I find that to be a good thing, but I can see how it would be off-putting to some and makes Scala somewhat of a controversial language for both imperative and functional language advocates.
If one is not careful and adhering to a formal style guide, it would easy to end up with an unreadable mess of inconsistent code. Anyone with some grounding in programming already at a professional level shouldn't have a problem, but someone that's relatively new to development might want to look into another language. For example, all of these are valid ways to create a class with some parameters/properties:
After having to use Java on Android for the past three years, such freedom is both liberating and shocking at the same time. I use C#, JavaScript and Python pretty frequent as well, but it's just I'd say Scala is even more liberal than any of those feature wise. It's more like Perl (not quite, but close), but not quite in the area of a Lisp variant. Scala is definitely written from the viewpoint of the developer and not the intended users though. It's also nice to have access to features that are standard in languages like Python, Ruby, C# and functional languages. Seeing 13 lines of Java become 1 line of Scala[1] is a great feeling.
I'd say if you have experience with Java, C#, Python, Ruby or any functional language you'll pick up on Scala pretty quick. If Java is your only language experience, it might be a bit rough at first, because of the expressiveness and freedom of the language, but don't let it detour you. If needed, you can mostly stick to the imperative side of Scala and slowly work in more functional features as well as some of the useful syntactical sugar stuff (like operator overloading) that Scala provides.
> If needed, you can mostly stick to the imperative side of Scala and slowly work in more functional features as well as some of the useful syntactical sugar stuff (like operator overloading) that Scala provides
I'd say that's a bad idea.
People keep saying that Scala is not an opinionated language and that you have to make choices and stuff. That's not true and in fact, Scala is a very opinionated language that makes imperative code painful. That's why some beginners get so frustrated when they pick it up. Because they come with certain wrong assumptions about how features in Scala work.
Examples: Scala does not have "break" or "continue", while "return" does not behave as many people think it behaves. The "yield" keyword in "for" expressions is also totally different than the "yield" in C# or Python or Ruby. Actually "for" expressions in themselves are actually monad comprehensions - powerful, elegant, but definitely not your grandma's foreach. Also, collections are immutable by default.
You have a point in that the features may not be one to one equivalents, though that's generally the case when using any new language to a point. Even Java to C# vary a bit for their overlapping keywords/features. Yield might return a collection in Scala instead of an iterator like in Python, but that's not a huge knowledge leap to wrap one's head around.
Are collections immutable by default in Scala? I thought each each was treated as a separate, but equal package (scala.collection.mutable and scala.collection.immutable) and collections within scala.collection itself can be either mutable or immutable since they're super-classes to both subpackages. The difference between the super-package collections and the subpackage collections.immutable being that collections.immutable was guaranteed to be immutable.
I've kind of avoided "yield" so far and opted for the functional equivalents. Something like
val result: Array[Int] = for (elem ← n if n % 2 == 0) yield 5 * elem
just looks more readable as:
val result = n.filter(_ % 2 == 0).map(5 * _)
or in more functional syntax:
val result = n filter { _ % 2 == 0 } map { 5 * _ }
I don't think imperative code is necessarily painful in Scala, it's just constructed a bit differently. On the other side of the paradigm, functional language advocates seem to say functional programming in it is also painful[1]. Just seems Scala cannot 100% please everyone 100% of the time.
Btw, regarding for-comprehensions and Futures, there's a new project that's going to make things interesting for working with Futures: https://github.com/scala/async
> On the other side of the paradigm, functional language advocates seem to say functional programming in it is also painful[1]
Worth pointing out that the people advocating for a better language in that thread, including the one that started it, have problems with Haskell too (currently the poster child for functional programming). It is the reason why many of them are using Scala, whether they like to admit it or not. In that thread it is even argued that lambda-calculus itself is outdated because it is inherently sequential.
Scala attracted many idealists that aren't pleased with any mainstream language. On one hand it is good, because it moves the language forward. By comparison the Go community is kind of toxic. On the other hand, people that don't get the context of that discussion jump to conclusions.
After going back and rereading some of the posts, I agree without you about it having a group of angry programmers that aren't happy no matter what they get.
That project looks interesting though. Looks like it's almost based on the new async abilities in C# 5.0[1]. Have you tried it any yet in Scala?
> Actually "for" expressions in themselves are actually monad comprehensions - powerful, elegant, but definitely not your grandma's foreach. Also, collections are immutable by default.
This definitely threw me for a loop when I started using Scala. I banged my head against the keyboard a few times trying to get for comprehensions to do what I thought they should do.
Once I began to fully understand the relationship between for comprehensions and monadic operations, especially on Futures and Options, I began to understand their power.
> I just sometimes get the feeling someone pressed accept to every feature enhancement to the language at some point as just about any feature you can think of in a modern language has found its way into Scala.
That was also my impression. Clojure is sometimes painfully restrictive (I need forward declarations for functions if I use them before they are defined? In a compiled language in 2013? Really?), but at least it is curated.
With all due respect, this impression is just folklore.
The difference between Scala and Clojure is the difference between ML and Lisp. Languages from the ML family are statically typed by definition, therefore they need slightly more features to be expressive. On the other hand, the trade-off is worth it for many people, because the compiler actually helps you - for example it's far easier to work with various functors (such as monads) in ML languages, than it is to do that in Lisp.
Also, Clojure is not "painfully restrictive" or "curated". Name one thing that Clojure doesn't allow you to do.
Clojure has always intrigued me, but I've stuck with Scala so far so I don't scare any of the more Java inclined developers I work with when they read my code.
I keep thinking with Scala though, I'm going to run into some really awful looking code one day from someone overly abusing all of its features. I know know even the most restrictive languages can be abused, but it just feels like Scala leaves the window much more open for that.
I'd be interested in hearing more about what you find restrictive besides forward declarations, which I've never found to be a big deal. As a side note, there was a pretty interesting discussion on HN between Steve Yegge and Rich Hickey about that: https://news.ycombinator.com/item?id=2467359
I mostly follow the official one on Scala. I deviate from it a little to help me stay sane when switching between languages like 4 spaces tabbing and sticking to K&R style[1] for indentation/braces. Using an IDE like Intellij or Eclipse can also help reinforce consistency as well since you can set the way it formats for you (and also have it auto-format before you commit to git).
Most important thing is to just stay consistent with whatever you decide upon more than which formal style you choose. If I were working in a team with Scala, then I would stick with a formal spec (or just let the IDE auto-format for me to adhere to the team's style when committing).
> If one is not careful and adhering to a formal style guide, it would easy to end up with an unreadable mess of inconsistent code.
This reminds me a lot of C++: powerful but unless you agree on a consistent style and only using a subset of its functionalities, you end up with nightmare code bases.
If one is not careful and adhering to a formal style guide, it would easy to end up with an unreadable mess of inconsistent code. Anyone with some grounding in programming already at a professional level shouldn't have a problem, but someone that's relatively new to development might want to look into another language. For example, all of these are valid ways to create a class with some parameters/properties:
https://gist.github.com/yareally/5811498
After having to use Java on Android for the past three years, such freedom is both liberating and shocking at the same time. I use C#, JavaScript and Python pretty frequent as well, but it's just I'd say Scala is even more liberal than any of those feature wise. It's more like Perl (not quite, but close), but not quite in the area of a Lisp variant. Scala is definitely written from the viewpoint of the developer and not the intended users though. It's also nice to have access to features that are standard in languages like Python, Ruby, C# and functional languages. Seeing 13 lines of Java become 1 line of Scala[1] is a great feeling.
I'd say if you have experience with Java, C#, Python, Ruby or any functional language you'll pick up on Scala pretty quick. If Java is your only language experience, it might be a bit rough at first, because of the expressiveness and freedom of the language, but don't let it detour you. If needed, you can mostly stick to the imperative side of Scala and slowly work in more functional features as well as some of the useful syntactical sugar stuff (like operator overloading) that Scala provides.
[1] https://gist.github.com/yareally/5810767