A trigger was an output from my "man"-script with argument "mg"
<standard input>:10: warning: unbalanced .el request
(NB. Line number is wrong, because ...)
Another script showed more:
/usr/share/groff/1.22.3/tmac/mdoc/doc-common:690: backtrace: string `Dd'
/usr/share/groff/1.22.3/tmac/andoc.tmac:49: backtrace: macro `Dd'
<standard input>:4: warning: unbalanced .el request
Input file is /usr/share/man/man1/mg.1.gz
The part of the file around line number 690 is
.de Dd
.ds command-name
.ie \n[.$] \{\
.ie "\$1"$Mdocdate:" \
.ds date-string \$2\~\$3, \$4
.el .ie (\n[.$] == 3) \
.ds date-string \$1\~\$2 \$3
.el \{\
.ds date-string "\*[date-\n[mo]]
.as date-string \~\n[dy], \n[year]
.\}
.\}
.el \
.ds date-string Epoch
..
I did not see at first anything wrong, there are two left curly
brackets and two right ones. Each "ie" and "el" has a one line
argument or a block, but the code is FLAT, there is NO STRUCTURE
visible.
Using one indentation to show structure (dropping lines outside the
"ie"-clause:
.ie \n[.$] \{\
. ie "\$1"$Mdocdate:" \
. ds date-string \$2\~\$3, \$4
. el .ie (\n[.$] == 3) \
. ds date-string \$1\~\$2 \$3
. el \{\
. ds date-string "\*[date-\n[mo]]
. as date-string \~\n[dy], \n[year]
. \}
.\}
.el \
. ds date-string Epoch
There are still "ie" and "el" elements not showing structure, adding
indentation shows
.ie \n[.$] \{\
. ie "\$1"$Mdocdate:" \
. ds date-string \$2\~\$3, \$4
. el .ie (\n[.$] == 3) \
. ds date-string \$1\~\$2 \$3
. el \{\
. ds date-string "\*[date-\n[mo]]
. as date-string \~\n[dy], \n[year]
. \}
.\}
.el \
. ds date-string Epoch
So there are 2 "el" after each other without structured coding, which
is bad.
Adding still one indentation shows
.ie \n[.$] \{\
. ie "\$1"$Mdocdate:" \
. ds date-string \$2\~\$3, \$4
. el \
. ie (\n[.$] == 3) \
. ds date-string \$1\~\$2 \$3
. el \{\
. ds date-string "\*[date-\n[mo]]
. as date-string \~\n[dy], \n[year]
. \}
.\}
.el \
. ds date-string Epoch
So not until now is the lack of block delimiters visible after the
first "el" (2 indentations).
So correct would be
.ie \n[.$] \{\
. ie "\$1"$Mdocdate:" \
. ds date-string \$2\~\$3, \$4
. el \{\
. ie (\n[.$] == 3) \
. ds date-string \$1\~\$2 \$3
. el \{\
. ds date-string "\*[date-\n[mo]]
. as date-string \~\n[dy], \n[year]
. \}
. \}
.\}
.el \
. ds date-string Epoch
Adding more delimiters is still better
.ie \n[.$] \{\
. ie "\$1"$Mdocdate:" \{\
. ds date-string \$2\~\$3, \$4
. \}
. el \{\
. ie (\n[.$] == 3) \{\
. ds date-string \$1\~\$2 \$3
. \}
. el \{\
. ds date-string "\*[date-\n[mo]]
. as date-string \~\n[dy], \n[year]
. \}
. \}
.\}
.el \{\
. ds date-string Epoch
.\}
Creating blocks makes the structure future-proof. Lines can be added
or deleted inside each block without touching the elements that define
a block.
Some conclusions
1) Flat (without visible and complete structure) code is worse and bad
2) Missing block structure [for example one liners in "if ... (else)"
compound statement] is worse and bad
3) People make bugs without learning from them because ... (e.g. no
thinking)
4) People accept flat code (cause is ..., e.g. lack of education,
understanding)
[1] Education gives a person the capability of handling a situation
not seen before."
Herman Rubin in "misc.education" (Usenet)
[2] "Most of the cost of tuition, even in private schools, does not
come from the students.
But even if it did, most of the students do not want an
education, but a degree. The students expect to be spoon-fed as
they were in high school, and do not take kindly to the idea
that they should understand the principles and be able to
deduce which steps to take in a problem."
Herman Rubin in "misc.education" (Usenet)
5) Other people do not learn from the bugs other make, because ...
6) There are no or insufficient (worse) code rules (commandments) to
establish the best style for reading (understanding) (by people,
programs, compilers, interpreters, etc.). This should (may, must,
shall, has to) be in every tar-file (archive) that distributions
download from upstream, and users from the distributions. Thus more
people have direct access to it and can criticise it without loosing
time searching for it. But they can still loose time, it it is kept
worse (bad). Also people do then not waste time on a project, that does
not follow work procedure (practice, rules of conduct) they want to
adhere to.
7) The example shows that
a) both the writer of the bug and those who
accepted it for an official release lack professionalism
b) Neither of them document their creation of bugs or acceptance of
them, which is a necessary prerequisite for their own learning and that
of others.
c) There are no visible consequences for making bugs or accepting
them.
d) They thus can't become wiser nor others.
[3] There is a saying,
Any fool can learn from his own experience;
The wise man learns from the experience of others.
Now I do not believe that the first line is correct, but
very definitely the second.
Herman Rubin in "misc.education" (Usenet)
[4] I do not believe that the first line of this adage is correct;
too many seem unable to do so. But the second line is usually
right on. It took mankind thousands of years to learn concepts
which we can teach to small children, such as the ideas of
writing and alphabetic writing. The same holds for mathematical
concepts and the important mathematical notation.
Herman Rubin in "misc.education" (Usenet)
e) People do not make each structure element in the code FUTURE
PROOF.
f) People do not make code robust
g) People do not use their brain to test the code (only the complier,
interpreter, and even avoid (ignore) warnings from them or prohibit some
kinds of them)
h) Lack of references is common.
Some other quotations:
"This second radical novelty shares the usual fate of all
radical novelties: it is denied, because its truth would be
too discomforting.
I have no idea what this specific denial and disbelief costs
the United States, but a million dollars a day seems a modest
guess."
P. xxix in
"On the Cruelty of Really Teaching Computing Science"
Edsger W. Dykstra (Dijkstra)
SIGCSE Bulletin 1989, 21(1), pp. xxv-xxxix.
Also in "www.cs.utexas.edu/users/EWD/"
#
"Since breaking out of bad habits, rather than acquiring new
ones, is the toughest part of learning we must expect from that
system permanent mental damage for most students exposed to
it."
P. xxxvii in
"On the Cruelty of Really Teaching Computing Science"
Edsger W. Dykstra (Dijkstra)
SIGCSE Bulletin 1989, 21(1), pp. xxv-xxxix.
Also in "www.cs.utexas.edu/users/EWD/"
#
"The problems of the real world are primarily those you are
left with when you refuse to apply their effective solutions."
P. xxxviii in
"On the Cruelty of Really Teaching Computing Science"
Edsger W. Dykstra (Dijkstra)
SIGCSE Bulletin 1989, 21(1), pp. xxv-xxxix.
Also in "www.cs.utexas.edu/users/EWD/"
--
Bjarni I. Gislason
