8 ms·

Personally, I'm tired of people bitching about C. At the time, the choice was C or assembly language for embedded/operating systems. There was no other choice i

Personally, I'm tired of people bitching about C. At the time, the choice was C or assembly language for embedded/operating systems. There was no other choice in the 1970's. In fact, it wasn't even an option for most of the 1970's. If you worked at a company and wanted a team of people to develop on a multi-user system, and port it to a single-user stand-alone system, you were out of luck. Our company sold test equipment based on the Data General minicomputers, and while DG had multi-user systems and single-user systems, they had no common programing language besides FORTRAN. It was so frustrating. And then Digital came to us and wanted to buy a lot of systems, but it had to be running on a PDP-11. Trouble is, our test system was written in Data General assembly language. We had to re-write the system in a portable high-level language that could run on RSX-11 OS. But how? We searched for a suitable programming language we could buy support for, and ended up using PASCAL - which was a P-code interpreter. The P-Code was portable across operating systems. So I "ported" an assembly-based system to Pascal, and was able to have equivalent runtime performance, because the DEC system had RAM-based overlays and the DG had disk-based overlays. Otherwise, performance of Pascal over ASM would have made it unfeasible. A few years later, C was commercially available. Oh I wish it was a choice that was available then. The rule of thumb was that C would run with 90% of the performance of assembly language. And that was before they made incredible strides in compiler technology. PL/1 would have been a disaster, assuming it could run at all on a 16-bit machine.

yourapostasy 5y ago
> PL/1 would have been a disaster, assuming it could run at all on a 16-bit machine. There was a PL/1 compiler of sorts that IBM flogged on MS-/PC-DOS in the early days of the IBM PC. IBM didn't write it and only distributed it IIRC, but I can't recall if the one I used was written by Digital Research or Language Processors, Inc. (LPI). It was riddled with compromises and indeed, slow as death compiling. That's saying something when I was used to fiddling with paper tape and audio cassette by then; floppy disks were considered lightning fast by comparison, and the compiler bogged down that experience. So. Many. Floppy. Swaps. It was sold under the value proposition that your mainframe programmers could prototype small bits of code on their PC's (even from home!!!), then when satisfied with the results they'd upload the polished source to the mainframe. I shudder to imagine what it took to make that USP a reality for real production code snippets.
- cagey 5y ago
  Perhaps you're thinking of PL/M [0]? I had a brief encounter with it (as sold by Intel) targeting (of all amazing things) the 8051 microcontroller ISA. And yes: So. Many. Floppy. Swaps. The codegen was not horrendous, but IIRC its price kept it well out of reach of non-commercial users. [0] https://en.wikipedia.org/wiki/PL/M https://en.wikipedia.org/wiki/PL/M
indymike 5y ago
> Personally, I'm tired of people bitching about C. The complaining gets old, but then again, memory leaks, overrruns and underruns and other C footguns get old, too. C has been and still is a great tool, but there is some level of... maybe we can do better 40 years later? You appreciate C more if you've had to implement anything reasonably large in assembly (which clearly you have). > In fact, it wasn't even an option for most of the 1970's. I started programming professionally in the mid 80s. There really wasn't much better than C. Pascal, compiled BASIC (it wasn't quite the VisualBASIC era yet)and ancient stuff like COBOL, PL/1 and FORTRAN were really the other real options. The old languages had a lot of limitations baked in. Pascal was better, but there were huge limitations imposed by Pascal arrays and Pascal's type system that rendered it very difficult to use for many entire classes of applications (anything where dynamic allocation of blocks of memory was needed, so for something like I/O... or video... or text editing (255 character lines much?) or whatever I happened to be working on. It wasn't impossible to do big projects with Pascal, but it was a lot more work.
- jacquesm 5y ago
  > maybe we can do better 40 years later? But we do. There are plenty of programming languages besides C. Also, while we're at it, UNIX is now a good 50 years old and if anything it contributes as much to the problem of unsafe software as anything else out there, every driver has the potential to hose the entire system.
  - indymike 5y ago
    > Also, while we're at it, UNIX is now a good 50 years old and if anything it contributes as much to the problem of unsafe software as anything else out there, every driver has the potential to hose the entire system. If Unix was a single OS and codebase this holds water, but Linux isn't Unix, and real Unix comes in lots of flavors, and each has it's own set of issues. In any OS, save some microkernels, interfacing to hardware creates problems. Incidentally, insecure hardware is a universal problem.
