Essentially correct, QUERY is safe, like GET, not merely idempotent, like PUT. Safety implies idempotence, but not vice versa.
Does “safe” here mean just “non-mutating”?
Readit Newssimonkagedal commented on Let go of StackOverflow; communities must take ownership ahelwer.ca/post/2025-11-2... · Posted by u/tensegrist
I don't know what TLA+ is, but thanks for an entertaining rant, and the excerpt from Heller's timeless book.
Took me a while to realize that it is an actual thing, rather than used as a placeholder (“three letter acronym”)
simonkagedal commented on Things I don't like in configuration languages medv.io/blog/things-i-don... · Posted by u/birdculture
Given that it's an essential/definitional issue, I would have preferred that the author at least showed awareness of the differences between languages intended for marking up text and languages intended to represent data in a structured way.
Back when XML was first being developed, I was really anticipating having a standardized, easier-to-implement successor to SGML (which was hampered by its complexity and by the cost of the ISO standard) in the text markup space. It was that disappointing it ended up filling the vacuum in the space of serialized representations for for structured data, then getting rejected when it wasn't quite as suitable for that as alternatives such as JSON.
Me too, I still think it's cool. But while indeed easier-to-implement compared to SGML, it could have been yet a bit simpler. :) I once attempted to write a conforming parser, I remember it being a _lot_ of work to even determine well-formedness.
simonkagedal commented on Things I don't like in configuration languages medv.io/blog/things-i-don... · Posted by u/birdculture
I think the author is probably aligning with "is" rather than "ought". So a language made this list if it IS being used as a configuration format, regardless of whether it OUGHT to be used as one.
Which is a way of deciding that makes sense given that I think the purpose of this article is "use my language instead". Getting lost in the weeds about each language's original design intent would bloat the article without meaningfully contributing to their thesis.
Ah, I was perhaps a bit unclear – I didn't mean to comment on whether certain languages made the list or not, I enjoyed the thorough walkthrough of languages being used for configuration.
I was more commenting on comments such as this one under Pkl:
> This is not a markup language. This is a full-blown programming language.
And under Nickel:
> Nice programming language. Not a markup language.
It's like he's saying "we should use markup languages for configuration, not programming languages", which I don't think he means.
simonkagedal commented on Things I don't like in configuration languages medv.io/blog/things-i-don... · Posted by u/birdculture
The author seems to be using "markup language" as a concept basically synonymous with a configuration language, or something that is not a programming language. A markup language is a language used to "mark up" text with formatting and structure. This may sound like a terminology nitpick, but I would argue the reason why for example XML is not a great configuration language is that it was designed to be something else – a markup language.
- Good automated tests which the coding agent can run. I love pytest for this - one of my projects has 1500 tests and Claude Code is really good at selectively executing just tests relevant to the change it is making, and then running the whole suite at the end
- Give them the ability to interactively test the code they are writing too. Notes on how to start a development server (for web projects) are useful, then you can have them use Playwright or curl to try things out
- I'm having great results from maintaining a GitHub issues collection for projects and pasting URLs to issues directly into Claude Code
- I actually don't think documentation is too important: LLMs can read the code a lot faster than you to figure out how to use it. I have comprehensive documentation across all of my projects but I don't think it's the helpful for the coding agents, though they are good at helping me spot if it needs updating.
- Linters, type checkers, auto-formatters - give coding agents helpful tools to run and they'll use them.
For the most part anything that makes a codebase easier for humans to maintain turns out to help agents as well.
Regarding documentation, I’d love to hear you take on creating the CLAUDE.md/AGENTS.md type of files using the tools themselves, typically via some /init command. I think Claude Code, Codex and Copilot CLI all have a similar thing.
Those often seem to generate a snapshot of the current state of the codebase that to me seem to be just begging to get out of date, often with references to specific files. I sometimes start out with them and remove a bunch of stuff, or I just start empty and add things as they appear to be needed.
What’s your strategy on these?
You could also just use a different time zone each day.
Yeah. There are many fun experiments one could do. Now I got this idea instead: what if it opened up on 07:39 PM on January 1st, but then the window moved forward 3 minutes and 56.7 seconds each day so that it was back on 07:39 PM a year later. That sounds like it would be extremely useless, but fun.
now i want to see a map with all timezones called EST but meaning something else in each one
It was a total brain fart though – I know what EST is and I know that my time zone is CET; just had some neurons misfiring!
I think it's a really cool idea. I signed up because I had a brain fart and thought that "EST" was "European Standard Time" (I was of course thinking of CET).
So yeah, the current window wouldn't work for me, but that's fine. Everything doesn't have to be for everyone. We all live in our bubbles anyway; creating artificial rules could actually be ways of creating new, unexpected interactions.
This being said – if you were to adjust the rules to accommodate more people, I don't think it should be "open from 7:39 to 10:39 in whatever your local time zone is", because that feels like it would just destroy the whole idea – that everyone is there at the _same_ time. Also, it would still exclude people who work evenings.
An alternative solution would be to have multiple windows. For example, if you have one starting at 7:39 PM EST and another one at 7:39 AM EST, there would be more chances that there is some time during the day for people around the globe to check in. Depending, of course, on many things: time zones, sleep habits, work schedule, ability to briefly slack off during work, etc. It would remain true to the idea while opening up for some more people. Just a thought.
I also think each window could be smaller, maybe like just one hour?
Would like to know how much they are optimizing for your pelican....