WorldMaker

The other difference was that Bootstrap met WCAG standards and had a very strong baseline of accessibility. These LLM slop outputs meet no such standards and seem to laugh in the face of accessibility.

The vast majority of LLM slop seems to be Tailwind to me, so sort of the opposite of a library, just a bunch of common patterns in Tailwind so common as to be everywhere but not common enough anyone bothered to put them into a reusable library.

Exactly. The benefit to the Bootstrap boom was it elevated a lot of cookie cutter designs like a raft on a series of sensible defaults that were are close to sensible/good taste as some very talented designers could make industrial cookie cutter standards. Bootstrap enshrined smart, intelligent defaults like good color contrast and a baseline of accessibility for developers just copy and pasting and modifying what Bootstrap gave them. For a brief moment the "I just need to get this done" web had a good accessible baseline.

LLMs aren't starting from sensible defaults and don't have to meet WCAG scores unless you tell them to (and even then might hallucinate checks they didn't actually make).

All caps text is a roadblock for reading speed/comprehension. Accessibility experts were finally convincing major company design standards to stop doing it when LLMs made it a default again [0] for headers and incidental text.

Not to mention that all caps text is also generally associated with shouting and just feels rude to some readers.

[0] Or more accurately trained on all the bad examples before experts started catching them and has stuck to the mistake.

It's partly a "Don't think of a Pink Elephant" problem. I've worked on several projects where I had to keep telling prompt writers to stop writing negative examples because the more you include the more its "attention" to them is all it has. Like telling a toddler not to do something and being surprised that is now all they can think about and they want to keep doing it. These prompt writers kept getting surprised that I'd delete all their negative examples and harshly worded "Don't do X" and "Never Y" and "NO: Z" sections they spend so much time on and got better results with smaller more focused positive example only prompts.

I've seen a couple companies already change their design standards to "best in class Tailwind designs from Claude, use this prompt file/Agent file/skill file combo for all UX work".

Looking at automated emails I get from Microsoft and GitHub it certainly feels like they are one weird layoff from doing it company-wide.

The worst part is these glassification Tailwind heavy slop almost universally fail WCAG guidelines (and personally, seem hard to read to me because of taking the whispy sans serif thing to its foregone conclusion by almost exclusively using what to me are unreadably thin weights of the already too thin Inter font). The slop is going so quickly backwards for companies that invested in accessibility and these companies need to be taken to task for forgetting design isn't just aesthetics but readability and accessibility.

"Confidence scores" have always implied an anthopocentric meaning that doesn't exist. An algorithm doesn't have "confidence" in the way that a person has confidence, but as soon you put something with that name in front of a business person they assume the number is always a meaningful "letter grade curve" or "universal percentage". I still believe so much that the old quote to "there's lies, damned lies, and then statistics" remains a key to understanding so much why ML is leading to dumb outcomes versus hype. People don't understand statistics, so machines that produce nothing but statistics especially confuse people. (I feel this applies to LLMs as well.)

LVT is about assessing improvements, conservation can be understood as an improvement and valued as such. For the same reasons that urban parks should have a different tax assessment than low value surface parking lots.

I don't know how hard it is to imagine the easily elided phrase "garage or parking lot or street parking or whatever parking situation" after apartment, but unless you also park in your apartment on the 6th floor it seems silly to ask this question to me.

> Using a functional language for data transforms sounds like a sane idea, haven't played around with it yet but it's definitely on my list now.

It's been one of the plays that the F# community has also been trying to make (somewhat with a modicum of help from Microsoft's marketing arm, but not enough help from what I've seen) pitching F# as a language close enough to Python to feel familiar and useful to data science but with the performance help of rich ML types and the modern .NET performance ecosystem.

(To my experience: getting "fast" compared to Python seems easy for most functional languages. Getting data science out of Python seems hard for a lot of sociology reasons more than technical ones.)

Interesting, most functional languages are quite terse and heavily whitespace, so you would expect raw token counts like that to be lower simply because source documents are on average shorter. Even having to make up for disadvantage things like C++ style operators like &&= all having single tokens from heavy use across a variety of languages but fancy functional operators like <=> being much more rare and in worst cases of undertrained models needing multiple tokens to express.

But yes, terser source documents and low raw token counts could mean lower prediction rates and more prediction attempts needed to get intended results (again, especially if the model was undertrained in that particular language).

EV batteries are reliable. "Range Degradation" is mostly a disproven myth. [0] Range figures vary with driving style, but that's the exact same issue with gas range, gas cars just had very bad/loose/nonexistent feedback on driving style inefficiency.

[0] Outside of the non-temperature controlled batteries of "classic" Nissan Leaf models and early Tesla models, but even then "range degradation" is largely overstated and statistically very few batteries were ever replaced in the lifetime of those cars.

No, I've been pretty consistent that I don't agree there's as much friction as people think there is, that in our society right now are a bunch of sociopolitical issues driving people away from doing the real research or actually trying to live with an EV. If goalposts seem to be moving it may be because you can't firm up your point on what "friction" even means to you.

But electricity is not nonexistent. It's easier to run an EV in rural Ohio than a gas car because you can install a real nice charger in that huge garage you have or outside your big barn next to your gravel lot, whatever, you've got space and a grid connection. That's not currently the average mentality, but that returns us to the sociopolitics of rural Ohio and EV adoption in the US in general more than any of the technicalities.

> since there are gas stations all over

That's the assumption, though. There aren't. There is an illusion of it, sure. I gave that anecdata from personal experience. It isn't "ridiculous", it's called having lived (and learned to drive) in rural Ohio.

> The cost differential is enormous and completely changes the economics of cost per mile.

Which is exactly the point and why it is a bonus. You can't do that with a gas car effectively or cheaply. You won't pay someone to come and install a gas service in your home or apartment with the express reason for fueling your car. That you can with an EV and would get a game changing efficiency and cost reduction is an incredible bonus.

> Sure, but a full gas tank gets you further than a full battery.

That seems to be less of a factor today. Most batteries have hit the same or more range as comparable gas vehicles.

Some EV models already have ~600 mile range which is double their gas counterparts.

> We have friends with a long range Tesla that takes them days to charge on 120.

Sure, but that's to 100%. You can drive a car with less than 100% battery. A 120v charge can add as much as 40-60 miles range overnight. That's an average person's regular commute. The car might "never" be at 100% if the 120v charge is all it ever gets, but for some people they might never need a fast charge in an average week or even month.

Take all of that anecdata and replace a gas car and it is the exact same with the same mental load: I've been on 18% fuel tank and wondering if my car will actually make it home or stall out on the road. I've been about to go somewhere and realized my car isn't fueled and and called a taxi or a Lyft as faster than the detour to refuel my car.

"It's an unreliable transport without having a gas pump at home." That just sounds silly. Funnily enough that was exactly one of the early complaints of gas cars when electric cars were preferred in the very early days of cars. It was a complaint when gas pumps were rare and hard to find, or didn't exist at all yet and you were pulling gas canisters from the back of a pharmacy.

It's a more reliable transport than a gas car because I can charge at home. (I can't do that at all with gas.) It's a more reliable transport than a gas car because in a pinch I can find an outlet on the outside of my hotel and trickle charge enough to get me to the next charger. (When was the last time a hotel had canisters of gas just in case?) It's a more reliable transport than a gas car because I can find RV plugs in national parks and state parks and campgrounds far away from chargers and gas stations. (You ever see what you might get charged for a tow from a remote national park, even if that tow is just dropping off a canister of gas?)

