The problem with trees is that the are a dimensional reduction, an aggregation; taking a problem without directionality and applying a useful/functional hierarchy.
So a tree is a way to take a high dimensionality graph and make it usefully lower dimensionality, but, given the aforementioned proof, that reduction is going to go from being a lossless compression to a heuristic. So any interesting problem (at least, any problem interesting to me) is only going to be aided (read: not solved exhaustively) by that hierarchy.
I'm okay with this. Being okay with this has been one of the most freeing things over the last 20 years of my career. Accept inaccuracy, and find usefulness in your data structures.
I woke up around 4am, read this, and wondered if I was still in a dream state given the meandering nature of it.
Were the man page musings written in response to the (alleged, but... uh... NSA) kleptographic backdoor in Dual_EC_DRBG? It requires multiple successive outputs to compromise and derive internal PRNG state, if memory serves.
In that one construction, /dev/random blocking on seeding would have a mild state-hiding advantage over /dev/urandom, I imagine... but, sheesh. Nobody use that generator.
Could have just been intercontinental ballistic human transport... I can't tell you how many times I've wished to just be fired out of a cannon to Hong Kong from SF.
He's even clearer about it in the last episode of season 1, where he assembles all the inventions from the season and shows how they make the US nuclear triad.
Not that I'd trust a self-driving car anyway, but if I were in his situation I would absolutely take the free ride there and back to get my stuff. It would be even more "massively wasting someone's time" to wait for them to do something else otherwise, which would entail a lot more risk.
100% agree, but, if that's the fix for the bug, I'd probably take an Uber next time. (I say this as someone with hundreds of Waymo rides)
Customer trust is a lot easier to lose than it is to gain. Moments of frustration are the perfect time to step up and prove to the customer that they can trust you to make things right.
That’s funny, I’ve actually used the same algorithm but with taxis in general, for having the same exact issue as the person in this article… but with a real driver.
(All of this assuming it’s safe to keep a door open!)
Having had Claude Code jump to inserting juvenile and all-filtering regex to (attempt to) solve open-ended semantic natural language problems (-sigh- there's 12 hours of my life I'll never get back), I can absolutely imagine that this was someone trying to code up a "defense in depth" mechanic that was explosively insufficient after Claude Code (even Opus 4.6) made a series of faulty assumptions.
This one feels like prime space for Hanlon's razor: "Never attribute to malice that which is adequately explained by stupidity."
The hassle with the performance of these systems is that they're ~70% of the way to awesome. For advanced prototyping (my current job description), a fast 60% of awesome is groundbreaking and game-changing. For production and real businesses, that last 30% is a really, really important thing to figure out.
I was under the impression that insider influence was the point of these systems? Want something to happen? Bet a lot of money that it won't, pulling the market forces towards the action you want.
It goes from "taking out a hit" to "betting that someone will live to next Thursday". It's such an obvious outcome of these systems that I was operating on the assumption that it was the actual point.
So maybe the thing this guy did wrong was to be so face-palmingly pants-on-head obvious about it that they had to shut it down?
Which is also horrifying if you think about it for more than a second.
"Want something to happen? Bet a lot of money that it won't" goes both ways. "Want to make money and have power over missile systems? Bet, and then make something happen."
“Super markets trade money for food. An obvious outcome is that someone without money will shoot the employees to steal food. Therefore the purpose of supermarkets is to facilitate murder”
Less so "supermarkets" specifically and moreso "capitalism" and the answers to your conclusion is obviously, yes.
This is why welfare systems exist. Because otherwise the system will push people to crime, especially so in our current implementation of Capitalism where it is possible to become unemployed/unemployable through no fault of one's own.
I think this is, more often, that we are spending too much time pretending to communicate. Far too often I've found myself in a meeting that doesn't have a quorum, but people try to have the meeting anyway. Even more often than that, I've found myself in a meeting that doesn't have the sufficient pre-requisites to be useful. It will just be some AI slop document dropped in front of folks, with little to no regard for coherent thought or responsibility. It's 30 minutes of gaslighting the readers, trying to make them feel stupid for "not getting it", followed by 10 minutes of "this meeting was a waste of time" course-correction (we read our docs in the beginning of meetings).
And the problem is that the communication (or alignment) is the thing that the meeting is supposed to be about, sharing well-considered thoughts and cohesive direction, soliciting meaningful feedback against clearly-articulated assertions. Instead, we're all-to-often addressing someone's attempt to turn their job into a group project, the stone soup of the modern business world. You can lay this bare by asking "what is the aim of this meeting?" early on, to level-set that the meeting owner isn't just setting up a study group.
Birds-eye-view-only managers only see work get done in meetings, so they assume that the meeting is where the work gets done. They don't understand all of the work that went into what came before the meeting to make it a successful one. If you rush the "communication" before you've found the clarity of thought, your meeting is just noise.
There's a simple but powerful response to this sort of persistent malaise, one that strikes fear in the hearts of the secretly inept: "I don't know, but let's figure it out right now."
When it's time to slow down and walk through the problem, I hold folks to an ordering of dependency: Why, What, How, Who, When... If you don't know all of the things before (e.g., Why, What, How - if you're trying to figure out Who), you cannot proceed. I don't care if you're an intern or a VP. No short-cuts to bullshit hand-wavy answers.
Decompose the problem, do the thinking, reason through it right there, and, if the team doesn't change its behavior, find another team. In the right environment, some folks are willing and able to step up to the plate and act like grown-ups working together to craft something better. Sadly, quite a few can't (or won't) answer the call to be responsible adults.
And that's a problem because Aggregability is NP-Hard: https://dl.acm.org/doi/abs/10.1145/1165555.1165556
So a tree is a way to take a high dimensionality graph and make it usefully lower dimensionality, but, given the aforementioned proof, that reduction is going to go from being a lossless compression to a heuristic. So any interesting problem (at least, any problem interesting to me) is only going to be aided (read: not solved exhaustively) by that hierarchy.
I'm okay with this. Being okay with this has been one of the most freeing things over the last 20 years of my career. Accept inaccuracy, and find usefulness in your data structures.