Natural Language Programming

[smackababy]

On the contrary, with a well-developed Plain English library the programmer doesn't have to remember anything -- he'd simply expresses a thought as it naturally occurs to him, and it compiles. "Clear the screen" or "Erase the screen", it doesn't matter -- since the same thought is being expressed.

Sure, they are the same thought, but your compiler is going to have to understand every abstract concept of the human language to get those ideas across. And, those change drastically over time. A compiler will have to understand "clear", "erase", "expunge", "annul", "blank", "wipe out", "white wash", etc. Otherwise, we're back to using reserve words. This will need to be verbose enough to actually understand human thought.

And, that doesn't even get into the complicate algorithms and implementations of things. Unless you're going to code for every connecting to every type of database, the command "connect to DB2 (or whatever) database" is never going to work.

 

[Gerry Rzeppa]

What are you using to extract the intention from unstructured language? In my current project at work I have implemented coarse geocoding (finding places in raw text) using the Stanford NLP model as well as Open NLP. Are you using a similar approach?

Not at all. Our approach is based on simple "recognition" and "matching" rather than detailed grammatical and semantic analysis. At the risk of sounding facetious, it is an extension of some real-world research performed and documented by Gary Larson:

To be more specific. When we say to a dog, "Want to play fetch with the ball?", we believe the dog responds appropriately, not because he grammatically analyzes the whole sentence and derives its semantic intent from that analysis, but simply because he recognizes a couple of the words and is able to match them with things already in his head. So he hears, "blah blah blah FETCH blah blah BALL" and matches the two words he recognizes with his mental image of a generic ball (similar to a "type definition" in a program), and perhaps his mental image of a particular ball (similar to a program "variable"), and his method for fetching ball-like things (similar to a "routine" in a program). In Plain English:

A ball is a thing with... [this defines "ball" as a type]

The red ball is a ball. [this defines "red ball" as a variable of type "ball"]

To fetch a ball: [this is a routine header with an unclassified word ("fetch") and a type ("ball")]

And that's the stuff in the "compiler's head" after its done "learning" about the programmer's world.

Now consider what happens when the compiler comes across an imperative sentence like this in the body of a routine:

Fetch the red ball.

