Natural Language Programming

Page 10 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

Natural Language Programming: Good Idea?

  • Yes

  • Maybe

  • No


Results are only viewable after voting.
Status
Not open for further replies.

Gerry Rzeppa

Member
Dec 13, 2013
195
1
76
www.osmosian.com
What I am struggling to understand is why does this require a programming language? Wouldn't a compiler that could interpret or an IDE that could convert "natural English" to something like C++ code be a much better instructional tool?

A system with "an IDE that could convert 'natural English' to something like C++ code" would require two translators: (1) the "English to C++ converter" and (2) the "C++ to machine code" compiler. Our Plain English system requires only one translator: the "English to machine-code" compiler. The latter system, with "fewer moving parts", is thus easier to explain and for that reason is a better instructional tool.

The two-step system would also send the wrong message to the student: it would give the impression that "real" programming is accomplished with esoteric languages like C++ and that English is suitable only for beginners and end users.

Besides, a hundred years from now, C++ will (hopefully) be gone and forgotten. But English will most likely survive. So the more code we can create in English, the longer our code is likely to endure.

Have you seen our original (albeit somewhat overly optimistic) Manifesto? www.osmosian.com/manifesto.pdf

Also, Gerry, I'd really work on your sales pitch, especially with regards as to what you need the money for. And, I'd invest in some kind of screen sharing program. It is a lot cheaper than moving to Ohio.

Yeah, my son and I use "Join Me" all the time to commune from a distance. But it's just not as handy (or as fun) as actually being in the same physical room. There's just something good and solid and inspirational about working face-to-face with someone else.

And I'm not sure exclusively virtual and isolated communications are a healthy thing in the long run. I'm pretty sure if Mark and I ever got together with our families for a spirited discussion of programming languages, we'd make more progress toward agreement in a day than we can make on a forum like this in a year.
 
Last edited:

Markbnj

Elite Member <br>Moderator Emeritus
Moderator
Sep 16, 2005
15,682
13
81
www.markbetz.net
And I'm not sure exclusively virtual and isolated communications are a healthy thing in the long run. I'm pretty sure if Mark and I ever got together with our families for a spirited discussion of programming languages, we'd make more progress toward agreement in a day than we can make on a forum like this in a year.

Fine, buy me a plane ticket. Invest your own money in the working lifestyle you prefer. Trying to crowd-fund it, unless you've specifically said "Hey, fund my lifestyle move to Ohio!" is borderline fraud.
 

smackababy

Lifer
Oct 30, 2008
27,024
79
86
A system with "an IDE that could convert 'natural English' to something like C++ code" would require two translators: (1) the "English to C++ converter" and (2) the "C++ to machine code" compiler. Our Plain English system requires only one translator: the "English to machine-code" compiler. The latter system, with "fewer moving parts", is thus easier to explain and for that reason is a better instructional tool.

The two-step system would also send the wrong message to the student: it would give the impression that "real" programming is accomplished with esoteric languages like C++ and that English is suitable only for beginners and end users.

Besides, a hundred years from now, C++ will (hopefully) be gone and forgotten. But English will most likely survive. So the more code we can create in English, the longer our code is likely to endure.

Have you seen our original (albeit somewhat overly optimistic) Manifesto? www.osmosian.com/manifesto.pdf

And, we already have a C++ to machine code compiler that has been refined for how any years? A two step system is absolutely ideal. Think about how you learn anything. First, you start with the fundamentals (easy to do in plain English, especially from a conceptual standpoint) and then you go to far more complex ideas and syntax.

And, C++ won't be forgotten in 100 years, same as in 40 years we will still be talking about FORTRAN. Sure people might not be using it, as something better hopefully comes along, but I'm sure someone will be getting paid ridiculous amounts of money to support all those "legacy" Java and C++ systems we're pumping out in corporate America today.

The more code you "create" in English, the more ludicrous actually debugging is going to be. Explain complex problems using words is hard and wordy enough. You've yet to post an example of a real world problem in Plain English, and at this point, I don't think you actually can.
 

Markbnj

Elite Member <br>Moderator Emeritus
Moderator
Sep 16, 2005
15,682
13
81
www.markbetz.net
And, C++ won't be forgotten in 100 years, same as in 40 years we will still be talking about FORTRAN. Sure people might not be using it, as something better hopefully comes along, but I'm sure someone will be getting paid ridiculous amounts of money to support all those "legacy" Java and C++ systems we're pumping out in corporate America today.

I think that for a fundamental change in the way we program computers we will have to see a fundamental change in the way computers work. As long as they are discrete state machines operating with boolean logic and a limited instruction set, then something like our current symbolic programming languages is going to be the normal way to interact with them. That's because despite the fact that we now work many levels of abstraction above the hardware, we're still speaking the same language it does: the language of instructions and boolean logic. All other systems are layered on top of that fundamental system and have to perform interpolation and translation. Because processors are so incredibly stupid and clockwork they have to be instructed very precisely in what to do. You can't simply tell them, using any language you like, unless you have built very sophisticated mechanisms to ensure that the translation is always accurate and specific enough for the machine to safely execute. If Gerry had actually accomplished that, or anything even close to that, then he wouldn't have any problem at all getting a lot of positive attention and involvement through any number of readily available channels.
 

