7 ms·

Case sensitivity is a mistake in every platform that embraces it. I will die on that hill.

by Pxtl 8y ago

smilliken 8y ago
Unix filesystems? Names in programming languages? English? Care to elaborate?
- Pxtl 8y ago
  Case-sensitivity is such a rare concept in English that any API or programming language that is based on it cannot be semantically thought of as English, even though it uses English words for all its function and class names. I've used systems that are case sensitive and systems that are case insensitive, and the former are responsible for an order of magnitude number of bugs more than the latter.
  - dtech 8y ago
    CasE-SenSITIVITY IS rarE IN ENGLISH? I WiSh SOMEone would'VE TOLD mE EARliER!
    - palunon 8y ago
      Tell it to the lawyers writing disclaimers in uppercase.
      - drdaeman 8y ago
        That's an artifact of the years past, still alive because everyone is too afraid to do something about it, and most lawyers just don't care about styling. Every time I copy a license to the project, I edit the formatting to use Markdown bold (or sometimes italic/emphasis) instead of ALL THAT UPPERCASE SCREAMING. Much easier for the eyes. IANAL, but I believe that was the intent. Just to highlight the important sections to be even safer with "you have been warned about this and can't say you haven't noticed it". If any lawyer out there knows if this is correct understanding or not - would be interesting to hear.
    - acdha 8y ago
      When was the last time you had someone refuse to deliver a letter to YOUR NAME in YOUR CITY? Ever have trouble catching a plane because your drivers license says Alice but your boarding pass says ALICE? Normal people don't think of case as changing the value in the same way that even abbreviations or alternate spellings do — I know people who've had trouble boarding planes because they have ID/boarding passes which are inconsistent on, say, using ü or ue – especially annoying when the latter usage was just to work around a bug in someone else's system.
      - ghostly_s 8y ago
        Capitalization of proper nouns is a core semantic feature of English. While I'm sure you'll be tempted to hand-wave it away as a special case (see what I did there) of case-sensitivity, it nonetheless refutes your argument.
        Pxtl 8y ago
        The problem comes primarily from systems that allow identifiers (or other semantically meaningful concepts like format strings) to differ only by case. This could be considered a side-quest of the naive implementation of case-sensitivity. "Case-sensitive but identifiers cannot differ only by case" would be a reasonable compromise. "Martin" and "martin" are obviously not different names. Martin may be more correct, but allowing "martin" as a separate name is worse.
        anticensor 8y ago
        > Capitalization of proper nouns is a core semantic feature of English. It is a core spelling rule of English. They could have gone the German way, with all nouns capitalised and compound words without spaces.
        acdha 8y ago
        No, as you'd learn if you tried to find counter-examples for the cases I mentioned. Computer systems commonly treat terms which differ only in case as separate values but humans almost always try to do the opposite. People have preferences for proper usage but that's quite different from treating alternate case values as separate because people try to recognize the intention even if it's poorly expressed.
  - dghf 8y ago
    > Case sensitivity is a mistake in every platform that embraces it. > I've used systems that are case sensitive and systems that are case insensitive, and the latter are responsible for an order of magnitude number of bugs more than the former. Do you have "latter" and "former" transposed in the second quote? If not, I'm confused.
    - Pxtl 8y ago
      Oops, yes, corrected.
  - cryptonector 8y ago
    Rare? Practically every programming language is case-sensitive. Unix filesystems are generally case-sensitive. You statements make no sense anyways. What is the antecedent of 'it' in "... any API or programming language that is based on it ..."? Since when are APIs / programming languages "semantically thought of as English"?!
