views:

885

answers:

7

What are the most commonly held misconceptions about the Scala language, and what counter-examples exist to these?

UPDATE

I was thinking more about various claims I've seen, such as "Scala is dynamically typed" and "Scala is a scripting language".

I accept that "Scala is [Simple/Complex]" might be considered a myth, but it's also a viewpoint that's very dependent on context. Not only that, but it has a certain tendency to inflame arguments, and I've not yet seen anyone change a strongly-held viewpoint on the topic...

+13  A: 

I think a common misconception amongst many scala developers, those at EPFL (and yourself, Kevin) is that "scala is a simple language". The argument usually goes something like this:

  • scala has few keywords
  • scala reuses the same few constructs (e.g. PartialFunction syntax is used as the body of a catch block)
  • scala has a few simple rules which allow you to create library code (which may appear as if the language has special keywords/constructs). I'm thinking here of implicits; methods containing colons; allowed identifier symbols; the equivalence of X(a, b) and a X b with extractors. And so on
  • scala's declaration-site variance means that the type system just gets out of your way. No more wildcards and ? super T

My personal opinion is that this argument is completely and utterly bogus. Scala's type system taken together with implicits allows one to write frankly impenetrable code for the average developer. Any suggestion otherwise is just preposterous, regardless of what the above "metrics" might lead you to think. (Note here that those who I've seen scoffing at the non-complexity of Java on Twitter and elsewhere happen to be uber-clever types who, it sometimes seems, had a grasp of monads, functors and arrows before they were out of short pants).

The obvious arguments against this are (of course):

  1. you don't have to write code like this
  2. you don't have to pander to the average developer

Of these, it seems to me that only #2 is valid. Whether or not you write code quite as complex as scalaz, I think it's just silly to use the language (and continue to use it) with no real understanding of the type system. How else can one get the best out of the language?

oxbow_lakes
I think I'd phrase my own belief as "scala doesn't have to be complex", rather than "scala is simple". Given the Turing-complete potential for obfuscation, any language can be made complicated if you so choose. Scala has a lot of potential for KISS design without a heavy burden of boilerplate, and that's no bad thing!
Kevin Wright
Is there a language which doesn't even allow one to write impenetrable code?
Ken
How about whitespace?
Kevin Wright
And brain**** of course? @Kevin - I think you'd want to hire a scala developer who was able to understand complicated code gymnastics for 2 reasons: firstly that they may come across this sort of code. Secondly; they may have cause to use it to solve a problem in an optimal way.
oxbow_lakes
"the equivalence of X(a, b) and a X b"? Nope, the equivalence is a.X(b) and a X b.
Landei
The argument based on keywords and such is at least more substantive than "look at this example of obfuscated code."
MJP
@Landei - I suggest you go and read the language spec before being so dismissive. How do you think you can pattern match on `x :: xs`? It is because, for an extractor, this is equivalent to matching on `::(x, xs)`
oxbow_lakes
@MJP - the point is that scalaz is not *intentionally* obfuscated. Neither is the new collections library, but they are still complicated to understand
oxbow_lakes
This sounds lots like what's the major issue with C++. It's possible to keep C++ code understandable, yes. In practice it requires limiting which language features are used in a particular project/organization, because otherwise other developers will write code that you don't understand and vice versa. Unfortunately this also prevents getting the best out of the language in the real world. I have not yet seen a *too simple* language. Too complicated, many of them...
Joonas Pulakka
@oxbow_lakes: Normally `x :: xs` is evaluated as `xs.::(x)`, which is essentially the same as I specified (just with the special colon-rule for reversing the arguments). Of course you are right concerning extractors and I didn't thought about that, but you have to admit that method calls are much more common, that new users often trip about that, and that you usually use the 'symmetric' extractor syntax for special chars and not for letters.
Landei
@Landei - *sighs*. You are wrong. Try it, or just look at this answer from Daniel: http://stackoverflow.com/questions/1059145/how-is-this-case-class-match-pattern-working/1059161#1059161
oxbow_lakes
scala> case class X(i : Int, s : String)
oxbow_lakes
scala> X(4, "Hello")
oxbow_lakes
scala> val j X t = res0
oxbow_lakes
@oxbow_lakes: Did you actually **read** my answer? I already said you were right concerning extractors and pattern matching, just from the way you wrote it wasn't very obvious what you meant (at least not to me). But there **are** two methods defined in List: `def :: (x: A): List[A]` and `def ::[B >: A](x: B): List[B]`, and they are the normal "use case" (when you are not pattern matching), and work as I stated, so I suggest you go and read the ScalaDocs before being so self-confident.
Landei
@Landei - indeed; I should have read the full comment. Apologies
oxbow_lakes
@oxbow_lakes: And I admit that my initial comment was too flippant, sorry for that.
Landei
From my experience, in informatics, many times you have no option than to learn "by need" or "by demand". Given the examples I have seen about scalaz I haven't had any need (or motivation) to learn it...
german1981
@german1981 - I'm not necessarily saying that you need to learn scalaz. But you might (for example) want to understand a bit more about how to get round scala's lack of partially applied type constructors. Or perhaps just a sounder grounding in FP. You should certainly understand about typeclasses (in my opinion).
oxbow_lakes
+10  A: 

