4 ms·

C is literally "high level assembly" and therefore lacks any guard rails you'd expect in a programming language. It's just unfortunate that so many software dev

C is literally "high level assembly" and therefore lacks any guard rails you'd expect in a programming language. It's just unfortunate that so many software developers embraced C for its speed, even when it wasn't strictly needed. I always remind people that C is a systems programming language and not fit for regular application programming. For that you need an application programming language like Pascal or Java.

sitzkrieg 2mo ago
yea, we certainly wouldn’t want regular user applications to run fast or respect user resources. can’t have that
- hn_submit 2mo ago
  I, for one, can't see any speed difference between a program written in Pascal (Total Commander, which I use every day) and one written in C++ (Windows Explorer).
  - asdff 2mo ago
    You can’t compare apples to elephants here.
  - leptons 2mo ago
    File browsers are probably the worst example you could use here. The actual file manipulations are handled by the OS. The rest of it is just displaying lists of files, so no real speed difference would be noticed in different languages/programs. Most of the time the file browser is just sitting there waiting for user interaction. The programs that do benefit from speed aren't file browsers.
    - Alpha3031 2mo ago
      There are a lot of applications like that though, only they're all being rewritten for electron.
    - hn_submit 2mo ago
      It's the only example I could come up with. There aren't that many programs written in Pascal.
- krior 2mo ago
  false dichtonomy
