Natural Language Programming

[Gerry Rzeppa]

Gerry's approach is to start with no sense of the machine's limitations...

How does a person with "no sense of the machine's limitations" manage to write an efficient native-code generating compiler/linker?

But he is disdainful of all that underlying stuff.

I think, "willing to question" or "willing to take a second look at" or "interested in alternative approaches" would be a more balanced assessment. But yes, openly disdainful of things that are anachronistic, unnecessary, or just plain ugly. Like my example from earlier that is still awaiting a response:

Picture a mom looking for a pair of shoes for her kid on the Walmart website. Which principle of good user interface design suggests that she needs to see, at the top of the screen, something like this:

http://www.walmart.com/search/?query=boy%27s%20shoes%20striker%20size%2010

He not only wants people to write statements in plain english, but also to throw everything else away...

I answered that earlier:

We think it unlikey that top-to-bottom natural language systems will ever be created the way most people approach the problem. As long as systems with natural-language input (like Wolfram's ALPHA and Apple's SIRI) are written in derivatives of the "C" programming language, there will always be a divide between the "priests" and the "people". Which is why we didn't write our Plain English compiler in some derivative of "C", but rather wrote it in Plain English. We wanted to make it clear that priests and people could speak the same language if they wanted to.

We also found the Plain English developmental approach to be (a) easier, because we only had to think in one way -- we were programming in the same language we were trying to parse; and (b) revealing, because the things we wanted to say in English were the same kind of things that our "users" would want to say-- thus, solving our problems turned out to be the same thing as solving theirs. Developers writing natural language systems in artificial languages are deprived of these advantages.

 

[Merad]

His behavior is essentially that of a leader of a cult. He holds firmly to a set of beliefs that a large majority of people find irrational, and proselytizes single-mindedly in the search for anyone who will join him in those beliefs.

Well, bear in mind that he is the "Grand Negus" of "The Osmosian Order of Plain English Programmers".

Soooo, yes.

 

[Squeetard]

Programming languages were developed to make things easier, not harder. Now you want to screw that all up.
Mathematical notation was developed over thousands of years to express complicated formula's in an easier to read fashion. Take this example:

They teach this in school. No one in history has ever said, screw this junk, let's just describe it in plain english. Or said let's toss out the "/" symbol and instead use "how many times does the first number go into the second number". If you want to learn math you first have to understand what parethisis, slashes and so on mean. You do this because it will make math easier for you. Not to keep math out of reach of the peasants.

Gerry, do me a favor and describe the above formula for me in plain english?

 

[Markbnj]

How does a person with "no sense of the machine's limitations" manage to write an efficient native-code generating compiler/linker?

That was a description of the starting assumptions for the analysis, not of limitations in knowledge.

 

[Markbnj]

Picture a mom looking for a pair of shoes for her kid on the Walmart website. Which principle of good user interface design suggests that she needs to see, at the top of the screen, something like this: http://www.walmart.com/search/?query...er%20size%2010

It's a silly question. You could isolate the more complex aspects of any interface to anything, rewind time to before we had the thing it is an interface to, and ask the same question.

Picture a mom who is late getting her kid to school in the morning. Which principle of user interface design suggests that she should be confronted by a sheet of metal with a weirdly shaped hole in it when she reaches her car? Is it instinctive in human beings that she should, at that point, take a metal ring out of her purse and insert another piece of metal into the hole to make the door open?

These parables and stories of yours are just like big hair on a poodle. Shave it off and what's left is this skinny little thing shaking in the cold air.

 

[BoberFett]

I think, "willing to question" or "willing to take a second look at" or "interested in alternative approaches" would be a more balanced assessment. But yes, openly disdainful of things that are anachronistic, unnecessary, or just plain ugly. Like my example from earlier that is still awaiting a response:

Picture a mom looking for a pair of shoes for her kid on the Walmart website. Which principle of good user interface design suggests that she needs to see, at the top of the screen, something like this:

http://www.walmart.com/search/?query...er%20size%2010

Sorry, what's the problem? Seeing a URL? People see URLs all the time. Whenever someone sees an ad telling them to go to www.myproduct.com it's a URL. Why shouldn't they be able to verify the Uniform Resource Locator matches where they want to be? What else would you put there, the page description? Great, follow my link to www.USBanke.com, I'll stick a US Bank logo and title on the page and be all set to capture passwords.

Dumb things down the lowest common denominator, and you'll find someone willing to prove you haven't found the bottom.

We think it unlikey that top-to-bottom natural language systems will ever be created the way most people approach the problem. As long as systems with natural-language input (like Wolfram's ALPHA and Apple's SIRI) are written in derivatives of the "C" programming language, there will always be a divide between the "priests" and the "people". Which is why we didn't write our Plain English compiler in some derivative of "C", but rather wrote it in Plain English. We wanted to make it clear that priests and people could speak the same language if they wanted to.