MagnusTheBrewer

IN MEMORIAM
Jun 19, 2004
24,135
1,594
126
Fine, buy me a plane ticket. Invest your own money in the working lifestyle you prefer. Trying to crowd-fund it, unless you've specifically said "Hey, fund my lifestyle move to Ohio!" is borderline fraud.

I think that's a little over the top. Everyone doing crowd funding projects are doing exactly what Gerry is doing, he's just being up front about it. I think he's misguided but, I don't think he's out to defraud anyone.
 

Markbnj

Elite Member <br>Moderator Emeritus
Moderator
Sep 16, 2005
15,682
13
81
www.markbetz.net
I think that's a little over the top. Everyone doing crowd funding projects are doing exactly what Gerry is doing, he's just being up front about it. I think he's misguided but, I don't think he's out to defraud anyone.

I don't really think so. This is from the indiegogo page:

So the hard part is done and it works. But it's only a prototype, and there are a lot of improvements we'd still like to make in our natural language processing. And we need to integrate the formula and graphic parts as well. Not to mention make the thing run on something other than just Windows. And thoroughly test it. Document it. Package it up and make sure it's ready for prime time. But we're out of money and need your help.

He never says specifically what he wants the money for, but he certainly implies that it is going to fund the improvements he needs to make, not the costs of moving his family to Ohio. You're right, it's probably no more vaguely misleading than lots of other unfunded crowd-funding projects. Maybe humans have better instincts than I give them credit for.

Edit: meh, I admit I can't get past the smell of the whole thing at this point, so I'm reading it the worst possible way. But the bottom line is he doesn't need to move to Ohio to accomplish the things he says he wants to accomplish. That's a lifestyle decision.
 
Last edited:

Gerry Rzeppa

Member
Dec 13, 2013
195
1
76
www.osmosian.com
You've yet to post an example of a real world problem in Plain English, and at this point, I don't think you actually can.

Writing a wysiwyg page editor is a real world problem.

Our page editor is written in entirely in Plain English. It can be used to conveniently and efficiently create documents with any number of wysiwyg pages.

The pages can be displayed in a list (with identifying text on the "edges") or one at a time in actual, enlarged, or reduced size.

Pages can be automatically numbered (single- or double-sided) with the location, font, style, size, alignment, and color of the page numbers at the user's discretion.

Each page can contain any number of "shapes" including:

(a) vector graphics (circles, ellipses, rectangles, round-corner rectangles, and polygons of arbitrary complexity);

(b) bitmapped images imported from any of the popular file types (.jpg, .png, .bmp, etc); and

(c) text in various fonts, styles, sizes, and alignments.

Shapes and groups of contiguously or non-contiguously selected shapes can be added, modified, deleted, duplicated, cut, copied, pasted, moved, sized, layered, cropped, smoothed, mirrored, flipped, and rotated (within and across pages and documents).

A predefined palette of 84 colors (plus seven shades of gray and black, white, and clear) is provided; colors can be applied to any shape as a border or a fill, and to the text within text shapes.

Grids of various sizes are included to simplify drawing by hand.

Spell checking is provided via a 64,000 word lexicon.

Incremental find is provided for interactive searching within and across pages.

Pages and groups of contiguously or non-contiguously selected pages can be duplicated, cut, copied, pasted, and moved within and across documents.

Single or multiple copies of pages and groups of contiguously or non-contiguously selected pages can be printed.

Documents are saved, by default, in the all-text Osmosian "mark up" language (much simpler and prettier than HTML). Pages and groups of contiguously or non-contiguously selected pages can also be saved as PDFs.

And there are many other standard and unique features.

The whole program is about 4,000 lines long. Here are the first hundred:

To add a page to a document:
If the document is nil, exit.
Create the page.
Insert the page into the document's pages before the document's first selected page.
Set the document's modified flag.
Adjust the edge of every page in the document.

To adjust a document:
If the document is nil, exit.
Put the pad's box into a box.
Put the box's height divided by the default font's height times the default font's height into a height.
Put the box's top plus the height into the box's bottom.
Put the box into the document's box.
Put 0 and the edge height into the document's grid.
Put the document's box's left-top into the document's origin.

To adjust the edge of every page in a document:
If the document is nil, exit.
Loop.
Get a page from the document's pages.
If the page is nil, break.
Adjust the edge of the page in the document.
Repeat.
Limit the origin in the document.

To adjust the edge of a page in a document:
If the document is nil, exit.
If the page is nil, exit.
Put 1/12 inch into the page's edge's radius.
Put 1/4 inch into the page's edge's left.
Put the document's right minus 1/4 inch into the page's edge's right.
Put 0 into the page's edge's top.
If the page is not the document's first page, put the page's previous' edge's bottom into the page's edge's top.
Put the page's edge's top plus the edge height into the page's edge's bottom.

