The Programmer's Paradox: The End of Coding as We Know It

Neal Stephenson was really on to something when he likened programmers of the future to digital construction workers. I certainly feel that way whenever I have to grind out a CSS layout.

Just IMHO.

It seems that the article should a little less categorical.

The typesetting example shows that instruments have changed (typesetting machines(or whatever it called?) to desktop computers), but it still exists - there're many people very skilled in typography these days. And many of them still have jobs in design companies, newspapers (online ones too), etc. I'm not very familiar with that industry, but I've seem many employed people doing typography full-time (on computers, of course).

The ramifications you're talking about in case of programming seem to be already here pretty much.

But they don't mean the end of programming. They just mean that libraries would be developing and much of stuff that can be automated - would be, but you still need to go low sometimes. Take a look at Yahoo Pipes - that's a very high level of "programming", i.e. - take that, transform, output. But still, there aren't many people using it, because more often than not it's: "take that, BUT ...." and that means that you need to go lower INTO the library. The best libraries let you automate the MOST COMMON tasks, but none of the libraries or programming languages available is the ultimate solution supposed to cancel programming.

Just like invention of computers didn't obsolete typography, it was just transformed (the instruments changed).

Someday we (programmers) will be obsolete, but it wouldn't be because of better types or transformations (pointed out in the article), it would be because somebody develops some kind of "brain-in-a-jar" that can transform natural language commands into acceptable electrical currents. (Or whatever kind of energy we would be harnessing at that point).

I.e. "get me some coffee" and the coffeemachine turns on and wheeliebot starts moving; "when I say curse word - deduct 5$ from my banking account" and bank's "brain-in-a-jar" "understands" command from your home's "brain-in-a-jar".

But seeing that isn't going to happen in at least next 5 years, I feel safe :) (5 years, because they recently started growing organs in jars.. who knows when it's simple enough to grow brains in jars). But my guess is that will make a lot of jobs obsolete. And market competition would get fierce!

"Software would no longer be a set of features in an application. Instead it would be millions and millions of simple transformations, which could be conveniently mixed and matched as needed."

Right, so instead of writing lines of code, we'd mix and match from a pool of "transformations"... which would require some means of describing how those transformations should be combined... which is pretty much analogous to writing code.

This prediction has been made repeatedly since 1950 and it has never happened. There are just as many good explanations as to why, so I won't bother enumerating them. I have no idea why new people keep coming up with this same idea.

Typesetting is nowhere near as complex as programming. You have much fewer freedoms to play with and hence much less room for creativity. This comparison is not just invalid: it doesn't make any sense.

He uses the fallacy of the false dichotomy: either something is intellectual work, or it requires little thinking. Since typesetting was 'intellectual work' and isn't required anymore, so will programming vanish. The fact that programming is just about the most complex activity known to man, spanning more layers and orders of magnitude than any other activity, is completely ignored.

This post resonates with me. Without getting too hung up on the typesetter extinction, I think the general notion that the task of "coding" will change is almost a given. Even the early assembly coders of the 60s would be hard pressed to imagine the life of a modern coder working in an IDE.

At a high level I agree with the general change vector the author proposes. I've been code doodling with some of these notions in my spare time for quite a while now. In particular, I think

contexts:

   are nested and form a graph (not necessarily a tree)
   can exist in isolation outside of any other context (e.g. a double entendre)
   are some times shared (a conversation)

transformations:

   *can* have conditional processing
   may not be deterministic (sometimes probabilistic feels better)
   I think other languages can (for all practical purposes) return lists

I think some other key aspects are missing from the description, particularly:

   external (unresolved) references
   self references
   self replication

On a few occasions I've almost written a similar blog post, but maybe this will spur that along. Many of these notions also seem to fit comfortably in LISP (from what I understand).