Do you believe that the Plain English language is better than Ruby language?

Quantum_Robin · 19 February 2019 11:09

Hi!

If not, why not?

The Plain English language website is www.osmosian.com

Paul_Robinson4 · 19 February 2019 12:41

Do you believe that the Plain English language is better than Ruby language?

This feelies like trolling, but there might be an interesting point about the nature of natural vs programming languages here, so I'll reluctantly engage: no, I don't.

If not, why not?

Natural languages are not suitable for programming machines, because they lack direct succinctness and have too much openness to interpretation to be useful.

English is one of the most complex languages in the World to learn for a non-native speaker.

There are many reasons for this including lexical ambiguity. The same word meaning different things - at the extreme, "set" has over 450 different meanings in the Oxford English Dictionary, for example - whilst in Ruby it has one meaning given at Class: Set (Ruby 2.6.1)

What would 'Set' mean in your Plain English language? You're going to have to choose one of those 450 meanings, or you're going to have to do what English does: the context infers the meaning. Can you imagine how complex that becomes? How many bugs that this is going to create?

You might argue I've chosen an extreme example, but linguists tell us many natural languages have an average of 2.805 +/- 0.005 meanings per word [1], so you are going to have to face up to this problem sooner rather than later.

I mean the name of your language itself is confusing: at first I thought you meant the natural language, or the version the Plain English Campaign suggests is used, not an actual programming language. The problem is recursive even in your example.

Then there are homophones: words that sound identical but don't have the same meaning: two, too and to for example. When I'm pairing with somebody and I describe a solution, I don't want to have to clarify. I want to reduce the number of homophones in my programming language to make collaboration over a keyboard or a coffee or whiteboard easier.

Next up is synonymy where multiple words mean roughly the same thing: like, favour, admire, enjoy, love, etc. - which one do I use here in this context? Are all of them acceptable, or do they all have different meanings?

Let's now add to the small mountain of issues spelling differences. Do I express colours or colors? Do I sanitise input or sanitize it?

If you don't fix ALL of these problems, you have a language that is harder to work with than Ruby, but without the maturity of it as an environment.

This is just the tip of the iceberg. English is so vast, so vague, so complicated, that it lends itself to human expression brilliantly, but it also sits at the root cause of many disagreements. How many times have you had an "argument" where you later realised you and your opponent were actually in ardent agreement just phrasing the problem and the solution slightly differently?

Why would you want to replicate any of that in a programming language where we require precise meanings?

"Ah!", you say, "we've thought of all this. We use a subset of English".

Great, and so do we: it's called Ruby.

Let's look at some of your sample code:

  To create some works given a buffer:
    Destroy the works.
    Put nil into the current work.
    Slap a rider on the buffer.
    Loop.
    Move the rider (Googley image rules).
    If the rider's token is blank, exit.
    Create a work given the rider's token.
    Append the work to the works.
    Repeat.

What? I've seen more expressive assembler. How is this helping anybody? How is this maintainable?

The purpose of a programming language is to be able to create and use a subset of a language with low cognition overheard (i.e. moderately close to a natural language), that avoids the above issues. It's been that way since COBOL and FORTRAN, and arguably Ruby enables a programmer to this better than almost any other language.

Sorry to be so cynical about a project people clearly care about and created with a sense of love, but as a programming language it has a limited and fraught future.

Paul

[1] A word of a natural language has 2.718 different meanings or slightly more - PubMed

···

On 19 Feb 2019, at 11:09, Quantum Robin <quantumrobin40@gmail.com> wrote:

Robert_K1 · 19 February 2019 18:26

We cannot answer "yes" or "no" as long as no criteria are given. There
is no general "better" or "worse".

Kind regards

robert

···

On Tue, Feb 19, 2019 at 1:42 PM Paul Robinson <paul@32moves.com> wrote:

On 19 Feb 2019, at 11:09, Quantum Robin <quantumrobin40@gmail.com> wrote:

