Occasionally in pure python "asymptotically reasonable, simple implementation, terrible memory locality" is the right pick for a data structure. You want to avoid an extra linear term, you don't care too much about the constant factor, and the cache doesn't really matter because the language is so slow that it's not really noticeable.
I guess to expand on my earlier post, it's generally a good thing that these kinds of absurd allegations are counterproductive and generally not convincing, because if they were more readily believable they would be quite irresponsible. Real violence has occurred because of beliefs (and posts) like this.
This hyperbole does more to turn people away from Bluesky and other sites more than X to be honest. There are clearly lots of politically moderate, wholesome "politically inert," and international X users. The people who are vocal about having left seem more extreme and less tolerant to me.
Perhaps for related reasons, I've also recently heard Elon Musk being described as a "literal Nazi" a lot, and I'm sure that kind of wild rhetoric has a similar backfire effect with anyone who has any familiarity with him.
Yeah I guess a c++ programmer might say `std::array::operator[]` is a function (or method, whatever), just like `std::array::size` is. And that identifying the array with just one of those functions (or even the collection of all methods offered) is to miss the point -- not just contiguous indices, but contiguous storage. A red-black tree with added constraints is not an array.
TFA does allude to this. An "array indexing function" that just met the API could be implemented as an if-else chain, and would not be satisfactory.
I wonder if "the right solution" is a programming language that is fast, concise, trivially easy to run, and outputs some efficient binary format like protobuf.
Programming languages have comments and control flow, multiple popular implementations, and can have nice literals. Lack of Turing completeness is actually not a terribly useful feature if you trust the input (and you should probably just use protobufs or similar for untrusted inputs in that case.)
"Easier" is probably the right one-word generalization, but worth noting that there are quite different challenges. Stopping distance is substantially greater, so "dead halt" isn't as much of a panacea as it is in dense city environments. And you need to have good perception of things further away, especially in front of you, which affects the sensors you use.
There's an Amdahl-like effect, where "100x slower" means that anything nontrivial in pure python ends up being fat in your flamegraphs, even if your "heavy lifting" core algorithmic stuff uses some nice fast libraries.
Many simple scripts at my work that more or less just argparse and fire off an HTTP request spend half a minute importing random stuff because of false deps and uncommon codepaths. For some unit tests it's 45 seconds, substantially longer than the time taken to run the test logic.
For cloud jobs that can be true, but for single threaded dev-in-the-loop work you can't just buy a 100x faster processor than the one on their dev machine, and the latency is expensive workflow friction.
This might have been your experience, but mine has been very different. In my experience a typical python workload is 50% importing python libraries, 45% slow python wrapper logic and 5% fast native code. I spend a lot of time rewriting the python logic in C++, which makes it 100x faster, so the resulting performance approaches "10% fast native logic, 90% useless python imports".
Yeah, I think the "paradox" is usually a problem for pundits and academics and not practitioners. Lots of people have experience finding and correcting market inefficiencies, usually getting paid for it.
> hardly beyond standard practice in the industry. The SLS is
Perhaps explaining GP's surprise: I've heard SpaceX's testing philosophy contrasted against this sort of thing. That none of their tests are "too big to fail". On the other hand, according to this narrative they also stress iteration speed over success rate, and ramping up fast works to that end too.
Maybe they were getting diminishing returns (in terms of lessons learnt) in small scale tests though. No doubt there are phenomena you only see in larger tests, and (as you say) their confidence in getting the smaller stuff right might be quite high.
Not too common, but it happens.