RFC 3092: Etymology of "Foo"(ietf.org)
ietf.org
RFC 3092: Etymology of "Foo"
http://www.ietf.org/rfc/rfc3092.txt
21 comments
Is your point that we should have more informative pseudocode or that readers should not have to think?
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.
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).
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).
There's nothing shameful about printf-style debugging.
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.
I don't have time for zealots so I head it off where I can.
[deleted]
"He who foos last foos best"
April 1, 2001.
So are you supposed to pronounce foo "f-oh-oh"?
Because I always pronounce it /fu:/
Because I always pronounce it /fu:/
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).
TIL: foobar may stem from German "furchtbar"
> , but it now seems more likely that FUBAR was itself
> 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
> 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
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.
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
Here is a long list with other humor RFC's from IETF: http://www.cs.hmc.edu/~awooster/joke_rfcs.html
Here is a long list with other humor RFC's from IETF: http://www.cs.hmc.edu/~awooster/joke_rfcs.html
Oops. I somehow overlooked the date.
http://en.wikipedia.org/wiki/April_Fools'_Day_Request_for_Co...
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
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
I would always prefer something like this
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.