4 ms·

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

• 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)
  • jstimpfle 5y ago
    > hacks like “we will always have this struct in another one with a pointer preceding A struct embedded within a different struct gives simply a bigger struct, which is something we have decided is a good idea (as opposed to e.g. attribute lookup in dynamic scripting languages). The unfortunate thing is that there is no way to check statically that an inner struct that you hold in your hand is indeed embedded within a larger thing. But that is the kind of assertion that is incredibly hard to prove in a simple framework without complicating things, so the better idea seems to not do it. (Also it's the kind of assertions that seldom wrong once you've tested a tiny bit). > (text based macros are simply the worst thing ever) Are they? Consider how many actual bugs were caused by text macros, and then consider how many useful things you can do with them that you simply cannot do with AST based macros.
    • kaba0 5y ago
      What about dynamically replacing said inner or outer struct? You get absolutely no insight on the intent of the developer. That’s why actually joining a C project is really hard. C simply sucks at abstraction, and can only manage it through convention, without enforcement. Please show me any IDE that can reliably refactor huge C projects. Compare it to eg. Java. The difference is night and day — what even is the point of text based macros? You have to parse the AST either way, why not manipulate that? And you can say that at the time memory constraint or whatever, but it is simply a terrible idea all around. You are basically running sed through your code.