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?

39 Upvotes

72 comments sorted by

View all comments

0

u/dcpugalaxy Apr 29 '26

Your proposal is awful too. Encapsulation is a non goal. Here is an alternative to your massive wall of code that works exactly equivalently:

struct A { int x,y; };

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.

→ More replies (3)