phlakaton

45 years earlier in some cases. I found the Robie House in Chicago (built in 1910!) to be a total head-trip.

None of the billionaires got that way by throwing money at egg studies. Bold to think they'd just start doing it now.

Insurance companies don't fund medical research AFAIK? But if they did, it would be coming out of your premiums.

The US Government is not a reliable source of research or funding these days.

Universities are generally looking for subjects that will further their prestige and expand the frontiers as they understand them. This isn't that. And they, too, have funding issues, tracing in many ways right back to the government.

Space is not a hedge against these things. At best it's our final tomb.

There is no backup plan.

Then your issue is not the S&P methodology, which despite changes in detail remains, as you've said, aimed at filtering out undesirable companies from the index. Your issue is that you want us to believe your favorite tech stocks, which are both wildly unprofitable and have P:S ratios that defy rational investment, are somehow desirable immediate additions to the index. And your argument for why this should be is a lofty claim that "the market environment has changed."

You believe in brand power over numbers. Which is your prerogative. But it's not how the S&P is managed.

Because it's selective, the S&P by definition does not reflect the actual market. It reflects a subset of it.

If you're comfortable with this notion of what the S&P does, then you ought to be comfortable with S&P applying the same methodology they've always used. There are other indexes you can reference if this particular sampling of the market isn't to your personal liking.

Because the index needs accuracy.

No, it doesn't. At least, not the way you are probably defining it.

This sounds to me like you may be trying to use the index for something it's not really meant to be used for.

A business that can bring in a steady $2.5B a year doesn't seem like a bad business to me, so long as they can turn that into a profit. I think there ought to be a recognized place in the ecosystem for this sort of thing, and for me their independence from the gigacorps is a major feature.

I thought the AI art was okay, actually! For AI art.

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.

Haven't read the book, but points two and three definitely struck some bells in the back clocktowers of my mind.

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.

Mostly when presented disagreeably. You might reflect upon that.

I've been here longer than you, buddy. I think you're the one that needs to leave.

But you cannot predict a priori what that deterministic output will be – and in a real-life situation you will not be operating in deterministic conditions.

This bug is categorically distinct from hallucinations.

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.

I think it might be a bad thing. I'm no stranger to math or computer science, but even after staring at the front page for a minute I was ready to dismiss this as the ravings of a lunatic.

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.

Hah! XML strikes again. :-)

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

1. The Register reports OpenAI is well ahead of Anthropic in B2B contracts. It's Anthropic playing catch-up, not OpenAI.

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.

I hope OpenAI realizes they cannot buy developer goodwill.

I went to a James Gosling talk where he excoriated the Emacs users in his audience for clinging to outdated technology and not using a state-of-the-art IDE.

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

As a Mayflower descendant I would scarcely say that. But the fact that you offer cheap platitudes and tales from hundreds of years ago to justify why it's OK to consider why the current bombing and slaughter is good for our work-life balance remains astonishingly tone-deaf. This is absolutely a you problem.

There's no lemonade to be found here at this time. What there is to be found are a bunch of tone-deaf people who seem utterly ignorant and indifferent to the war's reality.

Please do not use the occasion of the death of thousands of Iranians in a war we launched against them as some sort of illustrative point about return to office and birth rates in the West.

1. I don't disagree that attributes have been abused – so have elements – but you yourself identified the right way to use them. Yes, you can inline attributes, but that also leads to a document that's harder to use in some cases. So long as you use them judiciously, it's fine. In actual text markup cases, they're indispensable, as HTML illustrates.

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.

I disagree on several points here:

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.

By "parses well" in that case I mean "can identify where the error is, and maybe even infer the missing closing tag if desirable;" i.e. error reporting and recovery.

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.)

Depends on the application, I suppose. For OP's application, pulling in XML is no trouble and gives you a much better solution for typed unions.

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.

Aesthetically, I consider such JSON structures degenerate. It's akin to building a ECMAScript app where every class and structure is only allowed to have one member.

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

For this application, where you might have a lot of authors and apps working with the rule data, I think schema-based validation at some level is going to be a must if you don't want to end in sorrow.

LOL, I chose a Google Sheet and CSV for my current project, and I'm very serious about it. It's a short-term solution, and it fits my needs perfectly.

I unfortunately disagree that your syntax is "stupid-simple." But it highlights an impedance mismatch between XML users and JSON users.

JSON treats text as one of several equally-supported datatypes, and quotes all strings. Great if your data is heavily structured, and text is short and mixed with other types of data. Awful if your data is text.

XML and other SGML apps put the text first and foremost. Anything that's not text needs to be tagged, maybe with an attribute to indicate the intended type. It's annoying to express lots of structured, short-valued data. But it's simple and easy for text markup where the text predominates.

CSTML at first glance seems to fall into the JSON camp. Quoting every string literal makes plenty of sense in JSON, but not in the HTML/text-markup world you seem to want to play in.

I don't dislike the decision at all, FWIW! For data interchange it's totally reasonable. But it does make JSON ill-suited for a bunch of applications that JSON has been forcefully and unfortunately applied to.