> Do you believe that the Plain English language is better than Ruby language?

This feelies like trolling, but there might be an interesting point about the nature of natural vs programming languages here, so I'll reluctantly engage: no, I don't.

--
[guy, jim, charlie].each {|him| remember.him do |as, often| as.you_can
- without end}
http://blog.rubybestpractices.com/

Quantum_Robin · 19 February 2019 18:39

>
>
> > Do you believe that the Plain English language is better than Ruby
language?
>
> This feelies like trolling, but there might be an interesting point
about the nature of natural vs programming languages here, so I'll
reluctantly engage: no, I don't.

We cannot answer "yes" or "no" as long as no criteria are given. There
is no general "better" or "worse".

How can you answer my questions?

···

Em ter, 19 de fev de 2019 15:27, Robert Klemme <shortcutter@googlemail.com> escreveu:

On Tue, Feb 19, 2019 at 1:42 PM Paul Robinson <paul@32moves.com> wrote:
> On 19 Feb 2019, at 11:09, Quantum Robin <quantumrobin40@gmail.com> > wrote:

Kind regards

robert

--
[guy, jim, charlie].each {|him| remember.him do |as, often| as.you_can
- without end}
http://blog.rubybestpractices.com/

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>

Quantum_Robin · 19 February 2019 21:39

It is better to point people to Plain English Programming blog rather than
just www.osmosian.com since there is more background material, more sample
programs, and more pictures on the blog.

The Plain English Programming blog is the following blog:

···

On Tue, Feb 19, 2019 at 9:42 AM Paul Robinson <paul@32moves.com> wrote:

On 19 Feb 2019, at 11:09, Quantum Robin <quantumrobin40@gmail.com> wrote:

> Do you believe that the Plain English language is better than Ruby
language?

This feelies like trolling, but there might be an interesting point about
the nature of natural vs programming languages here, so I'll reluctantly
engage: no, I don't.

> If not, why not?

Natural languages are not suitable for programming machines, because they
lack direct succinctness and have too much openness to interpretation to be
useful.

English is one of the most complex languages in the World to learn for a
non-native speaker.

There are many reasons for this including lexical ambiguity. The same word
meaning different things - at the extreme, "set" has over 450 different
meanings in the Oxford English Dictionary, for example - whilst in Ruby it
has one meaning given at
Class: Set (Ruby 2.6.1)

What would 'Set' mean in your Plain English language? You're going to have
to choose one of those 450 meanings, or you're going to have to do what
English does: the context infers the meaning. Can you imagine how complex
that becomes? How many bugs that this is going to create?

You might argue I've chosen an extreme example, but linguists tell us many
natural languages have an average of 2.805 +/- 0.005 meanings per word [1],
so you are going to have to face up to this problem sooner rather than
later.

I mean the name of your language itself is confusing: at first I thought
you meant the natural language, or the version the Plain English Campaign
suggests is used, not an actual programming language. The problem is
recursive even in your example.

Then there are homophones: words that sound identical but don't have the
same meaning: two, too and to for example. When I'm pairing with somebody
and I describe a solution, I don't want to have to clarify. I want to
reduce the number of homophones in my programming language to make
collaboration over a keyboard or a coffee or whiteboard easier.

Next up is synonymy where multiple words mean roughly the same thing:
like, favour, admire, enjoy, love, etc. - which one do I use here in this
context? Are all of them acceptable, or do they all have different meanings?

Let's now add to the small mountain of issues spelling differences. Do I
express colours or colors? Do I sanitise input or sanitize it?

If you don't fix ALL of these problems, you have a language that is harder
to work with than Ruby, but without the maturity of it as an environment.

This is just the tip of the iceberg. English is so vast, so vague, so
complicated, that it lends itself to human expression brilliantly, but it
also sits at the root cause of many disagreements. How many times have you
had an "argument" where you later realised you and your opponent were
actually in ardent agreement just phrasing the problem and the solution
slightly differently?

