4 ms·

> Few people are enamored with C, but - the language itself is relatively simple if you don't use pointers, yeah. but like you can't built anything useful with

by merb 5y ago

> Few people are enamored with C, but - the language itself is relatively simple if you don't use pointers, yeah. but like you can't built anything useful without pointers.

b20000 5y ago
if you do not understand pointers and cannot work with them, you probably should not be a software engineer.
- danShumway 5y ago
  I'm not sure that it's the concept of pointers that make C code harder to maintain than other languages. Lots of languages have pointers, including Rust. It's a question of whether unguarded pointers (and a lack of language features that keep pointer math from devolving into an unreadable mess) are good to have in areas where pointer errors can result in critical bugs. We started discouraging goto statements not because developers didn't understand them, but because they did understand them, and they understood that the tools you use influence the type of code you write. And Rust doesn't even really get rid of pointers, it just adds rules around them. We all accept some degree of abstraction/safety tradeoff, otherwise we'd program in lower-level languages than C that are even simpler and even easier to understand. C does introduce a lot of complexity over more primitive assembly languages. And Rust introduces a lot of complexity over C. Different people pick different points where they think the tradeoffs are optimized. But we have a pretty large amount of data suggesting that even <quote>good</quote> programmers in industry make pointer errors in C. So it's pretty obviously not lack of understanding that's causing these issues, it's that unrestricted memory access and pointer math is inherently error-prone. Whether it's SO error-prone that's it's worth introducing a much more complicated, rigid language into the kernel is left as an exercise for the reader. There is a downside to introducing more complexity here, all abstractions have downsides. But it's real dismissive to say that if everyone understood C pointers then their code wouldn't ever devolve into an unreadable mess. I just don't think that's an opinion that can be backed up by any real evidence, pretty much every org struggles to some extent with writing secure C code. And we have a lot of experience in the field of software engineering that should have taught us by now that sometimes unreadable code is the result of language affordances and patterns.
  - afiori 5y ago
    Also there are many different ways to undestand and use pointers; there are many many programmers that are really good at using pointers and are able to engineer essentially safe architechtures, but many of those very good programmers would come up with incompatible architectures around pointer usage. My wild guess is that most "simple" pointer errors (use-after-free, double-free, unintentionally using unitialized memory, ...) happens at interfaces where there isn't perfect comunication about what component is responsible for keeping track of each task.
    - danShumway 5y ago
      Yeah, I think about a very offhand comment that Carmack made once that ended up resonating with me a lot, even though I don't think it's universally across the entire board true: > "Most bugs are a result of the execution state not being exactly what you think it is." There is an aspect of language design that is about making it hard to be surprised by things. And I vaguely suspect that a lot of pointer errors fall into this category; people assume something is being freed, they assume that a subroutine is cleaning up after itself or that it's not manipulating something, or that it doesn't need to call some setup method before it's run. These are boundary errors between interfaces where allowing users to (inadvertently) mask what is happening can lead to logic that feels very convoluted and hard to follow, and can also lead to simple errors around just forgetting to do stuff. I wouldn't call that Carmack quote a mantra, I'm not saying it explains all programming (or that all architectural restrictions are good), it's just a lens that I keep coming back to when I think about language design and architecture; there's a real tradeoff in removing flexibility, but there is also a huge amount of value in systems/patterns that make it very hard to bury relevant information. And if a language can auto-surface some of those problems, that can lead to cleaner code.
- viraptor 5y ago
  It depends what level you mean. Understanding and using pointers on basic way is simple. Understanding pointer provenance, aliasing rules, etc. are a completely different level and people not very familiar with the spec (so almost everyone) do not understand a lot about pointers. http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p1434r0.html http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p1434r0....

by merb 5y ago

> Few people are enamored with C, but - the language itself is relatively simple if you don't use pointers, yeah. but like you can't built anything useful without pointers.

b20000 5y ago

if you do not understand pointers and cannot work with them, you probably should not be a software engineer.

danShumway 5y ago
I'm not sure that it's the concept of pointers that make C code harder to maintain than other languages. Lots of languages have pointers, including Rust. It's a question of whether unguarded pointers (and a lack of language features that keep pointer math from devolving into an unreadable mess) are good to have in areas where pointer errors can result in critical bugs. We started discouraging goto statements not because developers didn't understand them, but because they did understand them, and they understood that the tools you use influence the type of code you write. And Rust doesn't even really get rid of pointers, it just adds rules around them. We all accept some degree of abstraction/safety tradeoff, otherwise we'd program in lower-level languages than C that are even simpler and even easier to understand. C does introduce a lot of complexity over more primitive assembly languages. And Rust introduces a lot of complexity over C. Different people pick different points where they think the tradeoffs are optimized. But we have a pretty large amount of data suggesting that even <quote>good</quote> programmers in industry make pointer errors in C. So it's pretty obviously not lack of understanding that's causing these issues, it's that unrestricted memory access and pointer math is inherently error-prone. Whether it's SO error-prone that's it's worth introducing a much more complicated, rigid language into the kernel is left as an exercise for the reader. There is a downside to introducing more complexity here, all abstractions have downsides. But it's real dismissive to say that if everyone understood C pointers then their code wouldn't ever devolve into an unreadable mess. I just don't think that's an opinion that can be backed up by any real evidence, pretty much every org struggles to some extent with writing secure C code. And we have a lot of experience in the field of software engineering that should have taught us by now that sometimes unreadable code is the result of language affordances and patterns.
- afiori 5y ago
  Also there are many different ways to undestand and use pointers; there are many many programmers that are really good at using pointers and are able to engineer essentially safe architechtures, but many of those very good programmers would come up with incompatible architectures around pointer usage. My wild guess is that most "simple" pointer errors (use-after-free, double-free, unintentionally using unitialized memory, ...) happens at interfaces where there isn't perfect comunication about what component is responsible for keeping track of each task.
  - danShumway 5y ago
    Yeah, I think about a very offhand comment that Carmack made once that ended up resonating with me a lot, even though I don't think it's universally across the entire board true: > "Most bugs are a result of the execution state not being exactly what you think it is." There is an aspect of language design that is about making it hard to be surprised by things. And I vaguely suspect that a lot of pointer errors fall into this category; people assume something is being freed, they assume that a subroutine is cleaning up after itself or that it's not manipulating something, or that it doesn't need to call some setup method before it's run. These are boundary errors between interfaces where allowing users to (inadvertently) mask what is happening can lead to logic that feels very convoluted and hard to follow, and can also lead to simple errors around just forgetting to do stuff. I wouldn't call that Carmack quote a mantra, I'm not saying it explains all programming (or that all architectural restrictions are good), it's just a lens that I keep coming back to when I think about language design and architecture; there's a real tradeoff in removing flexibility, but there is also a huge amount of value in systems/patterns that make it very hard to bury relevant information. And if a language can auto-surface some of those problems, that can lead to cleaner code.
viraptor 5y ago
It depends what level you mean. Understanding and using pointers on basic way is simple. Understanding pointer provenance, aliasing rules, etc. are a completely different level and people not very familiar with the spec (so almost everyone) do not understand a lot about pointers. http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p1434r0.html http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p1434r0....