3 ms·

> like many great early works, they are cliches This, a thousand times. It's just so easy for people to fall into the trap of thinking the current list of thin

> like many great early works, they are cliches This, a thousand times. It's just so easy for people to fall into the trap of thinking the current list of things to do or avoid has always been obvious. The path is always obvious after a million people have trodden it. But at one time it wasn't. At one time people had to figure out things we now take for granted - like network APIs or concurrent programming models or, most relevantly, memory management. At the time manual management of object lifetimes was the only feasible option for a systems programming language, and it was feasible in part because control flows were simpler. Yes, even in things like OS kernels. They were kept simple by design in part to keep lifetime management tractable. Many of the things that make that approach non-viable today - e.g. massive concurrency, callbacks, exceptions - weren't part of the idiom then. They were irrelevant to C's design. C was good for its time. Go ahead, take a look at PL/I and BLISS. See whether you'd rather program in those. It might or might not be relevant today, but C was better designed in its context than anything most of its modern critics have ever designed (or will design) themselves.

laumars 7y ago
> C was good for its time. Go ahead, take a look at PL/I and BLISS. See whether you'd rather program in those. I don't think that's a fair comment. Pl/I wasn't really the same domain as C and there were other alternatives to PL/I (such as FORTRAN, COBOL, ALGOL, Simula, LISP etc) In fact by the time C was released, there were already literally dozens of programming languages. And C itself an evolutionary progression because it took ideas from B, ALBOL and a few others. Also Pascal pre-dates C as well. I don't mean the following as a criticism against C because I do quite like the language but it does sometimes feel like it's put on a pedestal because it ended up dominating the industry -- either directly or via other languages heavily inspired by C. I do wonder if we've be seeing the same rose-tinted comments had UNIX been based on Pascal and Object Pascal not lost to C++.
- notacoward 7y ago
  > by the time C was released, there were already literally dozens of programming languages Hundreds, actually, I was there, but writing a compiler in COBOL or an OS kernel in FORTRAN would have been quite an exercise. For those kinds of domains, there were few alternatives and assembler was still a common choice. C was certainly an improvement on that.
- mark-r 7y ago
  Pascal was my favorite language for a number of years. But it was completely inappropriate for systems programming because it was too protective, it kept you from doing the things that are regularly required at an OS level.
  - laumars 7y ago
    > Pascal was my favorite language for a number of years. Likewise :) > But it was completely inappropriate for systems programming because it was too protective, it kept you from doing the things that are regularly required at an OS level. I guess it depends on what systems you're programming. I seem to recall Pascal was heavily used in the early days of Windows and Macintoshes. Albeit my memory is hazy so perhaps that was "just" user applications with the lower level stuff being done in assembly?
    - notacoward 7y ago
      I started my professional programming career working in Pascal on the Mac. I clearly recall having to write one piece (a MIDI driver) in assembly. I have fuzzier memories of the interfaces using a rather explicitly Pascal-based string format and stack calling convention, and MPW was also Pascal-oriented rather than C-oriented, so I suspect that at least some of the system software was written in Pascal. OTOH, I'm pretty sure I recall hearing that practically all of what Atkinson and Hirschfeld and Capps and so on wrote for the original ROMs was in assembly (as distinct from what had been done on the LISA) because that was the only way it would fit.
      - mark-r 7y ago
        The Pascal and C calling conventions were different in the way the stack got cleaned after a function call, and Pascal turned out to be ever so slightly faster. So the OS functions used that as the standard. Microsoft had a keyword that could be applied to any function in C to make it compatible. Assembly sounds very believable for early OS work.
    - mark-r 7y ago
      Most of my experience was user applications. Wirth later created the Oberon system completely in Modula, which was basically Pascal++. So maybe it was closer to suitable than I remember.
wbl 7y ago
The Lisp machines were contemporaneous with Unix, as were Wirth's Pascal based systems, the Burroughs with its bound checks, Algol 68. Dont get me wrong: C gets the job done. It's successful in a wide number of domains, and I do like using it. But its success was not inevitable and involved a lot of external and soft factors.
- notacoward 7y ago
  Lisp machines were contemporaneous C was introduced in 1972. Lisp machines started in 1975, so can't have influenced C without some time travel. > Wirth's Pascal based systems Pascal predated C by only two years, so it's not clear how much it could have influenced C's design. (Side note: Wirth originally intended Pascal to be a pure teaching language, and was reportedly furious when a TA wrote the first compiler to make grading easier.) More importantly, Wirth's Modula machines could not have existed until at least 1979 when the language itself was introduced. > Burroughs with its bound checks That's a machine, not a language. What language(s) were its OS and compilers written in? > Algol 68 Now we're getting somewhere. Yes, Algol 68 had existed for a whole four years. Was it suitable as a systems programming language? Not in its canonical form, but there were certainly members of its family (e.g. Wirth's PL/360 and ALGOL/W) that were worthy alternatives to C. > its success was not inevitable Never said so. I'm not even trying to claim that C was the best possible language at the time. The question is whether it was well designed for its time, with specific reference to the issue of memory management. I'd say it was, and leave it as an exercise for the reader to determine what strategies those other alternatives - even if they were superior in some ways - used to deal with heap-allocated memory.
  - wbl 7y ago
    C was not born in a day. ANSI C introduced a number of significant features like prototypes, and commercial compilers also evolved it.
    - notacoward 7y ago
      Did any of those subsequent changes affect the basic memory-management model?

