This post originated from an RSS feed registered with Python Buzz
by maxim khesin.
Original Post: How to speak Hungarian
Feed Title: python and the web
Feed URL: http://feeds.feedburner.com/PythonAndTheWeb
Feed Description: blog dedicated to python and the networks we live in
So Joel Spolsky finally gave a decent explaination for the Hungairan notation insanity. Actually, he points out, the explaination of the Good Hungarian was out there all along. It just got so diluted by the Insane Hungarian that people basically threw the baby out with the bathwater.
I think there is another factor that contributed to the decline and eventual demise of Hungarian. Considering this factor makes me wonder if the demise was not untimely or undeserved, as Joel claims, but rather expected.
This factor IMO is simply the shift from procedural to OO languages and from weaker type systems to stronger ones. I'll explain what I mean using Joel's example. Curious what you think. Just one note: I don't particularly like his solution. I have a lot of respect for Joel outside of this issue and gained a lot from his wrinting. So please take any sarcasm below in stride.
The basic example is the unsafe string that is submitted to a web form and needs to be encoded to prevent the cross-site scripting security hole. See the original post for detalis. So Joel goes into this whole thing of making wrong code look wrong, etcetra, basically coming up with a special naming convention that attaches metadata to the string and string processing functions via a prefix and accomplishes this "look wrong" goal. Ok. But why just not use the type system? If using C is your excuse, fine. But in the more modern languages there is a much easier way to accomplish the goal - use a special type for the unsafe string! How about something like:
using a type there is just not way to screw up and forget the prefix. It takes very little code and here is your alternative:
" Heck, I can take it one step further, by naming Write to WriteS and renaming SEncode to SFromUs:
us = UsRequest("name") usName = us recordset("usName") = usName sName = SFromUs(recordset("usName")) WriteS sName
"
Rather than coming up with special 4-character naming conventions for many potential domain concepts I can get everything wi/out fear of mistake - misuse will be caught by the compiler.
One of the downsides of the solution I outlined is the "heavyness" (though again, look at the typeless alternative above). What the programmer might want is just an string, that works like a string in all respects, but has this "metadata", (a mini user manual) attached to it. In my solution the new class represents the metadata. Well it actually formalizes it into a type constraint, but at the cost of hiding the "data" type's funcitonality. E.g. I have to reimplement string concatenation in my UnsafeString class.
This is a legitimate concern, but in most languages that I know there are ways to deal with this: you can use inheritance, or some sort of automatic delegation to allow the wrapper "metadata" class to behave like the wrapped "data" class.
One particularly sweet solution I am itching to mention is outlined in the "template metaprogramming" book written by a couple of boost wizards. Unfortunately that chapter is not available online, but the basic idea was to represent the basic physical quantities: length, mass etc. with a domain-specific language built on top of the C++ type system (using crazy amount of templates, of course). A similar library can be seen here here, but the explaination is not as consice.
Personally I can live with the Hungarian in a very limited number of very common cases, such as dx and dy for window geometry used in context of GUI programming (although I would still prefer types). In all other cases I think Hungarian leads to craziness, and types should definitely be used.
Previous Topic
