Markdownで十分に完璧な解決策があるよ。新しい革命的な技術が車輪の技術を置き換えないのと同じだね。

私にとって、Markdownは他のマークアップ言語に比べて余計な認知負荷が多いんだ。• 太字やイタリックにアスタリスクを使うかアンダースコアを使うか決めなきゃいけない。• 箇条書きにアスタリスク、ハイフン、プラスを使うか決めなきゃいけない。• 解析に関するいろんなルールや例外を覚えておかなきゃいけない。

Markdownは、Usenetやメール、他のテキストメディアで既に使われていた慣習をしっかりと組み込もうと頑張ったことも忘れないでね。引用を示すための「>」は、Usenetで広く使われていた慣習だったし、強調を示すためのアスタリスクやアンダースコアも一般的な慣習だった。どちらも合法だし、どちらも一般的だったからね。特に強調するためのダブルアスタリスクやダブルアンダースコアもよく使われていたし、箇条書きを表示するためのアスタリスクや段落を分けるための空行、コードを書くための4つ以上のスペースのインデントもそうだった。これは「道を舗装する」デザイン哲学の良い例で、ユーザーが既にやっていることをする方が、理想的な世界を押し付けるよりも良いってことだね。そして、それがうまく機能しているんだ。

「悪い方が良い」ってのは、「最悪が最高」って意味じゃないからね。

これがまさにReStructured Textが良い/悪い理由だよ。

「悪い方が良い」ってのはすごく古い考えだよ。論文の中で、コペルニクスは「悪いお金が良いお金を追い出す」って原則を提唱した。これは後にサー・トーマス・グレシャムによってグレシャムの法則として知られるようになった。この現象はニコル・オレスムによっても以前に指摘されていたけど、コペルニクスは独立して再発見したんだ。グレシャムの法則は、ポーランドや中央・東ヨーロッパではコペルニクス＝グレシャム法則として知られている。 https://en.wikipedia.org/wiki/Monetae_cudendae_ratio

「それが私たちが知っている最良の妥協だ」と言うのはちょっと行き過ぎだと思う。もっと読みやすくて直感的なフォーマットはあるけど、マークダウンのように広まってはいないんだよね。

私たちは、人々が最小限の摩擦で書き出しを行うことを奨励したいんだ。書くことへの障壁、特にドキュメントを作成する際の障壁は最小限にすべきだよ。うまく書くのは十分難しいから！ AsciiDoc（またはreStructuredText）みたいなものはどう？ * https://docs.asciidoctor.org/asciidoc/latest/asciidoc-vs-mar... * 「マークダウン、AsciiDoc、またはreStructuredText – ドキュメントをコードとして扱う物語」: https://news.ycombinator.com/item?id=33468213 簡単なことはまだ簡単だけど、必要な人にはもっと高度な選択肢があるみたいだね。

ドキュメント作成の障壁は、最小限に抑えるべきだよね。ちゃんと書くのも十分難しいのに！ 書くって、すごく要求される作業なんだよね。同時に、みんな良い、アクセスしやすくて検索可能なドキュメントを期待してるけど、実際にはほとんど手に入らない。なんでだろう？ 取り除けない障壁の一つは、意味の構造を保持する必要があることなんだ。TFAの著者はこう書いてる：「悪い点は、私たちが何を求めているのか分からないことだ。」まさにその通り。私たちは、なぜ書くのかを認識できず、その結果表現できなくなってる。技術的なドキュメントを書くのは、KLOCのためじゃない。役に立つ、意味のあるものを書くことは、KPIやSEOのためのパフォーマンス的な埋め草じゃなくて、構造が必要なんだ。効果的に取り出せない価値のあるものは、失われてしまう。実際のコードやデータベースの行を同じペースで失うことを想像してみて。私たちは常に意味を管理するのに失敗してる。プログラミングの技術は意味に関するものなのに、これは非常に逆説的だよね。コードを意味的に整理するのは、コンパイルのためだけじゃなく、拡張やリファクタリング、レビュー、取り出し、理解のためにも必要だから。私たちも同じ配慮を持って書く必要があるんだ。複雑である必要はないのに、レシピに合わない道具を使い続けてる。 > Markdownは、私たちが知っている中での最良の妥協策だよ。キー入力を減らして、書くという手作業を楽にしてくれる。でも…それは問題の一部しか解決してない。例えば、HTML5は最小限の意味的タグを提供してる。簡素なタグのセットかもしれないけど、簡単に入力できるテキストの塊よりは改善されてる。

