[markbnj]

> 1995 was the year in which programmers stopped thinking about the quality of their programs.

Oh, please. There are some good points in the article but that hyperbole was unnecessary. I was programming in 1995, and nobody stopped thinking about the quality of their software.

[wglb]

I’ve been programming since 1965, read Dijkstra, Niklaus Wirth. And these days I break software at people’s request. There is in fact much less concern and emphasis on quality these days.

It is also interesting to note that Knuth also does not do libraries

[markbnj]

> I’ve been programming since 1965, read Dijkstra, Niklaus Wirth.

Well sir, you have me by ten years, and believe me I respect that extra decade. That said, I think you're falling into the trap many of us greybeards tumble into as we get older: the things we cared about and focused on become, in our minds, the right and true perspective that has been lost or disregarded by younger practitioners. It's really not very different from "When I was your age I walked to school every day, uphill, both ways!" Or maybe it's just me.

Yes, there are far fewer programmers hand optimizing assembly code, and yes every programmer now cobbles together applications by reusing code written by other programmers, some of which is very good, and some of which is not. But if programmers were still spending their time optimizing low level loops and eschewing any code that they did not personally write and verify the beauty of, the world we have today would not exist. Instead of zooming with my family in the middle of a pandemic we'd be exchanging emails, or posting on a BBS to say "Hi!" There's obviously still a need and role for people who like to work at that level, and that kind of engineering remains fascinating (one of the reasons I love to read the linux kernel mailing list), but I don't bemoan the rise of high level languages, libraries, package management ecosystems, frameworks and the like. That stuff has given us the world we have today, and a few warts notwithstanding I still like it much better than the one we had.

[wglb]

Whippersnapper. I grew up in Montana back when winters were severe. I did walk to school—about 25 feet as my parents drove me.

None of what you seem to think about my rant represents what my position is. Read my other note in my thread about the NYT article concerning Knuth and Norvig’s commentary. There is a time today for total deep dive. There is skill involved to do this and wisdom when to do this.

There are folks who write with minimal libraries cf qmail.

What seems to be completely missing from today’s discourse about programming is something dijksata said about interrupts. Paraphrasing “If you don’t see the code on the page in front of you, you will make mistakes. “

Take a look at modern Java. Levels of abstraction in use require serious deep dive to truly know what is going on. There is a famous Node package issue where code that wasn’t even on your computer crashed a swath of applications.

Quality in the context of the article means the code is pleasing to read, doesn’t crash unexpectedly and doesn’t have side effects that you may only discover when Brian krebs emails you about your customer’s data ending up in some remote online flea market

[bfuclusion]

I'd say it's probably more a factor of the _requirements_ of the software getting harder. Pre 1995 most developers were writing apps running on a desktop that wasn't even multitasking. Post 1995 you have preemptive multitasking, TCP/IP / GUIs / multi platform / search indexes, etc. Most don't have the brain power to be experts in all those fields, hence you have to pick where you can excel in quality.

[wglb]

Sorry, I don't buy that. In 1970, I was writing multi-tasking assembler language code to real-time data collection of medical EKG data, feeding what we today would call an expert system or even AI to generate an English language cardiology report and sending it back to the hospital, first via paper tape carried over to ASR 33s, laater by dialout (where each character generated an interrupt). We gave ten minute turnaround.

I cringe today when programmers struggle with async processes in C or other languages, or async/await. We (Michael Whinihan and I) developed a dead-simple pattern using co-routines that vastly simplified interrupt driven programming. It is as if folks these days haven't read https://www.amazon.com/Operating-Principles-Prentice-Hall-Au...

I did a significant fraction of the work to build this, I wasn't the smartest guy in the outfit either. (Probably the most smart-aleck.) Check out one of the team members: https://en.wikipedia.org/wiki/Fibonacci_nim.

None of us were experts when we started this. We figured all the parts out and made it work, reliably. We had on the order of a small integer numbers of hours of outages per year. This was before Tandem Computers was born.

Now serving the medical community puts some pretty stringent requirements on what you build and how you operate it.

[OnlyOneCannolo]

Can you elaborate on the Knuth thing?

[wglb]

Reading his TAoCP you can see it in action.

The wonderful NY times article https://www.nytimes.com/2018/12/17/science/donald-knuth-comp... talks about this, with a quite from Norvig:

In those early days, he worked close to the machine, writing “in the raw,” tinkering with the zeros and ones.

“Knuth made it clear that the system could actually be understood all the way down to the machine code level,” said Dr. Norvig. Nowadays, of course, with algorithms masterminding (and undermining) our very existence, the average programmer no longer has time to manipulate the binary muck, and works instead with hierarchies of abstraction, layers upon layers of code — and often with chains of code borrowed from code libraries. But an elite class of engineers occasionally still does the deep dive.

“Here at Google, sometimes we just throw stuff together,” Dr. Norvig said, during a meeting of the Google Trips team, in Mountain View, Calif. “But other times, if you’re serving billions of users, it’s important to do that efficiently. A 10-per-cent improvement in efficiency can work out to billions of dollars, and in order to get that last level of efficiency, you have to understand what’s going on all the way down.”

[billfruit]

Proliferation of hyperboles has gone out of control, hard to read news, and watch YouTube videos without writers/content creators, or even normal people speak in daily life without this very annoying pattern. I think problem is worse among our American cousins, than elsewhere in the English speaking world.

[emmelaich]

> Proliferation of hyperboles has gone out of control,

:-)

[naikrovek]

Well if you have to pick a line, a point in time where the industry crossed a threshold, I'd say the author picked a good one.

There were people who didn't care about software quality in 1960 and there will be people who do in 2060, so no matter what year he chose, a lot of people would dismiss any chosen year as hyperbole.

As time moves forward, and more "healthy" ecosystems grow up around languages (like unwanted mold or fungus always does) software is going to get slower and slower and slower. And saying that it's a problem will always be an "old man is shouting nonsense again" moment to most young developers.

[nl]

It's like they never actually ran Windows 95 and had the experience of people accepting your operating system crashing daily. It was much more reliable than Windows 3.1 after all (and to be fair to MS, was also more reliable than MacOS System 7 and ran faster than OS2).

There's always been good software and bad software.

[TheOtherHobbes]

Windows particularly made terrible software acceptable. Windows really was an utterly unforgivable PoS compared to DR's Gem + TOS on the Atari and AmigaOS (multitasking!) on the Amiga - both of which were already around in the mid-80s.

It really took incredible hubris to sell Win95 as a huge step forward for the industry when it was so hugely inferior in quality to an OS that had been hacked together by a small team of best-in-world hardware and software designers ten years earlier.

But it did succeed in one area - which was doing a great job of lowering consumer expectations and making the most appalling carelessness and incompetence seem like a boon from the tech gods.