6 ms·

I wonder if Allen considered that there might be a reason people chose to use C, it's not as if they were forced into it. "Something where experts can really fi

I wonder if Allen considered that there might be a reason people chose to use C, it's not as if they were forced into it. "Something where experts can really fine-tune without big bottlenecks" is not a requirement specific to operating systems. It's a bit ironic to think that the inability to run fancy optimizations is considered a problem with C when one of the most widely recognized flaws in the C ecosystem is the way mainstream compilers will exploit behavior that was labeled "undefined" just to support old obscure architectures, to run all kinds of crazy transformations.

pjmlp 7y ago
The same reason people got to choose JavaScript or PHP years later, the platform's adoption, in this case UNIX.
- jacquesm 7y ago
  I don't think that's true. When I came of age in programming there were lots of choices already but none that offered the balance of control and speed that C gave. It was a very easy choice; do I invest my next two decades in Assembly, Pascal (in several flavors), Modula-2, Forth, LISP (which required unobtainable computers at the time), Basic (compiled or interpreted) or C? UNIX had very little to do with it, only very few people were lucky enough to have access to UNIX machines but untold 100's of thousands had access to PCs or 8 bit micros. The first time I saw a UNIX machine it was an Acorn 'Unicorn' and it was so far ahead of what I could afford that it might as well not exist.
  - pjmlp 7y ago
    Sure it was, there were zero reasons to use C on CP/M, MS-DOS, Atari, Amiga, Mac. It was just another programming language fighting for developer eyes. On Windows and OS/2, although IBM and Microsoft decided to go with C for the underlying low level layers, C++ was the way to go for high level coding, C Set++, MFC. With Borland having Turbo Vision, OWL and VCL. Macs were Object Pascal territory, and when MPW got C and C++ support, PowerPlant C++ framework was the way to go. Epoch, BeOS and Symbian were also C++ territory. MS-DOS games were also adopting C++ via Watcom and its DOS extender. UNIX and the rise of FOSS, based on UNIX culture, were definitely the only reason.
    - flohofwoe 7y ago
      IME C++ wasn't really a mainstream option until the second half of the 90's. BeOS choosing C++ for its operating system APIs was an extremely exotic choice at the time (same level of "exotic" as NeXT choosing Objective-C). And IMHO, at that time, before or around C++98, C++ didn't fix a single problem of C, but instead just added a lot of new ones (one could argue that this is still the case even today).
      - zabzonk 7y ago
        > IME C++ wasn't really a mainstream option until the second half of the 90's I was getting paid for teaching C++ on commercial training courses in 1990 - the C++ courses were probably the most popular after C and UNIX > before or around C++98, C++ didn't fix a single problem of C Of course it did, or why would people like me have transferred wholesale from C to C++?
      - pjmlp 7y ago
        It was so exotic that at my university, FCT/UNL, starting in 1992 they switched the first year students to learn Pascal followed by C++. C was never taught as such, as any student was expected to know it from their C++ classes. The professor was a great teacher of what all the ways that C++ fixed C's problems, by providing his own data structures for strings, arrays, vectors, linked lists and hash tables, all with bounds checking enabled by default on his implementation. Other issues that C++ fixed over C was having implicit conversions, a proper way to allocate memory (malloc() with sizeof, really?), ability to ensure valid pointers via references.
        jstimpfle 7y ago
        C++ fixes many of C's problems and introduces so many more that are not fixable. ("But why don't you write const-correct code? Why don't you use move semantics? Use the rule of three!") > malloc() with sizeof, really? One tiny macro to solve 20% of all the problems people are whining about. void _alloc_memory(void **ptr, size_t numElems, size_t elemSize) { size_t numBytes = safe_multiply(numElems, elemSize); void *p = malloc(numBytes); if (p == NULL) fatal("OOM!\n"); *ptr = p; } #define ALLOC_MEMORY(ptr, numElems) _alloc_memory((ptr), (numElems), sizeof **(ptr)) int *myArray; ALLOC_MEMORY(&myArray, 25); I've been using this for years without a problem.
