lightningspirit

I'm so happy with this! Thank you so much.

Good to know you're still building your own tools like back in the "old days" :)

And then everybody left, yeah, I remember this exactly.

I think we're comparing two very different categories. COBOL is an application language, whereas TCP and HTTP are foundational infrastructure. Replacing a language is challenging, but replacing the infrastructure that underpins most of the Internet is orders of magnitude more complex due to the sheer number of interoperating systems.

HTTP accounts for roughly 70-80% of global web traffic, and if you narrow it to TCP-based application traffic, its dominance is closer to 95%. Comparing HTTP to COBOL is a bit like comparing trucks to bicycles...

> {"a":1,"b":2} and {"b":2,"a":1} are the same query and two different cache entries

These two payloads are actually different. You're talking about semantics, which is determined by the payload format; in the case of JSON, these two are semantically similar.

> GET gets this for free because the URL is already a normalized string

It's the same principle; the order of properties matters too.

This is controlled by the (Last-Modified, If-Modified-Since) and (ETag, If-None-Match) header pairs. HTTP is stateless; it does not require any persistence. The only thing that defines kind of an optional persistence is the caching layer, for obvious reasons.

How does the origin server indicate that?

I don't think this requires so much discussion; it is a very obvious and simple addition, IMO.

How does this break rest?

It won't break GraphQL, as it uses POST. It can very much improve it if adopted: - use QUERY method when querying resources - use POST method for mutations

Because HTTP is stateless by definition, you now need to support persistence (state) on the server side whenever you want to run a slightly different query, which contradicts the preamble.

I understand the confusion around GraphQL's cached/persisted queries, but this is not the intention of HTTP.

The internet is complex, and you have tons of protocols that are not well supported. TCP/HTTP are well supported by proxies and have well-defined, stable specs, which also help with caching, throttling, etc.

Just because it's old doesn't mean it is worse than alternatives, most likely it is quite the contrary.

I think most of the value LLMs provide comes from connecting the dots between unsolved questions and patterns or structures that have already been demonstrated, which accelerates research.

Now, reasoning in the sense of making truly original discoveries, as Einstein did with the field equations, is a different story for current LLMs.

Yeah, I was surprised by that as well.