There is still a priest in your world vision, it's just that the priest is you. I'm sure that doesn't bother you at all.

Besides, the divide between programmers and users isn't the programming language. That's like saying the divide between a chef and a diner is the handwriting on the recipe card. I've never been involved in a project where the wrong result was reached because of the language used to write the program. The problem is almost invariably poor design due to user's lack of understanding of their own needs. Coding is only one piece of a successful software project, and not even all that large a piece. Requirements gathering and design are far more important in my experience.

We also found the Plain English developmental approach to be (a) easier, because we only had to think in one way -- we were programming in the same language we were trying to parse; and (b) revealing, because the things we wanted to say in English were the same kind of things that our "users" would want to say-- thus, solving our problems turned out to be the same thing as solving theirs. Developers writing natural language systems in artificial languages are deprived of these advantages.

Again, you're not programming in English. You think it's English because you've convinced yourself that it is. Regular people don't talk the way your code reads. Human communication is full of nuance. Hell, a huge part of communication is non-verbal. Most people are terrible writers and speakers, and depend on a great deal of inference by the listener to actually have any hope of communicating a complex idea. If natural language was sufficient for writing a program, then no project should ever fail due to problems during solicitation of system requirements. But people who want a program to do something leave out a ton of information.

And now I know what your code reminds me of. It sounds like the kind of over-simplified design requests made by users who have no concept of the things involved with writing software that works. "Do a thing with that other thing and display it on the screen. Oh, and can you have it done tomorrow? That should be easy right?"

 

[BoberFett]

Programming languages were developed to make things easier, not harder. Now you want to screw that all up.
Mathematical notation was developed over thousands of years to express complicated formula's in an easier to read fashion. Take this example:

They teach this in school. No one in history has ever said, screw this junk, let's just describe it in plain english. Or said let's toss out the "/" symbol and instead use "how many times does the first number go into the second number". If you want to learn math you first have to understand what parethisis, slashes and so on mean. You do this because it will make math easier for you. Not to keep math out of reach of the peasants.

Gerry, do me a favor and describe the above formula for me in plain english?

LOL :thumbsup:

 

[werepossum]

Hyperbole.

Riiiiight.

Painted whore of an interface? Now you just sound like an nutjob.

To you maybe.

Scroll bars aren't distracting, they serve a purpose beyond scrolling. They indicate position with a document. UI conventions such as scrollbars, radio buttons and checkboxes weren't pulled from somebody's sphincter on a whim, they came to solve a problem that wasn't handled previously.

You throw out all conventions when it suits you because they don't make logical sense in your mind, but apparently CTRL+C and CTRL+V still work for you, because V so clearly stands for Paste.

There are so many things wrong with your instructions, I'm not even sure where to begin.

