5 ms·

This is actually a pretty thought-provoking question. Here's my take on it. First of all, the expressiveness of a type system can mean two rather different thi

This is actually a pretty thought-provoking question. Here's my take on it. First of all, the expressiveness of a type system can mean two rather different things. It can refer to what kinds of information the type system is capable of encoding/checking/etc. It can also refer to what kinds of information it can handle conveniently. With that in mind, I think Hungarian notation gets us three things. (1) Hungarian notation allows the encoding of information that some type systems cannot encode. (2) Hungarian notation allows for easy, simple, readable encoding of information that many type systems cannot encode conveniently. (3) Hungarian notation presents type information at the point of use, as opposed to declaration. Of course, Hungarian notation has disadvantages as well, but these are thoroughly discussed all over the place. (Regardless, anyone who wants to talk intelligently about Hungarian notation needs to read the Joel on Software article.[1]) So, certainly HN (not referring to this site!) can be a workaround for an inexpressive type system. It can also be a crutch for poor coding tools (as in #3 above). But even assuming awesome type systems and tools, I take issue with anyone who answers the question with an unwavering, "Yes, so don't use HN." To a person who makes such an argument, I must ask: are you really arguing that identifiers need not give any hint as to what they are bound to? Because that idea is kinda problematic. [1] http://www.joelonsoftware.com/articles/Wrong.html http://www.joelonsoftware.com/articles/Wrong.html P.S. Regardless of our answer to the original question, I think the fact that arguments like this occur at all underscores a point: naming things well is hard. I think that, in practice, this is one of the harder problems involved in software design.

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.
bcoates 13y ago
> Hungarian notation presents type information at the point of use, as opposed to declaration. > I must ask: are you really arguing that identifiers need not give any hint as to what they are bound to? Because that idea is kinda problematic. seanmcdirmid's live programming environment makes heavy use of a "gutter" between code lines to display things like possible values of variables and errors, I could see adding terse inferred type information there too, without the programmer having to type any of it or go through the error-prone process of updating it when it changes. I'm guessing the hard part would be identifying exactly what type information the developer cares about, heavy anonymous type inference can result in very verbose type specifications with lots of noise. http://research.microsoft.com/en-us/people/smcdirm/liveprogramming.aspx?iedz00 http://research.microsoft.com/en-us/people/smcdirm/liveprogr...

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.

bcoates 13y ago

> Hungarian notation presents type information at the point of use, as opposed to declaration. > I must ask: are you really arguing that identifiers need not give any hint as to what they are bound to? Because that idea is kinda problematic. seanmcdirmid's live programming environment makes heavy use of a "gutter" between code lines to display things like possible values of variables and errors, I could see adding terse inferred type information there too, without the programmer having to type any of it or go through the error-prone process of updating it when it changes. I'm guessing the hard part would be identifying exactly what type information the developer cares about, heavy anonymous type inference can result in very verbose type specifications with lots of noise. http://research.microsoft.com/en-us/people/smcdirm/liveprogramming.aspx?iedz00 http://research.microsoft.com/en-us/people/smcdirm/liveprogr...