[Samis2001]

Here's the problem with that idea: How do you convert your abstract high-level description into a set of specific operations? First you need to parse your specification, and parsing natural language is already hard. Secondly, you have to infer everything else that was requested and will be needed but was not originally specified.

Alright, now you have your list of requirements. Firstly, you must break each requirement down into a long series of small steps that perform exactly one operation - such as add 1 and 1 together. You must also find the correct order for all of the steps, as well as the operations to store and manage all required data in memory as meeded.

Finally, the list must either be translated to the native language of your computer's CPU or ran by a program running on the CPU.

As you can see, this is actually a large and difficult task, even if you manage to not encounter any unsolvable problems along the way. I would think the following comes naturally: The difference between your language and the 'dumb-as-rocks' ones is that the latter are implementable and usable.

[logicallee]

>Here's the problem with that idea: How do you convert your abstract high-level description into a set of specific operations? First you need to parse your specification, and parsing natural language is already hard. [my emphasis]

If that were true it would be impossible to make a flow-chart based interface to a "compiler" that produces an executable based on the flowchart (without any keywords, variable names, etc). But plainly it is possible to make such a flowchart->executable compiler+visual IDE, so you are incorrect regarding the claim that the specification needs to be parsed lexically. Functionality does not depend on lexical parsing. It's that simple.