> The problem is that after a half a century, software engineering discipline has been unable to agree on global conventions and standards.
It can't, and it won't, as long as we insist on always working directly on the "single source of truth", and representing it as plaintext code. It's just not sufficient to comprehensibly represent all concerns its consumers have at the same time. We're stuck in endless fights about what is cleaner or more readable or more maintainable way of abstracting / passing errors / sizing functions / naming variables... and so on, because the industry still misses the actual answer: it depends on what you're doing at the moment. There is no one best representation, one best function size. In fact, one form may be ideal for you now, and the opposite of it may be ideal for you five minutes later, as you switch from e.g. understanding the module to debugging a specific issue in it.
We've saturated the expressive capability of our programming paradigm. We're sliding back and forth along the Pareto frontier, like a drunkard leaning against a wall, trying to find their way back to a pub without falling over. No, inventing even more mathematically complex category of magic monads won't help, that's just repackaging complexity to reach a different point on the Pareto frontier.
Hint: in construction, there is never one blueprint everyone works with. Try to fit all information about geometry, structural properties, material properties, interior arrangement, plumbing, electricity, insulation, HVAC, geological conditions, hydrological conditions, and tax conditions onto a single flat image, and... you'll get a good approximation of what source code looks like in programming as it is today.
I think we have to think of software like books and writing. It is about conveying information, and while there are grammatical rules to language and conventions around good and bad writing, we're generally happy to leave it there because too many rules is so constructive as to remove the ability to express information in the way we feel we need to. We just have to accept that some are better writers than others, or we like the style of some authors better.
That would make sense if code was written solely for the enjoyment of its readers, but it isn't.
Code uses text, sometimes even natural-language prose, but isn't like "books and writing". It has to communicate knowledge, not feels. It also ultimately have to be precise enough to give unambiguous instructions to a machine.
In this sense, code is like mathematical proofs and like architectural blueprints, which is a different category to drawings, paintings and literature. One is about shared, objective, precise understanding of a problem. The other is about sharing subjective, emotional experiences; having the audience understand the work, much less everyone understand it the same way, is not required, usually not possible, and often undesirable.
It can't, and it won't, as long as we insist on always working directly on the "single source of truth", and representing it as plaintext code. It's just not sufficient to comprehensibly represent all concerns its consumers have at the same time. We're stuck in endless fights about what is cleaner or more readable or more maintainable way of abstracting / passing errors / sizing functions / naming variables... and so on, because the industry still misses the actual answer: it depends on what you're doing at the moment. There is no one best representation, one best function size. In fact, one form may be ideal for you now, and the opposite of it may be ideal for you five minutes later, as you switch from e.g. understanding the module to debugging a specific issue in it.
We've saturated the expressive capability of our programming paradigm. We're sliding back and forth along the Pareto frontier, like a drunkard leaning against a wall, trying to find their way back to a pub without falling over. No, inventing even more mathematically complex category of magic monads won't help, that's just repackaging complexity to reach a different point on the Pareto frontier.
Hint: in construction, there is never one blueprint everyone works with. Try to fit all information about geometry, structural properties, material properties, interior arrangement, plumbing, electricity, insulation, HVAC, geological conditions, hydrological conditions, and tax conditions onto a single flat image, and... you'll get a good approximation of what source code looks like in programming as it is today.