HN does not often add new features. I assume this is the main reason HN has not added Markdown.

I would prefer that HN continues to NOT support Markdown. After all, the entire point of Markdown is that it should be readable in its unprocessed form [1]. Therefore, Markdown obviates its own utility: Why not just present the source text of a comment as-is? Why confuse non-savvy users with behaviour like collapsing line breaks [2]?

[1] "The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions." https://web.archive.org/web/20040402182332/https://daringfir...

[2] https://news.ycombinator.com/item?id=22677936

First, the processed form is more readable than the unprocessed form. And second, when I write a comment here in Markdown, what is displayed is worse than unprocessed Markdown. For example lists:

- One - Two

Lists require a new line between each item:

- One

- Two

Yeah, but it looks ugly, too much space between the items.

As implemented in most places, Markdown does many unexpected things to user text. e.g. changing numbers in lists, breaking some urls, breaking textart.

In Gitlab's Markdown, I don't know how to insert a backtick in between backticks. I tried escaping it with a backslash, by doubling it, etc. It seems impossible to put a single plainly-visible backtick.

HN could be said to have a very minimal Markdown, with it's support for using asterisks for adding italics. We can't have plain asterisks, because of that, though.

I rather have no Markdown than Markdown that doesn't have escaping facilities to allow expressing all plaintext.

Actually you could insert a backtick in between backticks in GitLab's markdown. ref: https://meta.stackexchange.com/a/82722

If one commenter wanted to get attention for their comment, they’d overuse large headings and bold. A lot of Markdown’s value comes from consistent use throughout a document (here, all comments).

I guess it's for historical reasons. Markdown wasn't really that popular before GitHub made it popular. Hacker News is older than GitHub.

HN does implement Markdown to some extent, such as lists, italics, quotes, code blocks, etc.

HN doesn't support lists or quotes at all, and I don't think the italic or code block support is exactly markdown compatible, though it's similar.

I can make lists just fine:

- One

- Two

  And quotes

The thing you are calling “quotes” is a code block, and the thing you are calling lists is no formatting at all, just HN presenting exactly the text you entered.

People use code blocks as quotes quite often, much to the chagrin of mobile users, but nonetheless, their being used as quotes make them de facto quotes on this site.

With regards to lists, as I can create them, that's all that matters, again the formatting doesn't need to be special, it just needs to exist.

> People use code blocks as quotes quite often, much to the chagrin of mobile users, but nonetheless, their being used as quotes make them de facto quotes on this site.

They aren't markdown quotes, which was the claim made. “People on the site use HN’s almost-markdown code blocks for quotes” is true. HN supports markdown code blocks and markdown quotes is not; it supports code blocks in a way that approximates markdowns, and has no separate quote functionality.

> With regards to lists, as I can create them, that's all that matters, again the formatting doesn't need to be special, it just needs to exist.

But...it doesn't. HN allowing you to type text and not transforming it at all isn't support for markdown (or any other kind of) lists. The claim upthread was that lists were another markdown feature that HN supported. It does not. Now, it's true that markdown’s markup for lists is itself a manner commonly used for presenting lists in unformatted text (a very big part of the idea of markdown is that it follows convention for plain-text presentation so that it is readable and recognizable without processing), but not recognizing or transforming a markdown feature isn't support for that markdown feature, even if by the nature of markdown the absence of transformation still leaves the intent recognizable.