[wtetzner]

> Actually, you often can't :) Ask Microsoft how easy it is for them to change some code once it's been shipped.

My understanding is that the OP was talking about prototyping. Once code is in a public interface in the wild, it's hard to change either way. I don't see how dynamic typing will save you there. In fact, stronger typing can at least help you restrict the ways in which an interface can be called.

[0xbadcafebee]

> Once code is in a public interface in the wild, it's hard to change either way.

Yes! Definitely for the final version (when the prototype becomes production, which is the moment a customer first uses it) everything should be locked down.

> I don't see how dynamic typing will save you there. In fact, stronger typing can at least help you restrict the ways in which an interface can be called.

Strong typing isn't inherently bad here, but it's often associated with strong coupling between components. Often people strongly type because they're making assumptions (or direct knowledge) about some other component. That's death. You want high cohesion and loose coupling, and one way to do that is just not depend on strong types at the interface/boundary.

To recap:

  1. When prototyping, loose types everywhere, to help me make shitty code faster to see it work
  2. When production, loose types at the component boundaries, and strict types within components

https://en.wikipedia.org/wiki/Cohesion_(computer_science) https://en.wikipedia.org/wiki/Loose_coupling

[wtetzner]

> Often people strongly type because they're making assumptions (or direct knowledge) about some other component.

I'm not really sure why strong typing would have that effect. It seems like an orthogonal concern to me.

In fact, strong static types can potentially help make it easier to see where things are loosely or strongly coupled. Often with dynamic typing it's difficult to tell where implicit assumptions are inadvertently causing strong coupling.