I use CTRL-V literally every day, but I have to admit I love me some things like scroll bars and pull-down/pop-up menus. I used to use a Calcomp digitizer which had a maximum possible combination of sixty-one button commands. I found I could permanently memorize roughly half those and maybe half the remainder if I was using those commands much on that project. Add common Windows and AutoCAD shortcuts and I still want to do more things than I can memorize; thus the painted whore is looking like a good thing. (And let's be honest, most painted whores are good things. )

He can't, because his language doesn't have that capability. He's created a somewhat fancy scripting language that still relies on all of that painted whore's magic to get any real work done. The natural language is just a wrapper around real programming. Any attempt to do your own real work that isn't something that he's already thought of will require you to use that painted whore magic too, leaving that natural language programming in the dust. You'll still have to understand the Windows API. How do his ODBC connectors work? How's his OpenGL support?

The OP is befuddled old man who may have once been a respected professional, but is past his prime and now has no business being allowed near anything resembling important code.

Just read through his examples in that PDF. The "natural language" he uses is just as complex as any programming language and outputs a primitive looking application. I'm not sure what the benefit is, other than for an aging ideologue to rant about these new fangled devices and operatin' systems painted up like whores! Now get off his lawn, whippersnapper!

I think he could, but it would be more difficult than with a more modern, more structured language. There are I think two main reasons such languages evolve, to handle complicated projects over time and to minimize machine resources used. Otherwise everyone would be programming in some sort of Basic.

That's simply not true. Our compiler translates directly from Plain English into machine language. Sure, we make use of operating system subroutines when they're handy, but it would be no harder to write a complete operating system in Plain English than in any other language.

Every programming language makes use of operating system facilities. How do ODBC and OpenGL interface with the C language? The same as they do with any other: everybody calls operating system functions via interface libraries.

I don't doubt you could do it, but I believe it would be immensely more difficult. Such programs are typically written by teams, and here Plain English's beauty, its simple flexibility, is also its Achilles heel. You can train your compiler to know you, but real language is naturally ambiguous. The more people working on something, the more likely they will have different meanings and contexts for the same words. And just as importantly, the more difficult it is for people to maintain the system. I don't know how many times I've written notes on technical drawings which seemed fine to me but which confused a contractor - even if a dozen previous contractors had read the exact same note with no ambiguity.

 

[Merad]

Besides, the divide between programmers and users isn't the programming language. That's like saying the divide between a chef and a diner is the handwriting on the recipe card. I've never been involved in a project where the wrong result was reached because of the language used to write the program. The problem is almost invariably poor design due to user's lack of understanding of their own needs. Coding is only one piece of a successful software project, and not even all that large a piece. Requirements gathering and design are far more important in my experience.

Not to mention that Udacity, Code.org, Code Academy, Khan Academy, and many others have shown that language syntax is not a barrier to entry into programming for most people.

I think he could, but it would be more difficult than with a more modern, more structured language. There are I think two main reasons such languages evolve, to handle complicated projects over time and to minimize machine resources used. Otherwise everyone would be programming in some sort of Basic.

I suspect that Gerry's compiler would need major revisions before it would even be close to viable for a large project. I was bored this morning and reading through his compiler code, and from what I can see there is zero attempt at code optimization of any kind. I'm guessing that performance is on par with totally unoptimized C/C++ code, possibly worse. Nor does it look like it would be very easy to optimize, because all of the lowest level functions that emit machine code appear to be basically hard coded.

If Gerry wanted to really do something interesting, he would be better off developing a natural english front-end for LLVM. Now THAT would be a project that could have some cool results.

 

[werepossum]

Programming languages were developed to make things easier, not harder. Now you want to screw that all up.
Mathematical notation was developed over thousands of years to express complicated formula's in an easier to read fashion. Take this example:

They teach this in school. No one in history has ever said, screw this junk, let's just describe it in plain english. Or said let's toss out the "/" symbol and instead use "how many times does the first number go into the second number". If you want to learn math you first have to understand what parethisis, slashes and so on mean. You do this because it will make math easier for you. Not to keep math out of reach of the peasants.

Gerry, do me a favor and describe the above formula for me in plain english?

Excellent point. At some point mathematical concepts were expressed solely in plain language. Math evolved past that point because at a certain level of complexity, artificially imposed structure actually makes things much easier.

I don't doubt that Gerry could describe the above formula in Plain English and have it generate the correct answer, but it would be difficult and the odds are if many people were doing this, a substantial number would be doing it incorrectly without knowing.

 

[Markbnj]

If Gerry wanted to really do something interesting, he would be better off developing a natural english front-end for LLVM. Now THAT would be a project that could have some cool results.

Yep. Emitting machine code throws away about 20 years of language and runtime evolution.

 

[Gerry Rzeppa]

Gerry, do me a favor and describe the above formula for me in plain english?

As I've said several times in this thread, we readily admit that certain kinds of things are better said with formulas (or even graphics) than plain English text. That's why we're proposing our Hybrid Programming Language as the ultimate solution: a natural language framework with snippets of formulas and graphics as appropriate. Like this page from one of Einstein's notebooks:

Or a typical math book. Or a book on physics. Or almost any technical whitepaper on almost any subject.

Our observation is that most of most programs are not mathematical in nature. They're stuff like "Move this over there" or "Draw that on the screen" or "Save something on a disk" -- things that are most conveniently and most naturally to expressed in a natural language.

 

[Gerry Rzeppa]

Sorry, what's the problem? Seeing a URL?

Exactly. My wife -- a typical mom -- doesn't need or want to see a URL on the screen when she's looking for kid's shoes. Putting one there shows an utter disregard for the point of view of that entire user community. In a word, it's bad design.

And now I know what your code reminds me of. It sounds like the kind of over-simplified design requests made by users who have no concept of the things involved with writing software that works.

The fact remains that we're able to write very sophisticated programs using Plain English -- conveniently and efficiently -- so it can't be as bad as you make it out to be.

 

[Gerry Rzeppa]

Yep. Emitting machine code throws away about 20 years of language and runtime evolution.

No, compiling Plain English directly into machine code shows how little actually needs to be written in lower-level languages.

Keep in mind that one of our major objectives here is education. And education works best when extraneous topics are removed from the equation; when we focus on the essentials.

So at the top we have a language with a familiar syntax that is easily understood by humans: Plain English. And at the bottom we have a language with an unfamiliar syntax that is easily understood by processors: machine code. In between, we have our compiler, written entirely in Plain English with a handful of hexadecimal literals representing the bits and bytes of the machine code.

The student thus quickly sees the whole picture, top to bottom, without any unnecessary and distracting complications. He sees how we translate a human-friendly language into a machine-friendly language. Conveniently and efficiently. Anything more is decoration -- which, now that the student knows the essentials, he can pick up anywhere.

 

[Gerry Rzeppa]

I was bored this morning and reading through his compiler code, and from what I can see there is zero attempt at code optimization of any kind. I'm guessing that performance is on par with totally unoptimized C/C++ code, possibly worse. Nor does it look like it would be very easy to optimize, because all of the lowest level functions that emit machine code appear to be basically hard coded.

Once again, the quality of a solution has to be judged relative to the goals set for that solution. And it must be kept in mind that great engineering almost always involves striking a balance between competing objectives. In this case, we wanted a compiler that was both (1) simple, and (2) efficient.

Regarding (1), as discussed in my post above, we wanted to go directly from Plain English to machine code to eliminate any unnecessary steps -- so the student could easily see how the translation takes place, without distraction. We thus chose to make the compiler little more than a "push the parameters and make the call" kind of affair.

Regarding (2), our goals for the system were that it (a) would be less than a megabyte in size, and (b) would be able to rebuild itself on a bottom-of-the-line computer from Walmart in three seconds or less. All of these goals were accomplished in the prototype.

We did, as well, include two specific "optimizations" that we thought both simple enough and relevant for the beginning compiler-writing student. The first was "smart linking" -- only those library routines that are actually called are included in an executable. The second was a handful of library routines actually implemented in machine code -- to illustrate to the student how our proposed Hybrid Language would work, and how it could greatly improve performance in certain cases.

Bottom line: the code our compiler produces is both small enough and fast enough for any application that might be attempted in straight Plain English. And certainly small enough and fast enough as the educational "proof of concept" that we intended. Our Hybrid Language, of course, will be faster and will support a wider range of applications.

 

[Markbnj]

No, compiling Plain English directly into machine code shows how little actually needs to be written in lower-level languages.

Congratulations. You've convinced us all that we don't need to write machine code. Why not compile your plain english statements down to C# or Java? Then you get actual platform portability as well as all the benefits of being part of an ecosystem where people can actually use your stuff to get something practical done. You'd have to abandon all these ideas about reinventing the UI, and taking us all back to the purity of Wirth, but trust me that's not a bad thing.

Actually javascript would be a much better fit, since on the one hand its variables are utterly pliable with regard to type and behavior, and on the other hand it is very rude and insulting to OO, so you'll get along. Do that and your plain english could compile down and run in a browser. Think of the possibilities, Gerry.

 

[Gerry Rzeppa]

Regular people don't talk the way your code reads.

I can see why, at first glance, somebody might think that. But it's primarily a difference in subject matter, not grammar. Let's take some examples where the subject matter is common to the both the "regular" and the "programming" worlds. Consider the following sentences:

Turn on the lights.
Drop the ball.
Follow the line on the floor.
Follow the yellow brick road.
Reach for the sky.
Move the block to the left 2 inches.
Open the door about half-way.
Wait 12 seconds.
Roll the dice.
Push the button.
If the temperature is greater than 70 degrees, turn off the heater.
Put the red box on top of the blue box.
Put the cake in the oven and set a timer for 23 minutes.

Can you tell which of those sentences were spoken, person-to-person, and which were Plain English code written in a middle-school robotics class?

 

[Gerry Rzeppa]

Why not compile your plain english statements down to C# or Java?

I answered that question in an earlier post:

A system that "converted 'natural English' to something like C++ code" would require two translators: (1) the "English to C++ converter" and (2) the "C++ to machine code" compiler. Our Plain English system requires only one translator: the "English to machine-code" compiler. Our system, with "fewer moving parts", is thus easier to install, easier to explain, and easier to use: for those reasons it is a better instructional tool. And closer to something Occam might approve of. And Einstein, as well: "As simple as possible, but no simpler."

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

Then you get actual platform portability as well as all the benefits of being part of an ecosystem where people can actually use your stuff to get something practical done.

When people write us for a copy of our program, we include release notes in the reply. Those notes have always included the following statement: "Our system is intentionally different - iconoclastic is the term we use. It was designed to make the programmer question almost every preconceived notion a modern practitioner might have." So you can see we're not interested in "being part of" the existing ecosystem: we want to remain outside it. We want to encourage people to question that ecosystem; to learn to disdain those parts of it that are less than they could be; to improve that ecosystem by simplifying it; in short, to think outside the box of the existing ecosystem.

You'd have to abandon all these ideas about reinventing the UI,

Our standard libraries do not contain any interface "widgets" intended for reuse by others: we believe that each application interface should be custom-designed to best suit that particular application and user community. Our interface is an example of one such custom interface designed specifically to meet our needs and our goals (as described in a previous post). We're not "reinventing the user interface"; we're encouraging others to best serve their users by reinventing whatever needs to be reinvented in their particular situations.

Case in point: almost every forum in the existing ecosystem (including this one) has a primitive "edit here, preview there, go back and make changes over there" kind of post editor -- when a straightforward wysiwyg editor would clearly be far superior. This should be questioned, disdained, and fixed.

...and taking us all back to the purity of Wirth...

Ah, Niklaus! A true Osmosian if ever there was one.

Actually javascript would be a much better fit, since on the one hand its variables are utterly pliable with regard to type and behavior, and on the other hand it is very rude and insulting to OO, so you'll get along. Do that and your plain english could compile down and run in a browser. Think of the possibilities, Gerry.

My son and I have discussed developing a version of Plain English that runs in a browser (by compiling to JavaScript) on several occasions. Each time we decide against it because it would lack at least half of the educational value of the existing system: the student would be able to learn nothing (directly from our code) about machine language and how computers actually work).

