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. 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…