To adjust a page:
If the page is nil, exit.
Adjust the shape refers given the page.
Adjust the title of the page.
Adjust the page number of the page.

To adjust the page number of a page:
If the page is nil, exit.
Clear the page's page number.
Find a shape given the page's shape refers and "page number".
If the shape is not nil, put the shape's text's first line into the page's page number; exit.
Find another shape given the page's shape refers and "page number (even)".
If the other shape is not nil, put the other shape's text's first line into the page's page number; exit.
Find a third shape given the page's shape refers and "page number (odd)".
If the third shape is not nil, put the third shape's text's first line into the page's page number; exit.

To adjust a shape:
If the shape is nil, exit.
If the shape's kind is "ellipse", put the shape's ellipse's box into the shape's box; exit.
If the shape's kind is "group", put the shape's shapes' box into the shape's box; exit.
If the shape's kind is "picture", put the shape's picture's box into the shape's box; exit.
If the shape's kind is "polygon", put the shape's polygon's box into the shape's box; exit.
If the shape's kind is "rectangle", put the shape's rectangle into the shape's box; exit.
If the shape's kind is "text", put the shape's text rectangle into the shape's box; exit.
Debug "adjust a shape: " then the shape's kind.

To adjust the shape refers given a page:
If the page is nil, exit.
Destroy the page's shape refers.
Create the page's shape refers given the page's shapes.
Sort the page's shape refers (horizontally).
Sort the page's shape refers (vertically).

To adjust the text in a shape:
If the shape is nil, exit.
If the shape's kind is not "text", exit.
Put the shape's text rectangle into a box.
Put the text margin into a margin.
Scale the margin given the shape's scale.
If the shape's border is not clear, add the margin to the box's left.
If the shape's border is not clear, subtract the margin from the box's right.
Change the shape's text given the box.

To adjust the title of a page:
If the page is nil, exit.
Put "untitled" into the page's title.
Find a shape given the page's shape refers and "title".
If the shape is nil, exit.
Put the shape's text's first line into the page's title.
If the page's title is blank, put "untitled" into the page's title; exit.
If the page's title ends with "...", exit.
If the page's title ends with "..", append "." to the page's title; exit.
If the page's title ends with ".", append ".." to the page's title; exit.
If the page's title's last's target is symbolic, exit.
Append "..." to the page's title.

To align any selected shapes on a page given an alignment:
If the page is nil, exit.
Loop.
Get a shape from the page's shapes.
If the shape is nil, exit.
If the shape is not selected, repeat.
Align the shape given the alignment.
Repeat.

To align a shape given an alignment:
If the shape is nil, exit.
If the shape's kind is "group", align the shape's shapes given the alignment; exit.
If the shape's kind is not "text", exit.
Align the shape's text given the alignment.

To align some shapes given an alignment:
Get a shape from the shapes.
If the shape is nil, exit.
Align the shape given the alignment.
Repeat.

To autoscroll a document given a spot and a flag:
Clear the flag.
If the document is nil, exit.
If the spot is in the document's box, exit.
Set the flag.
If the spot's y is less than the document's top, put the edge height into a difference's y.
If the spot's y is greater than the document's bottom, put - the edge height into the difference's y.
Scroll the document given the difference.
Wait for 50 milliseconds.
 

Gerry Rzeppa

Member
Dec 13, 2013
195
1
76
www.osmosian.com
Because processors are so incredibly stupid and clockwork they have to be instructed very precisely in what to do. You can't simply tell them, using any language you like, unless you have built very sophisticated mechanisms to ensure that the translation is always accurate and specific enough for the machine to safely execute.

One of the questions in our minds when we first looked into natural language programming was this: Can natural languages be parsed in a relatively "sloppy" manner and still provide a stable enough environment for productive programming?

Turns out the answer is yes. And we know that, from first hand experience, because we actually used 25,000 lines of "sloppily parsed" Plain English code to conveniently and efficiently develop a reliable Plain English development system including 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.

Can we "use any language we like"? Of course not. Do we have "sophisticated mechanisms to ensure that the translation is always accurate"? Nope. But can we tell the computer what we want it to do using typical English-language imperatives and get good results without straining our brains? Yes!
 

Gerry Rzeppa

Member
Dec 13, 2013
195
1
76
www.osmosian.com
...the bottom line is he doesn't need to move to Ohio to accomplish the things he says he wants to accomplish. That's a lifestyle decision.

And the programmers at Google don't need places like this to get their work done:

2uemz3p.jpg


But somebody thought they did. And paid for it all.

Compared with that, I think wanting to sit in the same room with my son while we write tens of thousands of lines of code together is more than reasonable.
 

velis

Senior member
Jul 28, 2005
600
14
81
I'd like to throw my 2 cents into this:

The way I see it Gerry, you have created a self-compiling language that can take its instructions in programming language similar to english. Whatever you program in it, it will compile into its new version and be able to use it in later iterations.

This means that if your son programs a text output function that needs to be specified as
select font osmosian. draw my fancy text at 300 horizontal and 500 vertical.