Parsing from left to right, the compiler collects everything up to the article ("the") and, since what it has found is not a variable, assumes that is just part of a routine name (we call it a "monikette" -- part of a routine's "moniker" or "name"). Then it throws away the article and sucks up the rest of the sentence, which turns out to be a variable of type "ball". Then it concatenates the monikette with the type name and goes looking through the headers compiled earlier for an appropriate routine to call. When it finds one, as in this case, it generates the code to make the call; if it doesn't find a match, it says something like, "I don't know how to 'fetch a ball' " and the programmer then makes the necessary corrections and/or additions to his code.

The beauty of this approach is that the vocabulary of a program, and indeed, much of the grammar, is defined, not by the compiler, but by the programmer himself as he develops his system. The compiler is only interested in a handful of English "separator words" -- articles, prepositions, conjunctions, and various forms of the verb "be".

Now I realize this approach sounds both simplistic and sloppy; but the fact is, it works. And not just for dogs and small children. Using little more than what I've just described, we were able to write an entire development system (with a unique interface, a simplified file manager, an elegant text editor, a hexadecimal dumper, a native-code-generating compiler/linker, and a wysiwyg page-layout facility for documentation), in Plain English, both conveniently and efficiently.

So three cheers for Gary Larson! We wouldn't be where we are today without him.

 

[Crusty]

Your IDE is nothing more than a toy in my opinion.

Have you produced any programs that run outside of your IDE? Like perhaps a standalone HTTP server or a picture browser?

Something I can download, open up and use without running your IDE.

I imagine something like this, at least according your theory, should compile to a functioning web server right?

When I get a request for a resource serve the results to the client.

 

[Gerry Rzeppa]

Sure, they are the same thought, but your compiler is going to have to understand every abstract concept of the human language to get those ideas across. And, those change drastically over time. A compiler will have to understand "clear", "erase", "expunge", "annul", "blank", "wipe out", "white wash", etc. Otherwise, we're back to using reserve words. This will need to be verbose enough to actually understand human thought.

And, that doesn't even get into the complicate algorithms and implementations of things. Unless you're going to code for every connecting to every type of database, the command "connect to DB2 (or whatever) database" is never going to work.

See my post just above for how our compiler actually works. The vocabulary and grammar of a Plain English program is defined, for the most part, by the programmer(s) who are developing a program -- with as much specificity or variation as they desire. When teaching children to program, for example, we include all sorts of synonyms in our Plain English libraries so the kids are more-or-less guaranteed of success their first time out; in professional programming collaborations, on the other hand, we tend to all use the same words and phrases and the vocabulary of programs thus developed tend to be smaller (though the programs themselves are larger).

It is expected that, as with natural languages, different dialects will develop in different sub-cultures (programming groups or teams). But, as with natural languages, the code will still be intelligible to all English-speakers. I may have a different vocabulary and accent than people from Boston or Alabama or the Left Coast -- but I can still make out what they're saying. And, if I move to different place, it's not a big deal to pick up the local modes of expression. Plain English, like all natural languages, is a "living language". It is easily understood but not precisely (or permanently) defined in any one place.

 

[Gerry Rzeppa]

Your IDE is nothing more than a toy in my opinion. Have you produced any programs that run outside of your IDE? Like perhaps a standalone HTTP server or a picture browser? Something I can download, open up and use without running your IDE.

The sample program on our site (www.osmosian.com) is such a thing. The zip file includes both the source code and the stand-alone Windows executable. We call it the "Cal Monet".

The program clears the screen and lets you type the name of pretty much anything you can imagine in the lower left corner. When you hit enter, it paints a picture -- in the dab, dab, dab style of Claude Monet -- in the center of the screen. And you can use the PAGE UP and PAGE DOWN keys to get additional renderings of the same subject. The ESCAPE key clears the entry field. Click the word "Print" in the lower right of the screen to print a painting to hang on your wall; click "Quit" to get out. Here's the Cal Monet in action, after I asked it to paint "a bowl of fruit":

The program does what it does by connecting to the internet, querying Google for images, and then modifying those images to create the paintings. The Plain English code for contacting Google and producing the paintings looks like this:

Put "http://images.google.com/images?q=" into a URL.
Convert the text's string to a query string. [this is what the user typed in]
Append the query string to the URL.
Read the URL into a buffer.
If the i/o error is not blank, show the i/o error in the status; exit.
Create the works given the buffer.

A complete, step-by-step description of how to recreate the program, in Plain English, can be found in our instruction manual:

www.osmosian.com/instructions.pdf

It also appears that you're missing the forest for the trees. Our IDE itself is a stand-alone program, created with an earlier version of the same program. It can be used to produce any kind of program, including "C" compilers and HTTP servers, etc.

 

[Markbnj]

Not at all. Our approach is based on simple "recognition" and "matching" rather than detailed grammatical and semantic analysis. At the risk of sounding facetious, it is an extension of some real-world research performed and documented by Gary Larson:
[... snip for humanity ...]

You could have shortened that whole thing to "No, we found that NLP was overkill and opted for a dictionary lookup on keywords." You're talking to working engineers here, for the most part. We don't need parables to enable us to get your insights, and when you try to make a dictionary lookup sound revolutionary by quoting a Gary Larson cartoon... well that's just silly and a little offensive.

 

[Markbnj]

Your IDE is nothing more than a toy in my opinion.

Have you produced any programs that run outside of your IDE? Like perhaps a standalone HTTP server or a picture browser?

Something I can download, open up and use without running your IDE.

I imagine something like this, at least according your theory, should compile to a functioning web server right?

Lol. Are you familiar with my new security program?

"When someone asks for something they shouldn't have don't give it to them."

 

[Gerry Rzeppa]

You could have shortened that whole thing to "No, we found that NLP was overkill and opted for a dictionary lookup on keywords."

We're not just saying that NLP is overkill for our particular application; we're saying that it's the wrong approach to the subject altogether.

You're talking to working engineers here, for the most part.

I'm not sure that's true, based on the threads I've seen and the replies given. Many posters here seem to be beginners and students and programmers with specialized (and thus limited) expertise. Not all, of course. But many.

We don't need parables to enable us to get your insights...

But perhaps you do, since you missed the one that I had to clarify at the top of this post! Perhaps this fabulous fable will help: "One day Henry Ford asked one of his engineers how much an oddly-shaped gas tank would hold. While the engineer was feverously calculating, Henry filled the thing with water and poured it into a large graduated cylinder. Then he fired the engineer."

...and when you try to make a dictionary lookup sound revolutionary by quoting a Gary Larson cartoon...

The "revolutionary" thing is finding insights into natural language processing in a cartoon -- who (but an Osmosian) would think to look there? But the really interesting thing is that the insight gained from that cartoon actually panned out into a practical and efficient compiler. I bet Gary Larson never imagined that happening!

...well that's just silly...

As Willy Wonka once sang, "A little nonsense, now and then, is cherished by the wisest men."

...and a little offensive.

I'm not here to offend. Encourage, yes. Inspire, yes. To encourage engineers (and everyone else) to "become as little children" and see things though their wide-open and wondering eyes. To encourage people to think outside the box. To inspire people to seek out simpler and better solutions to problems based on the Osmosian maxim, "If it's hard, it's wrong." But offend? God forbid!

 

[MagnusTheBrewer]

First rule of proselytizing: never use one word where four or five will do.

 

[Spungo]

To be more specific. When we say to a dog, "Want to play fetch with the ball?", we believe the dog responds appropriately, not because he grammatically analyzes the whole sentence and derives its semantic intent from that analysis, but simply because he recognizes a couple of the words and is able to match them with things already in his head.

:thumbsup:
Humans are the same way. This is why you're never supposed to tell people bad ideas. All they remember is the idea. They don't remember you saying it was bad.

The C# book I've been reading makes this mistake repeatedly. It will show a concept. In the next chapter, it says don't do that. Do it this other way instead. Do they think I'm going to remember which way was the correct way and which way was the incorrect way? All I remember is that both methods worked, so both methods seem equally valid. I might write a ton of crap code without realizing it.
A good book should only say what the correct way is. People should be unaware of bad programming practices. Bad programming should stand out. It should look unfamiliar.


Anyway, I find Perl much easier to understand than a language like VB. Perl is a bit more girly. It's a visual language. It's more like painting a picture.
$ is scalar
@ is array
% is hash table
= is the assignment operator
== means equal to (as number)
eq means equal to (as string)
<> is called a diamond operator
<=> spaceship operator for sorting numbers
cmp is like the spaceship but it's for strings instead of numbers
() usually means something is a function
{ } means the code is grouped together
/ / usually means regular expression

I like looking at something and having a sense of what is going on without actually reading any of the words.

Put "http://images.google.com/images?q=" into a URL.
Convert the text's string to a query string. [this is what the user typed in]
Append the query string to the URL.
Read the URL into a buffer.
If the i/o error is not blank, show the i/o error in the status; exit.
Create the works given the buffer.

How I would see that code:

words words words words words more words words number
words number bracket squiggly line words words words
words words words words

I always found math to be easier than English. It's a lot more visual. Things can be expanded or factored to change their appearance. Things can be moved from the right side to the left side of the equation. You can take one look at a function and have a rough idea of what it's saying.
Y = X^2 - 5
Without doing any calculations, I can tell you this graph looks like a U, it's symmetrical around X = 0, and the bottom of the U is at Y = 5. Look how many words it took to describe this thing. Maybe I have ADD or something, but I have a hard time with words. I like numbers and charts.

 

[Gerry Rzeppa]

I always found math to be easier than English. It's a lot more visual... Y = X^2 - 5... Without doing any calculations, I can tell you this graph looks like a U, it's symmetrical around X = 0, and the bottom of the U is at Y = 5. Look how many words it took to describe this thing.... I like numbers and charts.

We fully agree that some people find it easier to think in words, some in formulas, some in pictures, etc. And that certain kinds of ideas are better expressed in one way rather than another, regardless of who is doing the expressing. That's why we're proposing a Hybrid Programming Language as the next logical step beyond our Plain English prototype. See here:

https://www.indiegogo.com/projects/the-hybrid-programming-language/x/8950932

Note how your post above (the whole thing) naturally took on the form we describe in our Hybrid Programming project (without a picture -- but I strongly suspect you would have stuck a illustrative graph in there if it had been easy to do so). We all naturally communicate our thoughts in this way: a natural language framework with snippets of other stuff where the other stuff does a better job. Every post on this forum is an example.

 

[Markbnj]

The "revolutionary" thing is finding insights into natural language processing in a cartoon

I don't get why you think that was an insight. Humor is often funny because it presents truth in a different way. Everyone already knows that is how dogs interpret human speech. That's why it was funny. Everyone also already knows that you can use dictionary lookups to find actionable terms in free text. Not insightful. I read a paper recently on doing just that to extract data from handwritten doctor's notes. Everyone also knows that the bulk of text and speech is not relevant to the subject of the text or speech. Again... not insightful.

Your claims are contradictory. You can't possibly enable the full vision of the "plain english" paradigm that you are trying to sell based on dictionary searches for term matches. It's impossible that you don't already know that. There are far too many permutations of directives and labels. I'm not debating this with you. It's not debatable. And so the only other possibility, and I am having serious and not altogether pleasant deja vu right about now, is that your "plain english" means "that subset of terms we've taught our system about."

Adventure game parsers have been able to do what you're describing since the 1980's. If you're going to claim to enable "plain english" programming then you need to demonstrate how a user can instruct your system to do something useful by assembling a series of commands in natural english text, without any preconditions on which words are acceptable and which are not. Any other definition is not "plain english programming." It's "programming in osmossian" or whatever it's called.

If you're prepared to demonstrate that ability for anything less trivial than printing text on the screen I'll be the first to acknowledge your success. I would accept some small task as a goal, say, moving and renaming a directory full of files, or opening a spreadsheet and adding a row with some specific data. Show me a system that can do one of those things, or another of similar complexity, in reaction to any English language input that an outside observer would agree describes the task fully. Then I will be impressed. It still won't be a useful software development environment - these are toy tasks 1/1000 the complexity of a real application - but it would be impressive.

 

[Gerry Rzeppa]

I don't get why you thing that was an insight..."

The insight wasn't that dogs process language that way; as you say, we all suspected that. The insight was that we should approach the problem from that direction, instead of the way most others were attacking it.

You can't possibly enable the full vision of the "plain english" paradigm that you are trying to sell based on dictionary searches for term matches. It's impossible that you don't already know that.

Actually, I don't know that. In fact, it is our belief that most language processing in humans, most of the time, is done on a pattern-matching basis. Imperative sentences, we believe, are processed much as I've described above. Declarative sentences are simply broken up into WHO, WHAT, WHEN, WHERE, WHY, and HOW pieces and handled accordingly. Expletives readily fall into one of three mental buckets based on intensity. Etc.

We really don't believe natural language processing is the complicated affair that professional linguists make it out to be. We believe that it looks hard when studied that way for the same reason the motion of the planets is difficult to map out if you assume the earth is standing still -- that's the wrong perspective on the thing.

When I looked into robotics a while ago, I found that the field quickly divided itself into two camps: (1) those who thought, for example, that a robot should calculate its route from A to B (using lots of esoteric math) and attempt to follow that calculated route; and (2) those who thought, "Well, let's just take a step toward B and see if we run into anything; if we do, we'll move over a little and try again." Linguistically, you appear to be in the former camp; we're with the seat-of-the-pants-folks in the latter camp. No doubt the truth is somewhere in between; but we suspect it's closer to our camp, and that we'll find it sooner starting at this end.

Take a close look at a working voice recognition system like Dragon Naturally Speaking -- or any other practical natural language system like Apple's SIRI or Amazon's ECHO -- and you'll see that the parts that work best are essentially pattern-matchers with lots of "brute force" ad hoc code for the myriad exception cases that inevitably occur. The same is true for programs that translate one language into another. Natural languages are ad hoc things to begin with, and that's why they require ad hoc code to process them.

Adventure game parsers have been able to do what you're describing since the 1980's.

Indeed. And it is our belief that had research since the 1980's continued along those very practical lines -- instead of being sidetracked into abstract and esoteric dreams of having computers actually (and almost magically) "understand" what we're saying -- we'd be much further along today. (Nelson's INFORM being an obvious and welcome exception). Osmosians are proponents of Apparent Intelligence, not Artificial Intelligence. I don't care if my computer "understands me" -- that's my wife's job. I just want it to do what I tell it to do. In English.

 

