Plain English Programming - Another kick at the can.

[mikegonta]

Plain English Programming - Another kick at the can.

[Brendan]

Hi,

Plain English Programming - Another kick at the can.

For English, the words "Uppercase the byte" are unnatural and should be replaced with something like "Convert the byte to upper case".

In fact, all of the code seems stilted and poorly worded. Just replace it with this code:

Code: Select all

To figure out if two strings (that have lengths) are equal; compare the lengths, then compare characters from both strings in order (e.g. first character of one string compared to first character of the other string, then second character of one string compared to second character of the other string, etc). If anything (length or characters) aren't equal then the strings aren't equal. For character comparisons; characters with no difference other than case shall be considered equal.

This shouldn't be a problem for a compiler that compiles plain English.


Cheers,

Brendan

[DavidCooper]

Thanks for giving it another kick - I failed to appreciate it properly the last time. Gerry is very impressive, patiently explaining his project over and over again to people who make ridiculous objections to it. He really has built something worthwhile - much better than I'd expected it to be. I will take the time to read up on it properly this time.

[Brendan]

Hi,

Thanks for giving it another kick - I failed to appreciate it properly the last time.

The entire point of a plain English compiler is to prevent the need for people to spend a lot of time learning a new language and all of that new language's keywords and rules. This language fails to meet that objective. It'd be easier for someone who knows English to learn Python than it would be to learn the compiler's "plain English" language.

I can admire someone that tried and failed (it is better than not trying at all); but it's obvious that these developers didn't even try.


Cheers,

Brendan

[DavidCooper]

The entire point of a plain English compiler is to prevent the need for people to spend a lot of time learning a new language and all of that new language's keywords and rules. This language fails to meet that objective.

You're right that it fails, but it's a good effort which succeeds to a much greater degree than I had expected. It does get clunky in places with such weird wording that there's nothing plain about it, but a lot of it does use simple natural wording which does the job. It's a working system which its creator clearly enjoys using and which may appeal to others.

I can admire someone that tried and failed (it is better than not trying at all); but it's obvious that these developers didn't even try.

Having read the 120 page manual (which is well written and entertaining), it's clear to me that they did try, and they achieved a lot. However, with individual programmers being able to decide how words are used (i.e. what they mean) to extend the number of words it is able to respond to, I can imagine trouble when two programmers who've worked independently with the language for a long time get together to work on a shared project, although if that isn't a big problem for Forth, it may not be a problem for Plain English either. What really impressed me about it though was how well its creator handled the linguistics without going to the trouble of trying to do natural language properly - I expected it to be a useless pile of pants, but it's actually a high-quality, functional product which deserves to be recognised as such, and which is well worth taking a look at just to see what it does.

[~]

Another way to program in an exceptionally effective way is to just meditate as you normally do on how to implement the next step, and write down the very phrase that occurs to you in a text file, a short phrase of what you really need to do next. That's it. It will serve as human assembly language that you can later use instead of having to use energy again just to think about what to do next.

Over time, you will have so many sequences in normal language, that you will be able to reuse those sequences, and that will speed up your development a lot. Will be very similar to when machines didn't even have proper assembly language, only that you will do it with your brain.

________________________________________
________________________________________
________________________________________
________________________________________
When implementing the actual code, you could also assume that what you are writing is a regular text file. Then just write everything as comments, but as soon as it occurs you how to write some code, just do it giving the variables/functions/keywords, names that match the paragraph you were writing, with proper syntactic structure.

Later you will be able to easily remember what you were doing because it will resemble a tutorial or a book. It allows you to apply complex human optimizations. I've been trying it and I see that when I identify bugs or poor/bad code, I end up coming with very optimized changes to the code as I read the full paragraph and try to make it make sense again.

The comments and the code are the same. The regular explanations are the part that makes the code as easy to understand as a tutorial, and the actual code is the part of the writing that calculates the very details we intend from what we are saying. They could be other parts of that paragraph that we want to execute, but for what we want to do in a given moment, the comment/code writing, points to what we need to execute.

