http://queue.acm.org/detail.cfm?id=2349257
That article finishes with:
“But to anyone who has ever wondered whether using m4 macros to configure autoconf to write a shell script to look for 26 Fortran compilers in order to build a Web browser was a bit of a detour, Brooks offers well-reasoned hope that there can be a better way.”
A man after my own heart.
But what can be done? Can there be a better way? I don’t think so.
I have come up with a new theory relatively recently, in the past year or two to explain this:
I think we have reached “peak programmer.”
The work of rewriting the same stupid lines of code to read in command line params or process the “list” function from a json call, can’t be built once and reused, so everybody has to implement it themselves for their particular application or database or whatever.
And people like to do that, and they’re good at it because they’ve listed the items in a database a million times. They just like doing it with new frameworks and cooler c++ techniques. These are sometimes called “disk to screen” applications, which is really 99% of what everybody does.
But that’s it. That is peak programmer. That’s what most of the people who are programmers are capable of doing at least reasonably well. Well maybe. See below.
To do the next thing requires really smart people (I mean REALLY smart people) who can come up with the algorithms that are the backbone of neural networks and machine learning and all that. People who are not interested in just typing in the same crap all over again in a different programming language but are ready to and CAN invent the next paradigm shift departure from “disk to screen.”
For example: writing a program that can take an audio sample, and find a song match from what’s playing in the sample despite background noise, low volume and only getting a random snippet of the song. Not too many disk-to-screen-ers would be able to pull that off, I think.
I think there just aren’t that many people capable in the world. Programmers may be a small minority overall, but the people who will move the world next probably number in the thousands, if that. I think we’re running out of steam, the technology is getting too hard, abstracted away, layered with crap and filled with things like automake and autoconf and configure.
And it’s not going to go away. The pile of shit we have built as an industry has caught up to the average smart programmer intelligence.
We can’t make it better. We could start from scratch and build something better, but that will never get any traction so it will never take off. I’m sure people do projects like that and you never hear about them because it doesn’t run windows or simply because the barrier to adoption is too high.
The quantum computer? It is doomed. I can tell already. As soon as somebody gets something to work that is even moderately consumer usable, somebody will write an x86 translation layer for it and then get linux to run on it, and then windows and then all we’ll have is slightly faster computers that are even more shittily designed than what we have now.
I’ve got a few ideas for marvels of the future (like a computer that doesn’t need disk, or filesystems or files, the technology already exists) but everybody I pitch it to says “nope, never going to happen.”
Because we’ve reached peak programmer and nobody wants to or can do anything beyond disk to screen.
You know what really made me sad recently, it really hurt when I saw this:
The other day I was trying to help a friend find and set up a better print-screen screen-area selecter in xubuntu.
You go to the settings menu, then the keyboard option, then application shortcuts.
Click on the program entry to edit, change the setting, click ok and….
“System program problem detected.” or whatever it says when a program crashes.
That’s right. Just wanted to change the command that gets run when you hit a keyboard shortcut, and for that, I get a program crash.
This actually turned my stomach a bit. I often complain that nobody ever tests anything but the positive test case of their software, but this wonderful work of art, couldn’t even do that.
And I’m sure while it might seem simple to a programmer “just read the value from the text box and update a config file” I’m sure what’s actually going on is that there are layers and layers of remote target endpoint updater (even though the endpoint is just a config file on the same machine) and user interface abstraction text box locator (even though it’s just a textbox that GetWindowText could handle). And each of those layers and the libraries they rely on are all positive-test-case-only tested, and as a result, I want to use a feature of the UI manager that somebody thought was a good idea to bother writing a feature for, and I can’t because it blows up when I try and use it.
Peak programmer.
Updating a config file from a setting in a text box is beyond the abilities of the average software developer.
I have another friend who says “Complexity breeds profit.” So at least I know I will never be for want of employment.
Maybe what’s really going on, is that we’re doing this on purpose to make sure the computers can never take our jobs away.
This entry was posted
on Sunday, December 3rd, 2017 at 2:29 pm and is filed under Notes.
You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
I’m totally done with the m4/autoconf crap. Maybe that made sense when you had to detect whether your program was building for Brokenix 99 running on a 36-bit VAX with a left-hand-threaded MMU. Maybe at some point back then, it made sense to have a configure script that detected all sorts of idiosyncrasies, and then an m4 script to write the configure script because it got too complicated.
Today it just doesn’t make sense. My newer builds just have a simple Makefile, and a shell script, maybe 15-20 lines long, called by the Makefile to fill in some variables.