3 ms·

> It's not a big advantage. EBCDIC, for example, didn't do that, and programmers managed just fine without it. You might try asking an old IBM programmer just

• dalke 10y ago
  EBCDIC had many problems, agreed. One is the non-contiguous range. Another is the many variants (https://en.wikipedia.org/wiki/EBCDIC_code_pages https://en.wikipedia.org/wiki/EBCDIC_code_pages lists 11, x2 for the Euro Update). But how serious is the problem? How many times do you need to test if a given character is one of the 26 allowed letters of the English alphabet, and where you implement it by testing it against the range? Typically you write it as "islower_english(c)" once, and be done with it. Is that really hard? If you do think that's a serious problem, then what of those programmers who need to test for lowercase letters in "España", "München", "Diyarbakır", and "façade"?
  • msbarnett 10y ago
    I mean, if you really want to get into it, it was a huge pain in the ass at a time when paying the cost of a call to islower_english was much more expensive than a hardware less-than instruction. We've broadly moved beyond that, but there's still value in grouping sets together in a way that makes certain kinds of frequent tests less computationally expensive than they would be if codepoints were randomly distributed.
    • dalke 10y ago
      Agreed. Though to point out, I believe xyproto's comment refers to the present. EDIT: Plus, if it were that important, IBM could implement the function in hardware. (Perhaps they did.)