Natural Language Programming

[Gerry Rzeppa]

Plain English could be written in C and still be usable.

But not as usable. We couldn't for example, teach a kid who had learned to program easy stuff in Plain English how to write a Plain English compiler in Plain English. In fact, we'd be giving him the wrong impression: the impression that simple and familiar languages are fine for kids, but convoluted and esoteric languages are necessary for grown up stuff. Which might encourage him to give up programming and become a lawyer -- and nobody wants that!

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.

It's true that the availability of a wide range of pre-written routines is an asset to any language.

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.

That's one of the beauties of Plain English: on the surface, there's no difference between a sentence that is handled by the compiler, or a built-in routine, or a library we supply, or a library developed by another programmer, etc. All the sentences simply look like sentences. For example:

A running total is a total.

That sentence is handled entirely by the compiler.

Add 100 dollars to the running total.

Here, the conversion from dollars to pennies (the internal storage format we use for money) is handled by the compiler, while the rest of the statement is handled by a built-in routine coded in a hybrid of Plain English and assembler.

Add the running total to the grand total.

That sentence is handled by a standard library routine.

Print the grand total on the standard form.

And that sentence would be handled by a routine written by another programmer for this particular application.

The more you use Plain English, the more it "gets to know you" -- and the more things you can say in the way you want to say them.

 

[Markbnj]

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).

Triviality is in the eye of the beholder, and even if we were to agree that what you posted is not trivial, it wouldn't be meaningful because it is also not what you've been claiming since day one here. It's not "plain english." It's just your own custom, and more cumbersome, syntax. Your routine to "allocate memory for a type" is enlightening. I thought Osmosian was supposed to make programming easier?

 

[Gerry Rzeppa]

Triviality is in the eye of the beholder, and even if we were to agree that what you posted is not trivial...

So, can we agree on that? Can we agree that compilers and page editors are non-trivial, real-world applications? And can we agree that such things have been written in Plain English?

...it wouldn't be meaningful because it is also not what you've been claiming since day one here.

My claims are in the initial post:

1. That we personally find it easier to program when we don’t have to translate our natural-language thoughts into an alternate syntax;

2. That natural languages can be parsed in a relatively “sloppy” manner (as humans apparently parse them) and still provide a stable enough environment for productive programming; and

3. That low-level programs (like compilers) can be conveniently and efficiently written in high level languages (like English).

I stand by those claims, and offer our fully functional Plain English development system as evidence.

It's not "plain english." It's just your own custom, and more cumbersome, syntax.

"Plain English" (both words capitalized) is the name of our programming language; it is a subset of "plain English" (only the second word capitalized). The specifics of that subset are described, in summary form, on page 11 of our instruction manual which is readily available here:

www.osmosian.com/instructions.pdf

In addition to the plain English part of Plain English, there are a few non-standard exceptions (like doubling double-quotes in a string to indicate an embedded double-quote, and preceding hexadecimal literals with a "$") that we included (a) because we found them necessary and handy but not detrimental to answering the three questions we set out to answer; and (b) to demonstrate how Plain English could easily grow into the Hybrid Programming Language that we're now publicly proposing.

We found, in writing 25,000 lines of the stuff, that the syntax was, on the whole, not cumbersome. On the contrary, we found it easy to think about, easy to type, easy to remember, easy to explain to others. And we intend to address those few areas where the syntax did prove to less than ideal in the Hybrid Programming Language mentioned above.

Your routine to "allocate memory for a type" is enlightening. I thought Osmosian was supposed to make programming easier?

I presume you're referring to the routine in our compiler that generates a routine to "allocate memory for a type" (not the routine that actually allocates the memory). The generated routine, in fact, is quite trivial, and would look like this (for a 64-byte record of type "page"):

To allocate memory for a page: Assign the page given 64.

As mentioned in the aforementioned post, the imperative "Assign the page given 64" is a call to the generic memory allocation routine in our "Noodle" library:

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.

When we rework everything in our Hybrid Language we'll probably make the header of the above routine read like this:

To assign some bytes to a pointer:

Which not only reads better, but would make the generated routine read better as well:

To allocate memory for a page: Assign 64 bytes to the page.

Live and learn. In fact, we'll probably add garbage collection for all types (similar to the method we now use for strings) into the Hybrid Programming Language so beginning programmers, and programmers who are working on applications that don't require manual memory management, can avoid that hassle. We didn't put it in this version because we intentionally wanted to expose that aspect of computer science to our prospective students.

Memory management in the current version is described on page 93 of the manual:

www.osmosian.com/instructions.pdf

Language processors, as you've mentioned yourself, are non-trivial programs. I don't think it's unreasonable to find that ours requires 18 simple sentences (12 in the compiler and another 6 in a library) to handle memory allocations in an operating-system independent fashion for every type that a Plain English programmer might care to define.

 

[Gerry Rzeppa]

Woohoo! Over 10,000 views on this thread!

 

[cabri]

Woohoo! Over 10,000 views on this thread!

Many are repeat visitors.

I visit this 2-3 times a day to see where the thread is going.

 

[Gerry Rzeppa]

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.

Yes.

Whatever you program in it, it will compile into its new version and be able to use it in later iterations.

Not quite. It is intended that the compiler itself remain relatively simple and stable. Whatever is programmed in Plain English remains in the libraries where those new types, variables, and routines are defined. Such libraries can be used selectively by Plain English programmers. So the language is extended into different application domains primarily by the addition of new libraries, and only secondarily by improvements to the compiler itself.

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.

My experience as a lifelong student of English and the people who speak it has convinced me that most of what most people think and say falls into two categories: (a) fixed, memorized grammatical forms with noun, verb, adjective, and adverb substitutions, and (b) idiomatic forms that are memorized in their entirely. Truly novel forms of speech are rare.

