I think there's a case to be made for a theoretical subjectivity. Mathematical purity is nice and elegant, sometimes useful, but 'useful' refers to utility. The ease or the cost of making some valuable change to code in the possibility-space of changes you might make, and the ramifications of that change are directly proportional to utility. Understanding the theoretical, but discerning the 'useful' is what makes an engineer effective, and that's the difference between an engineer and a theoretical computer scientist.
I can say objectively that clojure is useful, because programs are read and languages are worked in subjectively by subjective humans, and I find it more useful than other things. That's at least a statistical measure (mathematicians frown on statistics too? Statistics are definitely useful, as anyone with a working cell phone should appreciate). If there's a theory that I could explore more to make a case, it would be one of cognitive load, mental 'overhead', and the convenience of removing classes of worries (say, action at a distance), letting you reason about your program in side-effect-free chunks. The easier it is to draw lines around chunks of your program, or the lower the time/effort cost of changing code to make the first easier, the less benefit there is to be had in types/contracts, in my opinion. Practical engineering is about the economics of the process, and it's about how our tools plus outside constraints limit our solutions. Mathy guys value 'objectivity', as that's the accepted social currency that's ingrained in techies. Clojure has a rich/proven heritage and a coherent/enabling design, and programs are written and read by people, so I think it's ok to admit that the subjective is 'useful' when there's enough objective common ground. We will be the most persuasive when we understand the theory and point of view of the other side of the argument, and we can effectively engage in the economics of that kind of reasoning. On Tue, Oct 8, 2013 at 1:46 AM, Jason Lewis <ja...@decomplecting.org> wrote: > 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. > -- -- 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.
