Natural Language Programming

[Markbnj]

Well, certainly, miracles are always possible. I mean, not actual miracles. Unlikely events are always possible.

 

[smackababy]

So, Amazon is a simple site. Good to know. Certainly, minimal degree of difficulty in running one of the largest marketplaces on the internet.

 

[Gerry Rzeppa]

So, Amazon is a simple site. Good to know. Certainly, minimal degree of difficulty in running one of the largest marketplaces on the internet.

I wasn't saying that Amazon doesn't have a lot of code in its systems. I was saying that most of that code does simple stuff like "move this over there" and "show that on the screen" -- things that can be conveniently expressed in a natural language. But let's consider an example we can examine in detail:

Our compiler -- a sophisticated Plain-English-to-Executable-Machine-Code translator -- has 3,050 imperative sentences in it.

1,306 of those (about 42%) are conditional statements, and at least half of those are trivial things like these:

If the item is not found, break.
If the compiler's abort flag is set, exit.

The remainder of those conditional statements are slightly more complex, but all of them fit on a single line. Here are a couple of the longer ones:

If the length is 4, attach $FF32 to the fragment's code; exit.
If the rider's token is any numeric literal, compile the literal given the rider; exit.

Of the remaining sentences:

272 (about 9%) are simple assignment statements:

Put the type name into the field's type name.

202 (about 7%) are just the infrastructure for various loops:

Loop.
Get a field from the type's fields.
[ other stuff here]
Repeat.

183 (6%) simply add something to the end of this or that list, like so:

Add the field to the type's fields.

164 (about 5%) are trivial statements used return boolean results, start and stop various timers, show the program's current status, and write interesting things to the compiler's output listing.

Say no.
Say yes.
Set the variable's compiled flag.
Start the compiler's timer.
Stop the compiler's timer.
Show status "Compiling...".
List the globals in the compiler's listing.

119 (about 4%) advance the focus in the source code, sentences like:

Bump the rider.
Move the rider (code rules).

92 (about 3%) are used to create, destroy and keep internal indexes up to date, sentences like:

Create the type index using 7919 for the bucket count.
Index the type given the type's name.
Destroy the type index.

58 (about 2%) are used to find things in various lists:

Find a variable given the name.

37 (about 1%) are calls to various conversion routines:

Convert the rider's token to a ratio.

31 (about 1%) are used to generate actual machine code (plus those that appear in conditional statements, as above):

Attach $E8 and the address to the fragment.

And that accounts for 80% of the code in our compiler.

Only 57 of the remaining sentences (less than 2% of the whole) are mathematical in nature, a line here and there like these:

Add 4 to the routine's parameter size.
Subtract the length from the local's offset.
Multiply the type's scale by the base type's scale.
Calculate the length of the field's type.
Round the address up to the nearest multiple of 4096.

And the rest are not formulaic at all. Stuff like:

Copy the field into another field.
Append the fragment to the current routine's fragments.
Abort with "I was hoping for a definition but all I found was '" then the token.
Initialize the compiler.
Remove any trailing backslashes from the path name.
Reduce the monikette's type to a type for utility use.
Eliminate duplicate nicknames from the type's fields.
Prepend "original " to the term's name.
Extend the name with the rider's token.
Unquote the other string.
Read the source file's path into the source file's buffer.
Generate the literal's name.
Extract a file name from the compiler's abort path.
Write the compiler's exe to the compiler's exe path.
Swap the monikettes with the other monikettes.
Skip any leading noise in the substring.
Scrub the utility index.
Fill the compiler's exe with the null byte given the compiler's exe size.
Position the rider's token on the rider's source.
Pluralize the type's plural name.
Link.
Finalize the compiler.
Check for invalid optional info on the type.

And that's why we say that most of what most programs do is easy stuff, stuff that can be conveniently expressed in a natural language. And that, in turn, is why we like programming in Plain English: the thoughts in our heads are typed in as Plain English "pseudo code" and, with a tweak here and there, that pseudo code actually compiles and runs. And is self-documenting, to boot.

 

[Markbnj]

And that's why we say that most of what most programs do is easy stuff, stuff that can be conveniently expressed in a natural language. And that, in turn, is why we like programming in Plain English: the thoughts in our heads are typed in as Plain English "pseudo code" and, with a tweak here and there, that pseudo code actually compiles and runs. And is self-documenting, to boot.

