Hello!
I'm the co-author of the Plain English programming language which (if you are interested) you can read about here:
http://www.osmosian.com/instructions.pdf
I'm thinking of creating a version that will work with the Arduino and I'm wondering (a) if there's any interest in such a thing, and (b) if anyone here would like to help with the Arduino side of the project (I'm familiar with microprocessors, but have not yet worked with an Arduino).
Thanks!
I gave up after page 15 (skim read only).
Weedpharma
Ugh! Nasty font, hurty eyes.
I like your example
hold your nose, open up the noodle, and use the Find command (like we discussed earlier) to search for the words TO START UP followed by a colon. Routines always start with the word TO, and their headers always end with a colon.
my humor runs parallel to yours. when eating.... it always ends up with a colon.....
Note that there are no unintuitive, distracting, space-consuming scroll bars
anywhere in my interface. To scroll, press the right mouse button and shove.
No scroll bars. Instead, you get to guess how to make things move. Been using you iWhatever too long, I suspect.
It seems, perhaps, that we're getting distracted by incidentals (fonts, scroll bars, etc). The question is would we rather have the Arduino programmer burdened with this:
void setup() { // the setup function runs once when you press reset or power the board
pinMode(13, OUTPUT); // initialize digital pin 13 as an output.
}
void loop() { // the loop function runs over and over again forever
digitalWrite(13, HIGH); // turn the LED on (HIGH is the voltage level)
delay(1000); // wait for a second
digitalWrite(13, LOW); // turn the LED off by making the voltage LOW
delay(1000); // wait for a second
}
Or free to "code what he is thinking" like this:
To run:
Make pin 13 an output.
Loop.
Turn on pin 13.
Wait for 1 second.
Turn pin 13 off.
Repeat.
I know I'd be way more attracted to the latter. And I think the comments in the "C" code above prove my point -- that's what the programmer was thinking when he wrote the "C" code, and that's what he wants the reader of the code to think; in short, that's what he wanted to say.
So why not let him say it?
Note: Plain English programming supports alternative but equivalent expressions. So...
Turn on pin 13.
Turn pin 13 on.
Set pin 13.
Make pin 13 high.
...all mean the same thing to the compiler, as they do to a typical English-speaking person.
Or free to "code what he is thinking" like this:
To run:
Make pin 13 an output.
Loop.
Turn on pin 13.
Wait for 1 second.
Turn pin 13 off.
Repeat.
And now tell us, in plain English, why it doesn't work . 
I was serious about the hurty eyes - presentation isn't at all "incidental"
AWOL:
And now tell us, in plain English, why it doesn't work .
Doh! Forgot to wait for another second at the bottom of the loop. But isn't it great that we can both (a) discuss the problem in English, and (b) code the solution in the very same terms:
To run:
Make pin 13 an output.
Loop.
Turn on pin 13.
Wait for 1 second.
Turn pin 13 off.
Wait for another second.
Repeat.
AWOL:
I was serious about the hurty eyes - presentation isn't at all "incidental"
You're right -- presentation is important. That's why, for example, every topic in our instructions occupy exactly one page! Don't see that every day.
We chose the font (a) to make it immediately clear that Plain English is different than other programming languages, and (b) as a tribute to my elder son and co-author of the compiler (the font is a digitized version of his handwriting). Incidently, most people like the font. The compiler's been on the market for over ten years and we've gotten lots of comments, pro and con, as you might expect. But mostly pro when it comes to the font. And it's easy to change if you don't personally like it.
I think it's a neat idea. If this was a professional presentation with some Adult* documentation, and some real world examples, then yes, I could see me doing more research into your language.
*Sorry, but that PDF reads like it was for 10 year olds. And if you are aiming for that age group, you are doing a fine job.
codlink:
I think it's a neat idea. If this was a professional presentation with some Adult* documentation, and some real world examples, then yes, I could see me doing more research into your language.*Sorry, but that PDF reads like it was for 10 year olds. And if you are aiming for that age group, you are doing a fine job.
As a matter of fact, our documentation was written with 10 year olds in mind!
And we consider our development system itself a "real world example" of programming in Plain English. After all, it's a complete IDE, with a unique interface, a simplified file manager, an elegant text editor, a hexadecimal dumper, a native-code-generating compiler/linker, and the wysiwyg page layout facility that we used to create the documentation -- and it's coded entirely in Plain English. It's small (less than a megabyte), it's efficient (it can re-compile itself in less than 3 seconds on a bottom-of-the-line machine from Walmart), and a single version of the program runs stand-alone (and looks and behaves exactly the same) on any version of Windows from XP to 10.
Feel free to write me directly if you're interested in this project: gerry.rzeppa@pobox.com
Details are important!
I would never get a book using a font like that.
I assume you are not serious in the least in doing so.
.
LarryD:
I would never get a book using a font like that.Iassumeyou are not serious in the least in doing so.
I'll use the forum's default font for this post so you can see how serious I am. I'll use the standard emojis, too! 
Here's a quote from page 41 of the manual that comes with the Arduino Starter Kit:
It can be helpful to write out the flow of your program in pseudocode, a way of describing what you want the program to do in plain language, but structured in a way that makes it easy to write a real program from it. In this case you're going to determine if switchState is HIGH (meaning the button is pressed) or not. If the switch is pressed you'll turn the green LED off and the red ones on. In pseudocode, the statement could look like this:
if the switchState is LOW:
turn the green LED on
turn the red LEDs offif the switchState is HIGH:
turn the green LED off
turn the red LEDs on
Now with our Plain English compiler, "pseudocode" is real code -- statements like those actually compile and run. Which seems like a step in the right direction to me. And what the guy who wrote the Starter Kit Manual wished he had!
Easiest way to proceed would be to write a plain-english to C compiler. You'd then compile this with the same tools that the ardiuno IDE uses.
Why not write that plain-english converter in plain-english? The initial C would have to be hand-coded, of course. But after that you are using your new, simple language to refine things.
Incidentally, there was a previous attempt to make programming more accesible in this the way that you are trying to do, and you should look into it. The result was called "Common Business Oriented Language". You'd write "ADD TRANSACTION_AMOUNT TO BALANCE" and so on.
It turns out that programming is inherently difficult, and you can't make it easier by adding english-language noise words. But it was a brave attempt and the language experienced some degree of commercial success.
I often wondered if COBOL had a German version, where the verb came at the end of the statement.
PaulMurrayCbr:
Easiest way to proceed would be to write a plain-english to C compiler. You'd then compile this with the same tools that the ardiuno IDE uses.
Our compiler converts Plain English source directly into a Windows PE-style executable full of Intel x86 machine code; turns out it's not that hard to do -- no need for an intermediate language (like C). I imagine that the conversion to code compatible with the Arduino would be even easier since the number of data types and functions available on an Arduino is small compared to a full-fledged Windows machine. And since we'll have no intermediate language, the student (who looks into our compiler) will have an easier time seeing how the conversion from Plain English to Arduino is done.
PaulMurrayCbr:
Why not write that plain-english converter in plain-english? The initial C would have to be hand-coded, of course. But after that you are using your new, simple language to refine things.
Our compiler is already written in Plain English; I haven't programmed in anything but Plain English for years.
PaulMurrayCbr:
Incidentally, there was a previous attempt to make programming more accesible in this the way that you are trying to do, and you should look into it. The result was called "Common Business Oriented Language". You'd write "ADD TRANSACTION_AMOUNT TO BALANCE" and so on... it was a brave attempt and the language experienced some degree of commercial success.
I like COBOL. And it's still a very popular and widely-used language. According to the microFocus people, "COBOL still runs over 70% of the world’s business and more transactions are still processed daily by COBOL than there are Google searches made." See:
But Plain English is different in several important respects. I'll describe just two:
Plain English allows spaces wherever spaces are normally found in written English. "The red LED," for example, is a valid and typical variable name. And "Turn the red LED on" is a valid and typical routine call.
In Plain English, as in real life, variables are described rather than artificially named. For example, in real life the chair I'm sitting on, and the screen I'm looking at, don't have proper-noun names: I simply call them "the chair" and "the screen." And that's what I'd call them in Plain English. I wouldn't, for example, feel the need (or be required) to assign artificial names like "c" to the chair or "s" to the screen.
PaulMurrayCbr:
It turns out that programming is inherently difficult...
I beg to differ. I've been an educator for more than four decades and my motto has always been, If it's hard, it's wrong. And I've always been able to find a way to make any subject easy for my students.
PaulMurrayCbr:
...and you can't make it easier by adding english-language noise words.
Again, I beg to differ. But rather than repeat a discussion I've had many times with many people, I'll just point you to the most interesting and complete record of one (which, incidently, has been viewed over 37,000 times):
AWOL:
I often wondered if COBOL had a German version, where the verb came at the end of the statement.
I don't know about COBOL, but we've had serious discussions with people who want to, or who are in the process of, translating our Plain English compiler into Plain Spanish, Plain Portuguese, Plain French, Plain German, and Plain Russian. Turns out that the deceptively simple parsing mechanism we implemented works well in any language.
I'm sure you'll think I'm being facetious, but the inspiration for the technique was based on two things: (1) close observation of my youngest, Chuckles, during his first couple of years, and (2) this comic by Gary Larson:
It became apparent to us that when we would say something like, "Time to suck on your bottle little buddy," what Chuckles actually heard was something like, "Blah, blah, SUCK, blah, blah, BOTTLE, blah, blah."
So it dawned on us that he must have a "type name" called BOTTLE somewhere in his left brain connected to a "type definition" (probably in the form of a picture) in his right brain, and a pre-compiled "routine" in his back brain with an associated left-brain "routine header" something like, "To SUCK a BOTTLE." And that he would eventually learn the inessential nuances of the language primarily by rote—simply by mimicking the speech patterns of his elders.
We thus developed our compiler along those lines, with local and global variables representing instantiated types (like Chuckles' actual bottle), taking great care to key only on articles, prepositions, conjunctions, and various forms of the verb "be" (which almost all languages have). The basic idea being that an imperative sentence could be considered understood when a matching routine header was found—even if the match was partial or sloppy.
The result, surprising as it may be to some, is a convenient, efficient, and remarkably reliable programming language where the natural-language vocabulary -- and even much of the grammar -- are defined by the user in his type, variable, and routine header definitions. It's a language that "learns" the "local dialect" simply by being used.
Plain English programming language
Hmm. OK, I guess.
Copyright © 2006
So, how's that been going for you? I guess that means that calls for more professional documentation or changes in design are unlikely to be heeded. Nevertheless...
I really don't want to read language reference manuals that spend a lot of their time complaining about the OS they run on, other languages, perceived style issues, and so on...
As a matter of fact, our documentation was written with 10 year olds in mind!
I will quickly take over your screen so you no longer have to look at that painted whore of an interface that comes with the kluge.
:
I see you're trembling. Don't be afraid. This may be the first time for you, but I'm an old hand at this. ... Was it as good for you as it was for me?
Right.
I see you've invented a new style of GUI, and Yet Another Set of editor keyboard shortcuts and mouse-directed movements. And vocabulary. Swell.
I don't do nested IFs.
I don't do nested LOOPS.
Really?
I'm thinking of creating a version that will work with the Arduino and I'm wondering (a) if there's any interest in such a thing
Not from me... I didn't like COBOL either.
(And yes - I listened to a talk by Grace Hopper once (online, in person - I don't remember) and she said that they did foreign language versions as part of a demo, but were told that that was just showing off, or something like that.)
Well, if you are generating windows executables, then generating arduino executables can't be that difficult. The main thing is the hardware abstraction layer that the existing arduino IDE supplies. Your compiler will have to do the same job of reading the board descriptions and working out how to convert a digitalWrite to a poke to the correct memory address.
The other main thing is providing some sort of layer allowing Plain English to use the existing C++ libraries - Serial, Servo and all the rest. You don't want to go re-writing them.
westfw:
I don't do nested IFs.
I don't do nested LOOPS.Really?
So every little control construct needs its own named block. Inevitably, these named blocks will be called something that basically re-hashes the conditions in the chain of ifs and loops that would otherwise surround it:
PROC thing_to_do_when_switch_1_is_on_and_we_havent_timed_out_and_the_motor_is_running_OR_the_override_switch_is_off
tell digital output 5 to be on
END PROC
A difficulty is that we deal with things that dont have nice plain-english names. When you set the SLC output on your XYZ667, the native way to name your variables is "SLC", because of the subject matter.