7 ms·

It's pretty hilarious how a good part of the comment section here is some variation of what the article starts out with: Person A: "Programming language X is b

It's pretty hilarious how a good part of the comment section here is some variation of what the article starts out with: Person A: "Programming language X is bad, code written in it is unreadable and horrible." Person B: "No it's not. You can write good code in X, you just have to be disciplined."

pdimitar 5y ago
It is indeed hilarious. Same people that will insist (until their grave apparently) that C is fine and that the OpenSSL guys were idiots for allowing Heartbleed, nevermind the fact that buffer overflows and underflows are literally the No. 1 cause of security problems when working with C... What really ticks me off about those kinds of people is that they are extremely likely to just have been blind about their own mistakes when coding C, while loudly claiming that "you just need to be disciplined".
- TheMonarchist 5y ago
  > buffer overflows and underflows are literally the No. 1 cause of security problems when working with C Why don't these ancient projects just move to C++ for vectors and strings, that do the buffer handling correctly for you? Surely they can run a C++ compiler on any workstation these days?
  - oriolid 5y ago
    The usual and not completely unfounded reasons are - Dependency on huge C++ runtime library and possible ABI problems. Twice so for embedded targets. - Careless use of C++ features can lead to large binaries and unexpected runtime costs. - Lack of judgement and template metaprogramming or even plain polymorphism can lead to code that's really difficult to maintain. - Bad experience with pre-C++11 versions of the language or Windows C++ APIs.
    - TheMonarchist 5y ago
      > Dependency on huge C++ runtime library and possible ABI problems. C++ runtime is hardly huge by modern standards, and the usual resolution to ABI issues is to provide C bindings. > Careless use of C++ -- Lack of judgement -- C doesn't make you immune to any of this. What are buffer overruns if not careless use of C? Edit: Considering that I suggested moving to C++ for vectors and strings, your bringing up of TMP and polymorphism sounds like a strawman argument.
      - oriolid 5y ago
        There are many modern things that run software, are connected to internet even if they shouldn't be and are tiny by modern standards. Just because something runs on servers doesn't mean that it doesn't run on processors that are just enough to run a minimal version of Linux kernel. And, have you ever worked with newbie C++ developers? When it comes to bad judgement, C++ gives a lot more rope and especially rope that's C developers are not familiar with.
        TheMonarchist 5y ago
        > Just because something runs on servers doesn't mean that it doesn't run on processors that are just enough to run a minimal version of Linux kernel. Maybe, but it seems unreasonable to hold the world back because of those systems. > When it comes to bad judgement, C++ gives a lot more rope and especially rope that's C developers are not familiar with. I think one could just ban most of that rope to junior devs. "Don't try to roll your own classes or templates, for getting them right requires both skill and discipline." Also common guidelines ban rope that isn't needed but for implementing the superior alternatives, that are usually found in the standard library. You can still program in a procedural way and use just the low hanging fruits of the STL, that was designed for correctness above all, for Alex Stepanov made it to demonstrate his ideas of generic programming: C++ just happened to make implementing it possible.
        oriolid 5y ago
        You're trying to convince the wrong person. Linus Torvalds is the one you should start from.
  - pdimitar 5y ago
    I'd guess a lot of C projects nowadays have very conservative management (most of which might even be actual programmers) and they could operate under "it works good enough, don't you dare touch it!".
- wglb 5y ago
  Heartbleed was not a memory safety issue.
  - marcosdumay 5y ago
    A buffer overflow isn't a memory safety issue?
    - wglb 5y ago
      A buffer overflow is a simple coding issue, not a C-style memory safetey error.
  - beaconstudios 5y ago
    yes it was - it caused the server to read past the end of a ping message and into unrelated memory.
    - wglb 5y ago
      See how this could have just as well been done in Rust: https://tonyarcieri.com/would-rust-have-prevented-heartbleed-another-look https://tonyarcieri.com/would-rust-have-prevented-heartbleed... Mind you, I am of the firm belief that C is at fault for many of the security vulnerabilities, but this is not one of them.
      - beaconstudios 5y ago
        I'm sure it could, but it was still a memory issue. Rust can have those too.
