5 ms·

> imperative programming is easy to understand by humans It's interesting that you choose C as an example because the absolutely immense numbers of bugs and se

> imperative programming is easy to understand by humans It's interesting that you choose C as an example because the absolutely immense numbers of bugs and security vulnerabilities directly due to C should, alone, lead us to question this. People might feel they understand C, but they're empirically wrong! We can argue about why this is the case or whether it applies to other imperative languages, but it's pretty depressing we're still arguing about whether it is the case...

lordgrenville 5y ago
> the absolutely immense numbers of bugs and security vulnerabilities directly due to C Isn't this simply a result of the absolutely immense amount of C being used in critical systems? Are functional languages empirically more secure?
- chillpenguin 5y ago
  The immense number of C bugs is not merely due to C's popularity. Other languages lead to less buggy and more secure code. This is largely due to memory safety. However, immutability is also known to reduce bugs and be more secure (as many security related bugs are due to mutability). Lastly, superior concurrency constructs also have this bug-reducing effect. That said I haven't looked into empirical studies. But I feel like it is just factually the case, at least for memory safety, that in most other languages you literally are unable to create entire classes of bugs that are possible in C. So just logically thinking about it, I don't even see why you'd need to see empirical studies. It should be quite obvious! Although it'd be cool to see the empirical research too! Maybe someone else can reply with links to studies.
  - mpweiher 5y ago
    > But I feel like it is just factually the case, Aka truthiness. [1] Or when this is asserted for safety, safyness. [2] [1] https://en.wikipedia.org/wiki/Truthiness https://en.wikipedia.org/wiki/Truthiness [2] https://blog.metaobject.com/2014/06/the-safyness-of-static-typing.html https://blog.metaobject.com/2014/06/the-safyness-of-static-t...
    - tikhonj 5y ago
      Memory safety is literally the only relevant topic in this whole thread whose impact isn't "truthy" in that sense! We can measure how many bugs and security vulnerabilities in real projects are memory issues, and we know that a memory safe language would rule those bugs out by construction. And we have! This blog post[1] is a good starting point, linking to a number of studies. Empirical evidence is never perfect, but that's much stronger evidence than we have for the impact of pretty much any other aspect of a programming languages! [1]: https://alexgaynor.net/2020/may/27/science-on-memory-unsafety-and-security/ https://alexgaynor.net/2020/may/27/science-on-memory-unsafet...
    - samatman 5y ago
      Your mistake was taking @chillpenguin at their word when they said "I feel". That was just a hedge, it is factually the case that memory safety eliminates an entire class of bugs. More accurately, it pushes them down to the garbage collector and runtime, where they can be epsilon close to eliminated, instead of rolling fresh ones in each and every program.
jchw 5y ago
I’m a bit sad that people in functional programming circles seem to think this way, because to me, it feels like a pretty flagrant disregard for the obvious. No offense intended at all, but please consider: is it possible you are mentally comparing C with a language that is generally memory safe? Like Lisp or Haskell? Understanding code and programming languages doesn’t prevent you from making mistakes. Advanced type systems can help, but you can put those in imperative languages too, and they do have their own pitfalls and limitations. Obviously, nothing is a panacea. But I think programming paradigms are neither here nor there...
- tikhonj 5y ago
  Yes, it's a function of memory safety. The abstractions C provides for working with memory and the semantics of the language itself are both design choices it makes. Memory safety is one of the few places where we have robust empirical evidence on how it directly prevents bugs and security issues in practice. Robust empirical evidence is fundamentally hard to come by in software engineering research, so when we do have it, it's a strong signal. The conclusion is that C is not simple and that the C model is not somehow "more natural" or a good fit for how people think. This was the core argument of the comment I was responding to and it is simply wrong, regardless of whether we're comparing C to functional languages or to something else. We should collectively not be drawing any conclusions by starting with C as an exemplar of how things should be. Personally, I am certain that other aspects of C also contribute to extra bugs: implicit type coercion, undefined behavior, the C preprocessor and anything to do with concurrency all come to mind. I did not bring those up because we do not have the same kind of strong evidence for their impact and because just one problem of that magnitude should be enough to show that a language is neither simple nor natural. I don't see how any of this is disregarding the obvious. Instead, I am making an obvious point that the original comment somehow disregarded. "Nothing is a panacea" might be true, but that does not mean that some things can't be better and other things can't be worse. C is one of the latter.
- kaba0 5y ago
  C does plenty of things badly - for another language in the same realm, consider Zig. It has sane metaprogramming and it can actually abstract over things without hacks like “we will always have this struct in another one with a pointer preceding it so we can decrement the object pointer” and macro magic (text based macros are simply the worst thing ever)
musicale 5y ago
> immense numbers of bugs and security vulnerabilities directly due to C If K&R were here they might argue that it's perfectly possible to write a memory-safe C compiler, runtime, or abstract machine, and indeed there are multiple examples of same. Certainly memory-safe compilers and runtimes were (and still are) available for Pascal and Object Pascal/Delphi. Unfortunately, from the 1970s to the 2000s memory safety (along with software reliability/security) was often considered much less important than speed and efficiency. Along with this, much C code depends on unreliable assumptions. Of course the speed and efficiency vs. reliability and security trade-off was made in hardware design as well, with predictable results.
- pjmlp 5y ago
  Ironically, one reason that Unisys keeps selling ClearPath MCP (nee Burroughs) it is not that a couple of companies are using a mainframe created in 1961, which anyway has had its evolution path anyway, rather there are security levels where a UNIX clone is just not desired at all.