_asummers 8y ago
What about passwords? match?("AAA", "aaa") == true is a bug, to me.
- Pxtl 8y ago
  ... okay, I'll grant passwords as a rare exception, but I do wonder if "correct horse battery staple" isn't a better solution to the problem that password case sensitivity solves.
  - _asummers 8y ago
    When you get into international, your intuition breaks down. Unicode is a zoo. Greek, for example, has TWO lower case forms of capital sigma depending on where it's placed in the word, so how would your system handle that? Latin has similar quirks.
    - LyndsySimon 8y ago
      Technically, doesn’t English have two forms of lower case “s”? “s” and “ſ” - the latter being u017F.
      - ubernostrum 8y ago
        From the perspective of Unicode, no. What you're looking for here is what Unicode calls "equivalence", and it comes in two variations: canonical equivalence and compatibility equivalence. For example, "é" can be written as either U+00E9 LATIN SMALL LETTER E WITH ACUTE, or as the sequence U+0065 LATIN SMALL LETTER E followed by U+0301 COMBINING ACUTE ACCENT. These two options have canonical equivalence; what this means is that Unicode treats them as two ways of specifying exactly the same thing. Now, consider "½". That's U+00BD VULGAR FRACTION ONE HALF. Generally you can replace that with the sequence U+0031 DIGIT ONE, U+002F SOLIDUS, U+0032 DIGIT TWO ("1/2"). This is not quite the same thing; most places where someone writes "½" can safely be replaced by "1/2", but not necessarily all, and it definitely doesn't work in reverse. This is compatibility equivalence, and under compatibility equivalence "½" maps to "1/2". So to get to your actual question: U+017F LATIN SMALL LETTER LONG S has compatibility equivalence with U+0073 LATIN SMALL LETTER S. But U+03C2 GREEK SMALL LETTER FINAL SIGMA does not have any type of equivalence with U+03C3 GREEK SMALL LETTER SIGMA. If you follow the general recommendations for things like comparing Unicode identifiers, you'll apply normalization to form NFKC (which decomposes by canonical equivalence, then recomposes by compatibility equivalence); this will turn a "ſ" into a "s". It will never turn a "ς" into a "σ".
lmkg 8y ago
I'll go ahead and voice some support. My position isn't as extreme, but I do think that case-sensitivity is overused and should not be the default. There are places where it makes sense and should be used, but not many compared to how much it's used in the wild. This is especially true for programming languages. Case sensitivity means that fooBar and FooBar can be valid identifies in the same scope but refer to different bindings. I see many ways where that can produce an errors and very few (possibly none) where it can help create well-structured code. If the names shadow, clash, or override then the error cases become much easier to see and diagnose. Honestly one of my favorite tiny things about programming in Lisp is the identifier rules. The caps insensitivity, plus '-' being available because there's no infix operators, means that multi-word identifiers are easier to type (no shift key) and IMHO more aesthetically pleasing than underscores or snake case.
- Pxtl 8y ago
  Yeah, I could see a language taking the position that referencing fooBar as FooBar is an error, and that level of case-sensitivity makes sense to me (my name is Martin not martin) but allowing both Martin and martin to exist as distinct identifiers is crazy. On the subject of spaces, I do wonder why no language has used enough punctuation to make spaces allowed in identifiers. I mean, most Algol-derived languages could get away with it if they put punctuation between type keywords and variables: private, my class: my instance = my factory function(my parameter one, my parameter two);
  - jfk13 8y ago
    > make spaces allowed in identifiers IIRC from my days at Cambridge, Algol68 allowed that. (Our local variant was Algol68C.)
  - ken 8y ago
    Lisp allows spaces in identifiers, or any other character. You just have to escape them: (defun |my + function| (x y) (+ x y)) (|my + function| 2 2) (Or maybe write a reader macro to deal with them in some other way.)
cryptonector 8y ago
Typically case-insensitivity is a filesystem feature rather than a pervasive feature -- if some programming language is case-sensitive (most are!) then that's what it has to be regardless of platform/OS. So your comment doesn't quite make sense. The problem here isn't case-sensitivity anyways. The problem is that many programmers think Y instead of y for years because that's how it is in many contexts. E.g., the C strftime() and strptime() functions use %Y for four-digit year. I don't think case sensitivity is a mistake. Case is a mistake. But we have it, and we have case-sensitive and case-insensitive things. It is what it is.

