Once again, strings are not simple sequences of characters. It's also useless to "index" into a string without specifying what you're indexing for the same reason.
It’s not wrong that "🤦🏼♂️".length == 7 (2019)
31–40 of 315 posts
Re: It’s not wrong that "🤦🏼♂️".length == 7 (2019)
#32Earlier quoted context omitted.
I think he meant to bring out defensiveness with that quip. He never says that it's a big deal, just that it's the worst way to get the length of a string containing emoji, presumably of the mainstream languages.
Why is it the worst way though?
Perhaps the part about it needing lookups of the unicode database and being dependent on the version of the database used?
Re: It’s not wrong that "🤦🏼♂️".length == 7 (2019)
#33> Python 3’s approach is unambiguously the worst one, though. Did I miss the part where he explains this take? It's made up of 5 valid unicode code units. For a language where you're not supposed to need to know the byte size semantics, the correct length should be 5. What am I missing? The close second being 17, because length in bytes. Is another fine way to represent this data, e.g. what a successful write of some…
5 makes perfect sense to me; the author's complaints seem kinda silly.
An area this makes sense is, what do you expect to get if you do something like:
emoji = " "
print(emoji[:3])
Modern strings are complex objects that have evolved a bit past char[] or byte[].
Re: It’s not wrong that "🤦🏼♂️".length == 7 (2019)
#34I'm not a fan of "everything you know about X is wrong" articles. Very often they try to present some little tidbit of knowledge as a revelation and mislead the reader in the process.
In this case, the tidbit is: "grapheme clusters exist and they are useful".
The misleading part is that the article draws a false equivalence between what the author calls "UTF-32 code units" and UTF-16 code units.
UTF-32 code units are Unicode code points. This is a general Unicode concept that exists in all Unicode encodings. UTF-16 code units, on the other hand, are an implementation detail of UTF-16. It is wrong to present them as equally arbitrary concepts.
Re: It’s not wrong that "🤦🏼♂️".length == 7 (2019)
#35Is there a situation where I am going to try to get the length of an emoji and I care about the outcome?
Re: It’s not wrong that "🤦🏼♂️".length == 7 (2019)
#36Python 3's approach is the most correct: Unicode defines text as a sequence of code points. UTF-whatever is an implementation detail.
> Unicode defines text as a sequence of code points.
Does it? Do you have a link?
[edit] I looked up the spec and here is what it says.
> The Unicode Standard does not define what is and is not a text element in different processes; instead, it defines elements called encoded characters. An encoded character is represented by a number from 0 to 10FFFF_16, called a code point. A text element, in turn, is represented by a sequence of one or more encoded characters. [1]
The definition of 'text' in the context of Unicode seems to explicitly not be defined as a sequence of code points, but rather a more nebulous sequence of aggregations of code points. It's probably closest to a grapheme cluster but they seem to want to avoid pinning it down.
[1] https://www.unicode.org/versions/Unicode15.0.0/UnicodeStanda... p. 7 (1.3 - Text Handling), PDF page 33.
Re: It’s not wrong that "🤦🏼♂️".length == 7 (2019)
#37HN discards emojis in the title. The original emoji was https://emojipedia.org/man-facepalming-medium-light-skin-ton... which consists of 5 Unicode code points. Also please make sure to read the first heading after the title, which summarizes the whole point of this essay.
Ok, we've remojied the title above.
Edit: there are always exceptions - https://news.ycombinator.com/item?id=34460417
Re: It’s not wrong that "🤦🏼♂️".length == 7 (2019)
#38> Python 3’s approach is unambiguously the worst one, though. Did I miss the part where he explains this take? It's made up of 5 valid unicode code units. For a language where you're not supposed to need to know the byte size semantics, the correct length should be 5. What am I missing? The close second being 17, because length in bytes. Is another fine way to represent this data, e.g. what a successful write of some…
It is wrong that "{emoji}".length == 7 -- but it's wrong because there's no such thing as the 'length' of a string out of context. A string should be viewed as an opaque data type with views into it depending on what you're trying to do. You can have its length in the context of storage/retrieval/transmission (UTF-8 byte count), its length in the context of parsing (code points), its length in the context of editing…
I agree, "length" is an ambiguous function name. It should probably not exist and instead you have functions with units in the name: .sizeBytes, .widthCharacters, .widthResAdjPixels, and so on. Back when the world was ASCII you could get away with just .length because the numbers would always be the same, but with Unicode and all of the other complications of the modern world it isn't sufficient.
Re: It’s not wrong that "🤦🏼♂️".length == 7 (2019)
#39Earlier quoted context omitted.
Why is it the worst way though?
Perhaps the part about it needing lookups of the unicode database and being dependent on the version of the database used?
That's not true though. It just counts the number of code units, that's not version dependent. It's certainly no worse than counting the number of UTF-16 points (I'd argue it's better since it's less arbitrary - whether something is a unicode scalar is a design decision, whether something is in the BMP or not is mostly an accident of implementation).
Re: It’s not wrong that "🤦🏼♂️".length == 7 (2019)
#40Once again, strings are not simple sequences of characters . It's also useless to "index" into a string without specifying what you're indexing for the same reason.
This is like when you first dive into date-time and slowly unravel the maddening complexity of it all.