logoalt Hacker News

otterleylast Friday at 6:13 PM11 repliesview on HN

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.


Replies

nostrademonslast Friday at 6:35 PM

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.

show 3 replies
neonstaticyesterday at 1:29 AM

> worse is better

It's a very old idea

  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.
https://en.wikipedia.org/wiki/Monetae_cudendae_ratio
show 1 reply
wisemanwillhearlast Friday at 6:21 PM

The solution is sufficiently perfected with markdown. Just like new revolutionary technologies doesn't replace wheel technology.

show 1 reply
throw0101cyesterday at 1:19 PM

> 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!

What about something like AsciiDoc (or reStructuredText)?

* https://docs.asciidoctor.org/asciidoc/latest/asciidoc-vs-mar...

* "Markdown, Asciidoc, or reStructuredText – a tale of docs-as-code": https://news.ycombinator.com/item?id=33468213

Simply things are still simple, but there seem to be more advanced options for those that want/need them.

show 1 reply
duxupyesterday at 5:27 PM

It's the inescapable truth that even after sitting down and engineering a magical solution ... sometimes just a basic CRUD function with just a couple bits added that doesn't have all the bells and whistles is what actually lasts when I write code and requires less maintenance.

There's the stuff that wows people and the stuff that people actually USE.

ZoomZoomZoomyesterday at 12:23 AM

This is exactly why ReStructured Text is better/worse.

zelphirkaltyesterday at 11:43 AM

Saying, that it is the best compromise we know of is going a little far, I think. There are more readable intuitive formats, but they simply don't have the spread, that markdown formats have.

heresie-dabordyesterday at 4:36 PM

> barriers to producing documentation--should be minimized. Writing well is difficult enough!

Writing is a demanding kind of encoding. At the same time, we all expect but rarely get good, accessible, searchable documentation. Why? The one barrier that cannot be removed is the need to retain semantic structure.

In TFA, the author writes:

    The Bad -- We don’t know what we want.
It's exactly this. We fail to recognise why we write and then we fail to express it. We don't write technical documentation for the equivalent of KLOCs. Writing something useful and meaningful -- not just performative filler for KPIs or SEO enshittification -- requires structure. Anything valuable that can't be retrieved effectively is lost. Imagine losing actual code or database rows at the same rate.

We consistently fail to manage meaning. It's strikingly paradoxical because the art of programming is all about meaning. We organise code semantically because it is essential to do so (not just for compiling, but also) for extending/refactoring/review/retrieval/understanding.

We need to write with the same considerations. This need not be complicated. Yet we persist in using the wrong utensils for the recipe.

> Markdown is the best compromise we know of

It reduces keystrokes and makes the handraulic act of writing easier. But... it addresses only part of the problem.

As an example of a small improvement, HTML5 offers a minimal set of semantic tags: <summary> <article> <main> <section> <details> <aside> <figure> <figcaption> <time>

It may be a simplistic set of tags, but it is an improvement over easy-to-type text blobs.

xigoilast Friday at 6:31 PM

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.

show 5 replies
sphlast Friday at 10:44 PM

Worse is better doesn’t mean worst is best either.

show 1 reply
recursivedoubtslast Friday at 6:32 PM

I came here to say this.