The Case Against Insensitivity
Drew Thaler explains more about why he doesn’t like case-insensitivity in filesystems. My somewhat naive opinion on this issue is that putting these smarts in the filesystem smells like bad design. It solves a good part of the problem implicitly, which encourages it to be mostly ignored at higher levels, and makes it likely that some code will accidentally rely on the filesystem where it shouldn’t. In other words, I think the end-to-end argument applies to filesystem case-insensitivity.
12 Comments RSS · Twitter
It's not at all clear to me that this is the tradeoff. I think it's a user experience issue that could be solved at the framework level, potentially leading to a better UI and more robust application code. Hiding the details from the frameworks and applications only makes it appear that the filesystem took care of everything.
Michael, you don't appear to know the correct capitalization of your DNS domain name, judging by the 'mailto' URL at the bottom of this page. Aren't you glad you don't have to?
Most of those arguments - that it's poorly defined for non-ASCII, that it's a layering violation, that it forces layering violations on other code and is contagious - would apply equally well to DNS name lookups and email. (The difference is that thanks to the DNS spec, everyone does it the same way.)
cheers,
Hugh
Hugh: I always use lowercase for domain names, and that’s what the mailto URL uses. As a user, it doesn't much matter to me whether the domain name is case-sensitive because the rest of the URL generally is, anyway.
Which is exactly the point I was trying to make: the correct capitalization of your domain name is mjtsai.COM not .com. (See the root zone file of a DNS server for examples of canonical names at the top level.)
If the DNS system wasn't "hiding the details" you'd be getting a lot less email! (OK, maybe that could be considered a good thing...)
Hugh: OK, you’re right about the domain name, but I still don’t see the problem. Domain case is defined not to matter, so we’re all sloppy with it. In the path, it does matter, and yet this isn’t much of a problem because users have clickable links, bookmarks, and search engines. Likewise, for files they would still have open panels, drag and drop, etc.
>I think it's a user experience issue that could
>be solved at the framework level
So then you get inconsistencies between Carbon, Cocoa, X11, Java, plain old C apps, and so on. I think it's annoying enough that (for example) text components work differently in different apps, depending on what Frameworks they use. Apple has basically spent the last 6 years getting rid of inconsistencies between Carbon and Cocoa. Why introduce new ones?
More robust application code is useless if it's perceived by the user as less robust because of slight inconsistencies.
LKM: "Nobody cares what your code looks like," but they do care about how you're able to evolve that code. The original Mac OS code was ugly and unmaintainable. As a result, the OS stagnated. Microsoft never modernized their Visual Basic code, and so they had to drop it from Mac Office 2008. I'm not saying this is one of those cases, but I disagree with the idea that problems should always be left to fester until they create a user-facing problem. By the time you absolutely must fix the problem, there may be too much technical debt.
Of course, unmaintainable code makes development more expensive and may lead to stagnation (which, by the way, is not always bad - sometimes, users don't really want new features - but that is another subject entirely). I would also not advocate ignoring problems until they create usability issues. If you can make code more maintainable without sacrificing the UI, do it.
However, when given the choice between clean code and a better UI, I always go for the better UI, because that's what'll help users.
It's also worth noting that you have between 1 and 100 developers working on any given software project who are inconvenienced by crappy code. Often, you have thousands or hundreds of thousands of users of the same software project who end up being inconvenienced by crappy UI. It's obvious to me who should get the priority here, especially since we developers are paid by our users :-)
As developers, it's not our job to make our own lives easier. It's our job to make our users' lives easier. That means solving hard issues so our users don't have to.
LKM: Well, I don't think anyone was arguing for clean code at the expense of the UI. On the contrary, the whole point of discussing these issues early is so that if there needs to be a transition, developers can have the guidelines and APIs that they need ahead of time, thus making the transition as smooth as possible. It wouldn’t just be dumped on the users in rough form. In this case, HFSX already exists, so it would be possible to test all this stuff before the Future Filesystem is even ready.
Ultimately, the developer has to decide on the best way to serve the user. Sometimes this may mean reducing technical debt, othertimes not.
[…] Previously: The Case Against Insensitivity. […]
>putting these smarts in the filesystem
>smells like bad design
So? This is a pretty clear-cut case of usability vs. engineering. As an engineer, I would want the file system to be as simple as possible. As an interface designer, it's obvious to me that having case normalization above the FS level is going to lead to inconsistencies and issues in the UI.
It's important to remember that we don't design and write code for the code itself, but for the users. Good design is no excuse for bad UI.