It seems to me that the Hungarian notation is just a noisy code smell indicating that the type system is too primitive. With proper types the compiler can disallow illegal operations automatically. Why would you need Hungarian notation then?
You still need to name concepts. Hungarian notation is actually as much about communication as it is about code.
You'll get a lot of the benefits simply by being really disciplined about being consistent and precise with how you refer to things. What Hungarian does is force you to out of necessity.
This is true. We used Hungarian Notation internally extensively. The most counterintuitive thing is that having a cryptic name for a concept can have advantages: it has a precise meaning, and if you don't know what it is, you can't convince yourself that you do. If there's a class in my code called, I don't know, "View", that's going to give me clues as to what it is, but it may also mislead me into thinking it should support certain operations that it doesn't, or that we're talking about a UI view when actually it's referring to a database view, or whatever. If you just string together a handful of random letters, at least when communicating with someone else you know you're talking about the same thing, and you'll use the same name consistently.
Not a good idea for code that you want people to be able to use without gaining a deep understanding of, but for collaborating on inventing new things, it's a very effective communication hack.
For about three years I maintained the official internal coding conventions documentation for the Microsoft Word development team. This was when we were working on Office 2007. I remember loving the spirit of Hungarian notation. Using it in practice was also a major lesson and shaped my valuation of naming variables and types.
That same timeframe we ported Word's codebase from C to C++. That meant rewriting a bunch of manually ordered vtables for COM as regular virtual member functions on classes, and sadly, the elimination of anonymous unions from the codebase. But, type systems have really taken over and I think that's a good thing.
Because Word was written in C it followed a beautiful pattern of functions calling other functions all the way down. It treated data as data, and did not utilize classes or inheritance. I later came to understand the value of that way of thinking but at the time I thought it was so old fashioned. Of course, lacking the OO mindset meant that Word also lacked a great deal of encapsulation, and had horrible coupling across certain modules. Most notably, Undo, and Display.
> The most counterintuitive thing is that having a cryptic name for a concept can have advantages: it has a precise meaning, and if you don't know what it is, you can't convince yourself that you do.
To see complete and total saturation of that concept, take a look at the source code of Urbit
I can confirm this is roughly what the intentional source code looked like.
Personally I found it a huge pain and an unnecessary difficulty, but opinions differed :). The bigger problem was a lot of the code was crap (yay research code!). The lack of english names only made this more difficult because it removed valuable clues as to what the intention of the author might have been.