4 ms·

I disagree. Many abstraction makes it easier to read for human. Example, the first abstraction is to use functions, if/else, and loops instead of plain goto eve

I disagree. Many abstraction makes it easier to read for human. Example, the first abstraction is to use functions, if/else, and loops instead of plain goto everywhere like the CPU like. Now abstraction also have a cost that needs to be kept under control. (Some have zero costs, some have compile-time costs, some have different level of run-time costs) And of course, not every abstraction is a good one: Sometimes it can even be counter productive to hide details if these details are simpler than the abstraction itself. In summary, it's all about trade-offs and not over-doing it.

dsego 4y ago
> Many abstraction makes it easier to read for human. Many abstractions are also conventions, just look at the js/react world. There is redux stores, mobx stores, hooks, class-based components, signals. All different abstractions with various performance and readability concerns. Someone used to one of them would say the others are not readable or maintainable. So maybe we can choose the more performant abstractions and teach them, so it becomes institutional knowledge.
badpun 4y ago
> Example, the first abstraction is to use functions, if/else, and loops instead of plain goto everywhere like the CPU like. CPU likes if/else and loops just as much as it like its gotos. If/else and loops are just conditional jump (with a comparison done before the jump), and gotos are uncoditional jumps. Both are very much machine code constructs, that's why they're in C (which is basically a syntactic sugar over assembly). Function calls are slightly more involved, but basically also very, very low level.
- jenadine 4y ago
  you don't write if (!condition) goto else_; // some code goto endif; else_: // the else block endif: // More code Same for loop. That's what we mean by "goto considered harmful".

dsego 4y ago

> Many abstraction makes it easier to read for human. Many abstractions are also conventions, just look at the js/react world. There is redux stores, mobx stores, hooks, class-based components, signals. All different abstractions with various performance and readability concerns. Someone used to one of them would say the others are not readable or maintainable. So maybe we can choose the more performant abstractions and teach them, so it becomes institutional knowledge.

badpun 4y ago

> Example, the first abstraction is to use functions, if/else, and loops instead of plain goto everywhere like the CPU like. CPU likes if/else and loops just as much as it like its gotos. If/else and loops are just conditional jump (with a comparison done before the jump), and gotos are uncoditional jumps. Both are very much machine code constructs, that's why they're in C (which is basically a syntactic sugar over assembly). Function calls are slightly more involved, but basically also very, very low level.

jenadine 4y ago
you don't write if (!condition) goto else_; // some code goto endif; else_: // the else block endif: // More code Same for loop. That's what we mean by "goto considered harmful".