5 ms·

C was the mistake we made before we knew the problem space. C++ is the mistake we made afterwards. Which is worse? I say the latter. Start teaching Pascal!

rbanffy 6y ago
C is a low-level language and extremely valuable as such. It's also conceptually simple and should be treated as slightly smarter and portable assembly. And we shouldn't call a pointer to an array of char a string, because it's not a string.
- chaganated 6y ago
  C definitely isn't portable assembly. For the most part, it has locked computing into the late-70s VAX ISA, then C++ just dug the hole deeper. And last I checked, Pascal has both PChar and PByte. Much better than C where both are called *char.
  - rbanffy 6y ago
    > it has locked computing into the late-70s VAX ISA It implements a very simple metaphor for a computer. One that's useful for teaching how a computer works. For more complicated things the mismatch starts to show. Maybe, at that point, it'd be time to teach other languages that can build upon the understanding of how a simple computer works. > And last I checked, Pascal has both PChar and PByte. Much better than C where both are called *char. The computer doesn't know the difference between a byte and a char. Usually, it doesn't even know what a char is.
    - chaganated 6y ago
      It is an overly-primitive metaphor for a computer--one that has pulled most hardware down to its level. The B5000 people understood this before the mistake was made. The PARC and Symbolics people understood this during/after the mistake was made. The computer may not know the difference, but having a way to let the compiler distinguish between the two opens up so many avenues for compile-time checks, smoother migration paths (i.e. ASCII/UTF-16/UTF-8), and better optimizations.
      - rbanffy 6y ago
        > but having a way to let the compiler distinguish between the two But then you are using the language to teach the language. I think C is most valuable to teach how a simple computer works as a foundation for exploring what more interesting computers could do and how we could program them (at this point, probably in languages that better match the abstraction you want).
        chaganated 6y ago
        I've been doing industrial systems in C for 20 years. It stopped being a good model of how computers work around the same time we stopped hooking them up to TVs with RF splitters. I would rather not inflict that brain damage upon the children. If any of them want to start writing drivers, I'm sure they will take to pointer arithmetic like ducks to water--with or without C.
    - chaganated 6y ago
      Take map/reduce for example. Totally do-able as a hardware implementation. Added bonus being that branch prediction would be greatly simplified (from a heuristic and/or dual-execution scenario down to a simple counter). That we have to do crap like `for(i=0;i<n;i++)` just to iterate an array, or this kind of insanity https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/strncpy-strncpy-l-wcsncpy-wcsncpy-l-mbsncpy-mbsncpy-l?view=msvc-160 https://docs.microsoft.com/en-us/cpp/c-runtime-library/refer... to handle strings is nuts. Having to state your solution in such primitive terms is throwing away information--the kind that an ever-so-slightly-improved compiler could use to great effect.
      - rbanffy 6y ago
        > Take map/reduce for example. Totally do-able as a hardware implementation Not sure I follow. The hardware would have to know a lot about how your arrays are organized and how they'd map (or not) to your SIMD instructions. The compiler, at this level, is generating instructions that are no longer very close to the code you wrote.
        chaganated 6y ago
        For a language with richer semantics (i.e. a string type with built-in operators instead add-on libraries implemented at a lower semantic level), the compiler has a better idea of what we are trying to do. If we only have a minimal RISC instruction set, it can generate a large batch of RISC instructions. If we have a wizard SIMD instruction to speed things up, we have a higher likelihood of being able to put it to use. For languages of a lower semantic level (just a wrapper over loads, stores, and arithmetic), making a compiler that can figure out whether the source is a good candidate for a particular hardware feature can be an intractable problem.
- chaganated 6y ago
  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.
- kazinator 6y ago
  ISO C 99, first sentence of Library clause: "A string is a contiguous sequence of characters terminated by and including the first null character." later in the paragraph: "A pointer to a string is a pointer to its initial (lowest addressed) character." The italics indicate that a normative definition is being given. So, the official C terminology is that a pointer to a null-terminated char array is a "pointer to a string".
  - rbanffy 6y ago
    I know that. We do call them strings. We really shouldn't.
    - deleted 6y ago
      [deleted]
icedchai 6y ago
They taught Pascal in the 80's and 90's. My AP Computer Science class used Pascal. Though by that point, I had already taught myself C so didn't think very highly of it...
- chaganated 6y ago
  I went from Turbo Pascal at home to C++ in college, and it felt like a huge downgrade--especially on strings: https://borlandpascal.fandom.com/wiki/String_operations https://borlandpascal.fandom.com/wiki/String_operations And I did a lot of low-level stuff in in too! It was a long time ago, but I don't recall it being any better or worse than C++ when it was pointer time.

