5 ms·

Well, I do think a programming language is a tool and it is kind of wrong to blame the tool for the mistakes made by the one wielding it. The problem with C is

Well, I do think a programming language is a tool and it is kind of wrong to blame the tool for the mistakes made by the one wielding it. The problem with C is that it's a tool where you have no safety and I don't think there's a programmer alive that can actually use it in a safe manner. I guess some are close, but they will still end up with the occasional wound here and there on their bodies... I would probably avoid using C for anything I put in production today, I still love the language though. It still feels special, sitting down with all that power at your fingertips knowing that you'll have a built in buffer overflow if you lose focus for a second, gets (no pun intended) my blood flowing! :-)

adwn 5y ago
> it is kind of wrong to blame the tool for the mistakes made by the one wielding it I strongly disagree. I think it is absolutely legitimate to blame a tool which is practically impossible to use correctly [1]. Some of C's design decisions were justified in its historical context, and some – like zero-terminated strings – were indefensible even back then. [1] Alternatively, you could blame its creators, but that's not very useful.
- flohofwoe 5y ago
  Zero terminated strings make sense when you consider the pecularities of the PDP instruction set. Snippet from "https://dave.cheney.net/2017/12/04/what-have-we-learned-from-the-pdp-11 https://dave.cheney.net/2017/12/04/what-have-we-learned-from...": One can write a string copy routine using two instructions, assuming that the source and destination are already in registers. loop: MOVB (src)+, (dst)+ BNE loop The routine takes full advantage of the fact that MOV updates the processor flag. The loop will continue until the value at the source address is zero, at which point the branch will fall through to the next instruction. This is why C strings are terminated with zeros.
  - pjmlp 5y ago
    Except the world stop being a PDP-11 around 1980's, while ISO C refuses to update itself to modern times. The biggest issue with C isn't its footguns, rather the WG14 unwillingness to provide additional language or library features that would allow for a safer C outside the low level code where it pretends to be a portable macro assembler.
    - flohofwoe 5y ago
      In the early years the job of the C committee wasn't to improve C, but merely to harmonize existing C implementations, and by the end of the 80's it was already too late, zero-terminated strings had already been baked into operating system APIs (e.g. zero-terminated strings are no longer primarily a language problem, but an ABI problem). Besides, the x86 "repeat while" string instructions continued the PDP legacy.
      - kortex 5y ago
        That argument sounds akin to "Well people are used to driving without seatbelts, it'd be painful to make them switch now." Or like my spouse likes to joke when we get in the car to leave and forgot something in the house: "it's too late, the door's shut." I get why null terminated strings once existed. It's baffling that they continue to exist 50 years later. Not to mention, they don't even work on data buffers, so you need fat pointers anyways!
        flohofwoe 5y ago
        Replacing the string memory layout in operating system APIs is more similar to changing the track width on an existing railroad network, across the whole world. It may be a good idea from a theoretical standpoint, but once you start calculating the cost it simply doesn't make sense.
        pjmlp 5y ago
        Liability and lawsuits due to security exploits will take care of that. Thankfully they are starting to pick up.
- fragbait65 5y ago
  Well, I agree that you can wish that the tool was better designed, that's a whole different thing though. What I meant to say, in a rather roundabout way to be fair, is that the problem is both the language and the programmers. C is a tool that is too hard to use correctly, but the programmers who write crappy C code are to blame for their crappy code. It's another thing if an expert fails to use the tool safely, then one might blame the design of the tool used. There seems to be 2 camps, one camp blames C and one camp blame it on poor programmers. Poor programmers have given C a reputation and the tool itself is too hard to use correctly, even for experts, so both camps are right and also wrong... I think some of the decisions made for C back in the day where fine, C was designed to be lightning fast and close to the metal, but I think it's time to pivot. I don't think it's necessary to sacrifice security to squeeze out the last percent of "speed" today. C has a lot of legacy code still in use though, so I don't think it will ever happen, that's why I use other languages for production code today and only write C when needed for C code bases still in use.
  - flohofwoe 5y ago
    There's a lot of room to explore between C and Rust, while not compromising on low-level features and performance (e.g. "performance" and "safety" are both not absolutes, and also not excluding each other. I hope that there will be many new languages (the more the merrier) exploring that space. But we'll live for a very long time with C code, it will most likely outlive us all, because important infrastructure code is never really replaced, it just becomes a new sediment layer.
    - deleted 5y ago
      [deleted]
    - pjmlp 5y ago
      Which is why stuff like Checked C, or something like SDS should really be made part of C, as UNIX clones are going to outlive us anyway. However just like rotating blade covers, butcher metal gloves, seat belts, helmets,..., apparently external forces like government regulations are required to make WG14 act accordingly.
  - 5y ago
