Useful applications of polyglot files that would unironically be good to see people adopt:
- JS-based build scripts being replaced with HTML/plaintext polyglot files that serve as both the README and the build script and that run in the universal runtime (the browser) rather than requiring e.g. NodeJS; alternatively
- JS/JS polyglot files that you can run with NodeJS if you so choose but that have first-class support for the browser instead
- JSON/HTML+JS polyglot files that parse as valid JSON but that you save with a .htm(l) extension and provide an advanced browser-based viewer for the data encoded in the JSON (especially typed data, e.g. JSON-LD)
mananaysiempre · 1d ago
I once encountered a podcast’s Atom feed that included an <?xml-stylesheet ?> reference to an XSLT stylesheet, so when opened in a browser the feed became a decently laid out list of episodes, complete with <audio> tags to listen to them in place. And there’s nothing even the slightest bit hackish about it, in contrast to the usual polyglots like the one in TFA, but somehow it had never occurred to me that you could do that. Your reference to JSON-LD feels similar.
(In general, XML stylesheets leave me conflicted. It’s a nice idea, in principle, but I do not really see a way it could fit into a frontend with more than the slightest amount of interactivity. Also, I’ve lived through the absolute misery that was rebuilding the hefty Nixpkgs manual on every system update using the—quadratic—DocBook stylesheets, and I don’t want to go back to that.)
fallat · 1d ago
Wow these are really cool ideas.
No comments yet
dhash · 1d ago
I love the vibe of squishing formats together — like APE.
I’ve had this problem in the past (shudders in Bazel’s WORKSPACE file) and what eventually ended up saving my bacon was org-babel.
Yes, it does mean that emacs is a build-dependency, but honestly literate programming pretty excellent for untangling the complexities of a large build.
Hmm...It seems that humans should be less interested in such things? Making Makefiles readable by human is less needed in the context of LLMs needs to know about it more than us no?
b33j0r · 23h ago
If that were true, LLMs wouldn’t have been invented to compute to and from structured language.
- JS-based build scripts being replaced with HTML/plaintext polyglot files that serve as both the README and the build script and that run in the universal runtime (the browser) rather than requiring e.g. NodeJS; alternatively
- JS/JS polyglot files that you can run with NodeJS if you so choose but that have first-class support for the browser instead
- JSON/HTML+JS polyglot files that parse as valid JSON but that you save with a .htm(l) extension and provide an advanced browser-based viewer for the data encoded in the JSON (especially typed data, e.g. JSON-LD)
(In general, XML stylesheets leave me conflicted. It’s a nice idea, in principle, but I do not really see a way it could fit into a frontend with more than the slightest amount of interactivity. Also, I’ve lived through the absolute misery that was rebuilding the hefty Nixpkgs manual on every system update using the—quadratic—DocBook stylesheets, and I don’t want to go back to that.)
No comments yet
I’ve had this problem in the past (shudders in Bazel’s WORKSPACE file) and what eventually ended up saving my bacon was org-babel.
Yes, it does mean that emacs is a build-dependency, but honestly literate programming pretty excellent for untangling the complexities of a large build.
They’d just be plain-ol LMs