Case sensitivity is a mistake in every platform that embraces it. I will die on that hill.

by Pxtl 8y ago

Case sensitivity is a mistake in every platform that embraces it. I will die on that hill.

smilliken 8y ago

Unix filesystems? Names in programming languages? English? Care to elaborate?

Pxtl 8y ago
Case-sensitivity is such a rare concept in English that any API or programming language that is based on it cannot be semantically thought of as English, even though it uses English words for all its function and class names. I've used systems that are case sensitive and systems that are case insensitive, and the former are responsible for an order of magnitude number of bugs more than the latter.
- dtech 8y ago
  CasE-SenSITIVITY IS rarE IN ENGLISH? I WiSh SOMEone would'VE TOLD mE EARliER!
  - palunon 8y ago
    Tell it to the lawyers writing disclaimers in uppercase.
    - drdaeman 8y ago
      That's an artifact of the years past, still alive because everyone is too afraid to do something about it, and most lawyers just don't care about styling. Every time I copy a license to the project, I edit the formatting to use Markdown bold (or sometimes italic/emphasis) instead of ALL THAT UPPERCASE SCREAMING. Much easier for the eyes. IANAL, but I believe that was the intent. Just to highlight the important sections to be even safer with "you have been warned about this and can't say you haven't noticed it". If any lawyer out there knows if this is correct understanding or not - would be interesting to hear.
  - acdha 8y ago
    When was the last time you had someone refuse to deliver a letter to YOUR NAME in YOUR CITY? Ever have trouble catching a plane because your drivers license says Alice but your boarding pass says ALICE? Normal people don't think of case as changing the value in the same way that even abbreviations or alternate spellings do — I know people who've had trouble boarding planes because they have ID/boarding passes which are inconsistent on, say, using ü or ue – especially annoying when the latter usage was just to work around a bug in someone else's system.
    - ghostly_s 8y ago
      Capitalization of proper nouns is a core semantic feature of English. While I'm sure you'll be tempted to hand-wave it away as a special case (see what I did there) of case-sensitivity, it nonetheless refutes your argument.
      - Pxtl 8y ago
        The problem comes primarily from systems that allow identifiers (or other semantically meaningful concepts like format strings) to differ only by case. This could be considered a side-quest of the naive implementation of case-sensitivity. "Case-sensitive but identifiers cannot differ only by case" would be a reasonable compromise. "Martin" and "martin" are obviously not different names. Martin may be more correct, but allowing "martin" as a separate name is worse.
      - anticensor 8y ago
        > Capitalization of proper nouns is a core semantic feature of English. It is a core spelling rule of English. They could have gone the German way, with all nouns capitalised and compound words without spaces.
      - acdha 8y ago
        No, as you'd learn if you tried to find counter-examples for the cases I mentioned. Computer systems commonly treat terms which differ only in case as separate values but humans almost always try to do the opposite. People have preferences for proper usage but that's quite different from treating alternate case values as separate because people try to recognize the intention even if it's poorly expressed.
- dghf 8y ago
  > Case sensitivity is a mistake in every platform that embraces it. > I've used systems that are case sensitive and systems that are case insensitive, and the latter are responsible for an order of magnitude number of bugs more than the former. Do you have "latter" and "former" transposed in the second quote? If not, I'm confused.
  - Pxtl 8y ago
    Oops, yes, corrected.
- cryptonector 8y ago
  Rare? Practically every programming language is case-sensitive. Unix filesystems are generally case-sensitive. You statements make no sense anyways. What is the antecedent of 'it' in "... any API or programming language that is based on it ..."? Since when are APIs / programming languages "semantically thought of as English"?!

_asummers 8y ago

What about passwords? match?("AAA", "aaa") == true is a bug, to me.

