May
2008
I’ve been turning that question over in my head for a few months now. It’s really a worthy thought. At face value, it’s incredibly derogatory and implicative of an over-bulked, poorly designed language. While I’m sure this is not how the concept was originally intended, it certainly comes across that way.
But the more I think about it, the more I realize that the parallels are uncanny. Consider the situation back in 1983, when C++ first got started. C had become the dominant language for serious developments. It was fast, commonly known and perhaps more importantly, structured. C had successfully applied the concepts shown in Pascal to systems programming, revolutionizing the industry and becoming the lingua franca of developers everywhere.
When C++ arrived, one of its main selling points was as a “better C”. It was possible to interoperate seamlessly between C++ and C, even to the point of compiling most C programs unmodified in C++. But despite its roots, it still managed to introduce a number of features drawn from Smalltalk et al. (such as classes and virtual member functions). It represented a paradigm shift in the way developers represented concepts. In fact, I think it’s safe to say that the popular object-oriented design principles that we all take for granted would never have evolved to this level without the introduction of C++. (yes, I’m aware of Objective-C and other such efforts, but C++ was the one which caught on)
So we’ve got a few catch-phrases here: “better C”, “seamless interop”, “backwards compatibility”, “paradigm shift”, etc. Sound familiar? (actually, it sounds a lot like Groovy) The truth is that Scala seems to occupy a very similar place in history (if six months ago can be considered “history”). Scala is almost an extension to Java. It brings to the language things like higher-order functions, type inference and a type system of frightening power. Scala represents a fundamental shift in the concepts and designs we use to model problems. I truly believe that whatever language we’re using in a decade’s time, it will borrow heavily from the concepts introduced in Scala (in the same way that Java borrowed from C++).
But if Scala and C++ are so similar in historical inception, shouldn’t we view the language with a certain amount of distrust? We all know what a mess C++ turned out to be, why should Scala be any different? I believe the answer has to do with Scala’s fundamental design principles. Specifically, Scala is not trying to be source-compatible with Java. You can’t just take Java sources and compile them with Scala.
This clean break with the progenitor language has a number of ramifications. Most importantly, Scala is able to smooth many of the rough edges in Java without breaking existing libraries. For example, Scala’s generics are far more consistent than Java’s, despite still being implemented using erasure. This snippet, for example, fails to compile:
def doSomething(ls:List) = { ... } |
All we have done is omit the generic type parameter. In Java, the equivalent would lead to a compiler warning at worst, because Java has to remain backwards compatible with code written before the introduction of generics. This “error vs warning” distinction seems a bit trivial at first, but the distinction has massive implications throughout the rest of the type system. Anyone who has ever tried to write a “generified” library in Java will know what I mean.
Scala represents a clean break from Java. This is in sharp contrast to C++, which was trying to remain fully backward compatible with C sources. This meant inheriting all of C’s weird wrinkles (pass-by-value, no forward referencing, etc). If C++ had just abandoned it’s C legacy, it would have been a much nicer language. Arguably, a language more like Java. 
Perhaps the most important distinction between Scala and C++ is that Scala is being designed from the ground up with consistency in mind. All of the major problems in C++ can be traced back to inconsistencies in syntax, semantics or both. That’s not to say that the designers of C++ didn’t put a good deal of effort into keeping the language homogenous, but the truth is that they ultimately failed. Now we could argue until the cows come home about why they failed, but whatever the reasons, it’s done and it has given C++ a very bad reputation. Scala on the other hand is being built by a close-knit team of academics who have spent a lifetime thinking about how to properly design a language. I tend to think that they have a better chance of succeeding than the C++ folks did.
So the moral of this long and rambling post is that you shouldn’t be wary of the Scala language. It’s not going to become the next evil emperor of the language world. Far from it, Scala may just represent the next step forward into true programmatic enlightenment.
Comments
Hm, … I do not think Scala will be the next C++. Following youre argumentation, one could argue that Groovy will be the next C++. Scala could perhaps be Objectiv-C then (- as far as I know it): Much better, butter not used widly.
Groovy introduces the concepts of dynamic languages to Java and trys to have a certain code compatibility. And I think you should a view Groovy “with a certain amount of distrust” - as you said.
I didn’t bring it up in the article, but I happen to agree with you. This is the main reason why I’m leery about Groovy. It really does remind me more of C++ than Scala does, especially when you consider the whole “backwards source compatibility” thing.
Hi, while your comments are interesting, I don’t think your arguments are terribly well thought out or backed up with any sorts of evidence. I for one, think C++ is a very successful language and use it successfully for a number of different projects. I’m not saying that Scala couldn’t become a language that is more successful than C++ (that may be difficult), however statements such as “Now we could argue until the cows come home about why they failed, but whatever the reasons, it’s done and it has given C++ a very bad reputation” are very subjective and opinionated - it doesn’t give me much confidence in the argument you are trying to put forward… maybe if you provided more empirical evidence for example, to back up your claims… Interesting comments, but it just feels like a load of bs to me ^_^ sorry - don’t take this negatively.
> but it just feels like a load of bs to me ^_^ sorry - don’t take this negatively.
Yeah, pretty much. For whatever reason, I wasn’t able to structure my thoughts too constructively when I wrote this. I still hold to the conclusion, but I should have provided some more useful samples to back up my claims. Since I didn’t, feel free to call “FUD”.
b.t.w Scala does look like a nice language… I haven’t used it though.
Maybe Groovy is for Java and Scala what Java is for C and C++. One level up from the original but keeping its main idea and avoiding the pitfalls of the sophisticated parent.
I wish there was a new language that is both powerful and easy to learn without learning its predecessors. I mean by this Java 5 without learning Java 1.4, C++ without learning C, Groovy and Scala without learning Java.
Well, I learned Ruby without learning Perl. I would also argue that you could learn Scala without learning Java, but I can’t speak to that personally. Groovy is obviously quite dependent on its Java underpinnings.
I am a lot more optimistic about Groovy (but I am one of those involved in its evolution). Groovy mostly provides Java compatible syntax (but does make a clean break in some places). It also can be argued that Groovy allows a Java programmer to make a clean break from Java’s static typing if they so choose. I have nothing bad to say about Scala as it has many nice features and is very well designed but I do think Groovy packages up powerful features on the whole in a more accessible form to everyday programmers than Scala does. I am optimistic that both will be around for the long haul and both have a great role to play in the JVM’s evolution.
@Paul: My personal opinion about groovy is, that it is not really “clean”. That is why I think it is more like C++ then Scala. Scala is much much cleaner. It has some features it do not like much. But it is a very clean language in contrast to Groovy. :-\
daniel, i really like your blog content. however, i think your article is poorly titled. there is a bit of a “scala is complex” meme and your title does not help. many folks only skim titles, and you may be unintentionally reinforcing this fallacy.
would like to see more scala examples on:
1. clean break - the language stands on its own and java-like is just an illusion (a great examples of this are the for comprehension, and that everything is an object…)
2. the language is orthogonal - any feeling of complexity in the language is there for a reason (amazing type system, or the ability to extend the language with constructs that look and feel like keywords or DSLs).
3. how simple it is to express things in scala via direct comparisons with ruby and java (you’ve done a bit of this in the past).
keep up the great work.
“So the moral of this long and rambling post is that you shouldn’t be wary of the Scala language. It’s not going to become the next evil emperor of the language world. Far from it, Scala may just represent the next step forward into true programmatic enlightenment.”
I disagree. Scala has consistency, purity in some things (operators being named function calls), but an overwhelming number of language constructs on the other hand. The type system is difficult and unintuitive. For example, in the compiler phases, one actually imports various classes (i.e. types) by referencing bound variables, essentially forcing long classes with many bound inner classes — even if these inner classes have pretty unrelated functionality.
One point where Scala does worse than C++ is by hiding potentially expensive processing. The -optimise setting breaks certain files, and the regular settings seem to be even too sugared for Java IcedTea to properly optimize.
The other unfortunate thing is class file compatibility. Things may be pretty on the surface, but having classes “Function0″ through “Function22″, and type-erased function signatures clearly demonstrates how they’re trying to hook into the class file format.
Regarding the concise syntax, I do very much like the match statement, but I think Python demonstrated how to achieve a lot of elegance with a very simple language, and some of these thoughts ($self$ as a parameter, being able to have classes deriving from str) were lost. Of course, some things are not feasible in a statically typed language.
Finally, I think they really messed up trying to support UAP. **The meaning of an expression can change based on what type it’s assigned to**, which they needed to do in order to support actually grabbing function objects, when the function had no parameters. C# did it better, and came out earlier.
However, as I don’t completely hate C++, I see Scala as a potentially useful / practical language. It fills a niche where one needs expressive statically-typed languages, and I hope it can evolve further.
in the second paragraph I think I was wrong; I think there might be a workaround for this — declaring a variable of a certain type, setting it to null, and importing classes bound to it.
with regards to UAP, there’s more confusion though. For example, let’s say I get an array using a function:
classOf[scala.collection.mutable.HashSet[_]].getDeclaredMethods
Then I want to index into the array. The logical way to do it is
classOf[scala.collection.mutable.HashSet[_]].getDeclaredMethods(0)
but, since it was actually a function, this produces an error; the correct code is
classOf[scala.collection.mutable.HashSet[_]].getDeclaredMethods()(0)
This is an inconsistency iirc. c# properties do not have.
Perhaps, Scala getter would better be denoted like name_? similar to setters’ name_=
Or just “if compiler cannot tell getter from property - assume property” rule of thumb ?
Or maybe Scala 2.8 arrays reworking will add for it.
where same term might be both value and function call, that is aways prone to ambiguity.
i like C approach there, that made parenthesis mandatory and eliminated ambiguity.
in contrast, in TurboPascal (pointers were untyped), function XXX():pointer lead to ambiguity on assignment : var x: function:pointer; x := XXX; - is it address of function or its result?
even such strict andd anti-ambiguious language as Pascal fallen to ambiguity there
Hi Dan:
How do you feel about Scala now ? Features, Libraries and Performance ?
It’s almost getting close to 2 yrs since you wrote this blog.
thanks
Saifi Khan.
Post a Comment