Why would you want to replicate any of that in a programming language
where we require precise meanings?

"Ah!", you say, "we've thought of all this. We use a subset of English".

Great, and so do we: it's called Ruby.

Let's look at some of your sample code:

  To create some works given a buffer:
    Destroy the works.
    Put nil into the current work.
    Slap a rider on the buffer.
    Loop.
    Move the rider (Googley image rules).
    If the rider's token is blank, exit.
    Create a work given the rider's token.
    Append the work to the works.
    Repeat.

What? I've seen more expressive assembler. How is this helping anybody?
How is this maintainable?

The purpose of a programming language is to be able to create and use a
subset of a language with low cognition overheard (i.e. moderately close to
a natural language), that avoids the above issues. It's been that way since
COBOL and FORTRAN, and arguably Ruby enables a programmer to this better
than almost any other language.

Sorry to be so cynical about a project people clearly care about and
created with a sense of love, but as a programming language it has a
limited and fraught future.

Paul

[1] A word of a natural language has 2.718 different meanings or slightly more - PubMed

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>

Andy_Jones · 20 February 2019 08:37

Do you believe that the Plain English language is better than Ruby language?

Better for what purpose? Is a 1989 Ford Mondeo better than an orange? I can’t drive the orange to work. But then again, I can’t eat the Mondeo.

Likewise, I can’t write a computer program in plain English (and many attempts to make a language that allows me to are all glorious failures, languages like Inform whose specific syntax you still have to learn, and which are a headache to debug code in).

And conversely, while you can write poetry or puns in Ruby, it’s an awful lot harder to do so, and they mostly don’t execute as anything useful.

···

From: ruby-talk [mailto:ruby-talk-bounces@ruby-lang.org] On Behalf Of Quantum Robin
Sent: 19 February 2019 18:40
To: Ruby users
Subject: Re: Do you believe that the Plain English language is better than Ruby language?

Em ter, 19 de fev de 2019 15:27, Robert Klemme <shortcutter@googlemail.com<mailto:shortcutter@googlemail.com>> escreveu:
On Tue, Feb 19, 2019 at 1:42 PM Paul Robinson <paul@32moves.com<mailto:paul@32moves.com>> wrote:

On 19 Feb 2019, at 11:09, Quantum Robin <quantumrobin40@gmail.com<mailto:quantumrobin40@gmail.com>> wrote:

> Do you believe that the Plain English language is better than Ruby language?

This feelies like trolling, but there might be an interesting point about the nature of natural vs programming languages here, so I'll reluctantly engage: no, I don't.

We cannot answer "yes" or "no" as long as no criteria are given. There
is no general "better" or "worse".

How can you answer my questions?

Kind regards

robert

--
[guy, jim, charlie].each {|him| remember.him do |as, often| as.you_can
- without end}
http://blog.rubybestpractices.com/

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org<mailto:ruby-talk-request@ruby-lang.org>?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>

Click here to view Company Information and Confidentiality Notice.<http://www.jameshall.co.uk/index.php/small-print/email-disclaimer>

Please note that we have updated our privacy policy in line with new data protection regulations. Please refer to our website to view the ways in which we handle your data.

Quantum_Robin · 20 February 2019 14:35

> Do you believe that the Plain English language is better than Ruby
language?

This feelies like trolling, but there might be an interesting point about
the nature of natural vs programming languages here, so I'll reluctantly
engage: no, I don't.

> If not, why not?

Natural languages are not suitable for programming machines, because they
lack direct succinctness and have too much openness to interpretation to be
useful.

English is one of the most complex languages in the World to learn for a
non-native speaker.

There are many reasons for this including lexical ambiguity. The same word
meaning different things - at the extreme, "set" has over 450 different
meanings in the Oxford English Dictionary, for example - whilst in Ruby it
has one meaning given at
Class: Set (Ruby 2.6.1)