You and your son are wrong. I'll just go ahead and assume that you mean to include him in your pronouncements, since you won't drop this "we think" and "our heads" crap, and he's the only other person using it, if in fact he is using it.

The complexity of modern software development has nothing to do with such primitives. This has been said a zillion ways in this thread, so the thought of trying to come up with yet another way to express it makes me physically weary.

There is also nothing self-documenting about your code. You obviously think so, but that could have more to do with your having stared at it for ten years, or whatever.

 

[BoberFett]

It's like the index in the back of a book. And it works. For beginners and experienced users.

No, I just told you. It's terrible. For me. As a user. You don't get to tell me what works for me. Grouping menus by function makes sense. Microsoft's grouping may leave much to be desired at times, but the concept is correct.

Your entire premise seems to be based on telling people that what they think is wrong, and that they need to follow you. Mark was correct, you're like a cult leader.

 

[Markbnj]

Grouping menus by function makes sense. Microsoft's grouping may leave much to be desired at times, but the concept is correct.

Gerry is like the guy who invented Esperanto, or Edison on the subject of DC vs AC, or Richard Stallman. I've put him in better company than his ideas deserve, obviously, but that's a matter of degree. Such people can never accept that the world has evolved a way of doing things that is less optimal than their own preferred solution.

 

[Squeetard]

Well, you are simply wrong and ignorant of what makes programming hard. Abstraction and logic are the two things I've seen new developers struggle with the most. What they don't struggle with are the various language features and syntactical anomalies. Gerry, this is what you don't understand and what has been brought up, numerous times, in this thread.

Exactly, never had a problem with the language. Trying to figure out how I am going to accomplish something is the toughest part.

I haven't had those problems with any of my students, many of whom have gone on to lucrative careers as professional programmers.

More BS. You realize we are all programmers here right? Your BS will not work here.

 

[Squeetard]

Okay, then, here's what that kind of thing looks like in Plain English. This is the essence of a pong-like game I wrote with a six-year-old where you try to stop a moving bird with a baseball bat:

To do it:
Draw the screen's box with the black color.
Move the bat. Draw the bat's picture.
Move the bird. Draw the bird's picture.
Check for collision.
Draw the score.
Refresh the screen.
If the escape key is not down, repeat.

To move the bat:
Put the mouse's spot into a spot.
Put the screen's right minus 1 inch into the spot's x.
Center the bat's picture on the spot.

To move a bird:
Move the bird's picture right the horizontal bump.
Move the bird's picture down the vertical bump.
If the bird's right is greater than the screen's right, play the pop sound; subtract 1 from the score; negate the horizontal bump.
If the bird's left is less than the screen's left, play the boink sound; negate the horizontal bump.
If the bird's bottom is greater than the screen's bottom, play the boink sound; negate the vertical bump.
If the bird's top is less than the screen's top, play the boink sound; negate the vertical bump.

To check for collision:
Put the bird's picture's center into a spot.
Put the bat's picture's box into a box.
If the spot is not in the box, exit.
Say "ow".
Add 1 to the score.
Add 1/64 inch to the horizontal bump.
Add 1/64 inch to the vertical bump.
Negate the horizontal bump.
Negate the vertical bump.
Move the bird's picture left 1/2 inch.

To draw the score:
Put the score into a string.
Put the green color into a color.
If the score is less than 0, put the red color into the color.
Draw the string in the center of the screen's box with the color and the font.

There's more stuff, of course, like type and variable definitions and some initialization code, but that's the gist of it.

More lies. Post the entirety of the code that makes a working game in your compiler. Not the trimmed down BS that will not work at all.

 

[BoberFett]

It also seems the ball in his pong game only ever moves at 45 degree angles. Depending on the velocity of your paddle at the point of contact, a ball in pong can bounce at various angles. He also doesn't seem to have timing in his game. Looks to me like it would run as fast as the computer can process the statements. There's no sound processing, so somewhere in the background there are things to handle sound card drivers. Oh no wait, he still relies on the painted whore to do all the real work, using their libraries via more complicated real code in his "noodle".

He says it's the gist of it and that there's "more stuff" as he does in every other example. He completely fails to note that the "other stuff" is where all the real work of the program is. All he seems to be proving is that with enough hidden code, programming is easy. Kind of like the way he boils down Amazon to "Display the product" and then brags about how easy it was. It's all smoke and mirrors, lots of hand waving but no substance.

