4 ms·

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

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.
hnfong 3y ago
It depends whether you include the standard library into consideration. atoi()? strrchr()? srand()? I’d argue the obtuseness of the standard library function names at least influence the legibility of the programs written against them.
- pif 3y ago
  > the obtuseness of the standard library function names I suppose you are too young to remember that back in the day there was no IDE helping you with autocompletion, thus one character less in the name is one character less to type. Furthermore, I'm ready to bet you are from the USA, and you forgot that most of the world (even the programming world) does not speak English natively, thus "SeedRandom" is NOT clearer than "srand": it's just as cumbersome and longer to type while reading character by character on a paper manual.
  - pezezin 3y ago
    I am not from the USA; I am from Spain and learnt programming before I learnt English. I never found English keywords and identifiers to be a problem, they are just fancy words that you memorize and reuse. Heck, I know plenty of programmers that don't speak English, and they don't see to have a problem either.
ninkendo 3y ago
> C (the language) does not cause people to write unmaintainable or hard to understand code Well then it’s good that OP didn’t claim that C the language causes people to write such code. They said “The C ethos”, not “The C language.” It’s not about the language’s technical requirements, it’s about what’s idiomatic in a language, how it’s taught, and what style is used by the vast majority of the existing corpus of code written in that language. Look at the C standard library’s function names, vsnfprintf/strdupa/acosh/ftok… Compare it to something like Objective-C at the other extreme, where method and variable names tend to always have fully spelled out identifiers with no abbreviations and a full description of what’s being done (`- [NSString stringByAppendingString]`, etc.) Is it due to some technical requirement? Is stringByAppendingString illegal in C because it’s too long? Is strdup illegal in ObjC because it’s too short? Of course not! But why do we see this everywhere so consistently? Why does C have short indecipherable function names and ObjC have such long ones, if the language doesn’t require it? Because idioms matter. If you’re learning C, you’re learning the way it is typically taught. You’re reading other C code. You’re encouraged to program the way other C programmers program. You’re likely using the standard library a lot. Likewise ObjC. This means two things: - Yes, in a very obvious sense, it’s not the language’s fault, it’s the programmers’s fault. - But also, paradoxically, it is the language’s fault, because a language is not just a set of syntax in a vacuum, it’s also a corpus of existing code, a set of idioms, a community of people, and a way of thinking of things. C absolutely causes people to write hard-to-understand code when viewed through this lens. Your comment has been written in so many ways in so many threads discussing programming languages, it’s absolutely tiring. Yes, you can write terrible code in any language, and you can write great code in any language (well almost any… probably not brainfuck.) Nobody is arguing that. When we discuss whether one language is more readable than the other, we’re always talking about the qualities of typical code you actually see in a language, and about what style of code that language encourages.
- p_l 3y ago
  It used to be a language limitation, first practical, later codified for portability. Originally (C89) it was 6 characters for anything externally visible, these days (C99) it's 63 ASCII characters for internal identifiers and 31 characters for external identifiers (implementation can allow longer, but does not have to - those are the minimal significant i.e. preserved identifier lengths). Same reason why Pascal has symbols limited to 10 characters and doesn't preserve case - because original implementation mapped identifiers into 10 6-bit characters packed into 60 bit word. Similarly some of the oldest Common Lisp functions retain aspects of encoding characters to fit into 36 bit words efficiently.
pjc50 3y ago
This comes up every time someone advocates for C, and it's basically a refusal to learn anything about process and safety culture since the 1950s. "Poka-yoke" was invented in the 1960s. The programming equivalent, the use of type systems and other proof systems to automatically detect or avoid errors, is strongly resisted by C developers, who seem to want to keep writing CVEs.
- djmips 3y ago
  Ooh a poka-yoke reference! You don't see that every day. I attempted to introduce this at a previous company that used C because it doesn't just apply to the language itself but I agree that you can start there these days but back then we had no real alternatives.

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.

