
Dynamic languages are static languages - llambda
http://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/
======
spacemanaki
There was a lot of interesting discussion on the previous submission:
<http://news.ycombinator.com/item?id=2346590>

Robert Harper's tone seems to rile a lot of people up (some might say he's
aggressive, but I would instead use "enthusiastic") and he seems to pick
really flame-baity titles, but I'm really glad to have found his blog. It's
usually thought provoking stuff.

------
codewright
I realize there was another discussion about 2 years ago and the specifics of
this post have largely been addressed.

I will say that it's a pretty strong turn-off when somebody appears to be
religiously aligned in their technical outlook. I'd rather talk to somebody
who appreciates the pros and cons of static vs. dynamic typing and what the
actual implications are.

I don't want to talk to somebody who appears to only understand dynamic typing
as a strawman and for whom higher-kinded/dependent static type systems are a
crusade. I don't trust crusaders to make sound engineering recommendations, I
want to talk to people who have a sober, well-reasoned, and experienced
outlook on a subject.

I like static type systems, I like compile-time type checking. That's not
going to stop me using a dynamically typed language where it's appropriate.

I'm going to loosely reiterate what Hickey has said on the matter: It's often
the conceptual aspects of a problem that are difficult. The more quickly you
can hammer out what exactly it is you need to do, the better off you are.

Static type systems, as they currently exist in Haskell, Scala, OCaml, Agda,
Epigram, Java, C#, C++, et al don't do a lot to help here. I'd rather chuck
some Python/Clojure around until I know what it is exactly that I want, then
start writing more rigid code.

Part of why I like Clojure so much is that when an API or the "shape" of my
problem becomes more clear after the REPL/experimentation stage, I can begin
defining things in terms of protocols or interfaces.

What's most interesting to me about this is that the protocols are largely
typeclasses which Go's interfaces resemble. You get the same basic expressive
power but there are better affordances for the conceptual stage and a greater
breadth of how firm/rigid your code is.

Part of my problem with static type systems is that they are often an all-or-
nothing proposition (disabled type-checking/type holes/undefined not-
withstanding, to avert the inevitable cascade of GHC-extension-(ab)using
Haskell users).

To summarize:

It's a progression where your code becomes more concrete and final over time
as you better understand the problem. Dynamic type systems that are well-
designed suit this model very well. Static type systems are better for
performance and for situations where the problem is well-defined and you're
mostly satisfying an engineering problem rather than exploring a conceptual
one that's subject to change.

Side note/anecdote: We use Python prolifically at my day job, what few type
errors that occur are usually related to None and not the general type errors
that static-type-users tend to suppose happens on a regular basis. Amusingly,
C++, Java, and C# are all subject to this same issue.

We've been cleaning it up over time by using imitations of monads/monoids.