VortexDream 5y ago
> it is kind of wrong to blame the tool for the mistakes made by the one wielding it. I always find takes like this bizarre. We're constantly improving the safety of the tools and devices we use. Our history is filled with examples of tools designed without safety in mind leading to deaths or maiming or other injuries. Thankfully, the people who came before us saw that it was up to us to reduce the likelihood of accidents by improving the tools that we use. Just look at the aerospace industry. They didn't say "well, don't blame the plane, the pilot should've gotten it right". Often times improvements in planes were to avoid common mistakes because of how fallible we human beings are, instead of holding us up to impossible standards.
- fragbait65 5y ago
  I agree. The difference is that engineering over all is mature enough that you can make incremental changes over time and it still does not invalidate what you did previously. If you built a bridge 10 years ago its probably safe enough to leave standing even if you can build a safer bridge today. The same cannot be said for programming yet. It's hard to improve the safety of the tool, the C compiler, without breaking your past bridges or having to redo the work again, i.e rebuilding the bridge.
  - tialaramex 5y ago
    England has lots of Victorian railways bridges. Now, the Victorian engineers knew perfectly well how to build a railway bridge, which is why those bridges are still there. But they hadn't yet got to the place where you always properly document your work as you go, and they also didn't think too hard about (from their perspective) the distant future, our present. So a modern railway engineer inspecting a Victorian bridge has a problem. The bridge was built in the usual fashion of the time, and it's impractical to fully inspect the load-bearing materials without dismantling the bridge. There is no detailed paperwork because the Victorians didn't keep any. Still, it stands to reason that if the cast iron load structure exposed in one place has 15-20 years of life left in it, the unexposed structures you can't see are similar and this bridge can be scheduled for replacement in say 10-15 years. Right? And then, one night, as a fully laden freight train crosses it, the bridge collapses. The driver feels something wrong on the bridge and then, a few seconds later, the locomotive automatically brakes to a full halt - unable to sense the rear of the train which is in fact now laying in the rubble of the broken bridge. The Victorians saved a little money by using thinner metal for the unexposed girder, which had therefore failed earlier than the predictions based on the thicker metal. Documentation is essential. If your 30 year old C project doesn't have adequate documentation chances are you don't know whether those unexposed elements are as strong as the parts you can see or if they're paper thin and likely to fail at any moment.
Gibbon1 5y ago
Bad tools should be replaced with improved ones. The problem with C is the two generations of standard committee members have stubbornly shirked their duty to fix these problems.

adwn 5y ago

> it is kind of wrong to blame the tool for the mistakes made by the one wielding it I strongly disagree. I think it is absolutely legitimate to blame a tool which is practically impossible to use correctly [1]. Some of C's design decisions were justified in its historical context, and some – like zero-terminated strings – were indefensible even back then. [1] Alternatively, you could blame its creators, but that's not very useful.

flohofwoe 5y ago
Zero terminated strings make sense when you consider the pecularities of the PDP instruction set. Snippet from "https://dave.cheney.net/2017/12/04/what-have-we-learned-from-the-pdp-11 https://dave.cheney.net/2017/12/04/what-have-we-learned-from...": One can write a string copy routine using two instructions, assuming that the source and destination are already in registers. loop: MOVB (src)+, (dst)+ BNE loop The routine takes full advantage of the fact that MOV updates the processor flag. The loop will continue until the value at the source address is zero, at which point the branch will fall through to the next instruction. This is why C strings are terminated with zeros.
- pjmlp 5y ago
  Except the world stop being a PDP-11 around 1980's, while ISO C refuses to update itself to modern times. The biggest issue with C isn't its footguns, rather the WG14 unwillingness to provide additional language or library features that would allow for a safer C outside the low level code where it pretends to be a portable macro assembler.
  - flohofwoe 5y ago
    In the early years the job of the C committee wasn't to improve C, but merely to harmonize existing C implementations, and by the end of the 80's it was already too late, zero-terminated strings had already been baked into operating system APIs (e.g. zero-terminated strings are no longer primarily a language problem, but an ABI problem). Besides, the x86 "repeat while" string instructions continued the PDP legacy.
    - kortex 5y ago
      That argument sounds akin to "Well people are used to driving without seatbelts, it'd be painful to make them switch now." Or like my spouse likes to joke when we get in the car to leave and forgot something in the house: "it's too late, the door's shut." I get why null terminated strings once existed. It's baffling that they continue to exist 50 years later. Not to mention, they don't even work on data buffers, so you need fat pointers anyways!
      - flohofwoe 5y ago
        Replacing the string memory layout in operating system APIs is more similar to changing the track width on an existing railroad network, across the whole world. It may be a good idea from a theoretical standpoint, but once you start calculating the cost it simply doesn't make sense.
        pjmlp 5y ago
        Liability and lawsuits due to security exploits will take care of that. Thankfully they are starting to pick up.
