undefined | Better HN

0 pointsjenadine3y ago0 comments

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.

0 comments

3 comments · 2 top-level

badpun3y ago· 1 in thread

> 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.

jenadineOP3y 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".

dsego3y 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.

j / k navigate · click thread line to collapse