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.

Note then that there's an inherent conflict in programming language design space between introducing too many abstraction building tools and low-level details. It is very hard to make things truly orthogonal. E.g. memory and resource management tends to spill all over the code, with the other example being error handling. And once a language designer adds ways (and a programmer culture) to hide things - it becomes very hard to follow the code. Zig attacks this design space from a low abstraction and explicit flow point of view.

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 ago
    Have 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 ago
      Yes, 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 ago
  C is used because of UNIX, it hides plenty of details.
auggierose 4y ago
Yes, I agree that there is this tension that no single "programming language" can resolve. That is why we don't need programming languages, but systems for building abstractions. But as long as we don't have those systems, I prefer programming languages that let me build proper abstractions.
- still_grokking 4y ago
  Programming languages are systems for building abstractions. At least the proper ones.

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 ago
  Have 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 ago
    Yes, 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 ago
C is used because of UNIX, it hides plenty of details.

auggierose 4y ago

Yes, I agree that there is this tension that no single "programming language" can resolve. That is why we don't need programming languages, but systems for building abstractions. But as long as we don't have those systems, I prefer programming languages that let me build proper abstractions.

still_grokking 4y ago
Programming languages are systems for building abstractions. At least the proper ones.