I think one of the less appreciated corollaries of Chesterton's line of thought, is that we should be wary of building fences in the first place. In programming, I think that abstraction should be avoided until the need for it arises. On the first pass (or two or three), a program should be written clearly and simply and only do what it needs to. Working with many abstractions in software can be very difficult later and it can be especially hard if it turns out the original abstractions are the wrong ones in hindsight. Because later Chesterton will apply and people will try to shoehorn their new work into the existing abstractions instead of taking a step back and realizing that they would never be there in that form if the abstractions were designed today.
There's no silver bullet with anything in life, but something to keep in mind.
I think one of the less appreciated corollaries of Chesterton's line of thought, is that we should be wary of building fences in the first place
Would that change anything?
Assume the original author did think about whether it was necessary, and they thought it was. You know have to think whether the fence is still necessary.
Now assume the original author didn't think. You still have to think about whether the fence is necessary.
Would it change anything? Uh...of course? If you build fewer fences it will result in fewer fences. I'm not really sure what confuses you.
Unless your point is whether not building as many fences now will save you from Chesterton's reasoning for any fences already built, then well of course not.
Changing the metaphor, I'm just saying that you should consider stretching to avoid future injury. Of course that doesn't save you from dealing with injuries that have resulted due to a lack of stretching in the past.
If you build fewer fences it will result in fewer fences.
Chesterton's Fence only applies to removing existing fences, so it obviously only applies to fences that already exist. It doesn't say anything about whether or not you should build the fence in the first place.
> Chesterton's Fence only applies to removing existing fences, so it obviously only applies to fences that already exist. It doesn't say anything about whether or not you should build the fence in the first place.
I'm also really having trouble understanding why it's so complicated for you to understand. Chesterton's fence says you shouldn't remove a fence until you understand why it's there. Ergo the removal of a fence requires effort. Ergo you should not put up fences unless provide actual value, because they will require effort to remove later.
Regardless, Chesterton's fence is a principle with whatever wisdom one chooses to draw from it. I guess if you disagree with me it doesn't really matter.
Software Engineering has been blessed, over the course of the past several decades, by exponential increases in available resources (Moore’s Law et simila). This has somewhat offset the inherent laziness that the author speaks of in his essay, in that while it requires effort to implement a feature (or an abstraction, is your case), but thereafter the increase in processing power essentially rapidly makes the performance penalty ‘free’. Now that Moore’s Law seems to be slowing down somewhat (though maybe that was just Intel’s monopoly position in CPUs showing, as AMD’s recent releases and the unending growth of GPU and ARM performance suggests), implementing additional features that carry a performance penalty will entail considering the effects of that slowdown in perpetuity, and therefore will be (hopefully) taken into account.
I’m not saying that people will revert to writing assembler onto the metal, but perhaps the whole trend of VMs inside VMs on dockers on compartmentalised OSes will slow down.
Honestly I didn't even consider the abstractions as a problem due to performance penalties in the vast majority of cases. I consider the abstractions a problem due to their cognitive penalty and the fact that you often need to put a square peg in a round hole (which requires a cognitive load both initially and in maintenance) due to incorrect abstractions. The fact that automatic optimizations (e.g. compilers) may get rid of these abstractions' performance costs doesn't mean their cognitive costs are removed.
I agree we shouldn't necessarily be writing in assembler, but we should be cautious of over-generalization. A math professor I had once said you should study problems in the right generality and no more. I think that software is the same. Abstractions have a cognitive cost and they are often not apparent until they are taken together. Keeping design simple and focused is a way to try to avoid those costs.
There's no silver bullet with anything in life, but something to keep in mind.