The impression of the charger situation being more inconvenient than gas stations is already flipping and has room to flip a lot more, possibly surprisingly quickly, as gas prices rise and low margin gas pumps go out of business.

I thought Return to Monkey Island did a very good job with it, and it was indeed exactly what MI2 was trying to say and what MI1 even foreshadowed, just refined with the time away from the project. It answered "What was Ron trying to say in the MI3 he wanted to write?" and it ended up doing it without diminishing Curse, Tales, or even Escape, and somewhat including them in the fun. (More Curse and Tales than Escape, it certainly ignored/retconned Escape events, but Escape's appeal has always been smaller.)

The Remaster added modern controls and even a point-and-click mode. Worth revisiting.

It's not a bad faith argument, it is comparing like for like. (Saying that it isn't like for like seems to me to be the more bad faith argument in 2026.) If I have a gas car with 300 miles of range I go about 297 miles safely between fill ups. If I have an EV car with 300 miles of range I can go about 297 miles safely between charges. Those are the same characteristics.

The part that isn't like for like sure is that there is an increased friction that even a "fast charger" can take a magnitude more time than a gas pump. But fast chargers are much safer and can be parallel tasked (running other errands while a charge happens) whereas gas is an explosive and requires diligent observation while refueling (despite how many people seem oblivious to all the warnings not to leave a refueling car unobserved and a long history of explosion statistics).

In my experience, fast charging time and lack of home charging ability (and under-estimation of Level 1/2 charging utility) feel like red herrings rather than actual issues. These things get talked about a lot, but the real world experience of them isn't the friction people believe it is. The biggest issues seem to be far more sociopolitical than technical to me. People have invested too much of their identities in gas. Entire political parties seem devoted to propping up gas sales for as long as possible.

It's true in the US market. Europe and Asia are seeing a flood of smaller EV cars from Dacia, Renault, BYD, VW, Fiat and far more. The US is getting left behind.

You don't need a home charger to enjoy driving an EV. A home charger is a bonus to driving an EV. Do you know anyone who has ever had a "home gas pump"?

Not to mention how many people sleep on Level 1 and Level 2 charging, which are cheap or cheap as free in many homes. (Garages have had electric outlets for a long time. Some have had "dryer plugs" for nearly as long, due to power tools one might own.) Trickle charging doesn't get you to 100% overnight, but no one drives on a 100% full gas tank every morning either.

I wish they had a variant in a more normal sedan or hatchback than its "PT Cruiser thing", but it is still one of the closest in the US market to a normal car.

It's too bad Europe and Asia get all of the nice EV sedans like Dacia Spring and BYD Dolphin. This article even says Toyota hasn't committed to this Corolla EV in the US market, which is shameful.

Again, I still don't need to know how `i` is getting invoked if my security bar is `no import() calls`. `i`'s declaration is the red flag. Full stop.

Notably `import` is still a special reserved word in JS, so it does not exist on globalThis. `import()` in function usage is special and so to get added to globalThis has to be redeclared in a wrapper function such as `i`. That redeclaration is now always a red flag. I can work to reverse engineer whatever is calling it, or I can simply declare that entire ESM dependency untrustworthy and move on to something more reliable.

(ETA: Especially because in an ESM context, to be declared on globalThis it cannot use simply top level `var`, it also has to especially be globalThis object pollution, which no matter how you access globalThis to pollute it, looks weird and strange. Bonus: If the source is Typescript it will also likely involve an explicit `as any`, another potentially untrustworthy marker in a downstream dependency.)

I seem to recall that GHE allowed you at one point to point a Wiki to a /docs or /docs/wiki subdirectory. I still don't know why that never became a public GitHub.com feature. Sure it is technically redundant with the file browser if you know how to use the view controls and don't mind the UI sprawl of the file browser, but I still think it would be a good feature.

Not so much a "you're holding it wrong" as much more directly "we didn't expect it to be used that way". The Linux Kernel team was using it in a DVCS way with a mailing list as the primary "remote work in progress ref storage" and local refs mostly just local personal branches and tags. The "Hub" model of everyone on a project having access to nearly any and all refs in the project is different from the model of the original git developers. Neither model is "wrong" just one is more unexpected when working on the other.

(As a Windows user, I certainly can't argue that sometimes the filesystem as database has been a performance hit when using git. Though Windows filesystem performance isn't always slow, just performs differently, especially with corporate anti-virus tools involved.)

git stash is given the UX of a stack, but it's more a list or a set of commits. The commits in your git stash don't need to be related (their commit parent pointers can point at very different branches). At some point if you are heavily using lots of stashes you tend to switch to referring to them by commit message and/or stash number instead of thinking it a stack you build bottom to top and always and only pop from the top.

It is a giant format change, but in the current documentation [0] sounds more like a repack than a force-push. git keeps a lookup table of the SHA1 object ids similar to an index file and some interop is allowed between SHA1 repositories and SHA256. (Primarily if you still needed to use GitHub as an SHA1 server because of some support hiccup, but needed your local repo to be SHA256 for security or other reasons, that's partially/mostly supposted.) Objects need to be resigned with their SHA256 id, but for different reasons than rebase/force-push and with a subtly different developer experience. In theory using that compatibility index of SHA1 hashes a good UI could show both signatures.

[0] Migration document: https://git-scm.com/docs/hash-function-transition

`i` still shows up in my grep, though, for anything like a function call of the word `import(`. Even if it takes a search to figure out what calls `i`, you know something is fishy because `import(` is used at all instead of the `import` keyword. Whereas there's no easy distinguishment of "top-level" static require and dynamic require, it's always a function call. (You can Regex match a negative lookahead for calls that don't include static strings, but that's a much harder regex than the `import(` call regex I provided.)

(ETA: Even/especially in minified code. Something like `var r = require` is rather common in Code Golfing/minifying CommonJS so grepping all uses of require both static and dynamic is also complicated by nicknames. But ESM doesn't minify static import ever and yeah dynamic import might be minified, but that still means it sticks out as a sore thumb if it exists at all even in minified shapes. Especially in minified shapes because that often means it is used multiple times for a minifier to decide that minifying it is worth the tax of declaring the minified nickname.)

Given Disney owns the IP now, they probably don't need to make a Grim Fandango movie because they made Coco: https://en.wikipedia.org/wiki/Coco_(2017_film)

On the other hand, I still think Disney should make a Monkey Island TV show or movie. They could use Sea of Thieves-style water effects in the Volume for useful shenanigans.