長年Markdownを愛用してきた開発者が、なぜ今なおMarkdownを使い続けているのかを問い直す動画である。Markdownの簡潔さや歴史的功績を認めつつ、構文の曖昧さ、インラインHTML、パーサーの複雑化、セキュリティ脆弱性、ObsidianやMDXのような拡張による混乱を取り上げ、現代のLLMやエージェント時代におけるMarkdownの限界を批判的に掘り下げている。単なる懐古的な技術批判ではなく、より健全なマークアップ言語やビルドシステムの必要性を考える内容である。
Markdownへの長年の愛と違和感
私は覚えている限りずっと、Markdownの大ファンであり、熱心な支持者でもありました。キャリアに悪影響が出るほどです。会社に正式な履歴書としてMarkdownの履歴書を提出できないところには、文字どおり応募しませんでした。
履歴書全体をGitHubに置いていて、どうしても必要だったり、本当に興味がある会社だったりした場合には、GitHub上のMarkdownファイルへのリンクだけを載せたPDFを提出していました。
それくらい本気だったんです。
情報を見せるための凝った方法なんて、ちゃんとした、シンプルで信頼できる専用の言語があるなら重要ではないと思っていました。John GruberとAaron SwartzがMarkdownのような魔法みたいなものを作ってくれたことには、これからもずっと心から感謝し続けるでしょう。コンテンツをただ書くだけで、それがとてもいい感じに出力され、レンダリングされる。そんなシンプルで信頼できる方法があるのですから。
今でもMarkdownには、少し魔法のような感覚があります。大学時代にLaTeXを何とか使いこなそうとかなり頑張った人間として、Markdownが自分の中で腑に落ちた瞬間から、今に至るまで、私は基本的にあらゆるものをMarkdownで書くようになりました。
だからこそ、この記事はすぐに私の注意を引きました。
なぜ私たちはいまだにMarkdownを使っているのか。
Markdownが素晴らしいものであることは間違いありませんが、それでも私は喜んで同意します。私たちはMarkdownをやりすぎました。
Markdownの中に別種のコンテンツを埋め込むために、新しいファイル拡張子を作るところまで行った時点で、おそらく一線を越えていました。そして今や、私たちはLLMやエージェントや、そういったものを使う世界にいます。そのあいだのコミュニケーション手段としてMarkdownが使われているわけです。ますます疑わしい状況になっています。
近いうちにMarkdownについて話したいことはたくさんあります。たとえば、Markdownはメモリのための正しいプリミティブではないという話や、特定の場面ではMarkdownがプログラミング用のスクリプト言語として実はかなり優れているという話です。このあたりは今後、間違いなくたっぷり話すことになるでしょう。
ですが今日は、もっと根本的なところを疑ってみたいと思います。
なぜ私たちはいまだにMarkdownを使っているのでしょうか。Markdownの何がそんなに素晴らしいのでしょうか。そして、現代の私たちがやっていることに対して、より良い解決策はどのようなものになるのでしょうか。
まだ始めたばかりなのに、もう頭の中ではObsidianコメントが大量に浮かんでいます。そして皆さんがObsidian以上に好きなものがあるとすれば、それはおそらく今日のスポンサーでしょう。
CIをローカルで回したい開発者へのスポンサー紹介
質問があります。
CIを直すためだけに、動かないコードを何回コミットしたことがありますか。
私はたぶん、15コミットくらい積み上げたことがあります。ただCIが何度も何度も壊れるのを見ていただけです。そして私が欲しかったのは、さらにコミットを増やさずにローカルでそれを実行できる能力でした。理想を言えば、エディタやエージェントから離れる必要すらない形でです。
今日のスポンサーはRWXです。
RWXがどれほど速いか、エージェントと一緒に使うとどれほど素晴らしいか、あるいは本来待つ必要のないブロッキング処理を待たずに済むよう並列実行してくれることについて話すこともできます。RWXを使う理由はたくさんあります。
でも私はそのどれについても話したくありません。なぜなら、私はCLIに惚れ込んでいるからです。
CI用のYAMLファイルを書いたら、あとは彼らのCLIを実行するだけで、コードをコミットしなくても実行をトリガーできます。つまり、コミットして、プッシュして、全部が走るのを待つ代わりに、ローカルでCLIコマンドを実行すればいいのです。するとクラウドインスタンスが立ち上がり、キャッシュ基盤や彼らが正しく実装しているその他すべてのものを活用しつつ、動いたかどうかのフィードバックをすぐに得られます。
これだけで十分、魅力は伝わるはずです。
でも、それを彼らのエージェントスキルと組み合わせると、急に、ああ、なるほど、という感じになります。
真面目な話、Run Loopは本当にさまざまな問題に対する素晴らしい解決策です。テストできない難しい機能に取り組んでいるなら、テストを書き、それをコミットしてから、エージェントにこう伝えればいいのです。RWXのrunコマンドを実行してCIが通るようにして、通ったらコミットしてプッシュして、と。
これは本当に良いワークフローです。他にこれを持っているものがないことに驚いています。
しかもこれは氷山の一角にすぎません。掘れば掘るほど、CIを修正して開発を遅くするのではなく速くしてくれるRWX独自のやり方をありがたく感じるようになるでしょう。
あなたのエージェントを速くするCIに、swade.link/rwxから登録してください。
なぜ私たちはMarkdownを使い続けているのか
では、なぜ私たちはいまだにMarkdownを使っているのでしょうか。
人生には、喜びと怒りを同時に与えてくれるものがいくつかあります。食べると痛いチョコレートとか、Markdownとかです。
本当に、なぜなのでしょう。
半分くらいの時間、私たちは完全な言語としてすら使っていません。
ちなみに、これはかなり強い書き出しです。
HTMLは最高のプログラミング言語である。
HTMLしか知らないプログラミング言語はHTMLです、と言う人のことを聞いたことがあるでしょう。そして私たちは二人とも、不満げに目を回しながら、HTMLはプログラミング言語ではなく単なるマークアップ言語であるという論文の束から、プログラミング言語についての書類を取り出そうとするわけです。
つまり、はい、私たちのほうが正しいのです。でもその人には、私たちにないものがあるのでしょう。
人生です。
はい、もうやられました。記事はまだほとんど始まっていないのに。
一応言っておきますが、私の彼女は、私がHTMLやMarkdownについて話すと喜んでくれます。
でも、人それぞれですね。
注記として、著者がMarkdownについて話すとき、特に断りがない限りCommonMarkのことを指しています。なぜなら、それが曖昧でない構文仕様だからです。
私はこのプロジェクトが好きです。この言語を少しでも地に足のついたものにしようとする取り組みは本当にありがたいと思っています。壊れているのは仕様ではありません。言語そのものです。
おっと。
Markdownの良いところ
良いところ。
Markdownは、単純な文書を組版するために使われる最小限の言語です。やるべきことは一つだけでした。Markdownファイルを受け取り、HTMLファイルを出力することです。
その一覧はこれ以上ないほど読みやすく、補助がなくても簡単に書けます。C言語のように、作られる出力を見ることができます。太字は常に開始タグがあり、最後に閉じBタグが来ます。斜体も同じです。
カジュアルなユーザーであれば、学習曲線は存在しないも同然です。チートシートを一度見れば、もう準備完了です。
ですが、ここから悪いところです。
私たちはMarkdownに何を求めているのかわかっていない
私たちは自分たちが何を求めているのかわかっていません。
UIが欲しいのでしょうか。プログラミング言語が欲しいのでしょうか。わかっていません。
機能の肥大化が起きる唯一の理由は、仕様が不明確だからです。
最小限で、簡単に読めるマークアップ言語が欲しいなら、Markdownがあります。シンプルな話ですよね。
では、まったく同じ出力を生成する二つの異なる構文を見てください。
タイトルには単一のハッシュ、hello。ここで斜体にするには星を使い、I amに対してはこう。そしてunambiguousを太字にしたい。最後に引用ブロックでgrammarです。
だいたい私ならこのように書くと思います。unambiguousには二重の星を使っていたでしょうが、私は私です。
いや、実際には、unambiguousには二重の星を使い、そちらにはアンダースコアを使っていたでしょう。だから、私はこっちに近いのかもしれません。
でも、ヘッダー構文をこんなふうには絶対に書きません。まったく。
そうですね。最後の引用ブロック以外、この二つのあいだに構文の重なりはほとんどありません。
うわあ。
さあ、ここから楽しくなってきます。
Markdownがあなたの求めていたものではないことを見るのに、二つの目が足りることを願います。
これらは同一の二つの出力を生成します。そしてこれは氷山の一角にすぎません。
Markdownにはあまりに多くの悪い判断が焼き込まれていて、使おうとすると、自分が何をしているかわかったと思った瞬間に、積極的に反撃してきます。
太字、斜体、太字斜体から始めましょう。
Markdownでは、太字をいくつもの方法で書けます。二重の星構文、二重のアンダースコア、あるいはBタグです。
しかも、これは有効な太字の書き方の一部にすぎません。これはCommonMarkの場合です。CommonMark準拠を謳っていないものを使っている場合、同じ入力を生成する有効なものに普通に遭遇する可能性があります。
こんなものや、こんなものや、はい、もう本当に。
T3 Chatでは、こういうものを本当に大量に扱わなければなりませんでした。皆さんには想像もつかないでしょう。
Markdownレンダリングの奇妙なケースをすべて処理するのは、ばかばかしいほど難しいのです。ただし個人的には、LaTeXのエッジケースのほうがさらにひどいとも言っておきます。
なので、はい。
鼻で笑ってしまいます。
そして、こういう重なり合ったものについては、話し始めさせないでください。
ああ、これは解析しようとすらしたくありません。
よし、ここに二つの星がありますね。それからこれは斜体です。なので、この部分全体はここで太字になっていて、こちらは斜体になっています。ここも斜体です。Aはここでは太字で、斜体ではありません。そしてここで再び斜体になっています。ofは斜体です。これは斜体で、ここはたぶんledのところで斜体が二重になっています。
痛いですね。
あるいは、これ。
いや。だめです。お願いですからやめてください。
これは試す気すらありません。
この代物は実際あまりにも極まっていて、ReDoS、つまり正規表現サービス拒否と呼ばれるパーサー脆弱性の分類が存在し、これにも影響しています。
たとえばMarkdown-itに対する深刻度6.9のCVEです。これは正真正銘のDoS脆弱性です。リンクの中に大量の星を入れるだけで、処理できなくなります。
美しいですね。美しい。
はい、この文字列は65,553ステップかかります。どんなものでもぶっ壊せます。
素晴らしい。最高にクールです。大好きです。
では、ここからさらにどれくらい悪化し得るのでしょうか。
インラインHTMLというさらなる混沌
展示B。ASMは良いアイデアでした。でもこれはどうでしょうか。
コンパイラが砂漠の川のように最適なコードをほとんど生み出せなかった古い言語では、インラインアセンブリによって、開発者は性能上重要なコードを簡単に書けました。もちろんその代償として、コンパイラエンジニアの血と汗と涙、そして彼らの第一子の誕生が捧げられるわけですが。
そうですね。完璧なコードを得るためにインラインアセンブリを書くのは地獄です。FFmpegのようなプロジェクトが非常に大変でありながら、同時に非常に重要である理由の一つです。
インラインASMは、コンパイラが対応する前にSIMD演算のようなものを可能にしました。
初期のSIMD生成失敗の概観を知りたいなら、こちらを見るといいでしょう。
ああ、それは私が最も見たくないものですね。
では、この素晴らしいアイデアを、最も肥大化し、シングルスレッドで、サンドボックス化された環境に直接取り付けてみましょう。しかも、そこでは文書を書くためのシンプルで簡単な方法が期待されています。
そうして、Markdown内のインラインHTMLが生まれました。
ああ、これはひどい。
インラインHTMLを使うと、こんなことができます。
個人的に、MarkdownとインラインHTMLでは本当に多くの問題に遭遇してきたので、今ではこの著者側にさらに寄っています。
はい。
私は「span class fancy text elegant close span」と書く、単純なプログラマーです。「Div class animation」。そしてこちらが私のポートフォリオです。「close div」。
これってシンプルですよね。これってきれいですよね。
正しいMarkdown解析が例外的に難しい主な理由は、Markdown構文が理解しにくすぎるからではありません。それは問題の10分の1にすぎません。
本当の問題は、Markdownパーサーを出荷するには、親切なHTMLパーサーも一緒に出荷しなければならないことです。
Markdownの中でHTMLを使っているなら、最初からHTMLを使えばいいのではないでしょうか。
公平な指摘です。
今思い出しました。チャンネルの友人であり、今ここにいるかもしれないJacob Evansが、少し前にものすごく頑張っていたんです。今はもう諦めたように見えますが、彼はGitHubプロフィール用と自分のホームページ用に、単一のMarkdownファイルを使おうとしていました。MarkdownをHTMLとして配信することで、理論上は有効なHTMLホームページを書き、それを同時に自分のプロフィールとしてもレンダリングできるだけの重なりがあるからです。両者の間にコードを挟まず、文字どおり完全に同じバイト列でです。
結果は地獄でした。
彼はそれを機能させるために本当に頑張っていました。でも、彼が挑戦するのを見るのは本当に楽しかったです。
Markdownそのものは、著者のような単純な猿脳の開発者を満足させるほど強力ではありません。サイトが十分に良く見えたときにだけ満足するような人間です。
この場合の「十分に良い」とは、少なくとも基本的なLaTeXサポート、パッケージをインストールできるTikZサポート、PlantUML、Mermaid、カスタムスタイリング、カスタムショートコード、タグ付けと分類、適切な脚注、BibTeXサポートが必要だという意味です。
単純なツールに単純な仕事をしてほしいわけでもないのです。
絵を壁に打ち付けるには、ハンマーが必要です。この場合、ハンマーはMarkdownです。
でも、絵を描きたい場合はどうでしょうか。ハンマーでキャンバスに絵を描こうとした瞬間、キャンバスを壊してしまいます。
キャンバスを壊すということは、大量のCVEも意味します。主にクロスサイトスクリプティング脆弱性まわりです。
これで少し考えさせられますね。
考えながら、自分のブログを見て、自分のMarkdownがどれくらいひどいか確認してみたいと思います。しばらくこのことを考えていませんでした。
すでにここにhelmetがあります。素晴らしいですね。
YouTube動画なのでiframeを埋め込んでいます。つまり最初の13行、2段落目の時点で、すでに変なHTMLをやっています。
その後は問題ありません。
ああ、これはいい例です。リンクでもある画像タグが必要でした。だから画像のHTMLタグを角括弧の中に入れて、リンクを付けました。
素晴らしいと思いませんか。
呪われたものを見つけるのに、2本の投稿を確認するだけで済みました。
さらに呪われたインラインHTMLです。
いやあ、昔の私は文章を書くのが本当にうまかったですね。構文がひどいのが残念です。
そういうことです。
Markdownをより面白い用途に使いたいと思った瞬間、結局は呪われたものを書くことになります。
インラインHTML、プラグインフック、埋め込み実行エンジンを許可するたびに、攻撃対象領域は広がります。結果は予測可能です。主要なMarkdown実装で繰り返し発生するクロスサイトスクリプティング脆弱性、そしてそれ以上の多くの問題です。
そしてこれは、市場に出回っているバイブコーディング製のパーサーによって、今後も増え続けるでしょう。
はい。
Markdownをどう解析するかを見直そうとする試みをたくさん見てきました。なぜなら、すべてのエージェントがMarkdownを吐き出すからです。私たちは、より良く、より速く、より信頼できるものを作りたいと思っています。
しかし、そのどれもがエクスプロイト、エッジケース、脆弱性などでいっぱいなのです。
どうやらObsidianのMarkdownはさらに呪われているようです。きっと私は気に入るでしょうね。
古く曖昧な構文という遺産
私が大好きなものといえば、ここからは展示C、古くてわかりにくい構文です。
Markdownは、World Wide Web周辺にある優れた技術の多くと同じように、懐かしき2000年代に作られました。
Markdownは、メールやUsenet投稿でプレーンテキストをマークアップするために存在していた慣習に着想を得ています。
念のため言うと、2000年以前の真面目なメールの多くはこんな感じでした。
各行の先頭にコロンを置く引用構文が見えますか。ああ、最後は署名で終わっています。うわあ。
この美しさが見えますか。引用構文、パイプによる縦方向の区切り。Markdownに必要とされたのはこれでした。もっとも、MarkdownではインラインHTMLの黒魔術なしに画面をn個の部分に分割できないので、そこではひどく失敗することになるのですが。
しかしこの遺産のせいで、見出しを書く方法が二つあります。普通の方法とATX方式です。
太字と斜体を書く方法が二つあり、さらにそれをめぐるCVEは二つ以上あります。
水平線を書く方法が二つあり、そのうちの一つはsetext見出し構文と衝突します。
順不同リストを書く方法が二つあります。
順序付きリストがありますが、どう順序付けしたかは気にしません。
そして脚注構文があります。これは文法全体を文脈依存文法へと移動させます。
Markdownでリストを書く「正しい」方法を初めて見たときのことを覚えています。正しいのは、数字を全部ゼロにすることだという話でした。そうすればMarkdownパーサーが正しく番号を振ってくれて、項目の順番を変えたときにすべての番号をやり直す必要がないからです。
うわあ、本当にいろいろありますね。
あ、ああ、この行を見落としていました。
この言語は文字どおり、マークアップ言語界のC++です。
いやあ、これを見てしまったら、もう見なかったことにはできません。完全に正しいです。
これはおそらく、OOP is garbage動画を除けば、私の一番好きなプログラミング動画かもしれません。2時間の動画で、途中で止めて一時停止し、あとで戻らなければなりませんでした。というのも、ほとんどの2時間動画と違って、その動画は良すぎてバックグラウンドで流し見できなかったからです。
実際に座って集中し、2時間ずっとスマホを見つめていました。当時のルームメイトに、大丈夫かと聞かれました。私はこう答えました。大丈夫どころじゃないよ。あとで君もこれを見ることになるから。
本当に素晴らしい動画です。強くおすすめします。
それを知っていて、今も頭の中に残っている状態で、C++とMarkdownと言われると、たしかにかなり重なります。
ほとんどすべてのことが二つの異なる方法でできます。そのうちのいくつかはクロスサイトスクリプティングを可能にするかもしれず、しかもどういうわけかHTMLでメモリリークまで起こすかもしれません。
どこでも使われていますが、同じようにどこでも失敗します。
Markdownは単に解析すれば済むものではない
そして展示Dです。
Markdownは、ただ解析すればいいものではありません。使わなければならないのです。
解析は簡単なほうです。
覚えているなら、私は脚注構文によってこの文法が文脈依存のものへ押し上げられると言いました。
説明しましょう。
引用用にキャレットを使ったこの構文があるとします。これはここにtest bracket oneという形になります。
しかし下の方で実際に引用を処理すると、Markdownが変わります。なぜなら、これは今度はリンクになるからです。以前はただこれを入れていただけでしたが、後ろにあるこの部分が、ここにある部分の解析方法を変えるのです。
ああ、これは大変です。
ただし実際には、脚注はCommonMarkではサポートされていません。CommonMarkにはリンクがあります。唯一の注目すべき違いは、リンク構文では定義の後に置けるのが一語だけであり、ピザにバナナを載せるのがなぜ良いアイデアなのかという恥ずかしい説明を置けないことです。
参照スタイルのリンクと脚注には、グローバルな定義解決が必要です。トークンの意味が、文書内の別の場所にある宣言に依存します。それは純粋な文脈自由解析の仮定を壊します。
したがって、CFGからCSGへ更新されるわけです。
私たちが使っているMarkdownは文脈依存文法なのではないかという直感は少しありましたが、これは本当に、本当に決定的な例ですね。
うわあ。
これらすべては、結局こう言うためのたくさんの言葉です。
シンプルな言語が欲しいなら、それはシンプルであるべきです。
難しいのはレンダリングです。
著者のこの批判の中で最も物議を醸す部分はここだと思います。なぜなら、誰も認めたがらないからです。私たちが使っているものと、私たちが必要としているものは、まったく違うということを。
素のMarkdownに必要なのはトランスリテレータです。文字どおり一対一対応のマッピング関数です。太字を見たらHTMLの太字が出てくる。それだけです。
しかし現代のMarkdownは、脚注のようなものをサポートしなければなりません。すると、この単純なトランスリテレータは本格的なコンパイラへと変わります。
そしてこの段階を踏んだ後、あなたは次のはしごを登ることになります。
個人用ナレッジ管理システムが必要です。
ああ、Obsidianの人たちはこれを気に入るでしょうね。
要件として、脚注が必要です。
いいでしょう。私たちは今、CSG文法にいます。コンパイラを作ったわけです。
ああ、カスタムコールアウトが欲しいのですか。HTMLとMarkdownを結びつけるフックが欲しいのですか。
では、依存関係グラフがあります。
数学が必要です。
では、組版ライブラリの統合も必要です。つまり依存関係グラフは、実行エンジンも伴って、はるかに複雑になりました。
カスタムスタイリング、カスタムCSSが欲しいなら、ファイルベースのスコープ規則に従ったCSSインジェクションにも対処しなければなりません。これは本当に楽しいですよ。
一つのMarkdownファイルにCSSを書いて、それが他のものを壊さないようにする。幸運を祈ります。楽しんでください。
これは素晴らしいセクションです。きっと皆さんも気に入るでしょう。
ObsidianでMarkdownを使って自分のニーズを満たすためにやらなければならないことを考えると、Notionが内部的にWordとExcelをコピーした判断のほうがまともだったように見えてくると、本気で思います。
そうです。著者は、MarkdownがあまりにひどいせいでNotionがまともに見えると言っているのです。この異常さがわかりますか。
正直に言うと、ここで私の熱い意見を落としておきます。
私はNotionにおけるMarkdownの使い方が好きです。実質的にはホットキーとしてのMarkdownです。NotionからMarkdownをエクスポートすることはできますが、そのフォーマットは壊れていてゴミです。本当にひどいです。
だから、それはやらないでください。
でもNotionで入力しているとき、たくさんの新しいホットキーを覚えなくても、Markdown構文を使って要素を変えられるというのは本当に便利です。
たとえば、この動画用のNotionドキュメントを見ているとして、「sup」と書いたとします。そして、これは実はタイトルにすべきだと思ったら、ハッシュ、スペース。これでタイトルになります。
ああ、もう少し小さいものにしたいなら、ハッシュ二つ、スペース。ハッシュ三つ、スペース。
これは本当に便利です。
ただし、それは別のユースケースです。私たちが使っている構文とは違います。これは、私たちが慣れ親しんだ構文または文法が、実質的にホットキーレイヤーとして使われているということです。
面白いですね。
WaboがMarkdownのasync構文をリンクしてくれました。
これはJSですが、それでもawaitを伴う実行をブロッカー内で行うこの構文は、あまりに呪われています。
これはVueレベルの呪われ方ですが、マークアップ言語の中にあるのです。
Async Markdown。一度たりともやってはいけません。
これは恐ろしいです。気分が悪くなってきました。
ああ、まだあるのですか。
これはObsidian内でテキストとして書かれたDataView JSですか。
いや、だめです。これは一切関わりたくありません。
助けてください。ここから逃がしてください。
解決策は何なのか
では、著者によれば、私たちはこれをどう解決するのでしょうか。
8086アセンブリで30年以上の経験を持つ、威厳ある髭の男性に聞けば、答えはプレーンテキストです。
MacBookとOpenClawを持ち、3台のMac miniを動かしながら1日1社スタートアップを作るような人に聞けば、答えはMDXです。
いや、私は3台のMac miniを持ったOpenClawの人ではありません。この部屋には3台のMac miniがありますが、電源が入っているのは1台だけです。
私でさえ、MDXがここでの正しい答えではないことはわかっています。
Cで生計を立てている人に聞けば、答えはreStructuredTextです。
著者に聞けば、答えは「どれでもない」です。
これらの解決策はすべて、それぞれのやり方で壊れています。
プレーンテキストは美しいですが、ヌルポインタの逆参照が何かわからない人には見せられません。
reStructuredTextは、読むだけで決して書かないなら素晴らしいです。
MDXはHTMLになろうとするのに忙しすぎて、読みやすくなければならないことを忘れています。
そしてそれらすべてにおける最大の問題は、ビルドシステムがないことです。
私たちは速度の名のもとに手を抜いてきました。
もしビルドシステムがあり、必要な目的に合わせて作られた、健全で曖昧さがなく、読みやすい構文があれば、すべての問題は解決されると思います。
インラインHTMLを許可しないでください。テキストを操作するための、明確に定義されたショートコードと関数を許可してください。
コンパイルの前、途中、後に実行されるカスタムフックを許可してください。
ああ、つまりあなたはAsync Markdownに賛成なのですね。
そして何より重要なのは、すべてを定義することです。
私たちに必要なのは、目的に合わせて作られたカスタムツールです。言語と呼ぶ勇気を持ってしまったフランケンシュタインの怪物ではありません。
Markdownやマークアップがプログラミング言語であるべきだと言っているのではありません。私たちはそれをプログラミング言語のように使おうとしていて、しかもそれには形式的な基盤が欠けているため、両方で失敗していると言っているのです。
私は本気で、より健全なマークアップ言語と、その周りにある適切なビルドシステム、そしてコンパイル時フックのサポートがあれば、正しい制約のもとで、この周辺の多くの問題を解決できると思っています。
この時点で、私たちはMarkdownを完全に手放し、別のところに答えを探すべきです。おそらく、些細なほど簡単に解析できる文法を持つものにです。
マークアップ言語とプログラミング言語の境界
彼はここで、形式言語理論のセクション全体を用意しています。
マークアップ言語とは、テキスト文書の構造、書式、または各部分の関係を制御するために、テキスト文書に挿入される記号の集合からなる標準的なテキスト符号化システムです。
そしてプログラミング言語とは、デジタルコンピュータに対する詳細な命令の集合を表現するための各種言語、つまりコンピュータプログラミング言語です。
はっきりわかるように、これらの公式定義は進むべき道ではありません。
だから彼は、別の定義を使います。
言語は、チューリング完全であればプログラミング言語である。
ああ、ということはMarkdownは間違いなくプログラミング言語ですね。
私は仕事でJavaScriptを書いているので、EBNFや文脈自由言語には踏み込みません。
チューリング完全性に関するこの深みに興味があるタイプの人は、説明欄の記事を読んでください。
ああ、これらの言葉はどれも聖書には載っていません。
数学的公理の集合を、証明可能性から非証明可能性へ分けるものは、再帰的な自己参照の欲求であり、それは一般的な乗算操作として現れます。
些細な観察が、非些細な反応を引き起こすことがあります。
はい。
ああ、これを見落としていました。
いやあ、これを忘れていました。これは2012年のものです。
Jeff Atwoodが、GruberにMarkdownを手放すか、少なくともより良い標準を作ろうとする試みに祝福を与えてほしいと懇願する記事を書いていました。
ああ、これは実際本当に良いですね。これが実現していたらよかったのにと思います。残念です。
John Gruberの元のmarkdown.plは、私が読んだ中で最悪の小規模プログラムの一つです。露骨なバグと誤機能だらけで、ユーザーを絶えず悩ませます。手書きの多段正規表現ベースのスパゲッティパーサーという、もともと低い基準から見てもひどいものです。
誰もこの元のスクリプトを使うべきではありません。そして残念ながら、世にある他の実装の多くは、そのばかげたエラーすべてを再現した直接的な移植なのです。
たとえば、文書内の別のトークンのMD5ハッシュに言及すると、そのハッシュがそのトークンに置き換えられる、というようなものです。なぜなら、それをインラインエスケープ機構として使っているからです。
Redditは、このためにフィルターを通り抜けたクロスサイトスクリプティングウイルスにやられました。
なんてことだ。
そして、昨年の「Markdown is a disaster」という別の記事もあります。
すごいですね。
Markdownという混沌と戦っている人々の静かなカルトが存在するとは知りませんでした。でも、それを見るのは本当に面白いですし、この記事を書くために時間を割いた著者には大きな敬意を持ちます。
Brock、この記事を書いてくれてありがとうございます。これは素晴らしい読み物でした。
自分がMarkdownをここまで嫌っていたとは気づいていませんでした。私は毎日使っているのに。
この記事によって、Markdownがいかに悪いものかをより深く理解する方向へ、完全に背中を押されました。
残念ながら、この著者はTwitterなどへのリンクを載せていないので、彼のブログ以外に皆さんを送り込む先はありません。ですが、こういうものが好きな人には、ぜひ確認することをおすすめします。元記事にはさらに楽しい詳細がたくさんあります。自分で読んでみたい人はぜひどうぞ。
私はもうほかに言うことはありません。
このHTMLシャツを着ている自分の皮肉に気づかずにはいられません。そして、自分のものを全部HTMLで書き直したい衝動、あるいは自分で新しいマークアップ言語を作りたい衝動に抵抗しようと思います。
皆さん、私にそれをやらせないでください。
T3 downは解決策ではありません。でも認めます。
少しだけ誘惑があります。
では、また次回。
平和であれ、ナードたち。
コメント