The Osmosian Order of Plain English Programmers

[Darren Dirt]

https://www.osmosian.com/

Our Sample Application

Imagine a program that can paint:
-Any person, place, or thing you name
-In the style of Claude Monet
-In 300 lines of Plain English code

https://www.osmosian.com/manifesto.pdf

WHO WE ARE

The Osmosian Order of Plain English Programmers is a group of like-minded developers and educators dedicated to the rescue of computer science from the pervasive fog of confusion engulfing it today.

WHAT WE HOPE TO ACHIEVE

We intend to supplant, in turn, the programming languages, operating systems, and hardware configurations currently in widespread use. Our initial goal is to see Plain English (and other natural-language variants, such as Plain Spanish and Plain German) adopted as de facto standard languages. We believe that the convoluted object-oriented approach -- together with the byzantine "C" programming language and all of its derivatives -- can be removed from common usage within the next ten years.

We offer our Plain English compiler as both "proof of concept" and a first step in the right direction. Our integrated development environment includes an elegant desktop interface, a simplified file manager, an efficient text editor, the compiler, and the page-layout routines used to produce all of our documentation, the illustrations for our web site, and this manifesto.

It should be noted that all this functionality is embodied in a single, stand-alone, native-code executable less than one megabyte in size. The program runs on the Wintel Kluge, was written entirely in Plain English, and re-compiles itself in less than three seconds. That's right. Three seconds.

Fry, Leela, Professor, Amy, Hermes: *gasp*
Bender: NEAT!


- - -

in case anyone cares, I found the above in -- of all places -- this Amazon discussion; the email for one discussion participant "Gerry Rzeppa" is apparently "help@osmosian.com". doubt anyone cares, though

[Mr. Analog]

After your description I'm still not sure what it's all about, a programming language that bloats simple logical concepts with clunky English rules of grammar?

The trouble I see with ANY programming language that tries to be plain English can be summed up thusly:

Thus spake I:

Code Select Expand

If I have apples and Johnny has less apples, give Johnny some of my apples until we have the same amount of apples.

In C:

Code Select Expand

do
{
if (x > y)
{
x--;
y++;
}
}
until (x == y)

I could boil it down to this in C#:

Code Select Expand

if (x > y)
x = y = ((x - y) / 2) + y;

Computer programming is algebra, not English. The two most painful languages I have to deal with from time to time are Visual Basic and COBOL. Both were initiated as languages that were to be as close to plain English as possible. Both fall well short of this.

Q.E.D.

P.S. That's the worst site design I've seen in a long time...

[Thorin]

Code Select Expand

If I have apples and Johnny has less apples, give Johnny some of my apples until we have the same amount of apples.

Imagine, it'll have to handle the following same descriptions of the same task as well:

Code Select Expand

Give Johnny my apples until Johnny has the same amount of apples as me

Code Select Expand

Do I have apples?  If I do, you should give apples to Johnny until I still have apples and he has just as much in his basket as I do

Code Select Expand

Take applez from my basket to putt in Johnnys basket untill the basketz are the same fullness

(spelling mistakes intentional in the last example)

For the same reason that I can't understand proper techniques in football or gynecological surgery, other people have trouble understanding computer science.  Why?  Because they haven't received the training and/or they don't have enough natural aptitude at the task.

Nevertheless, code in today's language can be written in a style that is easier to read, and I try to do that as much as possible. For instance (in C#):

Code Select Expand

int johnnysApples = 3;
int myApples = 9;
do
{
    johnnysApples = johnnysApples + 1;
    myApples = myApples - 1;
}
until (johnnysApples >= myApples);

Of course, that still doesn't explain why we're giving Johnny some of my apples, which is almost always the question that gets asked immediately after we have deciphered what the code is doing.  And I doubt very much that their "Plain English" coding style is going to make any difference on that front.

[Darren Dirt]

sorry for implying I think this is "the wave of the future" but I thought it WAS interesting, perhaps even ambitious. And "neat" to see the working demo app.

