Have you ever tried a dynamic language with a good supporting IDE (e.g. VW Smalltalk)? Try it and see what you think. Before Intelij can use your type system to help, you need to type in a hell of a lot of extra information first. Also there is a lot of stuff that a static language stops you doing, hence the need for patterns like factory, null object etc.

I know of no one who has tried both and feels that static languages are more productive (even using intelij).

I wasn’t trying to be controversial – static typing helps intelligent IDEs. It is a fact. Heck. Even Fowler says so in his famous blurp on dynamic typing:

Another area where static typing is useful is that it allows programming environments to be much more helpful. The revelation here (as in so many things) was IntelliJ. With an IDE like this I really felt the type system was helping me. Even simple things like auto-completion are greatly helped by static types, and leading IDEs can do much more than that.

(From http://martinfowler.com/bliki/DynamicTyping.html)

I’m from a C/C++ background, and whilst C/Unix was great in its’ day, I think we’ve got a bit stuck on the C legacy and need to see beyond C derived languages. As an advocate of Agile development, I agree that productivity is significant, and dynamic languages are just more productive (and fun).

Also static languages don’t really fully support OO semantics (IMHO). For full OO semantics I think that late binding of messages to methods at runtime is crucial (something overlooked in C++). The nearest Java gets to this is interfaces.

So ruby is a step in the right direction, but if people could just let go of the C like syntax the options increase.

Dynamic, pure 00, with a great class library and a great IDE? Sounds like Smalltalk!

I just do not understand why this obvious choice (to me at least) is so often overlooked.

The problem seems to be somewhere between a grotesque fascination with XML configuration files and the market-purported need for heavy application servers. Java isn’t heavy; it’s how people use it that makes it seem heavy.

Thank you for pointing out that there is a better way to develop then to deploy an app before running it. In the development team I work in we use a combination of Tomcat, Eclipse 3.1 and a project laid out like an expanded WAR to get all the benefits of so called code/alt-tab/refresh aka CAR (why not another TLA?) development. When Tomcat can’t handle a hotswap of the code the JVM terminates and restarts — with moderately fast machine this restart is not noticeable.

Here’s the rest of the environment for the heck of it. All in-container unit tests are done with Jetty/http-lib, Hibernate/x-doclet is used for O/R mapping and a stripped down struts+velocity setup for the web framework.

I have to disagree.

The language shapes and fundamentally defines what kind of tool support you can have.

Creating a refactoring tool like Idea for Ruby (or any other pure dynamic language) is impossible because you are severely limited on what you can statically reason about.

You will be left with tools that are little more than search and replace macros – loosing the “semantic preserving” guarantee that is what refactoring is all about.

Static typing has its strengths and weaknesses. It is more verbose and it can worsen the impedance mismatch between RM and OO.

But tool support: refactoring, UML-diagramming etc. is where it shines.

In freeride.rubyforge.org:s newest version 0.9.4. experimental refactoring support is deactivated because it doesn’t work too well.

And, there is no Windows or Linux version for x86 of TextMate, so I’m kind of lost what editor to use on Windows or Linux to code RoR.

Anyway, I agree that good tools are nice. I liked IDEA a lot when I was doing some Java work. I obviously enjoy pushing productivity into the core tools (the language, the framework) rather than layering it on top. BUT, I’d certainly like to have IDEA for Rails.

Good tools are important. Java is blessed to have IDEA and Eclipse.

It is much less useful when your (static) code structures are still in flux.

Essentially, the further you are in a project, the more useful it becomes. So don’t try using it at the start of a project, but switch it on once your interfaces and object structures have settled down a little.

Maarten