- pdpi 5y ago
  > and that the OpenSSL guys were idiots for allowing Heartbleed This is the most baffling part for me. I'm yet to figure out who these mythical non-idiots are that would not have fallen for any of the pitfalls that have led to exploits in the last several decades.
  - stackbutterflow 5y ago
    A few years ago I've read a comment on reddit of someone saying that they don't write tests because they don't write bug.
    - JoeyJoJoJr 5y ago
      Reminds me of a comment where someone said they don’t need static type checking because they have never have type related bugs.
  - mindslight 5y ago
    I know a few of them. They're robots. For example https://www.call-cc.org/ https://www.call-cc.org/ Transformation according to logical invariants is basically the goal of compilation. Eschewing compilation creates a treadmill whereby a programmer thinks they're getting a lot done because they're mechanistically spitting out a large volume of code, but really they're acting as an imperfect compiler. See also the large crowd of people writing JVM assembly (aka "Java"), as opposed to using higher level languages like Clojure or Scala. Yes JVM is leaps and bounds ahead of C, just like C is leaps and bounds ahead of machine assembler. But unless you're often writing things that existing compilers cannot, then personally standing in for a compiler is mostly just a way of introducing bugs.
    - pdimitar 5y ago
      Very well put! Thank you, I am stealing some of your quotes. :)
  - pdimitar 5y ago
    Same with me. Worst part is, I actually worked with some of these smug insufferable nerds. Nothing on this Earth can convince them that they can make a mistake. Literally worst possible people to have as colleagues. So glad I don't work with them anymore.
