The RFC process seems to work quite well for defining and clearly documenting standards. But I simply cannot understand how this RFC adds any value. All it does is to define some words!
By way of comparison, RCF 2119 has been a very successful and useful RFC. A naive reader might think that it simply defines some words, providing definitions for "SHOULD", "MUST", "MAY", "REQUIRED", and "OPTIONAL". But that is not the case... it does not provide _definitions_ for these words. Instead, it provides a standard describing how they are to be used in writing standards documents. Whether we like it or not, is a fact of the English language that "The document should end in a newline." can mean that it is optional but desirable for a document to end in a newline, or it can mean that a document ending in anything else would be invalid. But the sentence "The document SHOULD end in a newline.", appearing in a standards document that references RFC 2119 is not ambiguous -- 2119 specifies a particular protocol for use of these words.
As far as I can tell, RFC 3092 has none of those redeeming qualities. It does not specify what a metasyntactic variable is, how to use one correctly, and which metasyntactic variable list to use... instead it just provides the definition and origins of "foo", "bar", and "foobar". A dictionary would be a better source for that, not an RFC.
It's a popular April's fool from the IETF. They do this sometime. Pigeon carrier protocol is another well known one: http://www.ietf.org/rfc/rfc1149.txt
A new extention to RFC 2324 to allow the brewing of tea, RFC 7168. https://tools.ietf.org/html/rfc7168 (RFC 2324 is HTCPCP HyperText Coffee Pot Control Protocol)
Just because they're april fools RFCs doesn't mean they don't work :
Almost every time foo/bar/etc used I think there are better alternatives. For example, when I see syntax explained like this
if (foo) { bar; baz; }
I would always prefer something like this
if (someCondition) { /* statements */ }
I like it even less when people use them completely outside metasyntactic contexts, for example saying "company foo can sue" rather "BigCorp Inc can sue". In both cases the reader has to think about what foo stands for.
We should have more informative example code. Readers should only have to think about the idea being explained, rather than -- for example -- pondering why the writer chose to use "foo" for a condition and "bar" for a statement.
I completely agree. I find concrete examples far easier to understand than random sequences of characters. Take some time to come up with a toy situation in which I would want to use your code, and use the nouns and verbs appropriate for that situation. It's much easier to translate concepts from a concrete example to my own situation than to try to figure out how "Foo" maps into my problem.
Reminds me of my favorite April Fools RFC, which no one seems to have mentioned yet: Increasing Throughput in IP Networks with ESP-Based Forwarding (http://tools.ietf.org/html/rfc5984).
I use foobar every day (shamefully often in printf style "execution reached this branch style" debugging I'll admit).
Often I'll have foo in one branch and bar in the other.
Along with all for loops using n as the control variable (blame a kids book on basic I read in the 80's for that one) it is so deeply embedded I literally don't realise I'm doing it.
As an aside: if you are a PHP programmer (please hold the jokes) and haven't seen FirePHP check it out (it also supports Chrome/Chromium), it allows you to dump server side stuff to the client console (via some header magic) and mostly doesn't (I've never seen it happen but not saying it's not possible) break anything (even on ajax requests which is a nice ancillary benefit).
Oh I don't feel any shame but admitting it does tend to get you a torrent of abuse from programmers of that "type" and I suspect most people will know what I mean.
I don't have time for zealots so I head it off where I can.
21 comments
[ 3.4 ms ] story [ 62.6 ms ] thread> a derivative of `foo' perhaps influenced by German `furchtbar'
> (terrible) - `foobar' may actually have been the original form.
This sounds unlikely...
I think I'll stick with FUBAR https://en.wikipedia.org/wiki/FUBAR#FUBAR
Because I always pronounce it /fu:/
By way of comparison, RCF 2119 has been a very successful and useful RFC. A naive reader might think that it simply defines some words, providing definitions for "SHOULD", "MUST", "MAY", "REQUIRED", and "OPTIONAL". But that is not the case... it does not provide _definitions_ for these words. Instead, it provides a standard describing how they are to be used in writing standards documents. Whether we like it or not, is a fact of the English language that "The document should end in a newline." can mean that it is optional but desirable for a document to end in a newline, or it can mean that a document ending in anything else would be invalid. But the sentence "The document SHOULD end in a newline.", appearing in a standards document that references RFC 2119 is not ambiguous -- 2119 specifies a particular protocol for use of these words.
As far as I can tell, RFC 3092 has none of those redeeming qualities. It does not specify what a metasyntactic variable is, how to use one correctly, and which metasyntactic variable list to use... instead it just provides the definition and origins of "foo", "bar", and "foobar". A dictionary would be a better source for that, not an RFC.
Here is a long list with other humor RFC's from IETF: http://www.cs.hmc.edu/~awooster/joke_rfcs.html
This years' batch :
A new X.509 certificate type : "NSA", RFC 7169 https://tools.ietf.org/html/rfc7169
A new extention to RFC 2324 to allow the brewing of tea, RFC 7168. https://tools.ietf.org/html/rfc7168 (RFC 2324 is HTCPCP HyperText Coffee Pot Control Protocol)
Just because they're april fools RFCs doesn't mean they don't work :
http://www.blug.linux.no/rfc1149
Often I'll have foo in one branch and bar in the other.
Along with all for loops using n as the control variable (blame a kids book on basic I read in the 80's for that one) it is so deeply embedded I literally don't realise I'm doing it.
As an aside: if you are a PHP programmer (please hold the jokes) and haven't seen FirePHP check it out (it also supports Chrome/Chromium), it allows you to dump server side stuff to the client console (via some header magic) and mostly doesn't (I've never seen it happen but not saying it's not possible) break anything (even on ajax requests which is a nice ancillary benefit).
I don't have time for zealots so I head it off where I can.