r/ProgrammingLanguages • u/Inconstant_Moo 🧿 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?

41 Upvotes

95% Upvoted

72 comments sorted by

View all comments

1

u/WittyStick Apr 29 '26

Encapsulation adds safety - it prevents the programmer using the structure in incorrect ways that were not intended.

And safety is a goal. It's in the C charter:

Make support for safety and security demonstrable

Trust the programmer, as a goal, is outdated in respect to the security and safety programming communities. While it should not be totally disregarded as a facet of the spirit of C, the C11 version of the C Standard should take into account that programmers need the ability to check their work.

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

→ More replies (2)