5 ms·

The idea that "A good linter, proper programming practices, discipline will get you there" has resulted in "a million code vulnerabilities in C" !! That is a s

The idea that "A good linter, proper programming practices, discipline will get you there" has resulted in "a million code vulnerabilities in C" !! That is a surprising jump in cause-and-effect logic right there. I do not code any C, but I assure you if I did I'd consider it part of proper programming practice and discipline to write code that avoids those exact vulnerabilities you suggest. But, picking a whole new programming language instead is just lying to yourself, because there is no perfect programming language. None! Zero. Not one, no matter how much in love you are with it. They all have their warts, strengths and weaknesses, and if you are not aware of any in your language of choice, and actively working to avoid and mitigate against them (aka discipline and best practice) then you have fallen prey to exactly what I was talking about: the idea that a framework or language is a magical silver bullet to writing clean code. If you thought I was saying JS (or C, TypeScript, Haskel etc) is this perfect, wonderful language, you completely misunderstood me.

nmfisher 7y ago
> I do not code any C, but I assure you if I did I'd consider it part of proper programming practice and discipline to write code that avoids those exact vulnerabilities you suggest. And yet all of those vulnerabilities came from hundreds of developers who shared the same misplaced confidence in their own abilities. It's the same as hospitals. You can't just say "who needs checklists? Surgeons and assistants should be disciplined enough to not make mistakes in the first place!". In an ideal world they would be, but in this world, they're not and never will be. Not being able to admit this is how you end up with surgery on your left knee when it was meant to be your right. Accept that no-one is 100% perfect, 100% of the time - let alone you - and mould your development around these (very human) failings. "Disciplined programming" will never be as safe as "disciplined programming with guard-rails built into the language". Weigh up the trade-offs - sometimes the performance gain is worth the risk, sometimes it's not.
- orange8 7y ago
  > And yet all of those vulnerabilities came from hundreds of developers who shared the same misplaced confidence in their own abilities. This is a good example of a straw man argument. A comment about a programming language or framework not being a silver bullet to clean code has suddenly been twisted into a comment about developers with misplaced confidence in their abilities. How exactly does using best practice in and discipline equate to overconfidence?! good practice and discipline ≠ misplaced confidence
  - jolux 7y ago
    You appear to assume that applying good practice and discipline is a route to eliminating these problems rather than mitigating them.
    - orange8 7y ago
      > You appear to assume I like your choice of words, but no. I disagree with that assumption.
      - jolux 7y ago
        Well, in that case, I will observe that static type systems and memory safety do eliminate the problems of ill-typed programs and memory unsafe programs, and that these are highly desirable properties for a lot of systems.
        orange8 7y ago
        And I will observe, once again, that all that means nothing without best practice and discipline.
        jolux 7y ago
        It doesn't mean nothing without those things though. It means exactly the same whether or not you follow best practices or have discipline, that's the entire point. It will not ensure your code is good, it will merely ensure it does not have those problems.
        orange8 7y ago
        If its about clean code, all that means nothing without discipline and good practice. Clean code is something humans do, not linters, compilers or languages.
        7y ago
jolux 7y ago
You're making a false dichotomy here. There's a lot of light between something being a magical silver bullet that solves all your problems and every programming language being equally bad. If that weren't the case we would probably have never progressed from unstructured programming. In general the greatest progress in software engineering practice at the level of programming languages is made when something that was previously left up to human discipline is made automatic so we don't have to struggle with it anymore: memory safety, type checking, and at the beginning, returning from subroutines at a structured location back to a structured location instead of control flowing wildly throughout a program with jumps. Yes, it's theoretically possible to do all these things well without the assistance of a computer, but in practice, it's more work than any human can handle. The problems that newer programming languages have are an argument for fixing those problems, not reintroducing ones we've already solved.
- orange8 7y ago
  > Typescript. You pretty much need that on any reasonable size project unless you are happy to spend your life tracking down runtime bugs. This is the original grandparent comment I was responding to. To me, this sounds like the belief that only one language can solve a problem which I disagree with. TypeScript is not a silver bullet. They are all just tools. Pick the ones that work for you, but do not go and start preaching about your toolset being the one and only true path to code nirvana. > ...and every programming language being equally bad. I simply did not say that.
  - jolux 7y ago
    >I simply did not say that. No, you're right, what you said is that there is no perfect programming language, and that they all have warts and problems. On that I agree with you, but in this case you seem to be using it to suggest that the language doesn't matter and it's all or even mostly a question of personal discipline, which I completely disagree with. Correct me if I'm wrong. >To me, this sounds like the belief that only one language can solve a problem which I disagree with. I disagree with that interpretation too, but the argument they were actually making was about static type systems, as evidenced by their comment about React and the importance of type checking. TypeScript is merely the most popular typed JavaScript variant. >TypeScript is not a silver bullet. Sure, I would actually prefer a much stronger type system than it provides, but it's certainly better than nothing. >They are all just tools. Sure, but some tools work better than others. >Pick the ones that work for you, but do not go and start preaching about your toolset being the one and only true path to code nirvana. I didn't see the grandparent preaching about "code nirvana" at all. They were making a pretty typical argument about the outsize effectiveness of static types in large codebases. It's entirely possible that programming in a large codebase with TypeScript sucks, but that programming in a large codebase with JavaScript sucks more. There is no perfect programming languages, but there are definitely better ones.