[Cogman]

Take a close look at a working voice recognition system like Dragon Naturally Speaking -- or any other practical natural language system like Apple's SIRI or Amazon's ECHO -- and you'll see that the parts that work best are essentially pattern-matchers with lots of "brute force" ad hoc code for the myriad exception cases that inevitably occur. The same is true for programs that translate one language into another. Natural languages are ad hoc things to begin with, and that's why they require ad hoc code to process them.

Bad, bad examples of what point you are trying to make.

First. Most voice recognition software works because it limits what it is looking for, pretty strictly. So Siri, echo, and Dragon Naturally Speaking, as much as possible, try to take the context into account and even go so far as trying to limit what can be recognized to limit the search space to something reasonable.

Next, All of these pieces of software are NOT brute forcing things. They are using loads, upon loads, upon loads, upon loads of heuristics, prediction, etc to try and determine what the user probably said (maybe). Half the reason they work at all is because they are doing a lot of deductions like "Hey, I just heard 'The brick .ro... ox humped o.. the hazy frog' But that makes no sense, they probably meant 'The quick brown fox jumped over the lazy dog'". These deductions are based totally on word usage frequency and looking at usage patterns of users of their software. They are NOT being done by the software actually understanding what the user is saying.

Finally, when they actually take commands, they have a limited set of non-turing complete instructions that they will do (Search for 'x'. Raise volume 'y'). And a limited set of aliases that the user is allowed to do in order to get an action done. Google AFAIK does the best job of translating what is said into an action, but that is because they have spent billions upon billions just doing that with their search engine (It is why their search engine works so well). If it were an easy process, there would be hundreds of products out there just like google. But there are few and the few that are comparable are backed by multi-billion dollar companies.

