3 ms·

> C lacks mechanisms to do this apart from using its incredibly brittle macro facility. We programmers are the ultimate abstraction mechanism, and refining our

> C lacks mechanisms to do this apart from using its incredibly brittle macro facility. We programmers are the ultimate abstraction mechanism, and refining our techniques in pattern design and implementation in a codebase is our highest form of art. The list of patterns in the Gang-of-Four's "Design Patterns" are not as interesting as its first 50 pages, which are seminal. From the organization of files in a project, to organization of projects, to class structure and use, to function design, to debug output, to variable naming as per scope, to commandline argument specification, to parsing, it's nothing but patterns upon patterns. You're either doing patterns or you're doing one-offs, and one-offs are more brittle than C macros, are hard to comprehend later, and when you fix a bug in one, you've only fixed one bug, not an entire class of bugs. Abstraction is the essense of programming, and abstraction is just pattern design and implementation in a codebase, the design of a functional block and how it's consumed over time. The layering of abstractions is the most fundamental perspective on a codebase. They not only handle scale, they make or break correctness, ease of malleability, bug triage, performance, and comprehendability -- I'm sure I could find more. The design of the layering of abstractions is the everything of a codebase. The success of C's ability to let programmers create layers of abstractions is why C is the foundational language of the OS I'm using, as well as the browser I'm typing this message in. I'm guessing you are, too, and, while I could be wrong, it's not likely. And not a segfault in sight. The scale of Unix is unmatched.

kllrnohj 1y ago
> The success of C's ability to let programmers create layers of abstractions is why C is the foundational language of the OS I'm using, as well as the browser I'm typing this message in. What browser are you using that has any appreciable amount of C in it? They all went C++ ages ago because it has much better abstraction and organization capabilities.
- MrMcCall 1y ago
  That's a fair point that I hadn't considered. I was developing C+objects as C++ was first being released in the mid-90s, and then using Borland's C++ compiler in the early 2000s, but never really thought about it as anything more than what its name implies: "C with some more abstractions on top of it". Thank you for the correction, but I consider C++ to be just a set of abstractions built upon C, and, if you think about it, and none of those structures are separate from C, but merely overlaid upon it. I mean it is still just ints, floats, and pointers grouped using fancier abstractions. Yes, they're often nicer and much easier to use than what I had to do to write a GUI on top of extended DOS, but it's all just wrappers around C, IMO.
  - kllrnohj 1y ago
    C++ is very definitely not just wrappers around C and it's pretty ridiculous to frame it like that. Or if you want to insist on that, then C doesn't exist, either, as it's just a few small abstractions over assembly.
pjc50 1y ago
> The success of C's ability to let programmers create layers of abstractions You wrote several entirely valid paragraphs about how important abstractions are and then put this at the end, when C has been eclipsed by 40+ years of better abstractions.
- MrMcCall 1y ago
  Because programmers are creating the abstractions, not the programming language. And there is no OS I'm aware of that will threaten Unix's dominance any time soon. I'm not against it, but C's being so close to what microprocessors actually do seems to be story of of its success, now that I think about it. I personally haven't written in C for more than a half-decade, preferring Python, but everything I do in Python could be done in C, with enough scaffolding. In fact, Python is written in C, which makes sense because C++ would introduce too many byproducts to the tightness required of it. I was programming C using my own object structuring abstractions as C++ was being developed and released. It can be done, and done well (as evidenced by curl), but it just requires more care, which comes down to the abstractions we choose. So, I would say "eclipsed" is a bit strong a sentiment, especially given our newly favorite programming langauges are running on OSes written in C. If I had my druthers, I'd like everything to be F# with native compilation (i.e. not running using the .NET JIT), or OCaml with a more C-ish style of variable instantiation and no GC. But the impedance mismatch likely makes F# a poor choice for producing the kinds of precise abstractions needed for an OS, but that's just my opinion. Regardless, the code that runs runs via the microprocessor so the question really is, "What kinds of programming abstractions produce code that runs well on a microprocessor." I've never thought of this before, thanks for the great question.
  - pjc50 1y ago
    > there is no OS I'm aware of that will threaten Unix's dominance any time soon True, but irrelevant? > What kinds of programming abstractions produce code that runs well on a microprocessor .. securely. Yes, this can be done in C-with-proofs (sel4), but the cost is rather high. To a certain extent microprocessors have co-evolved with C because of the need to run the same code that already exists. And existing systems force new work to be done with C linkage. But the ongoing CVE pressure is never going to go away.

kllrnohj 1y ago

> The success of C's ability to let programmers create layers of abstractions is why C is the foundational language of the OS I'm using, as well as the browser I'm typing this message in. What browser are you using that has any appreciable amount of C in it? They all went C++ ages ago because it has much better abstraction and organization capabilities.

MrMcCall 1y ago
That's a fair point that I hadn't considered. I was developing C+objects as C++ was first being released in the mid-90s, and then using Borland's C++ compiler in the early 2000s, but never really thought about it as anything more than what its name implies: "C with some more abstractions on top of it". Thank you for the correction, but I consider C++ to be just a set of abstractions built upon C, and, if you think about it, and none of those structures are separate from C, but merely overlaid upon it. I mean it is still just ints, floats, and pointers grouped using fancier abstractions. Yes, they're often nicer and much easier to use than what I had to do to write a GUI on top of extended DOS, but it's all just wrappers around C, IMO.
- kllrnohj 1y ago
  C++ is very definitely not just wrappers around C and it's pretty ridiculous to frame it like that. Or if you want to insist on that, then C doesn't exist, either, as it's just a few small abstractions over assembly.

pjc50 1y ago

> The success of C's ability to let programmers create layers of abstractions You wrote several entirely valid paragraphs about how important abstractions are and then put this at the end, when C has been eclipsed by 40+ years of better abstractions.

MrMcCall 1y ago
Because programmers are creating the abstractions, not the programming language. And there is no OS I'm aware of that will threaten Unix's dominance any time soon. I'm not against it, but C's being so close to what microprocessors actually do seems to be story of of its success, now that I think about it. I personally haven't written in C for more than a half-decade, preferring Python, but everything I do in Python could be done in C, with enough scaffolding. In fact, Python is written in C, which makes sense because C++ would introduce too many byproducts to the tightness required of it. I was programming C using my own object structuring abstractions as C++ was being developed and released. It can be done, and done well (as evidenced by curl), but it just requires more care, which comes down to the abstractions we choose. So, I would say "eclipsed" is a bit strong a sentiment, especially given our newly favorite programming langauges are running on OSes written in C. If I had my druthers, I'd like everything to be F# with native compilation (i.e. not running using the .NET JIT), or OCaml with a more C-ish style of variable instantiation and no GC. But the impedance mismatch likely makes F# a poor choice for producing the kinds of precise abstractions needed for an OS, but that's just my opinion. Regardless, the code that runs runs via the microprocessor so the question really is, "What kinds of programming abstractions produce code that runs well on a microprocessor." I've never thought of this before, thanks for the great question.
- pjc50 1y ago
  > there is no OS I'm aware of that will threaten Unix's dominance any time soon True, but irrelevant? > What kinds of programming abstractions produce code that runs well on a microprocessor .. securely. Yes, this can be done in C-with-proofs (sel4), but the cost is rather high. To a certain extent microprocessors have co-evolved with C because of the need to run the same code that already exists. And existing systems force new work to be done with C linkage. But the ongoing CVE pressure is never going to go away.