UTF-32 allows for constant time character accesses, which means that mystr[i] isn't O(n). Most other languages can only provide constant time access for code units.

UTF-32 allows for constant time access to code points. Neither UTF-8 nor UTF-16 can do the same (there are 2 to the power of 20 valid code points, though not all are in use).

While most characters might be encodable as a single code point, Python does not normalize strings, so there is no guarantee that even relatively normal characters are actually stored as single code points.

Try this in Python:

  s = "a\u0308"
  print(s)
  print(s[0])

You will see:

  ä
  a

Would it work to run a bundler over your code, so all (static) imports are inlined and tree shaken?

Since align is only deprecated and not removed, and Markdown is a superset of HTML (at least for CommonMark and GFM), it would be valid markdown to just use <div align=center> to center text (not like there's such a thing as invalid Markdown)

Scratch supports Korean, but Scratch benefits from using JSON instead of bytes or code points to serialize programs, which allows the user to change their display language (similar to how hard tabs let users set indentation size).

There's probably a lot of reasons why non English programmers stick with English keywords, beyond just language/tooling support. Learning new keywords is already part of learning a programming language, and much of the documentation and resources available for languages and libraries are only in English. ASCII-only strings are still ubiquitous in software, like URLs and usernames. And in international teams, English is the go-to lingua franca.

Could this change with LLMs? Maybe, but most code in its training data is in English, so LLMs likely work most effectively in English.

This might be operating system/browser-specific. On Windows Chrome, shift-click opens in new window, ctrl in new tab, and alt downloads the link.

I disagree: this is not unlike including the schema in the JSON itself. This should be handled by the apps themselves, since they would have to know what the keys mean regardless.

If you do want the interchange format to be the one deserializing into specific runtime data structures, use YAML. YAML's tag syntax allows you to run arbitrary code inside YAML, which can be used for what you want.

I'm not talking about something arbitrarily extensible or compound values like vectors or lat/lon. Just a few more common data types -- primitive-like values that frequently need to be passed around.

This would probably best exist as a well-known wrapper around JSON itself.

there are a zillion of these "json pro" kind of things: superjson, devalue, capnweb, all with slightly different ideas about how to lower high-level semantics to json's available types. it's so easy to do this kind of thing, its a real https://xkcd.com/927/ situation.

CBOR (Concise Binary Object Representation) has JSON-like semantics with type extension support; with built in type extensions its much easier to get some agreement about registering certain magic type IDs to mean certain things. for example from a random google search for "cbor datetime" https://j-richter.github.io/CBOR/date.html; there's an IANA registry of type IDs: https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml

however, it is binary.

Amazon ION is kind of this?

Few people seem to use it outside of Amazon tho

I think that it's nice it's explicit that the method returns the current instant, rather than some other zero value.

There's also other methods that return other types, like

    const now = Temporal.Now.instant()

which isn't as bad.

One could argue that the ugliness of the API intentionally reveals the ugliness of datetime. It forces you to really think about what you mean when you want "the current date time," which I think is one of the goals of the API.

What would have been wrong with Temporal.now() returning a sensible value?

What counts as a sensible value? The whole point of the library is to be explicitly about what kind of date/time data you're working with, because different kinds of data have to be handled in very different ways.

If they at least had a Temporal.nowlocal() and a Temporal.nowUTC() that returned a ZonedDateTime set to the local and UTC timezones respectively, that would be 95% of what developers need in practice.

I'm skeptical of this both because this post was largely speculation, and because I would argue Meta has no need to record every private moment for training data.

After all, as the owner of massive social networks, they already have plenty of cleaner, public data that has way more associated labels, like captions, comments, viewer engagement data, and that way they would avoid another data scandal. It's like how people think the Facebook app is secretly recording their microphone, even though their behavior is already obvious through just their and their friends' app engagement. The point of the glasses is to share your footage online, so the recordings would end up public anyways without Meta needing to do anything sneaky.

Probably browser extensions operating on React apps

To be fair, there's little stopping you from putting the button action in its onclick attribute.

I guess the stylistic choice of separating content, style, and interactivity eventually became a convention to keep JavaScript isolated from HTML, but nowadays with Tailwind and HTMX, it does seem like at least some developers want everything in HTML, for the strengths you mentioned.