7 ms·

This is why we can't have these discussions...everything gets interpreted literally, and it becomes some sort of ego contest. I'll take your claim at face value

by defen 11y ago

This is why we can't have these discussions...everything gets interpreted literally, and it becomes some sort of ego contest. I'll take your claim at face value, that your team wrote 2M lines of C for a commercial project, with no memory corruptions, crashes, integer overflows, etc. That's a shockingly impressive achievement, one that I think has probably never been done before. But how is that a useful or replicable result, that will work in the real world for other projects? You're basically saying that everyone just needs to be a top 0.001% C programmer. This is the "abstinence-only sex education" of programming advice. It's super simple to not get STDs or have out-of-wedlock pregnancies - just don't have sex with anyone but your spouse, and ensure they do the same. It's 100% guaranteed to work, and if you don't follow that advice you're stupid and deserve whatever bad things happen to you.

code4life 11y ago
> This is the "abstinence-only sex education For the record, I don't think your stupid if you have a child accidentally. However, once you do accidentally have a child, the results are often not pretty, and I will feel bad watching as you deal with the consequences of your poorly thought out decision. Regarding programming, I can't see the relationship you make at all. If you write a good program, well good job. If you write a bad program, you are probably going to write a better one next time. (Ever look back at your old code?) It takes practice to get good, and the more we work at it, the better we'll get. Just keep trying.
- khedoros 11y ago
  I think defen's point was that if a team produces truly high-quality C code, it's similar to a couple that both abstain until marriage. Yes, it's technically possible, but it's rare, and it's not something that should be the expected outcome (that is, most C code will have some problems, and most couples will have at least a little bit of regrettable sexual history before they're married). It's as if I say: "Step 1 of writing good code: Don't make mistakes. If you make mistakes, you deserve what's coming to you!" Some mistakes are expected, and essentially inevitable; they're the default, not the exception. Blaming the programmer might seem like the right thing to do, but there's more practical benefit to improving the tools and teaching programmers how to handle errors, so that we can decrease the negative impact that bugs will have.
- defen 11y ago
  The point of the analogy is that it is very easy to prescribe behavior that is guaranteed to work if followed 100% to the letter, but fails catastrophically if there is even 1 mistake. There are two responses to this - you can either design systems that are easier to follow & fail less catastrophically in the real world (don't use C for new code if you don't need it; teach people about safe sex practices), OR you can double down on the sermonizing about how if people had just been smarter / had more willpower, they wouldn't be in this bad situation.
  - code4life 11y ago
    Yes, but the analogy isn't accurate, in the sense that when things do fail in a C system, it's probably not that hard to fix.
- crpatino 11y ago
  > However, once you do accidentally have a child, the results are often not pretty... Regarding programming, I can't see the relationship you make at all. I have two words for you: MAINTENANCE PROGRAMER.
  - code4life 11y ago
    Ha! Yes, aren't we all.
    - crpatino 11y ago
      It's either that or the life of the grasshopper ;) Now that I think of it, there's another parallel with unwanted pregnancies. There are men that stick around, and there are boys who run and let others clean up after their mess.
      - Roboprog 11y ago
        Would you let your daughter date a contractor???
        crpatino 11y ago
        Sure, if she was over 25 and fully aware that it is "no strings attached".
caf 11y ago
"out-of-wedlock pregnancies"? What is this, 1953? There are a great number of couples choosing to have children in stable, committed - yet unmarried - relationships.
- defen 11y ago
  This sums up internet commenting in 2016. Congratulations on entirely missing the point because you chose to focus on an irrelevant and pointless detail, which I'm sure will spawn a stupid subthread that changes no one's mind.
  - caf 11y ago
    The great thing about threaded textual commenting is that you can have a sub-thread to discuss a side point, without removing the ability to debate the main point in parallel. The comment struck me as incredibly anachronistic, bordering on offensively so.
    - deleted 11y ago
      [deleted]
    - doktrin 11y ago
      > bordering on offensively so. please don't.
  - readymade 11y ago
    And the parent thread will?
  - spajus 11y ago
    HN needs "collapse whole thread" feature. Badly.
    - MawNicker 11y ago
      +∞ Way to hijack a useless subthread and do something useful with it. Great meta-point. Honestly. This feature alone makes the comments on Reddit bearable for consumption.
ufo 11y ago
I'm gonna have to steal this analogy. Its impressive how often these dick-measuring arguments pop up.
- llamas02 11y ago
  Yaaaaa, is this hacked languishing? I love you ALL, so nice, healthy,religious righteousness, one of my favorite subjects, and I would know BEST at it. Just some translation needs to be fixed. I suppose it changes your life and THAT is what count's as positives. Solutions that WORK for the Good. It has to, for our kids. All kids. They're the future. So let's start working like slaves again and get THAT done. Joking.
