5 ms·

Based on Github searches I've done in the past a lot of code calling length on NSString was broken. Those people probably thought they were in the 99% who just

Based on Github searches I've done in the past a lot of code calling length on NSString was broken. Those people probably thought they were in the 99% who just needed the convenient 'normal' length. People not realising that length isn't giving them what they want is one of the things the Swift API aims to solve. Giving the wrong choice for most situations (and number of UTF-16 code units isn't what people want most of the time) the easy convenient name is just a recipe for broken code. It's bad API design, or at least unfortunate historical accident, and it's good to improve things when there is an opportunity to do so.

cookiecaper 11y ago
It's not an improvement to exclude functions that you know everyone wants from the API. It's just going to result in more mess, because we all know most people are going to search for "swift string length function" and copy and paste direct from Stack Overflow without more than skimming it. In practice, it just makes the behavior messy and non-standard, ultimately meaning Swift applications are more difficult and/or annoying to debug and maintain. The correct way to solve this would be to design the API so that the distinction between what you're getting and what you want is clear, and the place to go to get what you actually want is also clear. Including nothing is an admission that they couldn't do this.
- anon1385 11y ago
  >It's not an improvement to exclude functions that you know everyone wants from the API. Which functions have they excluded? You mentioned counting characters, but you haven't actually specified which definition of characters you want it to use. >The correct way to solve this would be to design the API so that the distinction between what you're getting and what you want is clear, and the place to go to get what you actually want is also clear This is what they have done.
  - cookiecaper 11y ago
    >Which functions have they excluded? You mentioned counting characters, but you haven't actually specified which definition of characters you want it to use. The typical human definition of characters. Humans usually don't think about bits or bytes and they shouldn't have to. A character is a single independent glyph, a separate unit that would be taught to a human whilst learning to write, regardless of the internal representation in the computer. If I need something else, I should ask for something else. Hypothetical API calls that may address this: "String".length() "String".lengthInBytes() "String".lengthInCodePoints() This would provide standard implementations for these common functions (circumventing the issue of copying a random chunk of code from SO and all its attendant problems), make it obvious that there is a difference to anyone browsing the docs and/or using autocomplete, and make it easy to select and use the one you actually want in a particular situation. This type of discoverability is an important component in a usable API.
    - mikeash 11y ago
      How is your suggestion any better than the actual Swift code for these? "String".characters.count "String".utf8.count "String".unicodeScalars.count Looks pretty much the same to me in concept and typing difficulty.
      - voxic11 11y ago
        If anything I like it more because it makes it very clear what you are getting back. Whereas with "length" I would be heading to the docs to check what that means.
      - brazzledazzle 11y ago
        I think it has less to do with typing difficulty and more to do with annoyance. Sometimes what people like is less about technical differences and more about previously built mental models that reduce cognitive overhead. In other words: It let's them simply start playing and experimenting without having to relearn things they take for granted. If most people (let's say 99% for argument's sake) expect "string".length to refer to character count and only 1% need something like "string".utf8.count why not just accommodate them and make the language more accessible? This reminds me a bit of UX design. I've seen people time and again make the mistake over the years of designing their UX in a vacuum. What they produced wasn't bad or hard to use, it just broke expectations. All that said, sometimes breaking expectations is exactly what you should do because someone has to for things to change and move in the right direction. And sometimes when you do that you're taking one for the team, so to speak. Of course I don't know shit, but if I were looking at making a language popular I'd weigh doing what's "right" against my desire to increase the popularity carefully.
coldtea 11y ago
>Those people probably thought they were in the 99% who just needed the convenient 'normal' length. And they probably indeed were.

cookiecaper 11y ago

It's not an improvement to exclude functions that you know everyone wants from the API. It's just going to result in more mess, because we all know most people are going to search for "swift string length function" and copy and paste direct from Stack Overflow without more than skimming it. In practice, it just makes the behavior messy and non-standard, ultimately meaning Swift applications are more difficult and/or annoying to debug and maintain. The correct way to solve this would be to design the API so that the distinction between what you're getting and what you want is clear, and the place to go to get what you actually want is also clear. Including nothing is an admission that they couldn't do this.

anon1385 11y ago
>It's not an improvement to exclude functions that you know everyone wants from the API. Which functions have they excluded? You mentioned counting characters, but you haven't actually specified which definition of characters you want it to use. >The correct way to solve this would be to design the API so that the distinction between what you're getting and what you want is clear, and the place to go to get what you actually want is also clear This is what they have done.
- cookiecaper 11y ago
  >Which functions have they excluded? You mentioned counting characters, but you haven't actually specified which definition of characters you want it to use. The typical human definition of characters. Humans usually don't think about bits or bytes and they shouldn't have to. A character is a single independent glyph, a separate unit that would be taught to a human whilst learning to write, regardless of the internal representation in the computer. If I need something else, I should ask for something else. Hypothetical API calls that may address this: "String".length() "String".lengthInBytes() "String".lengthInCodePoints() This would provide standard implementations for these common functions (circumventing the issue of copying a random chunk of code from SO and all its attendant problems), make it obvious that there is a difference to anyone browsing the docs and/or using autocomplete, and make it easy to select and use the one you actually want in a particular situation. This type of discoverability is an important component in a usable API.
  - mikeash 11y ago
    How is your suggestion any better than the actual Swift code for these? "String".characters.count "String".utf8.count "String".unicodeScalars.count Looks pretty much the same to me in concept and typing difficulty.
    - voxic11 11y ago
      If anything I like it more because it makes it very clear what you are getting back. Whereas with "length" I would be heading to the docs to check what that means.
    - brazzledazzle 11y ago
      I think it has less to do with typing difficulty and more to do with annoyance. Sometimes what people like is less about technical differences and more about previously built mental models that reduce cognitive overhead. In other words: It let's them simply start playing and experimenting without having to relearn things they take for granted. If most people (let's say 99% for argument's sake) expect "string".length to refer to character count and only 1% need something like "string".utf8.count why not just accommodate them and make the language more accessible? This reminds me a bit of UX design. I've seen people time and again make the mistake over the years of designing their UX in a vacuum. What they produced wasn't bad or hard to use, it just broke expectations. All that said, sometimes breaking expectations is exactly what you should do because someone has to for things to change and move in the right direction. And sometimes when you do that you're taking one for the team, so to speak. Of course I don't know shit, but if I were looking at making a language popular I'd weigh doing what's "right" against my desire to increase the popularity carefully.

coldtea 11y ago

>Those people probably thought they were in the 99% who just needed the convenient 'normal' length. And they probably indeed were.