My (predictable) response: PropBASIC gets pretty darn close to "plain English" but without the tedious typing. At least, this lazy programmer would find the typing to be tedious. I am all about self-documenting code, mind.
I much prefer BASIC syntax to C. But let's look at a couple of (non-BASIC) examples because the differences are not always as big as one might expect. Here's how a typical programming language might draw a box on the screen:
That's 10 words and 11 punctuation marks: 21 total elements.
The Plain English equivalent would be:
Draw the substring in the box with the color and the source's text's font and alignment.
Which is 16 words and 3 punctuation marks: 19 total elements. Admittedly, the Plain English version requires a few more easy-to-type alphabetic characters (it's difficult to say exactly how many since traditional coders put spaces in different places); but I think that's a small price to pay for not having to learn (or think in) an artificial syntax.
Here's another example (I've got a million of 'em):
if ( ! source.colorized ( ) ) color = black ;
Which is 5 words and 8 punctuation marks: 13 total elements.
The Plain English would read:
If the source is not colorized, put black into the color.
Which is 11 words and 2 punctuation marks: 13 total elements. Again, it's mostly a matter of whether you like to type words or punctuation. And whether you like to think in two different syntactical and grammatical forms simultaneously. And whether you want your code to be self-documenting. And whether you want code that's friendly for beginners. And whether you want to code in a language (like English) that will still be in common use 100 years from now. Personally, I believe that anyone who thinks "if (!source.colorized())" is a reasonable way to express one's self has lost touch with the rest of humanity!
What a fascinating discussion. Hope you don't mind if I disagree here and there. In a friendly way.
I'm not one to argue that we should focus on minimizing keystrokes. When it comes to it most of the time you spend programming is not spent typing, but rather thinking about what it is you want to do and how best to do it. Then you spend a lot of time wondering whey it does not work as expected...actual typing is the least of your worries. Source code should be easily readable, by yourself a year later and by others who want to use it or learn from it. As such reducing everything to weird punctuation and operators and meaningless short variable names is not a good idea. As a simple example I would rather see "x = x +1" in the source than "x++". Or is it "++x"? or which one do I mean here....The latter is confusing and error prone.
That said, personally I would go for the examples in red that you posted above rather than the blue. Why, it's easier to read, it has no redundant "the" all over the place, it's concise and precise. This becomes even more so when things get a bit complicated.
I'm not sure that when one does a lot of programming one thinks in two syntactical forms simultaneously. At some point you are no longer thinking in syntax any more than when you are speaking in your native language. Admittedly if you find yourself working with two similar languages at the same time, say C and Java you will get tripped up by automatically typing one syntax when you are working on the other, or assuming the wrong semantics for something.
Clear, self documenting code is an ideal. It's not clear to me that either of your examples demonstrate self documenting better than the other.
Code that is friendly for beginners is a great idea. That was the motivation behind BASIC, and SmallTalk and Logo and others. Even Javascript was designed for the non-programmer to get simple things done, despite that fact that it is quite a sophisticated language that can keep experts happy.
Recent times have shown that beginners get along quite well with C++ (see Arduino), Javascript (see the entire web), BASIC (see Mircrosoft world), Spin (See Parallax Propeller).
And whether you want to code in a language (like English) that will still be in common use 100 years from now.
That is rather skipping over a very large detail. Most of the world does not speak English. Right there is a huge barrier to an excessively verbose English based language. Admittedly all the languages I know have a few short keywords in English, but I'm betting that if those were replaced with some Chinese or Arabic squiggles we could get used to in a short time. English is of course a moving target given the rate that it mutates.
Personally, I believe that anyone who thinks "if (!source.colorized())" is a reasonable way to express one's self has lost touch with the rest of humanity!
I sort of agree. Those "( )" used with "if" in C are redundant and annoying. In your example "colorized" may as well be a property of the "source" object so those "( )" following it are redundant as well. Basically C messed a few things up when it evolved from B or BCPL or whatever it was. C++ made it worse!
But, as it happens humanity includes mathematicians, doctors, lawyers and so on, all of whom evolve their own notations and short cuts and so on to make communications between themselves about the subject at hand simpler and quicker. Often us humans on the outside have no idea what they are talking about.
By the way, you spelled colourised wrong. So much for Plain English
Furthermore, PropBASIC spits out pure PASM code with zero overhead so not only is it the most readable language available for the Prop, it also produces the fastest code.
The Plain English would read:
If the source is not colorized, put black into the color.
This is an interesting idea and discussion.
For the example above, could it be written:
If the source is not colorized, make the source black.
or
If the source is not colorized, make it black.
or
Make the source black if it is not colorized.
I can see one thinking any of the above are perfectly acceptable variations of the original statement. If Plain English requires a strict adherence to a certain phrasing and arrangement of keywords, then I can't see it being easily usable. Presenting a syntax that is real close to English but having to adhere to specific structure without the flexibility that people use in their plain English will make it very tedious and frustrating when trying to describe a problem to the computer.
Plain English will catch on when it is able to handle natural English and understand variations of the same idea as shown in the examples above.
To me, the chained possessives in this example are just awkward and not the way I would say or write this in English
The Plain English equivalent would be:
Draw the substring in the box with the color and the source's text's font and alignment.
"...the font and alignment of the source's text" seems clearer to me. If that is not what is meant then there is an underlying problem with Plain English. It has the flexibility of English which also allows the potential ambiguity of English sentences.
I won't continue with the multi-platform discussion - that's a can of worms for another fishing trip!
You have a lot of points there Gerry. Too many to quote them all so I'll just ramble on a bit...
I would not call myself a typical Linux programmer. Have programmed many things, large and small, in many languages starting before Linus Torvald's knew what a computer was. I'm not proposing that your end users have to use a command line, clearly that is not your goal. However it seems like good practice to me to have a "separation of concerns" in a large project. The compiler is not the IDE, or the documentation system or the program delivery system/package/installer. The compiler can be it's own module or subsystem which can be built into the IDE or a command line program or whatever.
I do agree that the source code for the Plain English compiler/IDE should be Plain English itself. In the same way that C and C++ compilers are written in C and C++. Pascal compilers are written in Pascal, etc, etc.
However, presumably when you started there was no Plain English compiler to compile itself with. Presumably you wrote the original Plain English, or a subset of it, in C++ or Visual Bascic or whatever.
How did you bootstrap it?
If Plain English can compile itself then all you need do is tweak the code generator to produce ARM executables and you soon have the Plain English system up and running on a Raspberry Pi or whatever.
I also agree that "the same GUI everywhere" is a good idea. Presumably you have used the Win32 API or whatever Windows has now for getting stuff on the screen. My only suggestion is to use something like the Qt or Lazarus API instead. Then you have a portable program with the same look and feel everywhere. It need not look like Qt or Lazarus, just use the low level services they offer, as you probably do in Windows.
Your use of "wysiwyg" tickled me. It's a term that entered the Oxford English Dictionary in the 1980's or so. I have not heard anyone use it for decades now. Still what this forum software does is besides the point.
As long as our program still runs, the programs coded with our system will also run. I'm not sure one can ask for more than that.
I can, a lot more
Firstly your program does not run here. Not unless I buy myself a Windows machine. Or go out of my way to install wine and even that can be hit and miss. (Which I will probably do out of curiosity).
Similarly your program does not run for Mac owners.
Lastly, it will only run as long as there is a Windows platform around to run it on.
Similarly your program does not run for Mac owners.
I think that he has not stated that to be a fact, maybe just using Windows here because that is the norm here.
I think it has been mentioned a couple of times that Plain English was created about ten years ago, so has it been in the field, being used by other people and groups all that time? If so, does Plain English have a substantial following?
The way I understand the description of Plain English is that it is a programming language, but I get the impression that it is more of an interactive problem solving program. We have had plenty of discussion here about having an interactive program for the Propeller, other than Forth.
Using the QuickStart board as an example, having eight LEDs and eight touch pads, I wonder how Plain English would deal with working with those items.
Yes, I find Plain English to be a very interesting concept, how it would work with the Propeller boards that are available is still a mystery to me.
I'm just a hobbyist but I think the point I want to make is relevant. Prop1 is here to stay. Prop2 is not here yet but it cannot replace Prop1 any more than luxury cars could ever replace commuter vehicles.
I'm hoping one of our senior programmers will offer whatever assistance you seek.
Regarding hosting Plain English on a Propeller 1 ... Most of the Propeller boards have video and/or VGA outputs and some of the boards have PS/2 inputs for a keyboard and/or mouse. Both can be added to pretty much any board using a few resistors and capacitors (see Cluso99's 1-pin keyboard and video drivers here). Several mouse drivers are also available. One cog gets used for the display and one cog gets used for handling the keyboard and/or mouse. They communicate with other cogs (presumably running Plain English programs) through shared "hub" memory locations (in the 32K shared memory). Similarly, a lot of Propeller boards have a micro-SD card socket and there are several SD card drivers that use another cog for the high speed I/O for the SD card.
Typically, a high level language like Plain English is run on the Propeller using an interpreter running in one or more cogs with the interpretive code and its data residing in the "hub" memory. Sometimes the interpretive code is kept externally in an EEPROM or serial RAM which can be quite large and paged into the "hub" on demand. An SD card file can also be used for this with an often quite reasonable performance "hit". C and C++ programs can optionally be compiled this way for large programs. Spin programs and data, for example, reside in the "hub" and the interpreter is stored in an on-chip ROM, read automatically into a cog for execution as needed.
As another example, there's a board sold by Cluso99 that has a 512K static RAM and micro-SD card designed for use as an Intel 8080 or Zilog Z80 CP/M machine. It can use the 1-wire display and keyboard drivers and emulates floppy drives and small hard disk drives using SD-card files ... runs standard CP/M and all the huge libraries of CP/M applications at nearly original hardware speeds.
But, as it happens humanity includes mathematicians, doctors, lawyers and so on, all of whom evolve their own notations and short cuts and so on to make communications between themselves about the subject at hand simpler and quicker. Often us humans on the outside have no idea what they are talking about.
We believe the ideal and "final" programming language will be a hybrid, as a math book (or even this post) is a hybrid with three kinds of elements: (1) a natural language framework with (2) snippets of specialized syntax and (3) graphics as appropriate. Here's a page from one of Einstein's notebooks:
Note that when he's not thinking about programming languages, but simply trying to express himself as clearly and concisely as possible, he begins with (1) a natural language framework, German in this case, inserts (2) a mathematical snippet here and there, and includes with some difficulty, (3) a graphic.
Our ultimate goal is to be able to compile and run pages like that. And Plain English, we think, is a step in that direction because, instead of making the formulas the framework (as most programming languages do), and instead of making the graphics the framework (as a lot of "kiddie" languages do), we (very naturally) make the natural language the framework. The rest is sub-compilers which are easy to write and include in that framework.
By the way, you spelled colourised wrong. So much for Plain English
Yes, funny. The version of Plain English currently under development supports statements like...
Color, colour, coler, and coller are synonyms.
So alternate (and even mis-) spellings in vocabulary can be understood. The current version already handles similar grammar problems (eg, where the programmer uses IS instead of ARE or AIN'T instead of ISN'T).
One of the great features of Plain English is that both the vocabulary and the grammar of the language are determined primarily by the programmer. For example, when he says...
A flapnabble is a thing with a size and a color.
...the vocabulary of the language has been increased; the compiler now "understands" the word flapnabble. And when he defines a routine with a header like this...
To draw a flapnabble;
To take a flapnabble and render it;
To put a flapnabble on the screen;
To git a flapnabble up on that there tv thingy:
...the compiler now "understands" a variety of new verbs and grammatical forms.
To me, the chained possessives in this example are just awkward and not the way I would say or write this in English. "...the font and alignment of the source's text" seems clearer to me.
Yes, possessives are simply shortcut-prepositional-phrases moved to the front in English: "Bill's house" is thus short for "the house of Bill." And you're right that we rarely chain possessives together in ordinary speech, typically because we rely on context for the uppermost nouns. The version of Plain English currently under development addresses both of these problems.
We had a Pascal-like language without all those annoying semicolons that we had developed using an early version of Delphi. We used that to create the CAL-1000 -- just enough of an IDE and compiler to recompile itself. We then used that to create the CAL-2000 series, the CAL-3000 series (the current release is the CAL-3040), and we're working on the CAL-4000 series. So it's been Plain English only for a long time now.
If Plain English can compile itself then all you need do is tweak the code generator to produce ARM executables and you soon have the Plain English system up and running on a Raspberry Pi or whatever.
It's not the compiler part that's difficult -- it's the "standard library" part. Windows' event-processing mechanism, for example, is not at all like XDE's or Gnome's or whatever the Pi people are using these days. Simply clearing the freaking screen or getting a machine to beep (without loading a whole MP3 player) is very non-trivial these days.
I also agree that "the same GUI everywhere" is a good idea. Presumably you have used the Win32 API or whatever Windows has now for getting stuff on the screen. My only suggestion is to use something like the Qt or Lazarus API instead.
The fact that there's an "or" in that last clause illustrates the problem. We know that the Win32 API is already installed on every Windows desktop, and that it will behave as expected. No installation instructions needed, no customer support necessary. We don't know what's on that kid's Pi: Qt? Lazarus? Neither? So we can't just say, as we do with Windows, "download and double-click."
If I thought the Pi was a good target, I think I'd sell the hardware with the software so I could pre-configure the "firmware" for consistency and simplicity. But now comes the rub, and this is important: A pre-configured Pi (with keyboard, mouse, and display) is going to cost as much or more than a cheap Windows laptop (and it will look like a kludge, to boot). So I think I'd rather sell the kid a Windows laptop with Plain English pre-installed. Or, as we do now, just let him download our software and double-click. In any case, those are the options to beat. Show me how I can make Linux as simple, elegant, complete, consistent, and cheap as those alternatives and you'll have my full attention.
Your use of "wysiwyg" tickled me. It's a term that entered the Oxford English Dictionary in the 1980's or so. I have not heard anyone use it for decades now. Still what this forum software does is besides the point.
I don't think so; it causes me grief every time I post. Edit here, preview there, come back to edit some more. Very primitive. And when I try to print one of these posts off so my wife can read it, I'm sent to another kind of preview screen (that often doesn't have what I want on it) and... well, the root problem is the way the world has abandoned the wysiwyg paradigm that made the Mac the seminal machine that it was.
Firstly your program does not run here. Not unless I buy myself a Windows machine. Or go out of my way to install wine and even that can be hit and miss. (Which I will probably do out of curiosity). Similarly your program does not run for Mac owners. Lastly, it will only run as long as there is a Windows platform around to run it on.
Touche. But the very same code, unchanged for ten years, did and does run on over 84% of the desktop computers in the world. Add 'em up:
Not bad for guy and his kid coding for a few months in the back bedroom!
I think it has been mentioned a couple of times that Plain English was created about ten years ago, so has it been in the field, being used by other people and groups all that time? If so, does Plain English have a substantial following?
I wouldn't exactly say "substantial." People tend to love it or hate it. It's used mostly for education, but not widely yet.
The way I understand the description of Plain English is that it is a programming language, but I get the impression that it is more of an interactive problem solving program. We have had plenty of discussion here about having an interactive program for the Propeller, other than Forth.
It's not interactive except in the sense that it compiles quickly enough so you can make a change, try it, make another change, etc. Less than a second turnaround, though that would probably be longer when we add in the time to download to the Propeller.
Using the QuickStart board as an example, having eight LEDs and eight touch pads, I wonder how Plain English would deal with working with those items.
Your code would probably say things like:
The start button is on pad 1.
The stop button is on pad 2.
The red LED is on pin 3.
The green LED is on pin 4.
...
If the start button is down, turn off the red LED; turn on the green LED.
If the stop button is down, turn off the green LED; turn on the red LED.[/qolor]
I'm just a hobbyist but I think the point I want to make is relevant. Prop1 is here to stay. Prop2 is not here yet but it cannot replace Prop1 any more than luxury cars could ever replace commuter vehicles. I'm hoping one of our senior programmers will offer whatever assistance you seek.
Thanks. What kind of applications do you use the Prop1 for? Why the Prop1 instead of something else?
I think you have something very clever and fascinating here. I say that after looking over your github repo. So forgive me if I have some questions/comments:
You have expressed a disdain for "objects" and "object oriented" programming. But in the post above I see:
A flapnabble is a thing with a size and a color.
Which sounds like a class of objects that derives it's properties from "thing" and adds "size" and "color" properties.
Presumably one could write:
A superflapnabble is a flapnabble with a superpower.
Which would be object oriented programming with inheritance.
If that is not the case presumably one would write:
A flapnabble has size and a color.
Which is just a structure that inherits from nothing.
Also in your compiler source on github I see:
to add a fragment given a tag and a variable and a number:
if the current routine is nil, void the fragment; exit.
create the fragment given the tag.
append the fragment to the current routine's fragments.
put the variable into the fragment's variable.
put the number into the fragment's number.
set the compiled flag in the variable.
to add an import to some imports given an import name:
create the import.
append the import to the imports.
put the import name into the import's name.
to add an intermediate given a type name and a locus:
if the current routine is nil, void the intermediate; exit.
add the intermediate to the current routine's locals given "local" and the locus.
generate the intermediate's name given "~I".
put the type name into the intermediate's type name.
resolve the intermediate.
Which looks very much like operator overloading in C++.
It looks to me like Plain English does indeed use classes and objects and object oriented programming.
Sadly, I have no way to bring up Plain English on any machine I own or use from day to day so as to be able to check all this out.
I agree Windows is everywhere. But it seems to me that the audience you want to reach is using Arduino or Pi.
I also agree that selling a Pi with a ready made OS and Plain English installation is a non-starter.
But, given all the inconsistency of "non windows" platforms then why even think about supporting the Propeller?
Looking at your posted browser statistics I can only conclude that Javascript is the language to use. It's everywhere. Clears the screen and beeps just fine.
Please don't think I'm bashing on the Plain English idea or all your work, I'm just trying to get to grips with the idea here.
Regarding hosting Plain English on a Propeller 1 ... Most of the Propeller boards have video and/or VGA outputs and some of the boards have PS/2 inputs for a keyboard and/or mouse. Both can be added to pretty much any board using a few resistors and capacitors (see Cluso99's 1-pin keyboard and video drivers here). Several mouse drivers are also available. One cog gets used for the display and one cog gets used for handling the keyboard and/or mouse. They communicate with other cogs (presumably running Plain English programs) through shared "hub" memory locations (in the 32K shared memory). Similarly, a lot of Propeller boards have a micro-SD card socket and there are several SD card drivers that use another cog for the high speed I/O for the SD card.
Having a VGA output and having a VGA output with a reasonably complete set of graphics primitives (from "set a pixel" to "blit some bits" to "draw a line, clipping to an arbitrary region") are not, as I'm sure you know, quite the same thing. Likewise, a PS2 port for a keyboard is not the same thing as having a port plus an event-processing mechanism to handle key combinations, key repeats, etc. In short, it seems to me a lot of work would be required to build up sufficient infrastructure on the Propeller to support our Plain English IDE.
Typically, a high level language like Plain English is run on the Propeller using an interpreter running in one or more cogs with the interpretive code and its data residing in the "hub" memory. Sometimes the interpretive code is kept externally in an EEPROM or serial RAM which can be quite large and paged into the "hub" on demand. An SD card file can also be used for this with an often quite reasonable performance "hit". C and C++ programs can optionally be compiled this way for large programs. Spin programs and data, for example, reside in the "hub" and the interpreter is stored in an on-chip ROM, read automatically into a cog for execution as needed.
Plain English is a difficult language to interpret on-the-fly because most of the information needed to properly "understand" a given statement is contained elsewhere in the program -- the vocabulary and grammar of the language are deduced from the whole of the code submitted to the compiler. Our compiler makes three passes at the source code when compiling. I suspect a Plain English interpreter would need more memory for "symbol tables" and "dictionaries" than is available on the Propeller. Unless, as you suggest, these things were kept externally and we could solve the ensuing performance problems. On the whole, it doesn't appear to be a very straightforward conversion due to the vast differences between a Propeller and a Windows machine.
As another example, there's a board sold by Cluso99 that has a 512K static RAM and micro-SD card designed for use as an Intel 8080 or Zilog Z80 CP/M machine. It can use the 1-wire display and keyboard drivers and emulates floppy drives and small hard disk drives using SD-card files ... runs standard CP/M and all the huge libraries of CP/M applications at nearly original hardware speeds.
Please don't think I haven't followed similar thought patterns (and searches) before. The bottom line is that, for programs that require a lot of high-level graphics facilities and a lot of memory, it's hard to beat something like a Raspberry Pi (if one can stomach Linux) or a cheap Windows laptop if one cannot. In other words, instead of trying to turn a Propeller into a laptop computer, it seems easier to turn a laptop into something like a Propeller by adding digital I/O and such via USB. I may very well be wrong, of course; I haven't done a lot of microcontroller stuff for some years now. But when I can readily get a fast processor, gigs of memory, a display, a speaker, a touchpad, WiFi, and a USB port in an elegant little package for $50 using a tablet, it's hard to think "building up" something like that "from scratch" is advantageous. I wish it wasn't so. Takes a lot of the fun out of it.
..it seems easier to turn a laptop into something like a Propeller by adding digital I/O and such via USB..
No. That cannot be done.
Or should I say, yes you can wiggle an I/O pin on the end of a USB cable.
But the magic of the Propeller is that it is small, and cheap, and low power, and one can wiggle pins with almost nanosecond precision. That and it's amazingly easy to program in assembler. Almost no need for a high level language to do things at that level.
Of course if that is not what one wants to do then it's perhaps better to look at something else.
We had a Pascal-like language without all those annoying semicolons that we had developed using an early version of Delphi. We used that to create the CAL-1000 -- just enough of an IDE and compiler to recompile itself. We then used that to create the CAL-2000 series, the CAL-3000 series (the current release is the CAL-3040), and we're working on the CAL-4000 series. So it's been Plain English only for a long time now.
If Plain English can compile itself then all you need do is tweak the code generator to produce ARM executables and you soon have the Plain English system up and running on a Raspberry Pi or whatever.
It's not the compiler part that's difficult -- it's the "standard library" part. Windows' event-processing mechanism, for example, is not at all like XDE's or Gnome's or whatever the Pi people are using these days. Simply clearing the freaking screen or getting a machine to beep (without loading a whole MP3 player) is very non-trivial these days...
If you want to avoid the variances of Linux, then perhaps look at some of the Bare-Metal work on the Pi :
I think you have something very clever and fascinating here. I say that after looking over your github repo. So forgive me if I have some questions/comments: You have expressed a disdain for "objects" and "object oriented" programming. But in the post above I see:
A flapnabble is a thing with a size and a color.
Which sounds like a class of objects that derives it's properties from "thing" and adds "size" and "color" properties.
Good catch. But record extension (which is what this is) is quite different than OOP. With OOP, verbs (commands, functions, methods, whatever you want to call them) are bundled with nouns (object, classes, whatever name is currently popular). In Plain English, nouns (types) are one thing, verbs (routines) are another, and the two are kept separate (as in real life). Simple example:
A wheel is a...
A bicycle has two tires...
Here we have two types (objects): bicycles and tires. Now I want to write a routine to mount a tire on a bicycle. Do I put that routine inside the tire object? or do I put it inside the bicycle object? Neither, of course. That routine (method) is not part of either type (object); it's an independent but related operation that involves both. Here's the header of the routine (method) in Plain English:
To mount a tire on a bicycle:
Further, the OOP approach would make my invocation of such a routine (method) very unnatural. I would have to say either:
A superflapnabble is a flapnabble with a superpower.
Which would be object oriented programming with inheritance.
Frankly, we put "record extension" into the system as an experiment (because Niklaus Wirth did the same kind of thing in Oberon). In the end, it turned out to be more trouble than it was worth. We're thinking of deleting the feature in the next release. We needed it for "things" so we could easily make linked lists ("things" have next and previous pointers prepended to them) -- but this is a special case because those pointers, and the programmer's data, are at different levels of abstraction. One might as well argue that static local variables "inherent" their addresses from the stack pointer object, which would not be clear thinking.
to add a fragment given a tag and a variable and a number:
to add an import to some imports given an import name:
to add an intermediate given a type name and a locus:
Which looks very much like operator overloading in C++.
In real life we often perform the same kind of operation on different things: we might, for example, EAT a sandwich, or EAT an apple, or even EAT our words! I believe such "overloading" of a verb existed long before C++ was invented. But note that in Plain English, all of those EAT routines would be only coincidently related: EAT could mean very different things (depending on the parameter).
It looks to me like Plain English does indeed use classes and objects and object oriented programming.
I think you're reading things into Plain English that aren't there. When OOP terminology manages to say something about the world that's simply true, of course you'll find an overlap. But to think that the ideas in Plain English were derived from OOP is putting the cart before the horse.
Sadly, I have no way to bring up Plain English on any machine I own or use from day to day so as to be able to check all this out. I agree Windows is everywhere. But it seems to me that the audience you want to reach is using Arduino or Pi.
I tried posting in the Arduino forum and all they could talk about was how much they didn't like our font! A much nicer (and more reasonable) bunch of folks over here.
I also agree that selling a Pi with a ready made OS and Plain English installation is a non-starter. But, given all the inconsistency of "non windows" platforms then why even think about supporting the Propeller?
The advantage of a small microcontroller is that a kid can learn not just about programming with it, but about electronics as well. I was picturing a kit with a cheap Windows laptop and a nice Propeller board that eliminated as much complexity as possible and explained everything in plain English. The trick here would be finding a collection of obvious, real-life but simple applications that are uniquely suited to the Propeller so the kid could not only learn how programming languages and electronic devices work, but why the Propeller is uniquely suited to certain kinds of tasks.
Looking at your posted browser statistics I can only conclude that Javascript is the language to use. It's everywhere. Clears the screen and beeps just fine.
Actually, it's harder to clear the screen and beep in JavaScript than one might think. And I'm somewhat ashamed to admit that my elder son, who developed Plain English with me, supports his wife and four kids programming mainly in JavaScript and GO. Why? Because by making his applications essentially nothing more than robust web pages, he can make them run on anything with a browser with very little trouble (relatively speaking -- even the browser world is full of buggers).
I think I agree with you regarding "object oriented programming" as it is presented in C++, Java, C# etc.
It all goes fine if your classes and sub classes, basically your taxonomy, fits what you are trying to do. If your design is correct from the beginning.
It all goes wrong when requirements change or you realize 100,000 lines into your project that your taxonomy does not cover all the weird cases that come up and it's really hard to re-factor everything to cater for it.
As you say, nouns (the things) and verbs (what we want to do) are orthogonal.
I tried posting in the Arduino forum and all they could talk about was how much they didn't like our font! A much nicer (and more reasonable) bunch of folks over here.
Oh yeah... there is a lot of smart and experienced guys here. Young and old. An IDE or font does not impress (or otherwise) us
Perhaps I should not go on about Javascript. For any programming language there is always the language and then there is the environment it lives in and the API it has access to. Javascript traditionally has possibly the worst, most ugly, hard to use, tortuous, most badly thought out API to live with ever invented, the browser Document Object Model (DOM).
I still have some thoughts about your posts from a while back to bring out, perhaps later.
One simple 'sanity check' you could do, is check what programs you have generated, give EXE files (less libraries) in the region of 32K bytes or less.
I'll look into that, but it's a little difficult because Windows' PE executable format has so many unnecessary "sections" and so much unnecessary padding in it -- none of which would apply in a Propeller EXE. In general, I don't think the efficiency of our generated code is the problem.
Also, how would someone code an embedded staple, like Bit-banged Serial ?
I'm not sure what that means. By "embedded staple" do you mean a chunk of code that is always assigned to a particular cog to supply a useful, general-purpose service? If so, I would imagine such things to be normal library routines written in Plain English and included in one's project.
One simple 'sanity check' you could do, is check what programs you have generated, give EXE files (less libraries) in the region of 32K bytes or less.
I'll look into that, but it's a little difficult because Windows' PE executable format has so many unnecessary "sections" and so much unnecessary padding in it -- none of which would apply in a Propeller EXE. In general, I don't think the efficiency of our generated code is the problem.
Most compilers can create a MAP file or similar, that lists the code & data requirements of the various linked modules.
I'm assuming you will have something similar.
Knowing where your resource is being used, is pretty important in embedded design.
Also, how would someone code an embedded staple, like Bit-banged Serial ?
I'm not sure what that means. By "embedded staple" do you mean a chunk of code that is always assigned to a particular cog to supply a useful, general-purpose service? If so, I would imagine such things to be normal library routines written in Plain English and included in one's project.
What kind of applications do you use the Prop1 for? Why the Prop1 instead of something else?
Robotics. I actually discovered micros fairly late in life. In 2007 2008 I built a camera slider with a 555 and a servo. I saw the Basic Stamp kit in RadioShack and bought it out of curiosity.
I built a digital version using the Basic Stamp then decided to challenge myself with the Propeller and succeeded yet again. I was on top of the world. I had realized a new passion.
My latest challenge is a wireless 'bot' with a pan/tilt camera, differential steering and a gripper arm.
I'm using the nrf24L01 tranceiver ic and making good progress.
How tolerant is this ? Can it also parse this English
If source not colorized, colour=black.
or
If source not colorized, make colour black.
or
If not source colorized, colour becomes black.
Generally speaking, it's as tolerant as the programmer wants it to be. The compiler focuses on articles (like A, AN, THE, SOME), prepositions (like IN, OF, TO), conjunctions (like AND, OR), and a handful of state-of-being verbs (like IS, ARE, WAS) and expects these words to appear in their usual roles. The rest is up to the programmer. Colors are an exception since we use often use "color words" without a leading article in everyday speech. So let me give you some generic examples that include the articles so you can see, in general, how it works. If we have a left-to-right routine with headers like these defined...
To put a number into another number;
To copy a number into another number:
... and a similar right-to-left routine with headers like these defined:
To set a number to another number;
To get a number from another number;
To Make a number another number;
To [make] a number become another number;
To [make] a number = another number:
...we could (assuming the various variables have been defined) say any of these things:
Put 10 into the subtotal.
Copy the subtotal into the total.
Set the total to 0.
Get the grand total from the total.
Make the grand total 100.
The grand total becomes the total.
The total = 10.
And so forth. In actual practice, you code up a routine with the header you're thinking about at the time, and when you try to use the routine later, it often works. If it doesn't, you add a header that matches the expression that you were trying to use, and now the compiler "understands" more than before. After a while, it "gets to know you" and understands almost anything that pops into your head. The standard library, of course, has all sorts of common variations of common routines already coded.
The conditional part of your sample statements are handled by calls to a routine we call a DECIDER. The header of a decider always starts with TO DECIDE IF and a typical one might look like this:
To decide if a number is equal to another number;
To decide if a number = another number;
To decide if a number is the same as another number;
To decide if a number is another number:
When a statement like one of these is found...
If the total is equal to 10, make the total 100.
If the total = the subtotal, add 10 to the total.
If the total is the same as the subtotal, put 10 into the total.
If the total is 100, beep.
...the compiler first calls the decider, then (based on the boolean result that is returned) may or may not call the subsequent routines required in the body of the IF. If you put a "negative word" like NOT in any of the above conditionals, the compiler will automatically reverse the boolean result that the decider returns.
No. That cannot be done. Or should I say, yes you can wiggle an I/O pin on the end of a USB cable. But the magic of the Propeller is that it is small, and cheap, and low power, and one can wiggle pins with almost nanosecond precision. That and it's amazingly easy to program in assembler. Almost no need for a high level language to do things at that level.
I'm wondering what kind of things a kid might like to do with a microcontroller that are uniquely suited to a Propeller chip.
There is bound to be stuff there, you can make use of.
Thanks for those links. That's exactly the kind of the thing the Pi should have had from the beginning -- something more like a 32-bit DOS than an operating system; something more like just a library of handy, low-level functions so you don't have to start from scratch. That, after all, is what Windows is to us (since we only use the "device driver" parts of it, more or less).
I only glanced at Ultibo, but it definitely holds promise. It seems that there are a lot of "not yet implemented"s in the list; and unless I missed it, it's got a console but is lacking even 2D drawing capabilities. I'll need to take a closer look.
In any case, the interesting thing to me is the "feel" of it which is decidedly different from most of the stuff on the Pi. It seems that Pascal programmers simply think differently than C programmers.
Robotics. I actually discovered micros fairly late in life. In 2007 2008 I built a camera slider with a 555 and a servo. I saw the Basic Stamp kit in RadioShack and bought it out of curiosity. I built a digital version using the Basic Stamp then decided to challenge myself with the Propeller and succeeded yet again. I was on top of the world. I had realized a new passion.
My latest challenge is a wireless 'bot' with a pan/tilt camera, differential steering and a gripper arm.
I'm using the nrf24L01 tranceiver ic and making good progress.
That's great. Really. But why use the Propeller on your wireless bot instead of something else? What advantages does it give you?
I can't answer for lardom, but I've been using the Propeller since it first came out. It has a number of relatively unique features:
8 x 32bit fast processors (cogs), each with 512 x 32bit words of local program / data memory. Instruction time is 50ns for most instructions. All 32 I/O pins are accessed identically by all the processors and each processor has a video generator, and two multifunction counters
There's a shared 32K byte memory (hub) that's accessed in a round-robin fashion with each processor getting one cycle (8, 16, or 32bits) every 200ns and there are special instructions for semaphores/locks.
The small local memory is adequate for most I/O drivers and a variety of interpreters which is how they're commonly used. There is a fast IEEE floating point package that runs in a single cog. Several cogs can be synchronized and work together for increased throughput for example for a high resolution VGA text display with each cog building a scan line, then displaying it.
For robotics, particularly during development, it's hard to decide ahead of time what peripherals might be needed and how they might function. With multiple processors, it's easy to just drop in a different I/O driver with little or no effect on any other part of the system as long as there's a free cog or two. When I was debugging an integer Basic interpreter, with a few minutes' work, I could add a TV text display for debugging that was specific to the problem I was having.
Comments
substring.draw ( box, color, source.text.font, source.text.alignment ) ;
That's 10 words and 11 punctuation marks: 21 total elements.
The Plain English equivalent would be:
Draw the substring in the box with the color and the source's text's font and alignment.
Which is 16 words and 3 punctuation marks: 19 total elements. Admittedly, the Plain English version requires a few more easy-to-type alphabetic characters (it's difficult to say exactly how many since traditional coders put spaces in different places); but I think that's a small price to pay for not having to learn (or think in) an artificial syntax.
Here's another example (I've got a million of 'em):
if ( ! source.colorized ( ) ) color = black ;
Which is 5 words and 8 punctuation marks: 13 total elements.
The Plain English would read:
If the source is not colorized, put black into the color.
Which is 11 words and 2 punctuation marks: 13 total elements. Again, it's mostly a matter of whether you like to type words or punctuation. And whether you like to think in two different syntactical and grammatical forms simultaneously. And whether you want your code to be self-documenting. And whether you want code that's friendly for beginners. And whether you want to code in a language (like English) that will still be in common use 100 years from now. Personally, I believe that anyone who thinks "if (!source.colorized())" is a reasonable way to express one's self has lost touch with the rest of humanity!
I'm not one to argue that we should focus on minimizing keystrokes. When it comes to it most of the time you spend programming is not spent typing, but rather thinking about what it is you want to do and how best to do it. Then you spend a lot of time wondering whey it does not work as expected...actual typing is the least of your worries. Source code should be easily readable, by yourself a year later and by others who want to use it or learn from it. As such reducing everything to weird punctuation and operators and meaningless short variable names is not a good idea. As a simple example I would rather see "x = x +1" in the source than "x++". Or is it "++x"? or which one do I mean here....The latter is confusing and error prone.
That said, personally I would go for the examples in red that you posted above rather than the blue. Why, it's easier to read, it has no redundant "the" all over the place, it's concise and precise. This becomes even more so when things get a bit complicated.
I'm not sure that when one does a lot of programming one thinks in two syntactical forms simultaneously. At some point you are no longer thinking in syntax any more than when you are speaking in your native language. Admittedly if you find yourself working with two similar languages at the same time, say C and Java you will get tripped up by automatically typing one syntax when you are working on the other, or assuming the wrong semantics for something.
Clear, self documenting code is an ideal. It's not clear to me that either of your examples demonstrate self documenting better than the other.
Code that is friendly for beginners is a great idea. That was the motivation behind BASIC, and SmallTalk and Logo and others. Even Javascript was designed for the non-programmer to get simple things done, despite that fact that it is quite a sophisticated language that can keep experts happy.
Recent times have shown that beginners get along quite well with C++ (see Arduino), Javascript (see the entire web), BASIC (see Mircrosoft world), Spin (See Parallax Propeller). That is rather skipping over a very large detail. Most of the world does not speak English. Right there is a huge barrier to an excessively verbose English based language. Admittedly all the languages I know have a few short keywords in English, but I'm betting that if those were replaced with some Chinese or Arabic squiggles we could get used to in a short time. English is of course a moving target given the rate that it mutates. I sort of agree. Those "( )" used with "if" in C are redundant and annoying. In your example "colorized" may as well be a property of the "source" object so those "( )" following it are redundant as well. Basically C messed a few things up when it evolved from B or BCPL or whatever it was. C++ made it worse!
But, as it happens humanity includes mathematicians, doctors, lawyers and so on, all of whom evolve their own notations and short cuts and so on to make communications between themselves about the subject at hand simpler and quicker. Often us humans on the outside have no idea what they are talking about.
By the way, you spelled colourised wrong. So much for Plain English
This is an interesting idea and discussion.
For the example above, could it be written:
If the source is not colorized, make the source black.
or
If the source is not colorized, make it black.
or
Make the source black if it is not colorized.
I can see one thinking any of the above are perfectly acceptable variations of the original statement. If Plain English requires a strict adherence to a certain phrasing and arrangement of keywords, then I can't see it being easily usable. Presenting a syntax that is real close to English but having to adhere to specific structure without the flexibility that people use in their plain English will make it very tedious and frustrating when trying to describe a problem to the computer.
Plain English will catch on when it is able to handle natural English and understand variations of the same idea as shown in the examples above.
To me, the chained possessives in this example are just awkward and not the way I would say or write this in English
"...the font and alignment of the source's text" seems clearer to me. If that is not what is meant then there is an underlying problem with Plain English. It has the flexibility of English which also allows the potential ambiguity of English sentences.
I won't continue with the multi-platform discussion - that's a can of worms for another fishing trip!
I would not call myself a typical Linux programmer. Have programmed many things, large and small, in many languages starting before Linus Torvald's knew what a computer was. I'm not proposing that your end users have to use a command line, clearly that is not your goal. However it seems like good practice to me to have a "separation of concerns" in a large project. The compiler is not the IDE, or the documentation system or the program delivery system/package/installer. The compiler can be it's own module or subsystem which can be built into the IDE or a command line program or whatever.
I do agree that the source code for the Plain English compiler/IDE should be Plain English itself. In the same way that C and C++ compilers are written in C and C++. Pascal compilers are written in Pascal, etc, etc.
However, presumably when you started there was no Plain English compiler to compile itself with. Presumably you wrote the original Plain English, or a subset of it, in C++ or Visual Bascic or whatever.
How did you bootstrap it?
If Plain English can compile itself then all you need do is tweak the code generator to produce ARM executables and you soon have the Plain English system up and running on a Raspberry Pi or whatever.
I also agree that "the same GUI everywhere" is a good idea. Presumably you have used the Win32 API or whatever Windows has now for getting stuff on the screen. My only suggestion is to use something like the Qt or Lazarus API instead. Then you have a portable program with the same look and feel everywhere. It need not look like Qt or Lazarus, just use the low level services they offer, as you probably do in Windows.
Your use of "wysiwyg" tickled me. It's a term that entered the Oxford English Dictionary in the 1980's or so. I have not heard anyone use it for decades now. Still what this forum software does is besides the point. I can, a lot more
Firstly your program does not run here. Not unless I buy myself a Windows machine. Or go out of my way to install wine and even that can be hit and miss. (Which I will probably do out of curiosity).
Similarly your program does not run for Mac owners.
Lastly, it will only run as long as there is a Windows platform around to run it on.
I think it has been mentioned a couple of times that Plain English was created about ten years ago, so has it been in the field, being used by other people and groups all that time? If so, does Plain English have a substantial following?
The way I understand the description of Plain English is that it is a programming language, but I get the impression that it is more of an interactive problem solving program. We have had plenty of discussion here about having an interactive program for the Propeller, other than Forth.
Using the QuickStart board as an example, having eight LEDs and eight touch pads, I wonder how Plain English would deal with working with those items.
Yes, I find Plain English to be a very interesting concept, how it would work with the Propeller boards that are available is still a mystery to me.
Ray
I'm just a hobbyist but I think the point I want to make is relevant. Prop1 is here to stay. Prop2 is not here yet but it cannot replace Prop1 any more than luxury cars could ever replace commuter vehicles.
I'm hoping one of our senior programmers will offer whatever assistance you seek.
Typically, a high level language like Plain English is run on the Propeller using an interpreter running in one or more cogs with the interpretive code and its data residing in the "hub" memory. Sometimes the interpretive code is kept externally in an EEPROM or serial RAM which can be quite large and paged into the "hub" on demand. An SD card file can also be used for this with an often quite reasonable performance "hit". C and C++ programs can optionally be compiled this way for large programs. Spin programs and data, for example, reside in the "hub" and the interpreter is stored in an on-chip ROM, read automatically into a cog for execution as needed.
As another example, there's a board sold by Cluso99 that has a 512K static RAM and micro-SD card designed for use as an Intel 8080 or Zilog Z80 CP/M machine. It can use the 1-wire display and keyboard drivers and emulates floppy drives and small hard disk drives using SD-card files ... runs standard CP/M and all the huge libraries of CP/M applications at nearly original hardware speeds.
That makes the most sense, at least early in development.
One simple 'sanity check' you could do, is check what programs you have generated, give EXE files (less libraries) in the region of 32K bytes or less.
Also, how would someone code an embedded staple, like Bit-banged Serial ?
How tolerant is this ? Can it also parse this English
If source not colorized, colour=black.
or
If source not colorized, make colour black.
or
If not source colorized, colour becomes black.
What size EXEs do these 3 equivalents create ?
Note that when he's not thinking about programming languages, but simply trying to express himself as clearly and concisely as possible, he begins with (1) a natural language framework, German in this case, inserts (2) a mathematical snippet here and there, and includes with some difficulty, (3) a graphic.
Our ultimate goal is to be able to compile and run pages like that. And Plain English, we think, is a step in that direction because, instead of making the formulas the framework (as most programming languages do), and instead of making the graphics the framework (as a lot of "kiddie" languages do), we (very naturally) make the natural language the framework. The rest is sub-compilers which are easy to write and include in that framework.
Yes, funny. The version of Plain English currently under development supports statements like...
Color, colour, coler, and coller are synonyms.
So alternate (and even mis-) spellings in vocabulary can be understood. The current version already handles similar grammar problems (eg, where the programmer uses IS instead of ARE or AIN'T instead of ISN'T).
One of the great features of Plain English is that both the vocabulary and the grammar of the language are determined primarily by the programmer. For example, when he says...
A flapnabble is a thing with a size and a color.
...the vocabulary of the language has been increased; the compiler now "understands" the word flapnabble. And when he defines a routine with a header like this...
To draw a flapnabble;
To take a flapnabble and render it;
To put a flapnabble on the screen;
To git a flapnabble up on that there tv thingy:
...the compiler now "understands" a variety of new verbs and grammatical forms.
Yes, possessives are simply shortcut-prepositional-phrases moved to the front in English: "Bill's house" is thus short for "the house of Bill." And you're right that we rarely chain possessives together in ordinary speech, typically because we rely on context for the uppermost nouns. The version of Plain English currently under development addresses both of these problems.
It's not the compiler part that's difficult -- it's the "standard library" part. Windows' event-processing mechanism, for example, is not at all like XDE's or Gnome's or whatever the Pi people are using these days. Simply clearing the freaking screen or getting a machine to beep (without loading a whole MP3 player) is very non-trivial these days.
The fact that there's an "or" in that last clause illustrates the problem. We know that the Win32 API is already installed on every Windows desktop, and that it will behave as expected. No installation instructions needed, no customer support necessary. We don't know what's on that kid's Pi: Qt? Lazarus? Neither? So we can't just say, as we do with Windows, "download and double-click."
If I thought the Pi was a good target, I think I'd sell the hardware with the software so I could pre-configure the "firmware" for consistency and simplicity. But now comes the rub, and this is important: A pre-configured Pi (with keyboard, mouse, and display) is going to cost as much or more than a cheap Windows laptop (and it will look like a kludge, to boot). So I think I'd rather sell the kid a Windows laptop with Plain English pre-installed. Or, as we do now, just let him download our software and double-click. In any case, those are the options to beat. Show me how I can make Linux as simple, elegant, complete, consistent, and cheap as those alternatives and you'll have my full attention.
I don't think so; it causes me grief every time I post. Edit here, preview there, come back to edit some more. Very primitive. And when I try to print one of these posts off so my wife can read it, I'm sent to another kind of preview screen (that often doesn't have what I want on it) and... well, the root problem is the way the world has abandoned the wysiwyg paradigm that made the Mac the seminal machine that it was.
Touche. But the very same code, unchanged for ten years, did and does run on over 84% of the desktop computers in the world. Add 'em up:
Not bad for guy and his kid coding for a few months in the back bedroom!
I wouldn't exactly say "substantial." People tend to love it or hate it. It's used mostly for education, but not widely yet.
It's not interactive except in the sense that it compiles quickly enough so you can make a change, try it, make another change, etc. Less than a second turnaround, though that would probably be longer when we add in the time to download to the Propeller.
Your code would probably say things like:
The start button is on pad 1.
The stop button is on pad 2.
The red LED is on pin 3.
The green LED is on pin 4.
...
If the start button is down, turn off the red LED; turn on the green LED.
If the stop button is down, turn off the green LED; turn on the red LED.[/qolor]
I think you have something very clever and fascinating here. I say that after looking over your github repo. So forgive me if I have some questions/comments:
You have expressed a disdain for "objects" and "object oriented" programming. But in the post above I see: Which sounds like a class of objects that derives it's properties from "thing" and adds "size" and "color" properties.
Presumably one could write: Which would be object oriented programming with inheritance.
If that is not the case presumably one would write: Which is just a structure that inherits from nothing.
Also in your compiler source on github I see: Which looks very much like operator overloading in C++.
It looks to me like Plain English does indeed use classes and objects and object oriented programming.
Sadly, I have no way to bring up Plain English on any machine I own or use from day to day so as to be able to check all this out.
I agree Windows is everywhere. But it seems to me that the audience you want to reach is using Arduino or Pi.
I also agree that selling a Pi with a ready made OS and Plain English installation is a non-starter.
But, given all the inconsistency of "non windows" platforms then why even think about supporting the Propeller?
Looking at your posted browser statistics I can only conclude that Javascript is the language to use. It's everywhere. Clears the screen and beeps just fine.
Please don't think I'm bashing on the Plain English idea or all your work, I'm just trying to get to grips with the idea here.
Plain English is a difficult language to interpret on-the-fly because most of the information needed to properly "understand" a given statement is contained elsewhere in the program -- the vocabulary and grammar of the language are deduced from the whole of the code submitted to the compiler. Our compiler makes three passes at the source code when compiling. I suspect a Plain English interpreter would need more memory for "symbol tables" and "dictionaries" than is available on the Propeller. Unless, as you suggest, these things were kept externally and we could solve the ensuing performance problems. On the whole, it doesn't appear to be a very straightforward conversion due to the vast differences between a Propeller and a Windows machine.
Please don't think I haven't followed similar thought patterns (and searches) before. The bottom line is that, for programs that require a lot of high-level graphics facilities and a lot of memory, it's hard to beat something like a Raspberry Pi (if one can stomach Linux) or a cheap Windows laptop if one cannot. In other words, instead of trying to turn a Propeller into a laptop computer, it seems easier to turn a laptop into something like a Propeller by adding digital I/O and such via USB. I may very well be wrong, of course; I haven't done a lot of microcontroller stuff for some years now. But when I can readily get a fast processor, gigs of memory, a display, a speaker, a touchpad, WiFi, and a USB port in an elegant little package for $50 using a tablet, it's hard to think "building up" something like that "from scratch" is advantageous. I wish it wasn't so. Takes a lot of the fun out of it.
Or should I say, yes you can wiggle an I/O pin on the end of a USB cable.
But the magic of the Propeller is that it is small, and cheap, and low power, and one can wiggle pins with almost nanosecond precision. That and it's amazingly easy to program in assembler. Almost no need for a high level language to do things at that level.
Of course if that is not what one wants to do then it's perhaps better to look at something else.
If you want to avoid the variances of Linux, then perhaps look at some of the Bare-Metal work on the Pi :
https://www.raspberrypi.org/forums/viewtopic.php?f=56&t=134956
https://ultibo.org/forum/viewtopic.php?f=4&t=52
There is bound to be stuff there, you can make use of.
A wheel is a...
A bicycle has two tires...
Here we have two types (objects): bicycles and tires. Now I want to write a routine to mount a tire on a bicycle. Do I put that routine inside the tire object? or do I put it inside the bicycle object? Neither, of course. That routine (method) is not part of either type (object); it's an independent but related operation that involves both. Here's the header of the routine (method) in Plain English:
To mount a tire on a bicycle:
Further, the OOP approach would make my invocation of such a routine (method) very unnatural. I would have to say either:
tire.mount(bicycle)
or
bicycle.mount(tire)
when what I really want to say is:
Mount the tire on the bicycle.
Frankly, we put "record extension" into the system as an experiment (because Niklaus Wirth did the same kind of thing in Oberon). In the end, it turned out to be more trouble than it was worth. We're thinking of deleting the feature in the next release. We needed it for "things" so we could easily make linked lists ("things" have next and previous pointers prepended to them) -- but this is a special case because those pointers, and the programmer's data, are at different levels of abstraction. One might as well argue that static local variables "inherent" their addresses from the stack pointer object, which would not be clear thinking.
In real life we often perform the same kind of operation on different things: we might, for example, EAT a sandwich, or EAT an apple, or even EAT our words! I believe such "overloading" of a verb existed long before C++ was invented. But note that in Plain English, all of those EAT routines would be only coincidently related: EAT could mean very different things (depending on the parameter).
I think you're reading things into Plain English that aren't there. When OOP terminology manages to say something about the world that's simply true, of course you'll find an overlap. But to think that the ideas in Plain English were derived from OOP is putting the cart before the horse.
I tried posting in the Arduino forum and all they could talk about was how much they didn't like our font! A much nicer (and more reasonable) bunch of folks over here.
The advantage of a small microcontroller is that a kid can learn not just about programming with it, but about electronics as well. I was picturing a kit with a cheap Windows laptop and a nice Propeller board that eliminated as much complexity as possible and explained everything in plain English. The trick here would be finding a collection of obvious, real-life but simple applications that are uniquely suited to the Propeller so the kid could not only learn how programming languages and electronic devices work, but why the Propeller is uniquely suited to certain kinds of tasks.
Actually, it's harder to clear the screen and beep in JavaScript than one might think. And I'm somewhat ashamed to admit that my elder son, who developed Plain English with me, supports his wife and four kids programming mainly in JavaScript and GO. Why? Because by making his applications essentially nothing more than robust web pages, he can make them run on anything with a browser with very little trouble (relatively speaking -- even the browser world is full of buggers).
No problem at all. I'm having fun.
I think I agree with you regarding "object oriented programming" as it is presented in C++, Java, C# etc.
It all goes fine if your classes and sub classes, basically your taxonomy, fits what you are trying to do. If your design is correct from the beginning.
It all goes wrong when requirements change or you realize 100,000 lines into your project that your taxonomy does not cover all the weird cases that come up and it's really hard to re-factor everything to cater for it.
As you say, nouns (the things) and verbs (what we want to do) are orthogonal. Oh yeah... there is a lot of smart and experienced guys here. Young and old. An IDE or font does not impress (or otherwise) us
Perhaps I should not go on about Javascript. For any programming language there is always the language and then there is the environment it lives in and the API it has access to. Javascript traditionally has possibly the worst, most ugly, hard to use, tortuous, most badly thought out API to live with ever invented, the browser Document Object Model (DOM).
I still have some thoughts about your posts from a while back to bring out, perhaps later.
I'll look into that, but it's a little difficult because Windows' PE executable format has so many unnecessary "sections" and so much unnecessary padding in it -- none of which would apply in a Propeller EXE. In general, I don't think the efficiency of our generated code is the problem.
I'm not sure what that means. By "embedded staple" do you mean a chunk of code that is always assigned to a particular cog to supply a useful, general-purpose service? If so, I would imagine such things to be normal library routines written in Plain English and included in one's project.
Most compilers can create a MAP file or similar, that lists the code & data requirements of the various linked modules.
I'm assuming you will have something similar.
Knowing where your resource is being used, is pretty important in embedded design.
Yes, good, so you have an example ?
I built a digital version using the Basic Stamp then decided to challenge myself with the Propeller and succeeded yet again. I was on top of the world. I had realized a new passion.
My latest challenge is a wireless 'bot' with a pan/tilt camera, differential steering and a gripper arm.
I'm using the nrf24L01 tranceiver ic and making good progress.
Generally speaking, it's as tolerant as the programmer wants it to be. The compiler focuses on articles (like A, AN, THE, SOME), prepositions (like IN, OF, TO), conjunctions (like AND, OR), and a handful of state-of-being verbs (like IS, ARE, WAS) and expects these words to appear in their usual roles. The rest is up to the programmer. Colors are an exception since we use often use "color words" without a leading article in everyday speech. So let me give you some generic examples that include the articles so you can see, in general, how it works. If we have a left-to-right routine with headers like these defined...
To put a number into another number;
To copy a number into another number:
... and a similar right-to-left routine with headers like these defined:
To set a number to another number;
To get a number from another number;
To Make a number another number;
To [make] a number become another number;
To [make] a number = another number:
...we could (assuming the various variables have been defined) say any of these things:
Put 10 into the subtotal.
Copy the subtotal into the total.
Set the total to 0.
Get the grand total from the total.
Make the grand total 100.
The grand total becomes the total.
The total = 10.
And so forth. In actual practice, you code up a routine with the header you're thinking about at the time, and when you try to use the routine later, it often works. If it doesn't, you add a header that matches the expression that you were trying to use, and now the compiler "understands" more than before. After a while, it "gets to know you" and understands almost anything that pops into your head. The standard library, of course, has all sorts of common variations of common routines already coded.
The conditional part of your sample statements are handled by calls to a routine we call a DECIDER. The header of a decider always starts with TO DECIDE IF and a typical one might look like this:
To decide if a number is equal to another number;
To decide if a number = another number;
To decide if a number is the same as another number;
To decide if a number is another number:
When a statement like one of these is found...
If the total is equal to 10, make the total 100.
If the total = the subtotal, add 10 to the total.
If the total is the same as the subtotal, put 10 into the total.
If the total is 100, beep.
...the compiler first calls the decider, then (based on the boolean result that is returned) may or may not call the subsequent routines required in the body of the IF. If you put a "negative word" like NOT in any of the above conditionals, the compiler will automatically reverse the boolean result that the decider returns.
Almost all Plain English statements generate similar code: push the parameters, call a routine, pop the parameters.
I only glanced at Ultibo, but it definitely holds promise. It seems that there are a lot of "not yet implemented"s in the list; and unless I missed it, it's got a console but is lacking even 2D drawing capabilities. I'll need to take a closer look.
In any case, the interesting thing to me is the "feel" of it which is decidedly different from most of the stuff on the Pi. It seems that Pascal programmers simply think differently than C programmers.
8 x 32bit fast processors (cogs), each with 512 x 32bit words of local program / data memory. Instruction time is 50ns for most instructions. All 32 I/O pins are accessed identically by all the processors and each processor has a video generator, and two multifunction counters
There's a shared 32K byte memory (hub) that's accessed in a round-robin fashion with each processor getting one cycle (8, 16, or 32bits) every 200ns and there are special instructions for semaphores/locks.
The small local memory is adequate for most I/O drivers and a variety of interpreters which is how they're commonly used. There is a fast IEEE floating point package that runs in a single cog. Several cogs can be synchronized and work together for increased throughput for example for a high resolution VGA text display with each cog building a scan line, then displaying it.
For robotics, particularly during development, it's hard to decide ahead of time what peripherals might be needed and how they might function. With multiple processors, it's easy to just drop in a different I/O driver with little or no effect on any other part of the system as long as there's a free cog or two. When I was debugging an integer Basic interpreter, with a few minutes' work, I could add a TV text display for debugging that was specific to the problem I was having.