Programming pain...

Programming pain...  An article on a topic I've often pondered myself: why is programming so damned hard for most people?  Some of it is the tools, which is what this article focuses on.  I used to fantasize about a graphical programming environment, in which a user could “draw” their program, much as an electrical engineer used to draw a schematic.  I say “used to”, because much of hardware design (anything but the simplest devices) is designed these days using text-based hardware design languages – even hardware has given up on graphical design.  Why?  In a nut shell, complexity.

The complexity of computer systems (by which I mean both the underlying hardware and the software) have grown many-fold just over the course of my own career.  The Univac mainframe computers I first worked with, back in the '70s, were not the biggest or most complex computers of the day – but they were pretty high on the computing complexity scale.  The ship I was on had 12 interconnected (we didn't use the word “network” back then :) mainframe computers, organized into functional units (radar, tracking, missile control, etc.), each of which had its own program.  Those programs ran directly on the hardware – there was no operating system as we know the notion today.  The sum of all that hardware and its specialized software – which seemed so big and complicated at the time – is downright trivial by comparison with a single cheap smartphone running Android.

I think that complexity is the main reason underlying the difficulty of programming.  While I believe there are many things that could be done to make that programming a bit easier, none of the things I can think of would make a significant dent in the overall complexity of the problem.  Short of actual machine intelligence (something I am highly skeptical of), I don't see any answers other than relying on those weird geeks that know how to program...