What would 'Set' mean in your Plain English language? You're going to have
to choose one of those 450 meanings, or you're going to have to do what
English does: the context infers the meaning. Can you imagine how complex
that becomes? How many bugs that this is going to create?

You might argue I've chosen an extreme example, but linguists tell us many
natural languages have an average of 2.805 +/- 0.005 meanings per word [1],
so you are going to have to face up to this problem sooner rather than
later.

I mean the name of your language itself is confusing: at first I thought
you meant the natural language, or the version the Plain English Campaign
suggests is used, not an actual programming language. The problem is
recursive even in your example.

Then there are homophones: words that sound identical but don't have the
same meaning: two, too and to for example. When I'm pairing with somebody
and I describe a solution, I don't want to have to clarify. I want to
reduce the number of homophones in my programming language to make
collaboration over a keyboard or a coffee or whiteboard easier.

Next up is synonymy where multiple words mean roughly the same thing:
like, favour, admire, enjoy, love, etc. - which one do I use here in this
context? Are all of them acceptable, or do they all have different meanings?

Let's now add to the small mountain of issues spelling differences. Do I
express colours or colors? Do I sanitise input or sanitize it?

If you don't fix ALL of these problems, you have a language that is harder
to work with than Ruby, but without the maturity of it as an environment.

This is just the tip of the iceberg. English is so vast, so vague, so
complicated, that it lends itself to human expression brilliantly, but it
also sits at the root cause of many disagreements. How many times have you
had an "argument" where you later realised you and your opponent were
actually in ardent agreement just phrasing the problem and the solution
slightly differently?

Why would you want to replicate any of that in a programming language
where we require precise meanings?

"Ah!", you say, "we've thought of all this. We use a subset of English".

Great, and so do we: it's called Ruby.

Let's look at some of your sample code:

  To create some works given a buffer:
    Destroy the works.
    Put nil into the current work.
    Slap a rider on the buffer.
    Loop.
    Move the rider (Googley image rules).
    If the rider's token is blank, exit.
    Create a work given the rider's token.
    Append the work to the works.
    Repeat.

What? I've seen more expressive assembler. How is this helping anybody?
How is this maintainable?

The purpose of a programming language is to be able to create and use a
subset of a language with low cognition overheard (i.e. moderately close to
a natural language), that avoids the above issues. It's been that way since
COBOL and FORTRAN, and arguably Ruby enables a programmer to this better
than almost any other language.

Sorry to be so cynical about a project people clearly care about and
created with a sense of love, but as a programming language it has a
limited and fraught future.

Paul

[1] A word of a natural language has 2.718 different meanings or slightly more - PubMed

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>

I asked to the Gerry Rzeppa, the Grand Negus of the Osmosian Order of Plain
English Programmers:

Why do you not agree with the Paul Robinson?

The Gerry Rzeppa said to me:

For a number of reasons:

• Paul begins by stating, as a factual statement, something that our
program itself proves to be patently false:

"Natural languages are not suitable for programming machines, because they
lack direct succinctness and have too much openness to interpretation to be
useful."

And later he attempts to emphasize this same point:

"English is so vast, so vague, so complicated, that it lends itself to
human expression brilliantly, but it also sits at the root cause of many
disagreements. How many times have you had an "argument" where you later
realised you and your opponent were actually in ardent agreement just
phrasing the problem and the solution slightly differently?"

My elder son Dan and I were able to write, conveniently and efficiently, in
less than six months, a useful and virtually bug-free, non-trivial program
that tightly integrates and fully defines a unique desktop, a simplified
file manager, an elegant text editor, a handy hexadecimal dumper, a
native-code-generating compiler/linker, and a wysiwyg page layout facility
(that we used to document the system) in less than 25,000 natural-language
sentences. This proves, beyond the shadow of a doubt, that at least one
natural language IS suitable for programming machines; IS sufficiently
succinct; and IS precise enough to be useful as a programming language.

