One commenter on Lobste.rs pointed out that the "make X Y again" can
have political connotations. That was not the intent, and I don't want
to scare people away with that.
I brainstormed several options, in the end this one captures the same
spirit ("boring", it should not create problems or cause surprises, it
should not feel like solving puzzles, building things is exciting,
configuring them should be boring), and even makes the goal a bit
clearer by hinting at the remove-duplication part.
It *is* pre-1.0 and it *does* occasionally have backwards-incompatible
changes, but they are well documented with clear upgrade paths, and not
happening at a breakneck pace. For example, with the introduction of
unpack, the |-operator is deprecated, but it still works. Or take the
assertion syntax: it changed, but the old syntax is still accepted, and
the autoformatter automatically upgrades documents. So I think that the
previous phrase was a bit too conservative. Other "mature" projects
cause me breakage headaches far more often than RCL. The readme should
reflect that.
Now that I added this "Playground" link, it doesn't fit on one line any
more on mobile. Maybe it needs a hamburger menu but that also doesn't
make that much sense with so few items. For now, I am very sorry
Codeberg, but probably fewer people click that link than people who want
the GitHub repo. The Codeberg repo is still linked further down.
RCL is now truly -- for all practical purposes, yeah yeah pedantics
surrogate pairs and a file with 20 GiB of zeros are technically valid
json but let's talk about documents used in the real world -- a json
superset!
Also I think I should try to make the readme and index pages a bit more
attractive to people who discover this. I wrote them from my niche
perspective and I had a lot of background about what I was building, but
probably it needs to be explained more to new users.
Also improve a few other things, e.g. as a quick hack, add a
"Playground" link in the website header to make the feature more
discoverable. We can extract it into a separate page at a later stage.
I originally developed the website in a separate Git repository, but to
keep them in sync, and also to be able to accept contributions, it is
nicer to have them in the same repository. Merge the histories using a
subtree merge.