- grymoire1 5y ago
  >The complaining gets old, but then again, memory leaks, overrruns and underruns and other C footguns get old, too. Agreed. C is an old language, but at the time it was a very good language. One can argue the choice nowadays, but comparing it to PL/1? A quick search on Linkedin: * 117 Jobs for PL/1 programmers * 300,000+ jobs for C programmers
gumby 5y ago
> At the time, the choice was C or assembly language for embedded/operating systems. There was no other choice in the 1970's. In fact, it wasn't even an option for most of the 1970's. Unix was written in C because Thompson and Ritchie had been working on Multics, which was written in PL/1 in the 1960s. So the idea of an OS written in a high level language was hardly obscure and had nothing to do with C. It’s hard to say that C was much of an option in the 1970s anyway as k&r wasn’t even published until 1978. There was a lovely (and also annoying) Cambrian explosion of languages and OSs in the 70s and even into the mid 80s or later. Computer companies often wrote their own languages and OSs, which made porting difficult (but porting wasn’t hugely common).
- devoutsalsa 5y ago
  I’ve never played with Rust, but could Rust have been viable on early 70s hardware? Had Rust existed, could Unix have been originally written in Rust?
  - jacquesm 5y ago
    I will answer 'Yes' to this the moment we have a viable mainstream OS written in Rust. There are people working towards this so with some luck we will be able to see what the brave new world of a whole system running production software built in Rust looks like.
- AnimalMuppet 5y ago
  > Unix was written in C because Thompson and Ritchie had been working on Multics, which was written in PL/1 in the 1960s. So the idea of an OS written in a high level language was hardly obscure and had nothing to do with C. OK, but at the time they started working on Unix, Multics had not yet been delivered. Nor was it clear that it would ever be delivered. So the idea that an OS could be successfully written in a high-level language was not yet proven.
  - gumby 5y ago
    I think you’re trying to split hairs for some reason I can’t figure out. In any case your assertion is not correct: Multics was operational around campus in 1969.
thayne 5y ago
Sure c was better than anything else in the 70s. The question is why aren't we using something better 40 years later? Even if that is just a better version of C with a better libc, error handling, protection from overflows, etc.
- ModernMech 5y ago
  It shocked me to realize this, but the 70s are now a half century ago.
  - FabHK 5y ago
    1983 (Star Wars Return of the Jedi, Michael Jackson Thriller and Billie Jean) is closer to WWII than to now...
- agentultra 5y ago
  You can if you want. Pick a board, a chip set, read the manual and get cracking. The Intel manual is only what, 2200 pages? I bet you could bootstrap an operating system, compiler, tool chain, and basic tools in a few years. And maybe in ten or twenty years you could have your new development environment up so you can start publishing software for all you new users. I think the reason it sticks around is because of network effects like platform exclusivity, ecosystem, etc.
  - jacquesm 5y ago
    From experience: it takes about two years so you are quite on the money with your estimate. The hard part is to gain traction.
TheOtherHobbes 5y ago
OK - but it's not the 1970s any more. Modern hardware is many orders of magnitude faster than it used to be. (If you check the numbers it's not just a linear jump in clock rate of a thousand or so, but a multiplier of another 10 or 100 because of pipelining, faster memory, larger caches, and bigger word sizes.) So why are we still using a language designed as a quick hack in the 70s and which is a dinosaur now? Beyond that - why are we still using the ideas from that period without modernising them? Why are so many 1970s constraints and hacks baked into POSIX and OS features when modern issues - security, stability, consistency, reliability, multi-national localisation and support, and so on - should be taking precedence?
- tremon 5y ago
  Arguably, it's not the prevalence of the language per se that's the problem: it's that the C function call interface has become the de-facto interop language for all shared libraries, which also means that every other language (whether it's Ada, Pascal, Rust, Python, Ocaml or Haskell) has to support the dinosaur-age ideas or exist only in its own niche.
