I'm not sure what you mean by invoking the putative silliness of an "any" type, but existential types aren't just a way of saying "anything goes here, typewise"---they do enable further substantive static guarantees (such as those used by e.g. Haskell's ST system).
On Mon, Dec 23, 2013 at 2:16 PM, Chris Zheng <z...@caudate.me> wrote: > @Richard. I would have said the same as you before I joined a relatively > large organisation heavily influenced by scala and the Coursera FP lecture > series. We are slowly moving into Clojure code but there now seems to be a > huge misconception that FP and Type Systems are joined at the hips. > > My conversations with one or two scala fanboys goes something like this: > > Them: "What's so good about clojure anyways? I'm really worried that it's > going to fail in large projects." > > Me: "Well.. Here is a large project. Check out this macro I wrote. it > abstracts out all these underlying complexities and it would be really hard > to this write the code with a type system." > > Them: "But you need types because types are mathematically provable... You > can't write correct programs if you don't have types." > > After a couple of these conversations. I find it useful to avoid them. > However, when push comes to shove, I have a list of examples where having > type systems are not natural to solving the underlying problem - modelling > relationships, querying databases, translating JSON, classifying elements > in non-treelike structures, dealing with change in specifications, > dealing with uncertainty in specifications... All very 'real world' > problems that are an unnatural fit with the type system. > > In those examples - there are ways of wrangling the type system to deal > with the problems, but they end up using an existential type - > http://www.haskell.org/haskellwiki/Existential_type , or a type of types > - http://ktoso.github.io/scala-types-of-types, or something meta like > template haskell. It seems quite silly to have the 'any' type when it is > probably best to not use types at all. Doesn't this remind you of the story > of 'the emperor's new clothes'? > > I completely agree with Korny that types are a premature optimisation. > Therefore understand why and how it is a premature optimisation is really > important to convince organisations to firstly understand, trust and then > use clojure in production. Sometimes, writing good programs and having good > use cases are not enough. We don't need a complete mathematical proof, but > we still need something to substantiate design decisions to those that may > not be as clojure friendly. > ---- > > > > On 24/12/2013, at 7:57, Mark Hamstra <markhams...@gmail.com> wrote: > > Dynamical languages are above all oriented toward practical programming >> needs *in certain contexts*--in other contexts, static typing is more >> practical. >> > > Agreed -- which is why I find your speculation about "lightening up" with > "more experience ... meeting the demands of practical coding" to be > unsound. For those of us whose "practical programming" context includes a > high cost associated with most any runtime bug, greater embrace of static > typing, not "lightening up", comes with more practical experience. I can > be happy using a dynamically typed language when the price to be paid for > getting it wrong isn't as high; but all of my experience goes against > "lightening up" in the demanding programming context where I work every day. > > > On Monday, December 23, 2013 10:04:52 AM UTC-8, Mars0i wrote: >> >> I came to this thread late, and have only skimmed some of the answers, >> but I think that the following, somewhat oblique, opinion hasn't yet been >> expressed about the, I don't know, maybe ... harassment by "type weenies" >> that zcaudate feels. Apologies in advance if I've missed a similar point. >> >> First, I'll note that I agree with many of the comments so far. To >> everything there's a season. That goes for type systems. >> >> In what I say next, I'm not trying to offend anyone. I'm expressing >> half-baked opinions about what I feel are general tendencies. I am certain >> that there are exceptions to *every* generalization I make. >> >> My personal opinion: >> >> Many of us who like programming like it partly because we like order, >> systematicity, and elegance, at least in our thinking. We like things to >> make sense. Some people have a greater need for this than others, at least >> at certain stages of their life. So things that seem more clean and neat >> are attractive. Full-fledged static typing has this character. It's >> appealing because it's orderly in a very, well, strict sense. I think it's >> probably easier to be religious about static typing and provable >> correctness as a universal goal if you don't have to deal with a lot of >> pragmatic concerns. So I suspect that many type zealots are students or >> were recently, and that they'll end up lightening up in several years, >> after they've got more experience with meeting the demands of practical >> coding. (That's not to imply they'll necessarily give up affection for >> static typing, but it's hard to be a zealot after you've freely chosen, >> many times, to compromise on formerly rigid principles.) Dynamical >> languages are above all oriented toward practical programming needs *in >> certain contexts*--in other contexts, static typing is more practical. >> Maybe some of the hard core static type advocates will see the potential >> benefits dynamic typing when they get more experience. But you can't >> *prove*, mathematically, that dynamical typing is better sometimes. Its >> advantage comes out in actual *practice* in real-world situations. >> ("Real world" doesn't mean business. I'm an academic coding solely for >> research purposes (and fun!).) >> >> My 2c. >> >> -- > -- > 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 a topic in the > Google Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/0I7u5yn01qU/unsubscribe. > To unsubscribe from this group and all its topics, 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. > -- Ben Wolfson "Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure." [Larousse, "Drink" entry] -- -- 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.
