[erlang-questions] Help

empro2@REDACTED empro2@REDACTED
Sat May 4 01:24:25 CEST 2019


Provocative subject? Yes, of course, but also no, as you
will soon discover when you stick the following text into
your head (phrasing is impudent parody of a line delivered
by Black Adder II):

First my apologies for appearing trollish again;
obviously it was not that obvious that this

<http://erlang.org/pipermail/erlang-questions/2019-May/097861.html>

was no superfluous correction but meant to hint at
something larger and to split off a thread.

But it was not completely off topic:
We hone every *bit* when expressing ourselves to
silicon-based processors, but when trying to make ourselves
understood by carbon-based processors we tend to leave an
undue amount of work to them.

This does *not* mean that anyone choosing a sub-optimal
phrasing or even making a mere typo is sloppy or whatever
(This is especially true for people speaking English as a
foreign language, as I do).
And zxq9 (I hesitate to use first names without previous
authorisation, especially in East Asia) is very probably
much more fluent and expressive in English than I am, and
he certainly is so in Erlang (statement based on
having browsed the erlang-questions archive for years (2?)
before subscribing).

The line was simply a perfect example of how distracting
even a small "mistake" can be. *Can* be, was, to me, might
be to others, and in a context where every bit counts, too.

My intention was to hint at a waste of brain cycles (and a
strange dichotomy between programming and spoken languages):

* On the first layer people want to implement their vision
  in Erlang, which requires one or more layers of
  understanding (depends on complexity).

* This requires them to add one more layer where they look
  up specs.

* Often it requires them to add at least one more layer
  reading and understanding the user guide.

* Being thrown into "language analysis mode" by buggy
  writing takes them one layer further away, and this can
  be quite a thick layer.

The first three take them far from their actual work, but
they are more or less necessary (depending on experience).

I would simply like people to see how really *help*ful it
is to reduce this "unnecessary" last layer.
(told you the subject was not merely rethorical :-)

We write bugs into our software.
We write "bugs" into our writings.
We appreciate *help* with debugging our software
(the silicon simply being relentless).
We get irritated by *help* with debugging our writings?!

I do not, and I am suprised again and again by how many
people treat programming and spoken languages so
differently; do they respect processes running
on Si-based hardware more than those running on C-based
hardware?

Of course, many cases of "text bugs" waste few cycles;
many are "debugged" so quickly that they go unnoticed,
but they get debugged.
Unfortunately even a small waste is multiplied by the
number of times it is required, and texts get copied and
distributed and served and read and read and read again
many times.

The idea is to free capacity for complexity on higher
levels by reducing complexity on lower levels.

It is sad that combining this:

	Everyone wants to be a language designer.

<http://erlang.org/pipermail/erlang-questions/2019-February/097337.html>

with:

	The greater the number of people participating in a
	project, the more its outcome approaches mediocrity.

	- [I thought this was by D. Knuth, but I cannot
	  track it back to him now; but it does not matter
	  much who said something, more important is what
	  is being said.]

we get: spoken languages.

Is this of any help to stir interest in debugging texts?

<http://www.catb.org/esr/faqs/hacker-howto.html#skills4>

This all is only part of musings about how to improve
the Erlang documentation, not because it is bad but because
it is good enough to deserve being improved.

But this is a different story,
to be told at a different time ...
and in a different thread probably ...

Michael

--

Normality is merely a question of quantity,
not of quality.













More information about the erlang-questions mailing list