- MaxBarraclough 5y ago
  You're right of course that hardware has improved immensely, but I'm not sure what your point was. There are plenty of domains where performance is still of great importance, and C still has excellent performance. I think the real point is that modern languages can significantly improve on the major issues with C, particularly its undefined behaviour and how that translates to real-world security issues, without significantly impacting performance. Rust (and in particular its Safe Rust subset) has been competing more with C++ than with C, but the point is still there. I admit though that I don't have hard numbers on what would be the performance cost of writing an OS (for example) in Rust rather than C.
  - ogogmad 5y ago
    Zig is apparently not much more complicated than C. It's got the same focus on low-level programming and manual memory management as C does. Doesn't support operator overloading though, and probably never will. :(
mamcx 5y ago
> Personally, I'm tired of people bitching about C ... There was no other choice in the 1970's. This in fact prove the opposite. People not complain hard enough about how much terrible C/C++ are. 1970: That is more than 50 years of BEING WRONG.
- jacquesm 5y ago
  Not really. For a long time C was a perfectly legitimate choice. The 'wrongs' of C have only really come to light with widespread usage of the Internet and the much higher focus on security. Back in the day people working with computers weren't necessarily doing so to make a quick buck, hose your system or to try to see if they could do damage. The bulk of the people working with computers was trying hard to produce something useful instead of to deconstruct that which was already there in a malicious way. The parasites came long after C.
  - mamcx 5y ago
    Even then, you have better options (main one: pascal). P.D: My main gripe is not about why C was made how is made. Is that it STAY like that until now. It must have been deprecating dangerous stuff long ago...
    - deterministic 5y ago
      Nope Pascal was never a real competitor to C. I have programmed serious software using both languages and I would never pick Pascal over C.
    - jacquesm 5y ago
      I've used both. C over Pascal any day, warts included.
    - peterashford 5y ago
      Disagree. Pascal was no more safe than C
- grymoire1 5y ago
stjohnswarts 5y ago
Also with minimal c++ you can fix almost all the issues with C and people in embedded who are new overlook it all the time for fancier things like rust/zig/whatever which would force a complete thought process change. Luckily I've been coding away with C++ as a better C for decades in embedded projects. It does require some knowledge of what's going on underneath classes, inheritance, basic templates, etc., but it's all very doable. I generally avoid RTTI and exceptions for example.

yourapostasy 5y ago

> PL/1 would have been a disaster, assuming it could run at all on a 16-bit machine. There was a PL/1 compiler of sorts that IBM flogged on MS-/PC-DOS in the early days of the IBM PC. IBM didn't write it and only distributed it IIRC, but I can't recall if the one I used was written by Digital Research or Language Processors, Inc. (LPI). It was riddled with compromises and indeed, slow as death compiling. That's saying something when I was used to fiddling with paper tape and audio cassette by then; floppy disks were considered lightning fast by comparison, and the compiler bogged down that experience. So. Many. Floppy. Swaps. It was sold under the value proposition that your mainframe programmers could prototype small bits of code on their PC's (even from home!!!), then when satisfied with the results they'd upload the polished source to the mainframe. I shudder to imagine what it took to make that USP a reality for real production code snippets.

cagey 5y ago
Perhaps you're thinking of PL/M [0]? I had a brief encounter with it (as sold by Intel) targeting (of all amazing things) the 8051 microcontroller ISA. And yes: So. Many. Floppy. Swaps. The codegen was not horrendous, but IIRC its price kept it well out of reach of non-commercial users. [0] https://en.wikipedia.org/wiki/PL/M https://en.wikipedia.org/wiki/PL/M

indymike 5y ago

> Personally, I'm tired of people bitching about C. The complaining gets old, but then again, memory leaks, overrruns and underruns and other C footguns get old, too. C has been and still is a great tool, but there is some level of... maybe we can do better 40 years later? You appreciate C more if you've had to implement anything reasonably large in assembly (which clearly you have). > In fact, it wasn't even an option for most of the 1970's. I started programming professionally in the mid 80s. There really wasn't much better than C. Pascal, compiled BASIC (it wasn't quite the VisualBASIC era yet)and ancient stuff like COBOL, PL/1 and FORTRAN were really the other real options. The old languages had a lot of limitations baked in. Pascal was better, but there were huge limitations imposed by Pascal arrays and Pascal's type system that rendered it very difficult to use for many entire classes of applications (anything where dynamic allocation of blocks of memory was needed, so for something like I/O... or video... or text editing (255 character lines much?) or whatever I happened to be working on. It wasn't impossible to do big projects with Pascal, but it was a lot more work.

