rspeele
Perl 6?
* A bad actor finds a real, theoretically severe but not easy-to-actually-exploit vulnerability in some popular software. E.g. it's an exploit that can get you pwned 100% with RCE, but only if you are using it in configuration X on platform Y with kernel version Z on a Tuesday.
* They design a patch that closes that vulnerability but subtly opens a more dangerous one known only to them. They privately test their patch against LLM reviewers, tuning the approach until the introduced vulnerability typically escapes detection by automated review.
* They "responsibly disclose" the original exploit and helpfully share the patch. In the hurry to fix the original exploit, the patch itself gets only cursory (claudy, codexy) review. By now this has happened so many times that just applying whatever code changes ClodSed were GTG is the status quo.
* When the new vulnerability is eventually discovered, they can plausibly say "oh my agent didn't catch that", which is true. In the meantime, they use the new exploit that only they know about.
This particular project is so low effort I'm leaning towards it being parody.
See: https://rustoffrails.org/how-it-was-built
> Hey Claude, write a set of guidelines for how Claude should build Rust web apps. Like Ruby on Rails, you know, but in Rust. Claude doesn't automatically know how to do this so I'm counting on you, Claude, to teach it. Make sure it's opinionated. I don't care what the opinions are, but it's gotta have them.
Edit: oh my God, not only is the framework just markdown files, it has an MCP server for agents to read the markdown files. Ok, I'm convinced it's a parody.
Also: "No line of the framework was typed by hand."
So it's not even your wish list.
I could prompt Claude "write down best practices for building web apps in rust, then build <my idea> as a web app in rust following those practices." How would that differ?
I can't tell if this is a satire of "markdown engineering" or not. Poe's law in action.
Some parser combinator environments are better than others. Haskell's applicative style is pretty good:
(\x y z -> ...) <$> parser1 <*> parser2 <*> parser3
parser1 .>>. parser2 .>>. parser3 |>> (fun ((x, y), z) -> ...) // ugly nested tuples!
pipe3 parser1 parser2 parser3 (fun x y z -> ...)
pipe3 (whitespace >>. parser1) (char '(' >>. parser2 .>> char ')') (whitespace >>. parser3 .>> whitespace) (fun x y z -> ...)
https://rspeele.github.io/FParsec-Pipes/Intro.html
My approach is more symbolic-operator flavored than yours though. In mine you always start a chain of parsers with `%%`, separate with `--` and end with `-|> function`.
%% parser1 -- parser2 -- parser3 -|> fun () -> ...
%% +.parser1 -- parser2 -- +.parser3 -|> fun p1 p3 -> ...
https://github.com/fsprojects/Rezoom.SQL/blob/master/src/Rez...
Shame on them for such weaknesses as:
* Desire to make memorable achievements in their field
* Missing the social elements of sharing and discussing problems with their colleagues
* Sense of self worth linked to ability to make a unique contribution to society
* Fear of losing status and income in a ruthlessly competitive economic system
* Anxiety over debts already accrued during years of studying
* Regret over choice of career path and roads not taken
Astra would never.
Mathematicians acquired their skills over long hours of study, but weren't asking to be paid just to sit around passively being smart, but to keep working on new results. It is the lost opportunity to do work they are lamenting, not the lost opportunity to sit on their laurels. So no, it doesn't sound like rent-seeking.
Oh yes, this new world is terrible for rent seekers. It's like the kum-bah-yah free software world Stallman might have imagined. Information wants to be free and all. Can't stop the signal. Very counterculture. Like the Adobe clone apps.
Except for the closed SOTA model weights, out of reach hardware, and the resulting $200 subscription rent now paid readily both by anybody trying to create something new, and anybody who wants to rip it off. That particular flavor of rent seeking is booming.
I myself am a "rent-seeker" in an alternative sense of "I seek a way to pay for my own continued shelter via my creative output" and it definitely seems like it's gonna suck for me.
With bitcoin nothing is reversible so every step of the process is a huge security risk where you can fall off a cliff and experience financial permadeath of "your" crypto, assuming a sufficiently motivated attacker.
* OpenSCAD -- cool idea, good for a few types of highly procedural parts, but most of the time I'd rather a parametric sketch-based interface over pure code.
* FreeCAD -- the most features of any open source CAD, but poor UI, tendency to crash, and the advanced features like loft kind of fall flat compared to commercial equivalents. You think you'll be able to model a part, but it becomes extremely frustrating if you actually need the advanced tools.
* SolveSpace -- pretty stable and reliable. Fast, compact, great sketching interface, good discoverable UI. You can predict what types of parts you can model with it and what types you can't. Doesn't try to do everything but is good at what it does.
You can tell which one is my favorite! N features done to a good level of polish and with somebody making sure it all "makes sense together" beats 10xN features all 80% done and haphazardly mashed together in different menus/workbenches, for any tools I want to rely on.
I am noodling around with a slopcoded CAD tool of my own these days, just out of curiosity to see how far Opus5.5/GPT6 can get doing it in F# and to experiment with some workflow concepts that match the way I like to design parts. But like you said, progress is slow. For stuff I actually want to get done, SolveSpace remains my go-to, and I greatly admire its coherent design.
[0] https://github.com/rspeele/infix.el
[1] https://github.com/rspeele/LicenseToCIL
[2] https://github.com/fsprojects/Rezoom.SQL
[3] https://rspeele.github.io/FParsec-Pipes/Intro.html
Yet, it's utterly hopeless to try to take the same stance visual artists are nobly holding. Of the programs I use daily, how many have I ever even glanced at the source code? I could count them on my fingers. And I'm in the target audience: a programmer, enthusiastic about the trade, one who has contributed to open source...
Conclusion: within a rounding error of NOBODY cares about the code. Of the weavers who were displaced by the automated looms, or the furniture-makers displaced by mass produced pressboard, some of the most skilled could still ply their trade for the rich who wanted to flex their bespoke handmade goods. Programmers writing code by hand will not even have that luxury market. It makes me depressed but I don't see any way around it.
My hope is that I can use my knowledge, willingness to spend long hours fighting with a computer, and industry experience to at least make better software with agents than the average vibecoder. I sadly don't think I'll get anywhere trying to play John Henry vs. the Steam Drill, trying to beat it with my hand-typed code. Maybe somebody who's 10x the dev I am can do that, and Godspeed to them, but I thought I was pretty decent and I don't have a chance.
Hell, it's not even possible to prove any code was written by hand, other than by having uploaded it pre-2024ish. For this reason I really feel bad for those coming up right now, who have the same enthusiasm and fascination for Real Programming that I did, but no way to prove themselves and no motivation to in a world that values that skill less all the time.
I also initially looked around the desk for a physical cartridge, such was the effectiveness of the rest of the “game”.
First job had me using a programming language I wasn't super familiar with and trying to add a feature to a codebase 100s of KLOC, all written by other people. Definitely a sink-or-swim moment. My skills of reading and navigating the dreaded Other People's Code were all honed over the next dozen years.
That being said AI is a lot better at reading code than I am, as demonstrated by its ability to find incredibly subtle bugs in huge codebases. So I'm not even sure those code reading skills are all that useful now. When I have to review somebody else's code I get more mileage from pointing an AI at it and asking targeted questions like "how does this handle when a Foo's approval is revoked" than reading it myself line-by-line. I'm not saying I never use those reading skills but the ability to get the big picture, chase down deep callback chains, know where to look... those skills are likely to atrophy.
It's like using GPS vs. knowing the roads as well as a cabbie. GPS gets you pretty damn far for zero effort.
The sub-agent separation is still valuable to keep context clean for the orchestrator, but I just have no reason to use Sonnet as the grunt-work implementer because I'm finding it hard to run out of tokens with Opus 5.5 on a $200 subscription plan. It's really really good at subjective quality of work per token used.
If they can just keep working on it and make sure to train it on all my past emails, it'll be a perfect simulacrum, and its oily token secretions will be impossible for my friends and colleagues to distinguish from my own writing. I'll have one that's just like me and you'll have one that's just like you. And then we can automate away those pesky distractions that occasionally delay us from consuming content perfectly matched to our interests. Won't that be grand?
It's like Clippy pops up and goes "It looks like you're trying to maintain a shred of human connection in an online interaction. Would you like a smiling skinwalker to do that for you instead?"
In my circles I've noticed it's very easy for us to rationalize why our previous favorite language is also the perfect language for the agent era.
If your favorite language before was Python, why, LLMs are fluent in it! So much training data! So many libraries! Home of machine learning! None of that pesky compile time, agents don't need compile time safety anyway, they write such good test coverage! It's The Perfect Agentic Coding Language.
If it was Rust, by jove, an agent can easily handle the headache of satisfying the borrow checker, and now you get the best of all worlds! Safety! Near-C runtime performance! Abstractions! The only reason people didn't use Rust before was it was Too Hard and there were Too Many Furries and now it's not hard and you don't have to interact with them, so get on board. It's The Perfect Agentic Coding Language.
If it was Golang, oh my goodness, what a choice. Pretty fast compile time and pretty fast runtime. Agents get a tight feedback loop with build->run->test->edit. Not very complicated, code has to be written in a straightforward banging-rocks-together way. Good stable ecosystem! Rob Pike designed the language for people he said were "not capable of understanding a brilliant language but we want to use them to build good software." That's an arrogant, demeaning way to describe your colleagues but if they're LLM agents it's dead on! It's The Perfect Agentic Coding Language.
I could go on and on. I'm not immune either! My own favorite language is F# and when I feel like self-justifying, I play the same game:
It has access to the .NET ecosystem like C#, but I don't have to constantly remind the agents to prefer a style with immutable data and pure functions, they idiomatically do that in F#. Files have to be in order and can only refer to symbols defined "earlier" in order, if you want mutually-referential types or functions they have to be declared as such in a joint statement, so spaghetti is hard to create: each project's codebase naturally ends up in a layered bottom-to-top architecture. The language is terse enough to be token efficient, without being symbol soup. FSX scripts can be generated during agentic code reviews to demonstrate repros for discovered issues. If there's any type of code that still warrants me jumping in and writing some myself, that code would be data type definitions/domain modelling, and F# is a joy to write those in. It's The Perfect Agentic Coding Language.
If your favorite language before was Python, why, LLMs are fluent in it! So much training data! So many libraries! Home of machine learning! None of that pesky compile time, agents don't need compile time safety anyway, they write such good test coverage! It's The Perfect Agentic Coding Language.
If it was Rust, by jove, an agent can easily handle the headache of satisfying the borrow checker, and now you get the best of all worlds! Safety! Near-C runtime performance! Abstractions! The only reason people didn't use Rust before was it was Too Hard and there were Too Many Furries and now it's not hard and you don't have to interact with them, so get on board. It's The Perfect Agentic Coding Language.
If it was Golang, oh my goodness, what a choice. Pretty fast compile time and pretty fast runtime. Agents get a tight feedback loop with build->run->test->edit. Not very complicated, code has to be written in a straightforward banging-rocks-together way. Good stable ecosystem! Rob Pike designed the language for people he said were "not capable of understanding a brilliant language but we want to use them to build good software." That's an arrogant, demeaning way to describe your colleagues but if they're LLM agents it's dead on! It's The Perfect Agentic Coding Language.
I could go on and on. I'm not immune either! My own favorite language is F# and I play the same game:
It has access to the .NET ecosystem like C#, but I don't have to constantly remind the agents to prefer a style with immutable data and pure functions, they idiomatically do that in F#. Files have to be in order and can only refer to symbols defined "earlier" in order, if you want mutually-referential types or functions they have to be declared as such in a joint statement, so spaghetti is hard to create: each project's codebase naturally ends up in a layered bottom-to-top architecture. The language is terse enough to be token efficient, without being symbol soup. FSX scripts can be generated during agentic code reviews to demonstrate repros for discovered issues. If there's any type of code that still warrants me jumping in and writing some myself, that code would be data type definitions/domain modelling, and F# is a joy to write those in. It's The Perfect Agentic Coding Language.
For an example, see my MSPaint drawings in the README (scroll near the bottom) for this tiny little project: https://github.com/rspeele/meshorient
I redrew those for the README but IIRC, I drew something similar when explaining how the feature would work to the agent.
And in reverse, after describing an architecture or an algorithm to it, I'll sometimes ask it to draw a diagram for me to demonstrate its understanding. If it draws the picture in line with what I intended, I conclude that it has gained the necessary context to proceed. If not, I know I explained something wrong or at least insufficiently and need to provide clarification. There are some domains where a picture is worth a thousand words.
It also helps cut through the Claudese. "Your decision is needed for one edge case, found by the gate. When a T-joint meets an endcap that the mesher solves by a fan, should this bisect a fan slice or raise a warning?" I'm sorry Claude, I am not from Missouri but you are going to have to Show Me this one with a picture.
Of course you can save pictures to files and open them with external tools, but it's nicer to have them inlined into the chat history when that's exactly what they are: part of the conversation.
My biggest conclusion from this test was: the most efficient use of my weekly Astra budget is as a reviewer/consultant for work done by Opus. I don't have Astra write much code right now, but I do have it reading a lot of what Opus writes. Of course with the way the AI landscape shifts the balance could be the exact opposite 2 weeks from now, but either way having 2 "smart" models available from 2 different companies is a boon.
Seeing how each model preferred its own flavor of code shows that, even from a "blind" fresh context, a same-model reviewer will still often look at the work of another incarnation of itself and go "yep that's how I woulda done it" and not be as likely to realize that there was an alternative path or implicit assumption/mistake in the work.
Astra used 215% of a week's budget (I burned 2 free resets) and took 13 hours. Opus used 20% of a week's budget and took 20 hours. Both were asked to use lesser sub-agents for implementation grunt work at their discretion (Luna, Sonnet) as long as they manage and review the output.
The timing comparison is not that interesting because the wall-clock speed mostly reflects how often they ran the (large, slow) test suite, not their coding speed. Although in the past my gut feeling is that OpenAI models do generally respond faster.
The quality of their implementation was more interesting. There turned out to be a bug in one of the unit tests the agents were trying to pass. Opus interpreted the natural-language requirements from the task packet, found the test bug, and fixed it. Astra tried hard to solve the problem without altering the test suite. In practical terms Opus got much, much farther into a useful implementation. Astra was still stubbing out and faking critical parts of the implementation (B-splines) and since it ultimately couldn't pass the full test suite, finally gave up on its implementation. Astra wrote some useful tooling in the process of its efforts which I ended up integrating into Opus's version of the code, but otherwise its approach was behind.
Now, this is just one comparison in one domain, and arguably Astra's strict adherence to the tests as-given is a good thing. But Opus wasn't merely loosening the rules / moving the goalposts to pass, it spotted an actual bug, and was more successful at doing what I actually wanted. And the cost difference was Astra-nomical.
Out of curiosity for an interpretation free from my personal bias, I gave Astra a hint from Opus and permission to change the test in question, which it did, and got a bit farther, but still ultimately didn't produce a working implementation (to be fair, Opus's was not completely working either, but was closer). I then fired up fresh agents to review the two repos. Predictably, an Opus agent thought the Opus-written repo was the better basis to build on, and an Astra agent thought the Astra-written repo was the one to keep. They were not explicitly told which was which nor did the commit trailers say, but I assume they can tell. However, after doing this twice each, I saved the 4 review reports into another folder and did yet another meta-review of the 4 reports, so each would see the arguments and critiques both directions. In this meta-review both Astra and Opus converged on preferring the Opus implementation.
In no way does this mean LSP is a perfect solution, but anything synchronous would be a step backwards.
I still count myself as "dejected" overall. I'm dejected by the economic shape of AI which seems destined to keep concentrating outsized rewards to the top few who own it or have enough capital to shackle it to their will. I'm fearful that intelligence, once it becomes a commodity you can rent any time you may need it, will be socially devalued in our already anti-intellectual society. I worry that in a couple decades we may resemble the world of "The Machine Stops" (1909), where nobody really knows how things work.
Of course we already live in such a complex world, no one person has complete knowledge of the "stack" they rely on. I can write software in C or assembler but I can't design a CPU and don't really understand how one is manufactured. (I may someday study that field, but I haven't yet!) But I take solace in the fact that somebody out there, has put the time in to study each of those things and is an expert in them. At every layer and in every niche of our engineering world there are masters of their craft, and there are students learning the fundamentals to keep that knowledge alive and growing. What if in 30 or 40 years that is not the case, and there are whole corners of knowledge the modern world depends on where everybody is reduced to "I dunno how it works, but Claude said..."?
Reduce has an accumulator and a 2-arg function and languages are not very consistent amongst each other as to whether it's reduce(initial_acc, callback(acc, elem)) or reduce(callback(acc, elem), initial_acc) or reduce(callback(elem, acc), initial_acc) or what.
Hard to remember. Also some languages have a version of reduce that doesn't take an initial accumulator at all, which is just a footgun waiting for you to hit an empty collection. Also ALSO, the accumulator can easily become awkward in languages that don't support anonymous types or don't support easy mutation of an anonymous type record. Which is most of them!
[1]https://theonion.com/amazing-new-hyperbolic-chamber-greatest...
If Anthropic can absorb proprietary or GPL code into their models, which they rent usage of for tens of billions of dollars in revenue, and successfully claim that this violates no licenses, then I can also consider the output of those models "clean" for purposes of my software I give away for free.