And, as above, it would give the student the wrong impression: that Plain English is okay for "scripting" languages, but "real" programs (like JavaScript interpreters and browsers) have to be written in something else.

Besides, such a thing doesn't fit into our long-term plans. Once we write our own operating system, we'll be implementing our own "Alternet" as well: a network of Plain English programmers and users that uses the internet's existing hardware, but is otherwise independent of it. An alternative "ecosystem". Why? Because it's always good to have an alternative. Or in this case, an "Alternet"

 

[Gerry Rzeppa]

I've never been involved in a project where the wrong result was reached because of the language used to write the program. The problem is almost invariably poor design due to user's lack of understanding of their own needs. Coding is only one piece of a successful software project, and not even all that large a piece. Requirements gathering and design are far more important in my experience.

I agree. The "enter stuff here, preview up there, go back down there to make corrections" post editor I'm using on this forum, for example, isn't primitive and inconvenient because it was coded in some derivative of the C language, but because of errors in design.

And here's another example that's a design problem, not a programming problem. I often print these posts to share them with my wife and kids. So I'm looking at the thing I want to print. But first I have to select "Printable Version" from a menu, which reformats the thing into another window. Then I have to hit another print button, which reformats the thing a second time into Chrome's print window. Then I have to hit a third print button to send the thing to the printer. Good design? You tell me. An "existing ecosystem" that I want to be part of? I don't think so.

