If agents can generate text so easily, why would they be limited to Markdown instead of reStructuredText, AsciiDoc, or LaTeX which have rich features that help users understand text? I can understand developers refusing to adopt proper formats for documentation, but this seems odd for the bots. It doesn’t even generate the correct syntax block in Markdown using “bash” instead of “sh-session”.
MS GitHub can not only render rST & AsciiDoc (albeit pretty poorly since they the CSS is bad), but it also is employing its own fork of Markdown that isn’t compatible with other forks. “Just Markdown”, like the base spec, is so feature poor that everyone has their own incompatible fork which don’t make it render properly.
console/shell-session/sh-session (parsers call them different names) are for shell sessions, terminal sessions. Bash syntax is for Bash scripts, & these aren’t scripts but something you run in your terminal session.
I'm not convinced Markdown's various flaws matter for the way I'm using it here.
I want a simple, widely-enough supported format for mixing text, code samples and images. The non-standard (because what even is a standard when Markdown is in play?) subset of Markdown I've picked for this project works fine for what I need in Showboat.
If it turns out to need more I can expand the format in the future - likely though embedding YAML in frontmatter but I could add sidecar JSON files instead if that proves to be more robust.
I dunno. I’ve written a bit of LaTeX but does it really shine in this context? IMO the real advantage it has is that it can allow the user to express more complicated intents than Markdown (weird phrasing—my natural instinct was to call LaTeX more precise than Markdown, but Markdown is pretty precise for describing the type of file that it is good at…).
Anyway LLMs don’t have underlying intent so maybe it is fine to just let them express what they can in Markdown?
I think its primarily because that is the most common formatting in every editor now? I could be wrong. Markdown has become the standard for README files for over a decade now.
Winning a popularity contest doesn’t mean it’s good. That is the worst part of about these things as they just generate the most common denominator type code/tooling while also repeating anti-patterns/mistakes like the bash vs. sh-session/console issue I pointed out. Garbage in has been so much garbage out unfortunately.
Never said it was good, just making an observation that Markdown is most likely to be available to render OOTB in more editors. I don't think Markdown is bad necessarily either. It's "good enough" for simple document.
Documentation isn’t as simple document. There are tons of rich elements missing from the spec specifically for documentation… which is why so many resort to adopting one of the many incompatible forks of Markdown to try to get features that were missing (but are a part of reStructuredText & AsciiDoc for instance). That has a real tradeoff since these forks are not going to be compatible & they aren’t going to be as well defined as the specs for these richer lightweight markup syntax choices.
Being snapshot-based. Git has some issues being distributed in practice since the patch order matter which means you basically need to have some centralized authoritative server in most cases with more than 2 folks to resolve the order of patches for meaningful uses as the hash is used in so many contexts.
That's... literally what a merge collision is. The tooling for that predates git by decades. The solutions are all varying levels of non-trivial and involve tradeoffs, but none of them require 24/7 cloud service availability.
It’s weird being literate enough in a language now without a bicameral script (or spaces). When I was younger, I thought this stuff wasn’t so important, but then when you learn a new language, you are trying to figure out what a “robert” is, to then be told “oh, it’s just a name”—which is obvious if know standard `en-Latn` conventions.
A contributor sent me a fix for the Darwin build as I don’t own any machine of this architecture & cannot test. It’s merged into Nixpkgs unstable.
I have tried a lot of technologies & chose the ones I like for on their own merits without following ‘trends’ as they should be used more.
Darcs predates Git & does a lot of things better than Git (plus I want to dog food supporting it); Pijul does great things too! If Nixpkgs has fetchers + prefetchers, there should be a tool that can support users not supported by the builtins (which is only URLs, archives, Git, & Mercurial). Hopefully we can get the Fossil prefetch script merged too for support. Supporting these alternatives is a part of the premise. Flakes can never support this—& they do not seem to want to accept any fetchers despite a few attempts due to the maintenance burden.
XMPP is a reliable, lightweight, decentralized messaging platform commonly, but not exclusively, used for chat. It offers more features than IRC & runs using 10x less resources compared to something like Matrix so I can in good faith recommend self-hosting your own node. I would like to set up an IRC gateway that works at some point, & if ProcessOne adds fuller gateway support to Ejabberd for the MUC, I will enable it despite not caring for Matrix. There definitely isn’t going to be any Discord option.
Location: Thailand (UTC +7), but night owl
Remote: Yes
Willing to relocate: No, but can travel on occasion
Technologies: Nix, but also any functional or scripting language
Résumé/CV: https://toast.al/skills/
Email: toastal posteo net
I have been doing software for 16 years now. I want to transition from front-end & work with Nix & its ecosystem which I have spent a lot of time contributing to in the last 3 years. I hav written tools, packages, modules, hosted servers & even given talks/lectures on Nix.
It allows Microsoft to collect the traffic data. Generally it also implies the code is also hosted on Microsoft GitHub—which requires an account, accepting ToS, training the Copilot models by interacting with the platform.
reply