You are naive at best to what these companies are doing. It certainly isn't as simple a process as you are making it out to be.

 

[werepossum]

I can't believe only three other people voted yes. An idea doesn't have to be THE future of programming to be a good idea.

I suspect this is the wrong place to sell something like this. Most of the people here are either programmers or software engineers; they KNOW the language and the syntax, and thus this represents no advantage to them. On the contrary, natural language programming would be a hindrance, for lacking the structure of an artificial language the programmer would have to impose structure.

Where I think this could shine is for the non-programmer who still has to write the occasional program, who doesn't have the language and syntax memorized, but who can probably describe what she wants reasonably clearly. It also obviously could be very useful in teaching beginning programming, as students would not have to concentrate on first learning a new language and grammar to learn concepts. It could also be very useful with quadriplegics or others with limited fine motor control who must use voice control. Describing what one wants surely should be immensely easier than formatting orally.

 

[Gerry Rzeppa]

Bad, bad examples of what point you are trying to make. First. Most voice recognition software works because it limits what it is looking for, pretty strictly.

No, good examples. We limit ourselves to the application programmer's "world" by having the programmer define his own types, variables, and routines (and thus the vocabulary and grammar of his "locale").

So Siri, echo, and Dragon Naturally Speaking, as much as possible, try to take the context into account and even go so far as trying to limit what can be recognized to limit the search space to something reasonable.

