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

Em ter, 19 de fev de 2019 09:42, Paul Robinson <[email protected]> escreveu:

> On 19 Feb 2019, at 11:09, Quantum Robin <[email protected]> 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
> https://ruby-doc.org/stdlib-2.6.1/libdoc/set/rdoc/Set.html
>
> 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] https://www.ncbi.nlm.nih.gov/pubmed/2804267
>
> Unsubscribe: <mailto:[email protected]?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

>


Unsubscribe: <mailto:[email protected]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>