4 ms·

> Code should be easy to read. It should be clear. No hiding code under clever constructs, fancy macros or overloading. I highly agree with this. I do not alwa

> Code should be easy to read. It should be clear. No hiding code under clever constructs, fancy macros or overloading. I highly agree with this. I do not always want highly abstracted code, and some programming languages aiming to replace C are much more difficult to read, that said, Rust is supposed to replace C++, not C, right? Thank you for the article!

MrMcCall 2y ago
The reality is that we spend FAR more time reading code than writing it. That is why readability is far more important than clever, line saving constructs. The key to further minimizing the mental load of reacquainting yourself with older existing code is to decide on a set of code patterns and then be fastidious in using them. And then, if you want to want to be able to easily write a parser for your own code (without every detail in the spec), it's even more important. And now that I have read TFA, I see he wrote: > We have tooling that verify basic code style compliance. His experience and dilligence has led him to the mountaintop, that being we must make ourselves mere cogs in a larger machine, self-limiting ourselves for the greater good of our future workload and production quality.
- johnisgood 2y ago
  > That is why readability is far more important than clever, line saving constructs. Yes, I agree, that is why I am put off by some supposed C replacements that are trying to be clever with their abstractions or constructs.
  - MrMcCall 2y ago
    Simplicity is essential to achieving managable complexity over time.
    - kryptiskt 2y ago
      Abstraction is necessary to handle scale. If you have painstakingly arrived at a working solution for a complex problem like say locking, you want to be able to package it up and use it throughout your codebase. C lacks mechanisms to do this apart from using its incredibly brittle macro facility.
      - johnisgood 2y ago
        Ada has built-in constructs for concurrency, with contracts, and there is formal verification in a subset of Ada named SPARK, so Ada / SPARK is pretty good.
      - MrMcCall 2y ago
        > 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 2y ago
  - pjc50 2y ago
    Could you give an example of "clever" (bad) vs "simple" (good)? In my experience C has a lot of simple grammar, a commonly-held simple (wrong) execution model, and a lot more complexity lurking underneath where it can't be so easily seen. (One of my formative learning books was https://en.wikipedia.org/wiki/C_Traps_and_Pitfalls https://en.wikipedia.org/wiki/C_Traps_and_Pitfalls , valid in the 90s and mostly still valid today)
- baumschubser 2y ago
  > The reality is that we spend FAR more time reading code than writing it. That is why readability is far more important than clever, line saving constructs. In JS sometimes chain two or three inline-arrow-functions specifically for readability. When you read code, you often search for the needle of "the real thing" in a haystack of data formatting, API response prepping, localization, exception handling etc. Sometimes those shorthand constructs help me to skip the not-so-relevant parts instead of mentally climbing down and up every sort and rename function. That being said, I would not want this sentiment formalized in code guidelines :) And JS is not C except both have curly braces.
  - MrMcCall 2y ago
    > That being said, I would not want this sentiment formalized in code guidelines :) Surely. I'm all for code formatting standards as long as they're MY code formatting standards :-) Ideally, I'd like the IDE to format the code to the user/programmer's style on open, but save the series of tokens to the code database in a formatting-agnostic fashion. Then we could each have our own style but still have a consistent codebase. And, I should add that my formatting conventions have gotten more extreme and persnickety over the years, and I now put spaces on both sides of my commas, because they're a separate token and are not a part of the expression on either side of it. I did this purely for readability, but I have NEVER seen anyone do that in all my decades on the internet reading code and working on large codebases. But I really like how spacing it out separates the expression information from the structural information. It also helps me deal with my jettisoning code color formatting, as, as useful as I've found it in the past, I don't want to deal with having to import/set all that environmental stuff in new environments. So, I just use bland vi with no intelligence, pushing those UI bells and whistles out of it into my code formatting. And, I fully endorse whatever it takes for you to deal with JS, as I have loathed it since it appeared on the scene, but that's just me being an old-school C guy.
Zambyte 2y ago
I have been playing around a lot with Zig lately, and though it's still in beta, it really feels like it has the best chance at being a true C successor. While Rust feels like they started with C++ and worked on making it harder to write incorrectly, Zig feels like they started with C and worked on making it easier to write correctly. They also have a few pillars that they call the "Zen" of Zig[0], of which three out of the first five are directly related to readability. [0] https://ziglang.org/documentation/0.14.0/#Zen https://ziglang.org/documentation/0.14.0/#Zen
- voidUpdate 2y ago
  I really want to start trying to learn zig, but right now I feel like it's not quite finished enough. When it hits 1.0, I'll probably give it a more serious look
  - woodrowbarlow 2y ago
    Zig is friendly for soft-transitions because the compiler can compile C code. you can use Zig tooling for a C codebase, and then slowly add Zig code where it makes the most sense.
    - voidUpdate 2y ago
      Well I was debating learning C this year, but Zig seems like the more attractive option. I'd be starting new projects from scratch
      - johnisgood 2y ago
        I think it is still useful to learn C, however. For personal projects you could use Zig, but it is still good to know C. C is like the lingua franca of programming languages, and some assembly (if you care about optimization, for example).
      - woodrowbarlow 2y ago
        ahh, ideally i'd say learning them in any order is fine but unfortunately since the zig ecosystem is not mature yet that means you'll find yourself using C libraries from zig fairly often. so, yes, i agree learning zig is a great idea for new independent projects but (at the current stage) be prepared to also learn at least enough about C to use C libraries (return type conventions, raw enums, c-style strings, inflexible allocators).