• Paul also shows his ignorance of our work when he says:

"What would 'Set' mean in your Plain English language? You're going to have
to choose one of those 450 meanings, or you're going to have to do what
English does: the context infers the meaning. Can you imagine how complex
that becomes? How many bugs that this is going to create?"

The meaning of the word "Set" in Plain English is determined by the
programmer, who describes the context in which it has that specific meaning
(in a routine header) and exactly what that meaning is (in the routine's
body).
It is not a complex matter; in fact, it is as simple as Forth, only
readable. And the remarkable reliability of our system -- not a single
major bug found in nearly 13 years of use -- attests to the fact that our
approach does not "create" bugs.

Then Paul simply gets silly, when he says:

"I mean the name of your language itself is confusing: at first I thought
you meant the natural language, or the version the Plain English Campaign
suggests is used, not an actual programming language."

We can all be silly about things like that. Does "Ruby" refer to a
transparent, deep red variety of corundum? or an Australian actress? or a
programming language?

• After that, Paul denies the obvious, saying:

"I want to reduce the number of homophones in my programming language to
make collaboration over a keyboard or a coffee or whiteboard easier."

What could possibly "make collaboration easier" than speaking to a fellow
human in the shared natural language used for ordinary conversation?
However many homophones English may have, they have not prevented people
from communicating their thoughts and feelings conveniently, efficiently,
and precisely to one another for thousands of years.

• Then Paul says...

"Next up is synonymy where multiple words mean roughly the same thing:
like, favour, admire, enjoy, love, etc. - which one do I use here in this
context? Are all of them acceptable, or do they all have different
meanings?"

...again showing ignorance of our work. The meaning of most words in Plain
English is determined by the programmer in his TYPE, global VARIABLE, and
ROUTINE definitions. Plain English thus operates with a context-sensitive
understanding of the programmer's local dialect, using whatever synonymous
wordings the programmer has deemed permissible in that context. Minor
adjustments have allowed us to create Español Llano, a version of our
system that understands both English and Spanish, even in the same sentence.

• Paul display his ignorance of our work again, when he says:

"Let's now add to the small mountain of issues spelling differences. Do I
express colours or colors? Do I sanitise input or sanitize it?"

This is the third of his objections that evokes the same essential reply:
most of the vocabulary (including alternative spellings, and even
mis-spellings), and much of the grammar of Plain English, are defined by
the programmer to suit his particular application and personal thinking and
writing style.

• Then Paul says:

"Ah!", you say, "we've thought of all this. We use a subset of English."
Great, and so do we: it's called Ruby.

Wrong twice. First, we don't "use a subset of English." Rather, we allow
the programmer to precisely yet flexibly define whatever subset of English
he deems suitable for his application and circumstances.

And secondly, Ruby is definitely not a subset of English. Collections of
letters like "elseif" and "undef" are not words in the English lexicon; and
a statement like...

file = File.open("res.txt")

...is hardly a proper English language sentence.

• Paul sums up his objections saying,

"The purpose of a programming language is to be able to create and use a
subset of a language with low cognition overhead (i.e. moderately close to
a natural language), that avoids the above issues... and arguably Ruby
enables a programmer to this better than almost any other language."

Except for Plain English, of course, which has the absolute minimum
"cognition overhead" since it allows the programmer to write his
natural-language thoughts in his native tongue, with ZERO additional
translation. This is not true of Ruby. For example, the thought...

Write "Hello, World!" on the console.

...in Plain English, is written exactly like that, as it would be if the
instruction were being given to another human. But in Ruby, this thought
must be translated to this unnatural formulation:

puts("Hello, World!")

I don't know about Paul, but I have never thought of saying "puts("Hello,
World!")" to another human in ordinary written or spoken communication
(unless, of course, I was talking about the Ruby programming language). But
I often find myself saying things in the general form, "Write this on
that," which is exactly what Plain English allows me to say in the source
"code" of an efficient, executable program.