逃れられない真実なんだけど、魔法のような解決策を考えた後でも…時には基本的なCRUD機能にちょっとした機能を追加しただけのものが、実際にコードを書くときに残るし、メンテナンスも少なくて済むんだ。人を驚かせるものと、実際に使われるものがあるよね。

ただの見出しだし、フォントもサイズも色もない…ただの見出し。だから、どんなデバイスでも表示できるし、どんな紙にでも印刷できる。どんなアクセシビリティツールとも連携できるし、読者の要求に最適化されるんだ。作成者が「これが良い」と思ったものじゃなくてね。ああ、HTMLとウェブの目標がそれだった頃を思い出す？本当に美しい数年間だったよね。

Markdownは素晴らしい。なぜなら、たくさんのことを定義しないから。見出し？それは見出しだよ、フォントもサイズも色もなし…ただの見出し。それは、どんなデバイスでも表示できて、どんな紙にでも印刷できて、どんなアクセシビリティツールとも連携でき、読者の要求に合わせて最適化されるってこと。書き手が良いと思ったものではなくね。HTMLやLaTeXの\section{}を書くときみたいに。

HTMLは有効なMarkdownだよ。だから、MarkdownとXMLを対立させる理由がよくわからない。XMLは基本的にMarkdownのサブセットだし。これは有効な マーク _ダウン_だよ。MarkdownはHTMLの上にさらに複雑さを加えるものだね。

読み書きが簡単で、もっと定義がしっかりしている別のソリューションもあるよね… Asciidocが思い浮かぶ。

rstで本を書いたことがあるけど、アドモニションやインポート、用語集、インデックスの機能があって、Markdownよりも良かった。ただ、見出しの規則は嫌いだね。

Markdown自体は、見た目が良ければ満足する単純な開発者の僕には物足りないんだよね。確かに、Markdownはその目的には不十分なツールだよ。著者には、HTMLやLaTeX、SVGなど、もっと強力なツールを使ってもらいたい。Markdownは、軽いフォーマットやシンプルなヘッダー構造には向いてるけどね。もし僕がそんなに怠け者じゃなければ、CommonMarkとは逆の、MarkdownDownみたいなものを考えつくかもしれない。代替フォーマットやエスケープ、複雑な構文を排除して、どこでも使える簡単で明確、安全なサブセットを目指すんだ。意図的に制限されたものね。（普段はOrg Modeを使ってる。お気に入りのエディタでのサポートが圧倒的に優れてるから。）

その通り。自分のメモはMarkdownで書いてるけど、ビューアアプリがなくても使えるしね。もっと良い代替があるかどうかもわからない。このフォーマットは、カジュアルな使い方や半分真面目な使い方には十分だよ。

僕はひどいミックスを使ってるよ：• Markdown（最近のメモはほとんどこれ、以前のプレーンテキストの代わりにね。）• シングルファイルHTML（FancyなドキュメントがMarkdownの限界を超えるときに使う。MarkdownにHTMLを埋め込むことはできるけど、レンダラーによって許可されるものやサニタイズの仕方が違うし、スタイルタグの使い方もバラバラ。印刷用のCSSルールを調べることもあるよ。ターゲットがPDFや実際の印刷になることが多いからね。たまにJavaScriptも！）• Googleドキュメント（Androidのクソみたいなアプリ！）「適材適所のツールを使う」って言いたいけど、自分を過大評価してるかも。