- Dylan16807 2mo ago
  Even if that was the tradeoff, your average C/C++ program isn't notably fast or lean.
  - uecker 2mo ago
    The C programs I use daily are generally very fast, very lean and very stable: Programs such as linux, terminals, shells, vim, etc.
    - dzhiurgis 2mo ago
      Most programmers don’t have 30 years to perfect their code
      - uecker 2mo ago
        It had no crash during 30 years, not after 30 years.
        fluffybucktsnek 2mo ago
        I did, in Linux. It was pretty common too. It got fix. But, every now and then, I still get an occasional panic. I also recall having my shell crashing (zsh or bash, I don't remember).
        uecker 2mo ago
        I certainly also remember the kernel crashing, but this was in the 90s. Later perhaps once or twice on faulty hardware. Shell, I don't think I have seen this ever.
        fluffybucktsnek 2mo ago
        In my case, the crashes were from last year to the start of this one. Some were related to AMDGPU, others to my WiFi card driver, so they're pretty recent. I don't quite remember the details of the shell crash, I only remember it being on a tool that've never seem crash due to a fault signal. It was somewhat amusing.
- xigoi 2mo ago
  You can have that without writing them in C or C++.
  - sitzkrieg 2mo ago
    you sure can. i recommend forth
emilfihlman 2mo ago
>therefore lacks any guard rails you'd expect in a programming language This is simply not true. Guardrails are enforced by the compiler, and both gcc and clang have a myriad of flags to make C safe, not to mention Fil-C.
inigyou 2mo ago
C should be considered powerful, more than fast. Part of that power is that it doesn't try to stop you from going so fast it's unsafe. But that's just one way you can choose to use your power.
xyzsparetimexyz 2mo ago
How is it high level assembly? Have you written much assembly recently?
- jkrejcha 2mo ago
  C is very much a "high level/portable assembly" type language still and there's really no sign that it'll change from that. Even if it has ostensibly has abstract semantics, many operations map to 1 or a few assembly instructions and much C code, even when not strictly conforming (as all but the most trivial examples are), is conforming enough that it's portable amongst most relevant targets For example, I kinda know that the code for (size_t i = 0; i < 64; i++) { // ... } ...will map to something that roughly that, on x86 will (in most cases) probably do a compare and jump, etc, for the loop body, vectorization and some other optimizations notwithstanding. I know a similar thing will happen on PPC, ARM, etc. This relationship breaks down a bit with a lot of higher level languages where what you want to occur is higher level. This can be both a blessing and a curse; it can enable easier opportunities for optimization but may also may make automatic things downright pessimizied with very very very large effort and expenditure to get things close to usable.
  - xyzsparetimexyz 2mo ago
    No, you don't know what that code will do. Depending on the inner block, it'll most likely be vectorized. Like I said, it's significantly higher level than assembly.
    - jkrejcha 2mo ago
      I don't really agree here. Setting aside the question of how often a compiler can vectorize a loop, because I do think it's not totally relevant here, as you still don't really have the language builtin stuff that other languages do. You really do have to write the code that iterates over a list and applies a transformation, you can't just do [x + y for a.x, a.y in b] ...in C, you have to iterate over the array. And you don't tend to have that much to help you. Most dialects of C don't have exceptions for instance (unless you invent your own). And in general, most of the time, non-trivial loops just... won't autovectorize and it can be a bit finnicky to nudge it in the right direction. Take, for example, Ghidra. It has a feature to decompile blocks of code into C(++). Other reverse engineering tools follow suit. Even in C, it's very possible to model assembly instructions that don't have a 1-to-1 mapping to a particular language construct as a function call (and this is what these do). But, there is a reason that, even with all of the architectural differences in the world, whether it be x86, x86-64, PPC, ARM, RISC-V, Xtensa, MIPS, etc, that you can provide a mapping that goes in 1 way (from source to object code) and also the other way (from object code to """source"""). It'd be much more difficult to do that with other languages, especially in an idiomatic fashion.

sitzkrieg 2mo ago

yea, we certainly wouldn’t want regular user applications to run fast or respect user resources. can’t have that

hn_submit 2mo ago
I, for one, can't see any speed difference between a program written in Pascal (Total Commander, which I use every day) and one written in C++ (Windows Explorer).
- asdff 2mo ago
  You can’t compare apples to elephants here.
- leptons 2mo ago
  File browsers are probably the worst example you could use here. The actual file manipulations are handled by the OS. The rest of it is just displaying lists of files, so no real speed difference would be noticed in different languages/programs. Most of the time the file browser is just sitting there waiting for user interaction. The programs that do benefit from speed aren't file browsers.
  - Alpha3031 2mo ago
    There are a lot of applications like that though, only they're all being rewritten for electron.
  - hn_submit 2mo ago
    It's the only example I could come up with. There aren't that many programs written in Pascal.
krior 2mo ago
false dichtonomy
Dylan16807 2mo ago
Even if that was the tradeoff, your average C/C++ program isn't notably fast or lean.
- uecker 2mo ago
  The C programs I use daily are generally very fast, very lean and very stable: Programs such as linux, terminals, shells, vim, etc.
  - dzhiurgis 2mo ago
    Most programmers don’t have 30 years to perfect their code
    - uecker 2mo ago
      It had no crash during 30 years, not after 30 years.
      - fluffybucktsnek 2mo ago
        I did, in Linux. It was pretty common too. It got fix. But, every now and then, I still get an occasional panic. I also recall having my shell crashing (zsh or bash, I don't remember).
        uecker 2mo ago
        I certainly also remember the kernel crashing, but this was in the 90s. Later perhaps once or twice on faulty hardware. Shell, I don't think I have seen this ever.
        fluffybucktsnek 2mo ago
        In my case, the crashes were from last year to the start of this one. Some were related to AMDGPU, others to my WiFi card driver, so they're pretty recent. I don't quite remember the details of the shell crash, I only remember it being on a tool that've never seem crash due to a fault signal. It was somewhat amusing.
xigoi 2mo ago
You can have that without writing them in C or C++.
- sitzkrieg 2mo ago
  you sure can. i recommend forth

emilfihlman 2mo ago

>therefore lacks any guard rails you'd expect in a programming language This is simply not true. Guardrails are enforced by the compiler, and both gcc and clang have a myriad of flags to make C safe, not to mention Fil-C.

inigyou 2mo ago

C should be considered powerful, more than fast. Part of that power is that it doesn't try to stop you from going so fast it's unsafe. But that's just one way you can choose to use your power.

xyzsparetimexyz 2mo ago

How is it high level assembly? Have you written much assembly recently?

jkrejcha 2mo ago
C is very much a "high level/portable assembly" type language still and there's really no sign that it'll change from that. Even if it has ostensibly has abstract semantics, many operations map to 1 or a few assembly instructions and much C code, even when not strictly conforming (as all but the most trivial examples are), is conforming enough that it's portable amongst most relevant targets For example, I kinda know that the code for (size_t i = 0; i < 64; i++) { // ... } ...will map to something that roughly that, on x86 will (in most cases) probably do a compare and jump, etc, for the loop body, vectorization and some other optimizations notwithstanding. I know a similar thing will happen on PPC, ARM, etc. This relationship breaks down a bit with a lot of higher level languages where what you want to occur is higher level. This can be both a blessing and a curse; it can enable easier opportunities for optimization but may also may make automatic things downright pessimizied with very very very large effort and expenditure to get things close to usable.
- xyzsparetimexyz 2mo ago
  No, you don't know what that code will do. Depending on the inner block, it'll most likely be vectorized. Like I said, it's significantly higher level than assembly.
  - jkrejcha 2mo ago
    I don't really agree here. Setting aside the question of how often a compiler can vectorize a loop, because I do think it's not totally relevant here, as you still don't really have the language builtin stuff that other languages do. You really do have to write the code that iterates over a list and applies a transformation, you can't just do [x + y for a.x, a.y in b] ...in C, you have to iterate over the array. And you don't tend to have that much to help you. Most dialects of C don't have exceptions for instance (unless you invent your own). And in general, most of the time, non-trivial loops just... won't autovectorize and it can be a bit finnicky to nudge it in the right direction. Take, for example, Ghidra. It has a feature to decompile blocks of code into C(++). Other reverse engineering tools follow suit. Even in C, it's very possible to model assembly instructions that don't have a 1-to-1 mapping to a particular language construct as a function call (and this is what these do). But, there is a reason that, even with all of the architectural differences in the world, whether it be x86, x86-64, PPC, ARM, RISC-V, Xtensa, MIPS, etc, that you can provide a mapping that goes in 1 way (from source to object code) and also the other way (from object code to """source"""). It'd be much more difficult to do that with other languages, especially in an idiomatic fashion.