The benchmarks at the bottom mention memory tiering and manually controlling where things go, but if your application already does that, then you probably don’t also need a CUDA shim. The application should control the VRAM to system memory transfers with boring normal code.

This was from two decades ago, and cursory searching suggests the average lifetime of an unpatched system is even lower now.

https://www.cnet.com/news/privacy/study-unpatched-pcs-compro...

1. CLAUDE.md is not part of the system prompt

2. The Claude Code system prompt almost certainly gives directions about how to deal with MCP tools, and may also include the list of tools

3. Instruction adherence is higher when the instructions are placed in the system prompt

If you put these three facts together then it’s quite likely that Claude Code usage of a particular tool (in the generic sense) is higher as an MCP server than as a CLI command.

But why let this be a limitation? Make an MCP server that calls your bash commands. Claude Code will happily vibe code this for you, if you don’t switch to a coding tool that gives better direct control of your system prompt.

Now that you bring it up, the M3 ultra Mac Studio goes up to 512GB for about a $10k config with around 850 GB/s bandwidth, for those who "need" a near frontier large model. I think 4x the RAM is not quite worth more than doubling the price, especially if MoE support gets better, but it's interesting that you can get a Deepseek R1 quant running on prosumer hardware.

For inference decode the bandwidth is the main limitation so if running LLMs is your use case you should probably get a Mac instead.

But you can simplify this problem down and ask: with no loss of generality, if your starting point is always 0 degrees, how many degrees clockwise is a random point on average, if the target is uniformly distributed?

Since 0-180 has the same arc length as 180-360 then the average distance is 180 degrees. So average half-platter seek is half of the full-platter seek.

I would embrace copying and pasting for functionality that I want to be identical in two places right now, but I’m not sure ought to be identical in the future.

The fact that you can write this sentence, consider it to be true, and yet still hold in your head the idea that the future might be bad but it's still important to have children suggests that "contact with reality" is not a curse.

The improved prompt or project documentation guides every future line of code written, whether by a human or an AI. It pays dividends for any long term project.

> Like there is a reason we are not using fuzzy human language in math/coding

Math proofs are mostly in English.

Let's be practical about it: the reason you might want to say map_tree is so it could potentially be optimized to run more quickly, e.g. via automatic parallelization.

But to even parallelize a tree read operation we'd have to pull in other threads, split work, we'd want metadata on each node (child counts), and at the end of the day within each worker you'd still have a serial execution order.

For map_tree to have practical benefit your language would need to make a ton of opinionated choices about trees and parallel programming. Feasible? Yes. Worth making it a basic primitive? Well, even LISPs don't offer map_tree, despite building the whole language on top of car/cdr.

For example if you literally don’t care about the order then your code can map over a default iterator that is efficient (DFS).