I still say the work is interesting, but not to the extent he wants to pass it off as the future of programming. The guy is a fraud.

 

[Gerry Rzeppa]

There is also nothing self-documenting about your code.

Here are a couple of lines from another thread here:

//get the existing pixel:
		
		pngpixel * pixel = GetPixel(x,y);

In Plain English, that would be something like this:

Get the existing pixel at the x and the y.

Three points:

1. The programmer was obviously thinking he'd like to "get the existing pixel" -- hence the comment; and

2. The Plain English version eliminates the need for the comment because it is essentially the same as the comment (with the details filled in); it is identical to the thought that was in the programmer's head; it is self-documenting; and

3. This is another example of what I said at the end of my previous post: "We like programming in Plain English because the thoughts in our heads can be typed in as Plain English "pseudo code" and, with a tweak here and there, that pseudo code actually compiles and runs. And is self-documenting, to boot."

Now you can argue, if you want, that the other programmer in question is not very good at programming, or needs more experience, or whatever. But that's not the point. The point is (a) he wanted to convey a thought in his head to the machine while preserving that thought for himself and others who may look at his code; and (b) that the Plain English approach is the simplest and most natural and most self-documenting way of doing that.

 

[Gerry Rzeppa]

Your entire premise seems to be based on telling people that what they think is wrong...

Exactly the opposite. Our premises are based on observations of actual human behavior. We arrange our menus like the index of a book (rather than a table of contents) because we have observed that most people, most of time, resort to the index when they're looking for something in a book, not the table of contents.

 

[Gerry Rzeppa]

More lies. Post the entirety of the code that makes a working game in your compiler. Not the trimmed down BS that will not work at all.

It's not nice to call people liars, especially when they're not lying. Isn't there a forum rule against that somewhere? Boy, oh boy, you can never find a moderator when you really need one!

Now here's the source code for the entire pong-like game that I wrote with my son (who was about six at the time). It's not as elegant as it would have been had I coded it by myself for myself, because I was trying to plant some seeds in the little guy's head regarding levels of abstraction and how thinking at only one level at a time can simplify a problem, etc; and illustrating other language features as well. But there it is. Write me directly (gerry.rzeppa@pobox.com) and I'll send you the executable with the pictures of the birds and the bat.

To do it:
Clear the screen.
Loop.
Draw the screen's box with the black color.
Move the bat.
Draw the bat's picture.
Move the bird.
Draw the bird's picture.
Check for collision.
Draw the score.
Refresh the screen.
If the escape key is down, break.
Repeat.

To initialize the bird:
Pick a number between 1 and 6.
Put "bird " then the number into a path.
Put the path into the bird's picture.
Put 1/16 inch into the horizontal bump.
Put -1/16 inch into the vertical bump.

To initialize the bat:
Put "bat" into a path.
Put the path into the bat's picture.

To initialize the score:
Put "jokerman" and 1 inch into the font.
Put 0 into the score.

To draw the score:
Put the score into a string.
Put the green color into a color.
If the score is less than 0, put the red color into the color.
Draw the string in the center of the screen's box with the color and the font.

To move the bat:
Put the mouse's spot into a spot.
Put the screen's right minus 1 inch into the spot's x.
Center the bat's picture on the spot.

To move a bird:
Move the bird's picture right the horizontal bump.
Move the bird's picture down the vertical bump.
If the bird's right is greater than the screen's right, play the pop sound; subtract 1 from the score; negate the horizontal bump.
If the bird's left is less than the screen's left, play the boink sound; negate the horizontal bump.
If the bird's bottom is greater than the screen's bottom, play the boink sound; negate the vertical bump.
If the bird's top is less than the screen's top, play the boink sound; negate the vertical bump.

The horizontal bump is a number.
The vertical bump is a number.

The score is a number.
The font is a font.

A bird has a picture.
The bird is a bird.
A bat has a picture.
The bat is a bat.

To run:
Start up.
Initialize.
Do it.
Finalize.
Shut down.

To initialize:
Seed the random number generator.
Initialize the bird.
Initialize the bat.
Initialize the score.

To finalize:
Destroy the bird's picture.

To put a path into a picture:
Put "c:\a pong program\" then the path then ".png" into another path.
Read the other path into a buffer.
Create the picture given the buffer.
Center the picture in the screen's box.

To clear the screen:
Draw the screen's box with the black color.
Refresh the screen.

