4 ms·

> Being "difficult to understand" is a perspective of an individual observer, not some fundamental property of the thing itself. I disagree. There are inherent

by lwhi 5y ago

> Being "difficult to understand" is a perspective of an individual observer, not some fundamental property of the thing itself. I disagree. There are inherent qualities associated with systems that happen to be easier to understand. If you or I were designing such a system, and wanted to ensure this system imbued similar qualities — I believe it would be possible to do so. > Japanese is "difficult to understand" if you only know English, but not if you grew up speaking Japanese. Needing a priori knowledge to be able to understand something, is different.

Karrot_Kream 5y ago
> I disagree. There are inherent qualities associated with systems that happen to be easier to understand. If you or I were designing such a system, and wanted to ensure this system imbued similar qualities — I believe it would be possible to do so. Can you formalize these inherent qualities? Until you can, it's hard to prove that a quality is or is not essential.
- TeMPOraL 5y ago
  > Can you formalize these inherent qualities? Until you can, it's hard to prove that a quality is or is not essential. There is an obvious one, though it's tricky to fully formalize and quantify: locality (also known as "coupling"). You ask yourself a question, "if I were to make a small change to a single piece of this program, how much of the program would I have to change/retest/keep in mind?". If the answer is, "typically, just the area around the change", it's a high locality (loosely coupled) program, a good design. If the answer is, "usually, most/all of it", then it's low locality (tight coupling), a bad design. The reason is, of course, that human mental capacity is limited and in general, number of interactions grows superlinearly with the amount of interacting components. So this here is an objective measure of "easy/hard to understand": the more code you have to keep track of when investigating a random piece of the program, the more mental effort you have to exert - the more difficult to understand it is.

by lwhi 5y ago

Karrot_Kream 5y ago

> I disagree. There are inherent qualities associated with systems that happen to be easier to understand. If you or I were designing such a system, and wanted to ensure this system imbued similar qualities — I believe it would be possible to do so. Can you formalize these inherent qualities? Until you can, it's hard to prove that a quality is or is not essential.

TeMPOraL 5y ago
> Can you formalize these inherent qualities? Until you can, it's hard to prove that a quality is or is not essential. There is an obvious one, though it's tricky to fully formalize and quantify: locality (also known as "coupling"). You ask yourself a question, "if I were to make a small change to a single piece of this program, how much of the program would I have to change/retest/keep in mind?". If the answer is, "typically, just the area around the change", it's a high locality (loosely coupled) program, a good design. If the answer is, "usually, most/all of it", then it's low locality (tight coupling), a bad design. The reason is, of course, that human mental capacity is limited and in general, number of interactions grows superlinearly with the amount of interacting components. So this here is an objective measure of "easy/hard to understand": the more code you have to keep track of when investigating a random piece of the program, the more mental effort you have to exert - the more difficult to understand it is.