4 ms·

In other words, if your target has something other than 16/32/64 bit words, or lots of cool SIMD instructions, C has all of the fiddlyness of assembly, and an a

In other words, if your target has something other than 16/32/64 bit words, or lots of cool SIMD instructions, C has all of the fiddlyness of assembly, and an added impedance mismatch, but none of the performance.

rbanffy 6y ago
It is a simple language that teaches simple concepts. After learning the fundamentals of C you have a reasonable understanding of what a simple computer can do at a reasonably low level. BTW, I think it'd be useful to teach assembly of a nice processor (NOT the x86, in any of its incarnations), with some toolbox of useful routines (at least for character output so the student can see something) before one goes into C.
AnimalMuppet 6y ago
And Pascal does work in those situations? Your position seems rather inconsistent...
- chaganated 6y ago
  Specifically addressing his "portable assembly" claim. I made no claim that Pascal was portable assembly. C is only portable assembly when every machine is roughly a VAX of the same generation.
  - rbanffy 6y ago
    I have moved C code from x86 Unix to MIPS Windows CE and the pain was with Windows CE, not MIPS. The compilers very happily abstracted the gory details away and pretty much did what I expected from i386 to MIPS (R2000, I think). And that Unix code was never intended to be ported to anything else.
    - chaganated 6y ago
      That's moving from one VAX-like 32-bit register machine to another, and the target is bi-endian. Migrate to a different word size, or a different endianness, and things get very ugly.
      - icedchai 6y ago
        As usual, it depends. I've ported code between i386 (32-bit, Linux) and POWER (64-bit, big endian, AIX) and it wasn't "very ugly." Yeah, we had some longs that should've been int32_t's but it was hardly rocket science. We missed a few conversions to network byte order, but again, not difficult to fix.
        chaganated 6y ago
        Having to manually find these things is always "very ugly" in my book. If I resolve a few of these problems, and the program seems to work, I will still have nagging doubts about "What did I miss?"
        icedchai 6y ago
        This is true. If I recall, when we worked on the port, we had some "checker" utilities that dumped out the struct name and size of all structures (sizeof(struct...)) on both platforms. The system was heavily based on memory mapped structs and serialization of those structs, so if a length didn't match, it was a bad sign. Fun times.
  - AnimalMuppet 6y ago
    If my target is some weird 56-bit thing, I'm still likely to be able to get a C compiler. It probably won't be a fully-standard C, because it probably won't support int64 types, and maybe not even int8. But that's all right, because in that situation, I probably don't want an int64. I want whatever natural word-size I get with int. The not-quite-standard-ness of the implementation doesn't make it not useful. And, it may be all I can get. I probably can't get a Pascal for that situation. I am somewhat unlikely to be able to get a Rust or an Ada. But I can probably get a C. Especially in embedded systems, you can quite often get a C on the quirky chips, but you can't get anything else. And no, all those machines are not "roughly a VAX of the same generation". Now, that may not be quite the same as your claim, because I'm not going to take my embedded application from an 8085 and drop it unchanged onto my 56-bit oddball. (On the other hand, my 8085 code probably isn't using int64 anyway.) In fact, embedded applications are more non-portable than that, because they always depend on the hardware context, not just on the compiler. Still, you can grab significant functionality from a different machine, modify it sensibly for the new environment, and use it.
    - chaganated 6y ago
      Those are all good pragmatic reasons to use C. Doesn't make C any less of a mistake. A slightly higher semantic level would have spared us so many headaches. To make the choices C made, after LISP, Algol, APL, Pascal... was a very costly punt.
      - AnimalMuppet 6y ago
        Again, I'm mostly coming from embedded systems. I can guarantee you that at least LISP and APL would be totally unsuitable there. They are very much not the languages to model on. Pascal was usable in embedded systems. It was used, even. But compared to C, it was like picking your nose with boxing gloves on. No, in my world at least, you don't want a "slightly higher semantic level". C got it far closer to right than any of the others, even Pascal.
        chaganated 6y ago

rbanffy 6y ago

It is a simple language that teaches simple concepts. After learning the fundamentals of C you have a reasonable understanding of what a simple computer can do at a reasonably low level. BTW, I think it'd be useful to teach assembly of a nice processor (NOT the x86, in any of its incarnations), with some toolbox of useful routines (at least for character output so the student can see something) before one goes into C.

AnimalMuppet 6y ago

And Pascal does work in those situations? Your position seems rather inconsistent...

chaganated 6y ago
Specifically addressing his "portable assembly" claim. I made no claim that Pascal was portable assembly. C is only portable assembly when every machine is roughly a VAX of the same generation.
- rbanffy 6y ago
  I have moved C code from x86 Unix to MIPS Windows CE and the pain was with Windows CE, not MIPS. The compilers very happily abstracted the gory details away and pretty much did what I expected from i386 to MIPS (R2000, I think). And that Unix code was never intended to be ported to anything else.
  - chaganated 6y ago
    That's moving from one VAX-like 32-bit register machine to another, and the target is bi-endian. Migrate to a different word size, or a different endianness, and things get very ugly.
    - icedchai 6y ago
      As usual, it depends. I've ported code between i386 (32-bit, Linux) and POWER (64-bit, big endian, AIX) and it wasn't "very ugly." Yeah, we had some longs that should've been int32_t's but it was hardly rocket science. We missed a few conversions to network byte order, but again, not difficult to fix.
      - chaganated 6y ago
        Having to manually find these things is always "very ugly" in my book. If I resolve a few of these problems, and the program seems to work, I will still have nagging doubts about "What did I miss?"
        icedchai 6y ago
        This is true. If I recall, when we worked on the port, we had some "checker" utilities that dumped out the struct name and size of all structures (sizeof(struct...)) on both platforms. The system was heavily based on memory mapped structs and serialization of those structs, so if a length didn't match, it was a bad sign. Fun times.
- AnimalMuppet 6y ago
  If my target is some weird 56-bit thing, I'm still likely to be able to get a C compiler. It probably won't be a fully-standard C, because it probably won't support int64 types, and maybe not even int8. But that's all right, because in that situation, I probably don't want an int64. I want whatever natural word-size I get with int. The not-quite-standard-ness of the implementation doesn't make it not useful. And, it may be all I can get. I probably can't get a Pascal for that situation. I am somewhat unlikely to be able to get a Rust or an Ada. But I can probably get a C. Especially in embedded systems, you can quite often get a C on the quirky chips, but you can't get anything else. And no, all those machines are not "roughly a VAX of the same generation". Now, that may not be quite the same as your claim, because I'm not going to take my embedded application from an 8085 and drop it unchanged onto my 56-bit oddball. (On the other hand, my 8085 code probably isn't using int64 anyway.) In fact, embedded applications are more non-portable than that, because they always depend on the hardware context, not just on the compiler. Still, you can grab significant functionality from a different machine, modify it sensibly for the new environment, and use it.
  - chaganated 6y ago
    Those are all good pragmatic reasons to use C. Doesn't make C any less of a mistake. A slightly higher semantic level would have spared us so many headaches. To make the choices C made, after LISP, Algol, APL, Pascal... was a very costly punt.
    - AnimalMuppet 6y ago
      Again, I'm mostly coming from embedded systems. I can guarantee you that at least LISP and APL would be totally unsuitable there. They are very much not the languages to model on. Pascal was usable in embedded systems. It was used, even. But compared to C, it was like picking your nose with boxing gloves on. No, in my world at least, you don't want a "slightly higher semantic level". C got it far closer to right than any of the others, even Pascal.
      - chaganated 6y ago