[anamax]

> 1. A program is run more times than it is compiled (hopefully). So the goal is really to make the effective combination of the two more efficient in a given usage scenario.

You're not counting development time, or rather, cost.

Even if I eventually need the efficiency of a statically typed language, dynamic languages let me save the time that I would have spent satisfying the type checker on code that didn't make it into that version.

> On the other hand, with a dynamic typed language, if N seconds are shoved away from compilation, at least N seconds will be added to run-time.

It's unclear that that's true. In fact, the cost of compile-time type checking is typically more than the cost of run-time type checking during much of development.

> Run-time errors take longer to detect and correct and the process of doing so is bound to see less automation.

Run-time errors aren't detected until run-time but since folks with dynamic languages get to run-time faster, they're often detected earlier.

As to "less automation", I don't see it. Do you have an automated system that corrects type errors?

[alok-g]

I partly agree to what you said, but just for sake of completeness:

>> Even if I eventually need the efficiency of a statically typed language, dynamic languages let me save the time that I would have spent satisfying the type checker on code that didn't make it into that version.

This conversion does not sound so trivial to me generally. At times converting from a dynamic language to a statically typed language requires either a change of code architecture or a massive refactoring operation.

>> Do you have an automated system that corrects type errors?

Not corrects, just detects. I have at times faced issues when code runs for half-an-hour and then crashes just because a the given object could not be converted to the needed new type at run-time. My reaction: "Sigh! I wish the compiler told me earlier during compile-time!"

[anamax]

> This conversion does not sound so trivial to me generally. At times converting from a dynamic language to a statically typed language requires either a change of code architecture or a massive refactoring operation.

I didn't claim that it was necessarily trivial. However, I'm happy to claim that it is very rarely required. What is it that they say about premature optimization?

That said, I think that you're overstating the amount of work. As our python friends keep demonstrating, the amount of code that is actually performance-critical is usually fairly small and can be handled by special means once you get things relatively stable.

And, when it is required, it may be an indication of massive success. If you wrote the first version, said massive success may make the conversion someone else's problem. :-)

> Not corrects, just detects. I have at times faced issues when code runs for half-an-hour and then crashes just because a the given object could not be converted to the needed new type at run-time. My reaction: "Sigh! I wish the compiler told me earlier during compile-time!"

No optimization produces speedups in every situation.

As to that particular problem, I develop in dynamic languages so I "never" have that problem after a significant amount of run-time.

To me, it's important to remember that dynamically and statically typed languages give you different rope with which to hang yourself, so it's best to program with that in mind.

To put it another way, it is generally agreed that it's a bad idea to write fortran in other languages even though it is possible. Why would you think that it would be a good idea to write static in a dynamic language or the reverse?