For me it's contextual. In the case of engineering presentations in particular, I'll live with some AI art if it means less reading off of fifteen-bullet-point wall-to-wall text slides. But I always prefer and appreciate non-AI art – even stock art, if employed judiciously.

If, say, a consultant or outside speaker brings in a dripping-with-AI-art slide deck to talk about AI – now that I consider the height of cringe.

More generally, reading a bit of Orwell was inescapable in my schooling, but I sought out 1984 myself. I discovered I had kind of a thing for both utopias and dystopias.

And as I contemplate things I might write or compose, I do note that outrage towards this regime is very much in the mix of my motivations.

Is it?

> after using it for months you get a ‘feel’ for what kind of mistakes it makes, when to watch it more closely, when to give it more permissions or a longer leash.

Do you really?

> This class of bug seems to be in the harness, not in the model itself.

I think people are using the term "harness" too indiscriminately. What do you mean by harness in this case? Just Claude Code, or...?

> It’s somehow labelling internal reasoning messages as coming from the user, which is why the model is so confident that “No, you said that.”

How do you know? Because it looks to me like it could be a straightforward hallucination, compounded by the agent deciding it was OK to take a shortcut that you really wish it hadn't.

For me, this category of error is expected, and I question whether your months of experience have really given you the knowledge about LLM behavior that you think it has. You have to remember at all times that you are dealing with an unpredictable system, and a context that, at least from my black-box perspective, is essentially flat.

It's like they had the idea of marketing this like a software project, not realizing that most front pages of software projects are utter bunk as well. It introduces terminology and syntax with no motivation or explanation.

Even once trying to get into "Quick Start" and "Specification" I was still mystified as to what it is or why I should want to play with it, or care. I had to go to the link mentioned upthread to get any sense of what this was or how it worked.

I think it's just badly written.

That being said, what seems to be proposed is a structure and calculus that are an alternative to lambda-calculus. The structures, as you can probably guess from the picture, are binary trees, ostensibly unlabeled except that there is significance to the ordering of the children. The calculus appears to be rules about how trees can be "reduced", and there is where the analogy to lambda calculus comes in.

Hopefully someone who actually knows this stuff can see whether I managed to get all that right – because I promise you, none of that understanding came from the website.

I understand that Spain was a participant in LexML as well... I gather they've since converted to something else?

2. In any case, the announcement strongly suggests that customer acquisition had little to do with this. The stated purpose of the acquisition, as I read it, is an acquisition (plus acquihire?) to bolster their Codex product.

3. But if they were hoping for some developer goodwill as a secondary effect... well, see my note above.

But the IDE he was hawking wasn't Eclipse. I think it was Sun Studio.

2. As far as JSON Schema, you're wrong on all acounts – wrong that I haven't seen Some Stuff, wrong that JSON schema doesn't get used (see Swagger/OpenAPI), and wrong that XML Schema doesn't also get underitilized when a group of developers get lackadaisical.

3. As far as what historical use has been, I'm less interested in exhuming historical practice than simply observing which of the many use cases over the last 20 years worked well (and still work) and which didn't. The answer isn't that none of them worked, and it certainly isn't that XML users had a better bead on how to use it 20 years ago – it went through a massive hype curve just like a lot of techs do.

4. Regarding tabular data exchange, I stand by my statement. Use XML or JSON if you must, and sometimes you must, but there are better tools for the job.

1. I think attributes absolutely should exist. They're great for describing metadata related to the tag: e.g. element ID, language, datatype, source annotation, namespacing. They add little in complexity.

2. The point of a close tag with a name is to make it unambiguous what it's trying to close off.

It sounds to me like what you want is not a better XML, but just s-exprs. Which is fine, but not quite solving the same problem.

3. As far as schema support, it seems to me that JSON Schema is well-established and perfectly cromulent – so much so that YAML authors are trying to use it to validate their stuff (the poor bastards) – and XML schema validation, while robust, is a complex and fragmented landscape around DTD, XSD, RELAX-NG, and Schematron. So although XML might have the edge, it's a more nuanced picture than XML proponents are claiming.

4. As far as tabular data, neither XML nor JSON were built for efficient tabular data representation, so it shouldn't be a surprise that they're clunky at this. Use the right tool for the job.

If you've ever debugged a JSON parse error where the location of the error was the very end of a large document, and you're not sure where the missing bracket was, you'll know what I mean. (S-exprs have similar problems, BTW; LISPers rely on their editors so as not to come to grief, and things still sometimes go pear-shaped.)

To get better than XML, I think you're looking at something closer to a Haskell- or LISP-embedded DSL, with obvious trade-offs when it comes to developer ecosystems and interoperability.

If you want tagged data, why not just pick a representation that does that?