Dennis Ritchie’s first C compiler (c. 1972)

And he was almost certainly using ed(1) as his editor and a mechanical teletype at 7.5 or 10.0 characters per second as his terminal...

The C language (and all of Unix) was designed to be very terse as a consequence.

Can't return in a ternary.

Why nightmarish? A reviewer may explain that it is prone for other human to overlook the end of conditional and go sleep as usual. I never understood the emotional component of blaming someone’s personal code styles, as if it were a religion with sacrifices and blasphemy instead of just a practical way of coding in a heterogeneous team.

This triggers me because many people jump on “bad c0de” in the forums, but then you read some practical code on github, and it is (a) not as perfectly beautiful as they imagine at all and (b) is still readable without nightmares they promised and (c) the algorithms and structure itself requires programmer’s perception and understanding levels far beyond the “it’s monday morning so i feel like missing an end of statement in a hand-written scanner” anyway.

That team had Bell Labs researchers, Ken Thompson and Doug McIlroy being among them. Their brains could handle much harder things!

Well, some say (I disagree) that C is a bug.

It means it lives on the stack, so it "exists" until the function returns.

Do you mean automatic type deduction?

Edit : I know it’s also storage specifier but it also does type deduction here, hope I’m not confused with the terminology

> ask a non programmer

Why should a non programmer understand programming terms? Words have different meanings in different contexts. That's how words work. There is no need to make these terms understandable to anyone. The layman does not need to understand the meaning of long or word in C source code.

Ask a non-golf player what is an eagle or ask a physicist, a mathematician and a politic the meaning of power.

Word and long may have been poor word choices, but asking a non-programmer is not a good way to test it.

> Microsoft’s WORD/DWORD are nearly as bad. Don’t call something a “word” if it doesn’t store characters.

"Word" as a term has been in the wide use since at least 50s-60s, you can't really blame MS for that

https://en.wikipedia.org/wiki/Word_(computer_architecture)

Yes, int_16/int_32 or something like that makes a lot more sense. Today, not when this compiler was written.

The PDP-9, PDP-10, and PDP-18 have 18 bits registers. The world had not settled on 16/32/64 bits at all.

Even the intel 80286 far/fat pointers are 24 bits.

It could not be clearer that you didn't read the page referenced by the comment you replied to.

"long" was commented out.

No, the names are fine and self evident after glancing through K&R for 15 min.

The real mistake in retrospect is that int and long are platform dependent. This is an amazing time sink when writing portable programs.

For some reason C programmers looked down on the exact width integer types for a long time.

The base types should have been exact width from the start, and the cool sounding names like int and long should have been typedefs.

In practice, I consider this a larger problem than the often cited NULL.

int is neither 32 nor 64. Its width corresponded to a platform’s register width, which is now even more blurred because today’s 64 bit is often too big for practical use and CPUs have separate instructions for 16/32/64 bit operations, and we agreed that int should be likely 32 and long 64, but the latter depends on a platform ABI. So ints with modifiers may be 16, 32, 64 or even 128 on some future platform. intN_t are different fixed-width types (see also int_leastN_t, int_mostN_t, etc in stdint.h; see also limits.h).

Also, don’t forget about short, it feels so sad and alone!

> It makes sense long would have needed a comment.

I think you misunderstood. There's no explanatory comment. The "long" keyword is commented out, meaning that it was planned but not yet implemented.

    ...
            init("int", 0);
            init("char", 1);
            init("float", 2);
            init("double", 3);
    /*      init("long", 4);  */
            init("auto", 5);
            init("extern", 6);
            init("static", 7);
    ...