Static or dynamic, use whatever works best

All this hype and noise about static vs. dynamic is starting to get to me. You know what? As a developer, I don't care if a language is static or dynamic. I want to write code to get things done quickly, efficiently and in an aesthetically pleasing manner. The last also translates to 'very maintainable', by the way.

Today, Ruby does that for me. Yeah, so it's dynamic. So is Python. Why am I not using Python? Because it doesn't, for one, support first class function objects. I love my blocks and closures. I can do everything in Ruby that I can do in Python, but it'll run slightly slower - that's a trade-off I'm prepared to make in my current context. Because I started out with Ruby and haven't needed something faster, so never really looked at it seriously (thanks, Paul, for pointing out that Python does have first class function objects). I'm also very very productive in Ruby as opposed to Java - I can create elegant code without having to create a bunch of interfaces first. Programming to an interface is not the same as creating a blessed Java interface, jeez, why the constant misunderstanding? Just because you create an interface first in Java doesn't mean you have a better design. In fact I'd argue that you should extract your interfaces in an evolutionary manner, not design them up-front.

However, I'm fairly convinced that Ruby doesn't work on teams of more that 10 people, unless all the developers are absolutely superb. Even then, you still need good documentation in the form of both rdocs as well as unit tests to ensure that code quality doesn't drop. If I'm on a large project, I'd probably vote against Ruby. I'd want to eliminate trivial errors by having a compiled, statically typed language. If it gave me blocks and closures I'd jump at it. Maybe something like Scala. But here's the point - I will use whatever helps me get my job done well given the current context.

An important thing to remember is that all the programming 'swords' we use cut two ways. Take Java - it was designed to reduce developer error. It's fairly successful at that, but is consequentially a singularly ugly and verbose language and the libraries aren't very intuitive. I have seen more crap code in Java than you'd believe possible and half the enterprisey OSS projects out there are an attempt to make development in Java half-way productive. And without a decent refactoring IDE like IntelliJ IDEA or Eclipse, you've already lost the battle. But hey, it's pretty damn fast, and that hotspot JVM is really cool.

Ruby, on the other hand, was designed for the programmer. It has a superb set of libraries which are arguably more intuitive than Java's. Ruby gives a disciplined developer the power to work miracles. Your code will be readable and elegant without being verbose. Every thing's an object and you get blocks, closures, continuations, first class function objects, message based method invocation, meta-programming...
But you know what? It's kinda on the slow side. And all that freedom in the hands of a novice is a sure recipe for disaster. Class behaviour hacked at runtime to fix bugs. No unit tests. Lots of magic in method_missing. Duck-typing misused causing type errors at runtime. Need I go on?

What I'm getting at is that there is no silver bullet - everything has its place. Your average 70,000 employee outsourcer trying to do Ruby projects on a large scale is probably a bad idea, because they can't always guarantee developer quality. Java on the other hand, combined with CMM, ISO and three other certifications may them help achieve some minimum level of code quality.
On the other hand, take something like Mingle or Slideshare, both running on Rails. I know for a fact that Mingle has a very small team (< 10 including devs, analysts etc) and yet managed a 1.0 release in about 9 months. Slideaware on the other hand supposedly started out with Ruby but I believe has now moved to Erlang for performance reasons.

Deciding which language to use should be based on factors like the delivery timeline, experience level of the team, level of discipline in development (TDD, CI) and performance requirements. Not because you like interfaces and believe that you can't use them in a dynamic language.

So the moral is this. Get. The. Job. Done. And use what it takes to do it quickly and well in that context. Period.