[0xbadcafebee]

Strict types are a great way to paint yourself into a corner. Good design should only impose strict types within a single module, with very loose coupling outside the module (meaning loose types)

Having a well defined data model is important, but you often can't really know what that data model should be until you've banged on a prototype. So the faster (in the long run), "better" way is to first prototype with very loose types and find what works, and then lock it down, within the scope of the above paragraph

[wtetzner]

> Strict types are a great way to paint yourself into a corner.

I've never really understood this stance. It's all code. It's not like you can't change it later.

> So the faster (in the long run), "better" way is to first prototype with very loose types and find what works, and then lock it down, within the scope of the above paragraph

I think this depends on the programmer, and what they're experienced with, how they like to think, etc. For example, as counterintuitive as it might seem, I find prototyping in Rust to be much quicker than in Python.

[0xbadcafebee]

> 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.

[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.

[pphysch]

>> Strict types are a great way to paint yourself into a corner.

> I've never really understood this stance. It's all code. It's not like you can't change it later.

Try maintaining a poorly designed relational database. For example, I am dealing with a legacy database where someone tacked on an innocent "boolean" column to classify two different types of records. Then years later they decided that it wasn't actually boolean and now that column is 9-valued. And that's how you get nonsense like "is_red=6 means is_green". Good luck tearing the entire system apart to refactor that (foreseeable) typing/modeling error. The economical path is usually to add to the existing mess, "is_red=10 means is_pink".

[wtetzner]

And if this was an untyped blob of JSON it would somehow be better?

I'd argue that dynamic typing makes it easier to paint yourself into a corner.

[marcosdumay]

The stuff you are complaining about is caused exactly by lack of type strictness.

Nobody fixes it because nobody has any idea on what code depends on that column. With strict types you just ask the computer what code depends on it, and get a list a few minutes later.

[forrestthewoods]

> So the faster (in the long run), "better" way is to first prototype with very loose types and find what works, and then lock it down, within the scope of the above paragraph

Disagree. You can still prototype and refactor with strict types. I don't find working with loose types to be faster at all. Once a program reaches non-trivial complexity loose types make iteration development significantly more difficult and error prone.

[JamesSwift]

Why loosen the types on the API, when the type system is fully capable of encoding higher-level restrictions? That then locks you into that API as a contract. If you instead lock the API down to the strict set, you are free to expand it over time.