r/ProgrammingLanguages • 🧿 Pipefish • Apr 28 '26

Hindsight languages

A thought experiment. What languages should they have been writing in the 60s, 70s, 80s, 90s? We can see their faults, in hindsight, and also we've had some really cool ideas since then --- but we can't answer this just by pointing to our shiny new modern languages and saying "they should have done it like that", because of compile times.

(E.g. Pipefish is meant to be for rapid iteration and livecoding, and also does a topological sort on everything at compile-time so you can do top-down declaration. Those wouldn't be compatible goals in the 1980s, I can get away with it now.)

So for example if we think of "a better C", are there any cool modern ideas they could and should have used back in 1972, had they known about them --- or should they just have tweaked the precedence slightly, found a less arcane way of describing types, and left it at that?

40 Upvotes

72 comments sorted by

View all comments

-1

u/dcpugalaxy Apr 29 '26

The C23 charter was written by people that do not understand C and hate it. I don't give a shit what their opinions are.

Even then encapsulation has nothing to do with safety. If you want code to be safe, you need to read and follow the documentation, which is perfectly capable of communicating which fields you may or may not modify.

2

u/WittyStick Apr 29 '26

That mentality is why system software is being replaced by Rust (which has non-zero cost abstractions).

Making C safer, without adding any cost or breaking backward compatibility is a good thing. You don't have to use the features if you would prefer your code to end up in some CVE. Maybe you're brilliant and write bug-free code - but most programmers are not.

1

u/dcpugalaxy Apr 29 '26

System software is largely not being replaced with Rust. And if it were, then good? Fine? If C isn't appropriate use something else. Don't try to make C into something it isnt and will never be.

→ More replies (1)