masklinn 2y ago
> Rust is supposed to replace C++, not C, right? Rust is intended as a systems langage. To the extent that it’s “supposed” to replace anything, it’s both.

MrMcCall 2y ago

The reality is that we spend FAR more time reading code than writing it. That is why readability is far more important than clever, line saving constructs. The key to further minimizing the mental load of reacquainting yourself with older existing code is to decide on a set of code patterns and then be fastidious in using them. And then, if you want to want to be able to easily write a parser for your own code (without every detail in the spec), it's even more important. And now that I have read TFA, I see he wrote: > We have tooling that verify basic code style compliance. His experience and dilligence has led him to the mountaintop, that being we must make ourselves mere cogs in a larger machine, self-limiting ourselves for the greater good of our future workload and production quality.

johnisgood 2y ago
> That is why readability is far more important than clever, line saving constructs. Yes, I agree, that is why I am put off by some supposed C replacements that are trying to be clever with their abstractions or constructs.
- MrMcCall 2y ago
  Simplicity is essential to achieving managable complexity over time.
  - kryptiskt 2y ago
    Abstraction is necessary to handle scale. If you have painstakingly arrived at a working solution for a complex problem like say locking, you want to be able to package it up and use it throughout your codebase. C lacks mechanisms to do this apart from using its incredibly brittle macro facility.
    - johnisgood 2y ago
      Ada has built-in constructs for concurrency, with contracts, and there is formal verification in a subset of Ada named SPARK, so Ada / SPARK is pretty good.
    - MrMcCall 2y ago
      > 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 2y ago
- pjc50 2y ago
  Could you give an example of "clever" (bad) vs "simple" (good)? In my experience C has a lot of simple grammar, a commonly-held simple (wrong) execution model, and a lot more complexity lurking underneath where it can't be so easily seen. (One of my formative learning books was https://en.wikipedia.org/wiki/C_Traps_and_Pitfalls https://en.wikipedia.org/wiki/C_Traps_and_Pitfalls , valid in the 90s and mostly still valid today)
baumschubser 2y ago
> The reality is that we spend FAR more time reading code than writing it. That is why readability is far more important than clever, line saving constructs. In JS sometimes chain two or three inline-arrow-functions specifically for readability. When you read code, you often search for the needle of "the real thing" in a haystack of data formatting, API response prepping, localization, exception handling etc. Sometimes those shorthand constructs help me to skip the not-so-relevant parts instead of mentally climbing down and up every sort and rename function. That being said, I would not want this sentiment formalized in code guidelines :) And JS is not C except both have curly braces.
- MrMcCall 2y ago
  > That being said, I would not want this sentiment formalized in code guidelines :) Surely. I'm all for code formatting standards as long as they're MY code formatting standards :-) Ideally, I'd like the IDE to format the code to the user/programmer's style on open, but save the series of tokens to the code database in a formatting-agnostic fashion. Then we could each have our own style but still have a consistent codebase. And, I should add that my formatting conventions have gotten more extreme and persnickety over the years, and I now put spaces on both sides of my commas, because they're a separate token and are not a part of the expression on either side of it. I did this purely for readability, but I have NEVER seen anyone do that in all my decades on the internet reading code and working on large codebases. But I really like how spacing it out separates the expression information from the structural information. It also helps me deal with my jettisoning code color formatting, as, as useful as I've found it in the past, I don't want to deal with having to import/set all that environmental stuff in new environments. So, I just use bland vi with no intelligence, pushing those UI bells and whistles out of it into my code formatting. And, I fully endorse whatever it takes for you to deal with JS, as I have loathed it since it appeared on the scene, but that's just me being an old-school C guy.

Zambyte 2y ago

I have been playing around a lot with Zig lately, and though it's still in beta, it really feels like it has the best chance at being a true C successor. While Rust feels like they started with C++ and worked on making it harder to write incorrectly, Zig feels like they started with C and worked on making it easier to write correctly. They also have a few pillars that they call the "Zen" of Zig[0], of which three out of the first five are directly related to readability. [0] https://ziglang.org/documentation/0.14.0/#Zen https://ziglang.org/documentation/0.14.0/#Zen

voidUpdate 2y ago
I really want to start trying to learn zig, but right now I feel like it's not quite finished enough. When it hits 1.0, I'll probably give it a more serious look
- woodrowbarlow 2y ago
  Zig is friendly for soft-transitions because the compiler can compile C code. you can use Zig tooling for a C codebase, and then slowly add Zig code where it makes the most sense.
  - voidUpdate 2y ago
    Well I was debating learning C this year, but Zig seems like the more attractive option. I'd be starting new projects from scratch
    - johnisgood 2y ago
      I think it is still useful to learn C, however. For personal projects you could use Zig, but it is still good to know C. C is like the lingua franca of programming languages, and some assembly (if you care about optimization, for example).
    - woodrowbarlow 2y ago
      ahh, ideally i'd say learning them in any order is fine but unfortunately since the zig ecosystem is not mature yet that means you'll find yourself using C libraries from zig fairly often. so, yes, i agree learning zig is a great idea for new independent projects but (at the current stage) be prepared to also learn at least enough about C to use C libraries (return type conventions, raw enums, c-style strings, inflexible allocators).

masklinn 2y ago

> Rust is supposed to replace C++, not C, right? Rust is intended as a systems langage. To the extent that it’s “supposed” to replace anything, it’s both.