Live data from Hacker News

It’s not wrong that "🤦🏼‍♂️".length == 7 (2019)

hsivonen.fi

61–70 of 315 posts

Re: It’s not wrong that "🤦🏼‍♂️".length == 7 (2019)

#61
post #60

Earlier quoted context omitted.

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…

What do you mean there is no such thing as a character when grapheme cluster is exactly that? This is also the out-of-context , and people get confused because instead of this human context attribute they've been forced to use all the other alternatives that require more knowledge

[deleted]

Re: It’s not wrong that "🤦🏼‍♂️".length == 7 (2019)

#63

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

> I'm basing this all on the idea that it's almost always a mistake to confuse how a program manages some data, vs how a drawing lib might. Your language shouldn't concern it self with how many glyphs it needs to draw... until you actually try to draw them.

Well, why not? There are a lot of things that people would want to call string.length for — drawing little equals signs under text in a terminal, for a frivolous example — where that’s the whole reason they’re making the call. Off the top of my head I’m not really sure how you solve that with variable-width characters if there’s no way to separate out or count them.

Re: It’s not wrong that "🤦🏼‍♂️".length == 7 (2019)

#64
post #60

Earlier quoted context omitted.

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…

What do you mean there is no such thing as a character when grapheme cluster is exactly that? This is also the out-of-context , and people get confused because instead of this human context attribute they've been forced to use all the other alternatives that require more knowledge

Characters in context are printable or non-printable/formatting marks right? I agree they probably meant grapheme clusters, but grapheme clusters can vary dramatically in width so the point of the conversation was to explain why a bounding box was a better approximation of their goals.

Re: It’s not wrong that "🤦🏼‍♂️".length == 7 (2019)

#65
post #25

this one one of those things that people point to when comparing languages, but in reality rarely matters. with Go, you just get the number of bytes, which the the correct default thing to do: https://godocs.io/builtin#len if the language default was anything other than this, THAT WOULD BE WRONG and unexpected. I would prefer the default to be the dumb, fast thing. then if I want the slow, fancy thing, I can import s…

Why would you want dumb???

(and it's not expected that a character's length is>1 unless you've been conditioned to excpect it)

Re: It’s not wrong that "🤦🏼‍♂️".length == 7 (2019)

#67
post #29

Earlier quoted context omitted.

That makes more sense. I'm sure there could be some language out there where a empty strings length could be 7.

Not sure if HN will handle it, but this empty string's length is 7: ' ' ( '\u200b'.repeat(7) ) Edit: HN does not, in fact, handle it.

HN does, in fact, handle it, and chose to discard it.

Re: It’s not wrong that "🤦🏼‍♂️".length == 7 (2019)

#69

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

Counting graphene clusters is a hard problem because it depends on the font that is being used. It only exists at render time in the context of a specific client.

If the user can freely change a font it is impossible to send a string of 3 graphene clusters because you won't know if it actually will show up as 3 to client or a different number.

Re: It’s not wrong that "🤦🏼‍♂️".length == 7 (2019)

#70
post #35

Is there a situation where I am going to try to get the length of an emoji and I care about the outcome?

There's most definitely a situation where you want the length of string that contains an emoji character and perhaps dumb things happen if you get that wrong.
Post reply on HN