[wonton2]

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.

[ryanobjc]

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!

[wonton2]

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.