Aspects of language design that are way more important are: the semantics, including type system, memory model, concurrency model, module system and so on; tooling; performance; FFI and OS interface; and lots of other things.

The reason these things matter more than surface-level syntax stuff is that they change what kinds of problems you can solve with the language, and what tradeoffs you’ll accept if you use it.

Of course, hyperpalatable syntax can be a factor in a language’s success, like Python. But at this point it’s Python’s ecosystem that perpetuates its dominance, and if they made some syntax changes it wouldn’t change that by much.

But, in this world, the website owner would receive tokens that they can then use to do whatever they want, including paying for servers and bandwidth. This is the sense in which the cycles aren’t wasted: the website owner now has cash to spend.

Effectively, both scrapers and ordinary users would be paying for the privilege of getting website bytes.

This also solves the problem of having to wait for your phone to solve the challenge while you’re browsing: you can buy or mine some tokens ahead of time and pay them as soon as challenged. So can the scrapers, but because they’re accessing enormous numbers of pages it’s hopefully prohibitively expensive for them.

This story turned out to be false but I think smart, reasonable people a couple years ago could have believed it with conviction. It doesn’t really seem like “completely asleep” to me.

A CPU is mostly transistors, so SRAM is made of the same “stuff” as the CPU logic itself.

This makes it easy to put SRAM on the same chip as a CPU, but difficult to put dense amounts of DRAM on that same chip. You could etch CPU and DRAM with the same process but both would suffer in density and therefore speed, cost and power efficiency. That’s the fundamental reason why DRAM and CPU/GPU are on different chips with a fast interconnect between them. This is so even in devices like the iPhone where one designer controls and designs the whole thing and could, in theory, fab a single design with both. But they don’t.

(There are some old exceptions to this like the PS2 shipping with a small amount of on-die DRAM. And process incompatibility is not the only reason for keeping the two chips separate. But if the processes weren’t incompatible there would certainly be high-end fast CPUs/GPUs with big gobs of DRAM.)

My understanding of US law is that there’s nothing in logic or precedent that makes such a contract unenforceable.

As for whether it’s “stealing”: they might be able to press charges under federal Trade Secret Theft laws, I’m not sure. But I’m not seeing how you can be so very very certain that it’s at best a civil violation of contract. What’s the reason for your confidence that a judge would never find this to be trade secret theft or economic espionage?

Sure you can set spending limits, just like you can make an account and give it a limited amount of credits.

I’m not sure this argument is correct. You can sign whatever contract you like with the model provider, right? Including “you are entitled to the end product but not the intermediate scratch work”?

Coming from a place of genuine curiosity: is there some precedent or statute that would invalidate that contract? I don’t see why the reasoning tokens belong to you.

For example, I pay lawyers by the hour but don’t necessarily own their meeting minutes, recorded discussions, research notes, etc.

This thread and this entire topic isn’t about stealing physical goods or money. We can all agree that if I break into your house and take your TV then that’s the ancient, obvious crime of stealing.

Grice’s maxims and common sense indicate that we’re talking about the word “stealing” as applied to infringement or unauthorized copying.

Where that number comes from: they claim 50% reduction in fuel consumption, which sounds doubtful to me, and fuel is about a third of flight costs, and I’m making some generous assumptions around perfect competition.

https://github.com/kshitijl/tinyrenderer-rs

if anyone is interested! The repo has lots and lots of in-progress screenshots so you can see the renderer come to life, plus all the hilarious visual bugs along the way.

I learned a lot! My biggest lesson, other than the specifics of how rendering works, was that modern CPUs are really fast: a single-threaded CPU renderer can definitely run an interactive 3D game with some fancy special effects.

You're implementing quicksort. The actual algorithm is a conceptual piece of math. You write the code. But sometimes the code produces output that isn't sorted.

The code "wins" in that whatever the code says is what actually happens. But the code is wrong. It must be edited to match the algorithm. The _algorithm_ is the thing that is proven correct; the _algorithm_ is what we wanted to execute. The code is a representation of the algorithm.