[0xbadcafebee]

Lisp, Algol 68, Pascal, Smalltalk, ML, all had both memory safety and type safety. Nobody uses it today. Why? Because software isn't developed by rational beings choosing the best tool for the job. It's developed by humans who are influenced by their cultural norms and environment. You can give someone a perfect programming language that produces bug-free programs, and they'll reject it because it uses curly-braces or some shit. Write all the papers you want; as long as the inmates are running the asylum, there is no safety.

[pron]

Algol 68 and Pascal weren't memory-safe, and as for Lisp, Smalltalk, and ML, their style of memory safety - based on GC - took over the world pretty much the second it became practical enough for widespread use.

It is true that some decisions people make aren't rational, and it may even be true that most decisions most people make aren't entirely rational, but the claim that the whole software market, which is under selective pressures, manages to make irrationally wrong decisions in a consistently biased way is quite extraordinary and highly unlikely. What is more likely is that the decisions are largely rational, just don't correspond to your preferences. It's like the VHS vs. Betamax story. Fans of the latter thought that the preference for the former was irrational because of the inferior picture quality, but VHS was superior in another respect - recording time - that mattered more to more people.

I was programming military applications in Ada in the nineties (also not memory-safe, BTW) and I can tell you we had very good reasons to switch to C++ at the time, even from a software correctness perspective (I'm not saying C++ still retains those particular advantages today).

If you think so many people who compete with each other make a decision you think is obviously irrational, it's likely that you're missing some information.

[heresie-dabord]

> What is more likely is that the decisions are largely rational, just don't correspond to your preferences.

Cyber Security itself is an example of this. It may seem rational to want guarantees of security for the entire supply chain. But that simply isn't possible in reality.

A professional effort is the judicious application of resources to the highest priorities. That includes care in design and testing. Applications built with C and C++ are running everywhere around the world, every minute of every day.

[daymanstep]

What were the reasons for switching from ADA to C++ if I may ask?

[pron]

The compiler was much faster, the tooling better, and it was easier to find knowledgeable programmers (we were spending quite a bit of time sifting through thick Ada reference manuals). Whatever correctness benefits Ada provided at the language level were more than made up for by C++'s productivity boosts (at the time) that allowed writing and running more tests and fixing bugs more quickly, resulting in code that was no less correct and easier to maintain and evolve to boot.

[sramsay64]

This was my experience of Ada as well. Beautiful language, that somehow seemed to combine the best parts of Haskell and C. But so difficult to find documentation online. C++ has it's footguns, but it's hard not to learn them all just from the background noise alone. The tooling and stackoverflow-ability makes C++ feel as fast to develop as a scripting language in comparison to Ada.

[elcritch]

I wonder if LLMs could change this calculus. Though Ada is in a situation where it likely doesn’t have much open source code to train on.

[kelseyfrog]

An enormous factor here is the cult of speed. This mantra — performance above all — has touched every generation of programmers. The zero-overhead zealots, the minimal-runtime purists, these camps are not only present, they are crowd out every other perspective. It's not that their arguments are entirely unfounded. Language choice does have a causal effect on application performance. The issue is that these voices drown out all others.

The root of the problem is measurement. Speed is one of the few dimensions of software that is trivially quantifiable, so it becomes the yardstick for everything. This is textbook McNamara Fallacy[1]: what is easy to measure becomes what is measured, and what is not easily measured is erased from the calculus. See developer velocity, cognitive overhead, maintainability, and joy. It's the same fallacy that McNamara made in Vietnam and Rumsfield made in the War on Terror so at least they're in good company.

This singular focus distorts decisions around language choice, especially among the inexperienced, who haven't yet learned to recognize trade-offs or to value the intangibles software process. Like you said, humans are irrational, but this is one particularly spectacular dimension of that irrationality.

1. https://en.wikipedia.org/wiki/McNamara_fallacy

[alex_smart]

> performance above all — has touched every generation of programmers

I find it hard to reconcile this with the actual observed trend of all software getting slower and more memory intensive over time

[sevensor]

My observation from internal C projects I’ve worked with is that they often end up doing the wrong thing very fast, because the right thing is so hard to express in C. If you do the wrong thing ten million times, it can start to approximate the right thing. The best of all worlds is using a low level language for speed and a high level language for dealing with complexity. I very much doubt there’s one right language for everything.

[kelseyfrog]

You can simply scroll down in this very comments section to find folks arguing about the performance characteristics of various languages in the context of making claims about their benefits. Res ipsa loquitur

[eviks]

That's simple indeed, but also simply wrong. Reality of actually written apps is a way more important factor than such comments, and in that reality the cult of performance is tiny, not crowding out everything else

[mittensc]

> An enormous factor here is the cult of speed.

Application performance is a very important factor. To ignore it is foolish.

[kelseyfrog]

Help me understand how this went from "There are factors other than speed that are important too" to "ignore speed." Would different phrasing conveyed the idea more effectively?

[burnt-resistor]

Pascal has subrange integer types. I'm wondering if any other language besides family relatives Ada or Delphi has this, apart from dependent type systems like Idris[0] or an explicit Haskell type like Data.Range.[1]

0. https://stackoverflow.com/questions/28426191/how-to-specify-...

1. https://hackage.haskell.org/package/range-0.3.0.2/docs/Data-...

[adgjlsfhk1]

rust has this to some extent (also enums can be seen as an evolution of this for some use cases)

[steveklabnik]

And it's quite possible it will get a fully equivalent thing someday, we'll see.

[ksec]

I am the only one on HN that brings up Ada because I think it deserve some credit. But then it seems there are a lot of hate towards Pascal style syntax.

[johnisgood]

I bring it up all the time. :P

[steveklabnik]

"table stakes" does not mean "guaranteed to succeed," so it's no surprise that some memory safe languages have died.

[1vuio0pswjnm7]

"You can give someone a perfect programming language that produces bug-free programs, and they'll reject it because it uses curly-braces or some shit."

Ada does not have curly braces.

Stephen Bourne, author of the Bourne shell, used macros to make C memory unsafe language look like Algo 68 memory safe language.