- flohofwoe 7y ago
  C was (and still is) a fairly obvious choice for programming when you need full control over the memory layout of an application (which is becoming all the more important with the growing CPU/memory gap). I choose C 15 years before I got into contact with UNIX (first on the Amiga, after that on Windows, and only fairly recently macOS and Linux).
  - pjmlp 7y ago
    Nothing special about C, plenty of other languages offer similar features. ISO C doesn't offer full control over anything beyond the abstract memory model of the standard.
    - jstimpfle 7y ago
      So what? Chill out. We all know that C is not without flaws. I would use other languages if there were good alternatives. For example, I liked some parts of Delphi, but it has too many show stoppers. For example, all local variables still have to be declared in the variables section before the function body, right? And are we still required to make type aliases to use pointer types in important places, such as function signatures? C is special in that it is the only language that I've known that has a minimalistic attitude, resulting in a shitty language (every language is shit!) whose problems we can actually work around in practice.
      - pjmlp 7y ago
        Just like C used to declare variables until C99. Delphi is not Go, you can declare variables at the point of use nowadays. Just like you can declare pointer types in function signatures, which would fail my code review, as those things tend to get out of hand. Minimalist attitude leads to write only code bases, where it is impossible to maintain on long term projects with regular rotating team members, as it usually happens in most multinationals. A workaround done today is a security exploit waiting to happen tomorrow.
        jstimpfle 7y ago