rbanffy 6y ago

C is a low-level language and extremely valuable as such. It's also conceptually simple and should be treated as slightly smarter and portable assembly. And we shouldn't call a pointer to an array of char a string, because it's not a string.

chaganated 6y ago
C definitely isn't portable assembly. For the most part, it has locked computing into the late-70s VAX ISA, then C++ just dug the hole deeper. And last I checked, Pascal has both PChar and PByte. Much better than C where both are called *char.
- rbanffy 6y ago
  > it has locked computing into the late-70s VAX ISA It implements a very simple metaphor for a computer. One that's useful for teaching how a computer works. For more complicated things the mismatch starts to show. Maybe, at that point, it'd be time to teach other languages that can build upon the understanding of how a simple computer works. > And last I checked, Pascal has both PChar and PByte. Much better than C where both are called *char. The computer doesn't know the difference between a byte and a char. Usually, it doesn't even know what a char is.
  - chaganated 6y ago
    It is an overly-primitive metaphor for a computer--one that has pulled most hardware down to its level. The B5000 people understood this before the mistake was made. The PARC and Symbolics people understood this during/after the mistake was made. The computer may not know the difference, but having a way to let the compiler distinguish between the two opens up so many avenues for compile-time checks, smoother migration paths (i.e. ASCII/UTF-16/UTF-8), and better optimizations.
    - rbanffy 6y ago
      > but having a way to let the compiler distinguish between the two But then you are using the language to teach the language. I think C is most valuable to teach how a simple computer works as a foundation for exploring what more interesting computers could do and how we could program them (at this point, probably in languages that better match the abstraction you want).
      - chaganated 6y ago
        I've been doing industrial systems in C for 20 years. It stopped being a good model of how computers work around the same time we stopped hooking them up to TVs with RF splitters. I would rather not inflict that brain damage upon the children. If any of them want to start writing drivers, I'm sure they will take to pointer arithmetic like ducks to water--with or without C.
  - chaganated 6y ago
    Take map/reduce for example. Totally do-able as a hardware implementation. Added bonus being that branch prediction would be greatly simplified (from a heuristic and/or dual-execution scenario down to a simple counter). That we have to do crap like `for(i=0;i<n;i++)` just to iterate an array, or this kind of insanity https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/strncpy-strncpy-l-wcsncpy-wcsncpy-l-mbsncpy-mbsncpy-l?view=msvc-160 https://docs.microsoft.com/en-us/cpp/c-runtime-library/refer... to handle strings is nuts. Having to state your solution in such primitive terms is throwing away information--the kind that an ever-so-slightly-improved compiler could use to great effect.
    - rbanffy 6y ago
      > Take map/reduce for example. Totally do-able as a hardware implementation Not sure I follow. The hardware would have to know a lot about how your arrays are organized and how they'd map (or not) to your SIMD instructions. The compiler, at this level, is generating instructions that are no longer very close to the code you wrote.
      - chaganated 6y ago
        For a language with richer semantics (i.e. a string type with built-in operators instead add-on libraries implemented at a lower semantic level), the compiler has a better idea of what we are trying to do. If we only have a minimal RISC instruction set, it can generate a large batch of RISC instructions. If we have a wizard SIMD instruction to speed things up, we have a higher likelihood of being able to put it to use. For languages of a lower semantic level (just a wrapper over loads, stores, and arithmetic), making a compiler that can figure out whether the source is a good candidate for a particular hardware feature can be an intractable problem.
chaganated 6y ago
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.
kazinator 6y ago
ISO C 99, first sentence of Library clause: "A string is a contiguous sequence of characters terminated by and including the first null character." later in the paragraph: "A pointer to a string is a pointer to its initial (lowest addressed) character." The italics indicate that a normative definition is being given. So, the official C terminology is that a pointer to a null-terminated char array is a "pointer to a string".
- rbanffy 6y ago
  I know that. We do call them strings. We really shouldn't.
  - deleted 6y ago
    [deleted]

icedchai 6y ago

They taught Pascal in the 80's and 90's. My AP Computer Science class used Pascal. Though by that point, I had already taught myself C so didn't think very highly of it...

chaganated 6y ago
I went from Turbo Pascal at home to C++ in college, and it felt like a huge downgrade--especially on strings: https://borlandpascal.fandom.com/wiki/String_operations https://borlandpascal.fandom.com/wiki/String_operations And I did a lot of low-level stuff in in too! It was a long time ago, but I don't recall it being any better or worse than C++ when it was pointer time.