Short answer: Paul does not know Plain English, so he doesn't know what he
is talking about.

Gerry

···

Em ter, 19 de fev de 2019 09:42, Paul Robinson <paul@32moves.com> escreveu:

On 19 Feb 2019, at 11:09, Quantum Robin <quantumrobin40@gmail.com> wrote:

Paul_Robinson4 · 20 February 2019 16:33

I asked to the Gerry Rzeppa, the Grand Negus of the Osmosian Order of Plain English Programmers:

Ah, so your only contribution here, "Quantum Robin", is to conduct a flamewar by proxy? Can I ask that you please do not continue to do that?

What could possibly "make collaboration easier" than speaking to a fellow human in the shared natural language used for ordinary conversation?

Based on the industry's experience of 70+ years: almost anything else, it turns out!

Natural language is inherently loaded with misunderstanding and ambiguity (it's a feature, most humour, irony, poetry and cryptic crossword clues couldn't exist without them!), that results in potentially catastrophic errors in a software engineering context.

This is why UML exists, even though we all wish it didn't. It's why automated test suites are an industry norm despite them being expensive to maintain. It's why good specification documents have tables and diagrams rather than stick to natural language, even though based on your argument, they are unnecessary.

You seem to try and duck this problem in PE by demanding the programmer defines the language semantics first in order to narrow the scope of ambiguity.

One problem with such an approach is that it would require a programmer to cognitively adjust when maintaining two programs written by two authors who have different meanings for the same word more so than they would in other languages.

Sure, we have this in Ruby when it comes to class names being the same in two programs with different functionality within them, but this difference is explicit and clear, but for PE to remain truly "natural", such differences must be minimised and implicit. Anything less, and it's no longer a "natural language" approach, after all.

"puts" might be an absurdly clunky shorthand for "Put on the screen" to your eyes, but at least it means exactly the same thing in every Ruby program I'm likely to ever have to pick up and maintain. Yet, 'Write "Hello" to the screen' in PE could mean different things if the author of the PE system I find myself in has changed the meaning of 'Write' or 'screen' in a way I had not anticipated.

You don't seem to have perceived or encountered such problems yet, and I am going to guess that this might be because the only people to have produced and maintained a significant amount of code in your language seem to be you and your son.

Take this into an enterprise code shop and see what they do with it, and you might learn a lot about human nature and problems with the language similar to the ones I have described.

What I fear is that PE will fail the "maintainable at team scale" test rather quickly, and worse given the tone of your reply you will find fault in the team rather than in your language.

Ironically for a language that seems to be borne out of a desire for empathy with the programmer, you may have designed an environment that is - completely unintentionally - passively hostile to them.

First, we don't "use a subset of English." Rather, we allow the programmer to precisely yet flexibly define whatever subset of English he deems suitable for his application and circumstances.

Your rebuttal reduces to "we don't use a subset of English, we make the programmer define a subset of English".

You haven't disproved my point, you've just made the whole idea even less attractive.

What you've described is what we call in Ruby "meta programming" and those of us who are a certain age spend a lot of time asking colleagues to avoid it.

Except for Plain English, of course, which has the absolute minimum "cognition overhead"

Based on your explanations and the source code that I have read, I do not believe this statement to be true beyond the point where a word is parsed at the surface level. Semantic and syntactic cognition seems to be harder in PE than any other programming language I know because as you've explained it, every word is defined differently in every program.

Short answer: Paul does not know Plain English, so he doesn't know what he is talking about.

Indeed, my short answer to this response could - if I was going to be as equally insulting and flippant - be something like: Gerry does not know professional software engineering, so he doesn't know what he is talking about.

Time to move on...

Paul

···

On 20 Feb 2019, at 14:35, Quantum Robin <quantumrobin40@gmail.com> wrote:

Hassan_Schroeder · 20 February 2019 17:01

LOL -- "13 years of use" by who, exactly?

Where are the examples? Where is the community?

···

On Wed, Feb 20, 2019 at 6:36 AM Quantum Robin <quantumrobin40@gmail.com> wrote:

-- not a single major bug found in nearly 13 years of use --

--
Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
twitter: @hassan
Consulting Availability : Silicon Valley or remote

Peter_Hickman2 · 20 February 2019 17:04

we allow the programmer to precisely yet flexibly define whatever subset

of English he deems suitable for his application and circumstances

The advantage of Ruby is that Set has a precise meaning that we all
understand even if we disagree as to what it should really be called

Array or list or vector. Hash or dictionary or associative array. Ruby
picks a term and defines it's behaviour, learn it and you can understand
anyones code. The cognitive load is lessened

APL was a programming language that was basically hieroglyphics and somehow
we could write programs that strangers could understand without ambiguity

As a programmer I don't want ambiguity. I don't want someone calling
something a Set when it is really a MultiSet. Array and vector are
different things to me but other programmers may not see the difference or
may not see them the same way that I do

To me list and array are synonymous but to others one is fixed length the
other extendable (but to me neither would be a vector)

Ruby defines that the term is array and that it is extensible. Like it or
lump it. But at least we all (Ruby programmers) have the same
understanding. I don't have to define Set or Array nor do I need to explain
them to anyone

Precision, lack of ambiguity and behaviour writ in stone

What are you offering?

Quantum_Robin · 21 February 2019 19:25

> I asked to the Gerry Rzeppa, the Grand Negus of the Osmosian Order of
Plain English Programmers:

Ah, so your only contribution here, "Quantum Robin", is to conduct a
flamewar by proxy? Can I ask that you please do not continue to do that?

> What could possibly "make collaboration easier" than speaking to a
fellow human in the shared natural language used for ordinary conversation?

Based on the industry's experience of 70+ years: almost anything else, it
turns out!

