The original idea probably came from T.S. Eliot who said "Immature poets imitate; mature poets steal." Imitation is surface level, but stealing here means to take inspiration and make it your own, transformation.
Would this be a defensible decision if the spec were designed today, an additional read method that takes the same argument, entirely for the purpose of not ignoring a specific property? It seems like just the path of least resistance considering all the controversy and legacy tools. That is not a good way to maintain the functionality and long-term relevance of a spec. But if there is a good reason to design it this way from the beginning, I'm curious to know more.
There are good arguments that if you were designing this from scratch it would still make sense to separate GET and QUERY. GET are things addressable purely by URI. QUERY are things that need HTML forms or JS to initiate (but optionally may return GET addressable URLs for future requests).
Similarly there are good arguments that if you were designing this from scratch it would make sense to still separate QUERY and POST. To some extent they mean very different things: "search" versus "create"/"do". Some of that is a modern expectation from years of mapping the common "CRUD" concepts to "REST": POST ~= Create; GET ~= Read; PUT ~= Update; DELETE == Delete. But that's a lens that's still useful in designing the thing from scratch even if it wasn't necessarily in mind when HTTP was first designed (especially given the different verbs in HTTP terminology).
My guess is that if you were building all of this from scratch, you would start with
- request-with-a-body
- idempotent-request-with-a-body
- safe-request-with-a-body
because the additional constraints induce properties that are extremely useful to general purpose clients ("I didn't get a reply to my idempotent-request-with-a-body, can I resend it without risking loss of property?")
Would someone then come along an introduce safe-request-without-a-body method? After all, we can already meet that "need" with safe-request-with-a-body and content-length: 0.
Think rfc-5789::PATCH - mechanically, it's just another request-with-a-body, but with more tightly constrained semantics. But general purpose components can take advantage of the additional properties, and so we introduce a "niche" method with tighter constraints.
Document resource manipulation is a common case, so we probably end up with a family of specialized methods, in much the same way that we have a bunch of WebDAV methods.
I really enjoyed this article because it happens to focus on a problem I'm knee-deep in at the moment, although I'm not ready to throw clustering out the window just yet.
There's a deeper issue which the author touches on, showing too much information on a map. This is possible independent of technology limits depending on what level of focus you wish each point to have. For many maps, showing a bunch of small points is an elegant solution, the map turns into more of a data visualization. But a bunch of points tells you very little about a particular thing. It is rich in aggregated information and poor in specific information.
If Google Maps just gave you a bunch of points instead of labels, it would be less functional. Every city would just be a large collection of points. Great, that might be interesting if you want to visualize how the locations are distributed in the region, but you are probably looking at the map because you want to find a particular thing.
Clustering is the natural choice: show the most important thing out of all the points in the area. A label is important, a big circle with a number in it is the worst out all the options discussed. My issue with Google Maps is that there is no visual indicator that there are other points there, and that seems to be largely driven by the fact that it is a marketing platform.
I'm working on a map that uses a hybrid approach. Each map has a narrow focus and is tied to a particular community/interest: concerts, bear sightings, hostels, food trucks, whatever you want. For each point of focus, there is a label and a thumbnail. Showing a bunch of these all in the same place is a bad user experience, so it ranks them and shows the most important one, and the thumbnail is replaced by a number indicating there are other points of focus in the vicinity. Users can click on the item to get a side panel that shows a listing of all the points.
There are also other points on the map that are secondary to its focus, public transportation vehicles and other location points that the user can filter. These are displayed as little dots, similar to the example that the author provides. If you zoom in far enough, they become more than just dots.
In designing the user experience, I tried to make it like a map experience that you might find in a strategy game. Each focus point is like a unit that will bring up more information in a side panel. If there is more than one unit there, show an overview of the units. It's a work in progress, but I'm happy with the result so far.
On some level, strangers are easier to connect with than people who are in your life more permanently, like neighbors. Maybe there are fewer expectations and more mutual curiosity. It seems backwards, but for dipping your toe into more personal connection, it is an easier path.
I have not noticed this, maybe because in my system instructions I asked it to push back rather than plow forward with what seems like a faulty assumption. Sometimes it is just because there is a lack of context or it is a trivial point and I just ignore it, and sometimes it is helpful and ends up being a timesaver. Sycophancy is a much bigger liability.
I think of the context window as a pot of soup that you add ingredients to between meals. If you have a relatively focused recipe and you are able to add only the ingredients you want, the soup stays good. If you or the agent add an ingredient that isn't fresh, it is going to be difficult to salvage and it is better to start over with a new pot.
It is not that agents can't function with a large context window, they can if that information generally has a desirable signal (like a large initial document or a well-focused session). Mistakes and the confusing signals that come out of fixing mistakes are why performance degrades. I start to trust the context window less not as a matter of size but the amount of friction we run into. The friction can be random but it is more often an issue with the path that I have us on.
It seems like there is a ready solution here, have an LLM review and filter pull requests from unknown sources before you read them. My understanding is there are semi-reliable ways to detect AI writing, maybe there is an analog for code. In any case, you can filter according to criteria you set. Analysis and bug-finding is where LLMs shine, much more than their ability to generate code.
I can understand wanting to minimize your interaction with LLMs, so this might not be an attractive solution. But it seems like a worthwhile feature to have on the platform level for people who would like to continue to accept pull requests without the frustration.
"AI-detectors" are still probabilistic and none of them are exactly stellar. (No, even Pangram. It still screws up on the regular, very badly.) And some of that includes calling real people's writing "AI-generated", which isn't acceptable for this task.
reply