[darrencauthon]

He wrote: "As much static checking as possible: Static checking is good. Did you ever write a larger piece of code in one go, compiled it and it produced tons of errors? All these error would still be there, if you would not have static checking. You err much more than you think."

I think he errors much more than he really thinks. If errors are what he's truly trying to avoid, he'd be more focused on unit testing and TDD than passing syntax.

Descriptions like his make me wonder how many static typing proponents have actually spent any legitimate amount coding in a dynamic language for a production application. It seems all scary to code applications without a big IDE, but I promise that it's possible and a lot of people make it work.

[slurry]

Java developer: "How can you code without an IDE?"

non-Java developers: "How can you code in fucking Java?"

[eropple]

I write Java in Vim on occasion.

I think I'm broken.

[jfb]

I'm a bad person: this made me spit-take.

[jussij]

FTFY

Java developer: "How can you code without a fucking IDE?"

Non-Java developers: "How can you fucking code in Java?"

[qu4z-2]

Type systems are a little more than just syntax. Static analysis can identify unreachable sections of code, for instance, which will often indicate a bug.

Unit tests cannot prove correctness, only provide a finite set of ways in which the program /isn't/ wrong. (having said that, they're definitely useful)

And above all, he's talking about his ideal programming language. Test coverage is the domain of the programmer. There's very little you can put in a language spec to improve test quality.

For the record, I'm a static typing proponent, and I do most of my coding in vim; I only use an IDE when I /have/ to (I use C# at work). I think a lot of people assume static typing necessarily means very verbose languages like Java, which isn't at all true. My ideal solution is some combination of type inference and optional typing that I haven't quite arrived at yet. I like being able to whip up a quick program without worrying about manual type annotations, but it's nice to be explicit about expected types in an API for instance.

[Someone]

"There's very little you can put in a language spec to improve test quality"

You could require presence of unit tests with 100% code coverage (compile both in memory, run unit tests, write object file if 100% coverage)

I'm pretty sure it would drive people crazy, though, and would have them write almost meaningless tests. 100% coverage isn't enough, either.

[jfb]

I think that static and dynamic type systems are classic incommensurable goods [1]. There's no way to pick between them based on some sort of value calculus; you just have to toss your hat in one ring or the other and live with the weaknesses as well as the strengths of your chosen approach.

[1] http://plato.stanford.edu/entries/value-incommensurable

[jacques_chester]

I think people pick dynamic more often because of the reward schedule. Dynamic languages don't dish out as many errors upfront; most of the time it'll "work"-as-written. Immediate positive feedback.

Meanwhile the static typing compiler is spitting grumpy errors about some nitpicktastic piece of fluff it spotted. Immediate negative feedback.

So given the weekend-new-language thing, which example leaves a better impression?

Basically -- generalising enormously -- dynamic languages reward in the short term and punish in the long term; static languages are the opposite.

But human cognition is dreadful at long term prediction or comparison. So static languages will always be underrepresented unless, I dunno, Haskell compilers start doling out XP for fixing errors in your code.