The natural argument against this is of course that separation is an illusion. I don’t say that to sound mysterious, I mean that just in the simple way that everything is tangled up together, dependent on each other for its existence, and its only in our models that clean separation can exist, and then only by ignore some parts of reality in order to keep our models clean.
As a working programmer, I’m very familiar with the original context of the idea of separation of concerns, and I can also tell you that even there is never totally works. It’s a tool we use to help us poor humans who can’t fathom the total, complete, awesome complexity of the world to get along well enough anyway to collect a paycheck. Or something like that.
Relatedly, every abstraction is leaky, and if you think it isn’t you just haven’t looked hard enough.
None of that is to say we shouldn’t respect the separation of concerns when useful, but also that we shouldn’t elevate it more than it deserves to be, because the separation is a construction of our minds, not a natural feature of the world.
Responding to this on the point of feelings/bids/etc:
One problem I run into a lot is that I want to just say X, but it’s fo freakin’ difficult to do so without also accidentally saying Y. The default solution is to put a boatload of effort into crafting what I’m saying to evoke the correct response in the other person, but this is difficult and failure-prone. So if we don’t go that route, in order to communicate what I mean to communicate and not also something else, it takes some cooperation between both parties — I promise that I just mean what I’m saying, and not other possibly-inferable implications, and the other party agrees to take what I say at face value. (And if any implications come up that seem important, assume they aren’t attempts at manipulation, by default, and ask about them directly if you want to know what they think of that unsaid thing)
Actually doing that is difficult for both parties, but when both give it a good effort it enables some things that are super difficult to communicate otherwise, and I suspect doing this frequently makes it much easier with practice.
This approach seems to assume that can create the message that you want to send from a blank slate. Plenty of times you can’t communicate what you want to communicate because what you want to communicate isn’t really true and it’s easy for the other party to see that.
That seems to be an argument that if the program works on my machine it should also work elsewhere. In reality there’s often some weird quirk that means that the abstrations that the program uses don’t generalize everywhere the same way.
But the point I was after everykind of separation we make it will in the end be undone. In that integration the leakyness will make itself apparent.
If you have a reference implementation then your “rule” can’t leak because the code just is what it is. What would be a bug or inconsistency can be redefined to be a feature. But any kind of spesification that is not an instantiation doesn’t contain enough information to construct an instantation yet programs are instances thus instances contain more information than the abstract rules.
The natural argument against this is of course that separation is an illusion. I don’t say that to sound mysterious, I mean that just in the simple way that everything is tangled up together, dependent on each other for its existence, and its only in our models that clean separation can exist, and then only by ignore some parts of reality in order to keep our models clean.
As a working programmer, I’m very familiar with the original context of the idea of separation of concerns, and I can also tell you that even there is never totally works. It’s a tool we use to help us poor humans who can’t fathom the total, complete, awesome complexity of the world to get along well enough anyway to collect a paycheck. Or something like that.
Relatedly, every abstraction is leaky, and if you think it isn’t you just haven’t looked hard enough.
None of that is to say we shouldn’t respect the separation of concerns when useful, but also that we shouldn’t elevate it more than it deserves to be, because the separation is a construction of our minds, not a natural feature of the world.
Responding to this on the point of feelings/bids/etc:
One problem I run into a lot is that I want to just say X, but it’s fo freakin’ difficult to do so without also accidentally saying Y. The default solution is to put a boatload of effort into crafting what I’m saying to evoke the correct response in the other person, but this is difficult and failure-prone. So if we don’t go that route, in order to communicate what I mean to communicate and not also something else, it takes some cooperation between both parties — I promise that I just mean what I’m saying, and not other possibly-inferable implications, and the other party agrees to take what I say at face value. (And if any implications come up that seem important, assume they aren’t attempts at manipulation, by default, and ask about them directly if you want to know what they think of that unsaid thing)
Actually doing that is difficult for both parties, but when both give it a good effort it enables some things that are super difficult to communicate otherwise, and I suspect doing this frequently makes it much easier with practice.
This approach seems to assume that can create the message that you want to send from a blank slate. Plenty of times you can’t communicate what you want to communicate because what you want to communicate isn’t really true and it’s easy for the other party to see that.
If your code compiles into one program it’s literallly one system.
That seems to be an argument that if the program works on my machine it should also work elsewhere. In reality there’s often some weird quirk that means that the abstrations that the program uses don’t generalize everywhere the same way.
I would count that as compiling in to two things.
But the point I was after everykind of separation we make it will in the end be undone. In that integration the leakyness will make itself apparent.
If you have a reference implementation then your “rule” can’t leak because the code just is what it is. What would be a bug or inconsistency can be redefined to be a feature. But any kind of spesification that is not an instantiation doesn’t contain enough information to construct an instantation yet programs are instances thus instances contain more information than the abstract rules.