3 ms·

I agree there's a grey line, but I'll take a stab at arguing that, yes, any time you rely on your parameter name for semantics it is an unforced error. I'll ar

by tel 13y ago

I agree there's a grey line, but I'll take a stab at arguing that, yes, any time you rely on your parameter name for semantics it is an unforced error. I'll argue in metaphor to documentation with similar caveats. Documentation is valuable and lack of it is confusing, but it's also impossible to ensure documentation is current (unless it's encoded in some kind of static verification system like a type system). This makes it so that your documentation can be a liability when describing your program semantics as it may simply be wrong. Likewise, using semantically meaningful variables names can be misleading as there's no way to ensure that the name is correct (unless you augment your HN system with a static verifier, which I've heard of people doing). These names can aid understanding but also can desynch and become confusing. I think of both like the colors of wires on a breadboard. They can be helpful, but fundamentally the value is in how the wires connect, not what their color is.

gfodor 13y ago
So to extend your breadboard analogy, Hungarian says you should have a dictionary of colors and everyone should learn the colors, since coloring a wire provides an informationally-dense, well suited way of expressing information un-ambiguously to those versed in the wire color convention. Non-Hungarian says you should attach a sticker with a small free-form written sentence explaining what each wire does, and each person can have their own general style for how they write these things, but the upside is they are intuitive and everyone can read them without learning a color dictionary. In either case the labeling/coloring of the wire is not fundamentally enforcing the wire's use, but experts are better served by conventions that may take time to adopt but convey information as efficiently as possible given the medium they must be used in.
- tel 13y ago
  I'm definitely not trying to defend the stickers, nor do I feel that taking this argument to its ultimate point retains any logic. My argument is that colors and tags are both potentially misleading, while the actual information and structure comes out of their connectivity diagram. Any time you put trust in anything else you're trading off safety for convenience. That isn't a bad thing, but it's a tradeoff that should be done conscientiously. Finally, I think it's illustrative to think about what would happen without HN (or, in analogy, without colored wires or little tags) because that drives you to solve the harder problem of how to represent the connectivity diagram of a breadboard directly, expressively, and in a way that solves the problems people face when building them. Analysis trumps documentation, except when it doesn't or is too expensive.

by tel 13y ago

gfodor 13y ago

So to extend your breadboard analogy, Hungarian says you should have a dictionary of colors and everyone should learn the colors, since coloring a wire provides an informationally-dense, well suited way of expressing information un-ambiguously to those versed in the wire color convention. Non-Hungarian says you should attach a sticker with a small free-form written sentence explaining what each wire does, and each person can have their own general style for how they write these things, but the upside is they are intuitive and everyone can read them without learning a color dictionary. In either case the labeling/coloring of the wire is not fundamentally enforcing the wire's use, but experts are better served by conventions that may take time to adopt but convey information as efficiently as possible given the medium they must be used in.

tel 13y ago
I'm definitely not trying to defend the stickers, nor do I feel that taking this argument to its ultimate point retains any logic. My argument is that colors and tags are both potentially misleading, while the actual information and structure comes out of their connectivity diagram. Any time you put trust in anything else you're trading off safety for convenience. That isn't a bad thing, but it's a tradeoff that should be done conscientiously. Finally, I think it's illustrative to think about what would happen without HN (or, in analogy, without colored wires or little tags) because that drives you to solve the harder problem of how to represent the connectivity diagram of a breadboard directly, expressively, and in a way that solves the problems people face when building them. Analysis trumps documentation, except when it doesn't or is too expensive.