3 ms·

>why isn't the compiler checking that type for you? Why can't your IDE follow the flow of that variable all the way back to its declaration The strength of the

>why isn't the compiler checking that type for you? Why can't your IDE follow the flow of that variable all the way back to its declaration The strength of the type system is really an orthogonal concern here. Why jump around in your code when that information could be contained in its name? Why do we use descriptive names at all when we can just analyze how the variable is used to understand its meaning? Clearly, more descriptive names are almost always a benefit. The type of the variable also provides a significant portion of its meaning. It's a matter of having as much contextual information presented with the least amount of friction. Hungarian notation does this for strongly typed languages.

WorldMaker 10y ago
I don't think that the strength of a type system is an orthogonal concern at all. I think there's a very distinct causation from the strength of the type system in C/C++ and hungarian notation. Much "weaker" dynamically typed languages typically don't see a need for it (Python, JS) and much stronger typed languages don't see a need for it (C#, ML family, Haskell). Hungarian notation, to me at least, finds most of its usage in a particularly painful "middle" of the strongly typed language spectrum where the language is strongly typed enough that subtle type differences are surprising footguns but not strong enough that the type system and compiler design provides you the tools/safeties to catch for you most cases when you are building a footgun. (With outliers like some BASIC variants whose typing system is a part of the variable naming system.) If anything, I think Hungarian notation is orthogonal to descriptive names. Sure, sometimes the type of something is useful descriptive information (though I'd argue rarely, even in strongly typed languages), but typically it's answers to the question "what is this variable for?" or "why does this variable exist at all?" I, at least, find more usefully descriptive. (Type information is pretty much never an answer to either question, it's much more to do with the mechanics of how the variable might accomplish its goals than what said goals actually are [1].) Certainly Hungarian notation has its places, and I'm not going to argue that it hasn't been useful in the history of languages, but I will argue that it's place in history is more as a historic tooling-related footnote than anything else. [1] The very rare exceptions that I know of are as you get into the deep end of super-strongly typed (mostly Haskell) stuff like type witnesses where knowing the type tells you everything and the type is almost more important than any actual variables of that type as the type has kind of suddenly "become" the algorithm.
- hackinthebochs 10y ago
  >Hungarian notation, to me at least, finds most of its usage in a particularly painful "middle" of the strongly typed language spectrum where the language is strongly typed enough that subtle type differences are surprising footguns I agree, but I think this has less to do with the type system and more do to with the immaturity of our API design ethos at the time. Certainly the weak static typing of C++ lead to lots of booby traps, and I agree that tooling should be able to mitigate the need for hungarian notation for this case. So for this aspect, the type system is central to the issue. But I see the power of hungarian notation in reading code and reasoning about how different pieces fit together. For languages like C/C++, owing to the conventions at the time and the relatively anemic facilities for abstraction, lower and higher level abstractions were often mixed together which made keeping the implementation details at the forefront a necessity. Having the type information carried along with a variable made this process a lot easier. Hungarian notation isn't needed anymore in modern languages (or even modern C++) because we've become so much better at following good design principles and our languages are much more powerful tools for abstraction.

WorldMaker 10y ago

I don't think that the strength of a type system is an orthogonal concern at all. I think there's a very distinct causation from the strength of the type system in C/C++ and hungarian notation. Much "weaker" dynamically typed languages typically don't see a need for it (Python, JS) and much stronger typed languages don't see a need for it (C#, ML family, Haskell). Hungarian notation, to me at least, finds most of its usage in a particularly painful "middle" of the strongly typed language spectrum where the language is strongly typed enough that subtle type differences are surprising footguns but not strong enough that the type system and compiler design provides you the tools/safeties to catch for you most cases when you are building a footgun. (With outliers like some BASIC variants whose typing system is a part of the variable naming system.) If anything, I think Hungarian notation is orthogonal to descriptive names. Sure, sometimes the type of something is useful descriptive information (though I'd argue rarely, even in strongly typed languages), but typically it's answers to the question "what is this variable for?" or "why does this variable exist at all?" I, at least, find more usefully descriptive. (Type information is pretty much never an answer to either question, it's much more to do with the mechanics of how the variable might accomplish its goals than what said goals actually are [1].) Certainly Hungarian notation has its places, and I'm not going to argue that it hasn't been useful in the history of languages, but I will argue that it's place in history is more as a historic tooling-related footnote than anything else. [1] The very rare exceptions that I know of are as you get into the deep end of super-strongly typed (mostly Haskell) stuff like type witnesses where knowing the type tells you everything and the type is almost more important than any actual variables of that type as the type has kind of suddenly "become" the algorithm.

hackinthebochs 10y ago
>Hungarian notation, to me at least, finds most of its usage in a particularly painful "middle" of the strongly typed language spectrum where the language is strongly typed enough that subtle type differences are surprising footguns I agree, but I think this has less to do with the type system and more do to with the immaturity of our API design ethos at the time. Certainly the weak static typing of C++ lead to lots of booby traps, and I agree that tooling should be able to mitigate the need for hungarian notation for this case. So for this aspect, the type system is central to the issue. But I see the power of hungarian notation in reading code and reasoning about how different pieces fit together. For languages like C/C++, owing to the conventions at the time and the relatively anemic facilities for abstraction, lower and higher level abstractions were often mixed together which made keeping the implementation details at the forefront a necessity. Having the type information carried along with a variable made this process a lot easier. Hungarian notation isn't needed anymore in modern languages (or even modern C++) because we've become so much better at following good design principles and our languages are much more powerful tools for abstraction.