5 ms·

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 receivi

by prirun 5y ago

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.

agumonkey 5y ago
It seems the world is a pile of shitty shortcuts.
- judahmeek 5y ago
  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.
41c2 5y ago
gameswithgo 5y ago
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.
grymoire1 5y ago
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.
- 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?
deleted 5y ago
[deleted]

by prirun 5y ago

agumonkey 5y ago

It seems the world is a pile of shitty shortcuts.

judahmeek 5y ago
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.

41c2 5y ago

gameswithgo 5y ago

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.

grymoire1 5y ago

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.

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?

deleted 5y ago

[deleted]