Funny Hungarian Notation Joke

From a conversation at Cyrus' Blather:

I think Hungarian notation is great. In fact, it should be used for everything, not just code development. For instance, see how much clearer things are if we prefix all nouns with a 'n', verbs with a 'v', adverbs with a 'd', and adjectives with a 'j'. Vdoesn't nthis vlook jbetter?

Nthat's dnot dreally jenough, though. Jplural nnouns vshould dreally vhave an nindicator, "pl". plnsubjects vshould vhave a "sbj" and sbjplnobjects vshould vhave a "obj" nprefix. Nwe vcan vuse "tr" for jtransitive nverbs, and trvuse "int" for jintransitive nverbs. Jour plndocuments vwill dthen vbe jmuch jclearer.

Now THAT'S comedy!

For those of you who've neven been assaulted by the idiocy of HN, it's basically a naming convention for variables in programming. The idea is that the type of the variable is attached to the name as an abbreviation. For example, if you have an pointer to an unsigned int named MyAge, then you'd have to prepend the initals pui to get puiMyAge.

HN is a relic from an era where compilers didn't give a hoot about types, and would let you assign anything to anything without complaining. These days, with quality languages like C++, the compiler bitches loudly if you try to fit a square peg into a round hole.

Some other Hungarian Notation Links:
Wikipedia Page on HN

A humorous example of Hungarian notation is this example:
a_crszkvc30LastNameCol : constant reference function argument, holding contents of a database column of type varchar(30) called LastName that was part of the table's primary key

The Good, The Bad and The Ugly
Some interesting points

Hungarian notation is, when all is said and done, a commenting technique. And the one great law of comments is that they lie. Comments are not syntax checked, there is nothing forcing them to be accurate. And so, as the code undergoes change during schedule crunches, the comments become less and less accurate.

The same happens with hungarian notation. When the type of a variable changes, it is not likely that you are going to hunt through all the code and change all occurrences of its name. Especially during the schedule crunch. Thus, the variables name will become a lie.

MSDN: Hungarian Notation
A 1999 paper by the inventor Simyoni, although it had been around for about a decade by then.

Simonyi has moved onto bigger things since then. His current idea is generative programming. All you need, he says, is a system where the customer writes the spec, and that spec is automatically converted to bugless software.

He doesn't say it outright, but it seems that the point is to get rid of software developers. In the process of coding, he says that programmers take a good spec and and put it through

the funhouse mirror of software coding, [where] it becomes all but unrecognizable: thousand times fatter, disjointed, foreign.

That reminds me of this Alan Perlis epigram:

When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop.

Oh yeah, also in the same article Simonyi gripes about automated scheduling:

The scheduling program for the airline takes many thousand times more memory than what I believe it should be. Hence the software represents complexity that is many thousand times greater than what I believe the problem is.

Dummy. Someone should tell him that scheduling is NP-complete -- the difficulty of the problem increases exponentially with the number of elements; there is no easy way to do it. (And if you do find an easy way, someone will give you a million dollars.) I can't believe that guy was Microsoft's Chief Software Architect at one time. On second thought, I take that back; it makes perfect sense.