(Not the author of the post you're replying to)

Apps Hungarian is, to a first approximation, a way for your program to use a type system not supported by the language. It's an ugly hack, in no small part because the type-checking is done visually by the programmer, rather than automatically by the compiler. People only use it if there's substantial value in the type system they're bringing in... which generally only happens if the language's type system is inexpressive.

Regarding Pascal, it's important to note that the array length is not an optional part of the type. An array of length 10 is type-incompatible with an array of length 20. A function whose input is an array must specify the length of the array it accepts, and the function cannot be called with an argument of different length. I assume the author's overall point is that this type system, while strong, is not useful for meaningful work.

> Can you elaborate? I read the wiki page on Apps Hungarian. I am not following. How does/would this address issues with the type system in C?

Apps Hungarian allows you to encode information about the value a variable contains which you can't capture in the type system.

For example, imagine you're writing a program which handles user input. You need to distinguish between Sanitized Strings and Unsanitized Strings because if you don't, you open yourself up to security problems. Absent a way to extend the type system to put this information in a type, you do this:

    char *usStr; /* An Unsanitized String */

    char *snStr; /* A SaNitized string */

You add a couple letters to the beginnings of the variable names to encode what the type system doesn't.

You can see that if you have a line of code which says:

    snStr = usStr;

it is wrong, and your brain can print a full-color warning message with highlighting.

Bottom Line: Apps Hungarian makes it easier for you to be the type checker.

> I didn't really follow your Pascal example explanation of this, you first mentioned "because it tells you if the type system can be used to enforce invariants." But the went on to talk about array lengths. How does whether or not the invariants are enforced by the type system help you answer the question of whether or not it maps to the problem domain? Might you be able to provide another example? Thanks.

Array lengths are an invariant. They're just one I don't care about, because nothing in the problem domain is modeled by how long a given array is. The contents of those arrays are much more important, and the types should vary based on that, instead.

A somewhat simplistic example:

You have a program which prints travel itineraries for people who must be addressed correctly along the way, where correctly means using their prenomial and postnomial titles. For example "Dr. Mary Richards, Ph.D." would be insulted to be merely "Mary Richards" or "Dr. Mary Richards, MD". You also have to print route information, which is a list of towns and states, like "Baltimore, MD".

Therefore, you have to ensure three things: Prenomials are always prepended to names, postnomials are always appended to names, and town names are always suffixed with state abbreviations. Oh, and if you print a name without prenomials and postnomials, you'll not escape unscathed.

Wouldn't it be nice if the type system were capable of keeping track of which strings were prenomials, postnomials, personal names, town names, and state abbreviations, to ensure you never try to append a state abbreviation onto a personal name, and never try to print a personal name alone? Those are the kinds of interesting invariants I'm talking about.

Thanks for the thorough explanations. This is really helpful. Cheers.