4 ms·

C is the language that doesn't force any preconceived notions about how the world should work onto you. Sure, C strings are NULL-terminated by convention, but

C is the language that doesn't force any preconceived notions about how the world should work onto you. Sure, C strings are NULL-terminated by convention, but even that is something you can almost completely ignore if you want to build up your own parallel stack of software that does it differently. It is for this reason that C (and sometimes C++) are what people use when they have a new idea about higher-level programming abstractions. With C, you can be totally free of other people's big ideas (and their associated costs/complications) and invent something new. Anyone who wants you to give up C in favor of their language/framework/VM/runtime is selling their own vision for how the world should work. That's fine and sometimes buying in will save you a lot of hassle. But what they're offering was almost certainly written in C or C++. Essentially their pitch is equivalent to "I have written the last C program you'll ever need." In the early 90s that was Perl. In the late 90s, Java. In the early 2000s, .NET, then Ruby, then fast JavaScript. This history is an oversimplification of course, but the real question is: would you really prefer a history in which we had, at some point, decided that the current VM that was in vogue should become the new replacement for C? That we'd tailor all our hardware to it, and no future VM would be "native" but would have to run on top of a different VM? C is the key to why we have general-purpose computers that can run a wide variety of different languages efficiently, and why programs that need to be particularly efficient can always drop down to lower-level programming to get extra performance.

kscaldef 14y ago
> C is the language that doesn't force any preconceived notions about how the world should work onto you Some preconceived notions forced upon you by C, off the top of my head: - problems should be solved by describing a linear sequence of steps (as opposed to logic/declarative programming) - a variable can have different values at different times in the execution of a program (in contrast to standard mathematical conventions) - a function can return different results when called multiple times with the same arguments (again, in contrast to the standard mathematical meaning of the term) - there is random access storage of information (with constant time access and update)
- haberman 14y ago
  > Some preconceived notions forced upon you by C Nope, not forced on you, because plenty of systems implemented in C define models in which none of what you mentioned is true. For example, the Haskell runtime is implemented in C. That's the whole point of what I'm saying. A stack with C at the bottom allows Haskell to exist with good performance even though the hardware/OS were not designed with Haskell in mind. The reverse is not true. Why do you suppose that no serious VMs or language runtimes are written in Haskell (or other functional languages)?
  - kscaldef 14y ago
    > A stack with C at the bottom You realize C is not at the bottom of the stack, right? > Why do you suppose that no serious VMs or language runtimes are written in Haskell (or other functional languages)? Because Lisp Machines didn't win. > plenty of systems implemented in C define models in which none of what you mentioned is true True, but that's the whole point of abstraction. C, in turn, gets rid of some of the "preconceived notions" of the layers under it.
    - haberman 14y ago
      > Because Lisp Machines didn't win. And if Lisp Machines had won, do you really think they'd run JavaScript, Erlang, C, and Haskell (as a rough sample) as fast as our Von Neumann machines do today?
      - jhuni 14y ago
        C is built to run on a MASOS (multiple address space operating system) like UNIX so it wouldn't run as fast on a system like the Lisp machines that uses a single address space. Many of the things C deals with like the file system and interprocess communication would be obsolete in a system with single address space orthogonal persistence. Running C on a Lisp machine will be possible but at a performance cost. JavaScript would run faster then it does on Von Nuemman machines because it would use the hardware support for dynamic languages and since JavaScript runs in a browser independently of the OS, the new machine architecture and OS wouldn't be a problem. Haskell, in so far as its purely functional, would probably run the same as it does now.
chromatic 14y ago
C is the language that doesn't force any preconceived notions about how the world should work onto you. ... except for a type system based on the memory model of a machine which strongly resembles the PDP-11, a compilation strategy built for machines with less RAM than my car fob, and optimization possibilities limited by aliasing, plus everything kscaldef mentioned.
- haberman 14y ago
  > except for a type system based on the memory model of a machine which strongly resembles the PDP-11 I'm interested in hearing about alternative memory models that are an improvement; every one I hear about is specific to some higher-level language or programming paradigm. Baking high-level language concepts into hardware is basically asking for stagnation. > a compilation strategy built for machines with less RAM than my car fob C is adapting (see: http://www.infoq.com/news/2012/11/llvm-modules http://www.infoq.com/news/2012/11/llvm-modules) > optimization possibilities limited by aliasing "restrict" exists, and while it's not perfect, I have not seen anything that is a Pareto improvement over it. In other words, every alternative that avoids aliasing problems (that I have seen) makes other trade-offs that make it a worse choice overall (including FORTRAN, which I am sure you will mention).
  - zvrba 14y ago
    > I'm interested in hearing about alternative memory models that are an improvement; Intel 80286 introduced segmented protected mode where you had the option of placing each of programs objects (struct, array, string, even a single variable, if necessary!) into its own segment described by privilege access level (0-3, RO or RW) and length. So you had hardware-based array length checking. Access an out-of-bounds index, BOOM - segfault! This is actually not incompatible with C's memory model (it requires that only individual objects be stored in contiguous memory blocks), but is incompatible with how most C programs were written at the time so it never caught on. Also, you had to distinguish between "near" and "far" pointers, there were few segment registers, etc. But had Intel developed segmentation further, and had C programmers adapted, we could have ended up in the world where you could run programs with performance of C and safety of Java.

