Flickr

  • www.flickr.com
    Abiola_Lapite's photos More of Abiola_Lapite's photos

« The First Emigrants | Main | Crime and Organization »

May 13, 2005

Comments

Dan Phillips

One thing I like about Joel is that he is realistic about the "human frailty" of programmers. He is right to think that way; programmers are human and they make mistakes, in spite of the macho culture of programming. So, Joel says, Hungarian notation allows us to more easily spot bugs, such as in this line:

s = UsRequest("name") // bug

But -- wouldn't it make more sense to get the compiler to check for such bugs rather than us fallible humans? Why not make "unsafe" strings into a fully fledged type (instead of being merely a Hungarian "kind")? In a language like C++, errors like the one above could be found at compile time, and in a language like Python at run time (in which case I suppose Hungarian notation might make some sense).

Unless he has changed recently, Joel uses VB. (Not VB.NET.) Can one do the sort of checking I describe above in VB? That's a genuine question. I don't know. I suspect one can't, at least not without much pain. It seems to me that his example is a hack to make up for deficiencies in VB.

A good programmer, Joel says, has a sense of smell for good and bad code. Hungarian "kinds" smell pretty bad to me. How do I know that a variable called sFred really is a safe string? I would prefer that the machine check such things for me.

I do agree with him absolutely that good, consistent naming conventions are important, because the more readable code is, the easier it is to spot errors, as he says. That is, I agree with his main argument. (I just didn't find that example about safe/unsafe strings very convincing.) And the historical note about true Hungarian notation being subverted was interesting.

Joel writes so well, he often sounds more profound than he really is. Take his "Law of Leaky Abstractions". Everyone seemed to think he had discovered something wonderful. I never really understand what the fuss was about. He seemed to be saying that abstractions are often not perfect and can often break down, especially when one is talking about technology, and that some abstractions are better than others. Yes, I knew that already. Didn't everyone? I don't see what the great insight was there.

Abiola Lapite

"Why not make "unsafe" strings into a fully fledged type (instead of being merely a Hungarian "kind")? ... It seems to me that his example is a hack to make up for deficiencies in VB."

Ever hear of the Halting Problem? An unsafe string can be anything at all, including any program in any language which is short enough to fit into the string buffer; expecting an automated method for recogizing one is therefore asking the impossible. Joel's choice of language really doesn't make a difference here.

"How do I know that a variable called sFred really is a safe string? I would prefer that the machine check such things for me."

Again, you are asking the impossible, unless by "safe" all you mean is a string which uses only a very restricted set of characters - in which case we're dealing with an issue too trivial to be devoting much attention to, as a simple "s/blah/yada/g" will take care of the issue.

"He seemed to be saying that abstractions are often not perfect and can often break down, especially when one is talking about technology, and that some abstractions are better than others. Yes, I knew that already. Didn't everyone?"

Believe it or not, no, not everyone did (or does, even now.) You'd be surprised at how much people don't know: it's been my experience that for every competent person I've encountered in the IT industry, there are 20-30 complete duds pulling down a salary. I've seen feats of incompetence so staggering that it's hard to grasp how those who accomplished them are able to tie their own shoelaces in the morning.

Abiola Lapite

By the way, you might want to check out the following page to see how wily attackers intent on evading string checks can be:

http://ha.ckers.org/xss.html

Also check out the following page for more info on the difficulties of protecting against such attacks:

http://www.technicalinfo.net/papers/CSS.html

Asking for a compiler to automatically detect "safe" vs. "unsafe" strings seems to me to be asking for working AI at the very least, and a solution to the Halting Problem at worst; the "safety" of a string is highly context dependent.

Factory

"Can one do the sort of checking I describe above in VB?"
You can do it in any language that allows one to associate type information with value information, ie. anything turing complete.

"Ever hear of the Halting Problem? An unsafe string can be anything at all, including any program in any language which is short enough to fit into the string buffer"
Spolsky's example was of string which determined to be safe or not by it's origin (ie. comes from the user == unsafe), so that does not apply here, indeed any type information that can only be discovered at runtime is not compatible with hungarian notation since it is a write time technique.

"It's been my experience that for every competent person I've encountered in the IT industry, there are 20-30 complete duds pulling down a salary."
While I wouldn't be that pessimistic about the programming community (1:30 is out of line, 4:1 sounds better to me, then again I haven't worked in many places), I would have to say that morons are going to be better to adhering to something enforced by code than something which is enforced by a social contract. (OTOH they eventually work out how to screw that up too)

Abiola Lapite

"any type information that can only be discovered at runtime is not compatible with hungarian notation since it is a write time technique"

A very good point there.

Dan Phillips

>> Can one do the sort of checking I describe above in VB?
> You can do it in any language that allows one to associate type
> information with value information, ie. anything turing complete.

Well, sure, one could make an Abstract Data Type and provide a set of functions and procedures that operate on that type. But what I was asking is whether or not it is possible to have VB detect that this statement is an error:

safeString = unsafeString; // bad

(Using Joel's definition of unsafe.)

In C++, one could make a class called UnsafeString, say, and redefine its assignment operators and arrange things so that you get a compile error when compiling that line above. I suspect that would be a case of over-engineering though.

In Python, detecting that error seems to be impossible. (Python has no redefinable assignment operator.) In VB, I suspect it would be impossible too.

Thinking about this some more, Joel's solution seems to be pretty good. But I don't think it's the best. I think what I would do is the make a type called UnsafeString that contains a regular string, and provide it with a method or property called 'unsafe_string' that provides a way to get at the actual string. This property would have a comment explaining the situation about safeness and unsafeness. Programmers would have to think about what they are doing if they had to use a property called 'unsafe_string'.


Dan Phillips

> Believe it or not, no, not everyone did (or does, even now.)
> You'd be surprised at how much people don't know [about "Leaky
> Abstractions"]

I think you are right. What I'm trying to understand is what people mean by the word "abstract". What is it they are thinking when they use that word? Often it is different to how I use it. When Joel's Leaky Abstraction article came out, I read the comments about it on Slashdot. Most of them were along the lines of "abstract is bad" and "abstract is slow", or a qualified "abstract is good in its place but you must be careful with it". But how can one write and reason about a program without using abstraction? Never mind that programming languages themselves are abstract things, and so is the science and engineering behind the electronics of the physical computer all the way down to solid state physics of the thing. I wonder what it is that they mean.

Thanks for the XSS links. They were really interesting.

Abiola Lapite

"But how can one write and reason about a program without using abstraction?"

Beats me! Actually, I think what these critics are getting at is rather straightforward: once one gets used to dealing with certain abstractions enough, they come to seem real to one, so much so that one loses sight of their abstract quality altogether - for example, the real number line with all its transcendentals, or the complex plane. What these people are complaining about isn't that they're being asked to deal with abstractions at all, but that they're being asked to utilize *new* ones all the time, rather than being allowed to make do with the stuff they've already learnt. The last thing a guy who's sweated bullets to master the complexities of C++'s pointers, multiple inheritance, overloading and so forth wants to do is have to struggle through templates, generic programming, design patterns or whatever the new flavor of the month happens to be - especially if it's for the sake of doing things he already thinks he has a fairly good idea of how to implement using the toolkit he already has.

The comments to this entry are closed.

Notes for Readers