pseudocomposer

The entire Python ecosystem is horrible and shouldn’t have been as falsely boosted by institutions as it was in the 2010s. Yes, it got less bad with 3.8 or whatever version added type annotations. But making so much of ML depend on Python has made it distasteful to a lot of devs who would otherwise have contributed more to it.

We really need to move all AI/ML research off PyTorch to Candle or… just anything that isn’t Python or another old-gen, broken language like it.

I guess you don’t travel by car except for work commutes?

I’m a few years into PHEV ownership now, and I’m so glad I didn’t get an EV. Just a normal weekend trip to the beach or mountains (200-ish miles from the Triangle of NC either way) would mean I’d have to limit myself to hotels/Airbnbs with a charger. And chargers are VERY sparse everywhere I’ve been.

With my RAV4 Prime, I get 40-50 miles of EV range, enough that most days I use zero gas. But if I want to hit up the beach or mountains, or take a cross-country trip, or drive up to PA or VA to visit my girlfriend’s family, there’s zero hassle to find a charger. It just reverts to a normal hybrid once you run out of electric-only range (around 20% of the battery’s actual capacity).

It also performs far better than any EVs or ICEs I’ve seen anywhere close to its price point.

This “everyone should just have an EV” thing really reads like a modern “let them eat cake.”

I agree with your sentiment, but at some point backwards compatibility has to break. Rust handles it better than basically anything out there. If it bothers you, you should never try any other language except maybe plain, no-framework JS.

Plus, LLMs have really made upgrading a codebase for a compiler or dependency update into a trivial chore, at least for the most part.

I don’t really understand the benefit vs. Kubernetes? Like, with modern agents and a generic Kubernetes cluster (and there are SO MANY providers), a good LLM harness can do basically anything you’d want to do, if you structure your work properly.

And heck, harnesses like Claude Code have a phone friendly UI too.

I agree with you about “thoroughness” being key here, but I’d additionally advocate that we need to leave room for people to make some slop learn it.

Part of the learning process, whether you’re a “skilled” or “unskilled” engineer (or not an engineer at all, and noting that going from one to the other is just a matter of learning), is being able to “vibe and not care.” Yes, it’s also helpful to identify things that might not work out theoretically in advance, using the things we learn in our CS programs. But coding with LLMs is a brand new modality, and we are all indeed just learning to work with them.

I think alternating vibe coding with vibe-assisted DRYing/cleaning is ultimately a workflow enhancer that can make better software faster. But engineers have to be allowed to make some slop to learn it.

I don’t like being disagreeable, but just no. On both of these.

First, the comparison is perfectly fair. Elm 0.19.1, 6 years ago/0.19.2 today, React 16.1 6 years ago/19.2 today. Literally identical conditions. What is unfair? Which required app developers to do more work? Which saw more security issues among its releases?

Second, not needing updates for 6 years, and having zero security holes in that time, is the definition of stability. This isn’t really a matter of opinion or preference.

I do see the appeal in other frameworks (ecosystem size, easier to find devs), but the appeal of Elm truly is stability. And it really is that much better than nearly everything else that runs in the browser, in that regard.

No framework that allow you to use actual JS (or “transpiles” but gives you the full JS API, like Coffee/TypeScript), will ever offer the level of stability Elm offers (aside from maybe the web standard APIs on which Elm is narrowly built).

I’ve been using Elm professionally at a very profitable, lean company the last two years. (Didn’t know it coming in, but had enough React, Redux, and other experience to learn quickly.) The Elm community would call this a feature. How much React code you wrote 6-8 years ago will work perfectly and identically with today’s React toolchain?

It’s a whole different set of values. Good React code in 2026 looks like any compiling Elm code since 2016.

I think “when you buy a product, be it a game, a house, a car, a computer, a tractor, washer, TV, it should continue to operate without rent-seeking behavior” is the best type of straightforward, uniformly-applicable pattern of regulation one could hope for. Opposing rent-seeking is literally why we have American democracy, which paved the way for French, Brazilian, Canadian, Indian, Mexican and so many other democracies. Kings were the ultimate rent-seekers: every citizen was the product.

It’s not like this is some special case. People make the exact same arguments against John Deere, Tesla, Apple etc. And it’s a major reason many understand we should favor local (or local-capable/open-weight) AI/LLMs. I think “for any product whose support is discontinued, with more than X users, either open source all relevant software and hardware schematics, or provide a binary that will work on the hardware in perpetuity without DRM checks, based on industry” is a miniscule request in the face of any of these industries. I’d say, for instance, weights for discontinued Claude and OpenAI versions would fit. And it’s exactly the type of problem (functioning) democracies are meant for.

Part of me hopes that without React (poorly) filling the void, something like Elm could have gained traction. But ultimately I think it’s unlikely.

I’m rather optimistic about the future of smaller open-source models and market competition actually doing its job here, honestly. I myself, again, err on the side of doing things with my own brain. But there are many things LLMs are useful for, and they’re definitely better than a “rubber duck” if you don’t trust them blindly.

We’re in a world where LLMs are basically going to be extensions of how we think. An additional thing we use to do a lot of thinking tasks.

As a piano player, it’s important to work hands separately. Sometimes your right hand will carry the melody and your left hand the harmony, sometimes vice versa. Sometimes there may be more than just two “voices”/melodies/lines between your two hands. Even as a very good (as in getting paid to do it) sight reader, I learn a lot working all the voices/melodic lines separately.

Singers do similar things like singing only the vowels to keep themselves in the right placement. Learning handstands, you have to work your wrists, rotator cuffs, core (which is many things), etc. separately. Yoga, Pilates, and running also help us learn to break problems down this way.

Anyway, all that to say: If LLMs are gonna be a natural extension of how we think, we need to understand what parts of problem-solving LLMs are good for, and what parts our brains are for. The nice thing about working these bits “separately” is that one side is done for us. So we just need to consciously practice using our brains.

As programmers that means, maybe we conscientiously practice writing things ourselves sometimes. Remembering that this even if this sacrifices short-term “velocity” (whose measurement is problematic, but I digress), it preserves our long-term ability to do good work. And I think any of the above physical/artistic practices (or countless others), worked in these ways, will help reinforce this entire mindset.

I think kids of the coming generation will be sharply divided on their ability to conscientiously practice things separately. It’s been happening, but I suspect LLMs will accelerate it unless how we actually teach kids can catch up.

What are “vs code hooks” exactly? A search for that or “VSCode Hooks” isn’t turning up anything for me in Kagi or Google…