We don't expect the computer to be able to truly "understand" English -- we're not even sure such a thing is intrinsically possible. We're more interested in "Apparent Intelligence" than "Artificial Intelligence". That is, we simply want the computer to properly respond to the kinds of sentences that people in a particular computing community would typically use to describe their procedures to one another. (Similar to the way Apple's SIRI responds to the kinds of queries that the majority of iPhone users typically pose.) By making certain improvements to our compiler, but especially by adding appropriate and comprehensive libraries for various application areas, we think this can be achieved.

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.

We don't picture "the library" as a monolithic thing. We imagine different communities of Plain English programmers using different libraries, ideally suited to their local vernacular. Thus a teacher of beginning programming at, say, a third grade level, would employ one set of Plain English libraries (that include the types, variables, and support routines that third graders are likely to require). Another teacher at the junior high level would use those same libraries, plus others with more sophisticated routines. But a person engaged in 3D game programming would use different libraries altogether -- libraries specifically created to serve that particular community. And a monolingual person in, say, France, would program in Plain French using libraries created by and for native French-speaking programmers.

It won't magically be able to do anything more than what you program in it.

Of course not.

Which is exactly the same as in any other computer programming language available today.

Except that it avoids specialized syntax wherever possible, and is thus easier to learn and use. Easier to document and explain to others. Eminently accessible to beginners without sacrificing the power, convenience, and efficiency necessary for professional programmers (like my son and I) to write serious real-world programs like compilers and page editors.

We see Plain English (and our proposed Hybrid Programming Language) as things that simplify and unify of the art of programming. We're not revolutionaries, we're iconoclasts; we're not trying to overthrow anything, just clear out the inessentials. Case in point. We wanted a language that people could easily deal with, so we choose a native human tongue, English; and we needed a language that the computer could easily deal with, so we chose a native machine tongue, Intel machine code; and to make it clear that all the intermediate levels are inessential, we wrote our compiler to translate directly from the one to the other. That's not a revolution, it's a simplification. And here's an example of a routine with both languages in the same sentence:

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

That's a unification.

Your language doesn't have any mechanisms in place to properly identify libraries, scopes, variables, and anything else for that matter.

Our development system equates a directory with a project. All the libraries that appear in that directory are part of the project; all other libraries are not. Within a project, we distinguish between global and locally scoped variables; all types and routines are global to the project. And that's it. Simple, effective, and powerful enough to write the kind of programs we're interested in writing. Philosophically, the architecture we imagine is like that recommended by Kernighan and Richie back in the day: lots of little programs that can be used together, rather than huge, complicated, tightly-bound programs. (If only those schooled in the "C" tradition could get back to their roots!) But again, that's a simplification, not a revolution. We're intent on doing more with less.

 

[Markbnj]

I'm not going to try to reply to you point by point, Gerry. It reminds me of trying to have discussions with the Christian missionaries that came over to our town from the nearby bible college when I was a kid. Those conversations didn't go anywhere, and this one isn't going anywhere either. I'll try to put succinctly why I am not going to participate in round 2 of this debate with you any longer.

The bottom line is you don't know what you're talking about. I get your passion for your vision, but you're so profoundly, and if I may say so, disdainfully, disconnected from what it actually means to write real software that there's no basis for an informed discussion.

All of the examples you've posted, the ones you feel are non-trivial demonstrations of the power of your system, are nothing more than simple algorithms stated in your idea of what a useful syntax might be. It looks like pseudo code to me; the sort of thing we might jot down or go over in our minds when figuring out the set of steps needed to do something like insert a paragraph between two other paragraphs. Maybe you didn't make it up on the spot, and I apologize for that snipe, but it's still childishly over-simplified, and the fact that you think it isn't only reinforces that you really don't have the experience to form an opinion.

You say those examples are part of a "fully functioning" word processor. Fine, then show me how you create dialogs to allow a user to choose files to read and write. Not "Create the dialog," but how you establish the window, create the controls, relate input events back to code that can handle them, etc. Show me how you handle an undo buffer, character selection, applying and removing formatting, spell-checking, pagination, print formatting, import and export to other formats, page layout, tables, media, etc., etc.

The algorithms for inserting paragraphs and "adjusting" pages edges are not what programmers spend their time working on. Very often those things are self-evident. It's all the rest of the stuff that is required for an actual working piece of software, which after all has to interact with the machine, the network, the local file system, and the user, not just your compiler. And the same language and set of tools that we used to build all of the complicated functionality of a real word processor has to be able to be applied the next day to a spreadsheet program, a 3D game, or the control software for an elevator.

I said this at the end last time, and I'll say it again this time: your ideas are wrong. You're barking up the wrong tree. If you actually want to make programming significantly simpler you're going to have to invent computers that can understand what we mean. You'll never get there using ever larger "libraries" of mappings between english statements and compiled/assembled routines. It's not possible, and if it were possible it wouldn't be better than what we have.

I hope you get your family up to Ohio, if that's what you want. As for your participation here, that's up to you and the other members. As long as you post ostensibly about programming you're free to continue to do so. I don't have any further interest in the topic. I would suggest that you perhaps spend some time working in some modern languages other than your own. It will give you some perspective, and you'll come off a little less like a vacuum cleaner salesman storming a watchmaker's convention.

 

[Gerry Rzeppa]

It looks like pseudo code to me; the sort of thing we might jot down or go over in our minds when figuring out the set of steps needed to do something like insert a paragraph between two other paragraphs.

Exactly. Plain English "looks like pseudo code; the sort of thing we might jot down or go over in our minds when figuring out the set of steps needed to do something." Yet it compiles and runs. Which is pretty much what I said myself at the top of my initial post in this thread:

"Having programmed for many years in many languages, I often find myself thinking in a kind of natural language pseudo-code, then translating it into whatever language I'm working with at that time. So one day I thought, Why not simply code at a natural language level and skip the translation step?"