Then ok, it will be drawn. Now you "teach" your language to recognise and perform this:
draw my fancy text at 300 horizontal and 500 veritcal using Osmosian

Than this is exactly what you will get. So you and your son basically achieved the same thing, but each of you did it a little differently.
Basically, what I'm saying, you each created your own libraries that performed the same task. Your "natural language" compiler grew in size because it included those libraries into its code.

However, there's one fundamental flaw with this concept and what you expect its final result will be:
No matter how many people you have to input new syntax into the language, the language itself will not evolve into something that would ultimately understand English as a language.

Consider this command:
display code editor

You already have that in your language. It does what YOU want it to do. It doesn't do what I want it to do. If I modify it by adding more code, you won't be happy because I just made it possible for cursor to move beyond EOL and you don't like it (or vice-versa).

Ultimately - or rather: put more obiously - you would issue command such as:
start Far Cry 4

You need commands to be able to run a game that complex. and the game needs to be programmed down to the smallest detail necessary for it to run in the form that you envision. That would make your compiler at least as big as the actual game title is. But few of those commands would be usable for command such as
start Civilization 5

That one too would require precise instructions on how to actually execute.

Or another, perhaps easier to understand example:
sort 5, 2 and 13 and print them to screen

Assuming that "and print" isn't recognised as just another data point: Which sort algorithm is that? Bubble, quick, shell, merge? Any of the myriad of others? Of course you can program all of them into your language, but you'd just be making a library of sort algorithms. Your compiler won't be any smarter because of that, it will just support more ways of doing things. EXACTLY the same as any other language available nowadays.

And the actual sort command itself? As programmed. Just like any other command.
Everybody would have to HEAVILY rely on documentation to see what each command does since functions may be programmed to anything.

That in turn would force you to use function names less friendly to english language because they would have to somehow convey what it is they are actually doing. This would happen pretty early in the process of "filling" as people would attempt to achieve more and more complex functionality.

So, ultimately you don't need to "fill" the language. Since your compiler currently understands basic instructions and supports all the fancy stuff you gave it, you basically already achieved your goal of natural language parser. Any further work just inflates the library and adds further capabilities, but doesn't fundamentally change anything in your product. It won't magically be able to do anything more than what you program in it. Which is exactly the same as in any other computer programming language available today. Only YOURlanguage doesn't have any mechanisms in place to properly identify libraries, scopes, variables, and anything else for that matter. My sorting example above proves just that. I can see quite a few different ways I could interpret that command.

Edit: NVM. I read the thread a few days ago and reading the last few pages again shows that mr. Rzeppa cannot process the most basic explanations provided by actual programmers here. Hence this post is a waste as well.
 
Last edited:

Cogman

Lifer
Sep 19, 2000
10,277
125
106
And the programmers at Google don't need places like this to get their work done:

2uemz3p.jpg


But somebody thought they did. And paid for it all.

Compared with that, I think wanting to sit in the same room with my son while we write tens of thousands of lines of code together is more than reasonable.

Yup. Google will even pay to move employees and help with housing costs.

Here is the difference. Google didn't beg for money to do that. They have the profits to do those kinds of things for their employees.

Just because a multi billion dollar company can afford nice things for their employees, doesn't justify begging for money so you can get the same nice things that google has.
 

smackababy

Lifer
Oct 30, 2008
27,024
79
86
To add a page to a document:
If the document is nil, exit.
Create the page.
Insert the page into the document's pages before the document's first selected page.
Set the document's modified flag.
Adjust the edge of every page in the document.

Right off the bat, you're not telling me anything with this. 'Create a page' means absolutely nothing. I am relying on your to create, in some way you've specified, an object you've also specified. It sounds nice, except in the real world, I need to create both the object and the instantiation process of said object.

And, handling objects English gets much too verbose when you start working with inheritance. A declaration of an object, and then having to specify which methods I am overriding as well as which I am retaining functionality of the super class is going to get just silly to read.

Every specialty, or profession, has a very specific lexicon for a reason; it is required to fully explain the job. Using "plain English" to explain something doesn't do justice to the actual details involved in the process. A blacksmith give his instructions to a layman as "I forged the shoe", but the process isn't simply "forge shoe", there is a long list of instructions. You can tell a blacksmith to forge a shoe though, because they've created that bridge. You are trying to remove the all the steps to "make it easier to teach" and that just doesn't work. You can obscure the advanced concepts, but simply hiding them doesn't make programmers.

Think about how you could give instructions to a child with zero concept of any of the objects or actions involved. It gets extremely wordy the more complex you get, especially if there is any ambiguity in how the objects will interact or the actions that will occur based on the types of objects. If certain objects can have similar steps for all of that type, it gets even more confusing teaching them, as they will have to be aware of those types and that only certain actions are more specific. That is all handled fairly easily in OO and it is succinct enough to not be a chore to parse and read.
 

Markbnj