kscaldef 14y ago

> C is the language that doesn't force any preconceived notions about how the world should work onto you Some preconceived notions forced upon you by C, off the top of my head: - problems should be solved by describing a linear sequence of steps (as opposed to logic/declarative programming) - a variable can have different values at different times in the execution of a program (in contrast to standard mathematical conventions) - a function can return different results when called multiple times with the same arguments (again, in contrast to the standard mathematical meaning of the term) - there is random access storage of information (with constant time access and update)

haberman 14y ago
> Some preconceived notions forced upon you by C Nope, not forced on you, because plenty of systems implemented in C define models in which none of what you mentioned is true. For example, the Haskell runtime is implemented in C. That's the whole point of what I'm saying. A stack with C at the bottom allows Haskell to exist with good performance even though the hardware/OS were not designed with Haskell in mind. The reverse is not true. Why do you suppose that no serious VMs or language runtimes are written in Haskell (or other functional languages)?
- kscaldef 14y ago
  > A stack with C at the bottom You realize C is not at the bottom of the stack, right? > Why do you suppose that no serious VMs or language runtimes are written in Haskell (or other functional languages)? Because Lisp Machines didn't win. > plenty of systems implemented in C define models in which none of what you mentioned is true True, but that's the whole point of abstraction. C, in turn, gets rid of some of the "preconceived notions" of the layers under it.
  - haberman 14y ago
    > Because Lisp Machines didn't win. And if Lisp Machines had won, do you really think they'd run JavaScript, Erlang, C, and Haskell (as a rough sample) as fast as our Von Neumann machines do today?
    - jhuni 14y ago
      C is built to run on a MASOS (multiple address space operating system) like UNIX so it wouldn't run as fast on a system like the Lisp machines that uses a single address space. Many of the things C deals with like the file system and interprocess communication would be obsolete in a system with single address space orthogonal persistence. Running C on a Lisp machine will be possible but at a performance cost. JavaScript would run faster then it does on Von Nuemman machines because it would use the hardware support for dynamic languages and since JavaScript runs in a browser independently of the OS, the new machine architecture and OS wouldn't be a problem. Haskell, in so far as its purely functional, would probably run the same as it does now.

chromatic 14y ago

C is the language that doesn't force any preconceived notions about how the world should work onto you. ... except for a type system based on the memory model of a machine which strongly resembles the PDP-11, a compilation strategy built for machines with less RAM than my car fob, and optimization possibilities limited by aliasing, plus everything kscaldef mentioned.

haberman 14y ago
> except for a type system based on the memory model of a machine which strongly resembles the PDP-11 I'm interested in hearing about alternative memory models that are an improvement; every one I hear about is specific to some higher-level language or programming paradigm. Baking high-level language concepts into hardware is basically asking for stagnation. > a compilation strategy built for machines with less RAM than my car fob C is adapting (see: http://www.infoq.com/news/2012/11/llvm-modules http://www.infoq.com/news/2012/11/llvm-modules) > optimization possibilities limited by aliasing "restrict" exists, and while it's not perfect, I have not seen anything that is a Pareto improvement over it. In other words, every alternative that avoids aliasing problems (that I have seen) makes other trade-offs that make it a worse choice overall (including FORTRAN, which I am sure you will mention).
- zvrba 14y ago
  > I'm interested in hearing about alternative memory models that are an improvement; Intel 80286 introduced segmented protected mode where you had the option of placing each of programs objects (struct, array, string, even a single variable, if necessary!) into its own segment described by privilege access level (0-3, RO or RW) and length. So you had hardware-based array length checking. Access an out-of-bounds index, BOOM - segfault! This is actually not incompatible with C's memory model (it requires that only individual objects be stored in contiguous memory blocks), but is incompatible with how most C programs were written at the time so it never caught on. Also, you had to distinguish between "near" and "far" pointers, there were few segment registers, etc. But had Intel developed segmentation further, and had C programmers adapted, we could have ended up in the world where you could run programs with performance of C and safety of Java.