nmfisher 7y ago

> I do not code any C, but I assure you if I did I'd consider it part of proper programming practice and discipline to write code that avoids those exact vulnerabilities you suggest. And yet all of those vulnerabilities came from hundreds of developers who shared the same misplaced confidence in their own abilities. It's the same as hospitals. You can't just say "who needs checklists? Surgeons and assistants should be disciplined enough to not make mistakes in the first place!". In an ideal world they would be, but in this world, they're not and never will be. Not being able to admit this is how you end up with surgery on your left knee when it was meant to be your right. Accept that no-one is 100% perfect, 100% of the time - let alone you - and mould your development around these (very human) failings. "Disciplined programming" will never be as safe as "disciplined programming with guard-rails built into the language". Weigh up the trade-offs - sometimes the performance gain is worth the risk, sometimes it's not.

orange8 7y ago
> And yet all of those vulnerabilities came from hundreds of developers who shared the same misplaced confidence in their own abilities. This is a good example of a straw man argument. A comment about a programming language or framework not being a silver bullet to clean code has suddenly been twisted into a comment about developers with misplaced confidence in their abilities. How exactly does using best practice in and discipline equate to overconfidence?! good practice and discipline ≠ misplaced confidence
- jolux 7y ago
  You appear to assume that applying good practice and discipline is a route to eliminating these problems rather than mitigating them.
  - orange8 7y ago
    > You appear to assume I like your choice of words, but no. I disagree with that assumption.
    - jolux 7y ago
      Well, in that case, I will observe that static type systems and memory safety do eliminate the problems of ill-typed programs and memory unsafe programs, and that these are highly desirable properties for a lot of systems.
      - orange8 7y ago
        And I will observe, once again, that all that means nothing without best practice and discipline.
        jolux 7y ago
        It doesn't mean nothing without those things though. It means exactly the same whether or not you follow best practices or have discipline, that's the entire point. It will not ensure your code is good, it will merely ensure it does not have those problems.
        orange8 7y ago
        If its about clean code, all that means nothing without discipline and good practice. Clean code is something humans do, not linters, compilers or languages.
        7y ago

jolux 7y ago

You're making a false dichotomy here. There's a lot of light between something being a magical silver bullet that solves all your problems and every programming language being equally bad. If that weren't the case we would probably have never progressed from unstructured programming. In general the greatest progress in software engineering practice at the level of programming languages is made when something that was previously left up to human discipline is made automatic so we don't have to struggle with it anymore: memory safety, type checking, and at the beginning, returning from subroutines at a structured location back to a structured location instead of control flowing wildly throughout a program with jumps. Yes, it's theoretically possible to do all these things well without the assistance of a computer, but in practice, it's more work than any human can handle. The problems that newer programming languages have are an argument for fixing those problems, not reintroducing ones we've already solved.

orange8 7y ago
> Typescript. You pretty much need that on any reasonable size project unless you are happy to spend your life tracking down runtime bugs. This is the original grandparent comment I was responding to. To me, this sounds like the belief that only one language can solve a problem which I disagree with. TypeScript is not a silver bullet. They are all just tools. Pick the ones that work for you, but do not go and start preaching about your toolset being the one and only true path to code nirvana. > ...and every programming language being equally bad. I simply did not say that.
- jolux 7y ago
  >I simply did not say that. No, you're right, what you said is that there is no perfect programming language, and that they all have warts and problems. On that I agree with you, but in this case you seem to be using it to suggest that the language doesn't matter and it's all or even mostly a question of personal discipline, which I completely disagree with. Correct me if I'm wrong. >To me, this sounds like the belief that only one language can solve a problem which I disagree with. I disagree with that interpretation too, but the argument they were actually making was about static type systems, as evidenced by their comment about React and the importance of type checking. TypeScript is merely the most popular typed JavaScript variant. >TypeScript is not a silver bullet. Sure, I would actually prefer a much stronger type system than it provides, but it's certainly better than nothing. >They are all just tools. Sure, but some tools work better than others. >Pick the ones that work for you, but do not go and start preaching about your toolset being the one and only true path to code nirvana. I didn't see the grandparent preaching about "code nirvana" at all. They were making a pretty typical argument about the outsize effectiveness of static types in large codebases. It's entirely possible that programming in a large codebase with TypeScript sucks, but that programming in a large codebase with JavaScript sucks more. There is no perfect programming languages, but there are definitely better ones.