Example

Convert Decimal to Hexadecimal


If we have a decimal number like 121, we have to divide %16 and get the remainder. For the first iteration, the remainder is 121%16 = 121/16=7.... 7x16=112 121-112 = 9.

That (9) is the least significant digit of the hexadecimal number, it's the remainder of 121/16, it is the modulo 121%16.

After dividing 121/16, we are left with 7, since this is lesser than 16 and that's the remaining decimal number, that is the last digit, the next most significant digit.

The hexadecimal number is left as:

(7)(9)

The above is intended to explain an Arithmetic problem with interleaved text and calculations, the math version of the same way of programming in a human readable way without leaving calculations or code when needed to implement.

Now we only need to write a program based on the above, with interleaved comments to write a dual tutorial/code text file that compiles. It's easier now.

We can also convert books to code in this way, we will learn to skip things that the book contains but that we cannot implement or add to the comments, and add them gradually to the code only as we need them for an implementation.

[Solar]

That's a good first step from "heaps of uncommented code" to "heaps of commented code".

But as long as you are working with a "normal" programming language, you are doing yourself a disservice if you attempt to "code along" a train of thought that was created with no regards to the peculiarities of the programming language in question -- because you can easily end up with a rather stilted design (if you stick too close to Plain English), or a huge discrepancy between comment and code (if you stick too close to the machine).

Design needs to be thought in terms of the language employed. You need to write up the "overall functionality", yes, but in-code comments should be phrased with regards to how the language used actually works. Procedural, Object-Oriented, Generic, Functional programming -- these require rather distinct design- and thought-patterns, and in-code comments should help someone already familiar with those patterns to follow your implementation.

If you are trying to bridge the gap between your code and someone not even familiar with, for example, OOP and its patterns (information hiding, objects messaging each other...), you are bound for failure.

As nice a thought as it might be -- "I just tell the computer what to do, in plain English" -- you will fail at some point. You either have to assume the programmer knows the elementaries (like branch and loop, making your language not that plain after all), or you're dumbing down the "plain" language to the point where it's no longer efficient to code in it.

As Strostrup said (paraphrased), you're a beginner but once, but an expert for most of your life. You'd want a language that's expert friendly, because that's what you will need most of your productive life.

[~]

It's a codetutorial, like a videotutorial. It compiles.

Normal words explain when complete in paragraphs. Code completes the normal words to execute what we want from them.

What is unclear to you because you're still learning it can be written in this way, but the parts that you can code at full speed because your creativity produces them easily can just be written as usual, and somebody else who doesn't understand them will have to decode them in a way like this.

This programming style makes the code to become mostly commented text, but it's highly useful to visualize chances of big optimizations at the code level, which will further be helped by the compiler optimizations, more than code without this feature.

Try it a few times and you will see how you can easily come up with extremely good natural optimizations that without the comments look as obscure as many compiler optimizations, despite being part of an average well-formed English sentence.

Who knows what would result if we translated all keywords to another language, who knows if writing code in other natural languages would result in other sorts or better optimizations for code written as regular technical document sentences.

With this style we are practically writing a technical paper designed to be compiled, so the comments and the code need to be updated at all times for anything to even make sense as the text is so dense that it's just designed to be read and only execute a few key points, but they all have some syntactical structure so the text needs to be rewritten whenever a change is made, but the compiled result is simply superior to just write brief machine code fast that will later become rapidly unreadable for a human.

It's just another win of the lay-man level at programming and explaining how it is done, but since we all have it, it can produce good and easy results with the same ease of writing tutorials, only that these ones execute.

[Schol-R-LEA]

Congratulations, ~, you just reinvented Literate Programming, except for, you know, the tools Knuth and those following him came up with to make it feasible.

