What happens when that 'higher level language' is the everyday language? Everyone knows it
User: 'Make me a sandwich'
*mighty robot slices up user and places in between two pieces of bread*
Computer: 'You are now a sandwich'>Make me a sandwich.
Do you want to (1) be turned into a sandwich or (2) have a sandwich prepared?
>2
What ingredients do you want in the sandwich?
(etc.)
Although in principle it should be possible to have a machine that performs each iteration near-instantaneously, rather than wait three hours between each change.
^ everything is a file...
Nevertheless, entire industries revolve around correctly writing contracts, making sure they are executed in the intended way, and resolving ambiguities and disputes about the original specification.
If it's ever possible to go directly from English to running code, programmers will still be around; they'll just sound more like lawyers.
You're always going to have people that manage the details and edge cases of complex software systems. Those people will be programmers.
And if there is ever an AI invented that can replace those people then many white collar workers are at risk of losing their jobs, not just programmers.
Lawyers are only paid to create clear specifications some of the time, and that mostly in criminal law and political legislation.
In non-trivial corporate contract law they're paid to find favourable ambiguities in existing specifications, and to build possible ambiguities and hidden implications into negotiated agreements.
They're also paid for their ability to use rhetorical, verbal, and theatrical tricks to persuade counterparties, judges, and juries of their point of view.
Outside of STEM, the relative predictability of code is a very poor and superficial model for the relationships, transactions, and goals that define most domains.
Natural language is rife with ambiguities, contextual information, and implicit assumptions. It is a terrible method for precisely conveying instructions or expectations, even to equally intelligent peers. Making this work at all requires a whole specialised profession with its own elaborate procedures and complicated argot.
If you wandered into an IBM office and said, "I need a document storage system. Here's a blank check; make it happen!", do you think you would be happy with the outcome? Probably not. What changes when you tell this to a chatbot instead of a guy in a suit? Instead, you'd work with someone lawyer/programmer who knows how to spec out the solution in enough detail that the vendor/optimizer can't go "well, you said STORE the documents, but you never said anything about RETRIEVING them later!"
The conversation at hand is not about "programs" in the traditional sense, but more a conversation between a human and an AI which is providing what is asked for.
This is very similar to asking a Genie to satisfy your wishes. You need to be clear and precise or it is likely you'll get exactly what you asked for, but not what you intended.
We're NOT talking about traditional programming here.
> Lawyers are only paid to create clear specifications some of the time, and that mostly in criminal law and political legislation.
Sure, but it appears that a Lawyer's domain involves the interaction between intent, specifications and reality. In all the points you raise, this is what the lawyer is doing.
> In non-trivial corporate contract law they're paid to find favorable ambiguities in existing specifications, and to build possible ambiguities and hidden implications into negotiated agreements.
This is exactly what a programmer is doing almost all the time (when not talking to clients). Finding the edge cases, creating rules. Avoiding or documenting them. Closing the loopholes, turning them into features or guiding the user away from them.
> They're also paid for their ability to use rhetorical, verbal, and theatrical tricks to persuade counterparties, judges, and juries of their point of view.
Okay, so lawyers are sales-people too. Do you really think that programmers are not already salespeople, or have people on their team that are?
> Outside of STEM, the relative predictability of code is a very poor and superficial model for the relationships, transactions, and goals that define most domains.
Bear in mind that a programmer RIGHT NOW is managing the issues that you are discussing, as the computer is only half their domain. The other half is interactions with teammates, clients, etc. They already have to manage "human relationships, transactions and goals."
Instead, I'm arguing that writing an air-tight specification of your goals can be tricky, time-consuming and requires a certain mind-set, even if we assume perfect natural language understanding and ignore all the implementation details by saying that wizards...err...deep neural networks solve those issues. As support for this argument, writing contracts is still tricky, despite everyone involved having perfect language understanding and the sort of generalized intelligence that computers lack.
Therefore, if there ever is an English-to-bytecode compiler, I expect that the "programs" written for it will look much more like a contract with lots of awkward but precise language and much less like "Yo Siri, build me a chatbot." You can call the person who spends all day drafting these things and interacting with the code-generating software something other than a programmer if you want, but if the shoe fits....
I'm also not convinced that optimal defaults exist for many things. You could certainly recommend a data structure based on the way it is accessed (if it's always being queried for the min, throw it in a heap, but use an array or hash table for random access), but how do you gradient-descent your way to a fun original video game without also assuming a decent model of human psychology? At some point, you have to specify that "when the player does X, Y happens", which is programming.
Ruby is a good example of this direction; it's intended to (mostly / sometimes) read like actual english (RSpec is an even better example), but in the context of the language, Ruby's abstractions are precise, rather than the vague abstractions of human language.
Additionally, there's a difference between "able to speak the language the computer can understand" and "able to program something"; that difference is "detail of thought".
I tried to demonstrate this to a friend with a pretty good "Uber but for X" idea. I said - Okay, you want to rate people. Who rates whom? When? On what scale? What do you want each rating to mean? What do you use the ratings for?
Following this train of thought - it's not JUST that we (as in the entire software engineering community) are adding levels of automation, it's that each higher level language adds "default" answers to those questions, so that at some point, you could just say: "Give me a rating system", and you'll get the usually-best one that you can refine; like the core CSS classes. We're rebuilding language from scratch, layer by layer, in order to have non-leaky abstractions.
Or maybe we'll see something like the neural nets that can draw based off a phrase - you say "give me a rating system between users and drivers", and the NN generates something that satisfies, and then you refine from there - "give me a rating system... from 1-10, where normal service is a 7".
So uhm... More seriously, what do you mean?
That name lookup is ambiguous.
What they are, indeed, is dynamic. The lookups you are talking about are done in runtime, so the result of these lookups can vary depending on the state in memory at a given time.
That doesn't mean they're ambiguous. Everything is perfectly unambiguous and deterministic. They're just dynamic. And that's fine.
FYI: People also write tests in static languages.
What I meant were things like automatic type conversions or used of undefined object properties, which aren't ambiguous, but certainly seem ambiguous and lead to many errors.
However, as a specialized language can quite plausibly make you 10% or 100% more productive, no one serious would use general english even if it was a possibility. You might imagine a somewhat efficient programming in a very "jargony" english (similar to "legalese") with very specific (and likely unintuitive) meanings of a large number of particular phrases, but then there's no meaningful advantage of it, it's just as far from everyday english as any other programming language, and requires just as much training.
We might see, say, "Unambiguas English version A", as an experimental or academic version.
Then a trial "English B".
And maybe on the third try, they'd get it right, say, "English C". We could call it "C" for short.
(I know, I skipped BCPL.)
You can't fully understand human language with anything short of Strong AI. And yes, we made some progress in our ability to extract specialized meaning from natural language with high level of accuracy for things like translation or indexing - but we didn't get any closer to having computers understand and reason about the meaning of the text.
In short, to say that we're rapidly getting to the point where computers can replace programmers in understanding natural language requirements and designing programs that achieve these requirements, you need to show consistent progress in general-purpose AI.
However, you might still need a huge bunch of english text to describe the problem domain. If such a text isn't already available, you need to write it yourself (coding).
However, you might not write it in one shot, so you need to store it in text files that you can read and modify later. Maybe you would team with other people to write it, and you would share and track your modifications (versioning). Maybe, to make it easier to manage, you would split your description in multiple text files (modularizing).
And then, you'd need a way to ensure that your text actually unambiguously means what you want. So you'd need ways to identify (testing) and correct (fixing) theses ambiguities.
And maybe, at some point you would change your mind on some behaviours ; and then you'd come back to your description and modify it so future behaviours changes might be easier to deal with (refactoring).
And also, maybe your intelligent system has inferred a correct way of doing things that is actually too slow. Maybe you could order "do it faster!", or maybe you would need to identify the source of slowness (profiling), and edit your description so a faster behaviour is inferred (optimizing).
At this point, you in an attempt to improve your efficiency, you might consider using a simplified notation, which would be less-ambiguous and less verbose (like did scientists, musicians, engineers, mathematicians ...).
See, nothing to do with programming!
Natural language typically doesn't supply many sound abstractions. Everything you say is open to interpretation, as the many misunderstandings in this very thread clearly demonstrate...