Static Reasoning favors perfect planning over runtime adaptability. This is a favored approach in the software community. However, there are limits to static reasoning, grasping this fact helps achieve better manageability of complexity.
Richard Gabriel in his arguments why "Objects Have Failed", writes:
And as a result we find that object-oriented languages have succumb to static thinkers who worship perfect planning over runtime adaptability, early decisions over late ones, and the wisdom of compilers over the cleverness of failure detection and repair.
Beyond static types, precise interfaces, and mathematical reasoning, we need self-healing and self-organizing mechanisms, checking for and responding to failures, and managing systems whose overall complexity is beyond the ken of any single person.
PI Calculus, the formalism that underlies some common Business Process Modelling languages, may have an interesting role to play in the static versus dynamic languages debate. Lots of powerful techniques that can be used with PI Calculi involve using higher order concepts such as sending names of ports/channels over links, creating ports on the fly and so on.
This stuff drives the math heads nuts because it makes it hard (impossible?) to formally prove equivalence between calculi.
So it boils down to this - do you want to be constrained in terms of flexibility or provably, formally, "correct" at some probably academic level?
Both intersting and compelling arguments, I will admit, I agree with both of them! That may sound as a surprise to people who recall my piece on "Static vs Dynamic Typing" debate. I had sided with the "Static" side. Recall however, my arguments were not for more correctness checking rather it was a realization that being more explicit allows a compiler to do a lot of the thinking for you. That is, the navigation, auto completion, on the fly checking, quick fix capabilities that you find in Eclipse and IDEA tend to outweigh the productivity benefits of any dynamic typed language. People who program in both environments know this as a fact.
However, I've always advocated a loosely coupled architecture. If you looked at the table I constructed earlier on "loose couping", you see that flexibility is a motivation at the expense of correctness. Furthermore, I had earlier talked about "programming in the large", and that our notions of programming in the small do not scale for much larger systems. In fact, the prescription for this, which I explained earlier, is that a dynamic component model is necessary to manage the complexity of building a large scale system.
Thus, the limits of static reasoning can be found at the boundaries between the one author single machine application and the multiple author distributed agent ecosystem.
I liked your points on your post about static vs. dynamic. However after playing with Ruby for a while now, I'm starting to realize a few things.
I think I like Idea a lot because it gets me a lot closer to the productivity you can achieve with a non-typed language that gets out of your way. Java is really in your way. So we call an IDE "good" when it does all these tricks to make Java easier to deal with (well, I think Idea provides a lot of benefit beyond just making Java less of a PITA, but historically this has been the big deal with IDE's).
Nowadays when I'm TDD'ing in Java I really wonder what's so great about all these class names and cast operations I have to type. The only thing I can come up with is when I hit ".", my IDE knows how to show me a list of possible methods/fields.
I, too, greatly appreciate a good IDE, one that gives me auto-completion and the like. It's certainly harder to do that with a dynamic language, but overall I don't find that the help from an IDE outweights the general ease of development using a dynamic language.
I write a lot of Ruby code, and while I don't have anything with auto-complete, I *can* run ri from inside Vim (or the ever-present Windows cmd box) to get a quick list of methods for the main Ruby library. (I also wrote a utility called Rimport to allow the addition of third-party classes to the ri data store.)
Agreed, refactoring IDE's like Eclipse and IDEA are great development tools and Ruby certainly needs a refactoring browser.
But frankly for a greenfield project where I have total discretion over technology I would use Ruby over Java if possible. Even with the IDE tricks I'm much more productive in Ruby. And when you look at a piece of Ruby code you have a signal/noise ratio that Java simply can't approach.
"the navigation, auto completion, on the fly checking, quick fix capabilities that you find in Eclipse and IDEA tend to outweigh the productivity benefits of any dynamic typed language. People who program in both environments know this as a fact."
I know no such thing. I use IDEA for java development. Its just OK. Not great. Compared to working in a Smalltalk development environment its still no contest. Smalltalk is a live environment with a debugger that supports fix and continue available.
Java still leaves you with a compile edit debug cycle. The editors are better than ever, but the diagnostic tools are still no comparison.