The "means" is being able to print trillions of imaginary dollars with value that magically pops into existence, merely backed by the fact that other nations do not want USD to lose value because they invest in it.

US did not care about trade deficits because they were able to just print dollars without having dollar itself devalued, which is what happens if any other nation decides to print currency without having a way to back its value. Because the US status as global hegemony is getting challenged, these trade deficits may become an issue. But trade deficits were not an issue until now (and they still are not as long as they can keep printing dollars without hyperinflation happening).

However you are sort of right that "churn" does not necessarily have to do with it being sigmoid because it will be anyway. It may be bring it earlier if the churn rate surpasses the user growth, but that's probably not important here.

I tried once the apple vision pro and it seemed fine, amblyopia-wise at least. It was too briefly though to know for sure how it would be like using it for longer.

Most developers do not touch array languages but I guess most developpers don't in general (need to) vectorise code this way and avoid loops (because they work in other problem domains, use lower level languages etc). If anything, not all problems can be vectorised anyway (or at least elegantly). But if one writes vectorised code, doing that in an array language makes more sense.

    [[1, 2], [3, 4], [5], [6]] 

    array([[ 6,  7],[ 9, 10]])

Much of the time I spend writing code, not thinking about the general overview etc but about the code I am about to write itself, and if I actually care about the actual code (eg I am not gonna throw it away anyway by the end of the day) it is about how to make it as concise and understandable to others (incl future me) as possible, what cases to care about, what choices to make so that my code remain maintainable after a few days. It may be about refactoring previous code and all the decisions that go with that. LLM generated code, imo, is too bloated; them putting stuff like asserts is always a hit or miss about what they will think is important or not. Their comments tend to be completely trivial, instead of stating the intention of stuff, and though I have put some effort in getting them use a coding style similar to mine, they often fail there too. In such cases, I only use them if the code they write can be isolated enough, eg write a straightforward, auxiliary function here and there that will be called in some places but does not matter as much what happens in there. There are just too many decisions at each step that LLMs are not great at resolving ime.

I depend more on LLMs if I care less about maintenability of the code itself and more about getting it done as fast as possible, or if I am just exploring and do not actually care about the code at all. For example, it can be I am in a rush to get sth done and care about the rest later (granted they can actually do the task, else I am losing time). But when I tried this for my main work, it soon became a mess that would take more time to fix even if they seem like speeding me up initially. Granted, if my field was different and the languages I was using more popular/represented in training data, I may have found more uses for them, but I still think that after some point it becomes unsustainable to leave decisions to them.

In my view, python+numpy is not actually an array language. Numpy as a library adds vectorization operations to python in order to help with speed. This is different. It does not (intend to) bring the advantages that array language syntax has, even if it was a bit more consistent.