- llamas02 11y ago
  Yaaaaa, is this hacked languishing? I love you ALL, so nice, healthy,religious righteousness, one of my favorite subjects, and I would know BEST at it. Just some translation needs to be fixed. I suppose it changes your life and THAT is what count's as positives. Solutions that WORK for the Good. It has to, for our kids. All kids. They're the future. So let's start working like slaves again and get THAT done. Joking.
clock_tower 11y ago
Well, there's a trick to writing C++ with no crashes and no memory corruption: never allocate memory using pointers. If you store all your data in stack variables and STL containers, C++ becomes a _much_ more forgiving language (especially if you also avoid templates and operator overloading). I imagine that this poster and his team took a similar approach with C: avoiding the dangerous features, or just finding ways to factor them out.
- humanrebar 11y ago
  Even if you do all the things you said, you can still crash a C++ program. Iterator invalidation is very easy to do on accident, for example.
derefr 11y ago
> You're basically saying that everyone just needs to be a top 0.001% C programmer. A more constructive/charitable phrasing of the parent's point might be: you should only be allowed to code in C if you're already a top 0.001% programmer. Then, obviously, all C code will be good—not that there'll be much of it. That's actually a more interesting point than it seems. Programmers generally tend to reject the idea of guilds and "professional" licensing—mostly because, AFAIK, most programs aren't critical and most crashes don't matter. But what if, instead of licensing all programming, we just licensed only low-level programming? What if, as a rule, everyone who was going to be hired to write code in a language with pointers was union-mandated to be certified as knowing how to safely fiddle with pointers? That could probably split on interesting dimensions, like a bunch of regular coders working in e.g. a Rust codebase, with a certified Low Level Programmer needing to "sign off on" any commit that contained unsafe{} code, where the actual failure of the unsafe{} code would get the Low Level Programmer disbarred.
- llamas02 11y ago
  I have people to do that for me. Thank you for the txt chit chat. Have we met? Maybe we should.
- s1m0n 11y ago
  Not all C developers need be a top 0.001% C developer to write high performance and rock solid code. Why? I'm a very experienced C programmer and one day my boss came to me and said that the sales guys had already sold a non-existing client side module to a house hold name appliance manufacturer. The deal was inked and it had to be ready in only 3 months. Even worse, it had to run in the Unix kernel of the appliance and therefore be rock solid so as to not take the whole appliance down. It also had to be ultra high performance because the appliance was ultra high performance and very expensive. Now the really bad news: I had a team made up of 3 more experienced C developers (including myself) and 3 very un-experienced C developers. We also estimated that in order to code all the functionality it would take at least 4 months. So we added on another 4 less experienced C developers (the office didn't have a lot of C developers). The project was completed in time, a success, and almost no bugs were found, and yet many developers without much C experience worked on the project. How? (a) No dynamic memory allocation was used at run-time and therefore we never had to worry about memory leaks. (b) Very, very few pointers were used. Instead mainly arrays. And not just C developers understand array syntax, e.g. myarray[i].member = 1 :-) Therefore we never had to worry about invalid pointers. (c) Source changes could only be committed together with automated tests resulting in 100% code coverage and after peer review. This meant that most bugs were discovered immediately after being created but before being checked in to the source repository. We achieved 100% code coverage with an approx. 1:1 ratio of production C source code to test C source code. (d) All code was written using pair programming. (e) Automated performance tests were ran on each code commit to immediately spot any new code causing a performance problem. (f) All code was written from scratch to C89 standards for embedding in the kernel. About a dozen interface functions were identified which allowed us to develop the code in isolation from the appliance, and not have to learn the appliance etc. (g) There was a debug version of the code littered with assert()s and very verbose logging. Therefore, we never needed to use a traditional debugger. The verbose logging allowed us to debug the multi-core code. Regular developers were not allowed to use mutexes etc themselves in source code. Instead, generic higher level constructs were used to achieve multi-core. My impression is that debugging via sophisticated log files is faster than using a debugger. (h) We automated the process of the Makefile so that developers could create new source files and/or libraries on-the-fly without having to understand make voodoo. C header files were also auto generated to increase developer productivity. (i) Naming conventions for folders, files, and C source code were enforced programmatically and by reviews. In this way it was easier for developers to name things and comprehend the code of others. In essence, we created a kind of 'dumbed down' version of C which was approaching being as easy to code in as a high level scripting language. Developers found themselves empowered to write a lot of code very quickly because they could rely on the automated testing to ensure that they hadn't inadvertently broken something, even other parts of the code that they had little idea about. This only worked well because there was a clear architecture and code skeleton. The rest was like 'painting by numbers' for the majority of developers who had little experience with C. The same team went on to develop more C software using the same technique and with great success.