Elite Member <br>Moderator Emeritus
Moderator
Sep 16, 2005
15,682
13
81
www.markbetz.net
Gerry doesn't understand - and based on his responses here never will understand - that syntax is not the essential thing in programming. It's just a convenient mnemonic symbology that we use to express thoughts to a very simple machine. The essential thing in programming... anything, a computer or the activities of a construction company... is decomposing the problem into steps that can be executed by whatever is going to execute them. In the case of a computer that thing is very dumb and needs very simple instructions, while the tasks are very complex and contain a large number of states and transitions. You have to describe these things accurately and at the correct level of abstraction regardless of what language you use. Which is precisely why Gerry has never posted anything other than trivial examples, despite many requests to show something non-trivial that actually works and can be built and experimented on by others. His made-up-on-the-spot "code" like the example for inserting a new page into a document is laughable. I especially like how his "plain english" code contains nil comparisons and modified flags.

But my favorite line, by far, is "Adjust the edge of every page in the document." Thank you, Gerry. Everyone needs a good laugh at least once per day.
 

LevelSea

Senior member
Jan 29, 2013
943
53
91
But my favorite line, by far, is "Adjust the edge of every page in the document." Thank you, Gerry. Everyone needs a good laugh at least once per day.
You must have missed "Debuggers are for sloppy programmers."o_O
 

Cogman

Lifer
Sep 19, 2000
10,277
125
106
Gerry doesn't understand - and based on his responses here never will understand - that syntax is not the essential thing in programming. It's just a convenient mnemonic symbology that we use to express thoughts to a very simple machine. The essential thing in programming... anything, a computer or the activities of a construction company... is decomposing the problem into steps that can be executed by whatever is going to execute them. In the case of a computer that thing is very dumb and needs very simple instructions, while the tasks are very complex and contain a large number of states and transitions. You have to describe these things accurately and at the correct level of abstraction regardless of what language you use. Which is precisely why Gerry has never posted anything other than trivial examples, despite many requests to show something non-trivial that actually works and can be built and experimented on by others. His made-up-on-the-spot "code" like the example for inserting a new page into a document is laughable. I especially like how his "plain english" code contains nil comparisons and modified flags.

But my favorite line, by far, is "Adjust the edge of every page in the document." Thank you, Gerry. Everyone needs a good laugh at least once per day.

Well, I disagree about syntax being unimportant. I think that it is pretty important. Closures, interfaces, scoping, mutability constraints, all of these things are pretty important. Languages that don't have them or have lacking versions of them can devolve into spaghetti in a hurry (even languages that do have it can devlove into spaghetti).

The plain english syntax that I've seen from Gerry (the compiler he linked on github) was just horrible. It had things like this beauty

Code:
to compile the next statement given a rider (say):
  if the current routine's decider flag is not set, compile the next statement given the rider (call - internal); exit.
  move the rider (compiler rules).
  compile an expression given the rider.
  if the compiler's abort flag is set, exit.
  if the expression's variable is nil, abort with "Invalid 'say', I don't understand the variable '" then the expression's phrase then "'." and the rider; exit.
  if the expression's type cannot be reduced to "flag", abort with "I need a definite 'yes' or 'no' here." and the rider; exit.
  add a fragment given the load eax tag and the expression's variable.
  add another fragment given the exit tag.

yeash... That's rough, verbose, and honestly really hard to understand exactly what it is trying to do. The code is literally littered with things like this.

Now, that isn't to say that some other compiler is going to be much easier to understand, but at least I don't have do nearly as much mental gymnastics in order to figure out what exactly each sentence is doing.