まさにそれ。今はMarkdownをレンダリングされたかのように読んでる。テーブルだけはプレーンテキストだと見た目がひどいけどね。他の部分、見出しや太字、イタリック、リストなんかは、正直言って違いがわからない。経験を積んだ映画を字幕付きで見るようなもので、脳が隙間を埋めて、気づかないんだよね。

YAMLはあんまり得意じゃないし、好きでもないんだ。でも、CommonMark準拠のパーサーを作りたいなら、Markdownはちょっと無茶だよ。伝えたいシンプルさに対して、あまりにも複雑すぎる。リストを見てみて、自由にネストできて、他のブロック要素も含められるんだから。それは極端なオーバーキルだよ。そんなに柔軟性が必要なら、どんな「シンプル」なマークアップも間違った選択だね。

残念ながら、プレーンテキストは見栄えが良くなくて、組版のコントロールも良くないんだ。少なくとも、僕が見るほとんどのMarkdownは「生」の状態だとほとんど読めないよ。手動でフォーマットされたモノスペースのテキストの方がずっと読みやすい。そうすれば、アスタリスクを箇条書きや脚注マーカー、強調マーカーとして同時に使えるし、普通のタイポグラフィのルールに慣れてる人なら何が何だかわかるから。

専用のエディタがあるのに、なんでマークダウンみたいなクソみたいなものをターゲットにするの？ あなたの保存形式は、どんなツールでも編集できるようにしてるよ。専用エディタは好まれるツールになるけど、唯一のツールでも一番重要なツールでもない。マークダウンとそのエコシステムは、エディタよりも前にあったんだよね。

専用のエディタがあるのに、なんでマークダウンみたいなクソみたいなものをターゲットにするの？ だってマークダウンは標準のテキストフォーマット言語だから。みんなが使ってるフォーマットだよ。 > でも、本当にドキュメントの意味を気にするなら、マークダウンで書かない方がいいよ。 でも、みんなが使う標準のテキストフォーマットなんだよね。

すごいね。

少なすぎる（変な空白のセマンティクスを保持して、余分な改行が必要、/イタリック/ マーカーのための非明示的な under 、混乱するリンク構文の多様性、リストマーカーが多すぎたり少なすぎたり（なんで • が使えないの？）遅すぎた？でも、当時の中途半端なマークダウンの試みの代わりに、素晴らしいスタートになったはずだよ…

Djotは今のところ素晴らしいと思ってるし、Pandoc Markdownから切り替えるのが楽しみ。Pandoc Markdownのエディタサポートが不足してるからね。リポジトリの問題を見てると、すでに一部の熱心な人たちがDjotの仕様を超えた機能を実装してるから、ちょっと心配になってる。みんなv1.0を待ちきれないみたいだね…

Djotの簡素化のほとんどは好きなんだけど、インデントの変更ごとに空行を入れてネストリストを書く必要があるのは、私には致命的だな。- Djotは - ネストリストを書くのに - 空行を挟む必要がある - 同じレベルのリストアイテムの間に - 空行を省略できる - でもこのリストアイテムはダメ そう、空行なしでインデントされたリストアイテムをサポートするのは、Djotのパーサーを複雑にするだろうけど、私はノートでネストリストを書くことが多いから、余分な空行は内容から気を散らせるんだ。私にとって、ファイルを解析しやすくするために生のテキストを汚くする価値はない。Djotは、ハードラップされた行を一つの段落やリストアイテムに戻そうとしなければ、空行の要件を避けられたと思う。それなら、私はテキストをソフトラップしかしないから、問題ないんだ。Djotがハードラッピングをサポートする選択をしたせいで、全てのユーザー（ハードラップする人も含めて）がネストリストの構文が悪化してしまった。