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.

Reply via email to