Maybe you didn't make it up on the spot, and I apologize for that snipe, but it's still childishly over-simplified, and the fact that you think it isn't only reinforces that you really don't have the experience to form an opinion.

Yet we were able to use that "childishly over-simplified" tool, conveniently and efficiently, to write an entire development system -- unique interface, simplified file manager, elegant text editor, hexadecimal dumper, native-code-generating compiler/linker, and wysiwyg page editor.

You say those examples are part of a "fully functioning" word processor.

Page-layout program. More like PowerPoint than Word. But yes, "fully functioning". We wrote our instruction manual using it (www.osmosian.com/instructions.pdf).

Fine, then show me how you create dialogs to allow a user to choose files to read and write. Not "Create the dialog," but how you establish the window, create the controls, relate input events back to code that can handle them, etc.

We believe a system that requires two different presentations of the file system (one on the desktop, one in a dialog box) is badly designed. Our unique interface and simplified file manager present the user with a single, consistent view of the file system. Each of our "workareas" (represented by tabs at the bottom of the screen) start off at the root of the file system. From there you can open a drive, a directory, or a file. When you open a file, you're automatically taken to the appropriate editor for that kind of file (unless you manually select a different editor -- for example, opening an executable as a hexadecimal dump or a saved document as text so you can examine our "markup" language). At any level but the editor level, files and groups of files can be selected contiguously or non-contiguously, and you can add, rename, duplicate, cut, copy, paste, delete, and get the size of any file selected. See pages 5-7 of the instructions (www.osmosian.com/instructions.pdf) for illustrations.

