7 ms·

Hubris is really, really nice. I've spent half an hour reading some of the kernel code and it’s exceptionally clear and well written - a far cry from ifdef macr

• hinkley 3y ago
  It bothers me deeply how much of C ethos can be boiled down to, "We can't be bothered to learn to type at a reasonable speed" Disk space for source code hasn't really been a problem for forty years (binaries definitely), and yet we are still being stingy with variable names.
  • pif 3y ago
    Code quality has zero correlation with typing speed.
  • postmodest 3y ago
    > It bothers me deeply how much of C ethos can be boiled down to, "We can't be bothered to learn to type at a reasonable speed" "My computer is a LITERAL TELETYPE, so I will enshrine typographical parsimony in every part of this OS/Language I am creating" -K&R
  • djmips 3y ago
    Yeah it wasn't about typing speed. Maybe you were being sarcastic.
  • tjoff 3y ago
    If it bothers you so much I'm happy to tell that that is not the reason for it.
    • throwaway11460 3y ago
      Who cares though? Just use an IDE or Copilot or something.
    • spc476 3y ago
      Could you spend some effort to explain the reason then?
      • refulgentis 3y ago
        Fwiw I've written some Real C++, think, audio encoders/decoders for voice recognition for 1B MAUs on the server, audio encoder on 2B devices. Each and every time there was just insane excuses that boiled down to only a few people wanted to write C++ and they found infinite ways to justify not doing things, like all us humans do. My favorite was the "don't write comments because as soon as you do they're out of date." Even though this is recognizably trollish tripe at the extreme it was implemented, I still find it hard to ignore that brainworm in my day to day coding.
        • Retric 3y ago
          I think that’s a common mutation of the far more useful and therefore relevant “Don’t trust comments” which everyone learns at some point.
          • citrin_ru 3y ago
            “Don’t trust people” is a heuristic to avoid being scammed. But it is much nicer to live in a society where you can trust most of the people. The same way it is nice to work with code base where you can trust comments by default. Which is the case for many open source projects.
            • Retric 3y ago
              Personally it’s always the programs you can generally trust that end up reinforcing the idea. On average you may be far better off trusting comments but that one time they fail you is all the worse because of that trust. It’s the same deal with compilers and computer hardware. They work so well that they become a blind spot, and yet I’ve had both fail me.
  • akira2501 3y ago
    > how much of C ethos can be boiled down to A lot of commercial code is like this, regardless of the language; there just happen to be people trying to sell new languages. They desperately want to convince you that this is all the fault of C and it's nebulous "ethos," and if you just use their new language, it will all magically go away and possibly improve human rights somehow.
  • hughesjj 3y ago
    I get that we as an industry went a bit overboard when Java +ooo was in vouge novelty with entire sentences being method names, but I'm with you that all the people I see making super compressed var names with contexts longer than a for loop initializer And don't even get me started on trying to text to speak your `mCtx` or whatever
    • OJFord 3y ago
      > And don't even get me started on trying to text to speak your `mCtx` or whatever I'm not saying TTS is there (I have no idea) but from an ideal point of view, to have it be equivalent, surely it would read 'm context', which then isn't so bad (maybe m is clear from the ..err.. context).
      • hughesjj 3y ago
        From my experience with someone who has CRPS the actual tooling in place to consistently do these kinds of things is severely wanting. Dragon naturally speaking isn't great for code and is all but abandon ware, and while there's a lot of cool new ai tools out the integration isn't there just yet. That said maybe `mCtx` wasn't the best example, but in general anything other than fully pronounceable words in a normalized format (PascalCase, camelCase, snake_case, kebab-case, etc) is a huge pita for language models in our experience. Things like `i` or other single letters are generally okay. But imagine things like "wait did you mean the letter 'm' or the unit 'em'"
      • ElFitz 3y ago
        You could run a LLM pass to "expand" abbreviations and acronyms before running it through text to speech. Although more expensive, it worked wonders for me with text containing units of measurement (°F, °C, m/s, etc).
        • hughesjj 3y ago
          You're right, but for non standard things configuring it for literally every project becomes quickly untenable IDK, I've yet to see a good argument for not having your variables being generally pronouncable (at least, in a way more or less consistent with the native language of your code base or English). I'm just going to lazily parrot the old adage that "code gets read more often than written, so prefer making it easier to read than write"
  • cdchn 3y ago
    Its funny because the article even talks about the importance of reducing space for binaries.
  • StressedDev 3y ago
    C (the language) does not cause people to write unmaintainable or hard to understand code. Programmers who choose to write unmaintainable or hard to understand code are the problem. I have seen great C code, good C code, mediocre C code, etc. It really depends on who is writing this. This is true of all languages. In short, technology cannot fix people problems.
    • npteljes 3y ago
      While that's true, what languages have is culture. Formatting conventions, names of built-in stuff, books that teach the basics, expectations of devs that already know the language, and the newbies are expected to work with. It's often not on the programmer, but rather on the complex interactions between the programmers.
    • hnaccount_rng 3y ago
      That’s a statement that comes up a lot. And while it is technically true, it really isn’t in practice. We can and do design systems to expose less of their surfaces that represent open knifes and more of the safe handle side. It is near universally true, that the easier to access way is the one that will be taken more often. To be fair to C, it was designed long before we as a society really appreciated that. So there is a lot of old code whose authors just couldn’t know better. And some (probably few) will even have managed to write readable code! But that doesn’t mean that languages can’t encourage good behavior and discourage bad. (I’m not even sure where I come down wrt Rust here) And that will (somewhat reliably) end in better or worse code. Not necessarily in a reliable way. But it’s e.g. really hard to write python code where local control flow isn’t reasonably obvious (since scoping is enforced by white space). Not impossible of course
      • pastage 3y ago
        There are lots of example of hard to understand Python local control flow, Python is a long way from being consistent in encourge good behaviour. When comparing the same type of code let say arg parsing C is usually worse. In Python you can get lost in library hell looking at the details of that code but in C it's just knowledge of basic functions of the language how ever terse it might be. On avarage I agree.
  • anilakar 3y ago
    Most of the bad habits stem from how C is taught. It should not be the first language freshmen are taught in universities. All the effort will be wasted on teaching basic programming instead of the actual language and good programming habits. Pointers and the memory model are core concepts and should be taught early on. The worst programming books I have seen introduce them in the very last chapter, often called "advanced language features" or something similar. It is not a compiled scripting language for Unix systems either and should not be programmed with a text editor on a remote machine. The programmer should have a proper development environment installed locally. Valgrind and and Clang's sanitizers should be used extensively. There is no such thing as partial credit when it comes to memory correctness. If a certain QuakeNet IRCop is reading this, thank you. Your uni C course managed to avoid all the pitfalls above.
    • pif 3y ago
      > should not be programmed with a text editor on a remote machine. The programmer should have a proper development environment installed locally. "should not", "They should have" ... well, it had to! And they didn't have. There is no point in trying to forget where C comes from.
  • xorcist 3y ago
    Identifiers aren't short in C (or any other language) because disk storage is expensive but because readability suffers with long identifiers. The example here is very much C-style (short, lowercase, underscore). The list of argument is called "args" (short and descriptive). It is not called argumentListArray. It is not a coincidence that math have very short and well known identifiers. The rate of change in horizontal position is called x'. It is not called posHorizontalChangeRate simply because the latter is harder to read. There is, of course, such a thing as having too short identifiers.
    • repler 3y ago
      > The list of argument is called "args" (short and descriptive) You’re proving the original point - it should be named “arguments” because that is what it is. Saving … 5 bytes? by naming it “args” instead is exactly OP’s point.
      • CogitoCogito 3y ago
        I don’t personally find “arguments” any clearer than “args”. Not sure what’s gained by calling it arguments other than 5 extra characters.
        • bluGill 3y ago
          How long haye you been programming? You got used to the short name and now it is a word to you.
          • krisoft 3y ago
            I don't think args is the right variable name to pick for this argument. As you say it is what that thing is called idiomatically. I think it is fine. It is more about if your code needs to parse an internationaly formated phone number from a string into a struct. (or pick anything else specific only to your problem domain) How do you call that function? Do you call it prsphi? (prs for parse, ph for phone number and i for international) Or do you call it parse_international_phone_number? Or maybe international_phone_string_to_phonenumber_struct? (or something similar in CamelCase) That is where the difference starts to matter. And I for one don't want to read code with many prsphi's around.
  • dspillett 3y ago
    > It bothers me deeply how much of C ethos can be boiled down to, "We can't be bothered to learn to type at a reasonable speed" I can understand it from way back when. People were moving from assembly and other languages where everything was terse by requirement so variable/function/other names were short out of habit, though even then your assembly should have had comments about what was in each register & why etc. Also, comments were relatively terse because people were working on small screens and in extreme cases were concerned about the size of code files. None of this is adequate excuse for doing things wrong now, decades later, but such habits have momentum: people with the habits write books and local style guides, and also short names are baked into the standard library, so new people are “infected” by the habits, and so it rolls forward.
    • cesarb 3y ago
      > Also, comments were relatively terse because people were working on small screens The standard screen size was 24 lines of 80 columns, and you couldn't expect a reader of your code to have a terminal with higher resolution than that. So the standard is to make your code fit in 80 columns; using longer identifiers means statements will end up taking multiple lines, which means less code can fit on the screen, making it less readable. Even today, terminal emulators like Gnome Terminal still open by default with 24 lines of 80 columns, so there's still value in making code readable in that resolution (though nowadays, the main advantage is making it easier to read code side-by-side in multiple windows).
• nebula8804 3y ago
  AI might kill this convention when everyone pipes their old crusty C code and all of a sudden all the variables are clean and named in the fashion the user loves best (because the AI has learned exactly the quirks of how a specific coder likes it).
  • chc4 3y ago
    AI might also make unicorns real and usher in world peace, while we're wishing for things.
    • TeMPOraL 3y ago
      Unicorns are merely an engineering problem tho (specifically, genetic engineering).
      • dxdm 3y ago
        > Unicorns are merely an engineering problem tho (specifically, genetic engineering). So is world peace, while we're saying things that contain the word "merely". :)
  • aitchnyu 3y ago
    One dev uses an autoformatter (black for Python) for his codebase. When he wants to do side by side diff on a laptop, he reduces line width to 70 characters and formats his entire codebase, works with his diff tool, then reformats back to original width.