"Section 1. All persons born or naturalized in the United States, and subject to the jurisdiction thereof, are citizens of the United States and of the State wherein they reside."

Note the "and subject to the jurisdiction thereof". Trump's argument is that people born in America to tourist parents here for a few weeks (for example) aren't subject to the jurisdiction of America. It's a valid argument to make, even if you come down on a different side. Even the author of the 14th amendment said that was the point of that clause. Even in logical terms it makes sense: You can't just let anyone in to give birth and then collect benefits; it's unsustainable.

However, this case wasn't about citizenship. It was about the broader issue of lower courts issuing restraining orders outside their jurisdictions. It's a recipe for chaos. There's a reason why there are multiple jurisdictions, and courts are limited to their jurisdictions. What happens when two lower courts issue conflicting nationwide orders? The only court in the US that has jurisdiction over the entire country is the Supreme Court. This was a losing battle.

There's a right way and a wrong way to go about addressing problems. Court cases are sometimes more about the core issues involved than the concrete circumstances. Sure, birthright citizenship was the reason for the suit, but the core issue was judicial overreach. Don't get mad because the way your side was "winning" was by cheating, and they were stopped. Try having an actual good argument, and doing things the right way by arguing the actual case in a court.

>Good support for Ukraine

You're looking through a particular narrow lens.

Oof. Yes.

Yes? You don't?

Perhaps this is just my ignorance talking, but it can't be that many permutations, can it? Somebody linked to https://en.wikipedia.org/wiki/Zalgo_text, which I doubt anyone would seriously want to enable. There's, what, maybe 3-4 marks typically added to chars in the most complex of cases, mostly for vowels, like Vietnamese. With 4 billion code points to work with, that seems doable. We could just throw in all permutations, regardless of past utility, to accommodate future expansions of acceptable marks. Chinese has, what, 10K chars? It doesn't seem like a big deal for Latin-based chars to have a similar set size when accounting for all mark variations.

>but means all of your documents require substantially more storage than they used to.

Good point! But that comes down to a trade-off analysis between design and space. High 32-bit code point values are meant to be used too, and not shied away from.

I'm not sure why you focused on this one example, which was just meant to indicate the nature of the issue, not cite a broad concrete problem. There are plenty of situations where you'd want to operate on graphemes, not code points, like deleting the previous grapheme in a text editor. It would certainly help programmers write correct code if the two were the same.

>doing away with combining marks and encoding everything as precomposed would be impossible because you cannot have a definitive list of every single combination of letters and diacritics that may mean something to someone

It seems to me it would be trivial to enumerate these combinations, and assign code points to them. For example, the Germanic umlaut is only used with vowels, so that's at most 5 code points.

Reversing a string merely indicates the problem. There are many cases for operating on graphemes instead of code points. For example, deleting the previous grapheme in a text editor when pressing backspace/delete. I think most programmers assume they're dealing with graphemes when they're actually dealing with code points. See, for example, the rune type in Go.

Was Unicode designed well? If it were designed from scratch today, with no legacy considerations, would the ideal design look like the current design? What would you change?

Being extremely ignorant of the problem space, the first thing I would consider for the chopping block would be combining characters. Just make every character a precomposed character (one code point), so there's no need for normalization. I'm curious if such a scheme could fit every code point into 32 bits, though. Would this be feasible?

Comments URL: https://news.ycombinator.com/item?id=32776035

Points: 3

# Comments: 14