Ditto.

Next, All of these pieces of software are NOT brute forcing things. They are using loads, upon loads, upon loads, upon loads of heuristics, prediction, etc to try and determine what the user probably said (maybe).

Agreed about the loads of heuristics, prediction, etc. But most of that, at bottom, is "brute force" stuff like searching for particular phrases in a list of well known and well understood phrases, etc.

Half the reason they work at all is because they are doing a lot of deductions like "Hey, I just heard 'The brick .ro... ox humped o.. the hazy frog' But that makes no sense, they probably meant 'The quick brown fox jumped over the lazy dog'".

Ditto again. Pattern matching (not grammatical parsing) against known possibilities. In our compiler, for example, we know that a we need to match each imperative sentence with an appropriate routine; the search space is thus limited to the routines that have been defined by the programmer.

These deductions are based totally on word usage frequency and looking at usage patterns of users of their software. They are NOT being done by the software actually understanding what the user is saying.

Agreed. Same for us regarding "usage patterns" as defined by the programmer's library of routines, common uses of prepositions, etc.

Finally, when they actually take commands, they have a limited set of non-turing complete instructions that they will do (Search for 'x'. Raise volume 'y'). And a limited set of aliases that the user is allowed to do in order to get an action done.

Again, same for us. I think you misunderstood somewhere what we're actually trying to do, and what I've said about it. My point in the immediate context is that natural language processing that works is of the type you describe here (and that we also do in our compiler).

Google AFAIK does the best job of translating what is said into an action, but that is because they have spent billions upon billions just doing that with their search engine (It is why their search engine works so well).

Again, agreed. But what they've learned from their search engine is that there isn't a "theory of everything" when it comes to language parsing; Chomsky looked for years for such a thing and couldn't even get close. It's just one special case after another processed by one ad hoc routine after another; and each relatively simple when considered on it's own. So the best we can do is limit our scope (as we do in real life) and work with our user (programmer) to "learn" one another's dialect, idioms, expressions, etc.

If it were an easy process, there would be hundreds of products out there just like google. But there are few and the few that are comparable are backed by multi-billion dollar companies.

