These placeholder variables are the worst thing to happen to language documentation in the modern era. And so there’ll be none of this on Lingua Pragma. I’ll illustrate (meta-illustrate) the problem by demonstrating classes in ruby.
Example 1
class Dog
def speak
return 'woof'
end
end
class Dachshund < Dog
end
fido = Dachshund.new
fido.speak
=> 'woof'
Example 2
class Foo
def bar
return 123
end
end
class Baz < Foo
end
qux = Baz.new
qux.bar
=> 123
Which example conveys more information? Which is easier to quickly grasp? Which would you rather read?
Posted on April 21, 2012
These placeholder variables are the worst thing to happen to language documentation in the modern era. And so there’ll be none of this on Lingua Pragma. I’ll illustrate the problem by demonstrating classes in ruby. Compare:
Example 1
class Dog
def speak
return 'woof'
end
end
class Dachshund < Dog
end
fido = Dachshund.new
fido.speak
=> 'woof'
Example 2
class Foo
def bar
return 123
end
end
class Baz < Foo
end
qux = Baz.new
qux.bar
=> 123
Which example conveys more information? Which is easier to quickly grasp? Which would you rather read?
The dog motif in Example 1 came to me because my GF asked me to write an app to simulate a pet salon. And I’d model the classes something like this.
...and it's back up, now that I switched to a slimmer Wordpress theme. Apparently, a Linode 1536 isn't quite enough to handle a basic Wordpress install getting Slash-dotted. (!)
Foo, bar and baz are to generalized identifiers what i, j and k are to loop counters. They're not ideal, but they get the point across without taking the emphasis away from the underlying constructs.
Are foo, bar and baz understandable terminology people can relate to like dog and bark? Not always. But if you don't speak English, dog and bark may make the same amount of sense as foo and bar.
Foo, bar, baz, quux, et al. are throw away variable names. They don't describe anything or mean anything, so using them to show a class hierarchy makes no sense to begin with.
I may be quite off base here, but i think it has to do with the audience you are dealing with. Once the reader is somewhat familiar with more abstract reasoning, e.g. able to identify placeholders in places such as (in programming) function/variable naming, return values and such, it becomes evident that you can put any garbage 'thing' in there, and it doesn't matter. You can gloss over these naming details and distill the entire concept into something like: A function named something, that belongs somewhere, returns something.
I'm not entirely sure if the author uses "language documentation" as synonymous to implementation semantics, like OO. The above was written assuming he isn't, because in my mind OO is a concept largely unrelated to the underlying programming language.
If he doesn't, then priming the brain with a set of well-known entities or concepts and how they relate to each other and then mapping them to the material you are trying to teach is desired. But, there is a balance to be struck between abstract reasoning and tying abstract patterns to things such as a cat or 'mew'.
Wait, people use foo/bar/etc in code they share with others?
I use them frequently in one-off programs that are destined to be thrown away in a day, but never in code I share. They are, at least in my mind, markers of badly thought out code (so badly thought out that I didn't spend the time necessary to think up good variable names!).
13 comments
[ 14.4 ms ] story [ 42.2 ms ] thread(alternate link: http://webcache.googleusercontent.com/search?sugexp=chrome,m...)
Example 1
class Dog def speak return 'woof' end end
class Dachshund < Dog end
fido = Dachshund.new fido.speak => 'woof' Example 2
class Foo def bar return 123 end end
class Baz < Foo end
qux = Baz.new qux.bar => 123 Which example conveys more information? Which is easier to quickly grasp? Which would you rather read?
Posted on April 21, 2012 These placeholder variables are the worst thing to happen to language documentation in the modern era. And so there’ll be none of this on Lingua Pragma. I’ll illustrate the problem by demonstrating classes in ruby. Compare:
Example 1
class Dog def speak return 'woof' end end
class Dachshund < Dog end
fido = Dachshund.new fido.speak => 'woof' Example 2
class Foo def bar return 123 end end
class Baz < Foo end
qux = Baz.new qux.bar => 123 Which example conveys more information? Which is easier to quickly grasp? Which would you rather read?
The dog motif in Example 1 came to me because my GF asked me to write an app to simulate a pet salon. And I’d model the classes something like this.
Are foo, bar and baz understandable terminology people can relate to like dog and bark? Not always. But if you don't speak English, dog and bark may make the same amount of sense as foo and bar.
I'm not entirely sure if the author uses "language documentation" as synonymous to implementation semantics, like OO. The above was written assuming he isn't, because in my mind OO is a concept largely unrelated to the underlying programming language.
If he doesn't, then priming the brain with a set of well-known entities or concepts and how they relate to each other and then mapping them to the material you are trying to teach is desired. But, there is a balance to be struck between abstract reasoning and tying abstract patterns to things such as a cat or 'mew'.
I use them frequently in one-off programs that are destined to be thrown away in a day, but never in code I share. They are, at least in my mind, markers of badly thought out code (so badly thought out that I didn't spend the time necessary to think up good variable names!).