I've been spending the last couple months working on a Markdown-like lightweight document format. (Short pitch, it's like Markdown but with natural extension points built in and far less subtlety).
A huge part of my goal is to write a "spec" of the format. I want it to be good enough that users can legitimately file bugs against my primary implementation for not following the spec: it is the source of truth about the language.
So, of course, I find it really interesting to discuss the grey space of "shrug, maybe this is correct". This whole process has been driving me to (a) make the language itself resilient and permissive so that it has _some_ answer for nearly all documents and (b) to constrain the output of the system such that it throws away as much information as possible, enabling us to make claims about semantics more confidently.
I don't know if I'm going to succeed at all my goals. This is sort of a small project and definitely far simpler than, say, a web browser. At the same time, it's very hard to narrow in on what it is, really, that I want such a spec to say.
I think the point was that Claude’s output can be somewhat easily and compellingly measured using this technique and its kind of massive (and human attributed).
I'm not able to judge this for content, but it feels frustrating to read something so obviously Claude-authored as being written "by" Jude Gomila. It's interesting to see the (presumed correct) reduction in this bound and this presentation is pretty compelling. I learned a bit about the Polymath 15 project from this post and I enjoyed that a lot.
That said, I have no idea what contribution may have been done by Mr. Gomila or not. I don't know if I can ask him for more details. Even if he wrote the whole thing (and either has deeply internalized Claude's voice or had it edited and rewritten by an agent) it's difficult to believe that he's the sort of expert I'd expect of someone who had actually done all this work.
This is basically the same feeling I have about vibe code contributors.
So, maybe this is not quite a fair analogy but a lot of famous modern artists don't do a lot of the actual execution of their work. If Jeff Koons relies on a team of artisans and technicians to make a balloon dog, and if Dale Chihuly depends on a workshop of glass blowers to make a chandelier, and if Paul Cummins used a team of ceramicists to make poppies, what did the headlining artist contribute? Not everything, certainly, but also not nothing. Ideas, vision, feedback, guidance?
I think we're used to the idea in math of generally every idea coming from a specific contributing human. In code, maybe less so, but still we generally we find it useful to attribute at least _lines_ to who touched them last. But maybe, if Claude were just less annoying in the prose it made, and could better imitate an actual human, we'd be able to get used to the idea of humans claiming credit for something that the human guided the software to create?
I appreciate the connection to artists guiding their teams. I think that's a good analogy.
At the same time, when Koons or Chihuly or Cummins sign their work I do have that expectation that they guided the piece in a meaningful and material way or that the people who built it did it in such a way that owes lineage and authorization to the style Koons/Chihuly/Cummins developed. If I asked one of them about their work and it was clear that they had become so disconnected from it that they couldn't be seen as the authority on it, that they'd delegated that away, then I'd also feel them signing it had a mark of dishonesty about it.
To that end, I genuinely don't know Mr. Gomila's engagement here. Worse, it, to my ear, very clearly is written in a style that's extremely reminiscent of LLMs. In that way, it directly invokes that feeling of inauthenticity when he claims authorship.
This reminds me of academic writing there there's sometimes a convention in author lists that the first author(s) did more of the work and the last author(s) were the PIs and guides. This anchors the work amidst all the authors, at least loosely. I understand that if I want to ask a question about the details of the procedure I can reach out to the first author and if I'm trying to understand the larger research objectives of the lab I can investigate the last author.
Personally, I think I'd feel more comfortable with this piece if it were attributed in that style.
Or, again, if this is genuinely work done in the majority by Mr. Gomila and the writing feels LLM-derived for some other reason then it's merely an unfortunate side-effect of this writing register.
> Worse, it, to my ear, very clearly is written in a style that's extremely reminiscent of LLMs. In that way, it directly invokes that feeling of inauthenticity when he claims authorship.
I get that and also find the style annoying. But, e.g. when I wear a garment that was clearly machine sewn, sit on furniture made with powertools, look at a photo (where a mechanical process determined what pigments appear where, with what intensity), if I eat a taco whose tortilla was industrially rolled ... none of those things seems like a reason to challenge someone taking credit and responsibility for creating a thing, even if 250 years ago they would have had to engage in a much more onerous manual process to create something similar.
So what is it about writing that feels so inauthentic when the human delegates the word choice and sentence structure to a machine? Is it just cultural expectations, and we'll get used to it as LLMs exist longer?
I wonder if partly there's a feeling of disrespect on the part of the reader -- if the author couldn't be bothered to write every word, it's presumptuous to think that other people's time is less valuable and they should read word by word.
Cummins doesn't expect anyone to examine the details of every poppy; we look at the overall effect and maybe admire the detail on one or two flowers. Koons doesn't leave enough evidence of the individual welds for audiences to inspect them; that would destroy the effect. But the default way to consume a language based work is at the word level, and you can't just take in the gestalt in a moment, so the implied demands on attention are greater?
I think it’s because it’s reasonable to believe that the human author had no meaningful contribution. If he’d written “by Claude with direction from me” then I’d feel more comfortable. If he’d hand written in his own voice a methods section that laid out exactly how he prompted the LLM then I’d have no trouble digesting.
But to take ownership over words and thought in this way reads as nearly fraudulent to me.
He posted it. That’s some of the work you question. Presumably he queried the AI and led it in some way. That’s also work.
As far as the exact breakdown we will never know. But questioning the authorship in a way that leads us to believe that the author did nothing is wrong.
For one, the whole text would show up in Safari's Reader mode, so I can skip past the hilariously low UI density that AI-generated websites have these days. Before AI you'd have to go out of your way put that much CSS padding into Wordpress! If everyone's going to play Terence Tao, at least copy his stylesheet.
Increasingly, I've begun to think of LLMs as sources of really interesting random objects: large pieces of "reasonable thinking" conditioned on a task. It's not that these are correct, in general, but instead they're a concentrated form of random search where that "randomness" is very likely to follow plausible, human patterns.
You can toss it at a task with a suitable machine for transforming that raw material into action and it'll rattle through and sample "plausible human behavior" at that endpoint.
There are more clever ways to use it, but a general tool here is to upgrade any sort of stochastic search to use this new form of random sampling. It'll be way more efficient, properly conditioned, because it just won't visit implausible things nearly as often as competing random sources.
In short, simplify the design to make it more reasonable for multiple implementations to agree while also adding intentional extensibility points and a governance model that allows for dialects to form without fracturing the community.
Markdown is really interesting. For most readers and most writers it's dead simple and you just get the idea from a few examples or reading a short description. In practice, it's dozens of dialects (though 3 related ones dominate) and dozens more implementations. It's hard to write new, compatible implementations, so they tend to fracture.
(This may be less true with LLMs nowadays, but it might also be worse.)
Often, someone wants to write a Markdown variant because they wish it supported some new extension to help it mesh with the use case and tool they are envisioning. Each one of these is a new fracture.
My goal is a simple specification that's easy to reimplement that eliminates years of cruft and subtle complexity. I'm designing it to be simple and obvious to extend and building a governance model so that extensions can live together, grow, maybe even become mainstream all without ever breaking compatibility.
An assert statement requires that you specifically come up with a test case. Lean lets you verify for all possible cases. Infinity is not a problem.
It's similar to a type system in that regard. The same difference could be applied there (comparing a Python type assert). Types, however, generally only cover checks similar to "the shape of the data is X".
Lean is different in that its language for expressing properties is wide enough to express anything you can imagine. The bottleneck becomes accurately stating properties you'd like to enforce and, subsequently, discovering proofs of whether or not they're true.
Without having any opinion on whether or not the Bun team was meaningfully fuzzing their codebase... Andrew's claim was not about whether or not they were, it was noting that the story was different between what they claimed in conversation and what they stated in this article.
It's also a language of distancing from personal experience and honesty.
Not saying you're wrong. Professionalism is an important tool for maintaining professional relationships. Lack of professionalism is dangerous to the point where it is reasonable for certain kinds of societies to begin to shun people who don't engage with it.
And, at the same time, a certain amount of emotional honesty can be really important to share, too. And that includes some amount of judgement and criticism.
It sounds like Zig's relationship with Bun is over. While Anthropic/Jason/Bun did not write a personal narrative about the end of that relationship, they absolutely were the initiators and could not have done this in a more aggressive way. It feels to me to be approximately the equivalent of moving out in secret and serving the divorce documents through your lawyer.
1) If he wants to rant in an emotionally honest way, he can, but other people are free to prefer professionalism and call him out.
2) > It sounds like Zig's relationship with Bun is over. While Anthropic/Jason/Bun did not write a personal narrative about the end of that relationship, they absolutely were the initiators and could not have done this in a more aggressive way. It feels to me to be approximately the equivalent of moving out in secret and serving the divorce documents through your lawyer.
What a bizarre framing of the relationship between a software library and the language it's written in. Why would you even liken it to a marriage lolwtf
I think you've got it. You go in each day and work on things and talk with people working on things. There are multiple opportunities to share weekly, one or two are pretty regular and the rest are self-organized. Maybe you learn about something new and dive in, maybe you come up with a project and share it with others.
I think the beating heart is that everyone is there with some passion to learn and build and you're encouraged to do so collaboratively. It's surprising, I feel, how rare it is to have a community of folks who are all learning together and not afraid to dive in and figure things out. Recurse Center is a chance to spend 6 or 12 weeks building and then living in a place like that.
I'm working on an easy-to-embed typed language called Ekto. I am taking a lot of inspiration from Koka and aiming to support full multi-shot delimited continuations all while keeping the virtual machine deeply predictable from the host side.
I'm also rebuilding an integrated task/knowledge/publication system I'd previously built atop Gemini's Gemtext format. While I loved the simplicity, I've discovered that there are lots of burrs in that design, especially on the publication side, which I'd be able to lift by using a more fully featured document format like Djot.
A huge part of my goal is to write a "spec" of the format. I want it to be good enough that users can legitimately file bugs against my primary implementation for not following the spec: it is the source of truth about the language.
So, of course, I find it really interesting to discuss the grey space of "shrug, maybe this is correct". This whole process has been driving me to (a) make the language itself resilient and permissive so that it has _some_ answer for nearly all documents and (b) to constrain the output of the system such that it throws away as much information as possible, enabling us to make claims about semantics more confidently.
I don't know if I'm going to succeed at all my goals. This is sort of a small project and definitely far simpler than, say, a web browser. At the same time, it's very hard to narrow in on what it is, really, that I want such a spec to say.
reply