- strictfp 5y ago
  This line of thinking is just an extension of everyday thinking of far too many people. Take nuclear reactors as an example. Some people seem to legitimately think that its possible to eliminate all sources of errors in such an immensely complex system. If there's been an accident, the analysis is generally "we have to add sections in the manual for this specific scenario and we'll be safe", rather than accepting that it's impossible to prevent all errors and that it's merely a question of time before the next anomaly arises.
  - gunfighthacksaw 5y ago
    The trick is to make ‘time before the next anomaly’ large enough to allow future generations a fair crack at solving/preventing it.
  - inglor_cz 5y ago
    "Some people seem to legitimately think that its possible to eliminate all sources of errors in such an immensely complex system." That mostly describes amateurs. Designers of modern reactors generally think along the "let us minimize possible negative effects of a failure" lines. So, no positive void coefficient (a horrible feature of RBMK in Chernobyl), addition of core catchers [0] etc. [0] https://en.wikipedia.org/wiki/Core_catcher https://en.wikipedia.org/wiki/Core_catcher
    - beaconstudios 5y ago
      yes this, good design not only includes means of avoiding failure, but means of failing safely.
  - Jtsummers 5y ago
    People working in systems safety work on (at least) two levels: 1. Physical 2. Social On the physical side they try to establish controls that prevent or mitigate issues or minimize the consequences of them. For instance, a modern reactor (probably, not my domain) is going to be designed in a way that certain meltdown situations can't occur (physically designed to separate reactor materials at certain thresholds, resulting in an automatic shutdown versus manual) or are properly contained (smaller reactors where a runaway reaction is more easily contained with modern materials at a reasonable cost). On the social side there is training, regulatory controls, and an emphasis on safety culture/discipline. Discipline doesn't scale, but you can't totally avoid having it. This would be things like not turning off an alarm because it disrupts your nap (looking at you, Homer J. Simpson), but actually responding to it to determine its legitimacy (related concept: normalization of deviance). They'd also want to look at it from an HCI perspective and minimize false alarms and overwhelming operators with alarms or information that seem to be at the same level of importance, but aren't. So true critical issues are brought to the front as high priority, but less critical issues (ones that should be addressed but are lower priority) won't overwhelm the operator. (I've worked with others on this wrt avionics systems, alarm fatigue is real so you have to be choosy in which things get audible alarms and which get visual alarms.) > If there's been an accident, the analysis is generally "we have to add sections in the manual for this specific scenario and we'll be safe", In my experience, that's a belief held by the prideful and the novices. > rather than accepting that it's impossible to prevent all errors and that it's merely a question of time before the next anomaly arises. Anyone with a modicum of humility or experience will accept this and act accordingly.
rambambram 5y ago
I knew to expect this before I clicked the comments section for this post, haha.
- cle 5y ago
  Sadly this is the case for most topics on HN. Most discussions involve people talking past each other and beating dead horses. Not that it’s unique to HN.
  - pdimitar 5y ago
    Sometimes it's worth beating the dead horse. I would love it if I can eventually shout the "you-just-need-discipline" people to extinction. They should never win this debate. We must be humble and accept it's in our nature to make mistakes and that we should improve and move the area forward, not constantly scream at each other in favour of something impossible like "well just be 100% disciplined 100% of the time, duh".
    - AnimalMuppet 5y ago
      > I would love it if I can eventually shout the "you-just-need-discipline" people to extinction. You shouldn't. They're partly right. You are correct that "just be 100% disciplined 100% of the time" will fail. But "just get a language/compiler smart enough that I don't need discipline" will also fail.
      - pdimitar 5y ago
        Ah, I thought that was a given. You definitely should learn a lot of discipline when you're a junior dev. You should develop eye for details and what feels right or wrong. That takes time and experience and can't be skipped. Speaking from the point of view of a senior dev however, certain practices become ultra tedious and annoying from one point and on. Literal soul crushers.
  - rambambram 5y ago
    I don't know if it's sad. Realizing this is not going to change, but one can change one's own outlook on it. Currently, I use it as a filter: if I see this in a discussion, I know there's nothing for me to learn. And people show their 'true' colors, when they bite on these easy and emotional pseudo-discussions. So I have a free filter that works really well, and I don't have to do anything for it. :)
atoav 5y ago
You also just need to be disciplined to calculate the structural integrity of a bridge in your head, yet civil engineers learned the hard way that bridges collapse independently of how genius they thought they were. Using design systems (languages) that eliminate entire classes of mistakes, because they make them impossible is the rational choice. It is human to make mistakes, but how we learn from the past to prevent mistakes in the future is where you can tell between engineers who truly care and those who are in it for their own ego.
- analog31 5y ago
  Indeed, and it points to why there are multiple languages, because features that eliminate one class of mistakes can make it harder to eliminate another class. For instance, a mistake might be a spelling error in an identifier, or it might be a program that does completely the wrong thing because it was too hard to read, or that does nothing because it took too long to write.
- kaba0 5y ago
  I’m absolutely in support of various compile time enforced constraints on languages, but do not forget that the field we are in has unbounded complexity. So after a certain range they have diminishing returns. (Eg. types are a trivial property that can be checked through arbitrary code bases, but race conditions and a litany of other bugs are not. Introducing harder and harder concepts to try to claim a tiny formal verification will quickly become diminishing returns at the price of a much complex language z)
  - pdimitar 5y ago
    I don't disagree. The problem is that people stop with the better practices (like statically strongly typed languages) and increased coverage/branch testing veeeeeeeeery long before they hit the diminishing returns. That's the crux of the issue most of the times: "eh, good enough". Additionally, I really want us to stop pretending we can program CPUs directly (and I include the higher-level languages here as well, not just machine code and assembly). We can't. We need more declarative languages, e.g. I want to be able to say "I want to open a huge file with scatter-gather mechanics and with these 3 functions piped that do mapping and reduction". Why should we always code this by hand? There are objective best ways to produce this code in most languages. Let's have a DSL library that allows us to express that intent and be done with it and move on to be productive on another task. This is not done enough to this day. Various people and organizations are doing it here and there and to me they are the beacons of our future hope. Everybody else is just banging at their Emacs / VIM in the meantime.

pdimitar 5y ago

It is indeed hilarious. Same people that will insist (until their grave apparently) that C is fine and that the OpenSSL guys were idiots for allowing Heartbleed, nevermind the fact that buffer overflows and underflows are literally the No. 1 cause of security problems when working with C... What really ticks me off about those kinds of people is that they are extremely likely to just have been blind about their own mistakes when coding C, while loudly claiming that "you just need to be disciplined".

TheMonarchist 5y ago
> buffer overflows and underflows are literally the No. 1 cause of security problems when working with C Why don't these ancient projects just move to C++ for vectors and strings, that do the buffer handling correctly for you? Surely they can run a C++ compiler on any workstation these days?
- oriolid 5y ago
  The usual and not completely unfounded reasons are - Dependency on huge C++ runtime library and possible ABI problems. Twice so for embedded targets. - Careless use of C++ features can lead to large binaries and unexpected runtime costs. - Lack of judgement and template metaprogramming or even plain polymorphism can lead to code that's really difficult to maintain. - Bad experience with pre-C++11 versions of the language or Windows C++ APIs.
  - TheMonarchist 5y ago
    > Dependency on huge C++ runtime library and possible ABI problems. C++ runtime is hardly huge by modern standards, and the usual resolution to ABI issues is to provide C bindings. > Careless use of C++ -- Lack of judgement -- C doesn't make you immune to any of this. What are buffer overruns if not careless use of C? Edit: Considering that I suggested moving to C++ for vectors and strings, your bringing up of TMP and polymorphism sounds like a strawman argument.
    - oriolid 5y ago
      There are many modern things that run software, are connected to internet even if they shouldn't be and are tiny by modern standards. Just because something runs on servers doesn't mean that it doesn't run on processors that are just enough to run a minimal version of Linux kernel. And, have you ever worked with newbie C++ developers? When it comes to bad judgement, C++ gives a lot more rope and especially rope that's C developers are not familiar with.
      - TheMonarchist 5y ago
        > Just because something runs on servers doesn't mean that it doesn't run on processors that are just enough to run a minimal version of Linux kernel. Maybe, but it seems unreasonable to hold the world back because of those systems. > When it comes to bad judgement, C++ gives a lot more rope and especially rope that's C developers are not familiar with. I think one could just ban most of that rope to junior devs. "Don't try to roll your own classes or templates, for getting them right requires both skill and discipline." Also common guidelines ban rope that isn't needed but for implementing the superior alternatives, that are usually found in the standard library. You can still program in a procedural way and use just the low hanging fruits of the STL, that was designed for correctness above all, for Alex Stepanov made it to demonstrate his ideas of generic programming: C++ just happened to make implementing it possible.
        oriolid 5y ago
        You're trying to convince the wrong person. Linus Torvalds is the one you should start from.
- pdimitar 5y ago
  I'd guess a lot of C projects nowadays have very conservative management (most of which might even be actual programmers) and they could operate under "it works good enough, don't you dare touch it!".
wglb 5y ago
Heartbleed was not a memory safety issue.
- marcosdumay 5y ago
  A buffer overflow isn't a memory safety issue?
  - wglb 5y ago
    A buffer overflow is a simple coding issue, not a C-style memory safetey error.
- beaconstudios 5y ago
  yes it was - it caused the server to read past the end of a ping message and into unrelated memory.
  - wglb 5y ago
    See how this could have just as well been done in Rust: https://tonyarcieri.com/would-rust-have-prevented-heartbleed-another-look https://tonyarcieri.com/would-rust-have-prevented-heartbleed... Mind you, I am of the firm belief that C is at fault for many of the security vulnerabilities, but this is not one of them.
    - beaconstudios 5y ago
      I'm sure it could, but it was still a memory issue. Rust can have those too.
pdpi 5y ago
> and that the OpenSSL guys were idiots for allowing Heartbleed This is the most baffling part for me. I'm yet to figure out who these mythical non-idiots are that would not have fallen for any of the pitfalls that have led to exploits in the last several decades.
- stackbutterflow 5y ago
  A few years ago I've read a comment on reddit of someone saying that they don't write tests because they don't write bug.
  - JoeyJoJoJr 5y ago
    Reminds me of a comment where someone said they don’t need static type checking because they have never have type related bugs.
- mindslight 5y ago
  I know a few of them. They're robots. For example https://www.call-cc.org/ https://www.call-cc.org/ Transformation according to logical invariants is basically the goal of compilation. Eschewing compilation creates a treadmill whereby a programmer thinks they're getting a lot done because they're mechanistically spitting out a large volume of code, but really they're acting as an imperfect compiler. See also the large crowd of people writing JVM assembly (aka "Java"), as opposed to using higher level languages like Clojure or Scala. Yes JVM is leaps and bounds ahead of C, just like C is leaps and bounds ahead of machine assembler. But unless you're often writing things that existing compilers cannot, then personally standing in for a compiler is mostly just a way of introducing bugs.
  - pdimitar 5y ago
    Very well put! Thank you, I am stealing some of your quotes. :)