But that doesn't mean we can't make our programming languages more natural, easier to learn, easier to use, as well. After all, the more alike we can make the user's and the developer's view of things, the more likely users and developers are to communicate without misunderstanding.

Some years ago we decided to develop an integrated system for our training company (www.era-sql.com). We ended up inventing the "PageBase", a system where everything we had -- customer files, accounting records, orders, invoices, schedules, maps, even our training manuals themselves -- were stored as collections of wysiwyg pages: the user's view, and the programmer's view, thus being identical: no need for mapping from a database to a form and back again. And every operation on a collection of pages produced as output another collection of pages which could, in turn, be used as input to subsequent operations: a mathematically closed system with no "dead ends". And since everything was wysiwyg, there was never any need to reformat anything for printing. We still use that system today. Write me directly (gerry.rzeppa@pobox.com) and I'll send you the user manual as a PDF if you're interested.

 

[Cogman]

My son and I have discussed developing a version of Plain English that runs in a browser (by compiling to JavaScript) on several occasions. Each time we decide against it because it would lack at least half of the educational value of the existing system: the student would be able to learn nothing (directly from our code) about machine language and how computers actually work).

And herein is why your project is doomed to failure. For all your touting of the superiority of plain english, you are almost fatally confused about what makes programming hard vs what makes it easy. You want your language to be very low level because it helps to understand what the computer is doing, yet you also want to use plain english because it is "easier and more intuitive".

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

But beyond that, your language is fatally flawed because it was designed like a first or second generation programming language, related more closely to cobol, fortran, or APL. The asinine focus on making it low level while still trying to make sentences is ultimately what makes this language terrible. The fact that you completely ignore the existence and utility of the last 60 years of innovation in language and programming development shows how incredibly ignorant you are.

What things are you ignoring?

Well lets start with the fact that basically your language provides functions, variables, and structs. It requires the user to know and use manual memory management and also provides absolutely no help to the writer when it comes to memory leaks. They should just be "good enough to know they are there." This is a huge fault and one of the biggest sources of errors in C.

You have very little in scope and namespace management, another big failing of the c language. It why many C libraries adopt function name like lib_png_sublibrary_subobject_doThing so they don't collide.

You offer very little (no?) library support, which is horrible in general. So now, everytime anyone wants to do anything they are supposed to what, copy out huge swaths of text from one project to the next? Umm, yeah, no thanks!

You include the ability to inline assembly and the language appears to have very strong ties to the x86 architecture. A particularly stupid design decision because, frankly, you ignore the fact that there are many, MANY, other platforms in the world. Promoting one to the top is a sure fire way to make sure that is the only platform your language will ever run on.

