I think you're right that all or nearly all of the functional aspects of Clojure have counterparts in Scala. On top of that, Scala provides mutable flavors of everything, so you can pick and choose your approach. So that makes Scala better, right?
But the difference between Clojure and Scala is bigger than a feature-to-feature comparison -- they have very different philosophies, and programs developed in Clojure consequently have a very different feel to them than those developed in Scala. I find Clojure programs to be dramatically simpler. Just as one example, consider modeling a deck of cards. In Clojure, you'd be more likely to come up with a simple representation for a card, perhaps: [10 :spades]. Depending on the card game, you might choose to represent a face card as [:king :clubs] or [13 :clubs]. A deck would likely be modeled as just a sequence of cards, and all the built-in sequence functions would apply, for example, shuffle, take, drop, etc. Serializing the data (for example, if you want to keep a database tracking all the shuffled decks you've ever used in a given game) comes for free. On the other hand, in Scala, you'd be more likely to create a card Class with a rank and suit field. The Suit class would be comprised of four case classes, because the philosophy is to enumerate all the possible suits as separate entities -- there's nothing in Scala like Clojure's convenient keywords. For the rank, you'd be steered towards representing all the ranks as integers. The possibility of representing face cards with a name would likely never occur to you, because it would be too complicated to go through the effort of defining the type of a rank to be a "integer or a class comprised of four case classes -- jack,queen,king,ace". For modeling the deck, you probably wouldn't say a Deck is-a sequence, because composition is favored over inheritance. So you'd probably have a Deck class which would *contain* a sequence of cards. This means that you'd have to reimplement methods like shuffle, take, and drop on your Deck class to turn around and dispatch those methods to the underlying sequence of cards. If you're not careful, years of object-oriented training might kick in and before you know it, you're representing the deck as a class where methods like shuffle, take, and drop *destructively update* the underlying sequence -- it feels so natural to do that once you've encapsulated the underlying sequence of cards in a class. If you want to serialize a deck, that's more code to write (although general "pickling" of a Scala object is an *active area of research*). This example pretty much sums up what I prefer about Clojure. I like to tell people that a big part of what makes Clojure special is its philosophy of *lightweight data modeling*. It leads to delightfully simple systems. Scala remains deeply rooted in the OO philosophy, which all too often leads to an over-engineered muddle. -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
