Those games were pretty awesome, and they had some of the same problems mentioned in this thread... If you say kiss frog, it says that's corny... It's just a limitation of getting non-programmers to enter commands.
This is a different situation from Plain English programming. With a text adventure game, the user and the programmer are two different (and usually unrelated) people. A Plain English programmer not only writes Plain English code, but he extends the language, in his own way, as he programs: every type, variable, and routine he defines adds to the vocabulary and grammar of his system. In short, he's not "working in the dark" as the player of a game is; he's both outside
and inside the system.
One could argue that the graphical user interface is the future of unskilled programming and automation.
There are obvious limits to what can be done with point-and-click programming interfaces. The fact remains that some things are best done with words, some with formulas, some with pictures, etc; no single approach can satisfy all needs, even for the uninitiated.
Our goal is to produce a
hybrid system where the proper tool for each job can be used: a system where the beginner (with limited finesse) and the professional (with, hopefully, much finesse) can communicate with their machines simply and naturally. With both groups -- and everyone in between -- using essentially the same tools (as children write short English sentences, and calculate with elementary formulas, and draw simple diagrams, while adults write longer sentences, and work with more sophisticated formulas, and produce more intricate drawings).
Am I saying that Outlook and Excel are forms of programming? Yes, I am. It's just a very high level form of programming. Very simplified, yet very powerful.
Agreed.
Coding with graphical software is the future as well. Look at Visual Studio. You type "string." and a menu pops up as soon as you hit that period.
This sort of thing appeals to some and not to others. The coder who is just learning or who is using an unfamiliar facility typically appreciates the help; while the coder who knows what he wants to say typically finds the prompts and pop-ups and color changes nothing but distracting. Different strokes for different folks.
That menu is doing what the OP is trying to do. It's making programming easier.
Yes, our goals are the same. But our methods differ. Instead of helping the programmer with an unfamiliar syntax, we're trying to eliminate the unfamiliar altogether. Instead of assisting the programmer with a system that is too large to master, we're trying to keep the system small enough so it
can be mastered (at least in its essential points and properties).
Instead of me telling the computer what to do in English, how about the computer uses English to tell me what I can do.
How about both? That's the idea we're developing in the interactive version of Plain English. You essentially code one sentence at a time, "coming to agreement" with the compiler, so to speak, and "chatting about alternatives and resolving ambiguities", as you go along.
I'm always saying that I think Perl is an easy language, but that's only true in Notepad++. Scalars are orange, arrays are pink, hashes are a light color I can't describe, keywords are blue, comments are green... It's a lot easier to see what's going on when it's color coded. Pasting the exact same script into regular notepad makes the code virtually unreadable. It feels difficult when it's all the same color.
Too much of a circus in our way of thinking; when everything is highlighted, nothing is highlighted. And generally unnecessary in a natural language. Think about it: authors write and ordinary people read millions of pages of black-on-white text every day, on every imaginable subject, with no trouble at all. There must be something wrong, at bottom, with a language that requires such a plethora of color-coding to make it accessible.
Unlike making a new language, helping visualize things will never go out of style.
The project that led up to our Plain English project was an attempt to create a better programming language in a more traditional style simply by retaining the best features of an existing language while removing the objectionable ones. And we were able to improve on many such languages. The problem was that the resulting language was always, to a great extent,
arbitrary. That's why we switched to English (which is also arbitrary, of course, but arbitrary in a widely-accepted way). A syntax that "will never go out of style".
Think of the first person to indent things. That was a huge step forward, it applied to all languages, and it will still be important 10 or 20 years from now.
Sure. But keep in mind that people were indenting their paragraphs centuries before computers were even imagined.
Anyway, I think the OP should work on the presentation of language rather than the language itself.
I'm not sure what you mean by that. Our integrated development environment already "presents" the language in a context that reflects a broad range of our beliefs regarding what makes programming easier for both beginner and expert. Have you tried it?
It seems like programmers always have nice grammar. Look at that use of a comma and semicolon. The comma is used to separate a condition from the rest of the clause. A semicolon is used to start a new clause related to the same topic.
In some languages, yes; But programmers "have nice grammar" in such cases because it's required of them: their programs won't run if they don't toe the line.
The people who would have trouble writing in C# due to syntax are the same people who would have trouble writing English.
I don't think that's true. I'm pretty sure there are many accomplished novelists who would abhor C#. And plenty of mathematically-minded C# programmers who couldn't write a decent short story if their lives depended on it. But it's a moot point. Languages that are effective will survive; languages that are not will fall into disuse and will eventually be forgotten. Not too many people use Roman numerals any more...