jacquesm 5y ago
> maybe we can do better 40 years later? But we do. There are plenty of programming languages besides C. Also, while we're at it, UNIX is now a good 50 years old and if anything it contributes as much to the problem of unsafe software as anything else out there, every driver has the potential to hose the entire system.
- indymike 5y ago
  > Also, while we're at it, UNIX is now a good 50 years old and if anything it contributes as much to the problem of unsafe software as anything else out there, every driver has the potential to hose the entire system. If Unix was a single OS and codebase this holds water, but Linux isn't Unix, and real Unix comes in lots of flavors, and each has it's own set of issues. In any OS, save some microkernels, interfacing to hardware creates problems. Incidentally, insecure hardware is a universal problem.
grymoire1 5y ago
>The complaining gets old, but then again, memory leaks, overrruns and underruns and other C footguns get old, too. Agreed. C is an old language, but at the time it was a very good language. One can argue the choice nowadays, but comparing it to PL/1? A quick search on Linkedin: * 117 Jobs for PL/1 programmers * 300,000+ jobs for C programmers

gumby 5y ago

> At the time, the choice was C or assembly language for embedded/operating systems. There was no other choice in the 1970's. In fact, it wasn't even an option for most of the 1970's. Unix was written in C because Thompson and Ritchie had been working on Multics, which was written in PL/1 in the 1960s. So the idea of an OS written in a high level language was hardly obscure and had nothing to do with C. It’s hard to say that C was much of an option in the 1970s anyway as k&r wasn’t even published until 1978. There was a lovely (and also annoying) Cambrian explosion of languages and OSs in the 70s and even into the mid 80s or later. Computer companies often wrote their own languages and OSs, which made porting difficult (but porting wasn’t hugely common).

devoutsalsa 5y ago
I’ve never played with Rust, but could Rust have been viable on early 70s hardware? Had Rust existed, could Unix have been originally written in Rust?
- jacquesm 5y ago
  I will answer 'Yes' to this the moment we have a viable mainstream OS written in Rust. There are people working towards this so with some luck we will be able to see what the brave new world of a whole system running production software built in Rust looks like.
AnimalMuppet 5y ago
> Unix was written in C because Thompson and Ritchie had been working on Multics, which was written in PL/1 in the 1960s. So the idea of an OS written in a high level language was hardly obscure and had nothing to do with C. OK, but at the time they started working on Unix, Multics had not yet been delivered. Nor was it clear that it would ever be delivered. So the idea that an OS could be successfully written in a high-level language was not yet proven.
- gumby 5y ago
  I think you’re trying to split hairs for some reason I can’t figure out. In any case your assertion is not correct: Multics was operational around campus in 1969.

thayne 5y ago

Sure c was better than anything else in the 70s. The question is why aren't we using something better 40 years later? Even if that is just a better version of C with a better libc, error handling, protection from overflows, etc.