Global mutable state is the order of the day, sorry, that is just such a horrible mistake in language design. Most new language don't support this and for good reason, global state is just a terrible idea which will only result in problems for future maintainers. It creates tightly coupled code which is hard to understand because at any given point anyone anywhere can mutate and change the state of a variable. This leads to all sorts of nasty bugs and debugging issues.

But then you also seem completely ignorant of today's current higher order programming constructs. Immutability, for example, is a cherished and very important feature of any new language. In fact, I would go so far as to say immutability constraints are the most important feature of new languages as immutable objects and data structures prevent a huge number of bugs (primarily in the concurrency arena). Your language has none of these.

Functional constructs such as closures and lambdas are increasingly showing their value in making highly maintainable, testable and reliable code. It makes it much easier to decouple logic and focus on individual correctness over system wide correctness. APIs designed with functional idioms in mind are simply easier to extend. They make the lives of the programmers much easier. Your language offers none of this.

Your language doesn't deal with concurrency at all. Given the importance of concurrency in a modern computer architecture, ignoring it completely is not wise at all.

Data structures aren't dealt with. You have them sort of in the background. Sure, you have structs, but that is about it. Datastructures are just so important that no modern language ships without a good healthy selection.

And finally, the fact that you think English is good for programming is simply stupid. English is a terribly ambiguous language. Everything I have said in this post could have been said 10,000,000 different ways while still conveying the same meaning. Programming is about specificity and exactness. English wasn't designed for programming, nor was any natural language. The closest (semi-spoken) language that could be use is esperanto which was designed to be as unambiguous as possible. As far as languages go, english is probably one of the worst designed languages available. Because it evolved as sort of a mixing pot of languages and language ideas, it has way too many rules, nuances, and inconsistencies. English is spoken completely differently in England, Scotland, Ireland, India, Texas, Idaho, New York, or Jamaica. As a programmer, it would be horrible trying to understand what is going on just because someone is writing something using a different dialect.

 

[Squeetard]

Our observation is that most of most programs are not mathematical in nature. They're stuff like "Move this over there" or "Draw that on the screen" or "Save something on a disk" -- things that are most conveniently and most naturally to expressed in a natural language.

That is total BS. Programs are written to perform complex tasks, that's why they are needed in the first place, geeez. I've never once written a program to "draw a line on the screen" or "Move this over here". I've done quick macro's to do such when they are a repetitive task. And guess what, for those I never have had to write a program or learn any language. I hit the record button, do my task. Save. Run macro until done.

The fact remains that we're able to write very sophisticated programs using Plain English -- conveniently and efficiently -- so it can't be as bad as you make it out to be.

No you can't and you admitted it in the first quote. And we know you can't. You make me laugh. You write some plain English compiler that works on only the very narrowest scope and call it a success. Again let me repeat this. Your project is not needed. You created it to try and solve a problem that does not exist, and it will never be used by anyone outside your cult.

I wrote a Tetris clone in VB. Do the same in your natural language. This should be right up your alley, there is no complicated math involved. Or better yet, have someone who has never programmed before (but knows the game well) write one using your natural language. You will have me firmly in your court if you can. Standing by.

 

[Squeetard]

Or better yet, copy and paste the rules of tetris into your compiler and see what comes out.
http://tetris.wikia.com/wiki/Tetris_Guideline

 

[Gerry Rzeppa]

You want your language to be very low level because it helps to understand what the computer is doing, yet you also want to use plain english because it is "easier and more intuitive".

Exactly. So the student can learn all about computers, from the top to tbe bottom; from his first and almost magical "Hello, World!" to the lowest level where the secrets of machine code, stacks, memory management, etc, reside.

Well, you are simply wrong and ignorant of what makes programming hard. Abstraction and logic are the two things I've seen new developers struggle with the most.

I haven't had those problems with any of my students, many of whom have gone on to lucrative careers as professional programmers, independently employed. Perhaps you're teaching the subject in an ineffective way. The key, in three words, is this: TEACHING IS TELLING. The so-called Socratic method is bunk. You want to transfer the working neural patterns in your brain into your student's brain -- not ask the student to reinvent the wheel. So you show him a problem, then you hand him the solution on a silver platter and have him type it in. (Our standard dual-monitor set up, where the teacher controls the mouse and the student controls the keyboard, is ideal for this kind of training.) Then you do it again, with the next problem. And again, and again, and again. When you see that the student is typing the right stuff before you tell him what to type, you're done.

But beyond that, your language is fatally flawed because it was designed like a first or second generation programming language, related more closely to cobol, fortran, or APL.

Actually, more like Pascal or Oberon. But clearly that's all that's needed, both for beginner and professional. If it wasn't enough, how could we write an entire integrated development environment (including interface, file manager, text editor, hex dumper, native-code-generating compier/linker, and wysiwyg page layout facility for documentation) -- conveniently and efficiently -- with just that and no more?

