but really people who think dynamic typing is suitable for large scale software development are just nuts
Flame-bait. I happen to like static typing-- and I'd be excited to see more progress with optional static typing in Clojure-- but I disagree.
First of all, you can pretty easily get principled strong typing with a language like Clojure. One of the first things I write on a large Clojure project is defn-typed. If types were a major part of what I was doing (e.g. theorem proving) that wouldn't be acceptable, but for web programming it's generally enough. It's pretty easy using a few macros to make it so that you get almost all of the guarantees (from unit testing) that you'd get from compile-time type checking.
Remember: dynamic typing doesn't mean you don't have types. You can include types in your contract system. It means that type sanity isn't checked at compile-time. For certain problems that require extremely high levels of correctness, you need static error-checking/analysis because runtime unit testing isn't good enough. For every large system? No, not the case. What you need, in general, are good programmers and sane development practices; those matter a lot more than static vs. dynamic.
My experience is that static typing performs best when you're trying to solve a known problem extremely well, and that's not an uncommon thing in software. Dynamic typing is better-suited to a more chaotic world where you don't know the problem yet, because it makes it easier to "poke" at things in the REPL and build prototypes.
Also, improperly used, static and dynamic typing both fall down disastrously on large or distributed systems. For example, if you have circular dependencies in a large Scala project ("don't do that", you might say; but we're talking multi-developer now, with the full spectrum of skill) you're going to see gargantuan compile times because incremental compiles will fail you, and while Scala's compiler is an extremely powerful machine, it's not fast.
All this said, Haskell is still a very cool language and I think everyone who wants to be a serious computer scientist needs to get some exposure to what it has to offer. Real World Haskell is a great book, for starters. I also think Scala is great if you have strong developers who won't be tempted to OOP things up.
I've found that static types help with prototyping because you can make changes to types used in your program and the compiler lets you know when you missed a spot, those locations could live for months in your code in a dynamically typed project.
static typing systems work with good programmers and sane development practices as a force multiplier. dynamic typing systems become something that requires you to have good programmers.
I've found that automated testing helps with prototyping because you can make changes to tests for your program and the tests let you know when you missed a spot, those locations could live for months in your code in a project without tests.
Yes, but this requires the additional steps (and work) of making the changes to your tests. Tests give a good approximation of what static analysis gives you, but it is more cumbersome. (Of course tests can also do things static analysis can't)
I usually write a macro (defn-typed) that generates pre- and post-conditions (contracts, essentially) for crucial APIs when I'm working in Clojure.
It's not as good as static analysis at catching all type errors-- if that's what you need, I wouldn't recommend any dynamic language-- but it does mean that most type errors will be caught in unit testing, with minimal recurring work.
Flame-bait. I happen to like static typing-- and I'd be excited to see more progress with optional static typing in Clojure-- but I disagree.
First of all, you can pretty easily get principled strong typing with a language like Clojure. One of the first things I write on a large Clojure project is defn-typed. If types were a major part of what I was doing (e.g. theorem proving) that wouldn't be acceptable, but for web programming it's generally enough. It's pretty easy using a few macros to make it so that you get almost all of the guarantees (from unit testing) that you'd get from compile-time type checking.
Remember: dynamic typing doesn't mean you don't have types. You can include types in your contract system. It means that type sanity isn't checked at compile-time. For certain problems that require extremely high levels of correctness, you need static error-checking/analysis because runtime unit testing isn't good enough. For every large system? No, not the case. What you need, in general, are good programmers and sane development practices; those matter a lot more than static vs. dynamic.
My experience is that static typing performs best when you're trying to solve a known problem extremely well, and that's not an uncommon thing in software. Dynamic typing is better-suited to a more chaotic world where you don't know the problem yet, because it makes it easier to "poke" at things in the REPL and build prototypes.
Also, improperly used, static and dynamic typing both fall down disastrously on large or distributed systems. For example, if you have circular dependencies in a large Scala project ("don't do that", you might say; but we're talking multi-developer now, with the full spectrum of skill) you're going to see gargantuan compile times because incremental compiles will fail you, and while Scala's compiler is an extremely powerful machine, it's not fast.
All this said, Haskell is still a very cool language and I think everyone who wants to be a serious computer scientist needs to get some exposure to what it has to offer. Real World Haskell is a great book, for starters. I also think Scala is great if you have strong developers who won't be tempted to OOP things up.