Natural language is inherently loaded with misunderstanding and ambiguity
(it's a feature, most humour, irony, poetry and cryptic crossword clues
couldn't exist without them!), that results in potentially catastrophic
errors in a software engineering context.

This is why UML exists, even though we all wish it didn't. It's why
automated test suites are an industry norm despite them being expensive to
maintain. It's why good specification documents have tables and diagrams
rather than stick to natural language, even though based on your argument,
they are unnecessary.

You seem to try and duck this problem in PE by demanding the programmer
defines the language semantics first in order to narrow the scope of
ambiguity.

One problem with such an approach is that it would require a programmer to
cognitively adjust when maintaining two programs written by two authors who
have different meanings for the same word more so than they would in other
languages.

Sure, we have this in Ruby when it comes to class names being the same in
two programs with different functionality within them, but this difference
is explicit and clear, but for PE to remain truly "natural", such
differences must be minimised and implicit. Anything less, and it's no
longer a "natural language" approach, after all.

"puts" might be an absurdly clunky shorthand for "Put on the screen" to
your eyes, but at least it means exactly the same thing in every Ruby
program I'm likely to ever have to pick up and maintain. Yet, 'Write
"Hello" to the screen' in PE could mean different things if the author of
the PE system I find myself in has changed the meaning of 'Write' or
'screen' in a way I had not anticipated.

You don't seem to have perceived or encountered such problems yet, and I
am going to guess that this might be because the only people to have
produced and maintained a significant amount of code in your language seem
to be you and your son.

Take this into an enterprise code shop and see what they do with it, and
you might learn a lot about human nature and problems with the language
similar to the ones I have described.

What I fear is that PE will fail the "maintainable at team scale" test
rather quickly, and worse given the tone of your reply you will find fault
in the team rather than in your language.

Ironically for a language that seems to be borne out of a desire for
empathy with the programmer, you may have designed an environment that is -
completely unintentionally - passively hostile to them.

> First, we don't "use a subset of English." Rather, we allow the
programmer to precisely yet flexibly define whatever subset of English he
deems suitable for his application and circumstances.

Your rebuttal reduces to "we don't use a subset of English, we make the
programmer define a subset of English".

You haven't disproved my point, you've just made the whole idea even less
attractive.

What you've described is what we call in Ruby "meta programming" and those
of us who are a certain age spend a lot of time asking colleagues to avoid
it.

> Except for Plain English, of course, which has the absolute minimum
"cognition overhead"

Based on your explanations and the source code that I have read, I do not
believe this statement to be true beyond the point where a word is parsed
at the surface level. Semantic and syntactic cognition seems to be harder
in PE than any other programming language I know because as you've
explained it, every word is defined differently in every program.

> Short answer: Paul does not know Plain English, so he doesn't know what
he is talking about.

Indeed, my short answer to this response could - if I was going to be as
equally insulting and flippant - be something like: Gerry does not know
professional software engineering, so he doesn't know what he is talking
about.

Time to move on...

Paul

Is Plain English a good programming language to teach basic programming
techniques?

If not, why the Plain English is not a good programming language to teach
basic programming techniques?

···

Em qua, 20 de fev de 2019 13:33, Paul Robinson <paul@32moves.com> escreveu:

On 20 Feb 2019, at 14:35, Quantum Robin <quantumrobin40@gmail.com> wrote:

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>

Robert_K1 · 22 February 2019 16:09

Easy: because it is not a programming language.

robert

···

On Thu, Feb 21, 2019 at 8:25 PM Quantum Robin <quantumrobin40@gmail.com> wrote:

Is Plain English a good programming language to teach basic programming techniques?

If not, why the Plain English is not a good programming language to teach basic programming techniques?

--
[guy, jim, charlie].each {|him| remember.him do |as, often| as.you_can
- without end}
http://blog.rubybestpractices.com/

Quantum_Robin · 22 February 2019 17:47

> Is Plain English a good programming language to teach basic programming
techniques?
>
> If not, why the Plain English is not a good programming language to
teach basic programming techniques?

Easy: because it is not a programming language.

robert

--

Why did you say that the Plain English is not a programming language?

[guy, jim, charlie].each {|him| remember.him do |as, often| as.you_can

···

Em sex, 22 de fev de 2019 13:10, Robert Klemme <shortcutter@googlemail.com> escreveu:

On Thu, Feb 21, 2019 at 8:25 PM Quantum Robin <quantumrobin40@gmail.com> > wrote:
- without end}
http://blog.rubybestpractices.com/

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>

Peter_Hickman2 · 22 February 2019 18:17

I'm getting flashbacks to Eliza based chatbots here

···

On Fri, 22 Feb 2019 at 17:48, Quantum Robin <quantumrobin40@gmail.com> wrote:

Why did you say that the Plain English is not a programming language?

Quantum_Robin · 22 February 2019 18:23

Why did you say that the Plain English is not a programming language?

I'm getting flashbacks to Eliza based chatbots here

I am not a Eliza based chatbots.

I want to know why the Robert Klemme said that the Plain English is not a
programming language.

···

Em sex, 22 de fev de 2019 15:18, Peter Hickman < peterhickman386@googlemail.com> escreveu:

On Fri, 22 Feb 2019 at 17:48, Quantum Robin <quantumrobin40@gmail.com> > wrote:

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>

CRAIG_JOHNSON · 22 February 2019 03:46

I've watched this....

After doing this stuff for 45 years....this has been amusing, but misguided....

Without significant software (compiler/interpreter) overhead---nat language is just a burden.

Tragically---intent may be good, but experience and understanding of the real issue of directing electrons about
silicon traces seems to be shallow...

Programming languages are build to do this right, everytime, clearly and unambiguously---natural languages do not share that feature.

thank you.

next please.

cj:)