> I've never really understood this stance. It's all code. It's not like you can't change it later.
Actually, you often can't :) Ask Microsoft how easy it is for them to change some code once it's been shipped.
The "new thinking" is that you should teach your users to upgrade constantly, so you can introduce breaking changes and ditch old code, sacrificing backwards compatibility. But this often makes the user's life worse, and anyone/anything else integrating with your component. In the case of a platform it makes life hell. For a library, it often means somebody forks or sticks with the old release. For apps it means many features the users depend on may stop working or work differently. It basically causes problems for everyone except the developer, whose life is now easier because they can "just change the code".
In many cases you literally can't go this route, due to technical issues, downstream/upstream requirements, contractual obligations, or because your customers will revolt. This affects almost all codebases. As they grow and are used more often, it makes changes more problematic.
> 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.
> 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
> 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.
Actually, you often can't :) Ask Microsoft how easy it is for them to change some code once it's been shipped.
The "new thinking" is that you should teach your users to upgrade constantly, so you can introduce breaking changes and ditch old code, sacrificing backwards compatibility. But this often makes the user's life worse, and anyone/anything else integrating with your component. In the case of a platform it makes life hell. For a library, it often means somebody forks or sticks with the old release. For apps it means many features the users depend on may stop working or work differently. It basically causes problems for everyone except the developer, whose life is now easier because they can "just change the code".
In many cases you literally can't go this route, due to technical issues, downstream/upstream requirements, contractual obligations, or because your customers will revolt. This affects almost all codebases. As they grow and are used more often, it makes changes more problematic.