- namirez 7y ago
  C is not a fad; it's an outlier among languages in the sense that basically it's a portable assembler very close to the metal. If you change the basic architecture of the machine, you can create a better language. For now however it's unlikely to beat C.
  - gmueckl 7y ago
    I'm not sure that this high level assembler assumption still holds for SIMD-capable CPUs. C compilers are asked to do quite drastic code transformations like autovectorization on these architectures. With these, the tight relationship between the high level code C code and the generated machine code is removed.
    - megous 7y ago
      You can still treat it that way even with SIMD. I quite enjoy using NEON (ARM SIMD) intrinsics in C, and the like.
      - gmueckl 7y ago
        When you do that, you write pretty much the equivalent of platform specific assembly code (not exactly, but the differences don't matter for what I want to say). What I am saying is that modern compilers also take your "dumb" code that is not SIMD, but just a pedestrian implementation of something and they still turn it into SIMD or do other very drastic rewrites to it that are hard to reason about. And these optimizations and transformations tend to stack. Something that had inlining, tail recursion optimizations and autovectorization applies to it may end up retaining absolutely no resemblance to what was actually written as C code. Most of the nice properties of C as a low level language come from the fact that you can map the code to assembler in your head - as long as the compiler is not trying to get too clever. Then the intuition becomes merely an illusion and the whole thing becomes harder to use. For example, strict requirements like strict ordering requirements for accesses to hardware registers in a device driver. C has come to a point where you have to pull stunts to prevent the compiler from reordering your memory accesses.
- jstimpfle 7y ago
  It's funny, when I'm not on Unix, C is still my go to language which lets me get shit done. I won't have to deal with performance problems or painful FFIs. Yesterday I was dealing with Webassembly, and having it interoperate with WebGL made me pull out the last few hairs I still had on my head. Go figure.

pjmlp 7y ago

The same reason people got to choose JavaScript or PHP years later, the platform's adoption, in this case UNIX.

jacquesm 7y ago
I don't think that's true. When I came of age in programming there were lots of choices already but none that offered the balance of control and speed that C gave. It was a very easy choice; do I invest my next two decades in Assembly, Pascal (in several flavors), Modula-2, Forth, LISP (which required unobtainable computers at the time), Basic (compiled or interpreted) or C? UNIX had very little to do with it, only very few people were lucky enough to have access to UNIX machines but untold 100's of thousands had access to PCs or 8 bit micros. The first time I saw a UNIX machine it was an Acorn 'Unicorn' and it was so far ahead of what I could afford that it might as well not exist.
- pjmlp 7y ago
  Sure it was, there were zero reasons to use C on CP/M, MS-DOS, Atari, Amiga, Mac. It was just another programming language fighting for developer eyes. On Windows and OS/2, although IBM and Microsoft decided to go with C for the underlying low level layers, C++ was the way to go for high level coding, C Set++, MFC. With Borland having Turbo Vision, OWL and VCL. Macs were Object Pascal territory, and when MPW got C and C++ support, PowerPlant C++ framework was the way to go. Epoch, BeOS and Symbian were also C++ territory. MS-DOS games were also adopting C++ via Watcom and its DOS extender. UNIX and the rise of FOSS, based on UNIX culture, were definitely the only reason.
  - flohofwoe 7y ago
    IME C++ wasn't really a mainstream option until the second half of the 90's. BeOS choosing C++ for its operating system APIs was an extremely exotic choice at the time (same level of "exotic" as NeXT choosing Objective-C). And IMHO, at that time, before or around C++98, C++ didn't fix a single problem of C, but instead just added a lot of new ones (one could argue that this is still the case even today).
    - zabzonk 7y ago
      > IME C++ wasn't really a mainstream option until the second half of the 90's I was getting paid for teaching C++ on commercial training courses in 1990 - the C++ courses were probably the most popular after C and UNIX > before or around C++98, C++ didn't fix a single problem of C Of course it did, or why would people like me have transferred wholesale from C to C++?
    - pjmlp 7y ago
      It was so exotic that at my university, FCT/UNL, starting in 1992 they switched the first year students to learn Pascal followed by C++. C was never taught as such, as any student was expected to know it from their C++ classes. The professor was a great teacher of what all the ways that C++ fixed C's problems, by providing his own data structures for strings, arrays, vectors, linked lists and hash tables, all with bounds checking enabled by default on his implementation. Other issues that C++ fixed over C was having implicit conversions, a proper way to allocate memory (malloc() with sizeof, really?), ability to ensure valid pointers via references.
      - jstimpfle 7y ago
        C++ fixes many of C's problems and introduces so many more that are not fixable. ("But why don't you write const-correct code? Why don't you use move semantics? Use the rule of three!") > malloc() with sizeof, really? One tiny macro to solve 20% of all the problems people are whining about. void _alloc_memory(void **ptr, size_t numElems, size_t elemSize) { size_t numBytes = safe_multiply(numElems, elemSize); void *p = malloc(numBytes); if (p == NULL) fatal("OOM!\n"); *ptr = p; } #define ALLOC_MEMORY(ptr, numElems) _alloc_memory((ptr), (numElems), sizeof **(ptr)) int *myArray; ALLOC_MEMORY(&myArray, 25); I've been using this for years without a problem.
flohofwoe 7y ago
C was (and still is) a fairly obvious choice for programming when you need full control over the memory layout of an application (which is becoming all the more important with the growing CPU/memory gap). I choose C 15 years before I got into contact with UNIX (first on the Amiga, after that on Windows, and only fairly recently macOS and Linux).
- pjmlp 7y ago
  Nothing special about C, plenty of other languages offer similar features. ISO C doesn't offer full control over anything beyond the abstract memory model of the standard.
  - jstimpfle 7y ago
    So what? Chill out. We all know that C is not without flaws. I would use other languages if there were good alternatives. For example, I liked some parts of Delphi, but it has too many show stoppers. For example, all local variables still have to be declared in the variables section before the function body, right? And are we still required to make type aliases to use pointer types in important places, such as function signatures? C is special in that it is the only language that I've known that has a minimalistic attitude, resulting in a shitty language (every language is shit!) whose problems we can actually work around in practice.
    - pjmlp 7y ago
      Just like C used to declare variables until C99. Delphi is not Go, you can declare variables at the point of use nowadays. Just like you can declare pointer types in function signatures, which would fail my code review, as those things tend to get out of hand. Minimalist attitude leads to write only code bases, where it is impossible to maintain on long term projects with regular rotating team members, as it usually happens in most multinationals. A workaround done today is a security exploit waiting to happen tomorrow.
      - jstimpfle 7y ago
namirez 7y ago
C is not a fad; it's an outlier among languages in the sense that basically it's a portable assembler very close to the metal. If you change the basic architecture of the machine, you can create a better language. For now however it's unlikely to beat C.
- gmueckl 7y ago
  I'm not sure that this high level assembler assumption still holds for SIMD-capable CPUs. C compilers are asked to do quite drastic code transformations like autovectorization on these architectures. With these, the tight relationship between the high level code C code and the generated machine code is removed.
  - megous 7y ago
    You can still treat it that way even with SIMD. I quite enjoy using NEON (ARM SIMD) intrinsics in C, and the like.
    - gmueckl 7y ago
      When you do that, you write pretty much the equivalent of platform specific assembly code (not exactly, but the differences don't matter for what I want to say). What I am saying is that modern compilers also take your "dumb" code that is not SIMD, but just a pedestrian implementation of something and they still turn it into SIMD or do other very drastic rewrites to it that are hard to reason about. And these optimizations and transformations tend to stack. Something that had inlining, tail recursion optimizations and autovectorization applies to it may end up retaining absolutely no resemblance to what was actually written as C code. Most of the nice properties of C as a low level language come from the fact that you can map the code to assembler in your head - as long as the compiler is not trying to get too clever. Then the intuition becomes merely an illusion and the whole thing becomes harder to use. For example, strict requirements like strict ordering requirements for accesses to hardware registers in a device driver. C has come to a point where you have to pull stunts to prevent the compiler from reordering your memory accesses.
jstimpfle 7y ago
It's funny, when I'm not on Unix, C is still my go to language which lets me get shit done. I won't have to deal with performance problems or painful FFIs. Yesterday I was dealing with Webassembly, and having it interoperate with WebGL made me pull out the last few hairs I still had on my head. Go figure.