4 ms·

>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,

>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.
    - mikeash 11y ago
      Apple is an interesting position here because of their massive clout. They could have introduced a language that looks like COBOL crossed with APL and it still would have been immensely popular just because they have such a huge base of fanatical developers. I think you're right that this sort of thing could pose trouble for adoption of a normal language, but Apple doesn't need to worry about it so much. I'm hoping that this will allow them to push the Right Thing even though some developers don't like it.
  - cookiecaper 11y ago
    Discoverability. Most people are going to try out "String".length first because that's what most other languages have. Whilst typing, if their IDE supports autocomplete, they'll see that 3 types of "String".length are available. Most people are not going to read through the entire list of methods of String and thereby discover .characters, .utf8, and .unicodeScalars when they want the character count of a string. I acknowledge that it may not be difficult to find this information with a quick Google search, but the more that can be done without having to switch to the browser or docs to look something up, the better. Injecting these so that they appear more frequently on the most likely UX path is better.

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.
  - mikeash 11y ago
    Apple is an interesting position here because of their massive clout. They could have introduced a language that looks like COBOL crossed with APL and it still would have been immensely popular just because they have such a huge base of fanatical developers. I think you're right that this sort of thing could pose trouble for adoption of a normal language, but Apple doesn't need to worry about it so much. I'm hoping that this will allow them to push the Right Thing even though some developers don't like it.
- cookiecaper 11y ago
  Discoverability. Most people are going to try out "String".length first because that's what most other languages have. Whilst typing, if their IDE supports autocomplete, they'll see that 3 types of "String".length are available. Most people are not going to read through the entire list of methods of String and thereby discover .characters, .utf8, and .unicodeScalars when they want the character count of a string. I acknowledge that it may not be difficult to find this information with a quick Google search, but the more that can be done without having to switch to the browser or docs to look something up, the better. Injecting these so that they appear more frequently on the most likely UX path is better.