BACKGROUND

Some years ago my elder son and I developed a Plain English programming language and development system in the interest of answering the following questions:

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

2. Can natural languages be parsed in a relatively "sloppy" manner and still provide a stable enough environment for productive programming?

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

We can now answer each of these three questions, from direct experience, with a resounding "Yes".

PRINCIPLES OF OPERATION

Our parser operates, we think, something like the human brain. Consider. A father says to his baby son:

"Want to suck on this bottle, little guy?"

And the kid hears,

"blah, blah, SUCK, blah, blah, BOTTLE, blah, blah."

But he properly responds because he's got a "picture" of a bottle in the right side of his head connected to the word "bottle" on the left side, and a pre-existing "skill" near the back of his neck connected to the term "suck". In other words, the kid matches what he can with the pictures (types) and skills (routines) he's accumulated, and simply disregards the rest. Our compiler does very much the same thing, with new pictures (types) and skills (routines) being defined -- not by us, but -- by the programmer, as he writes new application code.

SAMPLE CODE

A typical Plain English type definition looks like this:

A polygon is a thing with some vertices.

Internally, the name "polygon" is now associated with a type of dynamically-allocated structure that contains a doubly-linked list of vertices. "Vertex" is defined elsewhere (before or after this definition) in a similar fashion; the plural is automatically understood.

A typical routine looks like this:

To append an x coord and a y coord to a polygon:
Create a vertex given the x and the y.
Append the vertex to the polygon's vertices.

Note that formal names (proper nouns) are not required for parameters and variables. This, we believe, is a major insight. My real-world chair and table are never (in normal conversation) called "c" or "myTable" -- I refer to them simply as "the chair" and "the table". Likewise here: "the vertex" and "the polygon" are the natural names for such things.

Note also that spaces are allowed in routine and variable "names" (like "x coord"). This is the 21st century, yes? And that "nicknames" are also allowed (such as "x" for "x coord"). And that possessives ("polygon's vertices") are used in a very natural way to reference "fields" within "records".

Note, as well, that the word "given" could have been "using" or "with" or any other equivalent since our sloppy parsing focuses on the pictures (types) and skills (routines) needed for understanding, and ignores, as much as possible, the rest.

At the lowest level, things look like this:

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

Note that in this case we have both the highest and lowest of languages -- English and machine code (albeit in hexadecimal) -- in a single routine. The insight here is that (like a typical math book) a program should be written primarily in a natural language, with appropriate snippets in more convenient syntaxes as (and only as) required.

THE TASK AT HAND

I'm looking for an (open minded) Linux programmer to convert this program to run on Linux.

The program consists of about 20,000 lines of Plain English source code and includes a unique interface (that will look exactly the same on Linux as it does on Windows), a simplified file system viewer, an elegant text editor, a hexadecimal dumper, a native-code-generating compiler/linker, and the wysiwyg page layout facility that was used to produce the documentation. Most of the code (for example, the wysiwyg page layout facility) will not have to change; the system-specific portions of the program are isolated.

You can get the whole shebang, including the source code, here: www.osmosian.com/cal-3040.zip . Start with the PDF in the "documentation" directory and before you go ten pages you'll be recompiling it in itself (in less than 3 seconds on a bottom-of-the-line Windows machine from Walmart).

Interested parties please respond directly to gerry.rzeppa@pobox.com

Thanks!

To the OP: are you serious ? Have you ever heard of structural ambiguity in human languages ?

Explain to me the meaning of "metal bird cage" for starters.

Yes, I'm serious. One doesn't write 20,000 of code on a single subject if one isn't serious. But that doesn't mean I don't have a sense of humor. Did you hear the one where Bill Gates and Linus Torvalds walk into a bar?

Yes, I've heard of structural (and many other kinds of) ambiguity in human languages. The question we wanted to answer is whether such ambiguities pose a practical problem in systems such as ours. The answer -- and I'm speaking from first-hand experience here -- is "Nope". Our compiler was easy to write (except, of course, for all the Windows and Intel crap) and is remarkably reliable.

The meaning of "metal bird cage" in our system would depend on how the application programmer defined the type, and the routines that manipulate it.

There's a story of how Henry Ford asked one of his engineers to figure out how much gasoline an oddly-shaped fuel tank would hold. While the engineer was struggling with his calculations, Henry filled the tank with water and poured the contents into a graduated cylinder. After reading off the correct answer, he fired the engineer. The moral, which I'm sure you've guessed, is that sometimes complex problems can be turned into trivial ones simply by taking a different approach.

- the item in bold indicates you are not writing in English.

And regarding "metal bird cage" - way back in the USSR years, in Lithuania, I once saw in a pedestrian street trees - so far so good.

One of the tress was killed by fire - probably vandals, but it's not the point.

The authorities decided to keep the tree in place, among still alive ones.

But you know, birds sometimes "land" on trees, this is how the things are. But birds prefer alive/livings trees.

So the authorities solved that problem too - they installed metal birds on the branches of that dead tree.

- sounds truly suspicious. A compiler has very little to do with the underlying CPU and OS.

Rather, there is a frontend for your new language, the frontend produces some intermediate representation, and that representation undergoes optimizations and is finally converted into assembly or machine code directly. Or, say, into "C" or C++.

In your shoes I would use LLVM infrastructure.

