A place to discuss Joel on Software. Now closed.
This community works best when people use their real names. Please register for a free account.
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
Fog Creek Copilot
The Old Forum
Albert D. Kallal
I write entirely C++ and SQL at the moment, so I tend to view every problem as solvable with a hammer. Talking about the the safe-string vs. unsafe string problem referenced at http://www.joelonsoftware.com/articles/Wrong.html
I'd solve it a different way. I'd extend the string class to 'SafeString'. I'd set up conversions between the two classes, etc. etc. but (without thinking too much about it, probably not automatic conversions). This way, my COMPILER will detect if I'm doing something unsafe. Say, for example, trying to Write an unsafe string... Write would only accept SafeStrings.
The advantage of this way of doing things is that you CAN'T mess up. The compiler won't compile your code if you are messing things up. You are guaranteed that this sort of bug cannot slip into your code.
Now, I quite like Joel's justification for Hungarian. He's convinced me that I don't hate all Hungarian notation, just systems hungarian. But isn't this a better way still? The only obvious downside I can see is that you may well end up with thousands of different classes. That's not to discount this problem, of course.
I brought up the mechanical type checking issue in a previous thread: http://discuss.joelonsoftware.com/default.asp?joel.3.124370.6
I agree that this sort of thing can be done more easily by a real formal type system. Maybe using the semi-formal Hungarian Notation would be useful for the purpose of commenting some code, but I think the actual type constraints ought to be enforced by a formal process. There's no reason to introduce human error into this process.
Joel's way is easier to adopt.
Your way is more complicated but it does have the advantage of being idiot-proof. Somebody who doesn't understand the prefix notation could conceivably render a program insecure, whereas with your way they couldn't without breaking it.
I think yours is probably better in systems that *really* need to have bulletproof security (banking, etc.) whereas Joel's way will probably suffice for the rest.
I could see some use for that. The effect, if properly implemented, would be like Perl's taint mode.
Wednesday, May 11, 2005
Although, I think I'd have an 'unsafe string' class instead of a safe one. That way you could generate a safe string from the extended class.
Another way is to create a 'DisplayString' class, which not only makes the string safe but also does stuff like replace carriage returns with <br />.
How do you mean that Simonyi's way is easier to adopt? What if you bring a new programmer onto your team and they don't quite understand the explanation you've given for the "unsafe string" type? Would you rather find out about that misunderstanding right away (they come to you and ask "how come my code won't compile when I try to pass the user's input to the Write function?") or find out about it several months down the road when thousands of lines have been written and you're about to release your product to thousands of people?
This reminds me of the "you can do classes in C too!" argument. It's true that you can come up with a sort of ad-hoc class system. It's true that you can come up with an ad-hoc type system. However, because they're informal you leave yourself wide open to errors.
LOL, OP, exactly! Joel is just proving his lack of understanding of modern C++ programming.
That's what happens when you are a manager. And that's why working for a manger sux.
Wednesday, May 11, 2005
>How do you mean that Simonyi's way is easier to adopt?
>What if you bring a new programmer onto your team
>and they don't quite understand the explanation
>you've given for the "unsafe string" type?
Just tell them that any string input from a user on a form needs to have the prefix 'us' until it has been made safe to display, when you replace it with 's', which you can then display in normal HTML.
That's easier to understand than using different form of class. Though this may be a good application for the Decorator pattern.
Ritchie, it's not so tough to write a type-safe layer above ASP. I bet that Joel could get yet another intern to implement it along with a process to go back and forth between type-safe ASP and normal ASP with Hungarian-style type annotations.
Heck, maybe I'll make such a program myself.
Colm, I guess we'll just have to disagree. :)
As a very new programmer myself, I think I'm in the better position to judge which way a new programmer would be better able to understand ;)
I was about to write the same thing but you all beat me to it. In C++ you override operator= and it all becomes transparent and (hopefully) idiot proof.
Then again, Joel's exampl is done in a scripting language which probably doesn't allow you to do that so his point is still valid, under certain circumstances.
Wednesday, May 11, 2005
It boils down to the old debate between weakly and strongly typed languages, eventually. I don't think either are intrinsically better, they're just better for different things.
I probably wouldn't try to write a simple CMS in a strongly typed language and I wouldn't try and write an online banking application in a weakly-typed language. Same goes for the difference here.
I think Raymond Chen's post deals with this agrument.
The question he asks is "How do you tell the difference between code that has all the error checking is hidden away in clever typing, and when it is simply not there?
Once the clever typing is in place, you can rely upon the compiler to tell you if the type is being used incorrectly in some circumstances.
However, the compiler cannot tell you if the typing is absent, or in some way incomplete? How many programmers are qualified to state that your typing provides complete coverage for all circumstances?
With the 'code looks wrong' approach code is either right or wrong. Deciding if code is wrong or right is based upon simple rules that even a programmer of limited experience could understand an apply.
Ged, everything in programming is built on stupid rules that even an imbecile could learn and apply (nobody is dumber than a desktop computer). The real trick comes from saying in one line what an imbecile would say in 100.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz