Why Isn’t Programming Futuristic?

Programming is futuristic. It's just that we can always imagine a better future -- and that's what makes programming so awesome. It enables us to build that future.

But if you compare Ruby or Clojure to Forth or COBOL, there's no way you can't see how far we've come. And there's no end of improvement in sight.

I think the explanation for this is relatively simple:

The obvious is that the low hanging fruit has been picked, so of course the rate of change is going to decrease as the problems get larger and harder to solve.

The less obvious is the massive influx of users for these languages/tools. There is an unavoidable regression to the mean related to ability/willingness to expend effort that comes from that influx.

In the previous era if you were involved in any way with programming you were, by definition, interested in pushing the boundaries. Now the majority are actively resistant to change like humans are with most things. This is their job, and changing how things work threatens their livelihood.

So why have the subset of people who are willing and able to do these things not doing them? I say some of them are doing it, but not enough to get a critical mass (at least a critical mass that would lead to the kinds of widespread improvements being discussed).

Obviously this is affected by the subculture I'm in but the most common reason I've encountered why these new ideas don't get traction is because it's considered a waste of time. Learning a new way of solving problems is time not spent spamming other social networks trying to increase signups to your social network. Growth Hacking is "getting shit done!", using some new technique that requires learning something new in order to be more productive is considered Ivory Tower bullshit.

Both Clojure and Haskell are communities I follow where there is real interesting futuristic work being done right now. But Node.js, with it's basis on callbacks is way more popular. Even though everyone in the 70's agreed that continuation passing style was a usability nightmare for programmers and put a strict limit on the complexity a human using it could handle.

Looking at it another way: Programming is futuristic, it's just that most people are too lazy to bother and just stick with the older stuff that works the way they are comfortable with, then human nature kicks in and labels everything they don't do as "stupid waste of time".

Alternatively you could compare Ruby to SML and appreciate how far we've regressed.

The iPad is the pinnacle of the marketing job of making people forget everything that came before :)

But, seriously, Haskell, for example, is quite practical (better than the imperative languages) for a big set of applications. One problem is that people want a language to rule them all - and that language can only be imperative; the other problem is that people don't want to learn different things, and a new paradigm is as different as you can get in programming. That makes everything else unpopular.

Personally, I prefer just seeing raw text on a screen, without a fancy IDE, just a plain vi session. If it is my own code base, then I already know what is where, and can navigate / update very efficiently. If however I am working on someone else's code base, then it is necessary to study it for some time before diving in. What can really help in this case is a "code map" -- a document that gives a tutorial introduction and reference to the code, what is where, and why, etc. Included in the code map would be both program flow, and data flow (what data goes in, how it is transformed, and where it ends up). So what is needed is tools to help maintain that code map document so it doesn't get out of date.