I suspect his diagnostic is pretty accurate, though. The bitter lesson came up when deep learning was already mainstream. The text discusses how that happened, and it can be the case that convenience beats accuracy. Accuracy is an epistemic value, but current AI is largely driven by market values. If accuracy manages to get along, great, but other than that, market-laden convenience reigns. Commercially, it is often more convenient to even change the world in order to make it easier for our models (consider how we're willing to create special places without pedestrians or human-driven vehicles for autonomous vehicles as a "solution" for their shortcomings).
It's not mindless brute-forcing, the details of the architecture, data, and training strategy still matter a lot (if you gave a modern datacenter to an AI researcher from the 60s they wouldn't get an LLM very quickly). The bitter lesson is that you should focus on adjusting your techniques so that they can take advantage of processing power to learn more about your problem themselves, instead of trying to hand-craft half the solution yourself to 'help' the part that's learning.
I found this article a little weak, but there is an interesting parallel.
The 10,000 hours thing is encouraging because the amount of effort you put in as far more important than your natural ability.
... Until you get to the point where everyone is already working as hard as humanly possible, at which point natural ability becomes the sorting function again.
They have researchers working for insane salaries just so they don't go to another frontier lab to share their ideas. If you think it is just "mindless bruteforce" you don't understand anything. The idea is that the most effective methods are ones that scale but those ideas are also then limited by the compute available.
A little too US centric. With a bit more effort it would detect all of the G20's post code formats and fill in the country name automatically. (Sparing me the frustration of trying to choose between Switzerland and Swaziland in the 6 point font you chose for the pop-up.)
Also, don't be a dick. Have some empathy for your reader. Half of the UI designers you are talking to don't have a choice in how it works. Their colleagues chose some stupid framework which they can't customize. The other half didn't even want to do this task, they just got it assigned to them by some PM they don't respect (who, in turn, does not respect any advice coming from UI designers), and they are doing the minimum they possibly can while applying to other jobs that suck less.
UUIDs are recognizable, have a version field, can be sorted in the case of UUIDv7, a standardized format means easy interoperability (eg, encoding, validation, serialization etc), and databases can optimize storage and efficiency when using a native UUID type.
If just using random bytes, you still need to make decisions about how to serialize, put it in a URL, logging etc so you’re basically just inventing you’re own format anyway for a problem that’s already solved.
Why the hate though? Is someone forcing you to use them against your will? If you need 128 bits of crypto.Rand() for your usecase, you can just use that right?
To be fair that’s literally just a waste of resources. If you want 128 random bits just get 128 random bits from the underlying source, unless your host langage is amazingly deficient it’s just as easy.
That misses the point. The point is for easy validation that the key was generated appropriately. Many api keys have a standard prefix for just this reason. It especially helps on documentation where the key name might be confused with the value: "your key starts with hnkey-"
I hate UUIDv4, don't care about the rest. UUIDv4 is just random bytes with hyphens inserted in random places and some bytes reserved to indicate that this is in fact a UUID. This is wasteful and stupid
What if I want an ID in the URL? Parse it back and forth? And what if for example, nodejs's UUID api only gives me the string representation of the ID?
To minimize the storage space while having a URL-safe representation, yeah you'd want to serialise/deserialise on the boundary of presenting it to API consumers. I think the same for any ID that has an efficient binary representation as well as needing to represent it in ASCII.
UUIDs aren't random by design, and the structure is not pointless. Calling something you don't understand "stupid" is probably not a good approach to life.
One example where UUIDs are useful is usage as primary keys in databases. The constraints provide benefits, such as global uniqueness across distributed systems.
The global uniqueness of a uuid v4 is the global uniqueness of pulling 122 bits from a source of entropy. Structure has nothing to do with it, and pulling 128 bits from the same source is strictly (if not massively) superior at that.
General strike! Close the ports, close the airports, steal dozers and park them on railroad tracks, teachers on the streets in front of their schools to protect their students, blockade the grocery distribution centers, so that the shelves go bare, just stop everything, everywhere.
When it hurts the billionaires, they will tell their politicians to invoke the 25th.
It's the only way, we've lost our democracy, but we still have economic power.
Disrupting basic functions of the economy will hurt ordinary people a lot more than it will hurt billionaires.
Also under these conditions of food distribution and transportation being actively disrupted, why would anyone be at school? Huge numbers of American schools are unsafe and unpleasant places for kids to be in ordinary times, and a massive disruption to ordinary life is not going to make that situation any better.
I work at a company that was born and grew during the master->main transition. As a result, we have a 50/50 split of main and master.
No matter what you think about the reason for the transition, any reasonable person must admit that this was a stupid, user hostile, and needlessly complexifying change.
I am a trainer at my company. I literally teach git. And: I have no words.
Every time I decide to NOT explain to a new engineer why it's that way and say, "just learn that some are master, newer ones are main, there's no way to be sure" a little piece of me dies inside.
No, actually, zero people 'must admit' that it was a stupid, user hostile and needlessly complexifying change.
I would say any reasonable person would have to agree that a company which didn't bother to set a standard for new repos once there are multiple common options is stupid, user hostile and needlessly complexifying. And if the company does have a standard for new repos, but for some reason you don't explain that to new engineers....
There was only a single standard before, so there was no reason why a company should make any company specific standard. The need for companies to make a standard only exists, since the master to main change, because now there are two standards.
Except git init still creates branches named master without configuration (although with a warning), which will only change in 3.0 for obvious reasons, and tons of people (including me) still use master, and old projects don't just vanish.
Why does your company not migrate to one standard? Github has this functionality built in, and it's also easy enough to do with just git.
I'm personally a huge fan of the master-> main changejus5t because main is shorter to type. Might be a small win, but I checkout projects' main branches a lot.
It's extremely obvious that "main" is more ergonomic. It's sad that we're so resistant to change (regardless of how valid you think the initial trigger was)
I love the arguments where you tell me what I “must admit”.
I simply don’t, therefore your entire point is meaningless.
I’m sorry that something so inconsequential irked you so much. Maybe you need to read a book about git if this stumped you bad enough to want to voice your upset about it years later?
I’d consider yourself lucky that everything else is going so well that this is what’s occupying you.
reply