lordgrenville 5y ago

> the absolutely immense numbers of bugs and security vulnerabilities directly due to C Isn't this simply a result of the absolutely immense amount of C being used in critical systems? Are functional languages empirically more secure?

chillpenguin 5y ago
The immense number of C bugs is not merely due to C's popularity. Other languages lead to less buggy and more secure code. This is largely due to memory safety. However, immutability is also known to reduce bugs and be more secure (as many security related bugs are due to mutability). Lastly, superior concurrency constructs also have this bug-reducing effect. That said I haven't looked into empirical studies. But I feel like it is just factually the case, at least for memory safety, that in most other languages you literally are unable to create entire classes of bugs that are possible in C. So just logically thinking about it, I don't even see why you'd need to see empirical studies. It should be quite obvious! Although it'd be cool to see the empirical research too! Maybe someone else can reply with links to studies.
- mpweiher 5y ago
  > But I feel like it is just factually the case, Aka truthiness. [1] Or when this is asserted for safety, safyness. [2] [1] https://en.wikipedia.org/wiki/Truthiness https://en.wikipedia.org/wiki/Truthiness [2] https://blog.metaobject.com/2014/06/the-safyness-of-static-typing.html https://blog.metaobject.com/2014/06/the-safyness-of-static-t...
  - tikhonj 5y ago
    Memory safety is literally the only relevant topic in this whole thread whose impact isn't "truthy" in that sense! We can measure how many bugs and security vulnerabilities in real projects are memory issues, and we know that a memory safe language would rule those bugs out by construction. And we have! This blog post[1] is a good starting point, linking to a number of studies. Empirical evidence is never perfect, but that's much stronger evidence than we have for the impact of pretty much any other aspect of a programming languages! [1]: https://alexgaynor.net/2020/may/27/science-on-memory-unsafety-and-security/ https://alexgaynor.net/2020/may/27/science-on-memory-unsafet...
  - samatman 5y ago
    Your mistake was taking @chillpenguin at their word when they said "I feel". That was just a hedge, it is factually the case that memory safety eliminates an entire class of bugs. More accurately, it pushes them down to the garbage collector and runtime, where they can be epsilon close to eliminated, instead of rolling fresh ones in each and every program.

jchw 5y ago

I’m a bit sad that people in functional programming circles seem to think this way, because to me, it feels like a pretty flagrant disregard for the obvious. No offense intended at all, but please consider: is it possible you are mentally comparing C with a language that is generally memory safe? Like Lisp or Haskell? Understanding code and programming languages doesn’t prevent you from making mistakes. Advanced type systems can help, but you can put those in imperative languages too, and they do have their own pitfalls and limitations. Obviously, nothing is a panacea. But I think programming paradigms are neither here nor there...

tikhonj 5y ago
Yes, it's a function of memory safety. The abstractions C provides for working with memory and the semantics of the language itself are both design choices it makes. Memory safety is one of the few places where we have robust empirical evidence on how it directly prevents bugs and security issues in practice. Robust empirical evidence is fundamentally hard to come by in software engineering research, so when we do have it, it's a strong signal. The conclusion is that C is not simple and that the C model is not somehow "more natural" or a good fit for how people think. This was the core argument of the comment I was responding to and it is simply wrong, regardless of whether we're comparing C to functional languages or to something else. We should collectively not be drawing any conclusions by starting with C as an exemplar of how things should be. Personally, I am certain that other aspects of C also contribute to extra bugs: implicit type coercion, undefined behavior, the C preprocessor and anything to do with concurrency all come to mind. I did not bring those up because we do not have the same kind of strong evidence for their impact and because just one problem of that magnitude should be enough to show that a language is neither simple nor natural. I don't see how any of this is disregarding the obvious. Instead, I am making an obvious point that the original comment somehow disregarded. "Nothing is a panacea" might be true, but that does not mean that some things can't be better and other things can't be worse. C is one of the latter.
kaba0 5y ago
C does plenty of things badly - for another language in the same realm, consider Zig. It has sane metaprogramming and it can actually abstract over things without hacks like “we will always have this struct in another one with a pointer preceding it so we can decrement the object pointer” and macro magic (text based macros are simply the worst thing ever)

musicale 5y ago

> immense numbers of bugs and security vulnerabilities directly due to C If K&R were here they might argue that it's perfectly possible to write a memory-safe C compiler, runtime, or abstract machine, and indeed there are multiple examples of same. Certainly memory-safe compilers and runtimes were (and still are) available for Pascal and Object Pascal/Delphi. Unfortunately, from the 1970s to the 2000s memory safety (along with software reliability/security) was often considered much less important than speed and efficiency. Along with this, much C code depends on unreliable assumptions. Of course the speed and efficiency vs. reliability and security trade-off was made in hardware design as well, with predictable results.

pjmlp 5y ago
Ironically, one reason that Unisys keeps selling ClearPath MCP (nee Burroughs) it is not that a couple of companies are using a mainframe created in 1961, which anyway has had its evolution path anyway, rather there are security levels where a UNIX clone is just not desired at all.