And it isn't about parsing normal english. It's still a "structured" language, by the looks of it. Just a lot more "clear" and "human readable" (plus other benefits, BTLOI.


I presume from your posts that neither of you  guys had a look at the sample program's code? At first it seemed hard to figure out, hard to follow. Then I kinda "worked backwards" and realized, wow, this is in a way a lot "simpler" (remember, most of us are developers at HEART so we think like programmers, perhaps a little too much...

And the Osmosians seem to be not focused on "how short can a piece of code be" but rather "how CLEAR". It's like, which code would you rather try to decipher: something written in super-compact Perl? Or VB...  The sample code is a lot more "clear" (though with more characters) than the excellent counter-example offered by Mr. Analog.

There, hope that clarifies things a bit -- might be interesting if you guys have a look at the sample "code", even just for entertainment purposes.

[Mr. Analog]

Maybe I would like this better if I knew what makes this cool?

[Tonnica]

Our initial goal is to see Plain English (and other natural-language variants, such as Plain Spanish and Plain German) adopted as de facto standard languages. We believe that the convoluted object-oriented approach -- together with the byzantine "C" programming language and all of its derivatives -- can be removed from common usage within the next ten years.

So basically it's a front-end interperetive language slapped on top of C styled after the English language. I've used this kind of thing before with custom Python apps and scripting engines like OnScripter. Those kind of tools, while useful sure haven't reached this "defacto standard" the project is reaching for. In the end all the ones I've used end up having to use to programmer-ish calls and terms anyways because of some obtuse library or functionality.

I'm not really seeing what's neat about it (the concept or the code). Maybe it could be useful to ease students into logical programming? When you're first learning to program you do have to be able to describe the solution to the problem first. Either way, you're still training your brain around an interpretive language, even if it looks like plain English.

Choice of language depends on training and the programmers' comfort level in relation to how close to machine language an interperetive language gets. Writing at the machine level is painfully arduous but you know exactly what's being invoked. At a higher level you get a better view of what's being passed around but the invocation complexity is hidden. Both can be useful, and which one and how they're used is all up to the person writing it.

And as for the OOP is "convoluted" comment: pffft, whiners! 

[Darren Dirt]

I'm not really seeing what's neat about it (the concept or the code). Maybe it could be useful to ease students into logical programming? When you're first learning to program you do have to be able to describe the solution to the problem first.

Yeah, perhaps that. I mean, how many newbie programmers (I say they deserve not the label "developers" ) are too often stuck in the details, and are unable to think "top-down" or utilize "start at the end" kind of thinking, analysis, trouble-shooting etc.

Perhaps if they could think on the top level, describe the "main loop" or whatever in Plain English, and after writing that out (in the language's structure, whatever it is ) then "drill down" a level, inserting stubs when necessary to test parts and eventually getting to the point of it doing most of what they had envisioned the "finished product" would do (before they started coding a single byte) maybe THAT would make the software world a better, safer, happier place.

Or maybe it's just that I thought the "painting" demo app was pretty damn cool -- what time was it that I started this thread...?

[Mr. Analog]

I think it's far more constructive for someone to learn the real thing properly the first time than a layer of abstraction shielding them with the idea that it would be easier to learn. Logical concepts and problem solving are the same no matter the syntax.

I'd trade the four months of PowerBuilder I learnt for 2 months of Assembler or LISP.

[Darren Dirt]

I think it's far more constructive for someone to learn the real thing properly the first time than a layer of abstraction shielding them with the idea that it would be easier to learn. Logical concepts and problem solving are the same no matter the syntax.

Agreed. Seems like a lot of folks attend the 10 month or 2 year program at their local IT training centre, and know how to select boxes and widgets from a toolkit, but don't know how to step outside the equipment and understand the blueprints, let alone how to design their own... Learning logical concepts and intelligent app design from pre-generated/cut-and-paste code is like [insert thing that is just not gonna happen]. But teaching the interested youngsters how to problem solve and pseudocode and debug without hitting of any keys or clicking of any mouse buttons, now that can have an immeasurably positive impact on that apprentice's IT career, even outside of development. Oh, if only... (I guess overall I'm offering a personal lamentation for the apparent loss of the Golden Age of the self-motivated, independently-thinking coding addict...)

[Mr. Analog]

See this is where I think we sometimes don't see all the cool development that's going on all around us. I mean, look at stuff like Flickr, YouTube, heck even all the Flash scripting and computer game mods out there.

Hundreds if not thousands of programming hobbyists turning their little dreams into widget apps for MySpace or what have you.

Beats the hell out of the Adventure! clone i wrote on my C64!

[Thorin]

I think it's far more constructive for someone to learn the real thing properly the first time than a layer of abstraction shielding them with the idea that it would be easier to learn. Logical concepts and problem solving are the same no matter the syntax.

I'd trade the four months of PowerBuilder I learnt for 2 months of Assembler or LISP.

Assembler removes a lot of the abstraction, but Assembler still sometimes provide a single opcode mnemonic that gets translated into more than one opcode.  That is, a single Assembler instruction sometimes still gets turned into more than one machine-level instruction.

Lisp is a high-level language providing much abstraction to the programmer.  It's interesting as a language because of the paradigm shift in considering everything in your program to be a list including function calls and basic mathematics.  Once you get that concept, that it's basically a singly-linked list that can have lists nested in it, it starts to make a little more sense.

If I had my choice, I'd like to learn more about how memory is managed and how with my current toolset the memory footprint is kept as low as possible.  But .NET and Java are both basically black holes when it comes to memory management, and if you look at how bloated even little applets get nowadays, you can see that memory footprint isn't considered by very many programmers anymore.

[Mr. Analog]

In both .NET and Java there are ways of writing what Microsoft calls "unsafe" and what Sun calls "nativ" code, but then if performance is what you're after you should go back to C++

But getting back on topic:

I dunno, it's been an interesting discussion so far. I think the most interesting question that has been posed here is how do you teach someone to program, is it fundamentally better to have an "easier to understand" language or not, what of the pitfalls of using what we would call pseudo code as actual syntax?

I look at it this way, the basic logical constructs are the building blocks, the languages you use are mostly irrelevant if you understand how to use those building blocks to describe process.

Before there were computers, before there was electric light, Ada Lovelace was writing code for a nonexistent compiler. She understood mathematics and logical problem solving and applied those skills to virtual problems. I think there's something a lot of us can take home from that.

[Darren Dirt]

Before there were computers, before there was electric light, Ada Lovelace was writing code for a nonexistent compiler. She understood mathematics and logical problem solving and applied those skills to virtual problems. I think there's something a lot of us can take home from that.

and those of us who still remember a few of the "folks that were left behind" in NAIT 1st year, in the "logic and problem solving" course, I think it's a skill that not everyone can [easily] pick up

[Mr. Analog]

Before there were computers, before there was electric light, Ada Lovelace was writing code for a nonexistent compiler. She understood mathematics and logical problem solving and applied those skills to virtual problems. I think there's something a lot of us can take home from that.

and those of us who still remember a few of the "folks that were left behind" in NAIT 1st year, in the "logic and problem solving" course, I think it's a skill that not everyone can [easily] pick up

You've hit the nail on the head there Darren, I think problem solving isn't necessarily for everyone and certainly most of us have to work at it to get it right (or at least work together). Programming is the result of all that process.

[Gerry Rzeppa]

Hello, folks. I've just dropped in to offer a free evaluation copy of our Plain English development system to any open-minded soul who will take the time to write and ask for one. The package includes a unique interface, a simplified file manager, a hexadecimal dumper, an elegant text editor, our native-code generating compiler/linker (not an interpreter), and a full-featured page layout facility (that we used to document the thing). It's written entirely in Plain English (except for a handful of hexadecimal literals) and can recompile itself on a bottom-of-the-line Dell in less than 3 three seconds. Really. Three seconds.

If you do decide to make a study our work, there are three things you should keep in mind:

(1) The product is not intended for isolated self-study. Both the program and the documentation are designed to provoke questions and discussion. So when anything strikes you as unusual, strange, or just plain stupid (as some feel about our website), we strongly encourage you to ask us about it: help@osmosian.com. We have at least three good reasons for everything that we put in there, and we're more than happy to tell you what they are.

(2) The product is intentionally different - iconoclastic is the term we use. It is designed to make the programmer question almost every preconceived notion a modern practitioner might have. Are installation programs necessary? Can a high-level language like English be used to conveniently write low-level programs like compilers? Can a workable interface be designed without icons, scroll bars, radio buttons, and a wide variety of other widgets? Can complex programs be clearly and concisely written without nested ifs and loops? Can a polymorphic drawing program be effectively programmed without objects? And so forth.

(3) The product is serious stuff - in spite of our tongue-in-cheek presentation. We really believe in our unique and deceptively simple approach to natural language parsing. And we really do think this approach will provide a firm foundation for computers like the HAL 9000 sometime in the future. Our next step is to install the compiler on a dedicated machine where all previously compiled code will be resident at all times. We will then extend that machine's compiler to accept and rank additional and even alternative defintions and routines submitted by a group of dedicated Plain English programmers who will continue to "teach" it new things over a period of years. Our hope is to recruit 100 such teachers who will each explain 10 things to the machine every day, so that at the end of just three years, our "apparently intelligent"(tm) machine will understand and properly respond to more than a million natural language sentences. There's more to it, of course, but that's the gist. Additional information is, of course, available on request.

Looking forward to communicating with you directly, then, I am,

Gerry Rzeppa
Grand Negus, The Osmosian Order of Plain English Programmers (www.osmosian.com)
Founder and Director of Research and Development, Relational Systems Corporation (www.era-sql.com)
Author, "Some of the Parts", a ten-minute reply to rabid atheists like Richard Dawkins (www.someofthepartsbook.com)

PS. Don't forget to reply directly to help@osmosian.com. It's impractical for us to monitor every forum we post in.

[Darren Dirt]

ROFL you gotta love Google's indexing engine... and egocentric searching

[Mr. Analog]

This is actually kind of cool. I'd like to see what it can do!

[Cova]

After your description I'm still not sure what it's all about, a programming language that bloats simple logical concepts with clunky English rules of grammar?

The trouble I see with ANY programming language that tries to be plain English can be summed up thusly:

Thus spake I:

Code Select Expand

If I have apples and Johnny has less apples, give Johnny some of my apples until we have the same amount of apples.

In C:

Code Select Expand

do
{
if (x > y)
{
x--;
y++;
}
}
until (x == y)

I could boil it down to this in C#:

Code Select Expand

if (x > y)
x = y = ((x - y) / 2) + y;

Computer programming is algebra, not English. The two most painful languages I have to deal with from time to time are Visual Basic and COBOL. Both were initiated as languages that were to be as close to plain English as possible. Both fall well short of this.

Q.E.D.

P.S. That's the worst site design I've seen in a long time...

Just wanted to make a couple quick points...

1. Both of the above pieces of code (and actually the original problem statement) have a problem - what if the total number of apples is odd?

2. Ignoring that and assuming an even number, the C version could be shortened to:

Code Select Expand


while((--x) - (++y));

though it would execute even faster if it was written without a loop, like the C# above.