laumars 7y ago

> C was good for its time. Go ahead, take a look at PL/I and BLISS. See whether you'd rather program in those. I don't think that's a fair comment. Pl/I wasn't really the same domain as C and there were other alternatives to PL/I (such as FORTRAN, COBOL, ALGOL, Simula, LISP etc) In fact by the time C was released, there were already literally dozens of programming languages. And C itself an evolutionary progression because it took ideas from B, ALBOL and a few others. Also Pascal pre-dates C as well. I don't mean the following as a criticism against C because I do quite like the language but it does sometimes feel like it's put on a pedestal because it ended up dominating the industry -- either directly or via other languages heavily inspired by C. I do wonder if we've be seeing the same rose-tinted comments had UNIX been based on Pascal and Object Pascal not lost to C++.

notacoward 7y ago
> by the time C was released, there were already literally dozens of programming languages Hundreds, actually, I was there, but writing a compiler in COBOL or an OS kernel in FORTRAN would have been quite an exercise. For those kinds of domains, there were few alternatives and assembler was still a common choice. C was certainly an improvement on that.
mark-r 7y ago
Pascal was my favorite language for a number of years. But it was completely inappropriate for systems programming because it was too protective, it kept you from doing the things that are regularly required at an OS level.
- laumars 7y ago
  > Pascal was my favorite language for a number of years. Likewise :) > But it was completely inappropriate for systems programming because it was too protective, it kept you from doing the things that are regularly required at an OS level. I guess it depends on what systems you're programming. I seem to recall Pascal was heavily used in the early days of Windows and Macintoshes. Albeit my memory is hazy so perhaps that was "just" user applications with the lower level stuff being done in assembly?
  - notacoward 7y ago
    I started my professional programming career working in Pascal on the Mac. I clearly recall having to write one piece (a MIDI driver) in assembly. I have fuzzier memories of the interfaces using a rather explicitly Pascal-based string format and stack calling convention, and MPW was also Pascal-oriented rather than C-oriented, so I suspect that at least some of the system software was written in Pascal. OTOH, I'm pretty sure I recall hearing that practically all of what Atkinson and Hirschfeld and Capps and so on wrote for the original ROMs was in assembly (as distinct from what had been done on the LISA) because that was the only way it would fit.
    - mark-r 7y ago
      The Pascal and C calling conventions were different in the way the stack got cleaned after a function call, and Pascal turned out to be ever so slightly faster. So the OS functions used that as the standard. Microsoft had a keyword that could be applied to any function in C to make it compatible. Assembly sounds very believable for early OS work.
  - mark-r 7y ago
    Most of my experience was user applications. Wirth later created the Oberon system completely in Modula, which was basically Pascal++. So maybe it was closer to suitable than I remember.

wbl 7y ago

The Lisp machines were contemporaneous with Unix, as were Wirth's Pascal based systems, the Burroughs with its bound checks, Algol 68. Dont get me wrong: C gets the job done. It's successful in a wide number of domains, and I do like using it. But its success was not inevitable and involved a lot of external and soft factors.

notacoward 7y ago
Lisp machines were contemporaneous C was introduced in 1972. Lisp machines started in 1975, so can't have influenced C without some time travel. > Wirth's Pascal based systems Pascal predated C by only two years, so it's not clear how much it could have influenced C's design. (Side note: Wirth originally intended Pascal to be a pure teaching language, and was reportedly furious when a TA wrote the first compiler to make grading easier.) More importantly, Wirth's Modula machines could not have existed until at least 1979 when the language itself was introduced. > Burroughs with its bound checks That's a machine, not a language. What language(s) were its OS and compilers written in? > Algol 68 Now we're getting somewhere. Yes, Algol 68 had existed for a whole four years. Was it suitable as a systems programming language? Not in its canonical form, but there were certainly members of its family (e.g. Wirth's PL/360 and ALGOL/W) that were worthy alternatives to C. > its success was not inevitable Never said so. I'm not even trying to claim that C was the best possible language at the time. The question is whether it was well designed for its time, with specific reference to the issue of memory management. I'd say it was, and leave it as an exercise for the reader to determine what strategies those other alternatives - even if they were superior in some ways - used to deal with heap-allocated memory.
- wbl 7y ago
  C was not born in a day. ANSI C introduced a number of significant features like prototypes, and commercial compilers also evolved it.
  - notacoward 7y ago
    Did any of those subsequent changes affect the basic memory-management model?