(For the record, the book Literate Programming was published in 1992, but Knuth had been developing the idea - and the original WEB weave/tangle programs - for some years by that point. So, it was not really all that new even when he published on it.)

TBF, I always liked the idea; I was quite enthusiastic for FunnelWeb around 2004, though even then, that particular implementation had been unmaintained for about five years.

However, as Brendan has been quick to note in the past, there are serious problems with it as it is usually presented - it is really only suited to giving program examples, as for active development projects the text gets out of sync really very quickly without an inordinate amount of effort to keep to up to date.

Still, good job of catching up with ideas from the late 1980s.

[Solar]

What is unclear to you because you're still learning...

Son, I've had a (close) look at Literate Programming in the early 1990's.

Don't condescend on me.

...it's highly useful to visualize chances of big optimizations at the code level, which will further be helped by the compiler optimizations, more than code without this feature.

You're still looking at it from a beginner's perspective. Yes, a beginner might make optimization opportunities obvious (to an expert) if he is expressing intent verbosely. But that's 101 stuff you are talking about. Something that happens on StackOverflow or CodeReview.SE daily, without pamphlets surrounding the code. By the time you graduate, I'd fully expect you to write code that doesn't provide "chances of big optimizations at the code level", because you've had the stupid hammered out of you by that time.

Try it a few times and you will see how you can easily come up with extremely good natural optimizations that without the comments look as obscure as many compiler optimizations, despite being part of an average well-formed English sentence.

You are still afraid of the state of the art, and want to drag it down to your level of understanding. I know that phase. Most aspiring developers run through it at some point. Some, sadly, stay forever stuck in there.

Who knows what would result if we translated all keywords to another language, who knows if writing code in other natural languages would result in other sorts or better optimizations for code written as regular technical document sentences.

Not trying to put too fine a point to it, but you haven't even understood how a compiler works, let alone an optimizing one. As we've established rather clearly elsewhere, this is probably the best understood field of Computer Science.

It's like you proposing to NASA a radically new way to build a rocket from the things you found in your cupboard...

With this style we are practically writing a technical paper designed to be compiled, so the comments and the code need to be updated at all times for anything to even make sense as the text is so dense that it's just designed to be read and only execute a few key points, but they all have some syntactical structure so the text needs to be rewritten whenever a change is made, but the compiled result is simply superior to just write brief machine code fast that will later become rapidly unreadable for a human.

So you're massively increasing the workload (and chance for error) for any refactoring or design change. You'd be surprised how often those happen, in the real world, compared to "clean slate" implementation.

It's just another win of the lay-man level at programming...

Lay-mans have no business at programming other than becoming better at it.

Consider something like encryption software, or the software running the security systems in your car. There are things to be considered here that go way over the head of any layman, verbosely commented / explained or not. Or a compiler itself. If you don't understand the basics involved, no amount of literate programming will help you. I can't write a full-blown essay on cache timing side-channel attacks, known-plaintext attacks etc. etc. pp. ad nauseam when I implement an encryption algorithm. Or explain the various approaches to parsing when implementing a Bison (or Spirit) grammar. One, that's not what I'm being payed for. Two, the seminal works on the subject have already been written. Which is how I know about what I am doing.

You're still sitting there and waiting for some easier-to-understand technology to pick you up where you are sitting. It doesn't work that way. You have to get up and go to where the technology is.

[linguofreak]

Hi,

Thanks for giving it another kick - I failed to appreciate it properly the last time.

The entire point of a plain English compiler is to prevent the need for people to spend a lot of time learning a new language and all of that new language's keywords and rules. This language fails to meet that objective.

The objective is impossible to meet. Laymen don't have trouble programming because it's hard to pick up on the rules and keywords of a programming language. They have trouble programming because writing clear and correct instructions for complicated processes is hard. Natural languages are not precise, so the first thing you have to is rigorously define your terms and syntax. And once you've done that you suddenly have a new list of keywords and rules. Sure, those keywords and rules define an intelligible, if somewhat stilted, subset of a natural language, but you have to construct such a subset before you can get anywhere, you can't just use the natural language unmodified.

