chao-
Ruby is on its third (I think?) JIT now? I'm a little surprised, given Ruby's reputation as a wacky "anything goes" language with a very complex grammar, and it makes me wonder why that is? Does it have to do with the design of the runtime itself more than the language semantics? Or is it more incidental, e.g. many popular ibs are C wrappers, already generates bytecode files, and so on.
I half-agree with this sentiment and want to stream-of-thoughts back at you in response:
>I don't find there to be huge differences in legibility between the common high level languages. This is especially true now that I'm reading far more than I'm writing, and relying on static analyses to determine correctness, far more than on my own interpretation of the code.
At best I have 70% confidence in what I'm about to say. Without AI agents, I feel like a language and ecosystem's expressivity could shine more when a project had heavy and finicky business logic. It matters less when you can ask your bot to interpret the invariants and feature behaviors at a broad scale. Again, I'm not 100% confident in that claim.
Even prior to AI agents, in such a project, first and foremost you needed to understand why the piece of functionality you're looking at does what it does within the business domain. The code was already secondary, but I think what agents have changed (for me) is that by lowering the cost of maintaining types, tests, and documentation, the code (and thus its expressiveness) might be becoming tertiary? Even when I was the one who wrote some documentation, half of the time I would go straight to the code to get an answer, rather than read my past explanations. Perhaps a sign that I am a bad doc writer? But that's where I felt the combined language-ecosystem expressiveness mattered most (along with keeping to architectural standards): I need to look back at something to understand it.
To try and end with a conclusion for my own thinking aloud: I feel like further emphasizing those three aspects (types, tests, documentation) flattens the demands on "legibility". Bouncing between tests (and even types) in Language X vs Language Y is far less differentiated than bouncing between Language X's ORMs vs Language Y's ORMs (or dataframe libs, or http servers, et cetera).
Ruby is never going to be a BEAM language or Rust, but I'm pretty excited for the near-term performance improvements in Ruby; not only the base language (e.g. Spinel), but in the broader ecosystem. When you avoid a handful of footguns, you maintain some basic architectural consistency/organization (and get your agents to do the same), Ruby continues to have a good balance between expressiveness, and the ease of reasoning about the code, relative to the amount of annotations and boilerplate you need to throw in to get there.
For someone who is persuaded they should never read the code anyway, then that's not a benefit that they desire, vaya con dios! There's not much conversation to have when working from such different premises.
https://www.texastribune.org/2026/10/05/texas-flock-cameras-...
Less egregious, but still egregious, a few weeks ago a local news investigator in Houston was quoted $121,000 for public records request related to Flock cameras:
https://www.click2houston.com/news/local/2026/09/24/harris-c...
Observation: Sooner or later, all of our family's elders have wound up cared for by a mix of children, grandchildren, nieces, and nephews. Even those who didn't have children. We're an ornery bunch, so quite a few stubbornly insisted they didn't need anyone, yet eventually they did. Care often came at an inconvenience to those providing it, but one way or another, in one form or another, care was given. I can only think of one person from my extended family who wasn't cared for by the younger generations in his final years.
Speculation: The average number of children in my extended family hovers around three, and most of us are in a few geographic clusters (not the same city, but still a cluster). Perhaps if the average litter was between one and two, and/or we were more spread apart, we may have slipped into line with that stereotype?
A "scapegoat" is someone who is incorrectly blamed for someone else's errors or sins. The perspective you're responding to is this: They built the system, they run the system, they have continuously warned "This system is dangerous!", and yet persisted. That is not being incorrectly blamed, not being a scapegoat, and instead is a collaborator.
So I think you mean to ask: "Why do people focus so much on finding someone to blame?" It's not merely semantic, because the answer to that is more straightforward: Consistent accountability is a major factor in deterring bad behavior. It is not the only factor, but it is a major one.
That is my Steel Man understanding of the people searching for individual blame.
https://www.servethehome.com/ibm-z-and-linuxone-dual-isa-pro...
In truth, I don't think that's quite how it works, but I wouldn't be surprised if teams who scrape data for training apply weights in favor of data that is known to be generated prior to the GPT-3 era.
I can't bring myself to be bullish or bearish in such broad strokes.
Over the years, I have met and worked with a number of people who were "non-technical", but who nonetheless built their own internal rough software tools with a cobbled-together combination of spreadsheets and SaaS services, connected by something like Zapier. They are a particular kind of person, but I would not call all of them them "technical". They are experienced in their business domain, are detail-oriented, and are persistent in making improvements by any means they could.
I have seen those people be supercharged by AI app builders like Replit and Lovable, even if I don't personally have a need for either.
This might be a matter of definitions: Is such a person "technical" because they value systematizing human processes and put effort into it? Or is such a person "non-technical" because they are not experienced in software engineering best practices, or programming in the conventional sense?
In addition to the nature of the user, I suspect the fulcrum that success and failure rests on for these kinds of apps and tools is long-term maintenance. How frequent? How involved? How breaking are the changes? On this topic, there is a quote I think about a lot (paraphrased, and I forget who said it, or I would credit them):
>AI app builders mean that anyone can experience the joy of building software, but also that they will experience the joy of maintaining software.
Another awe-inspiring quine of his, from about a decade ago, is the 128-language ouroboros quine:
His backstory is really one-of-a-kind. If I recall correctly, he got really into botany because he worked for Union Pacific railroad, and while stopping in a city, would go to the library and checkout different botany books.
At some point he taught an online course called "Blue Collar Botany" that went through plant ecology, evolution, identification, and other topics. It was fantastic, and finally got me into learning about the plants around me more rigorously. Years later, I still hear his voice in my head when I see certain parts of a plant like a laminar stamen. His affect is so unique that it actually helped me remember the content easier.
I don't know if he still teaches it or sells the videos from those sessions, but I would recommend it to anyone who wants to learn more about the natural world around them.
https://gundam.fandom.com/wiki/ZERO_System?file=W_ZERO_Syste...
Later in life I would think of it as being inspired by the UK's SAGE defense system, even though it probably wasn't. You can't exactly see from the image, but the screen is a glass dome:
https://www.computerhistory.org/revolution/real-time-computi...
I never understood why it was set off to the side in an (official, first-party) extension, because I was always afraid they would one day stop supporting it. Now when I explain to people why I prefer Firefox, I don't have to explain "There's this extension, don't worry it's official, that allows me to..." I can just say "It has containers built-in. They're great. Try them."
So I guess someone wanting that would be prepared for it.
Also glad that Neil is getting the protection he needs (and the public as well) despite the media attention.