This is true, but there are a couple of points missing: firstly, many real-world programs are bound by factors other than the CPU, i.e. waiting for I/O or network events. In this case, benchmark speed differences between static and dynamic (or compiled and interpreted) are irrelevant. Secondly, the point of static typing is not merely for performance, but (hopefully) to catch some errors at compile time.
> Secondly, the point of static typing is not merely for performance, but (hopefully) to catch some errors at compile time.
The relevant question isn't so much when they're caught but how much it costs to fix them.
Has anyone seriously looked at whether or not the relevant hope is justified? I'm pretty sure that it isn't in any useful sense. Yes, static typing does trigger compiler errors, blocking further development until they're fixed, but those sorts of errors get caught when they're relevant in dynamic languages. When they're relevant right away, it's unclear that compile-time is cheaper. When they're relevant later, "blocking further development until" looks like a bad thing.
My expensive bugs are not caught by static type systems.
[+] [-] gaius|18 years ago|reply
[+] [-] anamax|18 years ago|reply
The relevant question isn't so much when they're caught but how much it costs to fix them.
Has anyone seriously looked at whether or not the relevant hope is justified? I'm pretty sure that it isn't in any useful sense. Yes, static typing does trigger compiler errors, blocking further development until they're fixed, but those sorts of errors get caught when they're relevant in dynamic languages. When they're relevant right away, it's unclear that compile-time is cheaper. When they're relevant later, "blocking further development until" looks like a bad thing.
My expensive bugs are not caught by static type systems.