OSDev.org

Ethin wrote:Natural language programming seems like overcomplicating easier non-natural language programming tasks. If I'm programming a GUI app, I find it much easier to write (for example):

Code: Select all

global::generateDSPList();
tts::init();
QApplication a(argc, argv);
// ...

And would find it much, much harder (and ridiculous) to write:

Code: Select all

Call the function generateDSPList in the global namespace with no parameters.
Call the function init in the tts namespace with no parameters.
Create a class a of type QApplication, calling the constructor that takes an integer and an array of character pointers and pass it argc and argv.

DavidCooper wrote:What does all that jargon-infested junk mean though?

How would you summarise what it does for someone who doesn't know anything about programming?

Why are you programming at such a low level instead of letting the intelligent compiler do that job for you?

Ethin wrote:

Code: Select all

global::generateDSPList();
tts::init();
QApplication a(argc, argv);
// ...

...

Code: Select all

Call the function generateDSPList in the global namespace with no parameters.
Call the function init in the tts namespace with no parameters.
Create a class a of type QApplication, calling the constructor that takes an integer and an array of character pointers and pass it argc and argv.

Generate a DSP list for everyone in the program to see.
Initialize TTS.
Make a copy of QApplication. The builder will want the program arguments, so give them to it.

• I chose "everyone" over "everything" because I've found common, natural English to be rather poor at ascribing actions to things; I couldn't find the words when roleplaying non-sapient robots. Besides, differentiating between dynamic individuals and passive things helps to distinguish between code and data.
• Note the capitalization of TTS. It's an acronym, capitalize it. Also, capitalize the first letter of sentences. Thus, the language must be case-insensitive, losing the possibility of capitalization carrying info. Of course, sometimes the programmer can use capitalization to highlight things, so maybe it's not all bad, but then there's the question of whether acronyms are emphasised or merely written properly. It's one of those horrible code style issues I can't stand. Actually, I have experience with this one. In different environments (or, I admit, moods,) I get into the habit of capitalizing correctly or not at all. It can be really difficult to switch from one to the other on demand.
• I found it easier to assume pure OO, where class is just an object, and any object may be instantiated as if it were a class. It makes the English form much shorter with less jargon. OO was invented to be easier and more natural to write. If I remember right, impure OO languages were resisted by some because they were less natural. (Some day, I'll get around to learning Smalltalk.)
• We do not separate a list from its length in high-level languages! XD
• Seriously, the arguments to a program are global data. Why are we passing them around explicitly? This especially applies to natural language where the long name, "the program arguments" isn't likely to conflict with anything module-specific. Also, the word "the" may help define it, but if we insist on that I have no idea how the compiler should then interpret "our program arguments".
• The compiler must recognize many ways to describe the same thing. Example: "Make a copy of QApplication," versus, "Have a QApplication built." (And I've just realized how impure OO could work in natural language. Still, "Have X built" is less common and thus less natural. What are we, the Lord High Commissioner?)