5 ms·

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

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 17y ago
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 17y ago
  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 17y ago
    > 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 17y ago
      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...)
  - stcredzero 17y ago
    He doesn't actually argue that the type system isn't useful. He assumes it derisively. Another example of "Argument by Snark."

joe_the_user 17y ago

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 17y ago
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 17y ago
  > 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 17y ago
    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...)
- stcredzero 17y ago
  He doesn't actually argue that the type system isn't useful. He assumes it derisively. Another example of "Argument by Snark."