This is an entirely superficial comparison. There is none of "this is how the language affects how you design your software" and there is plenty of "oh, here's a quicksort, big and scary. And looking at the table at the top: "object oriented", "statically typed." Is that all the author has to say? You could substitute C# in place of Scala and get the same point-by-point comparison.
What the author completely misses is Scala's entire type system. The evil genius monster of a type system. I can't think of any reason why I'd want to use Scala other than the type system -- oh, sure, anonymous functions -- and the fact that not a word is said about traits or type constructors as type parameters or existential types or things that use the word "implicit" is depressing. Scala is not so much object oriented as it is the best strictly evaluated form of Haskell that lives comfortably in the Java ecosystem, that, hey, happens to have classes and traits.
And I think it fails to do justice to the good parts of Clojure, too.
Also, the benchmark, computing factorial(5000), is nonsense, since it's really measuring the performance of the BigInt implementation.
Also, not surprisingly, the one demonstration of the power of macros is the typical body-wrapping kind that might as well be a higher order function.
I don't think he misses the type system but rather argues that it isn't useful. You may disagree but that's a different matter.
Also, I don't know much about Haskell but isn't any "pure" functional language based on immutability and doesn't Java/scala OO essentially assume mutability as per the article?
He doesn't actually argue that the type system isn't useful. He assumes it derisively. You can take the entire review and replace Scala with C#. What does that tell you?
Scala encourages immutability. See case classes, for example. Or if ( ) ... else ... expressions. Stuff is designed to return values rather than be actions that set values. Even try ... catch ... finally blocks are expressions that return values. Being OO has nothing to do with mutability/immutability.
> Being OO has nothing to do with mutability/immutability
It does if you are using OO to represent state - which most OO programmers do. For things like UI stateful code is often the simpler solution. However for large, large swaths of a program using stateful objects is a complexity bog.
The real question here is whether programmers will bring their stateful OO habits and recreate them in Scala.
When I was first learning Clojure I started by creating an object system. And then I realized I was entirely missing the point as well as going against the grain of the language- functional programming is palpable in Clojure's design.
If an object maintains state you can't generally view it as an immutable value- that's another benefit to Clojure's approach. You generally design your program around the idea value -> function -> new value (_not_ same object with a different internal state). The transparency of this is quite enlightening.
In anycase, I don't know enough about Scala to make an informed opinion, but whether Scala's decision to meet OO programming sensibilities halfway is a liability remains to be seen.
I do OOP extensively, and I rarely allow methods to mutate the object. Whenever I have an "is => 'rw'" declaration in my code, it is always immediately followed by a comment along the lines of "XXX: hack". I always feel bad, because it is rarely the right solution.
Even when my data structures are completely immutable, I don't consider myself to be doing "functional programming". I consider it "avoiding stupid bugs".
(As an aside, when using an object database, I am a bit more liberal. You shouldn't need to rewrite every object in the system when a user changes his password, after all. This does come at a cost, though; there is no way to "go back in time" and find an old object graph. There is the current one, and that's it; hope you didn't mess it up...)
This guy doesn't have the first inkling of how to benchmark something and he doesn't know how to make a non-fanboy comparison between two sets of anything, especially if one of the anythings is clojure.
I'm sure clojure is a great language but this is not the way to do it.
From a guy that lately programs only in clojure for my own projects : Could you please stop upvoting lau articles. They are troll bait down to every sentences.
I mean the guy made a point by saying Static typing is good for people who can't remember the order of function arguments. Isn't it enough to understand ?
This article is a joke. The guy has a bias so obvious the eifel tower is small in comparison.
Not a comparison of languages; a comparison of language concepts using Scala and Clojure. And language concepts are subjective - use case, user world-view. We learn more about the author than either language.
This is not neutral, the guy works exclusively in Clojure as freelancer, so it is fair to assume he is sort of biased.. as others mentioned here before he misses some important aspects which Scala has to offer.
He misses important aspects of clojure (based on some of the comments on his site) and Python as well. In short, he should probably not be getting exposure this wide with these troll articles.
"One guy asked me 'Havent you ever passed arguments in the wrong order and expected a different return than what you got ?" and I'll be honest: No, I haven't. But for people who have a hard time getting arguments order and return types right, this system is a great help. So it has it's place, I must say."
What the author completely misses is Scala's entire type system. The evil genius monster of a type system. I can't think of any reason why I'd want to use Scala other than the type system -- oh, sure, anonymous functions -- and the fact that not a word is said about traits or type constructors as type parameters or existential types or things that use the word "implicit" is depressing. Scala is not so much object oriented as it is the best strictly evaluated form of Haskell that lives comfortably in the Java ecosystem, that, hey, happens to have classes and traits.
And I think it fails to do justice to the good parts of Clojure, too.
Also, the benchmark, computing factorial(5000), is nonsense, since it's really measuring the performance of the BigInt implementation.
Also, not surprisingly, the one demonstration of the power of macros is the typical body-wrapping kind that might as well be a higher order function.