To play the boink sound:
Play "c:\a bird program\boing.wav".

To play the pop sound:
Play "c:\a bird program\pop.wav".

A guy has a picture.
The bad guy is a guy.

The good guy is a guy.

To decide if a guy is to the left of another guy:
If the guy's picture's right is less than the other guy's picture's left, say yes.
Say no.

To decide if a guy is to the right of another guy:
If the guy's picture's left is greater than the other guy's picture's right, say yes.
Say no.

To decide if a guy is above another guy:
If the guy's picture's bottom is less than the other guy's picture's top, say yes.
Say no.

To decide if a guy is below another guy:
If the guy's picture's top is greater than the other guy's picture's bottom, say yes.
Say no.

To check for collision:
Put the bird's picture's center into a spot.
Put the bat's picture's box into a box.
If the spot is not in the box, exit.
Say "ow".
Add 1 to the score.
Add 1/64 inch to the horizontal bump.
Add 1/64 inch to the vertical bump.
Negate the horizontal bump.
Negate the vertical bump.
Move the bird's picture left 1/2 inch.

To decide if a guy is touching another guy:
If the guy's picture's box is touching the other guy's picture's box, say yes.
Say no.

To draw a guy:
Draw the guy's picture.

To move a guy left a number:
Move the guy's picture left the number.

To move a guy right a number:
Move the guy's picture right the number.

To move a guy up a number:
Move the guy's picture up the number.

To move a guy down a number:
Move the guy's picture down the number.

To put a bird's bottom into a number:
Put the bird's picture's bottom into the number.

To put a bird's left into a number:
Put the bird's picture's left into the number.

To put a bird's top into a number:
Put the bird's picture's top into the number.

To put a bird's right into a number:
Put the bird's picture's right into the number.

 

[Gerry Rzeppa]

The guy is a fraud.

Is this kind of personal attack consistent with the forum rules? We're supposed to be discussing a programming language here, not me. Let's ask the moderator. Moderator?

 

[Gerry Rzeppa]

It also seems the ball in his pong game only ever moves at 45 degree angles. Depending on the velocity of your paddle at the point of contact, a ball in pong can bounce at various angles.

It was a program for a six-year-old. But any desired angle of movement can be had simply by adjusting the horizontal and vertical bump variables appropriately. It's not a big leap.

He also doesn't seem to have timing in his game. Looks to me like it would run as fast as the computer can process the statements.

True; again, it was a game for a six-year-old on his personal computer. If we needed special timing, it would have been easy to add. Autoscrolling in our file manager, text editor, and page editor, for example, are restricted to reasonable maximum speeds.

There's no sound processing, so somewhere in the background there are things to handle sound card drivers. Oh no wait, he still relies on the painted whore to do all the real work, using their libraries via more complicated real code in his "noodle".

Yes, we rely on the sound card to process sound -- isn't that what it's for? And isn't that what all the other languages do as well? There simply isn't time to reinvent every wheel in the universe. But we do contend that there isn't a single line of code on that sound card that couldn't have been written, as conveniently and efficiently, in our Hybrid Programming language; and we also contend that many of those lines -- perhaps most -- could have been written as conveniently and efficiently in straight Plain English.

He says it's the gist of it and that there's "more stuff" as he does in every other example. He completely fails to note that the "other stuff" is where all the real work of the program is.

So the "real work" is done at the lower levels only? I don't think so. I think real work is done at all levels, and none is more or less important than another. Our page editor, for example, couldn't do it's job if there wasn't a routine somewhere in the bowels of the graphics card to set a pixel to a certain color; but that graphics card, by itself, won't let us "Autoscroll the page to the cursor" in a wysiwyg document either.

Further, my very first post (and many since) have made it quite clear that a mixture of languages is not only most convenient, but sometimes necessary, to get our work done. Remember this routine from my initial post?

To add a number to another number: Intel $8B85080000008B008B9D0C0000000103.

Self-documenting Plain English combined with Intel machine code in a single sentence. Real work being done at both levels. And our proposed Hybrid Programming Language takes this a step further. Remember this example?

To convert a fahrenheit temp to a celsius temp: c=(f-32)*5/9

This time, self-documenting Plain English combined with standard "computer dialect" mathematical notation.

I really don't see why an operating system or a graphics card or anything, in fact, couldn't be conveniently and efficiently programmed in such a language.

All he seems to be proving is that with enough hidden code, programming is easy.

