phlakaton

1. The global temperature has never in human history done what it's doing now. 2. Weather isn't the same as climate. They operate on way different scales and timelines. Uncertainty in the one does not necessarily map to uncertainty in the other. 3. Climate change is most definitely not a solved problem. We know some big things we can do, and none of them are easy.

For those who read this title as being about Dr. Bill Bruford, the legendary English jazz-rock drummer, this here can be our little bemused happy place.

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.