A story. As Petzold writes, the Windows version of "hello world" was amazingly baroque. It bothered me, a lot. I had come up in the four line hello.c world of UNIX, and later the make/test world of UNIX, and when I had left Sun the idea of writing code like the Hello World example was something I could not bring myself to do. I rebelled in a bunch of different ways, but the worst part was it started a period for me where I programmed a lot less, I was getting curmudgeonly because programming had become so screwed up.
The thing that changed for me was getting a chance to help a young man with his programming who had come up through Windows rather than something easier, and he was full of all the wonder and excitement I had had at his age for programming, and had no idea that he was running with a large handicap to his productivity. And partly because many of the "tools" you had to have like Visual Studio worked their butt off to make that gap small, from self writing code to documentation at your fingertips. I realized that if I didn't get the 'wonder' back of writing code I was going to become one of those guys who sits around grumbling about how in my day things were so much better and FORTRAN just worked dammit :-).
What I tried to learn from it was that systems with great generality suffered from usability efficiency. The reason UNIX hello.c was so simple is that UNIX programs, by and large, did simple things, algorithmic computation driven by interaction over a character based interface. One way to drive effecive use of a system was to either eliminate or otherwise hide the modalities that were "possible" but not probable in future execution of the program.
That has helped me see when I'm building something that is letting to much generality leak out to the surface.
"What I tried to learn from it was that systems with great generality suffered from usability efficiency."
I'm entering "curmudgeon" age myself, at least for our industry, and what I'm getting curmudgeonly about are my fellow curmudgeons, and that's part of why. Oh, programming was so much better in the 8-bit era? So go back there then. It's still available to you if you want it! Oh, you don't want to take actions to match your words? Why not? Because, in a nutshell, no it wasn't easier. It was easier to do the things it could do, sure, but it can't do much. So stop telling me about how wonderful the 8-bit era was.
That's just one example. There's several of these recurring rants that come up here on HN periodically.
Well said, in particular this bit, "Oh, you don't want to take actions to match your words?"
There is a downside though when you get a curmudgeon with a fondness for the "old" days and takes action by re-implementing your build system to look like something you would read about in an IBM JCL handbook :-) I'm sure 8 character error codes were easy to remember but even better is a short sentence on what the error was.
The thing that changed for me was getting a chance to help a young man with his programming who had come up through Windows rather than something easier, and he was full of all the wonder and excitement I had had at his age for programming, and had no idea that he was running with a large handicap to his productivity. And partly because many of the "tools" you had to have like Visual Studio worked their butt off to make that gap small, from self writing code to documentation at your fingertips. I realized that if I didn't get the 'wonder' back of writing code I was going to become one of those guys who sits around grumbling about how in my day things were so much better and FORTRAN just worked dammit :-).
What I tried to learn from it was that systems with great generality suffered from usability efficiency. The reason UNIX hello.c was so simple is that UNIX programs, by and large, did simple things, algorithmic computation driven by interaction over a character based interface. One way to drive effecive use of a system was to either eliminate or otherwise hide the modalities that were "possible" but not probable in future execution of the program.
That has helped me see when I'm building something that is letting to much generality leak out to the surface.