fragbait65 5y ago
Well, I agree that you can wish that the tool was better designed, that's a whole different thing though. What I meant to say, in a rather roundabout way to be fair, is that the problem is both the language and the programmers. C is a tool that is too hard to use correctly, but the programmers who write crappy C code are to blame for their crappy code. It's another thing if an expert fails to use the tool safely, then one might blame the design of the tool used. There seems to be 2 camps, one camp blames C and one camp blame it on poor programmers. Poor programmers have given C a reputation and the tool itself is too hard to use correctly, even for experts, so both camps are right and also wrong... I think some of the decisions made for C back in the day where fine, C was designed to be lightning fast and close to the metal, but I think it's time to pivot. I don't think it's necessary to sacrifice security to squeeze out the last percent of "speed" today. C has a lot of legacy code still in use though, so I don't think it will ever happen, that's why I use other languages for production code today and only write C when needed for C code bases still in use.
- flohofwoe 5y ago
  There's a lot of room to explore between C and Rust, while not compromising on low-level features and performance (e.g. "performance" and "safety" are both not absolutes, and also not excluding each other. I hope that there will be many new languages (the more the merrier) exploring that space. But we'll live for a very long time with C code, it will most likely outlive us all, because important infrastructure code is never really replaced, it just becomes a new sediment layer.
  - deleted 5y ago
    [deleted]
  - pjmlp 5y ago
    Which is why stuff like Checked C, or something like SDS should really be made part of C, as UNIX clones are going to outlive us anyway. However just like rotating blade covers, butcher metal gloves, seat belts, helmets,..., apparently external forces like government regulations are required to make WG14 act accordingly.
- 5y ago

VortexDream 5y ago

> it is kind of wrong to blame the tool for the mistakes made by the one wielding it. I always find takes like this bizarre. We're constantly improving the safety of the tools and devices we use. Our history is filled with examples of tools designed without safety in mind leading to deaths or maiming or other injuries. Thankfully, the people who came before us saw that it was up to us to reduce the likelihood of accidents by improving the tools that we use. Just look at the aerospace industry. They didn't say "well, don't blame the plane, the pilot should've gotten it right". Often times improvements in planes were to avoid common mistakes because of how fallible we human beings are, instead of holding us up to impossible standards.

fragbait65 5y ago
I agree. The difference is that engineering over all is mature enough that you can make incremental changes over time and it still does not invalidate what you did previously. If you built a bridge 10 years ago its probably safe enough to leave standing even if you can build a safer bridge today. The same cannot be said for programming yet. It's hard to improve the safety of the tool, the C compiler, without breaking your past bridges or having to redo the work again, i.e rebuilding the bridge.
- tialaramex 5y ago
  England has lots of Victorian railways bridges. Now, the Victorian engineers knew perfectly well how to build a railway bridge, which is why those bridges are still there. But they hadn't yet got to the place where you always properly document your work as you go, and they also didn't think too hard about (from their perspective) the distant future, our present. So a modern railway engineer inspecting a Victorian bridge has a problem. The bridge was built in the usual fashion of the time, and it's impractical to fully inspect the load-bearing materials without dismantling the bridge. There is no detailed paperwork because the Victorians didn't keep any. Still, it stands to reason that if the cast iron load structure exposed in one place has 15-20 years of life left in it, the unexposed structures you can't see are similar and this bridge can be scheduled for replacement in say 10-15 years. Right? And then, one night, as a fully laden freight train crosses it, the bridge collapses. The driver feels something wrong on the bridge and then, a few seconds later, the locomotive automatically brakes to a full halt - unable to sense the rear of the train which is in fact now laying in the rubble of the broken bridge. The Victorians saved a little money by using thinner metal for the unexposed girder, which had therefore failed earlier than the predictions based on the thicker metal. Documentation is essential. If your 30 year old C project doesn't have adequate documentation chances are you don't know whether those unexposed elements are as strong as the parts you can see or if they're paper thin and likely to fail at any moment.

Gibbon1 5y ago

Bad tools should be replaced with improved ones. The problem with C is the two generations of standard committee members have stubbornly shirked their duty to fix these problems.