In my experience it is very important to define which chair is being talked about. There's usually a long description about how the chair is or where it is. I think it would be easier to label the chair.
I notice that on many farms the livestock are not called "cow" but are either numbered or named.
I also tend to find that, for example, handling of modular arithmetic is difficult to define in terms that make it easy to convey in English terms. Similar goes for type conversion and signed numbers.

Our compiler understands, not whatever might be floating around in somebody's head, but whatever the programmer has told it. The syntax takes the form of typical English language sentences. So I tell the compiler that "A polygon is a thing with some vertices." And in so doing I'm explaining what "polygon" means to me, in the context of the program that I'm writing. In a grammatically-correct English language sentence. That's all we mean by "programming in English."

True. But a complete IDE (desktop, file manager, text editor, hex dumper, native-code-generating compiler/linker, and wysiwyg page layout facility) like our program must interact with both OS and CPU in many places and many ways. Only about 4,000 of the 20,000 lines are compiler-specific.

It seems that you're greatly misunderstanding both our intent and our prototype. And it doesn't sound like you're contemplating the conversion to LINUX. So I bid you farewell; you may have the last word if you please.

1 members found this post helpful.

As somebody who has grown up in the land where English was first tried I have no idea what "a grammatically-correct English language sentence" is in this context.
I'd be willing to bet that most of the posts in this thread are not correct English and that all are open to misinterpretation.
Which table? How will you ensure that your implementation of set works correctly?

So how many of the chairs in your house have proper names? And how have you gotten by for so long without naming the others? In any case, I've programmed both ways and much prefer the more natural approach. But see below...

True. But note that sometimes it's "How is Bessie doing today?" and at other times it's "Did you put the cow in the barn?" Likewise, our programming language allows for proper names, but doesn't demand them. Depending on the context, in a Plain English program, the bovine in question might be called "Bessie" -- or she might be called "the cow". Nice to have a choice.

You've probably noticed that math books, for example, are written primarily in a natural language (like English), and drop down to other modes of expression (like graphs and formulae) when they're more convenient. Likewise, a Plain English sentence might say:

Put sqrt(a^^2+b^^2) into the length.

Again, nice to have a choice. And note that it's much easier to extend a language like ours to include snippets of specialized syntax, than it is to extend specialized languages to include an all-emcompassing natural-language wrapper above them.

Our compiler understands the "dialect" of the programmer who is using it. If he says, "ain't got" instead of "doesn't have", the compiler accepts that.

The theory, folks, is not in question here. The program works. It is a non-trivial 20,000-line chunk of code (including desktop, file manager, text editor, hex dumper, native-code-generating compiler/linker, and wysiwyg page layout facility) and we coded it entirely in (an earlier version of) itself with both convenience and efficiency. In other words, know from first hand experience that writing code in English is both easy and fast.

The question is, Do any of you folks want to take a shot at making the thing run on LINUX?

There is not choice. When I refer to "The chair with the cat hair on it.. No... The one with the black hair on it..." I'm using a key attribute which is unique to that chair. All databases work like this -- you *can* use something that's not the key attribute to find something but it can, and will, fail spectacularly if you rely upon it.
The same follows for the rest.
I think mathematics ought to be written in mathematics. I'm not very good at it but I've never seen it expressed in "natural language" properly. It's not by accident that mathematics uses something other than natural language -- it has been around for a while...

Have you bothered yourself with considering my "metal bird cage" example ? Specifically, does it mean for you compiler "a cage made of metal and intended for birds" or "a cage made of G-d knows what intended for birds made of metal" ?

My "metal bird cage" is a grammatically correct English example. Exactly because I know limitations of human languages I would not like to use a compiler that understands English.

Regarding your code. If people think cross-platform, they write code in a cross-platform manner from the getgo, using a cross-platform toolkit like Qt or wxWidgets. The mere fact that you have an issue of porting your GUI part to other platforms suggests poor architectural thinking.

- oh G-d, yet another text editor. What is the need in yet another text editor ?

...

All in all, what problems are you trying to solve with your language and compiler ? Language design in general is a tough problem, but, luckily, it's a mature area of knowledge.

So, is your new language just a kind of syntax sugar, or it also resolves in yet unknown way some language design problems ?

Are you aware of, say, https://en.wikipedia.org/wiki/Camlp4 and http://people.csail.mit.edu/mikelin/ocaml+twt/ (no, I don't like Python, but it's a good example of what can be done to an existing language regarding syntax sugar - if one of your goals is syntax sugar).

I don't doubt that you wrote that into it. How about "I ain't got no home."?
How about the amusing (to me) "I could care less."?
I think I asked about how you set set to set a set to work without problems confusing it with set or set?

Yes and no, and the "no" part is the most important. If you take a serious standard, like PCI, PCIE, IDE (I mean HW interface), they begin with clarifications of English. I.e. what, for example, "should", "ought", "must" mean.

I once said: "let's make out processor cool in order to make it hot". The "cool" was meant in the context of temperature, and the "hot" was meant as hot selling.

That's probably the funniest statement in the whole thread - I am telling as verification engineer who worked with VLSI chip models containing much more lines of code.

The fundamental issue is: "testing never shows absence of bugs, it can only show their presence".

OTOH, there is a hing called "formal verification", sometimes also called "static verification".

So, what verification methodology and tools did you use to prove that your program works ?