llamas02 11y ago
No room for mistakes. You must be as perfect as I AM!!! Haters are my biggest fans.ha-ha
Flimm 11y ago
Sorry to side-track, but the percentage of people who abstain from sex until marriage or death is far higher than 0.001%, so the comparison isn't really fair.
- coldtea 11y ago
  The "everything gets interpreted literally" though, that the parent wrote, is still spot on.

by defen 11y ago

code4life 11y ago

> This is the "abstinence-only sex education For the record, I don't think your stupid if you have a child accidentally. However, once you do accidentally have a child, the results are often not pretty, and I will feel bad watching as you deal with the consequences of your poorly thought out decision. Regarding programming, I can't see the relationship you make at all. If you write a good program, well good job. If you write a bad program, you are probably going to write a better one next time. (Ever look back at your old code?) It takes practice to get good, and the more we work at it, the better we'll get. Just keep trying.

khedoros 11y ago
I think defen's point was that if a team produces truly high-quality C code, it's similar to a couple that both abstain until marriage. Yes, it's technically possible, but it's rare, and it's not something that should be the expected outcome (that is, most C code will have some problems, and most couples will have at least a little bit of regrettable sexual history before they're married). It's as if I say: "Step 1 of writing good code: Don't make mistakes. If you make mistakes, you deserve what's coming to you!" Some mistakes are expected, and essentially inevitable; they're the default, not the exception. Blaming the programmer might seem like the right thing to do, but there's more practical benefit to improving the tools and teaching programmers how to handle errors, so that we can decrease the negative impact that bugs will have.
defen 11y ago
The point of the analogy is that it is very easy to prescribe behavior that is guaranteed to work if followed 100% to the letter, but fails catastrophically if there is even 1 mistake. There are two responses to this - you can either design systems that are easier to follow & fail less catastrophically in the real world (don't use C for new code if you don't need it; teach people about safe sex practices), OR you can double down on the sermonizing about how if people had just been smarter / had more willpower, they wouldn't be in this bad situation.
- code4life 11y ago
  Yes, but the analogy isn't accurate, in the sense that when things do fail in a C system, it's probably not that hard to fix.
crpatino 11y ago
> However, once you do accidentally have a child, the results are often not pretty... Regarding programming, I can't see the relationship you make at all. I have two words for you: MAINTENANCE PROGRAMER.
- code4life 11y ago
  Ha! Yes, aren't we all.
  - crpatino 11y ago
    It's either that or the life of the grasshopper ;) Now that I think of it, there's another parallel with unwanted pregnancies. There are men that stick around, and there are boys who run and let others clean up after their mess.
    - Roboprog 11y ago
      Would you let your daughter date a contractor???
      - crpatino 11y ago
        Sure, if she was over 25 and fully aware that it is "no strings attached".

caf 11y ago

"out-of-wedlock pregnancies"? What is this, 1953? There are a great number of couples choosing to have children in stable, committed - yet unmarried - relationships.

defen 11y ago
This sums up internet commenting in 2016. Congratulations on entirely missing the point because you chose to focus on an irrelevant and pointless detail, which I'm sure will spawn a stupid subthread that changes no one's mind.
- caf 11y ago
  The great thing about threaded textual commenting is that you can have a sub-thread to discuss a side point, without removing the ability to debate the main point in parallel. The comment struck me as incredibly anachronistic, bordering on offensively so.
  - deleted 11y ago
    [deleted]
  - doktrin 11y ago
    > bordering on offensively so. please don't.
- readymade 11y ago
  And the parent thread will?
- spajus 11y ago
  HN needs "collapse whole thread" feature. Badly.
  - MawNicker 11y ago
    +∞ Way to hijack a useless subthread and do something useful with it. Great meta-point. Honestly. This feature alone makes the comments on Reddit bearable for consumption.

ufo 11y ago

I'm gonna have to steal this analogy. Its impressive how often these dick-measuring arguments pop up.

llamas02 11y ago
Yaaaaa, is this hacked languishing? I love you ALL, so nice, healthy,religious righteousness, one of my favorite subjects, and I would know BEST at it. Just some translation needs to be fixed. I suppose it changes your life and THAT is what count's as positives. Solutions that WORK for the Good. It has to, for our kids. All kids. They're the future. So let's start working like slaves again and get THAT done. Joking.
llamas02 11y ago
Yaaaaa, is this hacked languishing? I love you ALL, so nice, healthy,religious righteousness, one of my favorite subjects, and I would know BEST at it. Just some translation needs to be fixed. I suppose it changes your life and THAT is what count's as positives. Solutions that WORK for the Good. It has to, for our kids. All kids. They're the future. So let's start working like slaves again and get THAT done. Joking.

