[ChrisMarshallNY]

I, too, am a crusty oldtimer.

I think that a lot of the work in languages and techniques, stems from a distrust of programmers. Most companies seem to think their programmers suck, and take a highly defensive posture in their tooling and process.

I started seeing this in the 1990s, with Taligent (their style guide was a fun read), but I think it predates that.

[Someone]

The 1990s also were the times of software that crashed ‘all the time” and had security vulnerabilities so large that they nowadays would be called open doors.

One can also see all that work on languages as trying to create a language where programmers get help preventing such issues, so that they can focus their attention on making stuff users want and that also produces code as performant as what expert programmers could write in the languages of old.

That’s not distrust, but realization that being vigilant about buffer overflows and data races is a part of a programmer’s job that (maybe) can be automated.p without sacrificing performance.

The kind of stuff discussed in this article, for example, can help compilers move data around less, without introducing potential concurrency issues.

Now, whether this accomplishes that? I wouldn’t know.

[ChrisMarshallNY]

> The 1990s also were the times of software that crashed ‘all the time”

Still a problem. I need to hard-restart my machine multiple times per day, because of two developer tools that spawn orphan processes, all day long. It seemed to suddenly become a problem, when the M1 came out, so I assume that the fault actually lies in Rosetta 2.

[mpweiher]

1. Not on NeXTStep (or Smalltalk for that matter)

2. I haven’t seen improvements in Apple software quality since the introduction of Swift, quite the opposite in fact.

3. Same with perf. In fact, Swift performs remarkably badly, roughly on par with Java.