Star Trek programming II (the wrath of the UI)

Ok, you are a programmer. You are accidentially beamed aboard the Starship Enterprise via a temporal anomaly. You have a short amount of time before you are discovered and returned to your timeline. Do you download the plans for a hyperdrive and take it back with you? Well, yea - of course. But in addition to that you want to know what programming is like in the 23rd century!

What is programming like in the 23rd century? Do people even still "program"? Or do they just tell a computer what they want and that robotic female voice just makes it so? Or is the line between UI and programming just so blurred that the question doesn't make sense anymore?

Programming is about giving the computer instructions on what to do. A UI is also about giving a computer instructions on what to do. Here in the 21st century we draw a fairly hard line between these two things. Programmers write UI's for non-programmer users to interact with. However programmers also write UI's for programmers to write other UI's in - these are called IDE's or Editors. But IDE's are not for users - they are for "real programmers" of course.

Back in the late 20th century some super smart folks were writing a new operating system, and they invented something amazing - pipes. Their idea was that input into a program, and output from a program should be treated as a stream of bytes. What if in the UI of the operating system (the "shell") users could pipe the output of one program into the input of another, regardless of who wrote the programs? Users would be able to compose brand new programs that were made up of existing programs, combined in ways never dreamed of by the original programmers.

It's impossible I would say to gauge the productivity gains enabled by pipes. What I have seen is that piping programs is so commonplace in the *nix world that we can't really imagine what it would be like had this never been invented. I would argue that the impact of pipes is perhaps second to the impact of spreadsheets - perhaps not nearly as impactful as spreadsheets in absolutes, but at least up there somewhere.

From this random site:

"Pipes were first suggested by M. Doug McIlroy" ... "McIlroy's persistence
led Ken Thompson, who developed the original UNIX at Bell Labs in 1969, to
rewrite portions of his operating system in 1973 to include pipes.".

From wikipedia:

"The next day", McIlroy continued, "saw an unforgettable orgy of one-liners
as everybody joined in the excitement of plumbing.".

What legends! It's almost accidential that we have pipes today - how lucky are we? Pipes turn users into programmers. Or perhaps pipes blur the lines between users and programmers. In the same way spreadsheets blur the lines between users and programmers.

Alternate timelines

Some time between the 21st and 23rd centuries, people started to clue-up that the line drawn between user and programmer was arbirtary, inefficient and authoritarian. In the relatively early part of the 21st century we saw an explosion of what was termed "No Code Platforms". These were attempts to hand back control to users of their computing, while still maintaining enough control to make them billable products. No code platforms provided something like walled gardens (or gated communities) where users could have much more control over what the software was doing for them, while still existing in a safe zone with padded walls.

But No Code platforms were like macros. They allowed a certain amount of flexibility but still very clearly drew a line between user and programmer. They were companies that employed "real programmers" and product managers to query and guess the needs of their users. They did not (on purpose) hand the keys to the kingdom to users and say: "knock yourself out!".

Then, something truly amazing happened: a program was written that layed a golden egg. In fact it layed millions of golden eggs - as many eggs as you wanted. This program worked like this:

...

Oh, sorry I forgot. That timeline must have been erased before I could make notes. I guess we are going to have to invent it ourselves ;-)