clock_tower 11y ago

Well, there's a trick to writing C++ with no crashes and no memory corruption: never allocate memory using pointers. If you store all your data in stack variables and STL containers, C++ becomes a _much_ more forgiving language (especially if you also avoid templates and operator overloading). I imagine that this poster and his team took a similar approach with C: avoiding the dangerous features, or just finding ways to factor them out.

humanrebar 11y ago
Even if you do all the things you said, you can still crash a C++ program. Iterator invalidation is very easy to do on accident, for example.

derefr 11y ago

> You're basically saying that everyone just needs to be a top 0.001% C programmer. A more constructive/charitable phrasing of the parent's point might be: you should only be allowed to code in C if you're already a top 0.001% programmer. Then, obviously, all C code will be good—not that there'll be much of it. That's actually a more interesting point than it seems. Programmers generally tend to reject the idea of guilds and "professional" licensing—mostly because, AFAIK, most programs aren't critical and most crashes don't matter. But what if, instead of licensing all programming, we just licensed only low-level programming? What if, as a rule, everyone who was going to be hired to write code in a language with pointers was union-mandated to be certified as knowing how to safely fiddle with pointers? That could probably split on interesting dimensions, like a bunch of regular coders working in e.g. a Rust codebase, with a certified Low Level Programmer needing to "sign off on" any commit that contained unsafe{} code, where the actual failure of the unsafe{} code would get the Low Level Programmer disbarred.

llamas02 11y ago
I have people to do that for me. Thank you for the txt chit chat. Have we met? Maybe we should.
s1m0n 11y ago
Not all C developers need be a top 0.001% C developer to write high performance and rock solid code. Why? I'm a very experienced C programmer and one day my boss came to me and said that the sales guys had already sold a non-existing client side module to a house hold name appliance manufacturer. The deal was inked and it had to be ready in only 3 months. Even worse, it had to run in the Unix kernel of the appliance and therefore be rock solid so as to not take the whole appliance down. It also had to be ultra high performance because the appliance was ultra high performance and very expensive. Now the really bad news: I had a team made up of 3 more experienced C developers (including myself) and 3 very un-experienced C developers. We also estimated that in order to code all the functionality it would take at least 4 months. So we added on another 4 less experienced C developers (the office didn't have a lot of C developers). The project was completed in time, a success, and almost no bugs were found, and yet many developers without much C experience worked on the project. How? (a) No dynamic memory allocation was used at run-time and therefore we never had to worry about memory leaks. (b) Very, very few pointers were used. Instead mainly arrays. And not just C developers understand array syntax, e.g. myarray[i].member = 1 :-) Therefore we never had to worry about invalid pointers. (c) Source changes could only be committed together with automated tests resulting in 100% code coverage and after peer review. This meant that most bugs were discovered immediately after being created but before being checked in to the source repository. We achieved 100% code coverage with an approx. 1:1 ratio of production C source code to test C source code. (d) All code was written using pair programming. (e) Automated performance tests were ran on each code commit to immediately spot any new code causing a performance problem. (f) All code was written from scratch to C89 standards for embedding in the kernel. About a dozen interface functions were identified which allowed us to develop the code in isolation from the appliance, and not have to learn the appliance etc. (g) There was a debug version of the code littered with assert()s and very verbose logging. Therefore, we never needed to use a traditional debugger. The verbose logging allowed us to debug the multi-core code. Regular developers were not allowed to use mutexes etc themselves in source code. Instead, generic higher level constructs were used to achieve multi-core. My impression is that debugging via sophisticated log files is faster than using a debugger. (h) We automated the process of the Makefile so that developers could create new source files and/or libraries on-the-fly without having to understand make voodoo. C header files were also auto generated to increase developer productivity. (i) Naming conventions for folders, files, and C source code were enforced programmatically and by reviews. In this way it was easier for developers to name things and comprehend the code of others. In essence, we created a kind of 'dumbed down' version of C which was approaching being as easy to code in as a high level scripting language. Developers found themselves empowered to write a lot of code very quickly because they could rely on the automated testing to ensure that they hadn't inadvertently broken something, even other parts of the code that they had little idea about. This only worked well because there was a clear architecture and code skeleton. The rest was like 'painting by numbers' for the majority of developers who had little experience with C. The same team went on to develop more C software using the same technique and with great success.

llamas02 11y ago

No room for mistakes. You must be as perfect as I AM!!! Haters are my biggest fans.ha-ha

Flimm 11y ago

Sorry to side-track, but the percentage of people who abstain from sex until marriage or death is far higher than 0.001%, so the comparison isn't really fair.

coldtea 11y ago
The "everything gets interpreted literally" though, that the parent wrote, is still spot on.