Not so; the programmer who works at a high level faces most of the same design and implementation problems as the programmer who works at a lower level. But sure, we need to use other people's code from time to time simply because no one will ever live long enough to code everything from scratch.

Kind of like the way he boils down Amazon to "Display the product" and then brags about how easy it was.

Take the last project you worked on and analyze it the way I analyzed our compiler code above. I'm pretty sure -- real sure, in fact -- that you'll find that most of your code does easy stuff like our compiler (or any other program that has ever been constructed, for that matter).

It's all smoke and mirrors, lots of hand waving but no substance. I still say the work is interesting, but not to the extent he wants to pass it off as the future of programming.

I refer you again to the examples in blue above. I really can't imagine a more natural, convenient, or self-documenting way of conveying those thoughts to the computer. Perhaps you can, and perhaps the future of programming will look more as you imagine it. But my experience has been that in the long run, it's the most natural, convenient, and self-documenting modes of expression that overcome. I hasten to add that I'm an optimist in many ways; but I'm realist enough to know that the innate foolishness of men can drag anything down to a lower common denominator: it may very well be that the end that's in store for all of us "under the sun" is much different from the bright and cheery picture I've been painting. But hope floats. God forbid that I be one who tries to sink it!

 

[repoman0]

I hasten to add that I'm an optimist in many ways; but I'm realist enough to know that the innate foolishness of men can drag anything down to a lower common denominator: it may very well be that the end that's in store for all of us "under the sun" is much different from the bright and cheery picture I've been painting. But hope floats. God forbid that I be one who tries to sink it!

This is why everyone here is irritated by you.

Anyway, I've been following the thread for the discussion because it's an interesting idea, although it definitely doesn't seem any easier than a traditional programming language. Trying to read some of the posted code is painful and at least to me would be easier and less ambiguous if it were just Python or any other higher level scripting language. Options are always nice but your presentation needs serious work to not come off as such a "holier than thou" obnoxious messiah ... see the bolded above.

 

[Gerry Rzeppa]

...at least to me would be easier and less ambiguous if it were just Python or any other higher level scripting language.

Were you thinking of Python 2 or Python 3? But let's look at some of our options:

BASIC:        PRINT "Hello, world!"
C:            printf("Hello, world!\n");
C++:          std::cout << "Hello, world!\n";
Delphi:       Writeln('Hello, world!');
Go:           println("Hello, world!")
Java:         System.out.println("Hello, world!");
JavaScript:   console.log('Hello, world!');
Objective-C:  NSLog(@"Hello, world!\n");
Perl:         print "Hello, world!\n";
Perl 5.10:    say 'Hello, world!';
PHP:          <?php print ('Hello, world!'); ?>
Python 2:     print "Hello, world!"
Python 3:     print("Hello, world!")
Ruby:         puts "Hello, world!"
Visual Basic: Console.WriteLine("Hello, world!")

The problem, as I'm sure you can see, isn't ambiguity, it's arbitrariness. And that's why we went with Plain English. We had been inventing languages for years, each (we thought) better than the last, but all with that same fatal flaw: arbitrariness. So finally we said to ourselves, "Instead of inventing a new language, why not simply use the one everybody already knows?"

Write "Hello, world!"

And why not make it extensible, so it can adjust itself to the vocabulary and needs of each programming community that uses it (possibly for very different purposes). But keep it English, grammar-wise and punctuation-wise, so any English-speaker can understand (in essence) what is being said. An elementary school teacher, for example, might want her students to be able to say things like:

Write "Hello, world!" in the middle of the screen.
Write "Hello, world!" in big green letters.
Write "Hello, world!" in a very fancy font.

While a professional programmer might want to be more specific of the output's target:

Write "Hello, world!" on the default console.
Write "Hello, world!" on the alternate console.

In all these Plain English cases, I hope you can see (a) that the programmers's thoughts are being conveyed to the machine, not in an arbitrary syntax that needs to be learned, but in a syntax that the programmer already knows; and (b) that all the statements are punctuated in the usual way, and are grammatically intelligible to all kinds of programmers (and users!), even though the specific vocabulary of each group may not be fully understood.

 

[BoberFett]

This thread is lockbait.

At this point, I agree. I don't think there's any further benefit to be gained, and the discussion is devolving into name calling. OP is free to create threads on topics specific to his project, but if the discussion heads in the same direction this one has then they will be locked too.

Markbnj