Graduate of analytic philosophy here (concentrating in philosophy of language), and my take away is a sloppy: "It's not a bug, it's a feature."
Sorry, but this is a completely shocking article to me. First in it's immediate dismissal of any formalism inherent in natural language, but also with the ease at which he dismisses the proposition without any real consideration.
If we learned anything from Chomsky, it's that the underlying grammar we are born with is both instinctual, and follows formal rules. To say differently is literally, demonstrably false. Irregular verbs, for example, aren't learned in the traditional sense, one must actually unlearn the formal rules. Any child that tells you she "swimmed" all afternoon is using a more formal version of English than you do.
The idea of a natural language programming language is flawed, but not by formalism. It's flawed by the evolutionary nature of natural languages. That is, the very people that he states "are no longer able to use their native tongue effectively," are probably using a new dialect that shares a common ancestor with his more "traditional" usage.
Many people in this thread are talking about the inability of plebes to express what they actually want. This is a fair point, but not a problem with language specifically. Communication tools would need to be employed by a computer in the same way as humans use them. E.g., a simple ambiguity checker could work wonders here, as it does between humans when someone you are talking to simply says, "What did you mean when you said you 'realized you forgot your phone at the train station'? Did you forget at the train station, or realize at the train station?".
What IS a problem, however, is Quine's indeterminacy of translation. That could pose serious hurdles that may be insurmountable, however, we still have effective communication between humans, so it's simple to see how this may only be a theoretical problem, rather than a formal one.
This subject should be under the purview of analytic philosophy and linguistics, not mathematics or computer science.
It seems an appalling number of people agree with Dijkstra here - "we not only don't need natural language, we don't even want it."
I'm sorry, but if I can express to a human being a set of directions to fill out a form in a minute or two and expressing that to a computer takes much longer and is more error-prone, that is an inefficiency in software development which it is extremely desirable to address.
There is nothing magical about human brains that would make them theoretically impossible to express in software in such a way that we can give a program natural language directions, and the fact that so many people want to dismiss this endeavor out of hand is ridiculous to me.
This should be our holy grail, something to strive toward, not something to ignore.
In fact I would suggest that it will most likely be the only way out of the mess of such a wide variety of software standards (ever have fun moving your things to a new system and having to re-learn many things just because you changed PC or phone operating systems?), whereas natural language is a standard we already have and works fine.
This way you essentially wouldn't need to learn a new set of incantations - just tell the damn thing what you want the damn thing to do, dammit.
The thing is, natural language suffers from many of the same problems. I'd say it's even worse, because it requires a common cultural background between the interlocutors.
Ever moved to a new job and had fun figuring out the local terminology, and learning the in-jokes (and figuring out when you were the butt of the joke but didn't quite get it), and when your boss told you to "just do your damn job and quit pestering me", did you immediately know he was just having a bad day and it wasn't your fault at all?
A mistake in understanding these "natural language incantations" will lead to you doing the wrong thing, or feeling embarrassed or depressed. Not so different from a system crash, when you think about it.
Thankfully machines never feel embarrassed or confused about the "damn thing" you want them to do. They only do the things we tell them, in a painfully literal way.
After all, when people want to be really precise, they use mathematical notation :)
Of course you are technically correct, however I retreat back to my main point: we do this every day and it works just fine.
Certainly not perfectly of course, but go and ask people who use some sort of CRUD system that used to be manual what they like and what they dislike about the new system.
Likely very few of them will say it is easier to use than just asking Sharon in the next cubicle to verify something.
They will have some likes, sure - but they will be things like the almost infinitely increased speed or the fact that they can access the system 24/7 while Sharon needs to sleep and take a break to eat the occasional Ding-Dong, but the ease of use that comes with dealing with another human being is a sacrifice that they make for these benefits.
(or to put it the reverse way, imagine the same office and a new employee named Eliza comes in and behaves exactly like a computer, "only doing the things you tell her in a painfully literal way." How quick would you want to give her the boot?)
> After all, when people want to be really precise, they use mathematical notation :)
Again, this is absolutely true. The problem is when you're dealing with a simple CRUD app for your insurance house or just copying files over to your iPod, you're not interested in being really precise - you're interested in the shortest path to get a relatively simple thing done.
If that path is blocked by the fact that you don't know the particular menu item, keyboard shortcut, or command switch for something that you can express in English without even thinking about it, then I regard that as a huge opportunity for technology in general and our industry in particular.
I fully agree conciseness is valuable! If a formal system doesn't have a direct route to the action you want, it probably can be improved. I don't think shorthand and formalism are opposites.
I also agree that a lot of people tend to shy away from formalism. I think that's what Dijkstra was lamenting.
By the way, what is a CRUD? John Doe doesn't understand the word. What do you mean, Create-Read-Update-Delete? He understands some of those words, but I'm unsure they mean what he thinks they mean. Are you sure that, without some training on the formalisms of the system (which Sharon obviously had!), you want John Doe to delete something from the system? He might try to unplug the harddrive, maybe that's what he thinks "deleting" means.
Yes, it's easier to teach John Doe to use a limited UI instead of, say, teaching him SQL. But he'll be able to do less complex stuff with just the UI. (And the fact SQL has some English-sounding keywords is helpful, but SQL is an extremely formal system with few parallels to natural language).
> you want John Doe to delete something from the system? He might try to unplug the harddrive, maybe that's what he thinks "deleting" means.
Highly unlikely that someone familiar with the system (even in an informal way) would do this, for the same reason that you have no trouble understanding me when I say "fruit flies like a banana". Is there technically a chance that I mean "all pieces of fruit fly through the air in the same manner that a banana flies through the air"? Sure. But it's so ridiculously low that you simply ignore it and are willing to accept the infinitesimal risk of misunderstanding.
Should all programming or user interface work be done this way? Of course not. I'm just saying it would be a very effective level of abstraction for a great many use cases, in the same way that I don't need formal mathematical notation to write a Python statement to print "hello, world".
Of course, he formalism has to be there once you get down far enough, in the same way that showing Sharon how to do an account credit in the CRUD system means that you are altering neural structures with electric and chemical signals.
However, the person who trains Sharon doesn't need to know exactly what neurons to stimulate in Sharon's brain with exactly what voltage in order to teach her that system - the relatively lofty level of abstraction provided by English works just fine.
I agree with some of what you say. The fruit flies sentence, for example. We humans are decent at disambiguating those, I'll grant you that.
Allow me to add some random thoughts:
- Python's print "hello, world" IS a formal notation. It's just that this particular notation and this particular task are so simple that we can delude ourselves into thinking it's English. But when you move to actual Python scripts, the only ones who believe "it sounds like English" are programmers :) I wouldn't trust my mom to write a Python script, after all.
- Let's go back to our CRUD/office situation example, and allow me to make it a bit more realistic (but still funny):
"Sharon, please print the report."
"Which report?".
"The one I asked you about yesterday."
"Uh, you asked about two reports yesterday. Do you mean the one about fruit flies or about bananas? Or do you want both?"
"Yes."
"Sorry, yes what? I asked you multiple questions!"
"Yes, both reports. I forgot about the other one, but I want it too."
(...)
"Ok, even though I have a terrible headache, I printed your reports. Here they are."
"Oops, sorry Sharon. I didn't mean you had to print them now. Tomorrow would have been fine. Also, please don't get mad, but I didn't want them on my desk. They are actually for Jane on the fifth floor... Didn't I mention that? Also, why did you print them using the expensive printer?"
----
My point is that just doing CRUDs with English is probably fine, but as the complexity of the task approaches that of a general purpose programming language, the level of precision you must use with your language approaches that of a formal system. Which is what programming languages are...
You've hit on an important point here. When we instruct our machines in natural language, they are surely going to have to be able to ask us questions to resolve ambiguities and fill in details we haven't specified.
I don't think EWD's point is that we don't need natural language at all; just that it's not a good way to program a computer. Which I do believe to be true.
We can explain to a human how to fill out a form because the human has probably seen a lot of forms before. Humans make a lot of assumptions that often end up being wrong: but enough of them are correct that they're still useful.
We trust computers to be unimpeachably accurate because we as humans are not. If computers need to make the types of assumptions that humans do, then they lose a good deal of their accuracy (and their usefulness).
Human language is also visually difficult to read. The biggest improvement that symbolic languages (specifically, modern programming languages) make is the use of spacing and symbols to break apart complex processes into sub-sections, loops, etc.
Furthermore, I disagree with your statement that "natural language is a standard we already have and works fine." Language is not static, nor is it standard. Sure, we may have "standard" grammar rules, but even those can vary from region to region and many people don't follow the rules on a day to day basis. It's not a static target, so developing something that could interpret natural language means developing an artificial intelligence capable of taking nuance, context and the like into account.
EWD was simply claiming that such a system applied to general purpose computing would be so complicated as to be wildly impractical.
>> This way you essentially wouldn't need to learn a new set of incantations - just tell the damn thing what you want the damn thing to do, dammit.
I'm going to guess that you've never given a set of requirements to a programmer before. Programmers ARE the human interface to computers, as they are often writing software to specifications created by someone else. Many of the problems arise in the ambiguity of the human-human communication. Another part comes from the lack of specificity combined with different ideas about how to handle unspecified cases. Your idea of what is obvious is not the only one. Some people lack domain knowledge that is assumed in requirements and leads to poor choices where specifications are not complete. In the end, natural language assumes a broad swath of "common sense" that computers do not have yet.
I'll respond to your points, but was the ad-hominem really necessary?
> In the end, natural language assumes a broad swath of "common sense" that computers do not have yet.
Absolutely. I'm not at all saying that we'd have had this last Tuesday if we'd just take our heads out of our asses - I'm saying it's something we should strive toward and not ignore.
> Many of the problems arise in the ambiguity of the human-human communication.
Human-Human communication works, and works well - once again, we do it every single day, all the time.
Do we encounter problems with ambiguity? Sure. But they are by far the exception and not the norm. After all, forms get filled out, Driver's licenses get renewed, complicated Starbucks orders get filled - these common use cases work.
By contrast, have you ever had this fun experience with a terminal program?
> quit
Unknown command: "quit"
> exit
Unknown command: "exit"
> shutdown
Unknown command: "shutdown"
or my favorite:
> quit
Unknown command "quit." If you want to close the program, type "exit."
Simple English statements like these work extremely well in human-human communication and do not work hardly at all in human-computer communication. I'd just like us to get from A to B, that's all.
There is nothing magical about human brains that would make them theoretically impossible to express in software in such a way that we can give a program natural language direction
I think we are still a long way from understanding what really happens inside our brains.
About telling a computer what to do: They don't 'do' anything. They run programs. (Free after Weizenbaum)
> I think we are still a long way from understanding what really happens inside our brains.
Agreed 100% - I'm in no way saying that it's easy or will be done in our lifetime or the next 10 lifetimes - just that it's not impossible because we're not magic and we do it every damn day.
> About telling a computer what to do: They don't 'do' anything. They run programs. (Free after Weizenbaum)
What I want is (to reference an example in another comment) to go to a command line and type "Copy the report to the share" and (if I'm on a linux box) have my computer translate that to "cp /path/to/report.pdf /path/to/share/" without my ever having to know what it's doing behind the scenes.
Whatever categorical bucket someone wants to put that in doesn't matter to me whatsoever - all I'm saying is that's what I want to see, and that's what I think we should work toward.
What'd help get there is, an object store instead of a file system. We continue to hang files on the ceremonial file tree like xmas ornaments and call it an OS feature. But nearly zero real apps are happy with that. Everybody implements an object store inside a file, and keeps all their crap organized in there (email folders; docx files; project databases and on and on).
When will we get an OS that lets me persist my objects, uniquely identify them with a uuid plus arbitrary attributes (print date??? give me a break), migrate and cache them anywhere and sign them for authenticity? That would be a real OS feature.
Sure all that can be cobbled together on one machine with different libraries. But to be an OS feature, I need servers that understand and respect all that. Object browsers that let me create a relation to view pertinent objects. Security managers that limit access to apps with digital authority etc. All on the network.
The biggest show stopper here is, how do you email your objects to some client after you are done with them? Do you use a different representation? If so, why don't you just use the network representation all the time?
It's not a new idea, nobody ever was able to make that kind of storage work.
Strange claim. Network representation is always different than local, don't know what that could mean.
As for making it work, there's no obstacle. Implementation is straightforward. And since any current file system API is trivially implementable on top of it (create a relation using parentDir, filename, {dates}) there should be little integration issue.
This could be a personal shortcoming but I am frequently left clueless what was meant. For low volume interactive situations asking for clarification is fine as long as the domain is simple.
Gathering requirements is generally done in natural language, but it's a very slow error-prone process. Even after sign-off on requirements it's pretty standard for them to be wrong in critical ways. Frankly this is the part of many software development projects that dooms them to failure.
Ignoring the difficulty of actually getting precise natural language, you'll still get to the point where no one can understand the language. If you don't believe me, go read some Kant.
I'd appoligize for the rambling comment with grammatical and spelling mistakes, but they further my point :)
The problem is a bridge between two disciplines. Saying that it should only be built from one side is no better than saying it should only be built from the other.
Indeterminacy of translation is indeed part of the problem. But you're not saying anything new by bringing it up - it's just a jargon term from linguistics to describe a problem a programmer might illustrate with the (buffalo)+ sentence or "(time|fruit) flies like (an arrow|a banana)" example. They already know the core of the problem without needing the whole weight of a linguistics education.
The obvious problem of indeterminacy of translation is why, when computer scientists talk about natural language programming, they do not normally mean natural language processing - even more so in Dijkstra's time, when computers were slower and our NLP algorithms worse.
The core that Dijkstra is getting at here is symbolic reasoning. He's pointing out that natural language is a poor fit for symbolic reasoning, that there's been a history of movement from rhetorical reasoning to symbolic reasoning in mathematics - in fact that mathematics stagnated where rhetorical reasoning persisted.
Even if we solved the translation indeterminacy problem, we would need Strong AI to convert such a high level description into something concrete enough for a computer to do. We propel computing machines using levers made out of abstractions - the higher the tower of abstraction, the longer the lever, and the greater the power. But the problem of programming is not in pushing the lever, it's in building the lever. In a word, it's engineering, not philosophy - it's about how, and not what.
Firstly, of course it's in the realm of all four disciplines. It would require a task so gargantuan as to be on par with J.L. Austin's dream of a formal dictionary, but doable. I just think the math and computer science students are often (as seen in this thread) not as well acquainted with natural language issues than their counterparts, but I'm still not really seeing your point.
Firstly, the indeterminacy of translation is a much, much deeper problem than the buffalo sentence and the time/fruit flies sentences.
The buffalo sentence is interesting in that it is grammatically perfect, and would be easy for anyone to understand following formal rules, but so bizarre that it's confusing at first.
The time/arrow sentence is also not an issue for humans as it's simply the result of two homonyms that happen to be verbs for one definition. They are clever, but not deeply ambiguous, and i seriously doubt they would pose a serious problem.
Second, natural language IS symbolic reasoning. I don't understand how you can justify a claim that it isn't. The term rhetorical reasoning presumes that symbolic reasoning is already happening.
The numbers '4' and '8' and the words 'four' and 'eight' in your example are already abstract symbols. In fact most words in natural languages are symbols/pointers to different things or processes in the human experience.
Of course you can argue that the 4 number, is more abstract than the word, and that the variable x is more abstract, than the 'concrete' number 4 ... even so, you can build arbitrary complex structures with just 1 level of abstraction/indirection.
In this sence, I agree with scoofy: '(usage of) natural language IS symbolic reasoning' indeed.
It's trivial to define a mapping from the symbolic to the rhetorical. The reverse isn't trivial, but even if it were trivial, we'd still prefer the symbolic.
If that were generally true, we wouldn't have bothered to invent mathematical symbolism and syntax. Natural language has any number of pitfalls -- "are you going to sleep or watch TV?" The "or" in that sentence differs in meaning from the formal logical "or" which would suggest doing both at once.
If I want to express the difference between time and space in relativity theory, I might say:
t' = t √(v^2/c^2)
With that equation I have said a lot, referring to the Pythagorean Theorem, orthogonal dimensions, and the constancy of the speed of light. To translate the above into natural language would require many more symbols, as well as the acceptance of much more ambiguity of meaning.
It's uncontroversial to say that, as we get closer to describing nature accurately, we use more equations and fewer words, and not because of an irrational preference for equations.
"If we learned anything from Chomsky, it's that the underlying grammar we are born with is both instinctual, and follows formal rules. To say differently is literally, demonstrably false."
The rejection of this idea is not only not "demonstrably false", it's actually pretty commonplace among linguists. It would be more accurate to say that Chomsky's theory of a universal grammar is demonstrably false.
"the evolutionary nature of natural languages"
One of Chomsky's more widely criticized ideas (and a pretty bizarre one), is that the language instinct could not have arisen by evolution through natural selection.
If i talk about Chomsky's generative grammar, i do not mean his literal first works, in the same way that i wouldn't mean literally Darwin's evolution when citing Darwin. I mean the theory, generalized as "Skinner was wrong, Chomsky was right." This is not up for debate, it's easily provable. I could site dozens of linguists, Pinker immediately comes to mind offhand.
By "the evolutionary nature of natural languages," i do not mean natural language as a product of natural selection. Instead, i mean the constant flux of natural language dialects. The loss of some words, phrases, etc. over time with the adoption of new ones. "Reprise" has been replaced with "remix," "how do you do" becomes "howdy" over time. This isn't exactly controversial.
A philosopher saying that something's not up for debate? I must be dreaming.
Skinner and Chomsky both came up with some ideas about language acquisition that were useful and stimulated subsequent research. They are both quite wrong, in the sense that neither theory withstands the scrutiny of research over the past 50 years in anthropology, psychology, and [computational] linguistics.
Pinker is one of the more prominent critics of Chomsky, who also points out the value of some of his ideas.
In stark contrast, Darwin's theory remains largely intact, with some modifications and additional insights. It's been magnificently confirmed by discoveries in genetics, of which Darwin could have known nothing. Darwin was right and created a successful theory that will live forever, even as it's added to and enhanced. We have nothing like that for a theory of language acquisition, neither from Chomsky, Skinner, nor anyone else, yet. On the whole Chomsky was not more right than Skinner in any ultimately significant way.
Sorry for misapprehending what you were getting at with evolution of language. I think the idea that human language changes over time is not unfamiliar.
> Could we generally agree that language is instinctual and follows formal or formalalizable rules
No, not without some evidence.
----
> First in it's immediate dismissal of any formalism inherent in natural language
That's not what Dijkstra's article is saying.
> the ease at which he dismisses the proposition without any real consideration
Dijkstra provides several paragraphs of clarification. IMHO, these do provide useful context and show the reader why he has the opinion that he does (of course, we may just disagree here -- but that's okay). What do you feel is missing?
> This subject should be under the purview of analytic philosophy and linguistics, not mathematics or computer science.
Why?
> To say differently is literally, demonstrably false.
Why? Can you demonstrate that, or point to a source that does?
> Many people in this thread are talking about the inability of plebes to express what they actually want. This is a fair point, but not a problem with language specifically.
Why not?
> Graduate of analytic philosophy
Possible appeal to authority.
> This is not up for debate
Why not?
> it's easily provable.
Then please prove it, or point to something else that does so.
> I could site dozens of linguists, Pinker immediately comes to mind offhand.
Then please do so, and please be more specific than just giving us "Pinker". The more specific you can be, the more useful the citation is. I (and presumably others here) are not familiar with his work.
Having actually done research in this field, I feel confident in saying that you are wrong about the state of consensus. Here's a decent overview of the ongoing debate (assuming you are aware of what Skinner and Chomsky's theories involve): http://www.simplypsychology.org/language.html
Very interesting stuff. I will say, though, as i responded to just now. If language is instinctual, and has formal rules, or formalizable rules i think my major points above would still stand.
As someone who also has a degree in philosophy (specifically, philosophy of language as it relates to math) analytic philosophy, mathematics and computer science share a lot of common ground. Even the best natural language processing algorithms can only really come up with a probability of the intent of the sentence; this is often not enough for a programming language (which by necessity requires precision to be repeatable).
Nouns themselves can take a number of different meanings (specifically proper nouns and names) depending on context. Communicative languages often don't distinguish between equality and identity; a critical distinction in computer science (i.e. I can truthfully say "I've eaten at same restaurant 3 days in a row" if I ate at 3 different McDonalds locations on consecutive days). These assumptions about identity and equality are not the same from language to language (or even generation to generation, as you discussed). Context is also an issue; we often discuss things in ambiguous contexts which often require clarifying questions from a human. We may have effective communication between humans, but misunderstandings are common. IMO, language is an effective communication tool almost specifically because it is imprecise: we fill in the gaps with our own experiences and it mostly works out.
Overall, I don't think EWD was saying that natural language programming would be impossible; just that the effort required to program in it would likely be more than learning a symbolic programming language. The computer would need to ask so many clarifying questions to reach the level of specificity required for computer science that it would be a very arduous task. Rather than making computer programming more accessible, natural language programming would make it substantially more difficult.
Here, again, i disagree with the weight of your intended counter-factual. Your issues with equality and identity (formally: the frege-russell distinction) i simply disagree with. Your issue here is not equality and identity, but identity and subsumption.
Equality and identity are essentially the same with being verbs. Your sentence is an error of clarity, you'd fool a human in the same way as you'd fool a computer. I believe the ambiguity you are going for is that of "123 Main St is McDonalds" (identity) vs "123 Main St is a McDonalds" (subsumption, also called class-inclusion). Here however, we have the "a" which clarifies that the statement means subsumption. Why? because it would fool humans otherwise, and so we created a rule for clarification.
I certainly think a natural language programming language would need to ask clarity questions via a parser before running a program, but i honestly don't think this is a serious problem.
It would really only be a problem with intentionally ambiguous words and phrases, such as the verb "to hook up" which is intentionally fuzzy enough to allow the speaker to mean one thing, while allowing the speaker to imply something else.
It's been over a decade since I graduated; so forgive me if I don't remember the terminology :) The Frege-Russell distinction is often described with the Julius Caesar example: if I take Julius Caesar and make a perfect, instantaneous atomic copy of him 2 feet away, how do I refer to them? Because it is not really in dispute that they are two separate entities. Are they both Julius Caesar, the man? Or is one Julius Caesar and the other a copy? If you sent them both into a room together and asked them to come out again, how do you determine which one is the copy? This is an admittedly contrived example, but it's relevant because in a computer we can and often do copy objects, change them, then care to distinguish between identity and equality.
Certainly we could come up with linguistic rules to differentiate them, but for the sake of convenience (or maybe because each of us possesses an incomplete knowledge of linguistic rules) we may refer to them as being the same. But this problem becomes much less difficult in a symbolic language, where many languages have defined an identity operator (usually ===) and an equality operator (usually ==).
You're right that we have language rules; but many of these rules are arbitrary and mutable in their own right (and do change over time as your previous comment pointed out). The problem starts to come in that language rules are a lot more complex and subject to multiple different (and potentially correct) interpretations.
I side with EWD on this one: the interpretation of natural language is going to differ from person to person and as such, building a system that can perfectly discern intent is going to require so much context as to be impractical. It's just easier to program a computer using a symbolic language, while building in well understood formal rules to the symbolic languages that cover the vast majority of cases.
It's not that it would be impossible to develop a general purpose compiler capable of interpreting natural language to machine code; merely impractical. Symbolic languages are much better adapted to these tasks; just as natural languages are much better adapted to conveying uncertainty.
Well, the issue you point to here is the flux of language, which is a real problem. There is no "English," we have no academy like they do for French (which is bullshit anyway), and we never will, and it would be impossible. There is just a series of languages each wholly understood only by the speaker, and perhaps people in the immediate culture of the speaker.
Now, this is sort of a problem, but it's not as though we are walking around confused all day. We make it work, we formalize, we come up with a perscriptivist framework, even if we live in a decriptivist world.
We can do this with any issue brought up with being verb "problems." Our Julius Caesar issue is fixed by a simple convention (yes we have conventions in English as we do in formal languages). Getting people to follow the rules is the only problem, and it will eventually fail, but that doesn't mean we won't have a few hundred years of it working, possibly more.
The issue of practicality is an entirely different question. Currently, it's an absurd proposition, that isn't to say however, that it isn't doable. Especially with greater computational power in the future. I think saying it's impractical is a cop out. The amount of energy that goes into learning languages is immense. If we were able to learn one syntax, nearly identical to English, that could convert instructions into readable code, we'd enter a renaissance of programming akin to art after the photograph was invented, or the current renaissance of music we've created with the invention of the synthesizer and sampler. Skill would evaporate, ideas would reign. People would complain that proper rules aren't being followed like they always do, but the amount of programs produced would expand so far that the cream would rise to the top and the world would be a better place.
I guess if I had to boil the problem down to a thought, it would be this: the effort required to build a system capable of interpreting the nuance of language would be as much or more than building a system capable of generating and implementing its own ideas. Once you have a sufficiently powerful AI, you don't even need to tell it to do anything; it should just do it based off sensor data.
If, for security reasons, you wanted to shackle an AI from making and acting on its own choices, you would need to shackle its ability to interpret language as well because they are the same thing. You have to make choices about implied intent when interpreting language; and those choices. You can't just restrict a machine to making choices on linguistic interpretations if those interpretations then lead directly to action (in the case of natural language programming).
We can (and have) created sets of natural language interpreters for specific situations: Siri is a good example of that. But by and large these are hacks that flag specific situations (such as creating a reminder or opening an app) and pick out the relevant phrases and plug data into fields.
The ideas that I, as a programmer in the traditional sense, want to communicate to computers are not the ideas I want to communicate to humans.
I might ask my friend to move the report he's working on to a shared network location so I can load it into my computer and read it: "Hey Joe, can you move the report to the share?"
Joe might ask the computer to do the same thing: "cp /home/joe/reports/cool_report.pdf /network/share/reports/cool_report.pdf"
The actual ideas that are communicated are very similar, but not the same. English is good for communicating one idea while bash/GNU is good for communicating the other.
Just because English has some established formalism doesn't mean it's good at communicating the ideas we want to communicate to computers.
BTW, I don't care which field you put the issue under; it's the same issue and anyone who cares about it might contribute to the discussion.
you very solidly supported the argument you are against.
"Hey Joe, can you move the report to the share?"
is a great way to communicate something you want done. it doesnt matter if its to a computer, a person, or a dog. If it can't operate on those bounds then its not sophisticated enough to actually meet the needs of the user. One day computers will get there, they haven't done so not because its a 'bad way to talk to a computer' but because computers have not yet become that sophisticated.
Sorry, but this is a completely shocking article to me. First in it's immediate dismissal of any formalism inherent in natural language, but also with the ease at which he dismisses the proposition without any real consideration.
If we learned anything from Chomsky, it's that the underlying grammar we are born with is both instinctual, and follows formal rules. To say differently is literally, demonstrably false. Irregular verbs, for example, aren't learned in the traditional sense, one must actually unlearn the formal rules. Any child that tells you she "swimmed" all afternoon is using a more formal version of English than you do.
The idea of a natural language programming language is flawed, but not by formalism. It's flawed by the evolutionary nature of natural languages. That is, the very people that he states "are no longer able to use their native tongue effectively," are probably using a new dialect that shares a common ancestor with his more "traditional" usage.
Many people in this thread are talking about the inability of plebes to express what they actually want. This is a fair point, but not a problem with language specifically. Communication tools would need to be employed by a computer in the same way as humans use them. E.g., a simple ambiguity checker could work wonders here, as it does between humans when someone you are talking to simply says, "What did you mean when you said you 'realized you forgot your phone at the train station'? Did you forget at the train station, or realize at the train station?".
What IS a problem, however, is Quine's indeterminacy of translation. That could pose serious hurdles that may be insurmountable, however, we still have effective communication between humans, so it's simple to see how this may only be a theoretical problem, rather than a formal one.
This subject should be under the purview of analytic philosophy and linguistics, not mathematics or computer science.