3 ms·
> Note then that there's an inherent conflict in programming language design space between introducing too many abstraction building tools and low-level details
by DeathArrow 4y ago
> Note then that there's an inherent conflict in programming language design space between introducing too many abstraction building tools and low-level details.
Best C++ code that deals with low level details is as least abstracted as possible.
One of the reasons C is used for writing operating systems kernels is that it doesn't hide details. Imagine Linux kernel written in OOP way with design patterns and SOLID principles. :)
- staunton 4y ago> Imagine Linux kernel written in OOP way with design patterns and SOLID principles. Doesn't sound that terrible to me. Just out of interest, do you think `*(int*)(0x12345678) = 0;` is the best way to do memory-mapped IO? That's least abstracted.
- maldev 4y agoHave you ever written low level code? There's constant hardcoded addresses you have to deal with which are in the spec. You can't really do BIOS, UEFI, Bootloder, Systems programming, ... without it. You wouldn't do a "magic number" and would make it a macro. But *SCREENBUFFER = 0;
- staunton 4y agoYes, my point being that the macro in this case is an "abstraction", and we were discussing GP's claim "all abstractions bad" (i.e., to quote them, low level code should be "as least abstracted as possible"). Was it really not clear what I meant? I've actually encountered seasoned embedded devs advocating using the magic number in this very case. Never really understood why. It was some combination of "abstractions bad" and "I want to be able to check all adresses against my printed dead-tree documents while debugging "... Of course noone really believes "all abstractions bad", but I wonder why some people still claim that.
- pjmlp 4y agoC is used because of UNIX, it hides plenty of details.