There are, nevertheless, times when a short "dialog" with the user is handy. All such dialogs in our standard interface allow only one parameter (to prevent programmer abuse) and temporarily overwrite only the menu and message area of the screen (to avoid obscuring the user's workarea). Such dialogs are trivial to create; when the "Print..." command is executed in our system, for example, this line of code displays the dialog necessary to get a copy count from the user (the default being a single copy):

Ask "Copies?" with "1".

The user's response is returned in a global variable called "the answer".

Show me how you handle an undo buffer...

Our text and page editors allow an unlimited number of undos/redos. The code to accomplish this is straightforward. In the page editor, for example, prior to any action we want to be "undoable", we insert this sentence...

Remember the page.

...and the page is copied to the "undo" list for that workarea. When the user executes the "Undo" command, the most recent entry is removed from the "undo" list, made current, and added to the "redo" list. A similar approach is used for text, except that each text "shape" on a page has it's own "undo" and "redo" lists whenever a text-editing activity is in progress. In fact, our text editor is essentially just a single text "shape" on a "page" of unlimited width and height.

character selection, applying and removing formatting...

Fundamental text editing routines are built-in to our Noodle library. You can read about them on pages 112-114 of the manual (www.osmosian.com/instruction.pdf). Here is the code for a typical routine, this one for inserting a character into a text (replacing any selection):

To handle an event given a text (printable key):
Remember the text with "insert".
Remove any selected bytes in the text.
Insert the event's byte into the text.
Wrap the text.
Scroll the text to the caret.

We qualify the "Remember" command in this case because we don't want an "undo" record for every single printable character typed; only for each contiguous string of such characters typed without some other intervening operation that would indicate an appropriate "break point" in a text-editing session.

...spell-checking...

Spell-checking is a command in our current version of our editors; we'll probably change that to something that happens as the user types in the Hybrid Programming Language version. Here's the top-level routine that checks spelling in a single text shape:

To find the next misspelling in a text given a flag:
Clear the flag.
If the text is nil, exit.
Loop.
Get a row from the text's rows.
If the row is nil, exit.
If the row's row# is less than the find anchor's row#, repeat.
Find the next misspelling given the row and the text and the flag.
If the flag is set, exit.
Repeat.

...pagination...

Pagination is not required in our page-layout facility because it's a page-layout facility, not a word processor. Pagination in our text editor takes place at print time.

...print formatting...

Print formatting is not required in our page-layout facility because it's wysiwyg: the presentation on the screen is identical to the presentation on the printer.

Print formatting in our text editor (particularly the color-coding of comments) is accomplished with this routine:

To print a row of a source at a spot:
If the source is nil, exit.
If the row is nil, exit.
Put 0 and 0 and 7-1/2 inches and the source's text's row height into a box.
Move the box to the spot.
Mask only outside the box.
Get a substring given the row and the source (commented part).
[ uncommented part ]
Slap another substring on the row's working string.
If the substring is not blank, put the substring's first minus 1 into the other substring's last.
Draw the other substring in the box with the black color and the source's text's font and the source's text's alignment.
[ commented part ]
If the substring is blank, exit.
Put the comment color into a color.
If the source's colorized flag is not set, put the black color into the color.
Get a width given the other substring and the memory canvas and the source's text's font.
Add the width to the box's left.
Draw the substring in the box with the color and the source's text's font and the source's text's alignment.

...import and export to other formats...

Text can be imported into and exported from both our text and page editors via the text clipboard (ie, with Copy and Paste).

Documents created in our page editor can be saved as PDFs. The code to accomplish this is, due to the ugliness of the PDF itself, rather lengthy. But here's a typical routine:

To convert a string to a pdf string:
Put "(" into the pdf string.
Slap a substring on the string.
Subtract 1 from the substring's first.
Loop.
Add 1 to the substring's first.
If the substring is blank, break.
If the substring's first's target is the left-paren byte, append "\(" to the pdf string; repeat.
If the substring's first's target is the right-paren byte, append "\)" to the pdf string; repeat.
If the substring's first's target is the backslash byte, append "\\" to the pdf string; repeat.
Append the substring's first's target to the pdf string.
Repeat.
Append ")" to the pdf string.

...page layout, tables, media, etc., etc....

Etc, etc, is right. The whole shebang is readily available for the asking from me (gerry.rzeppa@pobox.com) and on GitHub (https://github.com/Folds/osmosian). If you want to see more of the code, I recommend you seek out one of those sources.

The algorithms for inserting paragraphs and "adjusting" pages edges are not what programmers spend their time working on. Very often those things are self-evident. It's all the rest of the stuff that is required for an actual working piece of software, which after all has to interact with the machine, the network, the local file system, and the user, not just your compiler. And the same language and set of tools that we used to build all of the complicated functionality of a real word processor has to be able to be applied the next day to a spreadsheet program, a 3D game, or the control software for an elevator.

Sure. No problem.

I said this at the end last time, and I'll say it again this time: your ideas are wrong. You're barking up the wrong tree. If you actually want to make programming significantly simpler you're going to have to invent computers that can understand what we mean. You'll never get there using ever larger "libraries" of mappings between english statements and compiled/assembled routines. It's not possible, and if it were possible it wouldn't be better than what we have.

We already think it's better. And we've programmed significant systems both ways.

I hope you get your family up to Ohio, if that's what you want.

Thanks. From your lips to God's ears.

As for your participation here, that's up to you and the other members. As long as you post ostensibly about programming you're free to continue to do so. I don't have any further interest in the topic.

Thanks again. Sorry to see you go.

I would suggest that you perhaps spend some time working in some modern languages other than your own. It will give you some perspective, and you'll come off a little less like a vacuum cleaner salesman storming a watchmaker's convention.

I recently did spend some time working with a "modern language". That thread is here:

http://forums.anandtech.com/showthread.php?t=2410448

Writing that program in Plain English was a dream. Converting it to JavaScript was painful. As I pointed out to another poster above, I don't see how the JavaScript syntax:

function Story() { this.title=''; this.prolog=''; this.scenes=[]; this.epilog='' }

is an improvement over the Plain English version:

A story is a thing with a title, a prolog, some scenes, and an epilog.

 

[smackababy]

Exactly. Plain English "looks like pseudo code; the sort of thing we might jot down or go over in our minds when figuring out the set of steps needed to do something." Yet it compiles and runs. Which is pretty much what I said myself at the top of my initial post in this thread:

"Having programmed for many years in many languages, I often find myself thinking in a kind of natural language pseudo-code, then translating it into whatever language I'm working with at that time. So one day I thought, Why not simply code at a natural language level and skip the translation step?"

I really don't mean for this to be a personal attack, but "programming for many years in many languages" just doesn't past muster, in my eyes. At what level were you actually doing this programming? In every instance of me doing pseudo code and taking it back have I thought "this would be great to program in!". It never goes to the level of detail and implementation required for a real business application.


Also, I find it strange nobody has even gotten to the maintenance problem with your code. Plain English is incredibly difficult to parse and edit. Don't believe me? Ask an editor for any publication or book. There are entire fields dedicated to just this and nothing content related.

 

[crashtech]

Also, I find it strange nobody has even gotten to the maintenance problem with your code. Plain English is incredibly difficult to parse and edit. Don't believe me? Ask an editor for any publication or book. There are entire fields dedicated to just this and nothing content related.

But programming languages don't have these difficulties? No need for extensive commentary and debuggers in your world?

That said, I'm not sure how natural the "Natural English" would seem once it gained the level of specificity that would be required to write truly complex code. Seems like it, too, would end up needing extensive comments to keep things understandable.

 

[Merad]

But programming languages don't have these difficulties? No need for extensive commentary and debuggers in your world?

Every programming language has a finite set of rules defining its grammar (otherwise computers couldn't parse it). Granted in some cases that's a very large set of rules (C++), but nothing compared to English. Yes, you can find rules for English grammar, but even the experts often disagree: google grammar myths for just a few examples.

Programming languages also present information in a more compact manner than english. Yes, it requires learning to understand it, but when you're dealing with real world applications that are anywhere from hundreds of thousands to tens of millions of lines of code, you want a syntax that isn't verbose, because you're wasting a lot of time reading.

Consider this line from one of Gerry's posts:
"Draw the substring in the box with the color and the source's text's font and the source's text's alignment."
20 words

In most programming languages this would be expressed in a manner like:
box.draw(substring, color, font, alignment)
6 words

Or another example:
If the source's colorized flag is not set, put the black color into the color.
15 words

In a typical programming language:
if (!source.colorized()) color = black
5 words

Overall "natural english" appears to be 2-3x more verbose than typical programming languages. For a toy language or teaching language of course that doesn't really matter, but it's Very Bad for real world usage.

 

[Gerry Rzeppa]

I really don't mean for this to be a personal attack, but "programming for many years in many languages" just doesn't past muster, in my eyes. At what level were you actually doing this programming?

I started out programming in COBOL for Kmart Corporation. Then PL/I at the same place, then IBM 370 assembler in the technical support group there. Then I was assistant database administrator working with Cincom's TOTAL database management system, and later IBM's IMS. Then I joined a consulting firm and worked with all those same languages on major systems at General Motors, Ford, Henry Ford Hospital systems, Exxon, EDS, etc.

Around 1980 I founded my own company, Relational Systems Corporation, and started teaching my own database design methodology (www.era-sql.com) that is still widely used today. I also started teaching SQL classes to compliment the database design stuff. Financially, that was the peak of my career: I was busy year-round charging $1200 a day for consulting, and up to $3,500 a day to teach on site (and that was in the 1980's). We also had our own classroom with 32 seats that was filled, at least twice a month -- every time we offered a class (tuition was $600 a head). I worked on legal systems, logistics systems, patient tracking systems, accounting systems, etc. Major systems processing hundreds of millions of dollars' worth of goods and services. And closely with the folks at Oracle -- when there were only six of them in the whole company!

After that, I started doing a lot of research on my own dime. My mathematically-normalized relational database design process evolved into a grammatically-normalized process called LOGIC, and that, in turn, evolved into a stand-alone "pagebase" combining wysiwyg interface technology with the steps beyond relational pioneered by Mikhail M. Gilula (http://www.amazon.com/dp/0201593793/). We called that Perspective and still use it ourselves today to do all our accounting.

I also programmed MIDI programs using Applesoft Basic and 6502 assembler on the Apple II line of computers. And systems for the handicapped on the Macintosh using both 68000 assembler and Pascal. A multiuser point of sale system for restaurants for which I developed both the hardware and the software (in Z80 assembler and Pascal). And a lot of ad hoc applications for the Mac using ZBasic and AppleScript.

When my elder son got interested in programming I taught him C and Pascal, and then we started developing our own languages. AIQ was the forerunner to Plain English, and Plain English has evolved through at least three major versions since then (the CAL-1000 series, the CAL-2000 series, and the CAL-3000 series that we are using now: all written in Plain English). Currently my son makes big bucks programming in Plain English, JavaScript, and Go. He still likes Plain English best.

In every instance of me doing pseudo code and taking it back have I thought "this would be great to program in!". It never goes to the level of detail and implementation required for a real business application.

All I can say is that our Plain English "pseudo code" does "go the the level of detail and implementation required for a real business application" even though our development system is just a prototype. Compilers and page-layout programs are real-world applications. I've done lots of "real business applications" in the past 40 years and I assure you, none of them were as complex as our development system. Bigger, sure. Harder, no.

Also, I find it strange nobody has even gotten to the maintenance problem with your code. Plain English is incredibly difficult to parse and edit. Don't believe me? Ask an editor for any publication or book. There are entire fields dedicated to just this and nothing content related.

You might as well say that COBOL applications are hard to maintain. They're not. Simple, English-like languages are the easiest to learn and maintain. That's why COBOL has remained a viable language to this day. And Plain English is way better: syntactically smaller (with keywords like A, AND, and THE, instead of "IDENTIFICATION DIVISION" -- yet practically larger (since programmers can define their own vocabulary and grammar for each application domain).

 

[Merad]

I started out programming in COBOL for Kmart Corporation. Then PL/I at the same place, then IBM 370 assembler in the technical support group there. Then I was assistant database administrator working with Cincom's TOTAL database management system, and later IBM's IMS. Then I joined a consulting firm and worked with all those same languages on major systems at General Motors, Ford, Henry Ford Hospital systems, Exxon, EDS, etc.

No offense but, while it sounds like you certainly have a significant amount of experience, it also sounds like your experience is all 20+ years out of date. Frankly, that's also evident in your idea of what constitutes an "elegant" IDE.

 

[Gerry Rzeppa]

No offense but, while it sounds like you certainly have a significant amount of experience, it also sounds like your experience is all 20+ years out of date.

Unless the industry took a wrong turn about 20 years ago and needs someone to get it back on track, of course.

Some things get better with time; some don't. When I was young, all the TV shows filled the screen and all the captions appeared in the right places. Now some have black bars on the top, some on the sides, sometimes the captions fall off the bottom, and I often have to press the "pixel resolution" button on the remote --up to seven times -- to get a view that doesn't distort the proportions or cut off something important. Why? Because somebody along the way forgot some fundamental principles of design that don't change with the passage of time; that standards aren't necessarily bad, and that in some things, they're truly necessary. I think the TV industry could use a bit of "out of date" wisdom from 20 years ago.

And there are many other such examples. Automobiles too complex to maintain yourself, video recorders that nobody knows how to program, etc. But here's my favorite example: post editors like the one on this very forum. Edit in this box, preview up there, then go back to the first box to make corrections; repeat as necessary. Good God! My 1985 Macintosh (with just 128 kilobytes of memory) was more user-friendly.

Frankly, that's also evident in your idea of what constitutes an "elegant" IDE.

If you don't think our IDE is elegant, then you simply don't understand it. Write me directly and I'll explain it to you: gerry.rzeppa@pobox.com. And I won't even charge you my usual $1200 a day!

 

[Gerry Rzeppa]

I'm not sure how natural the "Natural English" would seem once it gained the level of specificity that would be required to write truly complex code. Seems like it, too, would end up needing extensive comments to keep things understandable.

What do you mean by "truly complex code"? I've been programming for 40 years and haven't seen any code that needed to be more complex than our compiler or page editor.

I've seen bad code that was very complicated, sure; but that kind of thing gets fixed by thinking more clearly about the problem, not by switching languages.

And I've see good code that was still a mess because the overall design of the system was faulty; that has to get fixed earlier in the process.

But I've never seen any code that wasn't reasonably simple once the problem was properly decomposed into a series of small and well-defined steps. And a language like Plain English helps to make that happen; insists upon it, in fact, by providing a sufficient but very small tool set, and by not allowing unnecessary complications like nested loops and nested ifs and unnatural objects.

 

[werepossum]

Maybe, but we're not talking about tweaking an effective strategy here. This subject first came up over a year ago when Gerry posted a link to a zip file of his compiler and I removed it. Since then he has received a lot of good advice about how to approach a project like this and he has ignored all of it.

He allowed the source to be posted to github and then removed the project when he didn't like the comments he received on the first commit, replacing it with a $450k indiegogo project. Yes, $450k to develop a programming language. Bjarne Stroustrup did most of the first versions of C++ in his spare time at work for AT&T.

He has continued to resort to abstractions, generalities, philosophy, and unproven claims, all seasoned with a more than liberal dash of missionary zealotry and single-minded obstinacy. Yes, I recognize that this could be genius. I don't immediately write off nuts when I meet them. But this has gotten ridiculous and almost comedic. If he has a drop of programmer anywhere in him he can open up his stuff and show people how it works, communicate with practitioners in their language and on their level, with evidence that they can respect, or take a hike. I really don't have a preference at this point which path he chooses.

Certainly fair points.

The only thing I'm willing to take on faith is God. When it comes to computer science, I need a demonstration of useful technology not, "take a look at this, it's so cool!"

That too is a fair point. I think though that as a programmer's he'll have a hard time demonstrating useful technology to you simply because the things at which his approach supposedly excels are things YOU don't need; you already know better ways to accomplish complex projects. If I understand him correctly - and I may not, as my programming is just as much out of date and far shallower - his point is that IF programmers were taught Natural English programming, then that would also be their preference in programming in addition to being better for beginning programmers. Certainly you'd have to think more about some things, and your pseudocode would be a lot more in depth, but once your pseudocode was finished you'd essentially be finished writing the program. You might have to make some adjustments if the results aren't exactly what you intended, but you wouldn't need a debugger because debuggers deal with language formatting.

That's not someone I'm equipped to judge. I can certainly see the attraction of the concept, and I also can see where Natural English programming would make things more difficult; I'm just not learned enough to judge the balance.

 

[Gerry Rzeppa]

If I understand him correctly - and I may not, as my programming is just as much out of date and far shallower - his point is that IF programmers were taught Natural English programming, then that would also be their preference in programming in addition to being better for beginning programmers. Certainly you'd have to think more about some things, and your pseudocode would be a lot more in depth, but once your pseudocode was finished you'd essentially be finished writing the program.... I can certainly see the attraction of the concept, and I also can see where Natural English programming would make things more difficult...

That's a fair assessment, from my perspective. Keep in mind, though, that while we believe that most of of what most programs do can be most easily written in a natural language syntax, we are just as certain that some things programmers want to say can be more easily expressed in formulas, or graphics, etc. Which is why we propose "Hybrid Programming" as the next step in our research:

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

Here, for example, is a Plain English fahrenheit to celsius converter as a kid might code it:

To convert a fahrenheit temp to a celsius temp:
Put the fahrenheit temp into the celsius temp.
Subtract 32 from the celsius temp.
Multiply the celsius temp by 5.
Divide the celsius temp by 9.

And here it is as an experienced Plain English programmer might code it. Note the use of nicknames (eg, "celsius" for "celsius temp"), and that mathematical precedence is strictly left-to right in Plain English):

To convert a fahrenheit temp to a celsius temp:
Put the fahrenheit minus 32 times 5 divided by 9 into the celsius.

Since ratios are a standard numerical type in Plain English, the programmer could also have said:

To convert a fahrenheit temp to a celsius temp:
Put the fahrenheit minus 32 times 5/9 into the celsius.

Where 5/9 is a ratio, not a division instruction. All of those versions actually compile and run.

Now here is the obvious Hybrid version, with the routine header (which also serves as a comment) in Plain English, and the calculation in standard "computer dialect" mathematical notation:

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

Note that the Hybrid compiler assumes letter names for the variables based on their full Plain English names. If other names were desired or a naming conflict arose, the programmer could either use the Plain English names, like this:

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

Or the programmer could explicitly assign short names to the variables:

To convert a fahrenheit temp to a celsius temp:
Let x = the fahrenheit temp.
Let y = the celsius temp.
y=(x-32)*5/9

This last approach would only be worthwhile, of course, when the formula was complex enough to justify the required variable definitions above it.

Our thought is that the programmer should be able to write the solution as it most naturally occurs to him or her, without really thinking about syntax. We believe Plain English is a big step in that direction, and that Hybrid Programming is the next logical step after that. Note that it's relatively trivial to add "special syntax snippets" to a Plain English compiler; it's a much bigger deal to extend, say, a C++ compiler to support a Plain English framework.

 

[Merad]

Unless the industry took a wrong turn about 20 years ago and needs someone to get it back on track, of course.

Based on your comments in this thread, you seem to have almost no knowledge of modern programming aside from a bit of javascript. You're certainly entitled to your opinion that it's "off track", but people aren't going to take you seriously when you literally don't know what you're talking about.

If you don't think our IDE is elegant, then you simply don't understand it.

As Mark has already mentioned a few times, your quasi-evangelical response to criticism isn't helping you at all. We went through my complaints with your editor back when the topic was first posted; I don't think rehashing them will accomplish anything. IIRC, you basically dismissed all of them with some variation of you just don't understand.

 

[Gerry Rzeppa]

We went through my complaints with your editor back when the topic was first posted... you basically dismissed all of them with some variation of "you just don't understand".

An elegant solution to one problem may be a very inelegant solution to another. Hammers are great with nails, not so good with screws. To judge the elegance of a particular design, we must first understand the goals of that design.

Our overall goal was to make sure our interface would be (a) simple and friendly enough for first-time programmers (such as children at a grade-school level), yet (b) convenient and powerful enough for seasoned programmers (such as ourselves) who wanted to write programs like native-code generating compilers and wysiwyg page-editors. This two-pronged overall goal led to the following design decisions (among many others):

1. Take over the entire screen (a) to remove all unnecessary distractions, not just for the sake of the beginner, but for ourselves as well; (b) to insure that our system would look the same on all operating systems and versions of those operating systems; and (c) to simplify and unify the system's documentation.

2. Clearly distinguish foreground and background elements of the interface. Keep interface elements simple and functional, with minimal or no decoration. Use only black, white, and various shades of gray for interface elements so colors in the user's data will stand out more clearly.

3. Employ a built-in system font that is (a) available on all operating systems; (b) proportionally spaced; (c) easy to read but reasonably dense; and (d) appealing to children. The font should also stand as a constant reminder to the experienced programmer that programming is fun.

4. Provide "tabbed" workareas so (a) the experienced programmer can have multiple files open simultaneously, while (b) the beginner will not be burdened with positioning, sizing and layering overlapping windows.

5. Fix the position of key interface elements (a) so they can serve as "anchor points" for educators, and (b) can be viewed and manipulated by experienced programmers without undue conscious thought.

6. Eliminate all unnecessary controls and widgets such as radio buttons, check boxes, scroll bars, and complex dialogs.

7 Arrange menu commands alphabetically rather than topically. More like the index of a book (where people most often go when they want to find something) rather than a "table of contents" (which is a useful organization only when one first surveys a text or program). Allow functionally equivalent commands to be listed under different names (such as "Exit" under "E" and "Quit" under "Q").

8. Provide a single, unified view of the file system (rather than the "one view on the desktop, another in the a dialog box" approach taken by most systems).

9. Include multiple clipboards for different kinds of entities, including at least (a) files, (b) pages, (c) elements of various kinds on pages, and (d) text.

10. Allow for unlimited "undo" and "redo" operations.

11. Use a common text editing facility everywhere in the system, including but not limited to (a) controls and dialogs; (b) text files; (c) documents; etc.

12. Use an incremental find facility, similar to the "LEAP" system pioneered by Jef Raskin at Apple, for locating text in files, dumps, and documents.

13. Allow the CTRL and ALT keys to be used interchangeably, where possible, to (a) shorten the learning curve for beginners, and (b) simplify keyboarding of menu shortcuts, etc.

14. Supply a simply organized built-in color palette that allows for both (a) easy visual search, and (b) simplified naming of distinct colors. A sample of our palette, with pertinent remarks, appears below.

15. Make sure the system can start up and be ready to go in less than a second.

16. Code the entire system in Plain English (a) for educational purposes, and (b) to insure that the interface has the same look and feel on all operating systems.

The resulting interface looks like this:

Note the alphabetical menus across the top. (All the letters appear all the time; the "..." is simply to keep the images narrow for posting.) Note also the fixed message area in the top right: this area is used for "status" messages only; error messages are handled differently (as described below). Note, finally, the workarea tabs at the bottom of the screen; workareas can be rearranged simply by sliding the tabs left and right.

Error messages temporarily overwrite the menu area (so they don't obscure the user's code, pages, etc), and typically appear in red (this is one of the few uses of color in the standard interface):

Error messages are modal and can be dismissed by clicking the "M'Kay" button with the mouse or hitting the Escape or Enter key.

All dialogs are modal and allow only a single response per question; they also overwrite the menu area and include appropriate command buttons at the far right:

Each workarea is initially positioned at the top of the file system showing all available devices:

When you double-click a device (or select it and use the "Open" command) the top-level directories and files on that device are shown. You continue "digging" until you find the file of interest, and then open that. The default open procedure examines the file and activates the appropriate editor (text, document, etc). You can also force a file to be opened by a particular editor (say, an executable you want to examine as a dump, or a document you want to open as text so you can see our Osmosian "markup" language) by using the specific "Open and dump" or "Open as text" commands.

Program text in the editor looks like this:

Comments are color coded so the programmer can quickly and easily see which parts of his code are currently included in a build; this is the only color-coding allowed in Plain English code.

When you open a document, our page editor first shows you the "edges" of the pages, one line per, with the title and the page number:

Pages can be added, cut, copied, duplicated, pasted, and deleted, singly or in groups, in this view. When you open a page, you get the wysiwyg view:

Each page can contain vector graphics of various kinds (circles, ellipses, squares, rectangles, rounded squares and rectangles, arbitrarily complex polygons, smoothed polygons, text in any font, size, and style, and photographic images imported from most standard file types (jpg, png, etc). The page editor is non-modal: you don't select a tool and then draw an object, but rather create an object (via menu command) and then manipulate it into the appropriate size, shape, and position with the mouse. Other functions available in our page editor have been described in a previous post.

Colors can be applied to the border and the fill of any shape on any page, and to text. Our color palette includes clear, white, and black, seven shades of gray, and all the colors of the rainbow arranged as reds, oranges, yellows, greens, blues, and purples:

The programming language recognizes the center color in each row as the "norm", say, "red" or "blue". The three shades to the left are referenced with the adjectives light, lighter, and lightest, respectively; the shades to the right use the adjectives dark, darker, and darkest.

And that's the gist of it. An elegant solution to a specific and unusual problem. Simple and appealing for beginners: we've used it to teach all kinds of people, from young children to old ladies, how to program in Plain English. Yet convenient and powerful enough for pros: we used it ourselves to write the whole system itself: 25,000 sentences of fully functional Plain English code -- and believe me, had it lacked anything we really needed or wanted, we would have quickly added it in.

 

[BoberFett]

This has to be one of the most elaborate pranks ever.

 

[Merad]

An elegant solution to one problem may be a very inelegant solution to another. Hammers are great with nails, not so good with screws.

I'm not even sure what this means in the context of your post, considering that you basically go on to say that your editor does everything and does it all perfectly.

Anyway, if you think that we are unique in our criticisms of your language, editor, and methodologies, I strongly encourage you to post on places such as the programming subreddit or Hacker News so that you can get more feedback from professional developers.

 

[Crusty]

Yes, please post this on Hacker News. I would love to read the discussion there.

 

[Gerry Rzeppa]

I'm not even sure what this means in the context of your post, considering that you basically go on to say that your editor does everything and does it all perfectly.

More accurately, "everything we as developers and our students need it to do, with reasonable convenience and efficiency." Of course it can be improved; what can't? But the fact that we've used it to develop such a useful, varied, and non-trivial system, and the fact that we've used it to teach others how to program, attests to it's efficacy. Say what you will, the thing works, for us and others.

Anyway, if you think that we are unique in our criticisms of your language, editor, and methodologies, I strongly encourage you to post on places such as the programming subreddit or Hacker News so that you can get more feedback from professional developers.

I put a link on reddit (http://www.reddit.com/r/controversial/comments/2l8pcq/plain_english_and_hybrid_programming/) about a month ago, pointing here (so I wouldn't have to repeat myself). We're well aware that views like yours are shared by others; we simply contend that such views judge our system out of the intended context. After all, we have lots of first-hand experience with it actually working, and working well, for ourselves. And we have letters from lots of others that say they're impressed with it too:

"A minor work of genius" - Aaron Gray

"Well I love it!!! Very very unique... Are you looking for an investor?" - Anthony Nystrom

"Good lord, that has got to be one of the strangest things I've ever seen... It certainly has some merit, as you can describe what you want to do 'naturally'. I'll keep playing with it." - Marc Clifton

"Interesting; the source code is easy to read" - Peter Norvig

"It looks like an interesting tool for those stuck in Gatesburg." - Neil Freeman

"Thanks Sir. People like you are giving different view to whole thing. Best Luck." - Vijay Sambhe

"If I ever were to use it seriously I would definitely contribute to your project; at this point I was only allaying my curiosity." - Paul van der Walt

"To some extent, I think I owe you an apology. I have been baiting you horribly on CP" - Mystery CodeProject Member

"The interface is pretty cool and would work well for a quite a few apps... All in all a good job... I can see a great market for beginner programmers trying to understand concepts" - Andrew Bleakley

"I have to say I'm quite impressed... keep up the good work!" - Ian Harrigan

"What a wonderful piece of work... the concept is noble, the execution brilliant, the whole thing is quirky and brilliant" - Joe Cherian

"I do like the font and the simplicity." - Edbert P.

"A very unique idea." - Dan Pronovost

"Interesting." - Chris Austin

"Thats a pretty cool thing you have produced." - Chris Meech

"May I know which font do you use. It’s very beautiful." - Weixiao Fan

"I've seen the sourcecode and it's nothing short of impressive." - elShoggotho

"I am really enjoying my experience with the Plain English compiler. The programs look like well-documented code without the code." - Joel Ashford

"The demo says a lot about the project and I was amazed by it." - V. Girish

"Your manifesto is bang on target and you are right about the fact that we won't go far using traditional approaches." - V. Girish

"I think your work is not so much a 'minor work of genius' as it is a major work of genius. Don't stop." - Paul Frenger

"If that source code was indeed used to create the [sample program] executable, it is indeed pretty impressive." - Nishant Sivakumar

"Frankly, [Gerry's] the only person I know who's achieved what he has on his own power, dime and time. It's truly a lifetime achievement." - Rex A. Winn, Jr.

"While it's definitely a niche market, the work he has done with it is truly amazing." - Pete O'Hanlon

"I respect him a lot, he truly is a living legend. There is so much to learn from him. I won't be surprised if tomorrow he is nominated for a noble prize and get it." - Rajesh Lal (Quartz)

"I read his document, which talks about his ideas and approach of taking his language to next level and was impressed. I support him and respect him for his language." - Tarakeshwar Reddy

"I've been using the Plain English language for a couple of weeks now and I must say that it is precisely what I was looking for... I don't need to worry about fighting any needless battles and I can just get on with programming." - Martin Pollard

"An astonishing work, genius! I was looking for something like this for many years. In addition, the Cal-3040 produces fast code. Congratulations! Keep it up. PS: Now I have 'deprogram' my thinking when writing code. I'll have to relearn how to think normally!" - Antonio Navarro Andreu

Different strokes for different folks, Merad. If our work doesn't address your particular needs, I'm okay with that. No program can be all things to all men.

 

[smackababy]

Gerry, what some random people have said means nothing. Also, most of your quotes mean nothing an lend zero to the merit of your project. Some guy saying "Interesting" is stupid.

Very first name on your list... A center in the NBA. http://lmgtfy.com/?q=aaron+gray

The second quote seems as if someone was willing to invest. Obviously, they didn't.

And I am done. You've demonstrated enough in my mind to write you off completely. You've yet to produce anything beyond "do this" or "write that" code samples and still haven't shown any insight into real world problems having to handle this. You also seem to be against OO, and coupling an abandonment of OO with verbose paragraphs to describe things in sentences, your code on a real project is going to be unmanageable. Debugging is just incredibly painful when I have to read Moby Dick to find out where something happens and where I should change it.

 

[Gerry Rzeppa]

This has to be one of the most elaborate pranks ever.

Not a prank at all. Using nothing but our Plain English development system I can simply and easily teach a kid or adult, who doesn't know how to program, about fundamental programming concepts: the difference between source code and executable code; hexadecimal arithmetic; about data types, both simple and compound; about data structures like lists and hash tables; about variables local and global; about routines and their parameters; about sequential instructions, conditional instructions, and loops; about inline expressions and function calls; about conversational applications and event-driven architecture; how to enter and run and test and debug a program; etc.

And I can further show that student how to develop his or her own graphical user interface, from blank screen to finished product (including things like tabs, menus, short-cuts, buttons, palettes, dialogs, text, etc). How to write a file manager; a hex dumper; a text editor (including autoscrolling, incremental find, and a dozen other handy features); a wysiwyg page layout program (including vector graphics, bit-mapped graphics, and all kinds of text, with unlimited levels of undo/redo); even a native-code generating compiler/linker -- for the very language the student has been using from the start!

All that and much more, and all in Plain English, without leaving the comfortable confines of our simple and friendly development environment. Here is the instruction manual that comes with the system:

www.osmosian.com/instructions.pdf

Tthe whole shebang, including source code, is available for Windows, free for the asking: gerry.rzeppa@pobox.com