On Mon, Dec 16, 2013 at 12:30 PM, Guru Devanla <grd...@gmail.com> wrote:
> 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. > Well, in Scala, if you wanted to simulate keywords (albeit less efficiently) you could just declare the type of something to be String. But you wouldn't do that because the culture is to enumerate all the possibilities. Yes, that culture comes from the fact that Scala's community believes in the value of static typing and being as precise as possible about the type of a value. But Scala's static typing doesn't inherently prevent you from doing a more general solution. That's why I described it as a philosophy, rather than something intrinsic to static vs dynamic typing. > 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? > Yes, although it is more verbose in Scala. I would argue that as we program, hundreds of times every day we make little design choices, and we are subtly influenced by our programming language, generally making the choice that is easiest in the language we are using. I think many programmers, without even thinking about it, would choose Integer over Scala's more verbose equivalent to datatype rank = Jack | Queen | King | Ace | Num of int Keep in mind that the type definition isn't the only place you incur extra complexity: every time you ever process a rank anywhere in your code, the datatype version will need to be "unpacked" using a match mechanism to ensure you've handled all the cases and only those cases. > > 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? > Yes. Again, the ideas of pinning down your types precisely and encapsulating data is more of a cultural/philosophical issue, driven by the static typing and object-oriented paradigms which Scala fully embraces. You can code Scala in other ways, but if you were the kind of person who didn't like those things, you probably wouldn't be using Scala. > > 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 admire Scala, I just don't enjoy programming in it as much as I had hoped. -- -- 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.
