Hmm, if the author is doing something high performance, they should probably use whatever mosh is doing to update the screen, not ssh.

That would require end users to install additional software though, which they do not want

Oh, true, ssh is not just the protocol, but also the name of the client software.

Though I would suggest to make mosh available, too. Many nethack servers are available via mosh and ssh. (And in an earlier age, telnet.)

VCs are pretty good at extracting money from Gulf state oil funds (sometimes via Softbank as the intermediary) and subsidising below-cost services for customers like office space sharing or ride hailing.

Of course, the VCs take a cut, but overall the redistribution seems net positive to me.

Well, if sanity had prevailed, we would have likely stuck to .ps.gz (or you favourite compression format), instead of ending up with PDF.

Though we might still want to restrict the subset of PostScript that we allow. The full language might be a bit too general to take from untrusted third parties.

Don't you end up with PDF if you start with PS and restrict it to a subset? And maybe normalize the structure of the file a little. The structure is nice when you want to take the content and draw a bit more on the page. Or when subsetting/combining files.

I suspect PDF was fairly sane in the initial incarnation, and it's the extra garbage that they've added since then that is a source of pain.

I'm not a big fan of this additional change (nor any of the javascript/etc), but I would be fine with people leaving content streams uncompressed and running the whole file through brotli or something.

> Don't you end up with PDF if you start with PS and restrict it to a subset?

PDF is also a binary format.

I thought PDFs can contain arbitrary PS.

Compression filters are in PostScript.

> It was odd to me, because it hadn't really occurred to me before that, given infinite memory (and within a mathematical framework), there's fundamentally not necessarily a difference between a "list" and a "function".

You don't even need infinite memory. If your function is over a limited domain like bool or u8 or an enum, very limited memory is enough.

However the big difference (in most languages) is that functions can take arbitrarily long. Array access either succeeds or fails quickly.

> However the big difference (in most languages) is that functions can take arbitrarily long. Array access either succeeds or fails quickly.

For some definition of quick. Modern CPUs are usually bottlenecked by memory bandwidth and cache size. So a function that recomputes the value can often be quicker than a look up table, at least outside of microbenchmarks (since in microbenchmarks you won't have to compete with the rest of the code base about cache usage).

Of course this depends heavily of how expensive the function is, but it is worth having in mind that memory is not necessarily quicker than computing again. If you need to go to main memory, you have something on the order of a hundred ns that you could be recomputing the value in instead. Which at 2 GHz would translate to 200 clock cycles. What that means in terms of number of instructions depends on the instruction and number of execution units you can saturated in the CPU, if the CPU can predict and prefetch memory, branch prediction, etc. But RAM is really slow. Even with cache you are talking single digit ns to tens of ns (depending on if it is L1, L2 or L3).

> For some definition of quick. Modern CPUs are usually bottlenecked by memory bandwidth and cache size.

I meant in most languages functions aren't guaranteed to return in finite time at all.

I've been watching those Kaze Emanuar videos on his N64 development, and it's always so weird to me when "doing the expensive computation again" is cheaper than "using the precomputed value". I'm not disputing it, he seems to have done a lot of research and testing confirming the results and I have no reason to think he's lying, but it's so utterly counter-intuitive to me.

I haven't looked into N64, but the speed of CPUs has been growing faster than the speed of RAM for decades. I'm not sure when exactly that started, probably some time in the late 80s or early 90s, since that is about when PCs started getting cache memory I believe.

I wonder if a breakpoint was out-of-order execution. Many computations would use some values from memory plus other that could be computed, and out-of-order execution would allow the latter to proceed while waiting on memory for the former. That would improve utilization and be a 'win' even if the recomputation in isolation would be no faster than the memory load.

The N64 was just really weirdly designed: they went with an overpowered CPU for bragging rights, and bet on the wrong RAM horse, Rambus.

Doing maths is extremely fast. You need a lot of maths to get to the same amount of time as a single memory access that is not cached in L1 or L2.

And you need to burn even more cycles before you’ve amortized the cost of using a cache line that could have benefitted some other work.

I used to develop for the N64 and I can confirm that it is true. It is crazy how much faster the CPU is compared with not-in-cache RAM access.

Optimizing for RAM access instead of CPU instruction speed can make your code magnitudes faster.

It's a classic space / time trade-off. The special relativity of programming, if you like.

Why?

Wages were higher in the North American colonies even before their insubordination.

I'm fairly sure statisticians know about history and account for it.

The Empire wasn't profitable.

You seem to be implying that the landed gentry financially benefited from the Empire?

Mammon and the Pursuit of Empire by Lance E. Davis and Robert A. Huttenback.

But like I said, I'm not a historian.

Check out https://en.wikipedia.org/wiki/The_Discovery_of_France to see how much better the Brits had it than the French. Many of the accounts in the book are drawn from British working class _tourists_. Ordinary people in Britain had enough disposable income to visit France.