The correct use for a language like Plain English would be to demonstrate to students that the hard part of programming is writing clear and correct instructions. You start them out by showing them how to write precise instructions in Plain English, on paper. Then you give them an assignment to define their own subset of English suitable for precise instructions. Then you make the point that it's a lot less writing/typing to say "int x = 2+2;" than to say "Put the result of adding 2 and 2 into the variable x." Then you let them actually sit down at a computer and introduce them to whatever programming language you're actually using for the course.

But every attempt you see at a language like Plain English is an attempt to define a programming language that laymen can automatically write in because they understand their native language. And natural language lacks the rigor needed to make such a project feasible.

[Solar]

So much this ^^^

On the contrary, I think a Plain English programming language would make it harder for the layman to understand what is required from him.

I've had first-hand experience with "laymen" -- actually people who've been working with domain-relevant software for most of their professional lifes -- make statements like, "but the computer should be able to see that this word is a last name in this context, not a first name".

With a Plain English language, you'd end up with them writing e.g...

Code: Select all

If the second word is a lastname...

...and then fret about the fact that the computer doesn't know what a "lastname" is (let alone necessarily agreeing with the user on the definition of what a word is). "Hey, I told the computer, in plain English, so why doesn't it automagically understand..."

In a "normal" programming language, it is much clearer that you do have a string, but you'd have to define "word" and "lastname" yourself... instead of pretending a "real" understanding of plain language that simply does not exist.

If you go into AI levels of understanding, you'll find that the AI will have to ask a lot of questions to nail down your actual intentions... or it will come up with a software that almost works as intended, with the exception of that little detail...

[DavidCooper]

...you can't just use the natural language unmodified.

You could if everything was worded clearly enough, but in reality you'd have the natural language compiler asking you for clarification (or confirmation) most of the time and repeatedly editing your instructions with you (still in natural language) until they're sufficiently precise to implement. That is how natural language programming will be done, and more of the editing of the instructions will be done automatically by software over time as it has more intelligence and understanding built into it. Initially, natural language programming will be no less work than using any programming language, so few people will get the point - every new detail of any required algorithm will still need to be worked out the hard way by a programmer, so it will take just as long to build anything. However, it will immediately mean that it won't be necessary to learn a programming language to write programs any more, and a new programmer will gradually learn how to produce better instructions in natural language that don't lead to so much interrogation and editing, guided by what they see happen as the compiler helps them rework their wording and the structure of what they're asking it to do. They will rapidly learn to think like programmers. Many different wordings will be able to represent the same instruction, so the programmer will be able to apply his/her own style on it much more than normal, but the machine code produced will be identical.

