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.
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.
I'd hope most functional adults understand that the Fields Medal and basically every other annual "prize" out there is awarded to both "recombinant" innovations and "new-dimensional thinking" innovations. Humans aren't going to come up with "new-dimensional" innovations in every field, every single year.
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.
The “cars stopping in random places everywhere in any remotely urban area” thing has become a huge problem in general. It’s probably our clearest sign of the fundamental scalability problems of car-centric design.
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’ve had a looming crisis for decades of young people increasingly not understanding a lot of the fundamentals of mathematical logic. And I think treating LLMs (which are amazing tools) as “AI,” and having it play this type of role, is the final step towards a lot of unrecoverable self-destruction.
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 say both local data structures and algorithms atop them, and external services like DBs, etc., are both just “resources” in a more abstract sense. Optimizing performance is a matter of using the right resources for the right things. Algorithms help a lot when you’re building FE components (even if the server is rendering them, or “rendering” responses for the FE).
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.
I’ve only taken two buses in Brazil (Goiânia to Pirenópolis and back), and can definitely report that this was not the case there. It was incredibly hot and dry there until you hit the mountains, and the AC barely worked. Granted, I think this was one of the crappier bus lines, and they had a monopoly on this particular route.
There’s an entire Linux distro (Asahi) for MacBooks. Apple has never released a Mac with a locked bootloader.
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).
This is what I built Jonline for. Haven’t maintained it for a while, but it’s quite functional as-is. Basically a very vanilla Twitter/Reddit-with-first-class-calendar-events, standard Rust web+gRPC server on Postgres DB, React web UI, and no encryption other than HTTPS/TLS. No server-to-server communication, just username/password auth. Super easy to understand APIs (https://jonline.io/docs). (I do need to build better cross-server auth, but this can be done in the FE only with the existing APIs.) Can boot it in a Docker container in seconds. A few “demo” instances I run are linked from the Readme: https://github.com/JonLatane/jonline
We definitely don’t have any hard boundaries baked into this tech preventing big tech from (ab)using our data this way. But are there specific companies you think are doing this? I think with Meta products, it’s been rather obvious for a long time. But I’ve had a Nest doorbell camera and thermostats for years, and first iRobot and now Roborock vacuums, and they don’t really seem so suspect.
I guess the flipside of this is, do we want poor/homeless people from groups our society dubs “overrepresented” to only be able to find help from organizations that specifically serve selected “overrepresented” groups? Are there no obvious bad sides to that?
Because you can’t really have the one without the other.
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.