Hi Mark, A few questions:
1. The point you raise regarding declaring case classes is inherent to the typed nature of Scala, correct? Can that be pointed to as valid strength of Clojure. Since, we are comparing static vs dynamic typing here. 2. I am not super familiar with Scale, but I am assuming Scala can do similar to what we have in ML, which would look like this: datatype rank = Jack | Queen | King | Ace | Num of int Isn't a similar idiomatic case class sufficient to achieve the needed simplicity in Scala? 3. Regarding walking down the path of multiple object hierarchies, I guess that is only a choice in Scala and is not necessitated by idiomatic Scala. So, can't one just use the functional construct to achieve what you define in Clojure? I believe Scala's blending of static typing with OO and FP principles is a exciting area of research and only time will tell if we could have all the features in one big language. Scala's tries to be different language to different people depending on which background one approaches from. I also agree with one other member where it is stated that Scala is just too complex and Clojure's wins by its simplicity and consistent representation. Thanks Guru On Mon, Dec 16, 2013 at 12:13 PM, Mark Engelberg <mark.engelb...@gmail.com>wrote: > 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. > -- -- 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.