The really big gains will only emerge later when the intelligence of the system is high enough for it to work out what you want from imprecise instructions and fill in more of the missing bits in what you're asking it to do based on what you most likely intend. You will see your instructions being speculatively reworked for you on the screen, while highlighted questions appear here and there for you to confirm that you want something done the way that's been suggested (or to reject it), while other questions may simply ask what you mean (in places where the machine can't guess what you want). The system will also supply details as to how it might like to rearrange parts of the program to optimise it, which you can either examine or ignore, depending on how much you trust it and whether you think you might be able to come up with something better, which in the early days you may well be able to do if you're an expert programmer. This will all happen, and specialist programming languages will decline rapidly, although some useful parts of them may still find their way into the natural language used by programmers where it adds to compactness, precision and readability, while each individual will be free to borrow things from any programming language they fancy. Each programmer's source code will be machine-convertible to a universal form with all programmer-specific jargon removed, and then be converted to any other programmer's preferred style if they wish to work on the program.

[Brendan]

Hi,

...you can't just use the natural language unmodified.

You could if everything was worded clearly enough, but in reality you'd have the natural language compiler asking you for clarification (or confirmation) most of the time and repeatedly editing your instructions with you (still in natural language) until they're sufficiently precise to implement. That is how natural language programming will be done, and more of the editing of the instructions will be done automatically by software over time as it has more intelligence and understanding built into it. Initially, natural language programming will be no less work than using any programming language, so few people will get the point - every new detail of any required algorithm will still need to be worked out the hard way by a programmer, so it will take just as long to build anything. However, it will immediately mean that it won't be necessary to learn a programming language to write programs any more, and a new programmer will gradually learn how to produce better instructions in natural language that don't lead to so much interrogation and editing, guided by what they see happen as the compiler helps them rework their wording and the structure of what they're asking it to do. They will rapidly learn to think like programmers. Many different wordings will be able to represent the same instruction, so the programmer will be able to apply his/her own style on it much more than normal, but the machine code produced will be identical.

No; initially "natural language programming with compiler asking for clarification" will be so frustrating that people will commit suicide before any program is written; and eventually (after an infinite amount of time and multiple miraculous breakthroughs) the compiler will become smart enough to commit suicide itself.

What we current have is:

• Machines that are incapable of doing anything except manipulating numbers
• Natural languages (e.g. English) that are so bad at describing how to manipulate numbers that humans invented a completely different language (mathematics)
• Programming languages that (despite being heavily influenced by mathematics) suck at mathematics
• Deluded fools that decided using mathmatics as a programming language is too hard, so they want to try something that's many orders of magnitude harder than "too hard"

It's like a child that tried to jump over a tall fence and repeatedly failed, who decides to stop trying to jump over the tall fence and try to jump over the moon instead. Of course children are never this stupid - this amount of stupidity requires trained adults.


Cheers,

Brendan

[Solar]

...you can't just use the natural language unmodified.

You could if everything was worded clearly enough, but in reality you'd have the natural language compiler asking you for clarification (or confirmation) most of the time and repeatedly editing your instructions with you (still in natural language) until they're sufficiently precise to implement.

After about 20 years of figuring out what the customer actually wants I can tell you that this will be, for the forseeable future, be beyond even AI levels of logic.

The customer usually does not have the skillset required to be precise enough for you to even ask the right questions about the things where the customer is ambiguous (i.e., everything).

Breaking down a complex problem (e.g. "figure out if this address is correct, and if isn't, find the most likely correct addresses this one could be referring to") into "computable" bits is the very thing that an aspiring software engineer needs to learn. That's the one thing that goes beyond languages, syntax, or handling the toolchain, and which we all have in common, no matter what kind of market our software aims at.

This skill is usually not taught in isolation, but in combination with a specific language, because the way we do break down a complex problem into lots of simple ones is heavily influencd by what our language of choice is capable of. Do we think in functions? Or objects? Neither are really represented in "natural" language. The programming language at hand is the vocabulary for this breaking-down process, and the more the language is geared to this purpose, the better.

To repeat, the user of our software does not have this skill, nor is he interested in acquiring it, nor is he necessarily capable of acquiring it, nor is it necessary for him to acquire it.

You need someone who has that skill, and some basic knowledge of the business at hand, so you can work out what questions to ask. You need to bridge the gap between business domain and technical design of the software.

So the point at which actual implementation is done is not the customer, or the business side, it's people who have learned how to break down problems, and how to express design / implementation in an unambiguous way.

At which point the benefits of a "Plain English" programming language rapidly diminishes.

To the contrary, actually. I found it much easier to express design and implementation in languages that do have very strict rules about what "works" and what doesn't, and are tersely expressive. The more "squishy" the language, the more problems I had "nailing" a design.

Functional languages aside (I have never mastered functional programming), I prefer C++ over Java over e.g. Groovy for that very reason. Because C++ allows me to express my design in very terse ways. (Looking mostly at strong typing, deterministic destructors, headers as documentation, and operator overloading here.)