This is an interesting question. Could you cite where this was stated/who they are? I would almost consider naming guidelines and OO principles as orthogonal to each other. However, I can see where people might take the position that variables names that indicate type, etc., would not be as abstract as a variable name that is purely domain based.
The only reason for time is so that everything doesn't happen all at once.
- Buckaroo Banzai
You can use the "Search" function at the upper right corner of the page to find past discussions using the phrase "hungarian notation" (or whatever other phrase you're interested in of course). Doing this, I find useful discussions here and here.
I wrote the style guide. Hungarian notation violates abstraction because it reveals what is inside. HN also makes code less maintainable. Suppose you want to change from and int to a long. If your variable is used 20 times, you have to change your code in 20 different places. Keep in mind that search and replace functions in editors are not always perfect.
I don't think Paul was talking about casting. Imagine the situation where a customer changes a requirement so that you must now allow for more than 256 widget types in your system. Unofortunately you have used 'byte' for the number of widget types throughout your code. Without HN, you only have to change the declarations of the variables from 'byte widgetCount' to 'int widgetCount' and recompile. If you use HN, you not only have to change 'byte bWidgetCount' to 'int iWidgetCount' in the declarations, but also everywhere it is used. And what if you have a method 'byte getWidgetCount()'? In general, The use of HN makes every type change during maintenance a major headache, and (IMHO) gives very little in return..