Yes, I did. But you weren't in trouble with the moderator(s) at that time! So I'm not sure "inconsistency" is the right term; perhaps "responding differently to differing circumstances" would be more accurate.

I'm not sure which "fundamental" problems you're referring to. Please enumerate.

I'm not trying to be difficult here, I just don't want to spend a lot of time answering questions you're not actually asking. For example, I think one of the "fundamental problems" that determined the direction of programming language development was that the bulk of the computer community has always been primarily a rather narrow and mathematically-minded group of people, hardly representative of humanity as a whole. If there were a balance of poets and mathematicians from the beginning, our machines would be much different than they are now. Case in point: in the early days, Bill Gates and his cronies, all quite mathematically-minded, produced MS-DOS; while the "poet" Jobs and his crew came up with the first Macintosh.

But I suspect that's not what you're asking. So please enumerate.

Local variables in the current version are allocated on the stack and are invisible outside of the allocating routine. An indefinite article preceding a (possibly qualified) type name indicates that such allocation is required. Parameters are passed by reference but can be "privatized" to make local copies of them. The current compiler does not support private procedures and functions; if and when it seems advantageous for us to do so, we will make it so.

It is, of course, difficult to be more right than right; if a current theory is both correct and as simple as possible, there is obviously no improving it. Our argument is that current theories of programming languages are neither entirely correct nor as simple as they could be. (We reject, for example, most of the object-oriented paradigm; we think case-sensitive naming is unnatural and unhelpful; etc.) So we wanted to see what we could do without. And what we might be able to do better. Like a couple of kids who build a model airplane to gain an understanding aerodynamics (since the construction of a Boeing 747 in the back bedroom is not feasible). At present we've got a third-generation model plane in the back yard, capable of actually flying the two of us (and our friends) from place to place. I can't say how much our little experiment will help the professional engineers at Boeing; but if it encourages any of them to get back to their roots, or look at problems from unusual angles, or to solve problems by deleting things rather than adding, we'll be more than gratified. And if we can, by our example, encourage other kids to build models of their own -- instead of thinking the subject too complicated to even approach -- then we'll go to our graves with smiles on our faces.

I don't think that's necessary. We're not trying to build a better plane than the Boeing guys; we're trying to re-live the Wright Brother's adventure, taking advantage of resources that were inaccessible to them. We're out to inspire, not to solve. And even if we utterly fail with others, we, at least, found the whole thing both inspirational and educational. I know way more now about programming than I did when we started out; and I know way more about programmers too, having had literally hundreds of discussions like this one! The whole enterprise has been not only fun, but frustrating, and yet always enlightening. And we're as anxious as ever to share that experience with others.

The current version supports recursion in both data structures and routines. Since the compiler makes multiple passes at the source code, the order in which things are defined is inconsequential.

To me therein lies the rub also. I am pretty bad at learning human languages and I'm still learning how to communicate effectively in this, my mother tongue. However, over the years I have managed to pick up the syntax of Amstrad BASIC, Sinclair BASIC, turtle[whatever?], Pascal, C/C++, Java, Visual Basic, VBScript, DOS Batch files, KiXtart Script and probably some others within pretty short periods of time. Heck, I even have basic certificates for C++ and Java.
The thing is, though, that I can't program for toffee. I get to the "Teach Yourself" book stage and can't get beyond because I can't design around problems.
My point being that learning the syntax is, in fact, the easy part and whilst it may be easier to typethanit only takes literally minutes to learn the latter. However, writing a real application to solve a real world problem takes much longer. I am not including a GUI such as yours as a real world application, by the way, because in VB I could code it up in 5 minutes.

Then why you were talking about the order in which routines are defined ?

During World War II Dorothy Sayers wrote a wonderful little book entitled "Begin Here" -- the gist of it being that you can never really start with a clean slate. So your plans should begin with where you are and what you've got and who there is. Even if we believed that human languages were not suitable for programming, we couldn't explain that do a "dumbed down" student anyway -- the subject is too deep for him.

But we don't believe that. Why? Because we've actually written a significant and non-trivial program in Plain English and not only does it work, and work well, but we really enjoyed writing it. We like programming in English.

The only person paying for our research is me. I made a lot of money in database design in my youth (www.era-sql.com) and that has financed a lot of independent research in a variety of subjects. And I'm very much against "dumbing down" anyone. Here, for example, is a reading course that I developed so that youngsters could learn to read properly, in the left side of their brains (rather than "sight read" words as if they were pictures): www.rhymingreader.com. Our younger son, who is now seven, has read over 1000 books, can type 50 words a minute, and is now learning to program: Does that sound like a parent who thinks "dumbing down" children is a good idea?

---------- Post added 03-05-13 at 02:49 PM ----------

Because a couple of other posters thought the code would be easier to read if it was presented differently.

