I really like this explanation. I think code could be thought of as extremely formal requirements interpreted by the computer extremely rigidly (called instructions). And the process of making software is a translation from high level requirements specified in all sorts of ways (like this law text) to gradually lower levels of abstraction. We meet somewhere in the middle by using apis/sdks. And I think programming languages could benefit a lot from becoming more elastic in the sense that they should allow you to consiusly choose which level of abstraction you need at every point in a project lifetime. Not in the sense that php is dynamic and eats errors, but more in the way the optional type forces you to consider if you care about what values tou really need and what to do if you dont have them. Or kind of (not this but kind of!) the way some business process modelling tools lets you create a graphical model of what work needs to be done and lets you automate parts of it gradually. I dont know if this makes sense, but programming languages have a very long way to go and i think they can be used in far more ways than we imagine today.

I disagree with “code can be thought of as formal requirements” - perhaps if you twist the meaning of the word requirement, yes.

This analogy puts us into a place where we mix intent and implementation and make them the same. It doesn’t allow for bugs in a sense.

This is why I dislike analogous thinking!

I was thinking requirements in the sense of «tell don’t ask». And I reslly believe that if we can define intent as implementation (on a high level of course) we have solved many problems. For example if you want to sort transactions by time in a accounting system you should only have to ask for a sorted collection ( sort(transactions)) and not worry about what way the data is sorted. Then the people developing the library for sorting will be able to optimize the implementation independently. This is something we do today, but I think this concept can be taken a lot further if we think of avstracting even higher. At the same time I think this requires rigor and extremely well defined boundaries between layers, so we dont end up with a mess like java null pointers.

Exactly. The law should express the intent, not the implementation means, which can—and does—improve over time.

Imagine a law mandating SHA-1 in 1999; it would end up enforcing a security problem today.

South Korea did a shockingly similar thing to your example in 1999, which enshrined Internet Explorer's use long after the rest of the world had moved on.

They're delegating creating the detailed regulations to the courts. When some court rules that something is acceptable, or unacceptable, you'll know what the "real" rule is.

Another approach some countries have taken is to have laws cite some set of government regulations, which some part of the government is supposed to update. That tends to be even messier as the courts still get involved, but at least you get faster updates.

Mostly agree, but there's a middleground between the ambiguities OP raises and mandating a hash algorithm. Legislators sure do know their limits; they know that laws that are not narrowly scoped remove a lot of limits on the enforcers.