On: Don't let dicts spoil your code

[turnsout]

Duck typing is so fragile… Once you have implementations that are depending on your naming or property structure, you can’t update the model without breaking them all.

If you use a real type, you never have to worry about this.

[pistoleer → turnsout]

You would still have to update everything if you rename a field in a struct, what do you mean you never have to worry?

[dwattttt → pistoleer]

If you use type checking, the breakage occurs when you introduce the change: the author of the change is the one who can figure out what it means if 'foo' is no longer being passed into this function.

If you're duck typing, you find this out in the best case when your unit tests exercise it, and in the worst case by a support call when that 1/1000 error handling path finally gets exercised in production.

[pistoleer → dwattttt]

I agree with that, in the context of dynamically typed languages.

Slowly but surely, new languages are starting to develop with static duck typing. Implicit interfaces if you will.

[jcgl → pistoleer]

Which languages are developing? This is something I’ve been wishing for.

[trealira → pistoleer]

> static duck typing

What do you mean by this? Macros? C++ templates?

[turnsout → dwattttt]

Exactly… with strong typing, you can do the refactor automatically, because the IDE knows everywhere that symbol is used. (For codebases in your control—for third party users, you can indicate that something has been deprecated or renamed via a warning or other language feature)

[zmgsabst → turnsout]

And now inserting every middleware is an exercise in retyping the system, rather than piggybacking on the parameter dict.