I think Google's dominance is more of a historical thing than a technological one. First to reach the tipping point, biggest in the end. You have to hand it to the Google guys for pushing the boundaries, though.

You are naive at best to what these companies are doing. It certainly isn't as simple a process as you are making it out to be.

Ah, but I believe it is simple, wherever it works and works well. It's the convoluted stuff that is quirky and unreliable and always way bigger than it needs to be.

 

[Gerry Rzeppa]

I can't believe only three other people voted yes. An idea doesn't have to be THE future of programming to be a good idea.

Thanks.

I suspect this is the wrong place to sell something like this. Most of the people here are either programmers or software engineers; they KNOW the language and the syntax, and thus this represents no advantage to them. On the contrary, natural language programming would be a hindrance, for lacking the structure of an artificial language the programmer would have to impose structure.

Agreed. We thought we'd test our mettle with the pros, first, and then move on to our primary audience: kids, especially kids who have not yet learned a lot of bad habits. Or different habits. Or any habits at all, for that matter.

Where I think this could shine is for the non-programmer who still has to write the occasional program, who doesn't have the language and syntax memorized, but who can probably describe what she wants reasonably clearly.

I find it works well for even myself in that context. Sometimes I get on a non-programming project for six months or a year and I really appreciate, then, how easy it is to "get back into" Plain English programming.

It also obviously could be very useful in teaching beginning programming, as students would not have to concentrate on first learning a new language and grammar to learn concepts.

Exactly.

It could also be very useful with quadriplegics or others with limited fine motor control who must use voice control. Describing what one wants surely should be immensely easier than formatting orally.

I like that idea. We did a lot of work with quads back in the day using on-screen predictive keyboards and mouth-manipulated joysticks, etc, with a good degree of success. We found, however, that a lot of non-congenital quads are not interested in programming -- many were athletes (or at least athletic) before their injuries and are more naturally inclined to less tedious enterprises. But now that you've brought it up, I'm going to take another serious look at that community. Voice recognition plus Plain English may turn out to be a winning combination whose time has come.

 

[Spungo]

I finally remembered why this argument seemed so familiar. Back in 1967-68 I play tested a logic game with some students at the University of Michigan called WFF - N - Proof. It's based on "Well Formed Formulas " and each legitimate WFF can be constructed and deconstructed following specific rules and is an excellent tool for learning how computers process and compile code (notice I didn't use "learn "). Now, there are many ways to reach the same result but, each "Proof " is dependent on the logic of the particular formula. In other words, you can not use the same proof to show 2+2=4 and 2^2=4, they are separate Formulas eve though the result is the same.

This somewhat lengthy preamble brings me to a popular pastime then which was applying the game rules to political speeches, notably LBJ 's. They most often came up semantically null but, pointed out a huge Flaw in dealing with the English language using logical constructs. They do not handle quantifiers or logical connectors without being specifically defined. In other words, it's easy to say, I want to go to the store. However, it requires a specific definition to say, I want to go to the store but, my mother won't let me. Now take the short leap back to my number equation example and think of the number of English phrases resulting in me not going to the store.

You guys must have been really stoned to come up with this game.

I have nothing against the OP or the idea of English programming. I just think it's a weird language to use. You can ask any immigrant and they will tell you English is a brutal language to learn. In a word, it's a terrible language. The spelling of words seems random. English includes lots of words and phrases from other languages. At least half of the words in any given sentence can be removed without changing the meaning of the sentence. Punctuation radically changes the meaning of a sentence.

What's worse is that most people writing and speaking English don't understand English.

What's interesting is how stereotypes play out and why. Asian people and computers. What's up with that? Languages like Chinese and Japanese don't use a lot of filler words.
English: "where do we go now?"
Chinese: "where do we go now?"
Computer: where.go(); //things like who and when would be optional arguments

In a lot of ways, programming languages try to incorporate familiar English style. Just like English, there are many ways to say the same thing. All of these are acceptable in Perl:

1):
print "this is a string" or die;     //English for emo kids

2):
die unless print "this is a string";    //drunk person grammar?

3):
unless (print "this is a string") { die; }    //sounds like apposition in English

4):
if (not print "this is a string") { die; }   //ye olde English

My style of writing English is closest to #3. apposition.
Sentence starts with condition, a comma separates the condition from everything else, and then say everything else. You'll find that the US constitution is written like this as well. Lots of commas, lots of condition statements. It's almost like the constitution was written in C or Perl. This is what wiki says the first amendment is:

