i've cultivated the perception of what op calls design pressure my whole career as the primary driver behind code and her shape. i think it's the most important aspect of a successful architecture, and it's purely intuition based, which is also why there's no silver bullet. i've seen people take most well intended best practices and drive them into the ground because they lack the design pressure sense.
i believe that design pressure sense is a form of taste, and like taste it needs to be cultivated, and that is can't be easily verbalized or measured. you just know that your architecture is going to have advantageous properties, but to sit down and explain why will take inordinate amount of effort. the goal is to be able to look at the architecture and be able to see its failure states as it evolves through other people working with it, external pressures, requirement changes, etc. over the course of 2, 3, ... 10, etc. years into the future. i stay in touch with former colleagues from projects where i was architect, just so that i can learn how the architecture evolved, what were the pain points, etc.
i've met other architects who have that sense, and it's a joy to work with them, because it is vibing. conversly "best practices or bust" sticklers are insufferable. i make sure that i don't have to contend with such people.
Zen and Art of Motorcyle maintenance is a good reference.
Also, it is good to remember what game is actually being played. When someone comes up with a popularizes a given "best practice", why are they doing so? In many cases, Uncle Bob types are doing this just as a form of self promotion. Most best practices are fundamentally indefensible with proponents resorting to ad-hominem attacks if their little church is threatened.
Code is for communicating with humans primarily, even though it needs to be run on a machine. All the patterns, principles, and best practices is to ease understanding and reasoning by other people, including your future self. Flexibility is essential, but common patterns and shared metaphors work wonders.
That's terribly short sighted. You can have a very clear architecture and code which cannot support the use cases required without almost starting from scratch.
You can also have the most flexible system ever designed, but if the rest of your team doesn't understand it then good luck implementing that required use cases
Sure, both extremes are shortsighted. I wasn't arguing for that, to be clear. I'm just saying clarity and ivory tower architecturing has little value if your system can't actually support the intended use case.
Which is what the person I was replying to said with "Code is for communicating with humans primarily, even though it needs to be run on a machine.". If the primary purpose is communication with other humans we wouldn't choose such awkward languages. The primary purpose of code is to run and provide some kind of features supporting use cases. It's really nice however if humans can understand it well.
That aphorism is completely incorrect. Code is primarily for communicating with a machine. If the purpose was to communicate with humans, we'd use human languages. Lawyers do that.
The code does also need to be understandable by other humans, but that is not its primary purpose.
So why do we have Java, Kotlin, Scala, Groovy, and Clojure, all targeting the JVM? And many such families?
The only thing that matter to the machine is opcodes and bits, But that's alien to human, so we map it to assembly. Any abstractions higher than that is mostly for reasoning about the code and share that with other people. And in the process we find some very good abstractions which we then embed into programming languages like procedure, namespacing, OOP, patterns matching, structs, traits/protocols,...
All these abstractions are good because they are useful when modeling a problem. The some are so good then it's worth writing a whole VM to get them (lisp homoiconicity, smalltalk's consistent world representation,...)
To allow you to write more readable and extensible code, that can solve real problems more effectively. Solving problems is the point of writing code.
Saying that reading code is the point of writing code is crazy, that's like saying the point of writing scripts is to read them, or the point of writing sheet music is to look at it.
No - the point of writing a script is to have it performed as a play, the point of writing music is to hear it and enjoy it. The point of writing code is to run it.
> All these abstractions are good because they are useful when modeling a problem.
Then what do you do after modeling the problem? You solve it! You run the program! Everything is in service to that.
No one does it in isolation. The goal of having a common formal notation is for everyone to share solution unambiguously with each other. We have mathematical notation, choreographic notation, music notation, electric notation,... because when you've created something, you want to share it as best as possible to others. If not, you could just ship the end result and be done with it.
So no the point of writing music is not to hear it and enjoy it. To do so you just find an instrument and perform. You do not to do anything else. But to have someone else to do it, you can rely on their ear, their sights and their memory to pick things up. Or you just use the common notation to exchange the piece of music.
Because a secondary goal of code is communication with other humans. That means readability is still a highly valuable trait. Just not as valuable as the primary purpose.
I'd say code is a machine. Even code in a high-level language. Code machine is somewhat special because its details look like words. This misleads us into believing we can reason with these words. We cannot. We can use them to make the machine itself, but the only way to explain how it works is to write a normal technical description and the normal way to understand it should begin with reading that description. (There's no standard for a normal technical description though.)
While you are obviously right about it not being the primary purpose, here it seems the discussion is about designing for long term maintainability vs just running code.
The person he replied said code is primarily for communicating with other people. I'm not sure how else to interpret that than what is literally written down.
Human language is imperfect: they never said "other" people, but just "humans" (this includes oneself, for example).
So you are already not interpreting it literally: none of us can avoid our biases (also, machine code is code too, yet nobody misinterpreted that).
I took that quote to mean that we go through the extra trouble of writing nice code for humans to be able to reason about the code, and especially to update when changes are needed: that makes it the primary reason we invent programming languages instead of going with machine code directly.
You than take primarily to not mean primarily. I mean sure you can do that, I don't find it very convincing. It's possible they misspoke(or wrote) but that's not really the fault of the person reacting to what they said.
This reminds me of the concept of “forces” [0][1][2] in design-pattern descriptions. To decide for or against the use of a given design pattern, or to choose between alternative design patterns, one has to assess and weigh the respective forces in the particular context where it is to be used. They are called forces because they collectively pull the design in a certain direction. Just a different physics analogy versus “pressure”.
