Just so. As I said, given the choice between static types without dynamic types and dynamic types without static types, I unhesitatingly affirm my preference for the ape, er, latter.

Sure, they could do proper reuse with creating abstractions, interfaces, design, bla, bla, but that requires effort and time which means that “the app” might only work tomorrow, which is not good because we need to ship yesterday. Oh and let’s not forget that good abstractions and interfaces require a better trained/more experienced/talented developer (more expensive, less replaceable, higher risk). So in the short term, it makes perfect business sense to “go dynamic”, and nowadays, nobody plans farther than the next quarterly shareholder meeting.

“Changing the library to accommodate the bug was another possibility, but a truly unpleasant one.” … bla … “so we made the new version of the library detect the presence of the buggy class”

So, you went with the unpleasant solution, what’s your point in favor of dynamic languages again? Oh, it’s the Java and C/C++ don’t allow hot-swapping of library methods, well for your particular use-case I think even old Java could hot-swap. In general I don’t see why statically typed languages could not do that.

@millstone2:
If I link against a library by someone who chose to ignore those warnings then my own program is broken without me getting any diagnostics.

Re generic proxies: all you need is either a typecase or a type dynamic – both can be supplied without breaking the type system.

This is one of the reasons I *prefer* static languages and real type systems.

We ship a library which contains a hash table class used by many client applications. While testing the next version of the library, we found that it revealed a latent bug in a high-profile client app: two equal objects could have different hash values, leading to data loss. Bad news!

The client app had already shipped to customers, all of whom would be unhappy if we released the library. We could try to get those customers to update the app, but it would have been expensive and inevitably some customers would not update in time. Changing the library to accommodate the bug was another possibility, but a truly unpleasant one.

Fortunately the library and client app were both written in a dynamic language, so we made the new version of the library detect the presence of the buggy class. If it finds it, it reaches in and outright replaces its hash method with a corrected one. Problem solved!

Note that this had nothing to do with type checking (though we could have dynamically introduced a type error if we chose, casting doubt on the whole notion of a “provable static type system”). Instead it’s all about the compiler permitting static information to be wrong. If the compiler assumed that the object’s hash function at compile time would not change at runtime (say, by inlining it), this fix would have been much harder. But dynamic languages made it simple!

This has real practical implications, e.g. if you change some type in your Haskell code, you have to fix every use of that type before you can test anything. Surely you’ve found that annoying? Dynamic languages permit interleaved fixing and testing.

Generic transparent remoting really is not possible to support in a static language. For example, see how Microsoft went about adding the [TransparentProxy class to C#](http://blogs.msdn.com/b/cbrumme/archive/2003/07/14/51495.aspx), which required significant changes to the compiler and runtime. In every case where the compiler emits a method call, it has to construct a special stub that considers the possibility that the receiver could be a TransparentProxy. In short, they were forced to tack on some limited dynamicism to the runtime to support remoting (and note the consequence: compile time types are now permitted to be wrong).

Had C# been a real dynamic language, this remoting could have been implemented entirely in a library, without requiring compiler or runtime modifications. That’s the strength of dynamic languages.

Many functional languages support interactive programming trivially, due to the fact that most if not all computation is pure. That being said, not all functional languages are equal in how long it takes the interactive session to resolve changes or how well they can handle changes without requiring a “reload” command.

Changing behavior at run-time isn’t even that particularly wild of a party trick. It also might not be the best way to describe what the “dynamic” program is doing; maybe what you are really trying to do is achieve an equilibrium state and abusing dynamic languages to achieve that goal? If so, why not spell out the goal state and let the runtime figure it out for you? Don’t you just love systems you can deploy and walk away from and not have to get paged into the office at 3am to fix, because you’ve proved they work?

And it think that author miss the point. Dynamic languages are called dynamic, not because of absence of static types, but because you can change the program behavior at run time, without need to do full world stop, and run compiler to do some static-type analysis for you.