Here's a really dumbed-down illustration of how I understand intentional fallacy. After the TV show Lost ended, the creators explained in interviews details like why the characters had to repeatedly enter a series of numbers into a computer terminal. But neither that reason nor the significance of the numbers was ever explained in the show. The reason (intent) is not available within the show and cannot be determined from the work of art. Even if you knew exactly what the writers were thinking, it doesn't count.
My biggest fear with this post was that there was a connection to be drawn, but that whatever point I made would be inarticulate. I think the nuance you and Valentin touched on above is really important to get across, and in trying to tie everything all together I think the post missed that (here I am, trying to explain my intent though :D). If I had another chance, I would put it this way: the intent of the code at a top level (the contract, the API, etc.) should be easily divinable and is definitely important. Down from there, code should still be as clear as possible, but the intentions of the implementation are less important than the intentions of the contract. The costs there are lower: maybe a refactor makes it less efficient or has some smaller effect, but it has less chance of breaking a downstream piece of code if you change some implementation detail. As the choices get more granular, the more likely it is that the intent behind the choice isn't relevant (or maybe doesn't exist). Yes, for sure, at a certain level intent is clear and matters, but at the level at which I have seen friends struggle to make changes, at the implementation choices level, I think it starts to matter less (unless we're talking about a major architectural choice). That being said, I was mostly just trying to draw the connection and start a conversation, and I totally see where you're coming from.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Here's a really dumbed-down illustration of how I understand intentional fallacy. After the TV show Lost ended, the creators explained in interviews details like why the characters had to repeatedly enter a series of numbers into a computer terminal. But neither that reason nor the significance of the numbers was ever explained in the show. The reason (intent) is not available within the show and cannot be determined from the work of art. Even if you knew exactly what the writers were thinking, it doesn't count.
My biggest fear with this post was that there was a connection to be drawn, but that whatever point I made would be inarticulate. I think the nuance you and Valentin touched on above is really important to get across, and in trying to tie everything all together I think the post missed that (here I am, trying to explain my intent though :D). If I had another chance, I would put it this way: the intent of the code at a top level (the contract, the API, etc.) should be easily divinable and is definitely important. Down from there, code should still be as clear as possible, but the intentions of the implementation are less important than the intentions of the contract. The costs there are lower: maybe a refactor makes it less efficient or has some smaller effect, but it has less chance of breaking a downstream piece of code if you change some implementation detail. As the choices get more granular, the more likely it is that the intent behind the choice isn't relevant (or maybe doesn't exist). Yes, for sure, at a certain level intent is clear and matters, but at the level at which I have seen friends struggle to make changes, at the implementation choices level, I think it starts to matter less (unless we're talking about a major architectural choice). That being said, I was mostly just trying to draw the connection and start a conversation, and I totally see where you're coming from.