> [follow] a convention of including unit names in identifier names.
appending units to identifiers helps, but it relies on a developer's eyeballs to spot any errors. It would be infinitely preferable if the type system would simply enforce this for you and developers not have to expend cycles reasoning about this stuff themselves.
If you stick to just a few units throughout the system (ideally, use a consistent base unit everywhere and convert any external measurements to it), you can avoid the rest of the problems.
Static typing is great, of course, I just don't agree that this can't be solved to almost the same level with languages with dynamic typing.
The keyword is “almost”, and whether you need stricter typing depends how much you care about software correctness (or to be pedantic, the class of problems that the typing system can fix for you in the language in question).
but it relies on a developer's eyeballs to spot any errors.
I'm assuming a relatively normal/sane environment where code is reviewed at pull request time, and there is a test suite.
developers not have to expend cycles reasoning about this stuff themselves
It is not my experience that `launch_rocket(distance_km:)` requires any extra cycles whatsoever.
I mean, as a coder, I'm going to have to be cognizant of the type anyway, even if we're doing `launch_rocket(distance:)` in a strongly typed language where `distance` is something of type `RocketLaunchDistance` or whatever.
I'm not arguing against static/strong typing in general or anything. Definitely lots of times when it is the clearly superior choice.
appending units to identifiers helps, but it relies on a developer's eyeballs to spot any errors. It would be infinitely preferable if the type system would simply enforce this for you and developers not have to expend cycles reasoning about this stuff themselves.