Yes, I agree that that is a legitimate interpretation of the phrase "1-1/2". I was reading a "C" program the other day and I thought the guy was writing an advertisement for an upgraded version of language, right in the middle of his code, when I came across the phrase:

c++;

But I soon got over the ambiguity by mentally "putting myself in the other guy's shoes" and trying to understand what he intended when he wrote it; by remembering the context and interpreting the term accordingly.

All languages, including precise mathematical languages, have conventions that need to be understood to properly interpret them. So you enter "1-1/2 minutes", thinking it an arithmetic expression, and get unexpected results; you do a little research on the local dialect, and you then correct your entry to "1/2 minute" or "30 seconds" or "1 minute minus 1/2 minute". What's the big deal?

See above. Conventions. Context. Clarifications. The same ways we deal with them in real life conversations.

Yes, we've looked at lots of attempted definitions of natural languages. I even had a little cartoon joke about it on our original website (go here: http://www.osmosian.com/old/ and click "NEXT" three times).

But we also wrote our compiler at a time when my younger son was around two years old and was just learning to talk. He convinced me that natural languages could be understood without a lot of formal analysis -- since the little guy was obviously doing it all day long. (He's seven now and uses predicate adjectives all the time -- without having the faintest idea what they are!) So I thought, what would happen if we tried to parse English like a kid does in his head? Would it be possible to write an entire IDE and compiler and page-layout facility in such a language, or would it be too ambiguous or unreliable or unwieldy? And the answer? Well, the answer is the IDE and compiler and page-layout facility that we actually wrote. It turns out you can parse a natural language like a two-year-old -- and still get a great deal of real work done. In a very natural (and interesting and fun) way.

You have not. Plain English does not use indentation while you do. To me your statement that you have written a significant and non-trivial program in Plain English is between a false advertisement and a plain lie.

Not only that, once you have been coding for a while, you will find that writing the whole sentence all the time becomes a real drag and wish you had a short cut like the latter.

The expression "i++" might look like gibberish to someone who has never seen C code before but C programmers are generally grateful that they don't have to constantly type out "i = i + 1" all the time. There is a reason why each profession has its own special language.

Yes, have to agree with that also. I lost count of the number of times I wished VBScript had increment operators and a few other "shortcuts" that C++ has.

We often use indention in everyday writing:
...When we want to make a list of things; or
...When we want to set off a quotation; or
...When we're writing a reply to a particularly contentious inquisitor.

Besides, indention is not required by our compiler; we can write:

To draw the desktop:
Draw the bar.
Draw the switch.
Draw the pad.
Draw the current menu.

Or we can write:

To draw the desktop: Draw the bar. Draw the switch. Draw the pad. Draw the current menu.

Or we could say:

To draw the desktop: Draw the bar and the switch and the pad and the current menu.

And soon we'll be able to say:

To draw the desktop: Draw the bar, the switch, the pad, and the current menu.

With or without the final comma. The thing just keeps getting better and better

What do you use to denote code blocks ?

It's curious, but I personally haven't found this to be the case. For me, translating things in my head and switching between significantly different modes of expression are much more onerous than typing and few extra strokes. But then I write a lot of letters, posts, essays, books and such, so thinking and typing complete sentences is second nature to me.

In any case, I've already indicated that our long-term vision for Plain English hopes to incorporate facilities for people with all kinds of minds and backgrounds and habits: a natural-language framework with snippets of alternative syntaxes wherever and whenever appropriate. I'll repeat the extreme example posted earlier for those who don't have the time to study the whole thread. In our standard library, "the noodle", you'll find this routine:

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

which includes both very high and very low modes of expression -- English at the start, hexadecimal machine code at the end. I'm sure you can all imagine a wide variety of variations on this theme.

May I ask whether your manager has given you a task such as described earlier by suicidaleggroll to be completed yesterday? Or, indeed, whether you've had to use your language "in anger" so to speak to solve a problem?
Your language seems to work and may make it easier for people to see whether they like programming but has it actually solved a real world problem whilst operating under a deadline?

There's a brief description of the inner workings of the compiler, in his own words, on page 11 of the documentation. I repeat it here for your convenience:

---

HOW I WORK

Alrighty then. Here's how I manage to do so much with so little.

(1) I really only understand five kinds of sentences:

(a) type definitions, which always start with A, AN, or SOME;
(b) global variable definitions, which always start with THE;
(c) routine headers, which always start with TO;
(d) conditional statements, which always start with IF; and
(e) imperative statements, which start with anything else.

(2) I treat as a name anything after A, AN, ANOTHER, SOME, or THE, up to:

(a) any simple verb, like IS, ARE, CAN, or DO, or
(b) any conjunction, like AND or OR, or
(c) any preposition, like OVER, UNDER, AROUND, or THRU, or
(d) any literal, like 123 or "Hello, World!", or
(e) any punctuation mark.

(3) I consider almost all other words to be just words, except for:

(a) infix operators: PLUS, MINUS, TIMES, DIVIDED BY and THEN;
(b) special definition words: CALLED and EQUAL; and
(c) reserved imperatives: LOOP, BREAK, EXIT, REPEAT, and SAY.

So you can see that my power is rooted in my simplicity. I parse sentences pretty much the same way you do. I look for marker words — articles, verbs, conjunctions, prepositions — then work my way around them. No involved grammars, no ridiculously complicated parse trees, no obscure keywords.

---

And here, in anticipation of similar technical questions, is the EBNF that we used to guide us on our first-pass parsing (the compiler makes several passes at the code, with a bit of ad-hoc stuff at each level)

---

--- LEXICAL BNF ---

token = glom | possessive | qualifier | string

glom = glomstarter { glombyte }
glombyte = letter | digit | ~ @ # % _ $ & - + / | non-possessive '
glomstarter = letter | digit | ~ @ # % _ $ & '
letter = A..Z | a..z | extended ascii
digit = 0..9

possessive = ' preceded by S followed by non-glombyte | 'S non-glombyte
qualifier = ( printable-chars )
string = " printable-chars | nested-quotes "

mark = . , ; : ! ?
symbol = | * + - ^ / < > { } = extended ascii

noise = non-printable | space | tab | non-breaking-space
comment = \ chars cr
remark = [ printable-chars ]

--- ONE LEVEL UP FROM LEXICAL ---

noise = lexical-noise | comment | remark
integer-token = digit { digit }
ratio-token = integer-token / integer-token
mixed-token = integer-token - integer-token / integer-token
numeric-token = integer-token | ratio-token | mixed-token
nibble-token = $ { digit | A..F }
string-token = same as lexical
qualifier-token = same as lexical

--- SYNTATICAL BNF ---

program = { type | global | routine }

built-in-types = BYTE | BYTE POINTER | WYRD | NUMBER | FLAG | POINTER | RECORD | STRING | SUBSTRING | HEX-STRING
| THING | THING RECORD | THINGS | RATIO | NUMERATOR | DENOMINATOR

type = A name IS A type-name [ optional-info ] .
= A name HAS fields .
= A name IS number-token type-name .

optional-info = TO A type-name | WITH fields

fields = field-descriptor { pauses field-descriptor }
field-descriptor = ( A name | numeric-token BYTES ) { CALLED name | AT THE name | ( REFERENCE ) }

pause = , | ; | AND | OR
pauses = { pause }

conjunction = AND | BOTH | BUT | EITHER | NEITHER | NOR | OR
preposition = IN | OF | ON | WITH | BEFORE | AFTER ... \*** NEEDS REVIEW ***

global = THE name IS A type-name [ optional-info ] .
= THE name HAS fields .
= THE name IS A type-name EQUAL TO constant-term .
= THE name IS constant-term .

routine = procedure | decider | function | callback
procedure = TO routine-name : employ-clause | statements
decider = TO DECIDE IF routine-name : employ-clause | statements
function = TO PUT A type-name 'S name INTO A type-name : employ-clause | statements
= TO PUT THE name 'S name INTO A type-name : employ-clause | statements
callback = TO COMPATIBLY routine-name : employ-clause | statements

routine-name = { monikette | parameter | phrase } [ qualifier ]
monikette = any word except articles
parameter = A name [ CALLED name ]
phrase = THE name
employ-clause = EMPLOY routine-name .

name = { any word except articles, prepositions, conjunctions, verbs, operators, CALLED, EQUAL }

statement = privatize | loop | conditional | unconditional .
privatize = PRIVATIZE parameter-term .
loop = LOOP .
conditional = IF decider-call , unconditional { ; unconditional } .

unconditional = break | call | exit | intel | repeat | point | push | say
break = BREAK
call (internal) = { monikette | expression | phrase } [ qualifier ]
call (external) = CALL "dll-name" "entry-name" [ WITH expression { AND expression } ] [ RETURNING term ]
call (indirect) = CALL expression [ WITH expression { AND expression } ] [ RETURNING term ]
exit = EXIT
intel = INTEL nibble-token
point = POINT term TO ROUTINE { monikette | parameter | phrase } [ qualifier ]
push = PUSH expression
repeat = REPEAT
say = SAY flag-expression

expression = term { operator term }
operator = plus | minus | times | divided by | then

constant-term = negated-constant-term | posigated-constant-term | literal
negated-constant-term = - constant-term
posigated-constant-term = + constant-term
literal = numeric-token [ type name ] | string-token | nibble-token | YES | NO | NIL

term = negated-term | posigated-term | new-local | variable | literal-term [ AS A type-name ] [ / term ]
negated-term = - term
posigated-term = + term
new-local = A name [ CALLED name ] possessives
variable = THE variable-name possessives
literal-term = literal possessives

possessives = { possessives }
possesive = 'S ( field-name | function | target | magnitude | whereabouts )