ModernMech 5y ago
It shocked me to realize this, but the 70s are now a half century ago.
- FabHK 5y ago
  1983 (Star Wars Return of the Jedi, Michael Jackson Thriller and Billie Jean) is closer to WWII than to now...
agentultra 5y ago
You can if you want. Pick a board, a chip set, read the manual and get cracking. The Intel manual is only what, 2200 pages? I bet you could bootstrap an operating system, compiler, tool chain, and basic tools in a few years. And maybe in ten or twenty years you could have your new development environment up so you can start publishing software for all you new users. I think the reason it sticks around is because of network effects like platform exclusivity, ecosystem, etc.
- jacquesm 5y ago
  From experience: it takes about two years so you are quite on the money with your estimate. The hard part is to gain traction.

TheOtherHobbes 5y ago

OK - but it's not the 1970s any more. Modern hardware is many orders of magnitude faster than it used to be. (If you check the numbers it's not just a linear jump in clock rate of a thousand or so, but a multiplier of another 10 or 100 because of pipelining, faster memory, larger caches, and bigger word sizes.) So why are we still using a language designed as a quick hack in the 70s and which is a dinosaur now? Beyond that - why are we still using the ideas from that period without modernising them? Why are so many 1970s constraints and hacks baked into POSIX and OS features when modern issues - security, stability, consistency, reliability, multi-national localisation and support, and so on - should be taking precedence?

tremon 5y ago
Arguably, it's not the prevalence of the language per se that's the problem: it's that the C function call interface has become the de-facto interop language for all shared libraries, which also means that every other language (whether it's Ada, Pascal, Rust, Python, Ocaml or Haskell) has to support the dinosaur-age ideas or exist only in its own niche.
MaxBarraclough 5y ago
You're right of course that hardware has improved immensely, but I'm not sure what your point was. There are plenty of domains where performance is still of great importance, and C still has excellent performance. I think the real point is that modern languages can significantly improve on the major issues with C, particularly its undefined behaviour and how that translates to real-world security issues, without significantly impacting performance. Rust (and in particular its Safe Rust subset) has been competing more with C++ than with C, but the point is still there. I admit though that I don't have hard numbers on what would be the performance cost of writing an OS (for example) in Rust rather than C.
- ogogmad 5y ago
  Zig is apparently not much more complicated than C. It's got the same focus on low-level programming and manual memory management as C does. Doesn't support operator overloading though, and probably never will. :(

mamcx 5y ago

> Personally, I'm tired of people bitching about C ... There was no other choice in the 1970's. This in fact prove the opposite. People not complain hard enough about how much terrible C/C++ are. 1970: That is more than 50 years of BEING WRONG.

jacquesm 5y ago
Not really. For a long time C was a perfectly legitimate choice. The 'wrongs' of C have only really come to light with widespread usage of the Internet and the much higher focus on security. Back in the day people working with computers weren't necessarily doing so to make a quick buck, hose your system or to try to see if they could do damage. The bulk of the people working with computers was trying hard to produce something useful instead of to deconstruct that which was already there in a malicious way. The parasites came long after C.
- mamcx 5y ago
  Even then, you have better options (main one: pascal). P.D: My main gripe is not about why C was made how is made. Is that it STAY like that until now. It must have been deprecating dangerous stuff long ago...
  - deterministic 5y ago
    Nope Pascal was never a real competitor to C. I have programmed serious software using both languages and I would never pick Pascal over C.
  - jacquesm 5y ago
    I've used both. C over Pascal any day, warts included.
  - peterashford 5y ago
    Disagree. Pascal was no more safe than C
grymoire1 5y ago

stjohnswarts 5y ago

Also with minimal c++ you can fix almost all the issues with C and people in embedded who are new overlook it all the time for fancier things like rust/zig/whatever which would force a complete thought process change. Luckily I've been coding away with C++ as a better C for decades in embedded projects. It does require some knowledge of what's going on underneath classes, inheritance, basic templates, etc., but it's all very doable. I generally avoid RTTI and exceptions for example.