> you periodically need a CS degree to follow code.
I have a CS degree, and the issue is not so much being able to follow the code, but wanting to.
Roughly 99% of the issues the Swift designers appear to care incredibly deeply about are things that have never, in my now almost 40 years of programming, popped up on my radar as something I would be even marginally concerned about.
And that's not because I am generally unconcerned, quite the opposite. Heck, I've been working on my own language for over a decade despite not really being all that much into languages, simply because I strongly believe that things need fixing, badly.
I think it's this (type of) disconnect that is at the heart of the trouble with Apple software development these days.
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.
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.
> 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.
I have a CS degree, and the issue is not so much being able to follow the code, but wanting to.
Roughly 99% of the issues the Swift designers appear to care incredibly deeply about are things that have never, in my now almost 40 years of programming, popped up on my radar as something I would be even marginally concerned about.
And that's not because I am generally unconcerned, quite the opposite. Heck, I've been working on my own language for over a decade despite not really being all that much into languages, simply because I strongly believe that things need fixing, badly.
I think it's this (type of) disconnect that is at the heart of the trouble with Apple software development these days.