4 ms·

> Will that make everyone happy? Of course not. But it's pretty much "expressive enough" and it makes dealing with filenames 10x simpler. Simple enough for a W

> Will that make everyone happy? Of course not. But it's pretty much "expressive enough" and it makes dealing with filenames 10x simpler. Simple enough for a Western language speaker, sure. Pretty inhibiting for a speaker of Kannada that they can't name their résumé file with their own name. > Require that every program that handles files in some capacity can handle every single possible weird unicode and control code subtlety in existence? I assert again that once you allow spaces, you're already in the situation that you need to treat filenames as sequences of bytes that need quoting. Also, I want to point out again that almost all of these problems are only when writing shell scripts. C programs or e.g. GUI applications with file pickers tend (with exceptions of course) to not have these problems since you get the filenames into them.

overgard 13y ago
Ok so fine, we allow people to write filenames top-to-bottom. So programs that show the filename in the title bar: how do they display it? Really big title bar? Align the title bar on the left or right? What if I mix english and Kannada? What then? Or what if I start with an english word in the terminal, and then switch to kannada, what's the terminal supposed to do? I haven't used a lot of asian language systems, but I'm going to guess two things that I'm pretty sure are true: A) they're already implicitly dealing with these restrictions, whether the file system enforces it or not B) they probably already have workarounds to deal with these cases anyway. (alternate scripts or whatever). Regardless of culture, I'm going to make what I think is a pretty obvious statement: good filenames are easy to type and unambiguous. If your filename is neither of those, it's not a good filename. The point of a filename isn't to be as expressive as possible, it's to be universal, descriptive, and easy to work with. None of that requires special characters. With regard to the space thing, I think it's overblown. Spaces are common enough that good software engineers think to handle it. Newlines in files? I've /never/ seen that, even though it's possible. Also, space doesn't require an escape character. Once you start getting to newlines, it does. Once you start introducing escape characters into it, it's an entirely new layer of complexity.
- hdevalence 13y ago
  Why are ASCII regarded as "normal characters", but Kannada, or Hangul, or Arabic, or whatever are "special characters"?
  - jerf 13y ago
    There is a reasonable, non-"culturist" answer to your question, which is that ASCII admits of a monospace typesetting in which each character is fully isolated in its own box and does not interact with any others across the box, nor are there any combining marks or any of the other vagueries of Unicode, and there's a very limited number of such characters. Possibly Hangul can claim that, I know Arabic and some other scripts can not. Other languages that can claim this include I believe all European languages (the accents are rare enough you can just represent them as characters of their own rather than combining marks) and Cyrillic. None of the ideographic languages can currently claim this, though I heard rumors that Japanese and Chinese are both experiencing some heavy pressure internally to go to an alphabetic subset of their language that actually would meet this criterion. (And not due to authoritative mandate, but rather the natural flow of language.) It is a problem when you have languages with fundamentally different rules trying to share the screen, and that is also not a culturist observation; indeed one would think that denying this would be the culturist position.
    - asdffdsa33 13y ago
      For Japanese, in a Unicode context, I've never seen a combining mark actually used.
      - duskwuff 13y ago
        While the precombined versions are much more common, Japanese does have combining characters to add voiced and semi-voiced marks to syllabic characters (e.g, か vs が, は vs. ぱ).
      - asdffdsa33 13y ago
        It does, but I've never seen them used in a Unicode context.
hisham_hm 13y ago
> Pretty inhibiting for a speaker of Kannada that they can't name their résumé file with their own name. That's what transliteration is for. I have no problems writing my name transliterated into the Latin script.

overgard 13y ago

Ok so fine, we allow people to write filenames top-to-bottom. So programs that show the filename in the title bar: how do they display it? Really big title bar? Align the title bar on the left or right? What if I mix english and Kannada? What then? Or what if I start with an english word in the terminal, and then switch to kannada, what's the terminal supposed to do? I haven't used a lot of asian language systems, but I'm going to guess two things that I'm pretty sure are true: A) they're already implicitly dealing with these restrictions, whether the file system enforces it or not B) they probably already have workarounds to deal with these cases anyway. (alternate scripts or whatever). Regardless of culture, I'm going to make what I think is a pretty obvious statement: good filenames are easy to type and unambiguous. If your filename is neither of those, it's not a good filename. The point of a filename isn't to be as expressive as possible, it's to be universal, descriptive, and easy to work with. None of that requires special characters. With regard to the space thing, I think it's overblown. Spaces are common enough that good software engineers think to handle it. Newlines in files? I've /never/ seen that, even though it's possible. Also, space doesn't require an escape character. Once you start getting to newlines, it does. Once you start introducing escape characters into it, it's an entirely new layer of complexity.

hdevalence 13y ago
Why are ASCII regarded as "normal characters", but Kannada, or Hangul, or Arabic, or whatever are "special characters"?
- jerf 13y ago
  There is a reasonable, non-"culturist" answer to your question, which is that ASCII admits of a monospace typesetting in which each character is fully isolated in its own box and does not interact with any others across the box, nor are there any combining marks or any of the other vagueries of Unicode, and there's a very limited number of such characters. Possibly Hangul can claim that, I know Arabic and some other scripts can not. Other languages that can claim this include I believe all European languages (the accents are rare enough you can just represent them as characters of their own rather than combining marks) and Cyrillic. None of the ideographic languages can currently claim this, though I heard rumors that Japanese and Chinese are both experiencing some heavy pressure internally to go to an alphabetic subset of their language that actually would meet this criterion. (And not due to authoritative mandate, but rather the natural flow of language.) It is a problem when you have languages with fundamentally different rules trying to share the screen, and that is also not a culturist observation; indeed one would think that denying this would be the culturist position.
  - asdffdsa33 13y ago
    For Japanese, in a Unicode context, I've never seen a combining mark actually used.
    - duskwuff 13y ago
      While the precombined versions are much more common, Japanese does have combining characters to add voiced and semi-voiced marks to syllabic characters (e.g, か vs が, は vs. ぱ).
    - asdffdsa33 13y ago
      It does, but I've never seen them used in a Unicode context.

hisham_hm 13y ago

> Pretty inhibiting for a speaker of Kannada that they can't name their résumé file with their own name. That's what transliteration is for. I have no problems writing my name transliterated into the Latin script.