This may be the first time my reaction to an objectively terrible programming language is a shrug and a "whatever". I like using markdown. I use it for journaling in Obsidian. It does everything I want it to. I like that it's just flat files. I don't want my journaling to be stuck in some online database.
Yet, I am the same person who refuses to code in anything but Rust due to how not-awful it feels to me. Strange how a person can hold a completely opposite view for two instances of the same problem. Being human in a nutshell.
This is just like the debate over YAML. In both cases, the language is simple enough, and people use it sanely enough in practice that I just don't care about the warts. Contrast this with something like C++, where the warts are less avoidable and therefore more worthy of notice. Markdown as I use it is functional and simple and no one has suggested an alternative I like better, so I keep using it.
Also, as I use it, Markdown is effectively plain text. I very rarely look at "rendered" markdown. I guess in practice I actually use "plain text" that just happens to look a lot like markdown by this article's definitions.
We want to encourage people to produce written output with minimal friction. Barriers to writing--and especially barriers to producing documentation--should be minimized. Writing well is difficult enough!
Markup is overhead. Complex markup is even more overhead. Markdown is the best compromise we know of today that provides just enough structure and typographic capability, while imposing very little cognitive load on the author.
Besides, if you need something more complicated these days, you can have your favorite AI agent do it.
It's also worth remembering that markdown tried very hard to encode conventions that were already used in Usenet, email, and other text media. A > to indicate a quote was widespread Usenet convention. Asterisks or underscores to indicate emphasis was also a common convention; both are legal because both were common. Double asterisk or double underscores to indicate really, really emphasizing something was also a common convention. So were asterisks to display a bulleted list, blank lines to separate paragraphs, and indenting 4+ spaces to write code.
It's a good example of "pave the path" design philosophy, where you do what users are already doing rather than trying to impose some platonic ideal of what the world should be like. And it works quite well at that.
Stepped right on the rake though because it uses sigils which were common, but requires they be used in uncommon ways (by doubling etc) which it why most chat UIs don't actually use markdown
Your quotation and list syntax should work out of the box in most Markdown flavors (HN has a very non-standard and crippled version - basically nothing other than italics, paragraphs, and code/preformatting works.)
Strikethrough and bold are doubled to avoid common ambiguities. Your underline should technically work, but it comes out as an <em> (emphasis) tag, which is rendered as italics in most browsers.
In the paper, Copernicus postulated the principle that "bad money drives out good", which later came to be referred to as Gresham's law after a later describer, Sir Thomas Gresham. This phenomenon had been noted earlier by Nicole Oresme, but Copernicus rediscovered it independently. Gresham's law is still known in Poland and Central and Eastern Europe as the Copernicus-Gresham Law.
Ugh, troff. It's mind-boggling that the closest way to have an actual (hyper)link in a manpage is to use your pager's "search for text" function. No, "JuSt usE gNu iNfO it'S beTtER" is not an answer either.
groff can produce output with links in it, and does by default in HTML mode! The GNU version of the Unix man page macro set has .UR and .UE for “URI start” and “URI end”. (I don't know whether these were present earlier in the lineage or whether they were introduced by GNU.) Also, the lowdown Markdown converter when in man output mode will output those for links. For fun, try:
echo 'Hi there! Have a [hyperlink](https://www.gnu.org/software/groff/manual/groff.html).' | lowdown -st man | groff -man -Thtml
There's also support for OSC 8 terminal hyperlink sequences throughout most of the groff toolchain: grotty(1) supports outputting them, and less(1) supports passing them through, including ^O^P and ^O^N gestures for moving between them. But man(7) says they're not enabled for grotty output by default. “Options” describes the rationale in its item for “-rU1”: “grohtml enables them by default; grotty does not, pending more widespread pager support for OSC 8 escape sequences.”
So if I set MANROFFOPT=-rU1 in the environment, I can get clickable links in man… if the man page author included them that way in the first place. I'm not sure how common that is in the wild, but grepping the ones on my system, I find firejail(1) contains a link to a GitHub issue embedded in that way, and it does indeed work when I hit ^O^N to seek to it and then C-mouse1—though the mouse gesture I have Alacritty using for links doesn't seem to work through tmux (there might be a way involving twiddling the tmux terminal-features setting, but I ran out of steam before trying this), and I didn't see a great way to get either grotty or Alacritty to style them on display instead of having them blend into the surrounding text, so it's still kind of scuffed in practice. (Though I bet the cool kids have moved on from Alacritty by now?) less displays the link target in the status line when you use the navigation commands, so it's not inaccessible, but for opening selected links directly from less with the ^O^O gesture rather than leaning on terminal support, it looks like you need to explicitly set the LESS_OSC8_ANY and/or LESS_OSC8_‹scheme› environment variable to a shell command that outputs a shell command pattern to substitute the link into; if I set LESS_OSC8_ANY='echo xdg-open %o' then it passes it to my Firefox. I wonder if they'd take a patch (or if any existing distributions patch it) to use that as the default?
That was a fun little rabbit hole to go down, thank you.
I think it would be easier for me to appreciate your comment if you named some of these other languages. Markdown is the only standardized one I regularly come across that I type by hand, these days.
What are you contrasting to?
As for Markdown specifically- the only thing I regularly mix up is the syntax for links. I frequently reverse the [] and (). But that's just because I don't use it enough to have the muscle memory.
1&2 just pick one, it doesn’t matter. 3 mostly you’re the parser… if you’re after accuracy there are better versions, but it sure is simple to read and write
Then you might like Obsidian. When the cursor is in some bit of formatted text, it displays all of the characters. When the cursor is elsewhere, it just shows the formatted text.
In the worst case, the barrier to entry and exit are pretty low.
Copying my thoughts from there which haven't changed:
>To which I say, are you really going to avoid using a good tool just because it makes you puke? Because looking at it makes your stomach churn? Because it offends every fiber of your being?"
Yes. A thousand times yes. Because the biggest advantage of Markdown is that it's easy to read, and its second-biggest advantage is that it's easy to write. How easy it is to parse doesn't matter. How easy it is to extend is largely irrelevant.
Markdown may or may not be the best tool for writing a book, but Markdown is the best tool for what it does - quickly writing formatted text in a way that is easy to read even for those who are not well versed in its syntax.
I don't want to write a book. If I did I'd use LaTeX before RST. I want something to take notes, make quick documentation and thread comments.
*****
My thoughts on strictly-defined XML-ish syntaxes are the same: they're harder for humans to read, write, and modify, which defeats the primary purpose and benefit of Markdown.
Very few people have to write a Markdown parser. Many orders of magnitude more have to read and write Markdown. Optimize for them even if it makes writing the parser painful.
"Better specified" doesn't mean better. A bunch of features doesn't mean better.
Markdown is popular because it is simple. I have never had to teach anyone Markdown. They look at the file and immediately see what's going on and can copy the style.
Occasionally someone may have to look up something like table syntax, but no one in my career or personal life has ever asked me to explain Markdown to them, which is rare for a technology that is so widely used.
This has not been my experience with other markup languages.
Have you tried Asciidoc though? It is, IMHO, much clearer than markdown (YMMV, obviously), and exactly the same pros you gave of markdown can be said of Asciidoc.
Bonus: It starts simple but can be used to do whole books if needed.
My experience is that Asciidoc very quickly gets into advanced syntax.
If you introduce something with advanced functionality onto a team, soon enough someone's going to use pieces that others don't fully understand later.
Now everyone touching the document has to understand includes and document metadata and whatever else someone added. Suddenly you have includes and cross-references and what used to be a document where you could read the raw non-rendered form linearly top to bottom is a confusing mess unless you render it. Markdown is almost always just as legible raw as rendered.
"Wrong" does not necessarily mean "against the standard". It means "against common usage and good team practice" in this context.
It's "allowed" to use raw pointers, malloc, and any number of things in C++ code. In general, if you do any of them in a modern codebase you're doing it wrong.
Yes, it's obviously "against common usage" given HTML support exists specifically for less common features that Markdown does not support. Like tables, which are supported by some implementations but not all, and iirc not even all Markdown variants that support tables use the same syntax for them. The only way to be 100% sure is to use HTML. Of course you wouldn't do that if you just have the file on Github, but in general HTML is supported in Markdown for a reason.
I like HTML and will use it for my own projects, but I cannot send pure HTML to someone who's not a into tech, so to speak, and expect them to actually read it. It doesn't take much CSS to make a readable web page, and I actually kind of like the barebones no-CSS HTML style, but for many others, that style reads as 'this page is broken'. I guess I can write all my styles inline or in the header, but that's a big ask when I never do that normally.
Markdown though, especially if you're not using way too much of it and mostly using it sensibly, just to give your document some structure, can be read as plain text by pretty much everyone, and will be implicitly understood. Sure, they might not understand the exact different between a word with asterisks on either side and one with underscores on either side, but they'll get that you meant to emphasise that work. They'll also understand a list shown with asterisks, while <ul> and <li> tags will get too verbose for them and clutter the actual content (I don't really care, but I get why they do).
1. Use a proper Markdown parser. The grammar is easy to define EBNF style most implementations I see now days use some recursive descent parser, etc… Regex implementation was used in original authors parser when it became popular.
2. You can resolve ambiguities and define more consistent symbols that make sense. Most markdown implementations are decent and follow common sense best practice syntax.
3. The beauty is its simplicity. You can pick it up in a few minutes and utilize it anywhere you damn near see a text box.
4. Parsing to HTML isn’t the only option! I mostly use TUI markdown viewers that render the document via ANSI escape codes beautifully. Check out glow project. But once you parse and have a AST, you can easily walk it and render it in other ways as well. Again though. Everyone can read a text document and a html document. You can render it to a PDF if need be.
5. Do we really need a whole new markup text2<format of some kind>? Markdown is simple fast and widely supported. So I have to say.. I prefer it over most things and that includes Rst.
If you need real beauty and power you can move to LaTeX or something… My two cents anyway.
Mark down is great because it doesn't define a bunch of things. Headline? Its a headline, no font, no sizing, no colors... Just a headline. It means that it can be displayed on any device, printed on any paper, work with any accessibility tool and optimized for what ever requirements the reader has, not what ever the writer thought looked good. The web is full of great content being made hard to access because of poor/inflexible layout choices. Just give me the text and let me choose how to make it readable. The added fact that you can read raw markdown without even parsing it makes it even better. Not having total control over what its going to look like for the reader is a feature not a bug.
> Its a headline, no font, no sizing, no colors... Just a headline. It means that it can be displayed on any device, printed on any paper, work with any accessibility tool and optimized for what ever requirements the reader has, not what ever the writer thought looked good.
God, remember when that was that goal of HTML and the web?
i use markdown because it's inherently limited to styling that is easy to represent. it's a good way to communicate the limitations of text-based content submission form.
if you tell somebody they can use HTML, they get frustrated when you tell them that tags other than anchor, bold, italic, list, heading, and paragraph aren't supported. but if you tell somebody they can use markdown, then they implicitly understand that the content they're submitting won't be rendered as green text on a purple background, and don't try to accomplish that.
I did a book in rst and liked that it had cool admonition, import, glossary, and index features that made it better than markdown for me. Still hate the heading conventions.
I have a custom pandoc filter for callouts and index entries. None of the simple lightweight markup languages has complete support for writing a real book. Writing custom rst code is a pain (and no one else in the world uses it). (I say this as a 25-year Python veteran and as a docutils committer!)
Markdown in the same directory as the code it documents is very readable by humans and LLMs.
Given LLMs proficiency in markdown and that reading it in view and edit mode is comparable I bet many engineering teams ditch confluence/Google docs for documentation in favor of just markdown plaintext docs adjacent to code (my team has moved design/RFCs to this as well, get feedback via PR commits, turn an LLM loose to implement design)
Also if you really don’t like it I bet you could just ask the LLM to translate it. No point wasting the human input characters or tokens on a ton of <></> etc
Looks like a duck, quacks like a duck… but is semantically different, except for when most people interact with them.
My point wasn’t that they are identically - my point is that 99% of the time they achieve the same effect. Or they would be if I had swapped the <p> tag for a <span> tag.
Not many keystrokes to get a readable text. Yes, it has issues. But at its core, it is a plaintext with extra stuff, and no temptation to turn it into a webapp. (See my footnotes on HTML vs MD for saving text in https://p.migdal.pl/blog/2025/02/markdown-saves/).
Yes, there is a problem with "many ways to do the same thing". The solution is ease - use a linter or autoformatter. No more bikeshedding.
> Simplicity through Consistency: If you know how to do one thing in Typst, you should be able to transfer that knowledge to other things. If there are multiple ways to do the same thing, one of them should be at a different level of abstraction than the other. E.g. it's okay that = Introduction and #heading[Introduction] do the same thing because the former is just syntax sugar for the latter.
What was the Bjarne Stroustrup quote about two types of languages again? I certainly have gotten more mileage out of Markdown at this point in my long career as a programmer and web developer than I have out of hand-written HTML, XML, or other markup languages. The latter are good for automation and unambiguous representation needed for system building, but for the type of informal writing that is my bread and butter outside of coding, Markdown kills, and Obsidian is the killer app.
I don't think Markdown should be (ab)used as a programming language. It should be treated as a plaintext container that has some formatting to organize the contents.
I've thought about this a bit too, and instead of a straight escape hatch to html when any special formatting is necessary, it might make sense to bind css to particular elements like so:
##[color:red] Heading 2
or using code blocks with particular headers which render out as normal text with the styling applied, like this:
```styling: 'ruleset here...'
Lorem Ipsum Dolor
```
this does require a lot of work to consider what might be ergonomic for a particular element (by element I mean ATX headings, blocks, etc.), though.
I enjoyed how it complained about how unclear and ambiguous Markdown’s syntax for bold and italic text supposedly is, then showed an HTML translation with <strong> and <em>.
The "right element for the right meaning" crowd is always going to fall when they charge against the sheer walls of "but I like using Caution for my bulleted list" crowd. Or the "of course we put tire patches in the wiring element, it's when we use the tire patches".
Or a million other examples I've wrassled with over the literal decades.
Whatever sophisticated semantic scheme you move into the markup layer, is gonna get messed up. And then your fancy schema is just noise, very expensive noise. Markup layer needs to glue as closely to natural language constructs as possible, and then glue a little more closely than that, and let the bulk of the information derived come from natlang. It's boring, but it works, and it's easier than ever to get quantitative information out of natlang.
Keep the domain stuff out of the markup layer.
All that said, Asciidoc forever baby. Write actual books in it. Not really more complex than Markdown[1]. Beats up DITA, takes its lunch money. Win win win.
[1] Unless you go legit insane with `include` and `ifdef/ifndef/ifeval`
That is a lot of complaining for having no suggested better alternative.
And there is your answer to the clickbait title -- we're still using markdown because there's no alternative that is so much better that it is going to dethrone the one that has all the momentum from being the first good-enough take on this that got any traction.
Everyone seems to forget Markdown was invented for humans and incidentally for machines.
Almost everyone who complains has some parser or rendering related agenda. No one cares if you can't nest asterisks inside underscores. Most of these edge cases don't read well as Markdown, which defeats the purpose.
>Everyone seems to forget Markdown was invented for humans and incidentally for machines.
We already had plain text for that. Markdown was invented to be converted to HTML. It has no utility over plain text otherwise. The link and image syntax is doing what HTML tags do, but are less readable for people than just pasting the URL. The relationship to the machine isn't incidental, it's intrinsic.
Markdown largely serves the same role as things like vocal emphasis and intonation in speech. Here are some example sentences that have slightly different semantics communicated by markdown differences.
You kind of do need Emacs though, as far as I know it is the only existing fully compatible implementation. As soon as the file is outside that environment, all bets are off. I tried using org-mode instead of Markdown once, not for long.
I don't read HTML all the time, and I don't expect it to be easy to read when outside of a browser.
Markdown though, that's my slightly fancy readme. It has just enough structure that I can easily read and understand it on the command line.
I can easily grep it without need for an advanced parsing engine.
If you need something with font and style weight then go for HTML.
But if I see README.html with a project, it's going to put me off wanting to contribute. I do not want to learn that project's style guide for how to add some new parameters to a table or remember that they want to specify italics in one of a dozen different ways.
i like html fine, but org-mode, now you're talkin'. it's like the nasa voyager equivalent of text markup. just needs to be rescued from being held hostage in emacs.
The format itself can be easily implemented. There's not much to it and it actually has features that's undefined in markdown like frontmatter and references. The things that are missing can be replicated outside of emacs (babel, agenda, task management, timetracking, export,...), it's just that no one is doing it.
On one hand, yes, all true, it’s definitely a bit of a mess. On the other hand, what’s the alternative and don’t all languages with limitations ultimately get extended by various parties in non-compliant ways? Can anyone point to any alternative that has done it all correctly? Show me one language where someone says “This is all good and correct” and I’ll show you a language with 100 feature requests to extend it way further than its original authors intended and would create a similar mess if acted on. This is all to say, I’m going to coin Roberts’ Rule which says “All markup languages eventually end up as piles of poo with half a Turing-complete language bolted onto the side. Resistance is futile.”
Markdown is widely used but I agree that it's a mess, there are so many dialects..
A similar but better markup is ASCIIDOC; it's formally defined and comes with a Technology Compatiblity Kit (TCK) that can be used to certify the compliance of an implementation with the spec.
I strongly dislike flexible input like
__Unambiguous___, *Unambiguous*
I’m reminded of the time Microsoft allowed mistakes in html writing. They attempted to parse a wide variety of common user errors. The effect of this was no standard and nobody else able to write a Microsoft compatible parser.
I dislike Nim lang because of this. At least Nim defined the specification. Still though I think it creates more cognitive load learning every legal variation and it makes searching more difficult.
I think to authors point if Markdown actually had a strict simple definition with one way to do it and no embedded html we would be better off.
When you look at wisdom principles, like those of the Solomonic kind, you observe that a proverb is profoundly true, wise, and useful when you first hear it, but it starts to feel less so when you subject it to intense scrutiny/deconstruction, or try to extrapolate it to places where it's not supposed to go.
Markdown is like that.
We use it because it's an incredibly human way of writing and reading data without having to wade too deeply into the various forms of overhead that allow machines to read, process, and display it.
People use Markdown because it's expected, it's probably already a part of whatever library or framework they're already using, and there is no well supported or popular alternative.
I mean I started using it because I don't like using Word or Google Docs and wanted a more portable data format since I was going between Mac and Linux.
There are bunch of reasons why it came to dominate.
I think markdown has problems, but this doesn't really propose a sane solution.
The need markdown solves is document formatting without needing to know or use a tag-based markup language and remaining easily human readable and editable.
That said, this is actually not the most widespread requirement. And when people need to solve this requirement, there often not tons of options. So some flavor of markdown is often the least problematic option.
If HTML were for machines it would be a binary format. It's text so it's meant for humans to read and write, and humans did both for years without it being a problem.
The article talks about how confusing Markdown can get. I understand, but HTML is *much* more confusing when it comes to creating technical articles. These days we are going to see more and more markdown with the advent of AI. Markdown works really we with AI because it reduces the number of tokens required for the same amount of information vs HTML.
Yes fully agreed, markdown is going to win by far just because of tokens and AI. The only thing I think right now that should be advanced, is plugins/custom components for markdown, like .mdx, etc token efficient ways of visualizing things in various ways, or custom interactive components, etc.
Start with Obsidian (with "Live Preview" and "Editing Mode" as defaults) for fantastic WYSIWYG note-taking. Then layer in plugins like Outliner, Templater, Canvas, Relay... and realize Obsidian is almost like an OS for .md files -- which are portable, and easily human- and machine-readable.
I just can't find myself summoning the energy to be mad about markdown. It's good enough for like 99% of the things I use it for. Sometimes I get annoyed at specific extension support or whatever when I realize I shouldn't be using markdown for that task.
I think the author is missing the point. Markdown is easy for humans to read, write, and modify. Yes, parsers can be complicated. Few people need to write parsers, so that's ok, if unfortunate for those parser authors. Orders of magnitude more people need to read, write, and modify the documents themselves, and the fact that it's easy to do so is a huge strength.
HTML is terrible when you consider these properties. It's not easy to read, and is annoying to write and modify. Ditto for any other XML-based markup language, or even something like RST. LaTeX is right out.
Ultimately the author seems to suggest plain text should be what people use? That misses the point. Plain text is great for a lot of things, but if you're going to generate HTML (or something else) from it, you need something that at least has some structure. Markdown hits a nice sweet spot where it has enough structure such that you can reasonably generate rich-text document formats from it, but not so much that non-technical users can't work their heads around the format.
This website, at least in dark mode, doesn't have any visible indication when text is selected.
... Which is additionally frustrating, since the links at the bottom aren't actually links (so you have to select them to copy and paste into your address bar)
...and? What a weird article. Of course two different pieces source code can produce identical output. Every single mainstream languages are like that too.
Why are we using Markdown? Why do I use it every day?
It's easy to write. It's easy to read. Despite the OP's complaints, quality parsers exist.
pandoc can turn it into almost any format. We will still be writing markdown in 50 years, because the design bridges a bunch of compromises very nicely.
I actually do agree that HTML is a better one, if it is a bit easier to read the source...I want text, image and links in one place and HTML is indeed the easiest one.
BTW TempleOS terminal comes into mind. I really love the hyperlinks.
Why the heck would you use the phrase "Why the heck" in any circumstance other than to avoid censorship/algorithmic penality on a social media platform?
Well, one good reason is that a person who generally doesn't "swear" can then choose to use them very effectively when the situation warrants. If you always go to strongest words when mild ones will do, you're out of things to say when you need to make a stronger/more forceful point.
Perhaps instead of worrying about someone else's free choice to use certain words iver others, it would be wise of you to ask: why would you complain about forced speech patterns in the context of censorship but then be angry when someone uses their free speech differently then you would use it?
I'm not using Markdown; I'm using plain text, along with a handful of well-understood formatting conventions which go back decades. "Markdown" is just a prettier means of displaying such text.
HTML is not a markup language anymore; it has become a lunatic application platform, and the last thing I want when trying to read some text is the intrusion of some lunatic's application.
This may be the first time my reaction to an objectively terrible programming language is a shrug and a "whatever". I like using markdown. I use it for journaling in Obsidian. It does everything I want it to. I like that it's just flat files. I don't want my journaling to be stuck in some online database.
Yet, I am the same person who refuses to code in anything but Rust due to how not-awful it feels to me. Strange how a person can hold a completely opposite view for two instances of the same problem. Being human in a nutshell.
This is just like the debate over YAML. In both cases, the language is simple enough, and people use it sanely enough in practice that I just don't care about the warts. Contrast this with something like C++, where the warts are less avoidable and therefore more worthy of notice. Markdown as I use it is functional and simple and no one has suggested an alternative I like better, so I keep using it.
Also, as I use it, Markdown is effectively plain text. I very rarely look at "rendered" markdown. I guess in practice I actually use "plain text" that just happens to look a lot like markdown by this article's definitions.
Because, like UNIX/Linux itself, worse is better: https://en.wikipedia.org/wiki/Worse_is_better - and perfect is the enemy of "good enough."
We want to encourage people to produce written output with minimal friction. Barriers to writing--and especially barriers to producing documentation--should be minimized. Writing well is difficult enough!
Markup is overhead. Complex markup is even more overhead. Markdown is the best compromise we know of today that provides just enough structure and typographic capability, while imposing very little cognitive load on the author.
Besides, if you need something more complicated these days, you can have your favorite AI agent do it.
It's also worth remembering that markdown tried very hard to encode conventions that were already used in Usenet, email, and other text media. A > to indicate a quote was widespread Usenet convention. Asterisks or underscores to indicate emphasis was also a common convention; both are legal because both were common. Double asterisk or double underscores to indicate really, really emphasizing something was also a common convention. So were asterisks to display a bulleted list, blank lines to separate paragraphs, and indenting 4+ spaces to write code.
It's a good example of "pave the path" design philosophy, where you do what users are already doing rather than trying to impose some platonic ideal of what the world should be like. And it works quite well at that.
Stepped right on the rake though because it uses sigils which were common, but requires they be used in uncommon ways (by doubling etc) which it why most chat UIs don't actually use markdown
Somehow basically only Discord gets it almost perfectly right though.
markdown tried very hard to encode conventions that were already used in Usenet, email, and other text media
For those of you who weren't there:
I've been using these for almost half a century. They're much easier and more intuitive than Markdown. I see no compelling reason to change.Your quotation and list syntax should work out of the box in most Markdown flavors (HN has a very non-standard and crippled version - basically nothing other than italics, paragraphs, and code/preformatting works.)
Strikethrough and bold are doubled to avoid common ambiguities. Your underline should technically work, but it comes out as an <em> (emphasis) tag, which is rendered as italics in most browsers.
But Usenet style didn't have a trendy name, an 'inventor' or Github stars. So it didn't exist.
GitHub stars weren't a thing when Markdown was roughly codified. Was GitHub even around then?
> worse is better
It's a very old idea
https://en.wikipedia.org/wiki/Monetae_cudendae_ratioThe solution is sufficiently perfected with markdown. Just like new revolutionary technologies doesn't replace wheel technology.
To actually manage notes and information in plain text I like org-mode markup. For just writing, markdown is good enough.
This is exactly why ReStructured Text is better/worse.
Worse is better doesn’t mean worst is best either.
Markdown is pretty far from the worst. It's decent and unobtrusive. Worst would be something like Troff or jira formatting. Midtier would be RST.
Ugh, troff. It's mind-boggling that the closest way to have an actual (hyper)link in a manpage is to use your pager's "search for text" function. No, "JuSt usE gNu iNfO it'S beTtER" is not an answer either.
groff can produce output with links in it, and does by default in HTML mode! The GNU version of the Unix man page macro set has .UR and .UE for “URI start” and “URI end”. (I don't know whether these were present earlier in the lineage or whether they were introduced by GNU.) Also, the lowdown Markdown converter when in man output mode will output those for links. For fun, try:
There's also support for OSC 8 terminal hyperlink sequences throughout most of the groff toolchain: grotty(1) supports outputting them, and less(1) supports passing them through, including ^O^P and ^O^N gestures for moving between them. But man(7) says they're not enabled for grotty output by default. “Options” describes the rationale in its item for “-rU1”: “grohtml enables them by default; grotty does not, pending more widespread pager support for OSC 8 escape sequences.”So if I set MANROFFOPT=-rU1 in the environment, I can get clickable links in man… if the man page author included them that way in the first place. I'm not sure how common that is in the wild, but grepping the ones on my system, I find firejail(1) contains a link to a GitHub issue embedded in that way, and it does indeed work when I hit ^O^N to seek to it and then C-mouse1—though the mouse gesture I have Alacritty using for links doesn't seem to work through tmux (there might be a way involving twiddling the tmux terminal-features setting, but I ran out of steam before trying this), and I didn't see a great way to get either grotty or Alacritty to style them on display instead of having them blend into the surrounding text, so it's still kind of scuffed in practice. (Though I bet the cool kids have moved on from Alacritty by now?) less displays the link target in the status line when you use the navigation commands, so it's not inaccessible, but for opening selected links directly from less with the ^O^O gesture rather than leaning on terminal support, it looks like you need to explicitly set the LESS_OSC8_ANY and/or LESS_OSC8_‹scheme› environment variable to a shell command that outputs a shell command pattern to substitute the link into; if I set LESS_OSC8_ANY='echo xdg-open %o' then it passes it to my Firefox. I wonder if they'd take a patch (or if any existing distributions patch it) to use that as the default?
That was a fun little rabbit hole to go down, thank you.
troff was originally used to format printed output, where hyperlinks would not make any sense.
For me, Markdown produces a lot of unnecessary cognitive load compared to other markup languages.
• I have to decide whether to use asterisks or underscores for bold and italic.
• I have to decide whether to use asterisks, hyphen-minuses, or plus signs for unordered lists.
• I have to remember all the various rules and edge cases about parsing.
> compared to other markup languages
I think it would be easier for me to appreciate your comment if you named some of these other languages. Markdown is the only standardized one I regularly come across that I type by hand, these days.
What are you contrasting to?
As for Markdown specifically- the only thing I regularly mix up is the syntax for links. I frequently reverse the [] and (). But that's just because I don't use it enough to have the muscle memory.
> I think it would be easier for me to appreciate your comment if you named some of these other languages.
HTML? Also my markup language I created for myself, which is currently not published.
my girlfriend goes to another school
1&2 just pick one, it doesn’t matter. 3 mostly you’re the parser… if you’re after accuracy there are better versions, but it sure is simple to read and write
I suggest trying Obsidian for WYSIWYG markdown editing. It beats heck out of typing it raw and eliminates that cognitive load.
I don’t like WYSIWYG editing, as it makes the formatting invisible.
Then you might like Obsidian. When the cursor is in some bit of formatted text, it displays all of the characters. When the cursor is elsewhere, it just shows the formatted text.
In the worst case, the barrier to entry and exit are pretty low.
I came here to say this.
Somewhat related past discussion: https://news.ycombinator.com/item?id=41120254
Copying my thoughts from there which haven't changed:
>To which I say, are you really going to avoid using a good tool just because it makes you puke? Because looking at it makes your stomach churn? Because it offends every fiber of your being?"
Yes. A thousand times yes. Because the biggest advantage of Markdown is that it's easy to read, and its second-biggest advantage is that it's easy to write. How easy it is to parse doesn't matter. How easy it is to extend is largely irrelevant.
Markdown may or may not be the best tool for writing a book, but Markdown is the best tool for what it does - quickly writing formatted text in a way that is easy to read even for those who are not well versed in its syntax.
I don't want to write a book. If I did I'd use LaTeX before RST. I want something to take notes, make quick documentation and thread comments.
*****
My thoughts on strictly-defined XML-ish syntaxes are the same: they're harder for humans to read, write, and modify, which defeats the primary purpose and benefit of Markdown.
Very few people have to write a Markdown parser. Many orders of magnitude more have to read and write Markdown. Optimize for them even if it makes writing the parser painful.
There are other solutions which are as easy to read/write (if not more) and which are defined much better… Asciidoc comes to mind.
"Better specified" doesn't mean better. A bunch of features doesn't mean better.
Markdown is popular because it is simple. I have never had to teach anyone Markdown. They look at the file and immediately see what's going on and can copy the style.
Occasionally someone may have to look up something like table syntax, but no one in my career or personal life has ever asked me to explain Markdown to them, which is rare for a technology that is so widely used.
This has not been my experience with other markup languages.
Have you tried Asciidoc though? It is, IMHO, much clearer than markdown (YMMV, obviously), and exactly the same pros you gave of markdown can be said of Asciidoc.
Bonus: It starts simple but can be used to do whole books if needed.
My experience is that Asciidoc very quickly gets into advanced syntax.
If you introduce something with advanced functionality onto a team, soon enough someone's going to use pieces that others don't fully understand later.
Now everyone touching the document has to understand includes and document metadata and whatever else someone added. Suddenly you have includes and cross-references and what used to be a document where you could read the raw non-rendered form linearly top to bottom is a confusing mess unless you render it. Markdown is almost always just as legible raw as rendered.
It's great apart from the nested list syntax. It's quite noisy. I'd prefer if it supported indentation.
HTML is valid markdown. So I'm not sure how you make oppose markdown and XML. XML is basically a subset of markdown.
Markdown basically adds a whole layer of complexity upon HTML.If you're writing things like that in Markdown files (without being escaped in code blocks as HTML syntax examples), you're doing it wrong.
Not wrong, perhaps a little weird. HTML is a first class citizen in the commonmark (spec)[https://spec.commonmark.org/0.31.2/#html-blocks].
"Wrong" does not necessarily mean "against the standard". It means "against common usage and good team practice" in this context.
It's "allowed" to use raw pointers, malloc, and any number of things in C++ code. In general, if you do any of them in a modern codebase you're doing it wrong.
Yes, it's obviously "against common usage" given HTML support exists specifically for less common features that Markdown does not support. Like tables, which are supported by some implementations but not all, and iirc not even all Markdown variants that support tables use the same syntax for them. The only way to be 100% sure is to use HTML. Of course you wouldn't do that if you just have the file on Github, but in general HTML is supported in Markdown for a reason.
I like HTML and will use it for my own projects, but I cannot send pure HTML to someone who's not a into tech, so to speak, and expect them to actually read it. It doesn't take much CSS to make a readable web page, and I actually kind of like the barebones no-CSS HTML style, but for many others, that style reads as 'this page is broken'. I guess I can write all my styles inline or in the header, but that's a big ask when I never do that normally.
Markdown though, especially if you're not using way too much of it and mostly using it sensibly, just to give your document some structure, can be read as plain text by pretty much everyone, and will be implicitly understood. Sure, they might not understand the exact different between a word with asterisks on either side and one with underscores on either side, but they'll get that you meant to emphasise that work. They'll also understand a list shown with asterisks, while <ul> and <li> tags will get too verbose for them and clutter the actual content (I don't really care, but I get why they do).
A few things here.
1. Use a proper Markdown parser. The grammar is easy to define EBNF style most implementations I see now days use some recursive descent parser, etc… Regex implementation was used in original authors parser when it became popular.
2. You can resolve ambiguities and define more consistent symbols that make sense. Most markdown implementations are decent and follow common sense best practice syntax.
3. The beauty is its simplicity. You can pick it up in a few minutes and utilize it anywhere you damn near see a text box.
4. Parsing to HTML isn’t the only option! I mostly use TUI markdown viewers that render the document via ANSI escape codes beautifully. Check out glow project. But once you parse and have a AST, you can easily walk it and render it in other ways as well. Again though. Everyone can read a text document and a html document. You can render it to a PDF if need be.
5. Do we really need a whole new markup text2<format of some kind>? Markdown is simple fast and widely supported. So I have to say.. I prefer it over most things and that includes Rst.
If you need real beauty and power you can move to LaTeX or something… My two cents anyway.
Mark down is great because it doesn't define a bunch of things. Headline? Its a headline, no font, no sizing, no colors... Just a headline. It means that it can be displayed on any device, printed on any paper, work with any accessibility tool and optimized for what ever requirements the reader has, not what ever the writer thought looked good. The web is full of great content being made hard to access because of poor/inflexible layout choices. Just give me the text and let me choose how to make it readable. The added fact that you can read raw markdown without even parsing it makes it even better. Not having total control over what its going to look like for the reader is a feature not a bug.
> Its a headline, no font, no sizing, no colors... Just a headline. It means that it can be displayed on any device, printed on any paper, work with any accessibility tool and optimized for what ever requirements the reader has, not what ever the writer thought looked good.
God, remember when that was that goal of HTML and the web?
What a beautiful couple of years that was.
IMHO still is. Just don't add any JS or CSS
i use markdown because it's inherently limited to styling that is easy to represent. it's a good way to communicate the limitations of text-based content submission form.
if you tell somebody they can use HTML, they get frustrated when you tell them that tags other than anchor, bold, italic, list, heading, and paragraph aren't supported. but if you tell somebody they can use markdown, then they implicitly understand that the content they're submitting won't be rendered as green text on a purple background, and don't try to accomplish that.
I've written over a dozen books.
Have used asciidoc, HTML, word, latex, and rst.
Markdown is the least painful of all. It's not perfect but the others are worse.
(My custom stack uses markdown (or Jupyter notebooks converted to markdown). Pandoc plus some custom filters creates typst (for PDF) or epub.)
I did a book in rst and liked that it had cool admonition, import, glossary, and index features that made it better than markdown for me. Still hate the heading conventions.
I have a custom pandoc filter for callouts and index entries. None of the simple lightweight markup languages has complete support for writing a real book. Writing custom rst code is a pain (and no one else in the world uses it). (I say this as a 25-year Python veteran and as a docutils committer!)
We use markdown because LLMs are great at it.
Markdown in the same directory as the code it documents is very readable by humans and LLMs.
Given LLMs proficiency in markdown and that reading it in view and edit mode is comparable I bet many engineering teams ditch confluence/Google docs for documentation in favor of just markdown plaintext docs adjacent to code (my team has moved design/RFCs to this as well, get feedback via PR commits, turn an LLM loose to implement design)
Also if you really don’t like it I bet you could just ask the LLM to translate it. No point wasting the human input characters or tokens on a ton of <></> etc
LLMs are great at it because it was already a widely adopted standard and fed to LLMs in training sets
Ambiguous means unclear meaning, not that there is more than one way to achieve the same thing.
Html has that same problem. Think <b>, <strong>, <p style=“font-weight: 900;”>, etc.
That’s life. Get used to it.
Those three are not the same thing though. They might render the same visually with the most popular visual user agents, but that's about it
Looks like a duck, quacks like a duck… but is semantically different, except for when most people interact with them.
My point wasn’t that they are identically - my point is that 99% of the time they achieve the same effect. Or they would be if I had swapped the <p> tag for a <span> tag.
<b> is now hilariously called the "bring attention to" element. I shit you not.
That's the sort of "we started at the acronym and worked backwards" approach the Pentagon loves to do.
Not many keystrokes to get a readable text. Yes, it has issues. But at its core, it is a plaintext with extra stuff, and no temptation to turn it into a webapp. (See my footnotes on HTML vs MD for saving text in https://p.migdal.pl/blog/2025/02/markdown-saves/).
Yes, there is a problem with "many ways to do the same thing". The solution is ease - use a linter or autoformatter. No more bikeshedding.
If you plan to use a clean yet expandable syntax, look at Typst. One of its core design principles (https://github.com/typst/typst?tab=readme-ov-file#design-pri...) is:
> Simplicity through Consistency: If you know how to do one thing in Typst, you should be able to transfer that knowledge to other things. If there are multiple ways to do the same thing, one of them should be at a different level of abstraction than the other. E.g. it's okay that = Introduction and #heading[Introduction] do the same thing because the former is just syntax sugar for the latter.
What was the Bjarne Stroustrup quote about two types of languages again? I certainly have gotten more mileage out of Markdown at this point in my long career as a programmer and web developer than I have out of hand-written HTML, XML, or other markup languages. The latter are good for automation and unambiguous representation needed for system building, but for the type of informal writing that is my bread and butter outside of coding, Markdown kills, and Obsidian is the killer app.
I don't think Markdown should be (ab)used as a programming language. It should be treated as a plaintext container that has some formatting to organize the contents.
Agreed, if you need programmable content you can add some Javascript: https://www.markdownlang.com/advanced/javascript.html
I've thought about this a bit too, and instead of a straight escape hatch to html when any special formatting is necessary, it might make sense to bind css to particular elements like so:
##[color:red] Heading 2
or using code blocks with particular headers which render out as normal text with the styling applied, like this:
```styling: 'ruleset here...' Lorem Ipsum Dolor ```
this does require a lot of work to consider what might be ergonomic for a particular element (by element I mean ATX headings, blocks, etc.), though.
cf `# Heading 2 { attributes}` in pandoc:
https://pandoc.org/demo/example33/8.3-headings.html#extensio...
There are also attributes for image position/size, etc.
This is sweet!
The article correctly identifies the upsides of Markdown, then identifies a bunch of issues that I, as a casual user of it, don't care about.
Then, in the solution section, doesn't identify a solution.
No thank you, I'll stick with Markdown.
I enjoyed how it complained about how unclear and ambiguous Markdown’s syntax for bold and italic text supposedly is, then showed an HTML translation with <strong> and <em>.
The "right element for the right meaning" crowd is always going to fall when they charge against the sheer walls of "but I like using Caution for my bulleted list" crowd. Or the "of course we put tire patches in the wiring element, it's when we use the tire patches".
Or a million other examples I've wrassled with over the literal decades.
Whatever sophisticated semantic scheme you move into the markup layer, is gonna get messed up. And then your fancy schema is just noise, very expensive noise. Markup layer needs to glue as closely to natural language constructs as possible, and then glue a little more closely than that, and let the bulk of the information derived come from natlang. It's boring, but it works, and it's easier than ever to get quantitative information out of natlang.
Keep the domain stuff out of the markup layer.
All that said, Asciidoc forever baby. Write actual books in it. Not really more complex than Markdown[1]. Beats up DITA, takes its lunch money. Win win win.
[1] Unless you go legit insane with `include` and `ifdef/ifndef/ifeval`
That is a lot of complaining for having no suggested better alternative.
And there is your answer to the clickbait title -- we're still using markdown because there's no alternative that is so much better that it is going to dethrone the one that has all the momentum from being the first good-enough take on this that got any traction.
Everyone seems to forget Markdown was invented for humans and incidentally for machines.
Almost everyone who complains has some parser or rendering related agenda. No one cares if you can't nest asterisks inside underscores. Most of these edge cases don't read well as Markdown, which defeats the purpose.
>Everyone seems to forget Markdown was invented for humans and incidentally for machines.
We already had plain text for that. Markdown was invented to be converted to HTML. It has no utility over plain text otherwise. The link and image syntax is doing what HTML tags do, but are less readable for people than just pasting the URL. The relationship to the machine isn't incidental, it's intrinsic.
Markdown largely serves the same role as things like vocal emphasis and intonation in speech. Here are some example sentences that have slightly different semantics communicated by markdown differences.
My cat is an idiot.
My cat is an idiot.
My cat is an idiot.
All problems are solved once you embrace org-mode.
All you need is Emacs! Nothing more!
Objectively false. Please stop spreading misinformation.
I can think of a lot of potentially false things in the statement. The biggest falsehood likely is the perception that one needs Emacs. :-)
You kind of do need Emacs though, as far as I know it is the only existing fully compatible implementation. As soon as the file is outside that environment, all bets are off. I tried using org-mode instead of Markdown once, not for long.
I don't read HTML all the time, and I don't expect it to be easy to read when outside of a browser.
Markdown though, that's my slightly fancy readme. It has just enough structure that I can easily read and understand it on the command line.
I can easily grep it without need for an advanced parsing engine.
If you need something with font and style weight then go for HTML.
But if I see README.html with a project, it's going to put me off wanting to contribute. I do not want to learn that project's style guide for how to add some new parameters to a table or remember that they want to specify italics in one of a dozen different ways.
i like html fine, but org-mode, now you're talkin'. it's like the nasa voyager equivalent of text markup. just needs to be rescued from being held hostage in emacs.
The format itself can be easily implemented. There's not much to it and it actually has features that's undefined in markdown like frontmatter and references. The things that are missing can be replicated outside of emacs (babel, agenda, task management, timetracking, export,...), it's just that no one is doing it.
i use it because it does what i want and is easy to use.
There are other options. AsciiDoc come to mind.
On one hand, yes, all true, it’s definitely a bit of a mess. On the other hand, what’s the alternative and don’t all languages with limitations ultimately get extended by various parties in non-compliant ways? Can anyone point to any alternative that has done it all correctly? Show me one language where someone says “This is all good and correct” and I’ll show you a language with 100 feature requests to extend it way further than its original authors intended and would create a similar mess if acted on. This is all to say, I’m going to coin Roberts’ Rule which says “All markup languages eventually end up as piles of poo with half a Turing-complete language bolted onto the side. Resistance is futile.”
Markdown is widely used but I agree that it's a mess, there are so many dialects..
A similar but better markup is ASCIIDOC; it's formally defined and comes with a Technology Compatiblity Kit (TCK) that can be used to certify the compliance of an implementation with the spec.
I strongly dislike flexible input like __Unambiguous___, *Unambiguous*
I’m reminded of the time Microsoft allowed mistakes in html writing. They attempted to parse a wide variety of common user errors. The effect of this was no standard and nobody else able to write a Microsoft compatible parser.
I dislike Nim lang because of this. At least Nim defined the specification. Still though I think it creates more cognitive load learning every legal variation and it makes searching more difficult.
I think to authors point if Markdown actually had a strict simple definition with one way to do it and no embedded html we would be better off.
When you look at wisdom principles, like those of the Solomonic kind, you observe that a proverb is profoundly true, wise, and useful when you first hear it, but it starts to feel less so when you subject it to intense scrutiny/deconstruction, or try to extrapolate it to places where it's not supposed to go.
Markdown is like that.
We use it because it's an incredibly human way of writing and reading data without having to wade too deeply into the various forms of overhead that allow machines to read, process, and display it.
People use Markdown because it's expected, it's probably already a part of whatever library or framework they're already using, and there is no well supported or popular alternative.
I mean I started using it because I don't like using Word or Google Docs and wanted a more portable data format since I was going between Mac and Linux.
There are bunch of reasons why it came to dominate.
fair enough, but what alternatives did you have?
Depending on the context: plaintext, HTML, BBCode, WYSIWYG editors
I think markdown has problems, but this doesn't really propose a sane solution.
The need markdown solves is document formatting without needing to know or use a tag-based markup language and remaining easily human readable and editable.
That said, this is actually not the most widespread requirement. And when people need to solve this requirement, there often not tons of options. So some flavor of markdown is often the least problematic option.
Why would anyone dislike markdown when it is so simple to use? My only gripe with markdown is that sometimes i forget how to include links.
The answer to the question in the headline:
- It's pretty easy for humans to read & write
- It's very easy for AI to read & write
- It's quite token-efficient relative to its expressiveness
- It can be used in many different contexts, so it's actually surprisingly good for interchange.
There are many formats that are better-suited for a given purpose, but Markdown remains a very attractive compromise for many applications.
Markdown is for us humans. HTML is for machines.
Per keyboard stroke, you write much more content with MD than HTML.
Even without a specific browser/reader Markdown is relatively non-intrusive to read. You cant read HTML without an extra tool/effort to discard tags.
And you can parse MD with regular expressions, or can you? ;). (tip hat to infamous Stackoverflow discussion)
If HTML were for machines it would be a binary format. It's text so it's meant for humans to read and write, and humans did both for years without it being a problem.
The article talks about how confusing Markdown can get. I understand, but HTML is *much* more confusing when it comes to creating technical articles. These days we are going to see more and more markdown with the advent of AI. Markdown works really we with AI because it reduces the number of tokens required for the same amount of information vs HTML.
Yes fully agreed, markdown is going to win by far just because of tokens and AI. The only thing I think right now that should be advanced, is plugins/custom components for markdown, like .mdx, etc token efficient ways of visualizing things in various ways, or custom interactive components, etc.
Markdown is essentially plain text with a couple extra features. I think Markdown’s basic appeal is that it’s plain text.
Because I think it’s fair to say it’s becoming a standard format for ai agent specs docs etc. It’s not going away anytime soon.
Aaron needs to hurry up and reincarnate already.
Aaron had very little to do with Markdown, other than reviewing the spec once at the end.
This sounds like all the arguments against using JSON/YAML as well.
People forget how important good UX can be, sometimes.
We're using Markdown, YAML, and JSON bc they're easy to use; they're "highly memetic" (easy to learn, easy to teach, easy to spread)
They don't require many months to learn like XML, back in the day
Start with Obsidian (with "Live Preview" and "Editing Mode" as defaults) for fantastic WYSIWYG note-taking. Then layer in plugins like Outliner, Templater, Canvas, Relay... and realize Obsidian is almost like an OS for .md files -- which are portable, and easily human- and machine-readable.
I just can't find myself summoning the energy to be mad about markdown. It's good enough for like 99% of the things I use it for. Sometimes I get annoyed at specific extension support or whatever when I realize I shouldn't be using markdown for that task.
The only changes I'd want to Markdown:
- Reverse the link syntax braces, so the URL is in [], and the link text is in ()
- Allow table cell content to have line continuations
I love markdown for technical reporting when the alternative was a hacked together Word document.
Markdown lacks JavaScript and can be considered mostly harmless.
Anyone that thinks Markdown is bad is crazy. People need to be able to quickly and easily markup their text.
Funniest part of this article is claiming * will produce a b tag then demonstrating it will usually produce a strong tag and not even noticing this.
Easy and "good enough" very often trumps complex and comprehensive. Markdown is great precisely because it can't do a lot of things.
Because Markdown is awesome, easier to write, and easier to read at the source level.
Because there's only one reasonable implementation of AsciiDoc
I think the author is missing the point. Markdown is easy for humans to read, write, and modify. Yes, parsers can be complicated. Few people need to write parsers, so that's ok, if unfortunate for those parser authors. Orders of magnitude more people need to read, write, and modify the documents themselves, and the fact that it's easy to do so is a huge strength.
HTML is terrible when you consider these properties. It's not easy to read, and is annoying to write and modify. Ditto for any other XML-based markup language, or even something like RST. LaTeX is right out.
Ultimately the author seems to suggest plain text should be what people use? That misses the point. Plain text is great for a lot of things, but if you're going to generate HTML (or something else) from it, you need something that at least has some structure. Markdown hits a nice sweet spot where it has enough structure such that you can reasonably generate rich-text document formats from it, but not so much that non-technical users can't work their heads around the format.
This website, at least in dark mode, doesn't have any visible indication when text is selected.
... Which is additionally frustrating, since the links at the bottom aren't actually links (so you have to select them to copy and paste into your address bar)
> These 2 produce IDENTICAL output.
...and? What a weird article. Of course two different pieces source code can produce identical output. Every single mainstream languages are like that too.
These examples are contrived af.
Nobody uses markdown like that bro. We like markdown because it's easy to read both rendered and raw.
Yea I’ve been typing encyclopedias worth of markdown, most to throw away, some to publish, and I’ve never had any the problems shown here.
Hard, hard no on this.
Why are we using Markdown? Why do I use it every day?
It's easy to write. It's easy to read. Despite the OP's complaints, quality parsers exist.
pandoc can turn it into almost any format. We will still be writing markdown in 50 years, because the design bridges a bunch of compromises very nicely.
I actually do agree that HTML is a better one, if it is a bit easier to read the source...I want text, image and links in one place and HTML is indeed the easiest one.
BTW TempleOS terminal comes into mind. I really love the hyperlinks.
When I read articles like this my reaction is always “put up or shut up.”
If you have a better idea, make it happen.
The author merely described the parameters of a solution and didn’t even attempt to solve it.
In essence, we aren’t even left certain that a better solution that satisfies all stakeholders is possible.
You communicate on hacker news through plain text. You don't need to control the user don't, color, and what ads they see.
If what is to communicate, plain text is good enough. If you want to control how information is consumed, fuck of, die already.
You can say hell on your own blog.
Interestingly, you can also choose not to say it on your own blog.
Why the heck would you use the phrase "Why the heck" in any circumstance other than to avoid censorship/algorithmic penality on a social media platform?
These things tend to get ingrained in you so you continue to use them even if you could technically use the words they replace.
Well, one good reason is that a person who generally doesn't "swear" can then choose to use them very effectively when the situation warrants. If you always go to strongest words when mild ones will do, you're out of things to say when you need to make a stronger/more forceful point.
And there is nothing better to use for the headline than a minced oath if you explicitly don't want to swear? Make it make sense.
Perhaps instead of worrying about someone else's free choice to use certain words iver others, it would be wise of you to ask: why would you complain about forced speech patterns in the context of censorship but then be angry when someone uses their free speech differently then you would use it?
Markdown has a lot of weird choices and works best for longer documents.
Check out my "Advent of Markdown" where I go through surprising markdown behavior: https://mastodon.social/@timokoesters/115643467322561173
I'm not using Markdown; I'm using plain text, along with a handful of well-understood formatting conventions which go back decades. "Markdown" is just a prettier means of displaying such text.
HTML is not a markup language anymore; it has become a lunatic application platform, and the last thing I want when trying to read some text is the intrusion of some lunatic's application.