Some common misconceptions related to Actors library:

  • Actors handle incoming messages in a parallel, in multiple threads / against a thread pool (in fact, handling messages in multiple threads is contrary to the actors concept and may lead to racing conditions - all messages are sequentially handled in one thread (thread-based actors use one thread both for mailbox processing and execution; event-based actors may share one VM thread for execution, using multi-threaded executor to schedule mailbox processing))
  • Uncaught exceptions don't change actor's behavior/state (in fact, all uncaught exceptions terminate the actor)
Vasil Remeniuk
Could you be more specific about the first point? Does "actor is represented with one thread" mean:1) it is always run by one and the same worker thread2) it is run by one thread at a time, but the same actor may at different points be run on different threads (i.e. after blocking, it may later be run on some other thread)Note that this has an impact on certain things - for instance, can you safely use ThreadLocals with actors?
axel22
In a basic configuration, Scala actor is backed with ThreadPoolExecutor (ExecutorScheduler). It's ensured that suspended actor will be resumed on the same thread. When actor is backed with SingleThreadScheduler, all actor tasks are executed on the same single thread.
Vasil Remeniuk
Nice. I didn't know its ensured they get executed on the same worker thread. Thanks!
axel22
+15  A: 

I disagree with the argument that Scala is hard because you can use very advanced features to do hard stuff with it. The scalability of Scala means that you can write DSL abstractions and high-level APIs in Scala itself that otherwise would need a language extension. So to be fair you need to compare Scala libraries to other languages compilers. People don't say that C# is hard because (I assume, don't have first hand knowledge on this) the C# compiler is pretty impenetrable. For Scala it's all out in the open. But we need to get to a point where we make clear that most people don't need to write code on this level, nor should they do it.

Martin Odersky
One of things I'm enjoying most about learning Scala (and gradually infecting my Java codebase with it) is that while at one level it can be very clean and straightforward and even pleasurable to code in, there are so many other powerful levels to explore. Some of those latter features are still beyond me, but that just means I have things to learn, which is cool! And if that power results in the occasional bullet hole in my shoe, well, Scala restricts me to a six-shooter, unlike, say, the Uzi that Perl provides. ;-)
Rodney Gitzel
I can't help but agree. If a tool is complicated because it allows you to make complex things, then you'd also have to include both minecraft and lego under such a definition. This feels very counter-intuitive to me.
Kevin Wright
There this very nice post by Martin him self: http://lamp.epfl.ch/~odersky/blogs/isscalacomplex.html
pedrofurla
+15  A: 

Myth: That Scala's Option type won't save you from nulls. :-)

Debunked here by James Iry.

missingfaktor
Scala option types do save you from null. You can think of an option type as a null pointer you have to "null check" to derefer. Since it's impossible to use an "Option[a]" like an "a", Option types will make sure that null pointer exceptions never occur. Iry's article is basically missing that point.
voxcogitatio
Nevermind. Shows my reading comprehension eh? :)
voxcogitatio
That's only partly true I think. The reference to the Option itself can be null, as well as the value in it (it can be Some(null)). There's nothing that prevents that.
Arjan Blokzijl
Perhaps Option should extend the NotNull trait?
MJP
With the disclaimer that Option only helps if it's actually used. You can still get nulls in Scala, especially where Java interop is involved.
Kevin Wright
Isn't `Null` is a subtype of all `AnyRef` types? Doesn't that mean that any reference can be null?
Gabe
@Gabe: Yes, they can. Read the Postscript in James Iry's above-linked article for clarification on this.
missingfaktor
missingfaktor: So he's saying that even though nulls are possible, in practice they're rarely a problem? I think the myth is still correct. While idiomatic Scala uses `Option` types to avoid nulls, you stil have to worry about them when interacting with any Java code.
Gabe
@Gabe: Agreed, but that doesn't validate the statement "Scala's `Option` type won't save you from nulls". It certainly will, provided you use it.
missingfaktor
+11  A: 