Congress shall make no law respecting an establishment of religion, 
or prohibiting the free exercise thereof; 
or abridging the freedom of speech, 
or of the press; 
or the right of the people peaceably to assemble, 
and to petition the Government for a redress of grievances.

If you're really bad with English, the first amendment looks like nonsense. Why are things separated by semicolons? Why are coordinating conjunctions used with semicolons instead of commas? What's the difference? It might be easier to understand when written in pseudocode since most people don't really understand English. Forget the class-function type of syntax and just look at the grouping of things. Look at the indentation:

congress {
   shall make no law {
      religion {
         (respecting an establishment of) || (prohibiting the free exercise of);
      } 
      abridging the freedom of {
         (speech) || (the press);
      }
      the right of the people peaceably to {
         (assemble) && (petition the government for a redress of grievances)
      }

   } //shall make no law
} //congress

Instead of getting people to program in English, we should probably teach people how to program in C++ so they write better English.
Legal documents are actually quite easy to understand once you know the basic syntax and structure of English. A single sentence that is a paragraph long can be broken down into segments based on the punctuation. it almost reads like a class definition. People often get screwed up by the commas because they don't understand the purpose of commas. They're like putting new lines and indentations in your code:
The receiver of funds (class), upon request (event handler?), for the purpose of establishing credit worthiness (a method?), shall submit a letter of employment (return type), dated after the formal request (condition).

 

[MagnusTheBrewer]

WFF-N-Proof was created by Professor Layman Allen to teach symbolic logic. The problem with using English or any other spoken language as a programming language is it's malleable form. Conditional statements are natural and inherent to our use of language. The OP says this isn't a problem because the individual user can define it however they want. The problem I see is conflicting definitions between different users. Well, you can import definitions (libraries) along with the program but, what happens when you call that program or maybe just use one of it's functions in your own version with different definitions? An overly simplified example might be a function expecting a "to" input but receiving a "too" or, "two" input. Perhaps a better example could be found but, the point remains. You can not use English words as a programming language when different users have different definitions of the same word. That is the entire point of inventing symbolic languages, their definitions and rules of use are the same for everyone and allow portability.

 

[Gerry Rzeppa]

You can not use English words as a programming language when different users have different definitions of the same word.

This problem is not unique to natural language programming.

Imagine we have two friends with the same first name, say, "John". How do we deal with this problem in ordinary conversation? in traditional programming languages? in Plain English?

1. With scoping. In everyday conversation we assume that "John" refers to the closest antecedent with that name. In a traditional programming language this would be akin to assuming a local variable will take precedence over a global variable with the same name. In Plain English, we do the same.

2. With qualification. In everyday conversation, we might use surnames to distinguish, like "John Smith" and "John Adams". In a traditional language this would be like tacking the library name onto the ambiguous name. In Plain English we would do something similar (but with a commonplace syntax).

3. With renaming: We call one of guys "John" and the other "Johnny". In a traditional language this would be actually renaming one of the culprits. Ditto for Plain English.

In the "Apparently Intelligent" interactive version of Plain English currently under development, the system asks the programmer for clarification in such cases. Much as we do with each other in everyday conversation: "Do you mean your brother John, or the guy next door?" And like adventure games have done for decades: "Do you mean open the red door, or the blue door?"

 

[Gerry Rzeppa]

Instead of getting people to program in English, we should probably teach people how to program in C++ so they write better English.

I agree that it would be nice if people spoke and wrote better English -- but I'm not at all sure C++ is the way to go!

In any case, Plain English isn't fussy about spelling and grammar: that's one of the advantages of our "sloppy" parsing and substitution methods.

And while English may be a messy language, it is nevertheless one that millions already know and use everyday. And some of them are already programming in it. When, for example, someone tells her phone to "Remind me about my dentist appointment next Tuesday at 10am," she's writing a little program. In English.

 

[Sequences]

Who is your target audience?

 

[Markbnj]

We really don't believe natural language processing is the complicated affair that professional linguists make it out to be. We believe that it looks hard when studied that way for the same reason the motion of the planets is difficult to map out if you assume the earth is standing still -- that's the wrong perspective on the thing.
[... snip ...]

A couple of points in reply. First, Cogman is right that Dragon Dictation and Siri, etc., are terrible examples, and it makes me wonder whether you really understand the problem you're claiming to solve. In the case of Dragon it has the much simpler task of matching sampled phonemes to a dictionary. There is a lot more to it than that, but the important point is that it doesn't much know or care what the content of the communication is. Siri and other examples of front-end voice command processing handle a very limited set of inputs and map them to a very limited set of outputs. In scope it is a much narrower problem than deducing the set of operations described by any given English statement.

