4 ms·

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 chec

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.

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.