- pdimitar 5y ago
  Same with me. Worst part is, I actually worked with some of these smug insufferable nerds. Nothing on this Earth can convince them that they can make a mistake. Literally worst possible people to have as colleagues. So glad I don't work with them anymore.
strictfp 5y ago
This line of thinking is just an extension of everyday thinking of far too many people. Take nuclear reactors as an example. Some people seem to legitimately think that its possible to eliminate all sources of errors in such an immensely complex system. If there's been an accident, the analysis is generally "we have to add sections in the manual for this specific scenario and we'll be safe", rather than accepting that it's impossible to prevent all errors and that it's merely a question of time before the next anomaly arises.
- gunfighthacksaw 5y ago
  The trick is to make ‘time before the next anomaly’ large enough to allow future generations a fair crack at solving/preventing it.
- inglor_cz 5y ago
  "Some people seem to legitimately think that its possible to eliminate all sources of errors in such an immensely complex system." That mostly describes amateurs. Designers of modern reactors generally think along the "let us minimize possible negative effects of a failure" lines. So, no positive void coefficient (a horrible feature of RBMK in Chernobyl), addition of core catchers [0] etc. [0] https://en.wikipedia.org/wiki/Core_catcher https://en.wikipedia.org/wiki/Core_catcher
  - beaconstudios 5y ago
    yes this, good design not only includes means of avoiding failure, but means of failing safely.