Pxtl 8y ago
... okay, I'll grant passwords as a rare exception, but I do wonder if "correct horse battery staple" isn't a better solution to the problem that password case sensitivity solves.
- _asummers 8y ago
  When you get into international, your intuition breaks down. Unicode is a zoo. Greek, for example, has TWO lower case forms of capital sigma depending on where it's placed in the word, so how would your system handle that? Latin has similar quirks.
  - LyndsySimon 8y ago
    Technically, doesn’t English have two forms of lower case “s”? “s” and “ſ” - the latter being u017F.
    - ubernostrum 8y ago
      From the perspective of Unicode, no. What you're looking for here is what Unicode calls "equivalence", and it comes in two variations: canonical equivalence and compatibility equivalence. For example, "é" can be written as either U+00E9 LATIN SMALL LETTER E WITH ACUTE, or as the sequence U+0065 LATIN SMALL LETTER E followed by U+0301 COMBINING ACUTE ACCENT. These two options have canonical equivalence; what this means is that Unicode treats them as two ways of specifying exactly the same thing. Now, consider "½". That's U+00BD VULGAR FRACTION ONE HALF. Generally you can replace that with the sequence U+0031 DIGIT ONE, U+002F SOLIDUS, U+0032 DIGIT TWO ("1/2"). This is not quite the same thing; most places where someone writes "½" can safely be replaced by "1/2", but not necessarily all, and it definitely doesn't work in reverse. This is compatibility equivalence, and under compatibility equivalence "½" maps to "1/2". So to get to your actual question: U+017F LATIN SMALL LETTER LONG S has compatibility equivalence with U+0073 LATIN SMALL LETTER S. But U+03C2 GREEK SMALL LETTER FINAL SIGMA does not have any type of equivalence with U+03C3 GREEK SMALL LETTER SIGMA. If you follow the general recommendations for things like comparing Unicode identifiers, you'll apply normalization to form NFKC (which decomposes by canonical equivalence, then recomposes by compatibility equivalence); this will turn a "ſ" into a "s". It will never turn a "ς" into a "σ".

lmkg 8y ago

I'll go ahead and voice some support. My position isn't as extreme, but I do think that case-sensitivity is overused and should not be the default. There are places where it makes sense and should be used, but not many compared to how much it's used in the wild. This is especially true for programming languages. Case sensitivity means that fooBar and FooBar can be valid identifies in the same scope but refer to different bindings. I see many ways where that can produce an errors and very few (possibly none) where it can help create well-structured code. If the names shadow, clash, or override then the error cases become much easier to see and diagnose. Honestly one of my favorite tiny things about programming in Lisp is the identifier rules. The caps insensitivity, plus '-' being available because there's no infix operators, means that multi-word identifiers are easier to type (no shift key) and IMHO more aesthetically pleasing than underscores or snake case.

Pxtl 8y ago
Yeah, I could see a language taking the position that referencing fooBar as FooBar is an error, and that level of case-sensitivity makes sense to me (my name is Martin not martin) but allowing both Martin and martin to exist as distinct identifiers is crazy. On the subject of spaces, I do wonder why no language has used enough punctuation to make spaces allowed in identifiers. I mean, most Algol-derived languages could get away with it if they put punctuation between type keywords and variables: private, my class: my instance = my factory function(my parameter one, my parameter two);
- jfk13 8y ago
  > make spaces allowed in identifiers IIRC from my days at Cambridge, Algol68 allowed that. (Our local variant was Algol68C.)
- ken 8y ago
  Lisp allows spaces in identifiers, or any other character. You just have to escape them: (defun |my + function| (x y) (+ x y)) (|my + function| 2 2) (Or maybe write a reader macro to deal with them in some other way.)

cryptonector 8y ago

Typically case-insensitivity is a filesystem feature rather than a pervasive feature -- if some programming language is case-sensitive (most are!) then that's what it has to be regardless of platform/OS. So your comment doesn't quite make sense. The problem here isn't case-sensitivity anyways. The problem is that many programmers think Y instead of y for years because that's how it is in many contexts. E.g., the C strftime() and strptime() functions use %Y for four-digit year. I don't think case sensitivity is a mistake. Case is a mistake. But we have it, and we have case-sensitive and case-insensitive things. It is what it is.