In the beginning, there were switches on consoles. Later on came the command line, and later still, the text editor.

That's where program entry and editing tools just about stopped until a short burst of creativity in the 80s (I think) yielded the "syntax directed" program editor (SDE). This was a special-purpose tool that understood the syntax of a particular programming language (usually Pascal) and, instead of letting its user type any random gibberish, they could instead type in any random syntactically-correct program in that language. Of course, this removed lots of irritating syntax errors at the cost of producing lots of irritating constraints on how programs looked as displayed on screen. Programmers being the primadonnas that they are, they rebelled against enforced standards and this technology soon flopped in favor of more powerful text editors that could do things like keep parenthesis balanced regardless of document content.

In a sense, this is another example of "worse is better". The SDE was so tightly coupled to its one task of producing programs in Pascal that it was utterly useless for anything else. However, Pascal did not become the dominant programming language, and even if it had, then there might have been issues of compatibility of file format between different editors and compilers. Ordinary ascii text was the best medium for expressing programs because of its complete flexibility. You don't need a highly specialized tool for text, and it's relatively simple to provide a comfortable program entry and editing environment that works the same way all the time.

There is at least one more interpretation of the same history, though. It might be that syntax direction just didn't buy enough to be worth the extra hassle. In a simple economic tradeoff, programmers chose flexibility over protection from syntax errors.

Frankly, syntax errors don't cost much. They are always caught by the compiler, and most of the time, they take only a few seconds to fix. In short, this type of protection was a bad gamble.

On the other hand, let's look higher up the totem pole. What happens when a program accurately expresses the wrong computation? We'd like to prevent that, but it's equivalent to the problem of telepathy. Even when you prevent simple mistakes by careful use of libraries and high-level languages, at some point you have to decide what you want the computer to do, and then write the program.

Well, maybe not exactly. What if you don't write the program per se, but instead engage in conversation with the computer about what its task is? What if it could ask you directly for the information needed in a particular operation, instead of expecting everything to come in a perfect packaged source file?

At one extreme, a GUI is exactly that. As you use your packaged program, any questions it has for the operator result in dialog boxes. After waiting patiently for user input, the program proceeds to do work.

Another example is the spreadsheet. Each cell represents a portion of an overall program, and as the user operates the spreadsheet tool, her program evolves to include real-world data, calculations, and charts. Visicalc, Lotus 123, Excel, and Gnumeric are super-high-level programming languages in that respect.

What can do for systems programming what Visicalc did for financial modelling? Is there a middle ground for the programming task?