5 ms·

Instead of “harmful to performance”, why can’t we say “slow”? Harmful should be reserved for things that affect security or privacy e.g. accidentally encourage

Instead of “harmful to performance”, why can’t we say “slow”? Harmful should be reserved for things that affect security or privacy e.g. accidentally encourage bugs like goto does.

dwattttt 1y ago
Only once we convince C developers that a lack of performance isn't inherently harmful.
- DaSHacka 1y ago
  More like Python / JS devs C devs are the few I've met that seem to actually care.
  - amonith 1y ago
    I think you misunderstood. That's exactly the problem. C developers consider slow performance harmful, which is often dumb.
    - 1718627440 1y ago
      Except that's why I use hundreds of C programs every day, but complain about the few python programs and all the sloppy websites.
      - amonith 1y ago
        You do you. Most people don't care about software that much in general. The most important thing is that it does the job and it does it securely. C won't help you with bugs in any shape or form (in fact it's famously bug-friendly), so it often makes more sense to use a tech stack that either helps with those or lowers the cost on the developer side.
        dijit 1y ago
        externalising developer cost onto runtime performance only makes sense if humans will spend more time writing than running (in aggregate). Essentially you’re telling me that the software being made is not useful to many people; because the cost of writing the software (a handful of developers) will spend more time writing the software than their userbase will in executing their software. Otherwise you’re inflicting something on humanity. Dumping toxic waste in a river is much cheaper than properly disposing of it too; yet we understand that we are causing harm to the environment and litigate people who do that. Slow software is fine in low volumes (think: shitting in the woods) but dumping it on huge numbers of users by default is honestly ridiculous (Teams, I’m looking at you: with your expectation to run always and on everyones machine!)
        1718627440 1y ago
        > Most people don't care about software that much in general. This is an example of not caring about the software per se, but only about the outcome. > [C is] in fact it's famously bug-friendly Yes, but as a user I like that. I have a game that from the user-experience seams to have tons of use-after-free bugs. You see that as a user, as strings shown in the UI suddenly turn to garbage and then change very fast. Even with such fatal bugs, the program continues to work, which I like as a user, since I just want to play the game, I don't care if the program is correct. When I want to get rid of these garbage text, I simply close the in-game window and reopen it and everything is fine. On the other side there are games written in Pascal or Java, which might not have that much bugs, but every single null pointer exception is fatal. This led to me not playing the games anymore, because being good and then having the program crash is so frustrating. I rather have it running a bit longer with silent corruption.
        denotational 1y ago
        A null-pointer dereference in C will be just as fatal (modulo optimizations).
        kelnos 1y ago
        I think people also care that software runs reasonably quickly. Among non-technical people, "my Windows is slow" seems to be a common complaint.
  - tialaramex 1y ago
    A language community which so prizes the linked list is in no position to go throwing such stones. Linux lucked out, when you're doing tricky wait free concurrent algorithms that intrusive linked list you hand designed was a good choice. But over in userland you'll find another hand rolled list in somebody's single threaded file parser and oh, the growable array would be fifty times faster, shame the C programmer doesn't have one in their toolbox.
jayd16 1y ago
"Considered harmful" is a meme they're referencing but yeah...its pretty stale at this point.
- Agingcoder 1y ago
  To me it’s not a meme, it’s a reference to a very famous letter by dijkstra regarding goto statements. https://en.wikipedia.org/wiki/Considered_harmful https://en.wikipedia.org/wiki/Considered_harmful
  - tialaramex 1y ago
    Not really "goto statements" so much as the go-to arbitrary control flow semantic aka jump. C's goto is a housecat to the full blown jump's tiger. No doubt an angry housecat is a nuisance but the tiger is much more dangerous. C goto won't let you jump straight into the middle of unrelated code, for example, but the jump instruction has no such limit and neither did the feature Dijkstra was discussing.
  - jayd16 1y ago
    That is the meme.
  - bmn__ 1y ago
    You want to object because of a misunderstanding. The usage of the word meme here is correct in its original sense. The word cliche would also work.
sim7c00 1y ago
maybe its not 'slow' but more 'generalized for a wide range of use-cases'? - because is it really slow for what it does, or simply slower compared to a specialized implementation? (this is calling a regular person car slow compared to an F1 car... sure the thing is fast but good luck takin ur kids on holiday or doing weekly shopping runs?)
- masklinn 1y ago
  “Generalised to a wide range of use cases” is a really strange way to say “unsuitable to most multi-threaded programs”. In 2025 an allocator not cratering multi-threaded programs is the opposite of specialisation.
  - flohofwoe 1y ago
    It only matters when your threads allocate with such a high frequency that they run into contention. A too high access frequency to a shared resource is not a "general case", but simply poorly designed multithreaded code (but besides, a high allocation frequency through the system allocator is also poor design for any single-threaded code, application code simply should not assume any specific performance behaviour from the system allocator).
    - Joker_vD 1y ago
      Well, what is "such a high frequency"? Different allocators have different breaking points, and the musl's one is apparently very low. > application code simply should not assume any specific performance behaviour from the system allocator Technically, yes. Practically, no; that's why e.g. C++ standard mandates time complexity of its containers. If you can't assume any specific performance from your system, that means you have to prepare for every system-provided functionality to be exponentially slow and obviously you can't do that. Take, for instance, the JSON parser in GTA V [0]: apparently, sscanf(buffer, "%d", &n) calls strlen(buffer) internally, so using it to parse numbers in a hot loop on 2 MiB-long JSON craters your performance. On one hand, sure, one can argue that glibc/musl developers are within their right to implement sscanf however inefficiently they want, and the application developers should not expect any performance targets from it, and therefore, probably should not use it. On the other hand, what is even the point of the standard library if you're not supposed to use it for anything practical? Or, for that matter, why waste your time writing an implementation that no-one should use for anything practical anyhow, due to its abysmal performance? [0] https://news.ycombinator.com/item?id=26296339 https://news.ycombinator.com/item?id=26296339

Instead of “harmful to performance”, why can’t we say “slow”? Harmful should be reserved for things that affect security or privacy e.g. accidentally encourage bugs like goto does.

dwattttt 1y ago

Only once we convince C developers that a lack of performance isn't inherently harmful.

DaSHacka 1y ago
More like Python / JS devs C devs are the few I've met that seem to actually care.
- amonith 1y ago
  I think you misunderstood. That's exactly the problem. C developers consider slow performance harmful, which is often dumb.
  - 1718627440 1y ago
    Except that's why I use hundreds of C programs every day, but complain about the few python programs and all the sloppy websites.
    - amonith 1y ago
      You do you. Most people don't care about software that much in general. The most important thing is that it does the job and it does it securely. C won't help you with bugs in any shape or form (in fact it's famously bug-friendly), so it often makes more sense to use a tech stack that either helps with those or lowers the cost on the developer side.
      - dijit 1y ago
        externalising developer cost onto runtime performance only makes sense if humans will spend more time writing than running (in aggregate). Essentially you’re telling me that the software being made is not useful to many people; because the cost of writing the software (a handful of developers) will spend more time writing the software than their userbase will in executing their software. Otherwise you’re inflicting something on humanity. Dumping toxic waste in a river is much cheaper than properly disposing of it too; yet we understand that we are causing harm to the environment and litigate people who do that. Slow software is fine in low volumes (think: shitting in the woods) but dumping it on huge numbers of users by default is honestly ridiculous (Teams, I’m looking at you: with your expectation to run always and on everyones machine!)
      - 1718627440 1y ago
        > Most people don't care about software that much in general. This is an example of not caring about the software per se, but only about the outcome. > [C is] in fact it's famously bug-friendly Yes, but as a user I like that. I have a game that from the user-experience seams to have tons of use-after-free bugs. You see that as a user, as strings shown in the UI suddenly turn to garbage and then change very fast. Even with such fatal bugs, the program continues to work, which I like as a user, since I just want to play the game, I don't care if the program is correct. When I want to get rid of these garbage text, I simply close the in-game window and reopen it and everything is fine. On the other side there are games written in Pascal or Java, which might not have that much bugs, but every single null pointer exception is fatal. This led to me not playing the games anymore, because being good and then having the program crash is so frustrating. I rather have it running a bit longer with silent corruption.
        denotational 1y ago
        A null-pointer dereference in C will be just as fatal (modulo optimizations).
      - kelnos 1y ago
        I think people also care that software runs reasonably quickly. Among non-technical people, "my Windows is slow" seems to be a common complaint.
- tialaramex 1y ago
  A language community which so prizes the linked list is in no position to go throwing such stones. Linux lucked out, when you're doing tricky wait free concurrent algorithms that intrusive linked list you hand designed was a good choice. But over in userland you'll find another hand rolled list in somebody's single threaded file parser and oh, the growable array would be fifty times faster, shame the C programmer doesn't have one in their toolbox.

jayd16 1y ago

"Considered harmful" is a meme they're referencing but yeah...its pretty stale at this point.

Agingcoder 1y ago
To me it’s not a meme, it’s a reference to a very famous letter by dijkstra regarding goto statements. https://en.wikipedia.org/wiki/Considered_harmful https://en.wikipedia.org/wiki/Considered_harmful
- tialaramex 1y ago
  Not really "goto statements" so much as the go-to arbitrary control flow semantic aka jump. C's goto is a housecat to the full blown jump's tiger. No doubt an angry housecat is a nuisance but the tiger is much more dangerous. C goto won't let you jump straight into the middle of unrelated code, for example, but the jump instruction has no such limit and neither did the feature Dijkstra was discussing.
- jayd16 1y ago
  That is the meme.
- bmn__ 1y ago
  You want to object because of a misunderstanding. The usage of the word meme here is correct in its original sense. The word cliche would also work.

sim7c00 1y ago

maybe its not 'slow' but more 'generalized for a wide range of use-cases'? - because is it really slow for what it does, or simply slower compared to a specialized implementation? (this is calling a regular person car slow compared to an F1 car... sure the thing is fast but good luck takin ur kids on holiday or doing weekly shopping runs?)

masklinn 1y ago
“Generalised to a wide range of use cases” is a really strange way to say “unsuitable to most multi-threaded programs”. In 2025 an allocator not cratering multi-threaded programs is the opposite of specialisation.
- flohofwoe 1y ago
  It only matters when your threads allocate with such a high frequency that they run into contention. A too high access frequency to a shared resource is not a "general case", but simply poorly designed multithreaded code (but besides, a high allocation frequency through the system allocator is also poor design for any single-threaded code, application code simply should not assume any specific performance behaviour from the system allocator).
  - Joker_vD 1y ago
    Well, what is "such a high frequency"? Different allocators have different breaking points, and the musl's one is apparently very low. > application code simply should not assume any specific performance behaviour from the system allocator Technically, yes. Practically, no; that's why e.g. C++ standard mandates time complexity of its containers. If you can't assume any specific performance from your system, that means you have to prepare for every system-provided functionality to be exponentially slow and obviously you can't do that. Take, for instance, the JSON parser in GTA V [0]: apparently, sscanf(buffer, "%d", &n) calls strlen(buffer) internally, so using it to parse numbers in a hot loop on 2 MiB-long JSON craters your performance. On one hand, sure, one can argue that glibc/musl developers are within their right to implement sscanf however inefficiently they want, and the application developers should not expect any performance targets from it, and therefore, probably should not use it. On the other hand, what is even the point of the standard library if you're not supposed to use it for anything practical? Or, for that matter, why waste your time writing an implementation that no-one should use for anything practical anyhow, due to its abysmal performance? [0] https://news.ycombinator.com/item?id=26296339 https://news.ycombinator.com/item?id=26296339