For example, we are told that "the" promotes a variable to global scope. Yet obviously that is not the case here (or is it? Is "exit tag" a global variable?. I honestly can't what the scope of the if statement is. And then there is the whole "and then the rider" which, wtf is that doing?

At least with this from the GCC

Code:
void
set_decl_tls_model (tree node, enum tls_model model)
{
  struct varpool_node *vnode;

  if (model == TLS_MODEL_NONE)
    {
      vnode = varpool_node::get (node);
      if (!vnode)
	return;
    }
  else
    vnode = varpool_node::get_create (node);
  vnode->tls_model = model;
}

I know the scope of the if statement. I know what functions are being called. I know what all the variables are. I can reasonably look at this code and know exactly what it does (even if I don't know how it fits in with the rest of the big picture.) and what it affects. The plain english example doesn't give those guarantees. I don't know if I'm modifying global variables, local variables, or what. I don't know what the scoping of the statements are. I don't know what mysticism each word is doing.
 

Markbnj

Elite Member <br>Moderator Emeritus
Moderator
Sep 16, 2005
15,682
13
81
www.markbetz.net
Well, I disagree about syntax being unimportant. I think that it is pretty important. Closures, interfaces, scoping, mutability constraints, all of these things are pretty important. Languages that don't have them or have lacking versions of them can devolve into spaghetti in a hurry (even languages that do have it can devlove into spaghetti).

I'm just saying that the fundamental misunderstanding is that it is syntax and everything that is associated with the _act_ of programming that makes it complex, when in fact the complexity is inherent in the problems. That complexity would emerge regardless of what form the expression took.
 

Spungo

Diamond Member
Jul 22, 2012
3,217
2
81
What I am struggling to understand is why does this require a programming language? Wouldn't a compiler that could interpret or an IDE that could convert "natural English" to something like C++ code be a much better instructional tool?
Maybe that's how it currently works. Perl is mostly written in C. Python is written in C. Plain English could be written in C and still be usable.


A blacksmith give his instructions to a layman as "I forged the shoe", but the process isn't simply "forge shoe", there is a long list of instructions.
Which raises one of the more important points about programming and general computing - simplicity is in the libraries and tools. The easiest programming is done using the easiest tools, not the easiest language. I could say C# is a horrible language, but that doesn't change the fact that writing a C# program in Visual Studio is one of the easiest ways to build a simple program with a graphical user interface.

the complexity is inherent in the problems. That complexity would emerge regardless of what form the expression took.
Unless libraries are introduced to simplify things. Take the example of a random number generator. How does one make a random number? I don't know, but the problem can be simplified if someone else has already figured it out:
x = random();

Same thing with sorting lists. I don't know how sorting works. It seems to have something to do with comparing A vs B then returning -1, 0, or +1, and this is somehow applied to the entire list. Easier way:
sort(list);
someone else created the sort function

This relates back to the concept of using bigger and better tools, not creating new languages. The tools themselves might start to look like a new language.
 
Last edited:

Gerry Rzeppa

Member
Dec 13, 2013
195
1
76
www.osmosian.com
Right off the bat, you're not telling me anything with this.

Sure I am. I'm telling you that serious, real-world programs can and have been conveniently and efficiently written entirely in Plain English. Something you seemed to doubt before.

'Create a page' means absolutely nothing. I am relying on your to create, in some way you've specified, an object you've also specified. It sounds nice, except in the real world, I need to create both the object and the instantiation process of said object.

Of course. We're in the real world too. The definition of a page (the "type" -- or "object" as you call it) is further on in the code (under "P"):

A page is a thing with a width, a height, and some shapes,
[runtime only]
an origin, a grid, a superduper,
a scale ratio, a measure,
an edit shape (reference), some shape refers,
[edge stuff - also runtime only]
an edge roundy box,
a selected flag, a previously selected flag,
a title string, and a page number string.


Now here's the routine that you saw in the previous post:

To add a page to a document:
If the document is nil, exit.
Create the page.
Insert the page into the document's pages before the document's first selected page.
Set the document's modified flag.
Adjust the edge of every page in the document.


The imperative "Create the page" instructs the computer to allocate memory for an instance of that type and to initialize it. After the command is executed, a pointer to that instance will appear in the passed-by-reference parameter "a page" (which is referred to within the routine as "the page").

And, handling objects English gets much too verbose when you start working with inheritance. A declaration of an object, and then having to specify which methods I am overriding as well as which I am retaining functionality of the super class is going to get just silly to read.

Exactly. The object-oriented paradigm is unnatural. That's why we don't find a convenient and efficient mode of expression for the things you describe in English: people don't naturally think in those terms, and thus don't often talk in those terms, and that's why English doesn't have a convenient way to express thoughts in those terms.

Every specialty, or profession, has a very specific lexicon for a reason; it is required to fully explain the job. Using "plain English" to explain something doesn't do justice to the actual details involved in the process.

In this case it did. We were able to write a non-trivial wysiwyg page layout program conveniently, efficiently, and clearly in Plain English. Top to bottom.

A blacksmith give his instructions to a layman as "I forged the shoe", but the process isn't simply "forge shoe", there is a long list of instructions. You can tell a blacksmith to forge a shoe though, because they've created that bridge. You are trying to remove the all the steps to "make it easier to teach" and that just doesn't work. You can obscure the advanced concepts, but simply hiding them doesn't make programmers.

But all those "advanced concepts" must be in our system somewhere or that "Create a page" command wouldn't work. So we haven't removed any of the steps. Let's chase that "Create a page" imperative all the way down. "Create a page" calls this routine:

To create a page:
Allocate memory for the page.
Put 8-1/2 inches into the page's width.
Put 11 inches into the page's height.
Put 0 and 0 into the page's origin.
Put the tpp and the tpp into the page's grid.
Put 1/1 into the page's scale.
Put 1 / the tpi into the page's measure.
Reset the superduper given the page.
Adjust the page.


The first line of that routine, "Allocate memory for the page," calls a routine that was generated by the compiler (at compile time) when the type "page" was defined. Here's the code from the Compiler that generates the routine:

To add the allocate routine for a type:
If the type is nil, exit.
If the compiler's abort flag is set, exit.
If the type cannot be reduced to "pointer", exit.
If the type's target type is nil, exit.
Add a routine to the routines given nil.
Append "allocate memory for a " then the type's name to the routine's header string.
Append "assign the " then the type's name then " given " to the routine's body string.
Append the type's target type's length then "." to the routine's body string.
Slap the routine's routine header on the routine's header string.
Slap the routine's routine body on the routine's body string.
Compile the header of the routine.


The generated routine will have just a single imperative in it of this form:

Assign the [type name] given [the number of bytes required].

At runtime, this imperative calls the routine you see below (which is located in the Noodle library -- a given for the creator of a page-layout program):

To assign a pointer given a byte count:
If the byte count is 0, void the pointer; exit.
Privatize the byte count.
Round the byte count up to the nearest power of two.
Call "kernel32.dll" "HeapAlloc" with the heap pointer and 8 [heap_zero_memory] and the byte count returning the pointer.
If the pointer is not nil, add 1 to the heap count; exit.


(If you're wondering why we didn't have the compiler generate code to directly call Windows to allocate memory, it's because we wanted to keep as much operating-specific stuff as we could out of the compiler and in a library (in this case, the Noodle) where it could be easily modified for use with other operating systems.)

And that's that. I hope you get the idea. It's Plain English, from the very top to the very bottom. Easy to think about, easy to type, easy to read, easy to explain to others. A thing of beauty. I love Plain English; best programming language I've ever used (and I've used a lot of 'em).

Think about how you could give instructions to a child with zero concept of any of the objects or actions involved. It gets extremely wordy the more complex you get, especially if there is any ambiguity in how the objects will interact or the actions that will occur based on the types of objects. If certain objects can have similar steps for all of that type, it gets even more confusing teaching them, as they will have to be aware of those types and that only certain actions are more specific. That is all handled fairly easily in OO and it is succinct enough to not be a chore to parse and read.

Whatever you're talking about there, it's not a problem we've encountered. And we've done a lot of serious programming in Plain English. Perhaps the object-oriented approach is a solution in search of a (non-existent) problem?
 

Markbnj

Elite Member <br>Moderator Emeritus
Moderator
Sep 16, 2005
15,682
13
81
www.markbetz.net
Unless libraries are introduced to simplify things. Take the example of a random number generator. How does one make a random number? I don't know, but the problem can be simplified if someone else has already figured it out: x = random();

Yes you can introduce abstractions and that works really well up to some limit of general utility. That's why we're able to focus so much more of our time on domain problems today than we did twenty years ago. But it's the complexity of the domain problems I'm talking about, not those minor utility abstractions that can be reused in literally any context. Which is not to devalue those. They're great :).
 

Cogman

Lifer
Sep 19, 2000
10,277
125
106
I'm just saying that the fundamental misunderstanding is that it is syntax and everything that is associated with the _act_ of programming that makes it complex, when in fact the complexity is inherent in the problems. That complexity would emerge regardless of what form the expression took.

Gotcha and I agree.

I was going to write a long post about the importance of a good syntax... But I really do agree with you and I thought it might come off sounding like I was trying to debate your statement :).
 

Gerry Rzeppa

Member
Dec 13, 2013
195
1
76
www.osmosian.com
The essential thing in programming... anything, a computer or the activities of a construction company... is decomposing the problem into steps that can be executed by whatever is going to execute them.

Agreed.

In the case of a computer that thing is very dumb and needs very simple instructions, while the tasks are very complex and contain a large number of states and transitions.

Some tasks "are very complex and contain a large number of states and transitions." Others are not. We maintain that most of the tasks that most programs do, are not.

You have to describe these things accurately and at the correct level of abstraction regardless of what language you use.

Agreed.

Which is precisely why Gerry has never posted anything other than trivial examples, despite many requests to show something non-trivial that actually works and can be built and experimented on by others.

Nonsense. Just above I posted the first 120 lines of a complete and elegant wysiwyg page editor written entirely in Plain English (the forum editor wouldn't let me post the whole thing). The rest of that source and, in fact, the source for our entire development system is readily available from me (gerry.rzeppa@pobox.com) or on Github (https://github.com/Folds/osmosian).

His made-up-on-the-spot "code" like the example for inserting a new page into a document is laughable.

That's not "made-up-on-the-spot code" -- that's the actual code from our system. I simply copied it from our source and pasted it here. That code compiles to a working, stand-alone Windows executable that does all of the things I described in the post above, and much more.

I especially like how his "plain english" code contains nil comparisons and modified flags.

The great thing about programming in English is you can say things as you please. If you want to say "If the document is modified" instead or "If the modified flag is set", you can.

But my favorite line, by far, is "Adjust the edge of every page in the document." Thank you, Gerry. Everyone needs a good laugh at least once per day.

The "edges" of pages in our wysiwyg document editor are displayed when a document is viewed in toto (so the user can easily select one or more pages to work on). Those "edges" contain run-time-only data (like a flag that indicates whether a page is selected or not) that needs to be updated from time to time. The sentence "Adjust the edge of every page in the document" instructs the computer to perform the appropriate updates.
 

Gerry Rzeppa

Member
Dec 13, 2013
195
1
76
www.osmosian.com

Issue #4 on the GitHub project, which is kind of a summary of the other issues, is more enlightening:

The changes to the program currently proposed, and the use of GitHub itself, are contrary to the underlying philosophy of the original Osmosian program. Since the program loses its value when it ceases to be a manifestation of that philosophy, this project should be abandoned.

Allow me to elaborate.

The original objective of the Osmosian programming project was to create a minimal yet sufficient programming language / development environment -- something simple enough for beginners, yet powerful enough for professionals. The test case for the project was to be the resulting system itself: a system that could be explained, in the simplest of terms, to a novice; yet written, top to bottom, code and documentation, using nothing but the facilities of the system itself.

This objective was our guide as we studied and evaluated a wide variety of programming languages, real and hypothetical, and an equally wide variety of development environments, real and hypothetical. The conclusions we reached at the end of these studies was twofold. First, that the syntax of the programming language should simply be our own native tongue (with allowance for similar systems in other natural languages). And secondly, that the development environment should be a minimal yet intuitive marriage of form and function -- employing text where text is most efficient or convenient, and graphics where graphics are most efficient and convenient.

These conclusions quickly gave birth to a collection of questions that we attempted to answer with actual prototype facilities. Where we succeeded in achieving workable implementations, the ideas were retained and the prototype facilities merged into the final product. Where we failed, the ideas were rejected and replaced with others. The major questions thus answered by our working prototype are these:

1. Can low-level programs like compilers be conveniently and efficiently written in high-level languages like English? Yes.

2. Can English be parsed in a relatively "intuitive" and "sloppy" way and still provide a stable enough means for productive programming? Yes.

3. Can sophisticated programs like wysiwyg page-layout facilities be conveniently and efficiently written without "make" files, objects, nested ifs, real numbers, and a wide variety of other common constructs? Yes.

4. Is it in fact easier to program when you don't have to translate your natural-language thoughts into an alternate syntax? Yes.

5. Can a convenient and efficient user interface be designed without overlapping windows, re-sizable windows, scroll bars, tool bars, tear-off palettes, dialog boxes, multi-state menus and commands; disappearing tabs, three-dimensional embellishments, and a wide variety of other common widgets and devices? Yes.

6. Can a project of this magnitude be managed without automated tools such as version control systems, and proved reliable without recourse to automated testing facilities? Yes.

7. Can a project of this magnitude be completed by a very small team of dedicated programmers in less than a man-year without recourse to social coding sites like GitHub or BitBucket? Yes.

And so forth. In short, the system stands as a needed iconoclastic challenge to nearly every preconceived notion about programming that a modern practitioner might have. A candle in the wind, perhaps, but a light in the darkness nevertheless.

Unfortunately, the proposed changes here on GitHub (which do nothing but inflate the system with new menu styles, new buttons, new ways of entering commands, new ways of presenting results, unnecessary facilities, additional source files, etc), and, in fact, the whole of the GitHub machinery itself (which does nothing but complicate the project with multiple copies of the code in various states of modification, copies of the documentation in various states of modification, new interfaces, additional instructions, etc) are in direct conflict with the original objectives and underlying philosophy of the system as it was conceived and implemented. They appear, in fact, to be nothing but attempts to snuff out its distinctive character by making it more like everything else.

Further development is, of course, in order. Such a remarkable little flame should be tended until it becomes bright enough to inspire all. But this is not the way to go about it.


The original GitHub post of this issue is here: https://github.com/Folds/osmosian/issues/4
 
Last edited:

Gerry Rzeppa

Member
Dec 13, 2013
195
1
76
www.osmosian.com
For example, we are told that "the" promotes a variable to global scope.

That's not true (in Plain English) and I never said such a thing. Global variables are defined with declarative sentences that start with the definite article (the), outside the scope of all routines. In imperative sentences (which are the only kind allowed within a routine), the definite article (the) indicates a reference to either a parameter or a previously defined local variable.

This sentence (which starts with an indefinite article) defines a type called "total" based on the built-in type "number":

A total is a number.

This statement (which starts with the definite article) defines a global variable called "grand total" based on the type just defined ("total"):

The grand total is a total.

This statement (a routine header, which starts with a preposition) defines a parameter of type "total" that can be referenced within the routine as "the total":

To do something to a total:

And this statement, an imperative within a routine, defines a new local variable called "running total" (of type "total") on the fly, so to speak, and initializes it with the total that was passed as a parameter.

Put the total into a running total.

Sometimes I think you folks just want things to be difficult.

And then there is the whole "and then the rider" which, wtf is that doing?

You can read all about riders on pages 46 to 48, and page 103 of our instruction manual:

www.osmosian.com/instructions.pdf

At least with this from the GCC... I know the scope of the if statement. I know what functions are being called. I know what all the variables are. I can reasonably look at this code and know exactly what it does (even if I don't know how it fits in with the rest of the big picture.) and what it affects. The plain english example doesn't give those guarantees. I don't know if I'm modifying global variables, local variables, or what. I don't know what the scoping of the statements are. I don't know what mysticism each word is doing.

"User friendly is what the user is used to." :)

You need to take a few minutes to learn the fundamentals of Plain English programming. A Plain English programmer can easily spot all the things you mention above: we never would have been able to construct our 25,000 sentence development system in Plain English if we couldn't.
 
Status
Not open for further replies.