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.
Tuesday, December 24, 2013
Clojure vs Scala
Last week, someone posted a question on the Clojure group asking for a comparison between Clojure and Scala. Since my most popular blog post, by far, is my Racket vs Clojure post from three years ago, I thought it would be good to post my response here. Ten years ago, I would have said that my ideal dream language is one that provides the flexibility to program in any style. I want to be able to choose object-oriented or functional, immutable or mutable, high-level abstractions or low-level speed. With respect to this ideal, Scala clearly wins, supporting more programming styles than Clojure. I've definitely changed my tune, though, and now I actually prefer the way that Clojure constrains and shapes my thinking. I argue that even though Scala may provide me with more options on how to tackle a given programming problem, Clojure guides me towards a simpler solution. If this intrigues you, read on... The following text is only slightly paraphrased from what I posted to the group: