771 karma · joined June 14, 2023
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’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 think people like nuclear because, over the last half century, CO2 emissions per capita have been drastically lower in the places nuclear has a larger energy share, like France.
Plus, LLMs have really made upgrading a codebase for a compiler or dependency update into a trivial chore, at least for the most part.
And heck, harnesses like Claude Code have a phone friendly UI too.
Agents have been huge for me. In addition to the Elm app, I used them to:
- build out ffmpeg/imagemagick image/video resizing - unify all my servers behind one Traefik ingress - build proper cross-site auth with a public/private key pair generated in the browser - create Homebrew/macOS and Linux tarball distros of my service - build an iCal calendar sync feature (if you browse the sites, you’ll see many of the events are synced from locally-oriented ICS feeds)
I also set it up to run my band’s new website at https://ato.band.
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.
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).
It’s a whole different set of values. Good React code in 2026 looks like any compiling Elm code since 2016.
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.
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.
I'd say yes, LLMs "just" recombine things. I still don't think if you trained an LLM with every pre-Newton/Liebniz algebra/geometry/trig text available, it could create calculus. (I'm open to being proven wrong.) But stuff like this is exactly the type of innovation LLMs are great at, and that doesn't discount the need for humans to also be good at "recombinant" innovation. We still seem to be able to do a lot that they cannot in terms of synthesizing new ideas.
Assuming we can’t significantly reduce car usage (and noting that you can still prioritize bike/pedestrian-friendliness and assume this), we really need regular car equivalents to bus stops. For Waymo or human rideshare drivers, or just non-transactional human families, say, dropping grandma off at a brunch restaurant. And significant fines + license points for anyone who stops anywhere outside them, like they do now, once established. The idea is no different than frequent trash cans and significant littering fines, really.
(I’m just spitballing here and am open to being wrong, just putting the idea out there as someone who’s noticed how much worse driving in cities has become over time.)
We need to remember that the core of what “logic” is can be understood by every human mind, and that it’s our individual responsibility to endeavor to build this understanding, not delegate or hand-wave it. For all of human history, delegating/hand-waving away basic logic that can be understood by actuarial/engineering types has never gone well in the long term.
I’d also argue “micro-ORMs” like Diesel (which isn’t really much like ActiveRecord, Hibernate, etc., but more a very thin DSL/interface that maps SQL types to Rust types), combined with LLMs, are the ideal solution (assuming we still want humans to be able to easily understand and trust the code generated). And there’s a big argument to be made for schema migration management being done at the app level (with plain SQL for migrations).
All that said, at work, we use Rails. And ActiveRecord’s “includes/preload/eager_load” methods are fantastic solutions to 99% of cases of querying for things efficiently, and are far more clear than all the SQL you’d have to write to replicate them.
And macOS frankly provides a far better Unix experience than ChromeOS, in my experience, having actually used both (including for development, though only for a short time on ChromeOS because it was horrible).
Because you can’t really have the one without the other.