hnfong 3y ago

It depends whether you include the standard library into consideration. atoi()? strrchr()? srand()? I’d argue the obtuseness of the standard library function names at least influence the legibility of the programs written against them.

pif 3y ago
> the obtuseness of the standard library function names I suppose you are too young to remember that back in the day there was no IDE helping you with autocompletion, thus one character less in the name is one character less to type. Furthermore, I'm ready to bet you are from the USA, and you forgot that most of the world (even the programming world) does not speak English natively, thus "SeedRandom" is NOT clearer than "srand": it's just as cumbersome and longer to type while reading character by character on a paper manual.
- pezezin 3y ago
  I am not from the USA; I am from Spain and learnt programming before I learnt English. I never found English keywords and identifiers to be a problem, they are just fancy words that you memorize and reuse. Heck, I know plenty of programmers that don't speak English, and they don't see to have a problem either.

ninkendo 3y ago

> C (the language) does not cause people to write unmaintainable or hard to understand code Well then it’s good that OP didn’t claim that C the language causes people to write such code. They said “The C ethos”, not “The C language.” It’s not about the language’s technical requirements, it’s about what’s idiomatic in a language, how it’s taught, and what style is used by the vast majority of the existing corpus of code written in that language. Look at the C standard library’s function names, vsnfprintf/strdupa/acosh/ftok… Compare it to something like Objective-C at the other extreme, where method and variable names tend to always have fully spelled out identifiers with no abbreviations and a full description of what’s being done (`- [NSString stringByAppendingString]`, etc.) Is it due to some technical requirement? Is stringByAppendingString illegal in C because it’s too long? Is strdup illegal in ObjC because it’s too short? Of course not! But why do we see this everywhere so consistently? Why does C have short indecipherable function names and ObjC have such long ones, if the language doesn’t require it? Because idioms matter. If you’re learning C, you’re learning the way it is typically taught. You’re reading other C code. You’re encouraged to program the way other C programmers program. You’re likely using the standard library a lot. Likewise ObjC. This means two things: - Yes, in a very obvious sense, it’s not the language’s fault, it’s the programmers’s fault. - But also, paradoxically, it is the language’s fault, because a language is not just a set of syntax in a vacuum, it’s also a corpus of existing code, a set of idioms, a community of people, and a way of thinking of things. C absolutely causes people to write hard-to-understand code when viewed through this lens. Your comment has been written in so many ways in so many threads discussing programming languages, it’s absolutely tiring. Yes, you can write terrible code in any language, and you can write great code in any language (well almost any… probably not brainfuck.) Nobody is arguing that. When we discuss whether one language is more readable than the other, we’re always talking about the qualities of typical code you actually see in a language, and about what style of code that language encourages.

p_l 3y ago
It used to be a language limitation, first practical, later codified for portability. Originally (C89) it was 6 characters for anything externally visible, these days (C99) it's 63 ASCII characters for internal identifiers and 31 characters for external identifiers (implementation can allow longer, but does not have to - those are the minimal significant i.e. preserved identifier lengths). Same reason why Pascal has symbols limited to 10 characters and doesn't preserve case - because original implementation mapped identifiers into 10 6-bit characters packed into 60 bit word. Similarly some of the oldest Common Lisp functions retain aspects of encoding characters to fit into 36 bit words efficiently.

pjc50 3y ago

This comes up every time someone advocates for C, and it's basically a refusal to learn anything about process and safety culture since the 1950s. "Poka-yoke" was invented in the 1960s. The programming equivalent, the use of type systems and other proof systems to automatically detect or avoid errors, is strongly resisted by C developers, who seem to want to keep writing CVEs.

djmips 3y ago
Ooh a poka-yoke reference! You don't see that every day. I attempted to introduce this at a previous company that used C because it doesn't just apply to the language itself but I agree that you can start there these days but back then we had no real alternatives.