Hacker News Reader

Comment by prirun | Hacker News Reader

PL/I, created in 1964, had strings. Real strings, where the compiler knows the length even when it gets passed around and is declared char(*) var in the receiving function. You can't have buffer overflows because the compiler and runtime know every string's current length and allocated length.

This isn't a particularly hard problem. C just took a shitty shortcut to fake strings using byte arrays and the world glombed onto it. Now we're stuck with a crappy "standard" that people should have scoffed at when it first showed its ugly face.

View on HN

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.

> 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.

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

> 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.

> 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.

> 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.

>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

I'm not promoting the PL/I language, although I did do significant work with it back in the day, including the Prime operating system which had huge chunks written in a system-programming version of PL/I. PL/I likely never "made it" because it's a huge, bloated language that's hard to implement, compilers were scant, and they were expensive. For the curious, here are Prime's 2 system-programming subsets, the first, PL/P, is from 1978:

PLP: https://sysovl.info/pages/blobs/prime/pet/pe-t-483%20PLP%201... SPL: https://sysovl.info/pages/blobs/prime/pet/pe-t-xxx%20SPL%20R...

I am promoting the concept of strings having a built-in capacity and current length, and the language compiler and runtime understanding that rather than trying to use a byte array as a string. Even compiled BASIC I used in the late 70's had real strings like that.

> but comparing it to PL/1?

I think the point was that a language designed when pterodactyls ruled the skies had a better string implementation than C. Regardless, C's not going anywhere. You still need something close to the hardware that has better ergonomics than assembly language to implement that new safe language that mythical safe OS will be written in :-)

> 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).

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?

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.

> 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.

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.

The Burroughs system for the B5000 was written in Algol and preceded Multics.

Thanks, excellent example! I had no known that one.

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.

It shocked me to realize this, but the 70s are now a half century ago.

1983 (Star Wars Return of the Jedi, Michael Jackson Thriller and Billie Jean) is closer to WWII than to now...

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.

From experience: it takes about two years so you are quite on the money with your estimate. The hard part is to gain traction.

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?

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.

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. :(

I didn't mention Zig because as far as I know there's no Safe Zig subset, nor are there plans to develop one. Zig itself is an unsafe language. [0][1]

That's the nice thing about Safe Rust, it's a proper safe language akin to Java and JavaScript, while retaining high performance, plain old ahead-of-time compilation, and no garbage collector. Zig isn't playing the same game.

[0] https://www.scattered-thoughts.net/writing/how-safe-is-zig/

[1] https://news.ycombinator.com/item?id=26537693

> OK - but it's not the 1970s any more

Sure, but that can be taken both ways. eg: "then stop griping about a language that was at the top of the heap in the 70's".

It should rather be "then stop using a language that was at the top of the heap in the 70's". The entire discussion around C happens because C is still actively being used.

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.

> 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.

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.

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...

I've used both. C over Pascal any day, warts included.

Disagree. Pascal was no more safe than C

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.

>That is more than 50 years of BEING WRONG.

"I'd like to write software for you, but I have to wait 20 years before there's a suitable language to be invented first."

Code written in C/C++ is running the world. Python/JavaScript/PHP/Java etc. are all thin layers on top of runtimes written in C/C++, running on operating systems written in C/C++, using drivers written in C/C++/Assembler. There is a reason for this. It didn’t happen by accident. C/C++ competed against thousands of alternative languages and won. We are only now starting to see any real competition (Rust maybe?) but there is a looooooong way to go before C/C++ doesn’t run the world.

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.

It seems the world is a pile of shitty shortcuts.

I don't know about the world, but our brains sure are! xD

We rely on cognitive biases (shitty shortcuts) for as long as we can. In many cases, for longer than would be optimal.

at the time the choice made sense for C, today it is a vanishingly rare case that you want a language that doesn’t know how long its own arrays and strings are, or that doesn’t know what might be null.

Reply on news.ycombinator.com