Scala Vs Clojure – Let's get down to business
blog.bestinclass.dk
blog.bestinclass.dk
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.
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?
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.
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.
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...)
Another example of "Argument by Snark."
http://news.ycombinator.com/item?id=890697
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.
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.
I can't understand the point in spending time slagging off another open source project that simply has a different point of view.
They're all tools built to solve a problem. Maybe you can't find a use for a 5 headed hammer, but the person who created it found one.
And therefore, no mention of the document of said libraries (which I'm now convinced is crucial).
Trolololo.