Second, I note that you did not respond to my challenge. So let me restate it more specifically. You've gone well beyond theorizing and claimed in various threads that people should learn to program your way. I've also said to you before that showing beats preaching. So I would like to see a program in plain English to do a task, many orders of magnitude less complex than even a simple application. Assume you have a folder full of randomly named jpeg images. Can you demonstrate a working plain English program that iterates the files, copies them to a new folder, and in the process renames each to a combination of the current date and the sequence number of the file (the order of processing)? Given what you've claimed I would expect that to be possible now, and furthermore I would expect to be able to take your program and alter the language as I see fit, assuming I have not changed the semantics, and be able to observe it running and doing the same thing as your program.

I'm not trying to trap you here. I'd be thrilled to play with this and see it work. The task itself is an example of a very minor and straightforward thing that any application development language can do, and the ability to alter the language and re-run the program is a natural expectation of a "plain English" programming language such as you have described.

 

[MagnusTheBrewer]

This problem is not unique to natural language programming.

Imagine we have two friends with the same first name, say, "John". How do we deal with this problem in ordinary conversation? in traditional programming languages? in Plain English?

1. With scoping. In everyday conversation we assume that "John" refers to the closest antecedent with that name. In a traditional programming language this would be akin to assuming a local variable will take precedence over a global variable with the same name. In Plain English, we do the same.

2. With qualification. In everyday conversation, we might use surnames to distinguish, like "John Smith" and "John Adams". In a traditional language this would be like tacking the library name onto the ambiguous name. In Plain English we would do something similar (but with a commonplace syntax).

3. With renaming: We call one of guys "John" and the other "Johnny". In a traditional language this would be actually renaming one of the culprits. Ditto for Plain English.

In the "Apparently Intelligent" interactive version of Plain English currently under development, the system asks the programmer for clarification in such cases. Much as we do with each other in everyday conversation: "Do you mean your brother John, or the guy next door?" And like adventure games have done for decades: "Do you mean open the red door, or the blue door?"

The examples you gave are simple ones for variables or objects but, don't apply to operators or values being passed. The way I see it, each programmer would have to either redefine the "language" being used and, thus continually reinvent the wheel OR, every term would need a wrapper, quickly making overhead unmanageable. The first would cause a nightmare trying to troubleshoot and the second would make the program so inefficient as to be unusable.

You still have not adequately addressed conditional statements.

 

[Spungo]

And while English may be a messy language, it is nevertheless one that millions already know and use everyday. And some of them are already programming in it. When, for example, someone tells her phone to "Remind me about my dentist appointment next Tuesday at 10am," she's writing a little program. In English.

Is the appointment at 10am or is the reminder at 10am?

Who is your target audience?

I would assume little kids. C-like syntax would be difficult to understand if you didn't know math. It also helps to know physics and chemistry because those use different applications of math.

I remember hating when teachers wrote things like f(x) = x^2 - 3. What is f(x)? Are you saying I should multiply f * x? Am I trying to isolate the f or the x? Then they say it's the same as y = x^2 - 3. Well then why didn't you write it that way? It's because one is an equation and the other is an expression. What's the difference? One equals something and the other doesn't. What?? Why would you write an equal sign if it doesn't equal something? Then they get all crazy with f of g(x) and saying it's not the same as f(g(x)) or g(f(x)). I don't even remember. Then they say things like f at g of x. It starts to look like they're making it up. Who thought it was a good idea to write math stuff like this? I want heads on platters.
The symbols themselves would probably cause a lot of confusion if someone is trying to learn programming without learning math first.

On the flip side, struggling with math syntax while programming might make it easier to learn math in the future. Let's look at that f(x) = x^2 - 3 one more time. It's not an equation, but it looks like an equation? It's a "function," but I don't know what a function is unless the concept was already introduced in some other class. If you've done programming before, it immediately makes sense:

float f(float x) {
   return (x^2 - 3);  //way of writing powers varies between languages
}

How do you use the function defined in that code? you would write f(5) and it would return 22. That's exactly what a question on a math test would ask. "For the function f(x) = x^2 - 3, evaluate for f(5)." The question makes sense even if you skipped every math class covering this topic.


There are always valid reasons for learning one way or another. Some people think in math. Some people think in words. Some people think in music.