@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.

Reply via email to