
Scala Vs Clojure – Let's get down to business - fogus
http://blog.bestinclass.dk/index.php/2009/09/scala-vs-clojure-lets-get-down-to-business/
======
shrughes
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.

~~~
joe_the_user
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?

~~~
shrughes
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.

~~~
swannodette
> 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.

~~~
jrockway
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...)

------
jacquesm
python vs clojure (twice), scala vs clojure, can we stop posting this trash,
please ?

<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.

~~~
wicknicks
I agree!

------
Raphael_Amiard
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.

------
JoeAltmaier
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.

------
jister
another language comparison, again?

~~~
ulf
Actually this one is kind of refreshing: neutral. As well gives a little peek
into Scala for people who do not know it (like me)...

~~~
scott_s
I did not think it was neutral. While the code comparisons and one benchmark
come about similarly, his characterizations of Scala seem biased to me.

~~~
ConceptDog
Very biased. I've read some pro clojure stuff from the author before.

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.

------
joubert
The nice thing of course is that you could use BOTH languages in the same code
base with full interaction between them.

------
10ren
No mention of libraries (yes, they both can use Java's libraries, but some
native ones would be useful).

And therefore, no mention of the document of said libraries (which I'm now
convinced is crucial).

------
ilyak
"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."

Trolololo.

