3 ms·

I totally agree with you on the fact that for a skilled engineer good code does not comes with a bigger cognitive load (nor time spent). But I would like to cha

I totally agree with you on the fact that for a skilled engineer good code does not comes with a bigger cognitive load (nor time spent). But I would like to challenge your point on writing maintainable and understandable code. One can argue that writing maintainable code following the best practices it's just a set of conventions that are useful just because we have no better solution right now. It's a solution that works but can be very well be improved for instance by removing the needs of writing code in the first place (ie: with some very advanced level of code generation). About the understanding bit I usually look at tests for understanding code, it's easier for me to read an English statement that tells me what a things does rather then trying to understand it starting from how the problem has been solved in details. Code is for machines, "it should do this" is for humans.

lolc 6y ago
> it's just a set of conventions that are useful just because we have no better solution right now. Every profession has conventions on how their solutions are expressed. Go against the convention, and you'll make us work harder to understand you. This is not appreciated. If you want to establish a new convention, show us how yours is better.
kingdomcome50 6y ago
Surely one must actually improve upon the current conventions before dismissing them, no? Similarly the field is called computer science. Not every convention an engineer follows is simply because "we have yet to find a better one". I can certainly agree that the landscape has and will continue to change over time, but there are some truths when it comes to designing systems. As for gleaning understanding, tests are useful for learning "what" a system is meant to do, but wholly meaningless when we need to know "how". Often the latter becomes the important bit when we need to extend/modify code. I agree that there is a balance to be had. Not every LoC or module needs to be perfect. It's often more important (and practical) to choose a suitable level of abstraction, and make sure that the code at that level has an amount of agreed upon standardization.
nyberg 6y ago
Code is a medium for communication of concepts and solutions between humans first and for the machine second. Code generation input still requires a specification which is the code you feed into the inference engine even if it's of a higher abstraction than the generated output. In the end you're still stuck with code regardless and someone has to understand how it acomplishes what it does. Now I can agree that having decent documentation or even literate programming [1][2] contribute in large to understanding but it's never a replacement for clean and maintainable code. It's the same as architecture where if you're sloppy with the designing a bridge it can (and often will) come crashing down resulting in high expenses and lives lost over something that could have been prevented had others been able to understand the design and question the practices. The same applies to code. [1]: https://cs61.seas.harvard.edu/site/pdf/p384-bentley.pdf https://cs61.seas.harvard.edu/site/pdf/p384-bentley.pdf [2]: https://jhidding.github.io/adhesion-code/ https://jhidding.github.io/adhesion-code/

lolc 6y ago

> it's just a set of conventions that are useful just because we have no better solution right now. Every profession has conventions on how their solutions are expressed. Go against the convention, and you'll make us work harder to understand you. This is not appreciated. If you want to establish a new convention, show us how yours is better.

kingdomcome50 6y ago

Surely one must actually improve upon the current conventions before dismissing them, no? Similarly the field is called computer science. Not every convention an engineer follows is simply because "we have yet to find a better one". I can certainly agree that the landscape has and will continue to change over time, but there are some truths when it comes to designing systems. As for gleaning understanding, tests are useful for learning "what" a system is meant to do, but wholly meaningless when we need to know "how". Often the latter becomes the important bit when we need to extend/modify code. I agree that there is a balance to be had. Not every LoC or module needs to be perfect. It's often more important (and practical) to choose a suitable level of abstraction, and make sure that the code at that level has an amount of agreed upon standardization.

nyberg 6y ago

Code is a medium for communication of concepts and solutions between humans first and for the machine second. Code generation input still requires a specification which is the code you feed into the inference engine even if it's of a higher abstraction than the generated output. In the end you're still stuck with code regardless and someone has to understand how it acomplishes what it does. Now I can agree that having decent documentation or even literate programming [1][2] contribute in large to understanding but it's never a replacement for clean and maintainable code. It's the same as architecture where if you're sloppy with the designing a bridge it can (and often will) come crashing down resulting in high expenses and lives lost over something that could have been prevented had others been able to understand the design and question the practices. The same applies to code. [1]: https://cs61.seas.harvard.edu/site/pdf/p384-bentley.pdf https://cs61.seas.harvard.edu/site/pdf/p384-bentley.pdf [2]: https://jhidding.github.io/adhesion-code/ https://jhidding.github.io/adhesion-code/