There is a myth that Scala is difficult because Scala is a complex language.

This is false--by a variety of metrics, Scala is no more complex than Java. (Size of grammar, lines of code or number of classes or number of methods in the standard API, etc..)

But it is undeniably the case that Scala code can be ferociously difficult to understand. How can this be, if Scala is not a complex language?

The answer is that Scala is a powerful language. Unlike Java, which has many special constructs (like enums) that accomplish one particular thing--and requires you to learn specialized syntax that applies just to that one thing, Scala has a variety of very general constructs. By mixing and matching these constructs, one can express very complex ideas with very little code. And, unsurprisingly, if someone comes along who has not had the same complex idea and tries to figure out what you're doing with this very compact code, they may find it daunting--more daunting, even, than if they saw a couple of pages of code to do the same thing, since then at least they'd realize how much conceptual stuff there was to understand!

There is also an issue of whether things are more complex than they really need to be. For example, some of the type gymnastics present in the collections library make the collections a joy to use but perplexing to implement or extend. The goals here are not particularly complicated (e.g. subclasses should return their own types), but the methods required (higher-kinded types, implicit builders, etc.) are complex. (So complex, in fact, that Java just gives up and doesn't try, rather than doing it "properly" as in Scala. Also, in principle, there is hope that this will improve in the future, since the method can evolve to more closely match the goal.) In other cases, the goals are complex; list.filter(_<5).sorted.grouped(10).flatMap(_.tail.headOption) is a bit of a mess, but if you really want to take all numbers less than 5, and then take every 2nd number out of 10 in the remaining list, well, that's just a somewhat complicated idea, and the code pretty much says what it does if you know the basic collections operations.

Summary: Scala is not complex, but it allows you to compactly express complex ideas. Compact expression of complex ideas can be daunting.


There is a myth that Scala is non-deployable, whereas a wide range of third-party Java libraries can be deployed without a second thought.

To the extent that this myth exists, I suspect it exists among people who are not accustomed to separating a virtual machine and API from a language and compiler. If java == javac == Java API in your mind, you might get a little nervous if someone suggests using scalac instead of javac, because you see how nicely your JVM runs.

Scala ends up as JVM bytecode, plus its own custom library. There's no reason to be any more worried about deploying Scala on a small scale or as part of some other large project as there is in deploying any other library that may or may not stay compatible with whichever JVM you prefer. Granted, the Scala development team is not backed by quite as much force as the Google collections, or Apache Commons, but its got at least as much weight behind it as things like the Java Advanced Imaging project.

Rex Kerr
+5  A: 

Myth: Scala supports operator overloading.

Actually, Scala just has very flexible method naming rules and infix syntax for method invocation, with special rules for determining method precedence when the infix syntax is used with 'operators'. This subtle distinction has critical implications for the utility and potential for abuse of this language feature compared to true operator overloading (a la C++), as explained more thoroughly in James Iry's answer to this question.

Aaron Novstrup
This one gets my vote for answering the question. Mostly because it's the sort of answer I was looking for. A widespread myth that's absolutely and objectively false, and one which leads to a misunderstanding of the language and its complexity. But it's a community wiki, so keep 'em coming!
Kevin Wright
@Kevin: You mean others (including myself) didn't answer the question?!
missingfaktor
@missingfactor: sure you did, but SO was nagging me to accept just one answer... This one seemed to best represent the kind of well-intentioned-but-ultimately-misinformed statements about Scala that I was seeking with my question.
Kevin Wright
@Cevin: Fair enough.
missingfaktor
+4  A: 

Myth: Pattern matching doesn't fit well with the OO paradigm.

Debunked here by Martin Odersky himself. (Also see this paper - Matching Objects with Patterns - by Odersky et al.)

missingfaktor