mrlongroots
This is not me being snarky, but all meaningful questions can be settled empirically---e.g., "what happens to my body if I jump off the cliff". But empirical trials have a cost (time, money, irreversibility etc.) and we model and predict because it's cheaper than the trial.
> Bottom line, Tao is pushing for human understanding as the primary goal
100%. This applies to SWEs/math folks/etc. I do infra and I see many SWEs take their hands off the wheel. When they encounter perf issues they ask their agent and agent says GC and they say GC. It's rarely GC.
Now we might be well past the point where we need to remember the kubectl flags for rollouts etc. But basic human understanding of what their bots are doing as a goal has never changed. Humans are still liable for when bad things happen, and that hasn't changed over the roller coaster the last 5-odd years have been. LLMs, as astonishing they are at Navier Stokes, are still eminently capable of nuking your filesystem and saying "I can now see that that was wrong" with zero regrets. If you can't understand you can't sign off.
> math is the most pure expression of human understanding
This I don't know about. I think math acquires meaning when it contacts reality: like an iota is pointless until there's some circuit that it explains. Abstract math can diverge from that and can become an exercise in playing with symbols for their own sake.
I'm in an infra team and for the last 2 weeks or so I've been trying to understand whether a particular workload will catch fire if a switch is flicked. I'm also new to the team so partly it is me wearing training wheels, familiarizing myself with the telemetry etc, but I will state that I'm not completely lousy at this stuff.
No model in my experience can do anything remotely comparable to the work "what happens to the workload if this switch is flicked" needs. They can't even design a reliable quick experiment to answer what cast should be applied to the binary trace_id in table A for the join to table B to work. They will happily do something idiotic and then conclude that the join does not work.
You do not even need to change the Iceberg spec, although you could. Just rejig things a bit to produce better statistics (think liquid clustering but on the write path). You still write the same dataset queried the same way, but automatically get better query performance. Workload owners should be able to decide the tier at which this streaming reorganization happens: they know their data staging and bandwidth constraints the best.
DoE compute budgets are ~10B USD across labs. AI training is a trillion-dollar workload. Different league.
Plus one think I like to say is that if a bullet is flying towards you, you could know everything about the chemistry of the gunpowder and the composition of the alloy without it affecting what happens next.
Regardless, to bring the discussion back to the claim at hand: at all points in future, we will need the ability to reason under partial information. "Absolutely flawlessly complete diagnostics" is an asymptotic goal we get closer to but never reach. This is both very doable for a disciplined human, and very hard to outsource completely to an LLM. Treated as tools operatored by competent users, they are magical. But they can not outperform their user.
Ok let us unpack this statement.
For your point to hold, I would have to be saying "all kinds of practical diagnostics are invented now. No progress can be made in better diagnostics".
If Alzheimer's can be validated by slicing open a dead patient, there is a causal mechanical explanation for the disease. If we can not confirm that defect without slicing open the patient, that is a limitation of 2026 tools. The "One True Diagnosis" is an Oracle explanation that all real diagnostic techniques try to approach in the asymptotic sense, and it is helpful exactly because it clarifies in discussions like this.
There are going to be diseases where we do not yet have causal explanations. Or where we treat them without establishing them. Hypertension is one example: while technically it can be caused by vascular stiffness, some weirdness with the RAAS system, some hyperadrenergic weirdness, practically you get a lot of mileage out of just prescribing people telmisartan if they're old.
That does not mean the frontier of hypertension is settled, or the 10% who do not have a vascular stiffness problem would not benefit from better causal models of hypertension. Science is us continuously pushing back against the fog: of the tools we have in 2026, some are great, some are imperfect, some are promising etc.
> This is a kind of thinking a lot of programmers fall prey to. The real world, outside of code, is a very fuzzy and inherently analog place.
Having said that, I would vehemently reject and push back against this, and without doubting your sincerity, characterize it as an ad hominem.
The vast majority of issues with the human body are mechanical in nature. Restricted blood flow, unwanted tissue, a broken bone, a bad valve etc. These are causal descriptions of "disease". Where causal descriptions exist, the "One True Diagnosis" principle holds. Psychiatry just happens to be unique in that it is a fuzzy science where we rely on checklists and ultimately all diagnosis is probabilistic.
EDIT:
> This is a kind of thinking a lot of programmers fall prey to. The real world, outside of code, is a very fuzzy and inherently analog place. There is very rarely one in any complex system having a complex problem needing a complex solution. At some point even the definition of diagnosis gets fuzzy.
I would also push back against this mindset in general. This is not a falsifiable claim, it is incoherence as an argument, and I do not need to be a programmer to hold this position.
That the real world is analog is irrelevant to its amenability to causal explanations. Or "fuzzy": "fuzzy" in this context just does not mean anything.
I am not trying to sound exasperated or win internet points, just impress this point on you and anyone reading this. We can write math to predict weather, make it tractable to solve using approximations, tolerate IEEE 754 weirdness, and finally tell what the clouds will do a week from now. This is nature telling us that there is a pattern to how it behaves, and it is the only weapon we have as scientists.
To say that nature is not amenable to explanations is a very defeatist thing to say: neither Newton nor Einstein nor any of the million-odd people that have built modern society would exist if nature did not have causal explanations. I urge you to reject this defeatist thinking.
"The Diagnosis" does not mean "one root cause".
Situation: my car has some unexplained vibrations. 1. Mechanic A says that it is the engine mounts 2. Mechanic B says that it is some weirdness in how the exhaust assembly is hanging to the underbody 3. Mechanic C says that it is just my wife farting
I replace engine mounts and 40% of the problem is reduced. I then drive without my wife and the remaining 60% is solved.
"The Diagnosis" was: 40% mounts, 60% wife, 0% exhaust.
There is always one "The Diagnosis".
Absolutely. The guarantee does not come from the LLM. The LLM is a simply an improved version of Google Search.
The guarantee can only come from a systemic application of epistemic discipline and reasoning, which is very much (smart) human territory.
Put it another way, I could make good decisions with/without LLMs, with some uncertain diagnostics as input. I would have to trawl through 50 papers myself, and it is possible that my decision arrives 5 years too late as a result. LLMs enable trawling and do some of the legwork in connecting the dots, but are ultimately only as capable as the orchestrating human.
There is absolutely one "The Diagnosis". Human body is a machine, albeit a very complex one, and all measurement sources have noise. But they are all measuring one reality, and if there is a problem, there should be one explanation that all measurements align with. They can be noisy but can never be conflicting (instrument error notwithstanding).
Physicians' ability to arrive at "The Diagnosis" would vary, but it does not mean one does not exist. I am not sure if characterizing human body as derministic or not is relevant here.
Everything is a puzzle: there is one "Truth" or one diagnosis. You (a smart human) should be able to converge on it by cross-examining your LLMs. By themselves, they have no interest in revealing this, no stakes, which makes them tools only useful at the hands of a capable investigator.
I think there's some misinterpretation here. Not staying on in academia after PhD (common/modal) is not the same as not getting to complete a PhD (rare).
In CS/tech, those who exit academia after PhDs get paid $300K-$500K in the industry. I don't think there's any misleading going on.
I feel like PhD stipends are not a major problem. Like I got $40K in a low CoL area, but accounting for tuition and overheads I cost my advisor closer to $150K/year.
Now why are tuition and overheads that high is a reasonable question and it ties into inefficiencies in broader American administrative processes, but I cost society and taxpayers $150K/year, and that I'm doing it for societal benefit is honestly only partly true. The first 6 years was just me building real skills and letting myself be frustrated, and maybe in the last 1.5 years I did things that justify the $1M bill and more.
Even if I did eventually do things that justified the $1M bill, I think most students don't. The larger value IMO lies in a workforce trained in the failures and frustrations of grad school. While I could rattle of plenty of limitations of academia/grad school, I'm not entirely convinced that me being shortchanged/underpaid was one of those things.
One reason is that most clouds/neoclouds don't own workloads, and want fungibility. Given that you're spending a lot on H200s and what not it's good to also spend on the networking to make sure you can sell them to all kinds of customers. The Grok LPU in Vera Rubin is an inference-specific accelerator, and Cerebras is also inference-optimized so specialization is starting to happen.
To your point, I wonder if the 73 distinct transforms were just different defaults/usability wrappers over these. And you may also get into situations where kernels can be fused together or other batching constraints enable optimizations that nice algebraic primitives don't capture. But that's just systems---theory is useful in helping rethink API bloats and keeping us all honest.
But Codex/5.2 was substantially more effective than Claude at debugging complex C++ bugs until around Fall, when I was writing a lot more code.
I find Gemini 3 useless. It has regressed on hallucinations from Gemini 2.5, to the point where its output is no better than a random token stream despite all its benchmark outperformance. I would use Gemini 2.5 to help write papers and all, can't see to use Gemini 3 for anything. Gemini CLI also is very non-compliant and crazy.
And the reason is ABI compatibility. Reasoning about ABI compatibility across different C++ versions and optimization levels and architectures can be a nightmare, let alone different programming languages.
The reason it works at all for Arrow is that the leaf levels of the data model are large contiguous columnar arrays, so reconstructing the higher layers still gets you a lot of value. The other domains where it works are tensors/DLPack and scientific arrays (Zarr etc). For arbitrary struct layouts across languages/architectures/versions, serdes is way more reliable than a universal ABI.
(I do HPC, IIRC ANL Aurora is < 1PB/s DAOS and 20 PB/s bisection).
I think your point is a good one in that it is more economics than systems physics. We size clusters to have more compute/network than storage because it is the design point that maximizes overall utility.
I think it also raises an interesting question in that let's say we get to a point where the disparity really no longer holds: that would justify a complete rethinking of many Spark-like applications that are designed to exploit this asymmetry.
You want to use Spark for a large dataset with multiple stages. In this case, their I/O bandwidth is 1GB/s from S3. CPU memory bandwidth is 100-200GB/s for a multi-stage job. Spark is a way to pool memory for a large dataset with multiple stages, and use cluster-internal network bandwidth to do shuffling instead of storage.
Maybe when you have S3 as your backend, the storage bandwidth bottleneck doesn't show up in perf, but it sure does show up in the bill. A crude rule of thumb: network bandwidth is 20X storage, main memory bandwidth is 20X network bandwidth, accelerator/GPU memory is 10X CPU. It's great that single-node DuckDB/Polars are that good, but this is like racing a taxiing aircraft against motorbikes.
Unfortunately American retail prices might as well be generated by a PRNG, and do not mean much.
On Ulta, a basic lipid panel vs an ApoB test are $22 and $36 respectively. Looking at Indian lab prices, (approx. INR->USD), both are under $10 there.
https://www.ultalabtests.com/test/cholesterol-and-lipids-tes... https://www.ultalabtests.com/test/cardio-iq-apolipoprotein-b...
My advice would be to "shop around" for doctors, establish a relationship where you demonstrate openness to what they say, try not to step on their toes unnecessarily, but also provide your own data and arguments. Some of the most "life-changing" interventions in terms of my own healthcare have been due to my own initiative and stubbornness, but I have doctors who humor me and respect my inputs. Credentials/vibes help here I think: in my case "the PhD student from the brand name school across the street who shows up with plots and regressions" is probably a soft signal that indicates that I mean business.
My only complaint is the verbosity, things like `std::chrono::nanonseconds` break even simple statements into multiple lines, and you're tempted to just use uint64_t instead. And `std::thread` is fine but if you want to name your thread you still need to get the underlying handle and call `pthread_setname_np`. It's hard work pulling off everything C++ tries to pull off.