5 ms·

Sleeping Barber: Clojure x Scala

39 points by DanielRibeiro 16y ago

rbanffy 16y ago
For whoever misses part 1: http://www.bestinclass.dk/index.clj/2009/09/scala-vs-clojure-lets-get-down-to-business.html http://www.bestinclass.dk/index.clj/2009/09/scala-vs-clojure...
grimlck 16y ago
for (i <_- style="color: #afeeee; font-weight: bold;" span="span" _="_" _20="_20" to="to" _1="_1">val customer = new Customer(i) ?? It took me a minuet to figure out that was a bug in the HTML page, and not some obscure scala syntax i haven't seen yet ;)
freshhawk 16y ago
Am I the only one who see's this as blatant link bait? I only read part 2 but he's either not doing this seriously or he's overconfident in his thinking abilities.
- rbarooah 16y ago
  He does come across as smug, but as far as I can see, the clojure version is indeed both smaller and correct compared to the longer and buggy scala version. What do you think he's missing?
  - jorgeortiz85 16y ago
    He's comparing Actors to STM, not Scala to Clojure. I'd be more interested in a comparison of Clojure's STM to ScalaSTM (http://nbronson.github.com/scala-stm/index.html http://nbronson.github.com/scala-stm/index.html).
    - rbarooah 16y ago
      This is true, but to be fair, rightly or wrongly those are the technologies that are put forward by the designers as the primary solution for concurrency problems in the respective languages. ScalaSTM looks good though and the comparison would be interesting.
      - jorgeortiz85 16y ago
        The philosophy behind Clojure is that there is a right way of doing things and a wrong way of doing things, and Clojure won't let you do things the way it considers to be wrong. The philosophy behind Scala is that you can do whatever you want. It might nudge you in certain directions, but it won't force you. The language is designed to be flexible enough to support several paradigms. Actors was a demonstration of this: you can build some of the syntax and semantics of Erlang actors into Scala as a library, rather than a core feature of the language. Likewise with ScalaSTM: it's purely a library, rather than a core feature of the language. If you pick a problem that's well suited to STM, you can use STM in Scala. If you pick a problem that's well suited to Actors, you can use Actors in Scala. If you pick the wrong tool for the problem, well, then yes, you'll find yourself in a lot of pain.
        rbarooah 16y ago
        The Scala philosophy of actors just being a demonstration has been somewhat lost when you look at the literature, where Actors are presented as a solid solution. STM doesn't really exist in Scala except as an experiment, so you cannot use it in Scala unless you're prepared to seek out the experimental library. Yes, yes, I know it's planned for inclusion and code is being tested, but that's not the same as shipping today in the base library. I agree that Scala is all about flexibility "a scalable language" etc, but in practice we're talking about comparing a future Scala feature with today's Clojure. I don't see how you can say that Clojure 'won't let you' use actors. It would seem to me just as easy to implement an actors library in Clojure as to implement STM in Scala. Rich Hickey has even suggested himself that Actors may show up for use in distributed systems in a future Clojure. My point is that this is a reasonable comparison between the current versions of the languages that most people are likely to encounter. If a journeyman programmer has a concurrency problem to solve in each of the languages today, they'll be guided towards the STM system in Clojure, and the Actors library in Scala. The original article which compares the two is actually quite insightful in exposing difficulties with using Actors. Given that the solution was taken from a prominent book on Scala and not contrived by the author, it's hardly a strawman. Why did the authors of the O'Reilly book pick actors if they're a bad choice? If they're doing it wrong, it would be useful to explain why, than to just shoot the comparison down by saying Scala can do anything once the appropriate library has been written.
- plinkplonk 16y ago
  "Am I the only one who see's this as blatant link bait?" Lau Jensen is a known pro Clojure troll with a history of dissing other languages with not much knowledge about those languages. See the discussion at http://news.ycombinator.com/item?id=1771595 http://news.ycombinator.com/item?id=1771595 for links to where he attempts to discredit Scala, C# and Python (the last of which, in retrospect, is mildly funny, since a Clojure port of Norvig's Sudoku solver ended up slower than Python). fwiw he's even made dumb comments on the Clojure dev process and got told off by Rich Hickey.(who said about one of his blog posts "tl;dr: This blog post is the idle chatter of people who are not involved in the Clojure development process in any significant way. Lau has never submitted a single patch. Apparently his free lunch isn't arriving fast enough." http://news.ycombinator.com/item?id=2055543 http://news.ycombinator.com/item?id=2055543) I wouldn't pay him much attention (I am surprised this article got so many upvotes). He writes inflammatory stuff all the time. Think Jon Harrop minus the competence.

39 points by DanielRibeiro 16y ago

For whoever misses part 1: http://www.bestinclass.dk/index.clj/2009/09/scala-vs-clojure-lets-get-down-to-business.html http://www.bestinclass.dk/index.clj/2009/09/scala-vs-clojure...

grimlck 16y ago

for (i <_- style="color: #afeeee; font-weight: bold;" span="span" _="_" _20="_20" to="to" _1="_1">val customer = new Customer(i) ?? It took me a minuet to figure out that was a bug in the HTML page, and not some obscure scala syntax i haven't seen yet ;)

freshhawk 16y ago

Am I the only one who see's this as blatant link bait? I only read part 2 but he's either not doing this seriously or he's overconfident in his thinking abilities.

rbarooah 16y ago
He does come across as smug, but as far as I can see, the clojure version is indeed both smaller and correct compared to the longer and buggy scala version. What do you think he's missing?
- jorgeortiz85 16y ago
  He's comparing Actors to STM, not Scala to Clojure. I'd be more interested in a comparison of Clojure's STM to ScalaSTM (http://nbronson.github.com/scala-stm/index.html http://nbronson.github.com/scala-stm/index.html).
  - rbarooah 16y ago
    This is true, but to be fair, rightly or wrongly those are the technologies that are put forward by the designers as the primary solution for concurrency problems in the respective languages. ScalaSTM looks good though and the comparison would be interesting.
    - jorgeortiz85 16y ago
      The philosophy behind Clojure is that there is a right way of doing things and a wrong way of doing things, and Clojure won't let you do things the way it considers to be wrong. The philosophy behind Scala is that you can do whatever you want. It might nudge you in certain directions, but it won't force you. The language is designed to be flexible enough to support several paradigms. Actors was a demonstration of this: you can build some of the syntax and semantics of Erlang actors into Scala as a library, rather than a core feature of the language. Likewise with ScalaSTM: it's purely a library, rather than a core feature of the language. If you pick a problem that's well suited to STM, you can use STM in Scala. If you pick a problem that's well suited to Actors, you can use Actors in Scala. If you pick the wrong tool for the problem, well, then yes, you'll find yourself in a lot of pain.
      - rbarooah 16y ago
        The Scala philosophy of actors just being a demonstration has been somewhat lost when you look at the literature, where Actors are presented as a solid solution. STM doesn't really exist in Scala except as an experiment, so you cannot use it in Scala unless you're prepared to seek out the experimental library. Yes, yes, I know it's planned for inclusion and code is being tested, but that's not the same as shipping today in the base library. I agree that Scala is all about flexibility "a scalable language" etc, but in practice we're talking about comparing a future Scala feature with today's Clojure. I don't see how you can say that Clojure 'won't let you' use actors. It would seem to me just as easy to implement an actors library in Clojure as to implement STM in Scala. Rich Hickey has even suggested himself that Actors may show up for use in distributed systems in a future Clojure. My point is that this is a reasonable comparison between the current versions of the languages that most people are likely to encounter. If a journeyman programmer has a concurrency problem to solve in each of the languages today, they'll be guided towards the STM system in Clojure, and the Actors library in Scala. The original article which compares the two is actually quite insightful in exposing difficulties with using Actors. Given that the solution was taken from a prominent book on Scala and not contrived by the author, it's hardly a strawman. Why did the authors of the O'Reilly book pick actors if they're a bad choice? If they're doing it wrong, it would be useful to explain why, than to just shoot the comparison down by saying Scala can do anything once the appropriate library has been written.
plinkplonk 16y ago
"Am I the only one who see's this as blatant link bait?" Lau Jensen is a known pro Clojure troll with a history of dissing other languages with not much knowledge about those languages. See the discussion at http://news.ycombinator.com/item?id=1771595 http://news.ycombinator.com/item?id=1771595 for links to where he attempts to discredit Scala, C# and Python (the last of which, in retrospect, is mildly funny, since a Clojure port of Norvig's Sudoku solver ended up slower than Python). fwiw he's even made dumb comments on the Clojure dev process and got told off by Rich Hickey.(who said about one of his blog posts "tl;dr: This blog post is the idle chatter of people who are not involved in the Clojure development process in any significant way. Lau has never submitted a single patch. Apparently his free lunch isn't arriving fast enough." http://news.ycombinator.com/item?id=2055543 http://news.ycombinator.com/item?id=2055543) I wouldn't pay him much attention (I am surprised this article got so many upvotes). He writes inflammatory stuff all the time. Think Jon Harrop minus the competence.