Here are some of my thoughts on why it hasn’t succeeded.
First, obviously, it’s difficult. For most of us programmers, writing a program to do a particular task isn’t particularly tough. But getting the idea for how to do it, that’s the really hard part. Given a little time, any professional programmer could probably write a usable spreadsheet from scratch. But if you go back to (?can’t remember his name?), the guy who wrote Visicalc, the very first one, he probably had a really tough time doing it. You see the same principle at work regularly, somebody writes a killer program with a new concept and within a few weeks or months, there are several clones of it out. Anybody want to start a new thead on what such a language or programming system would look like, how you’d interface with it, what core functions it would need, etc?
Second. It’s a truism in the programming business that about 10% of code actually does the program’s real job, the other 90% is bulletproofing (those numbers may be a bit of an exaggeration but the idea holds). What that means is that the remaining code is there to handle exceptions. In the case mentioned a while ago of
Do 10 times
xxx yyy zzz
In order to make this program work acceptably, you’d need to add additional code to handle situations like – the data that was being handled inside the loop is defective or missing and we have to jump out early, or the person executing the program pressed a key so we have to stop and decide what to do about that, or the operation being attempted there failed for some reason (maybe a write-protected disk of disk-full,) or a thousand other things that might happen. The upshot is that if we wrote a stripped down program that assumed everything worked properly, it would be fairly intuitive to write but nobody
would want to use it. As an aside, this is the one of the root causes of complaints about buggy software. If everything went perfectly, just as the programmer expected it to, the bugs probably wouldn’t happen. You seldom hear somebody complain that “every time I type the letter E, my word processor crashes.”
Third, if we were able to write one, it would probably be extremely inefficient and slow at execution. In order to function, a high-level language (HLL) program like COBOL or C++ or any of the thousands of others has to use the lower
level language components available to it that are built into the hardware, what is called machine code, which is a programming language unto itself and is far more complex than the high level languages. During compilation, each HLL instruction is translated into one or more (usually more and
sometimes many more) machine code instructions. The more layers of interaction or hidden functionality you build into the program, the more instructions are needed to execute it. More instructions means more time needed for the hardware to execute it. In general, the more closely a language is tied to the machine-level instructions, the more complex it is, but also the more fast and efficient it is. That’s essentially why a program written in C is so much faster than a program written in BASIC to do the same job.
Finally, writing a program is a way of solving a problem in a logical and orderly fashion. It requires a certain mindset in order to do it effectively. For the majority of people, I suspect it will always remain a mystery, like programming a VCR. Likewise, for me it’s pretty much a mystery how a car works. While I’m a pretty good programmer, I don’t have the mindset to for mechanical things so I rely on professionals for that. The auto industry could probably build a car that’s easy to fix but the tradeoffs they’d have to make in the process would be unacceptable to the vast majority of customers.