On 15/12/2021 12:23, Carsten Bormann wrote:
On 2021-12-15, at 13:05, Job Snijders <job=40fastly.com@xxxxxxxxxxxxxx> wrote:
All in all - I believe pseudo-code should be eradicated from the IETF's
body of work, rather than be wrapped or labeled. Use of pseudo-code
should be discouraged at all levels of our organization.
Non sequitur, I’d say.
Moi aussi.
Since programming got structured, concepts such a
if -then -else
do while
and such like have become universal and much clearer than a prose
descripion. Can be overdone of course but I would rely on the judgement
of an ART reviewer as to what is likely to be understood by most.
In the example quoted, I would add a few 'then' and perhaps semicolon
for end of statement
Tom Petch
Yes, pseudocode can have problems. As can any other form of description.
As long as author and reviewers are aware of these problems, they can be mitigated.
I’ll offer Page 4 of RFC 7396 as an example where pseudocode has worked very well (*).
Sure, this could have been translated into Python or Ruby without much change, but the pseudocode is readable to people with very different programming backgrounds.
What is a larger danger in my experience is lengthy sequences that really are pseudocode but are instead phrased as English prose (still with all the problems pseudocode can have, see above), without any explanation for *why* a particular (often confusing) algorithmic choice was made in that normative English-language-as-pseudocode implementation.
(This is also true of pseudo-formal descriptions other than code; a recent example was 7484bis where the English-language data description did not address some questions that were obvious once we tried translating them into CDDL — now CDDL is not pseudocode, but the translation clearly demonstrated that there was a false sense of security about the semiformal English-language description.)
Grüße, Carsten
(*) Well, except for the RFC 7386 desaster, but that was ASCII HT characters creeping into the final editing of an RFC…
.
