I think what you're banging your head against is the tension between computer science qua pure science, versus software engineering qua engineering practice.
This tension isn't unique to our field; mathematicians look down on theoretical physicists, who look down on practical physicists, who look down on engineers, all the way down to the humanities, who are generally ignored. Or, to summarize: <http://imgs.xkcd.com/comics/purity.png> So, sure, from a theroetical standpoint, oriented toward proofs and provable correctness, type systems are superior. OTOH, for practicing software engineers, who care more about reliably and efficiently *building shit,* language flexibility is a massive boon, and we compensate for the lack of "provable correctness" with strategies like TDD. I agree w/ Laurent; it's not a black/white issue... to me it's more apples and oranges, dispatching on intent. Are you trying to prove a theorem, or build software? Not that you can't build scalable web services in Haskell, but I don't know anyone within a standard deviation of "sanity" who has ever done so for production code. The beauty of Clojure is that it gives us the ability to create realiable, robust, real-world solutions without sacrificing elegance; not because it's dynamically typed or because it has an optional type system (although both of those aspects are great), but because it combines power and simplicity. Holy wars are fun for a while (if I wanted to start one on this list, I'd go into the superiority of vim over emacs), but if your real goal is building things, you gotta let them go, and when people start heckling the fact that Clojure doesn't implement Hindley-Milner type inference... just shrug, point to the reliable, scalable architecture you built in two weeks, and get back to work. Just my US$0.02. Jason On Tuesday, October 8, 2013 12:46:41 AM UTC-4, zcaudate wrote: > > Hahaha, thanks Philip. Does it really take a doctorate to understand > classification of elephants? > > I think the overall consensus is that having basic type checking is > good... but over doing types is bad. > > Would this be a reasonable guideline for using types? > > 1. Types are useful for structures that HOLD data (ints, strings, maps, > arrays… ) because they provide ways defining standard operations to > manipulate data that make sense in the context of that type of data. It is > helpful to have a type checker check that I am not accessing the 6th > element of a hashmap or that I am adding 10 to "Hello". > > 2. When a particular data-structure is sufficient for holding > information, then its better to just use the data-structure because we have > so many generic operations predefined. > > > For example, if I have to model customers in a line. I wouldn't > have type CUSTOMER and type LINE. I would just represent this as a QUEUE of > MAPS…. > > ---- > > However… I find that I am writing a lot of statements like this: > > (cond (hash-map? v) > …… > > (vector? v) > …… > > (list? v) > ….. > > :else …..) > > I'm not sure a type checker will help in that instance. -- -- 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.
