No, it doesn't just mean that (it does mean non-mutating from the point of view of the client and in regard to the target resource, but the essential meaning involves more than that and it is more subtle than simply “non-mutating”.)
The specific definition is in the HTTP spec, and I don't think I can describe it more concisely without losing important information necessary for really understanding it.
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.
XML is a fantastic configuration language. Its primary purpose is text markup, right, but it can really shine as a configuration language too. It is meant to be used as a language, that is to describe structures of unbounded complexity while keeping them syntactically constrained.
The best configuration language is the one that is custom made for a specific application. A domain-specific language. But DSLs requires a parser and adding one is usually too cumbersome to merely parse a configuration. This is where XML comes in.
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.
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.
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.
I’ve often wondered the same. The op doesn’t go far beyond:
> The era of XML is in the past.
Which is about as deep as it seems to get.
My suspicion is that the reason people don’t like it is because it’s a bit of a pain to work with in JavaScript
More generally XML is so thoroughly out of fashion that it is perceived as driving resume-driven architecture backwards in time, into an unfamiliar "dark age" of deliberate engineering decisions.
XML has a DOM API. And most people use JavaScript in a browser to manipulate the DOM. So I would say among all the language it should be the JavaScript devs that are the most proficient at the DOM API.
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.
I have to admit I don't actually use those yet - I've been enjoying learning how to succinctly prompt in a way that gets the right results without them.
I've experimented with having LLMs write snippets for them - things like "Based on this session, update AGENTS.md with notes about running the tests" - but my stuff tends to be simple enough that I can just say "Run tests with pytest" and it will know what to do.
I did just confirm that you can use efficiently both AGENTS.md and CLAUDE.md in the same repo by having a CLAUDE.md with a single line:
My issue with that is that I don't really have any Python tooling installed globally (old trauma with overlapping package versions), each project is in an uv venv.
So every time an LLM starts firing blind they'll go python -> python3 -> damnit -> uv run python, wasting precious tokens.
That's why I have explicit instructions on how to use uv to manage things in AGENTS.md
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?
> 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.
I like the idea that something like this could be open for 3 hours in the evening local time. Like, you'd get totally different communities coming on at different times, and having completely separate experiences together. But some other people would bridge the gap.
While you're online, every hour some people would be forced to leave and some other people could join.
A moving window would be just like what you already get with somewhat global communities. E.g. hn while Europe and Africa is mostly sleeping vs hn while the Americas are mostly sleeping. As I understand it, seven39 is not so much about only being allowed to chime in during a specific time window, but about it being offline outside that window. You could have multiple instances from date line to date line, but they'd have separate content and user identities (even if some people might have accounts in different timezones).
What I really don't get, it completely blows my mind: why hasn't this concept been completely chewed through, explored to hell and back, back in the days when everybody and their dog tried to invent some new variation of social media website (and get bought up by Yahoo when they ran out of runway or grew tired of it)? Age of the yo app? Feels almost as if the convertible wasn't invented before 100 years after the automobile.
I think that what sets this type of apart is its position as a response to the fatigue people feel from social media in its current form. I don't think something like this would have resonated as much when social media was in its infancy.
True. Also in the very old days, people actively "went online" at certain times. Dial in the modem, visit the Internet Cafe, things like that. A web community would better be ready and waiting.
But then on the other hand, there have been a few years between that time and the present...
It was always a small source of joy on Discord to see Americans getting on the server while East Asians would go to sleep, with us Europeans being in the middle. It always feels so cute for some reason I can't explain, but I do love that every time.
Back in late 1990s I had xplanet-rendered sun-synchronous rotating Earth as my desktop background. It had the nicknames of our IRC channel regulars placed at their lat/long… it felt cyberpunk af.
This happens on Reddit- you'll make a comment that makes sense to Europeans or Asians, and it gets n upvotes. Then America wakes up and all of a sudden it gets n downvotes.
It's especially interesting in local expat communities: in Asia local time, you'll make a comment that is the ground truth and it gets n upvotes from locals and other foreigners in-country. But then the children of immigrants in America who are associated with that country wake up, and suddenly 8 hours later you're a monster.
> But then the children of immigrants in America who are associated with that country wake up, and suddenly 8 hours later you're a monster.
Mostly what this immigrant effect has produced in America is a bunch of movies about how the writer of the movie hates their mother. (EEATO, Turning Red, etc.)
But a funny one I've repeatedly noticed in West Coast Japanese-Americans is they have West Coast progressive political beliefs (basically, noone should ever be punished for crimes because it's mean) at the same time as Japanese ones (copyright violation or disrespecting important big companies should get the death penalty), and I don't think they've noticed.
This happened to me in Twitter a lot of times (back when it was good). I’ve seen different parts of my time wake up at different times – a very peculiar effect.
Pretty much every day that I comment on HN, at least a couple of the comments I write get to +3 or so by the end of the day, and then in the middle of the night they're at +1 or 0. Consistently. I assume it's this.
One approach might be to have many instances, like we do with Discord etc, and have the admins choose a timezone, so an instance for French people would be on Paris time, etc.
Or even just choose the start of the time range directly. French joggers might prefer a different time to French Counter-Strike players.
A complete opposite approach: same instance for everybody, but you can choose the hours when you sign up. Changing is allowed once every 4 weeks or something.
Another idea is that the window drifts slowly, so everyone gets an optimal time. Make the period non divisible by 7 so it doesn't line up on the same day of week every time.
The user can choose their time zone when they sign up, and the service can prevent them from changing it (or heavily limit how often it can be changed)
The sibling comments are a perfect demonstration why projects tend to balloon in complexity and ever-increasing requirements just to deal with rare corner cases.
YAGNI. A niche tool whose selling feature is time-restricted usage shouldn't have to account for weirdos that miss the point of it and cheat with their clock.
They could be allowed to interact but only with a delay that caches interactions until the next window. If I post at 8pm my time, it should wait until 8pm your time to make it appear on your instance.
One simple script that automatically connects to your account on the current time frame's server and unifies all into a single timeline will kill the fun.
Or, have N available 3 hour windows, and if you've interacted (viewed the website/posted) in any way with the website during one of those periods, you cannot use the other periods for that day.
So basically the same idea, but letting the decision be more dynamic.
CST and BST are a couple of common ones with overloads. Use the ISO standard for your time stamps guys. I have to work with one API that uses these ambiguous abbreviations in a key time stamp field (faceplam).
The “real” EST means “Eastern Standard Time”. The top commenter thought it was “European Standard Time” which could for instance be equivalent to WET (“Western European Time”). What your parent comment is suggesting is a joke to come up with other definitions which would fit EST to other time zones. E.g. MST (“Mountain Standard Time”) could be EST (“Eagle Summer Time”).
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.
> Instead of googling for the site, I google for the site's Wikipedia article
This seems like a bit of unfortunate wording – there does not seem to be a Google search involved, just a search directly on Wikipedia (the English version).
Yeah, I might use “googling” to mean generic web search in everyday language, but I wouldn’t use it to refer to a site’s internal search function, and I wouldn’t use it at all in a technical description of some software.
I understood that statement as an example of author's workflow before the existance of this addon, as in instead of googling for the site directly, he would rather google for the Wikipedia's article of the site and find the correct URL there.
reply