@lispi314 @waldoj @SwiftOnSecurity I have to say I am a bit baffled that people find the foo/bar convention to be confusing when used to document in a generic way. To me, it is just like the convention of using x in math.
The whole point is they are easy to recognize as things you need to replace.
However I realize some newer programmers consider this convention to be a kind of gate-keeping by us old-timers, and that would be bad. So maybe it is time to stop using our cherished foo and bar.
it's not that it's confusing to follow (tho it can be), it's that it's way harder to make examples stick in memory compared to names that describe their use. additionally, if your primary language is far from english's pronunciations/word boundaries/etc it makes it a lot more inscrutable. cutesy names aren't worth the cost.
And I've met CS undergrads who don't know. so, seems worth just not using. naming's hard, but you write once and read many
@NireBryce @lispi314 @waldoj @SwiftOnSecurity I agree that if there are names that describe the use, they should be used instead of foo and bar
But sometimes the description is inherently abstract. Take this random example from the invert-kv docs:
Example: {foo: 'bar'} → {bar: 'foo'}
if you used something specific instead like
Example: {size: 'big'} → {big: 'size'}
then the reader might be confused whether the property had to be size or not. With foo/bar it's clear the names are arbitrary
@eob @NireBryce @lispi314 @waldoj @SwiftOnSecurity
In that specific case I think a more distinct pair might help. A typical number key to string value mapping, maybe?
Example: {3: "frog"} → {"frog": 3}
The actual example also throws a rainbow and unicorn emoji in there, which definitely feel like they make the foo/bar problem even worse to me.
@NireBryce @eob @lispi314 @waldoj @SwiftOnSecurity replacing x with apple will distract new learners with the semantics.
Like, you have 4 apples and split between 2 people, are the apples of the same size, is that fair.
Can't they cut the apples.
@eob @lispi314 @waldoj @SwiftOnSecurity For whatever it's worth: pixels are sufficiently inexpensive that documentation could easily include both!
Ideally, documentation can include the foo/bar abstraction for those it will help, and a "worked example" that demonstrates the pattern applied to a common example.
This "worked example" is how many textbooks introduce patterns. It'd be great for documentation to do the same.
@dtipson @villares @eob @waldoj @SwiftOnSecurity #AuditoryIcons (https://en.wikipedia.org/wiki/Earcon) might also be usable, for audio interfaces.
#Emacspeak is what introduced me to the concept, where they're used to denote lexical/syntaxic information for programming (among other things).
@dtipson They're pretty much already there.
I'd strongly suggest never enabling that in any networked software.
@dtipson Unless you tightly control exactly what is displayed on your screen & what you read, that'll mostly be used to uniquely optimize spam/ads for your consumption (nevermind all the other privacy implications).
LLMs will make that even easier now.
Naming things is hard. Foo/bar are still used because people writing examples don't want to come up with creative var names for sample code.
I don't find meta metasyntactic var names confusing (and I don't remember finding them confusing as a beginner either), but I still avoid foo/bar in examples because I don't vibe with old military jargon.
@eob @lispi314 @waldoj @SwiftOnSecurity
Yea this is an excellent point. Mathematics is full of short variables. You don’t see “volume_of_cone = …” It’s unreasonable to be ok with mathematical prose but for some reason want super long var names in cs prose.
@lispi314 @eob @waldoj @SwiftOnSecurity thought experiment: would you replace the symbol for pi with “ratio_of_circle_circumfrence_to_diamter” and use that everywhere?
Probably not. You would probably write let [pisymbol] =…. Then the brief symbol everywhere. It’s also a brevity thing - without variable substitutions the text would be a much more massive wall of text
@tjc @eob @waldoj @SwiftOnSecurity That is true, although very little text bothers to actually do those let parts for the various symbols. There's just the assumption you know everything.
Wikipedia Mathematical articles are widely considered useless for learning for exactly that reason. "Explanations? We don't need no stinking explanations."
Oh good it's not just me who can't make sense of their docs. Just started trying to use jq to solve an issue, now I have three issues.
@starblind @waldoj @SwiftOnSecurity you are the first person I've seen complain about this... I thought I was alone for like 25 years...
To this day, I can barely understand those man and help pages.
CppCon 2019: Kate Gregory "Naming is Hard: Let's Do Better"
@mrtnj @waldoj You know that old saw about opinions, I'm sure.
Continuing with the history lessons I guess: We all have it lucky today where we can have very lengthy names for things. That hasn't always been the case, Microsoft BASIC 2.0, for example, allowed up to two letters for a variable name. And you wanted to keep it short anyway, because the variable names used RAM and 3.5K on a Vic-20 was very limiting. And then of course variable names in machine language are zero characters long.
@waldoj I fully agree. (Also stay away from variable names like "lambda" or "rho". Spelling out the name of a Greek letter doesn't mean you know the purpose of the variable.)
Foo and bar also bother me because the names come from the military acronym "FUBAR" (pronounced FOO BAR). It means "f*cked up beyond all recognition" (https://dictionary.cambridge.org/us/dictionary/english/fubar). If they wouldn't write "F*cked up" as a variable name, then why would they think "foo" is acceptable?
@waldoj My personal theory is that writing "foo", "bar", and whatever the fuck else tells other computer touchers that you too are part of some special nerd club, like you are in the know.
I wish to not guess what the fuck "foo" and "bar" are supposed to represent. I wish to immediately understand what the example code is supposed to do!
@Chuck_ORourke @chucker @Hawlucha @waldoj Not that the origin matters a great deal, it only distracts from the point that they are primarily nonsense words.
(Further evidence is that in programming vars it is often the nonsense foursome foo, bar, baz, quux or more. baz and quux have no “military origin”, no backronyms. Are about as pure nonsense from Dungeon/Zork as possible to find.)
(If the military origin were more “true” you’d expect foo/bar more in error examples than general examples.)