- Jtsummers 5y ago
  People working in systems safety work on (at least) two levels: 1. Physical 2. Social On the physical side they try to establish controls that prevent or mitigate issues or minimize the consequences of them. For instance, a modern reactor (probably, not my domain) is going to be designed in a way that certain meltdown situations can't occur (physically designed to separate reactor materials at certain thresholds, resulting in an automatic shutdown versus manual) or are properly contained (smaller reactors where a runaway reaction is more easily contained with modern materials at a reasonable cost). On the social side there is training, regulatory controls, and an emphasis on safety culture/discipline. Discipline doesn't scale, but you can't totally avoid having it. This would be things like not turning off an alarm because it disrupts your nap (looking at you, Homer J. Simpson), but actually responding to it to determine its legitimacy (related concept: normalization of deviance). They'd also want to look at it from an HCI perspective and minimize false alarms and overwhelming operators with alarms or information that seem to be at the same level of importance, but aren't. So true critical issues are brought to the front as high priority, but less critical issues (ones that should be addressed but are lower priority) won't overwhelm the operator. (I've worked with others on this wrt avionics systems, alarm fatigue is real so you have to be choosy in which things get audible alarms and which get visual alarms.) > If there's been an accident, the analysis is generally "we have to add sections in the manual for this specific scenario and we'll be safe", In my experience, that's a belief held by the prideful and the novices. > rather than accepting that it's impossible to prevent all errors and that it's merely a question of time before the next anomaly arises. Anyone with a modicum of humility or experience will accept this and act accordingly.

rambambram 5y ago

I knew to expect this before I clicked the comments section for this post, haha.

cle 5y ago
Sadly this is the case for most topics on HN. Most discussions involve people talking past each other and beating dead horses. Not that it’s unique to HN.
- pdimitar 5y ago
  Sometimes it's worth beating the dead horse. I would love it if I can eventually shout the "you-just-need-discipline" people to extinction. They should never win this debate. We must be humble and accept it's in our nature to make mistakes and that we should improve and move the area forward, not constantly scream at each other in favour of something impossible like "well just be 100% disciplined 100% of the time, duh".
  - AnimalMuppet 5y ago
    > I would love it if I can eventually shout the "you-just-need-discipline" people to extinction. You shouldn't. They're partly right. You are correct that "just be 100% disciplined 100% of the time" will fail. But "just get a language/compiler smart enough that I don't need discipline" will also fail.
    - pdimitar 5y ago
      Ah, I thought that was a given. You definitely should learn a lot of discipline when you're a junior dev. You should develop eye for details and what feels right or wrong. That takes time and experience and can't be skipped. Speaking from the point of view of a senior dev however, certain practices become ultra tedious and annoying from one point and on. Literal soul crushers.
- rambambram 5y ago
  I don't know if it's sad. Realizing this is not going to change, but one can change one's own outlook on it. Currently, I use it as a filter: if I see this in a discussion, I know there's nothing for me to learn. And people show their 'true' colors, when they bite on these easy and emotional pseudo-discussions. So I have a free filter that works really well, and I don't have to do anything for it. :)

atoav 5y ago

You also just need to be disciplined to calculate the structural integrity of a bridge in your head, yet civil engineers learned the hard way that bridges collapse independently of how genius they thought they were. Using design systems (languages) that eliminate entire classes of mistakes, because they make them impossible is the rational choice. It is human to make mistakes, but how we learn from the past to prevent mistakes in the future is where you can tell between engineers who truly care and those who are in it for their own ego.

analog31 5y ago
Indeed, and it points to why there are multiple languages, because features that eliminate one class of mistakes can make it harder to eliminate another class. For instance, a mistake might be a spelling error in an identifier, or it might be a program that does completely the wrong thing because it was too hard to read, or that does nothing because it took too long to write.
kaba0 5y ago
I’m absolutely in support of various compile time enforced constraints on languages, but do not forget that the field we are in has unbounded complexity. So after a certain range they have diminishing returns. (Eg. types are a trivial property that can be checked through arbitrary code bases, but race conditions and a litany of other bugs are not. Introducing harder and harder concepts to try to claim a tiny formal verification will quickly become diminishing returns at the price of a much complex language z)
- pdimitar 5y ago
  I don't disagree. The problem is that people stop with the better practices (like statically strongly typed languages) and increased coverage/branch testing veeeeeeeeery long before they hit the diminishing returns. That's the crux of the issue most of the times: "eh, good enough". Additionally, I really want us to stop pretending we can program CPUs directly (and I include the higher-level languages here as well, not just machine code and assembly). We can't. We need more declarative languages, e.g. I want to be able to say "I want to open a huge file with scatter-gather mechanics and with these 3 functions piped that do mapping and reduction". Why should we always code this by hand? There are objective best ways to produce this code in most languages. Let's have a DSL library that allows us to express that intent and be done with it and move on to be productive on another task. This is not done enough to this day. Various people and organizations are doing it here and there and to me they are the beacons of our future hope. Everybody else is just banging at their Emacs / VIM in the meantime.