The asinine focus on making it low level while still trying to make sentences is ultimately what makes this language terrible.

The beginning student doesn't need to see any of the low-level stuff. That's why, for example, we manage memory for strings automatically. But we do want the more advanced student to understand memory management, so we expose that level of detail when the student is ready to study more advanced data structures.

The fact that you completely ignore the existence and utility of the last 60 years of innovation in language and programming development shows how incredibly ignorant you are.

Yet smart enough to develop the non-trivial program under discussion. Smart enough to teach others who are now gainfully self-employed in the field. Smart enough to be self-employed in the field myself for over four decades.

Well lets start with the fact that basically your language provides functions, variables, and structs.

We would say, types, variables, and routines, in that order. But yes.

It requires the user to know and use manual memory management...

Only the advanced student/programmer (whom we want exposed to such things so he'll understand what the computer is actually doing); the beginner can work entirely with static variables.

...and also provides absolutely no help to the writer when it comes to memory leaks.

That's not true. Memory leaks (including the number "drips") are reported when a program terminates. The developer can then use our standard debugging facilities and techniques to find his error. Besides, in practice it's hardly ever a serious (or even frequent) problem -- at least not for a student trained as we train them.

You have very little in scope and namespace management, another big failing of the c language. It why many C libraries adopt function name like lib_png_sublibrary_subobject_doThing so they don't collide.

All types and routines in Plain English are global in scope, and variables are either global or local in scope. Each project is also it's own scope. This is sufficient for our needs: for teaching beginners how to write simple programs, and for teaching advanced students how to write sophisticated interfaces, editors, compilers, etc. In fact, it encourages the student not to let a program get too big, and not to integrate too many things into a single executable.

You offer very little (no?) library support, which is horrible in general. So now, everytime anyone wants to do anything they are supposed to what, copy out huge swaths of text from one project to the next? Umm, yeah, no thanks!

Yes, the developer copies the libraries (or the parts of the libraries) he needs into his project directory. (There is no separate "project management" facility in Plain English.) This insures that the developer's project will remain stable and operational even if the source library is "improved" at a later time. It's similar to the way our DNA is carried along in every cell of our bodies.

You include the ability to inline assembly and the language appears to have very strong ties to the x86 architecture. A particularly stupid design decision because, frankly, you ignore the fact that there are many, MANY, other platforms in the world.

At the time we wrote our prototype, most computers were x86s running Windows, so we chose that as our target. And sure, we could have inserted an intermediate virtual machine into our architecture, but that would have unnecessarily complicated the system for the student, and slowed performance. As I've said before, the elegance of a solution has to be judged based on the goals set for that solution -- not the personal goals of an outside observer like yourself.

Promoting one to the top is a sure fire way to make sure that is the only platform your language will ever run on.

All of the operating-system-specific stuff is in a single library in our system, and all of the machine-specific stuff is either in that library or in the compiler library. It's not a big deal to make it run on different operating systems and hardware configurations.

Global mutable state is the order of the day, sorry, that is just such a horrible mistake in language design. Most new language don't support this and for good reason, global state is just a terrible idea which will only result in problems for future maintainers. It creates tightly coupled code which is hard to understand because at any given point anyone anywhere can mutate and change the state of a variable. This leads to all sorts of nasty bugs and debugging issues.

It's a wonder, then, that our code is so simple and reliable. In over eight years of productive use, only a handful of inconsequential bugs have turned up, and a serious defect in the compiler is yet to be found.

But then you also seem completely ignorant of today's current higher order programming constructs. Immutability, for example, is a cherished and very important feature of any new language. In fact, I would go so far as to say immutability constraints are the most important feature of new languages as immutable objects and data structures prevent a huge number of bugs (primarily in the concurrency arena). Your language has none of these.

Not needed for our purposes. And our disdain for the object approach (verbs inside nouns indeed!) has been documented elsewhere in this thread.

Functional constructs such as closures and lambdas are increasingly showing their value in making highly maintainable, testable and reliable code. It makes it much easier to decouple logic and focus on individual correctness over system wide correctness. APIs designed with functional idioms in mind are simply easier to extend. They make the lives of the programmers much easier. Your language offers none of this.

The imperatives that fall from the lips of everyone on the planet, all day, every day, are typically procedural, not functional, in nature. We thus adopt a strictly procedural paradigm for our natural-language programming system. If it's not for you, fine. The "rest of us" are going to stick with the paradigm that has served humanity well for all 6000 years of recorded history.

Your language doesn't deal with concurrency at all. Given the importance of concurrency in a modern computer architecture, ignoring it completely is not wise at all.

Actually, we are forced to deal with concurrency in some spots -- the same file opened on more than one tab, for example. And we do. But it's not a major area of concern for us or our intended audience.

Data structures aren't dealt with. You have them sort of in the background. Sure, you have structs, but that is about it. Datastructures are just so important that no modern language ships without a good healthy selection.

Simple types (like numbers and strings), compound types (records or structs), and nested types (records inside other records, etc) are all built-in. As are doubly-linked lists. Our "Noodle" library also includes a handy general-purpose hash table structure that is used for compiler symbol tables, spell checking, etc. Other structures can easily (and educationally) be implemented by the student himself, when necessary. The curious thing is how unnecessary we found those other structures to be when writing a program both so broad and deep in scope.

And finally, the fact that you think English is good for programming is simply stupid. English is a terribly ambiguous language. Everything I have said in this post could have been said 10,000,000 different ways while still conveying the same meaning.

That's clearly hyperbole. The set of all potential English sentences is indeed huge; but the set of all sentence-forms that people actually use is relatively small. And the set of typical imperatives is smaller still. But if you think English is so bad for communication, and artificial languages are so much better, try writing your next post entirely in the programming language of your choice and you'll quickly see how limited it is. In fact, you'll probably end up with a Hybrid post: a natural language framework with snippets of special syntax where convenient -- which is exactly what we've been proposing.

Programming is about specificity and exactness.

No, programming is about telling a machine to do something. And the future of programming is about telling a machine to do something in the most natural and convenient way.

English wasn't designed for programming, nor was any natural language.

English has been successfully used for millennia to communicate thoughts (and, more specific to our application, commands) to others. It's no where near as bad as you make it out to be. Every successful procedure manual ever written, every instruction sheet, and yes, our Plain English system itself attests to the viability of English as a tool for productive communication. Granted, special syntaxes and graphics are helpful in certain cases; but such things are almost always found in the context of a natural language framework. Think about it. When Einstein wanted to express some thoughts that were in his mind -- and could express them in any form he chose -- he used the Hybrid approach: a natural language framework with snippets of formulas and graphics where more convenient:

This is the most natural way for us to communicate written thoughts to others. Think of a teacher in a classroom (at any educational level): he speaks -- that's the natural language framework -- and then writes formulas and draws diagrams on the board. Think of any typical text book: math, physics, biology, whatever. Think of technical whitepapers. Etc, etc.

The closest (semi-spoken) language that could be use is esperanto which was designed to be as unambiguous as possible.

Yes; and people don't like that kind of thing. It's unnatural. So instead of trying to change the way people communicate, we've opted to teach the computer how to understand people.

As far as languages go, english is probably one of the worst designed languages available.

Sure. But there it is.

Because it evolved as sort of a mixing pot of languages and language ideas, it has way too many rules, nuances, and inconsistencies. English is spoken completely differently in England, Scotland, Ireland, India, Texas, Idaho, New York, or Jamaica.

Sure. And our system allows for local dialects and modes of expression. Sometimes unusual in the eyes of outsiders, but intelligible nevertheless.

As a programmer, it would be horrible trying to understand what is going on just because someone is writing something using a different dialect.

It's not as bad as you make it out to be. When someone travels from New York to Alabama, they get by without any serious difficulty.

 

[Markbnj]

I wrote a Tetris clone in VB. Do the same in your natural language. This should be right up your alley, there is no complicated math involved. Or better yet, have someone who has never programmed before (but knows the game well) write one using your natural language. You will have me firmly in your court if you can. Standing by.

This would be a good idea as well. Simple games are often chosen for demo programs because they touch on every aspect of what a modern language has to enable: input, timing, events, looping, logic, drawing, etc.

If Tetris isn't up your alley, Gerry, feel free to port my C#/WPF rendition of Conway's Game of Life. Link to an archive with binaries and sources is at the bottom of the page.

 

[Markbnj]

It's a wonder, then, that our code is so simple and reliable. In over eight years of productive use, only a handful of inconsequential bugs have turned up, and a serious defect in the compiler is yet to be found.

"We", "our", you use these terms almost exclusively and yet you're the only one here. I find that remarkable. If the author of a newer language with just some minor adoption, Go or Rust for example, were fighting for his ideas on a programming forum you'd have an actual "we" taking part. Not that I flatter myself that anyone knows about this place, but Reddit and Hacker News are a different story. So that's another thing that would help your deflated credibility: if one or two of these working programmers you've trained were writing about your system and ideas and supporting them.

As far as the "eight years of productive use" comment, you can define "productive" any way you want. But I think there is a certain base standard of "productive use" when we talk about programming languages and tools. So far you've linked nothing, and shown nothing, to indicate there has been any use of the system beyond your own farting around with ideas. If anyone, anywhere, is using this system to do "productive work" they're welcome to come here and talk about it. I don't think that's going to happen, because I think your comment is bullshit. I'll happily apologize here if you can show me that I'm wrong.