10,337 karma · joined January 18, 2008
For me personally, in my projects there's not a single line of LLM code. At most I ask LLMs for advice about specific APIs. And the more I think about it, the more I want to stop doing even that.
Wait, what would be the point of using locks then? It seems to me there's no point taking a lock if you're gonna release it without calling any awaits, because nothing can interfere anyway. Or do you mean cases where you have both cooperative and preemptive concurrency in the same program?
So maybe the lesson I'd take is that if you're programming with locks (or other synchronization primitives), your concurrency model has to be preemptive. Cooperative concurrency + locks = invitation to very subtle bugs.
Imagine you buy a car, then a few years later the company remotely disables it because they're selling a newer model. Without giving you the money back of course. That's what's happening with games. And not just multiplayer: tons of single player games have been killed this way. The whole SKG thing started with The Crew, whose single player campaign (a massive thing with tons of content) got remotely yanked by the publisher.
1) Imagine the timeline of musical history. If you don't have a clear idea of it, Wikipedia is a good place to start.
2) Pick any genre/period you don't know well. (For example, medieval music, or swing-era jazz.)
3) Look up the main figures of that genre/period. (For example, Guillaume de Machaut, or Duke Ellington.) Wikipedia is good for this too.
4) Listen to a sample of their most well known pieces. YouTube is good for this.
5) Repeat. Go down rabbit holes when you like.
No fancy tools needed, just your mind and the internet. This will give you interesting music for many years, and improve your musical taste a lot too.
A better heuristic is always keep in mind not only developer efficiency, but also program efficiency. I'm not saying optimize everything, but keep program efficiency in mind at least a little bit. In this case, that would've led the developer to download a tiny SVG or PNG and serve it from the app itself. Which would've avoided the problem in the post, and maybe other problems as well.
Except when they killed all 32bit games a few years ago with Catalina.
Consider a second-price auction: everyone submits bids, the highest bidder gets the resource, and pays the price submitted by the second-highest bidder. This is incentive-compatible: everyone is incentivized to submit the maximum amount they're willing to pay, no more no less. Does it matter if the resource is being sold by its original owner or a scalper? No. Who gets the resource and how much they pay depends only on which people wanted the resource and how much. The only loser from the scalper's existence is the original owner, because they sold to the scalper too cheaply.
If there are villains in this situation, they aren't those who extract market price: a scarce resource was always going to be sold at market price. If the price is set lower, people will line up in queues and so on, to "burn" an amount of patience and time equal to the price difference in their eyes. Except in a queue all participants end up spending this "burn", so it's strictly more wasteful for society than a market where only the winner pays.
No, the real villains are those who engineer the market so the resource is scarce to begin with. In case of housing: not landlords, but people who vote for laws restricting housing construction. In other words, most homeowners. That's the unpleasant conclusion that people are trying to ignore when they blame landlords, price fixing and so on.
Though I guess writing like this doesn't pay off in the modern world. Most readers don't consistently pay attention when reading, and to be honest, I don't either.
For example,
(1 + 2) * (3 + 4)
becomes 1) + (2 * 3) + (4
and then we add the missing parentheses and it becomes (1) + (2 * 3) + (4)
which seems to achieve a similar goal and is pretty unambiguous.I guess from the inside it feels different: I'll read 99 mind-numbingly bad comments and cut them all slack (in the sense of not replying to them at all), but these 99 instances of benevolence are invisible and count for nothing, because the 100th comment will make me fly in a rage and that's when I'll actually post something. And unload a bunch of my frustrations from the previous 99, too. The internet selects for extreme reactions.
> Later, in the 1970s, ARPA did emphasize the goal of "command and control". According to Stephen J. Lukasik, who was deputy director (1967–1970) and Director of DARPA (1970–1975):
> "The goal was to exploit new computer technologies to meet the needs of military command and control against nuclear threats, achieve survivable control of US nuclear forces, and improve military tactical and management decision making."