プレーンテキストは何十年も続いてきたし、これからも残る

 (unsung.aresluna.org)
2 ポイント 投稿者 GN⁺ 4 일 전 | 1件のコメント | WhatsAppで共有
  • 等幅プレーンテキストベースのダイアグラム・UI設計ツールが再び使われており、テキスト編集インターフェースへの親しみやすさとファイル形式の移植性が長く続く力を与えている
  • Mockdown、Wiretext、Monodraw のようなツールは、限られた視覚的選択肢を保ちながら軽量なダイアグラムを作るのに向いており、ソースコード内に入れる用途にも合っている
  • Mockdown はウェブとモバイルですぐ使え、Wiretext はウェブで動作するがデスクトップ専用で、Monodraw はMacアプリとして提供される
  • 1970〜1980年代に頂点を迎えた方式が、Turbo Vision のような TUI 系を思わせる形で戻ってきており、現代的な感覚や性能、ウェブアクセシビリティ、マウス・トラックパッド操作性が加わっている
  • コンピューター性能が高まるほど、自ら制約を設ける作業スタイルがより有用になり、こうしたプレーンテキストツールはますます gen AI の入口としても使われている

プレーンテキストツールの持続性

  • プレーンテキストまたは「ASCII」ベースのダイアグラム・UI設計ツールとして Mockdown、Wiretext、Monodraw が挙げられている
    • Mockdown はウェブですぐ動作し、モバイルにも対応している
    • Wiretext はウェブで動作するが、デスクトップでのみ利用できる
    • Monodraw は Mac アプリとして提供される
  • こうしたツールは、意図的に限られた視覚的選択肢を好むとき、ソースコードに入れる軽量なダイアグラムを作るとき、そしてますます gen AI の入口としても使われている
  • 1970〜1980年代に頂点を迎えた方式が、現代的に再びよみがえっている
    • Turbo Vision のような TUI 系を思わせる
    • そこに現代的な感覚、性能、ウェブアクセシビリティ、マウスとトラックパッドの操作性が加わっている
  • 制約を設ける作業スタイルそのものが重要になってきている
    • コンピューター性能が高まるほど、自ら制約を課して作業をより簡単にすることはすでに有用である
    • AI の普及とともに、自己制約は仕事をより難しくする方向でも重要になっている
  • 等幅プレーンテキストは、ファイル形式の移植性だけでなく、インターフェースとしてのテキスト編集が広く知られていて強力であるという点でも、長く続く力を持っている
  • Mockdown の ASCII spray は、特に面白い要素として挙げられている
  • ここでいう「ASCII」は、厳密な技術用語というより、反復アニメーションを総称して「GIF」と呼ぶのに近い口語的な表現である

関連記事

1件のコメント

 
GN⁺ 4 일 전
Hacker Newsの意見

  • 例としてプレーンテキスト会計が挙がっていたのはうれしかった
    QuickBooksからBeancount+Favaへ個人事業の帳簿を移したが、はるかに満足していて、テキストベースの請求書システムや車両の走行距離追跡も組み合わせ、税務ステータスのある支出には証憑書類が必ず関連付けられるよう validator も入れてある
    QuickBooks よりずっと速くて使いやすく、広告を見る必要もなく、git と RFC3161 のコミット証明を組み合わせることで、いつ何を追加したのか証明できるし、不注意なテキスト編集で記録が消える可能性も減り、各項目がいつ作られたかも簡単に確認できる
    要するに中身はすべて plain text だが、必要ならブラウザでも扱えるように Fava 拡張も追加してあり、グラフまで表示できる TUI Fava があればさらに良いが、Web UI でも十分に満足している
    あとは会計士がこれをどう見るかだけだ

    • Beancountを初めて知ったが、かなり魅力的だ
      自分はアメリカ人だが他国で働いていて、常に2通貨を扱う必要があるのに、Gnucash ではマルチ通貨の扱いに満足できず、夫婦でこれまでテキストファイルに記録してきた
      フォーマットはかなり一貫して使ってきたので、Beancount へ移す際に変換スクリプトを書くか LLM の助けを借りれば、作業の 95% くらいは自動化できそうで、パースできない項目だけ警告として出せばよさそうだ
      自分も Beancount + Fava に行く可能性が高い
    • これは自分のplain text accountingプロジェクト群にとって本当に良い刺激になる
      とくにRFC3161 コミット証明をどう使っているのかもっと詳しく知りたい
      コミット作成者が本人であることを示すために GPG で署名するのだろうとは思うが、外部タイムスタンプサービスや外部 CA を使うのか、それとも独自の信頼チェーンを作るのか気になる
      会計監査人が帳簿コミットの真正性を求めた場合、実際にどんな資料と手順で立証することになるのかも知りたい
    • こういうやり方は本当にいい
      自分で単純なファイル形式を作るときも、必要になればより一般的な形式へどう変換するかを常に考えている
      必要なときに他人へ渡せる脱出経路があると思うだけで安心できる
      このケースなら、会計士が受け入れられるCSVにも簡単に変換できそうだ

  • 全盛期は 1970〜80 年代だったかもしれないが、1990年代初頭の DOS時代にも非常に優れた TUI は多かった
    Windows が完全に支配する前で、たいていは VGA 互換のグラフィックカードとモニターがあり、高解像度で鮮明、しかもフォントまで調整できるテキストモードが使え、マウスを備えていることも多かった
    自分が育ちながら親しんだのも、まさにそういう環境のQBASICとEDIT.COMだった
    当時のアプリには、まともなマウスカーソルまで実装していたものさえあり、Bisqwit の動画がそれをよく示している: https://www.youtube.com/watch?v=7nlNQcKsj74

    • あの時代のBorland コードエディタが本当に好きだった
      Turbo-C、Turbo-Pascal などに入っていたエディタで、IDE と呼んでもいいくらいだった
      テキストモードのWordPerfect、WordStar、Lotus 1-2-3もかなり優秀だった
    • 自分にとってTUI の頂点に近いのは Norton Commander か Midnight Commander だ
    • むしろTUI の全盛期は今だと思う
      ターミナルと設定ファイル中心で動く OS であるOmarchyを見ると、ほとんど楽園に近い
      今後、機械との主要なインターフェースがテキストベースの対話になる世界へ進むなら、この流れがどこまで広がるのか楽しみだ
      ここでは AI の話をすると嫌がる人も多いだろうが、自分はその未来を心から楽しみにしている

  • タイトルを見て本文とは少し違う方向へそれるが、plain textがシンプルで堅牢なコンピューティングの基盤だと信じるなら、Dylan Beattie の There's no such thing as plain text という発表を見る価値がある
    https://www.slideshare.net/slideshow/theres-no-such-thing-as-plain-text-dylan-beattie/249952971
    いろいろなカンファレンスの動画も簡単に見つかる

    • まだ動画は見ていないが、スライドだけを見ると要点の一つはエンコーディングの問題のように見える
      UTF-16LE や UTF-16BE のような例もあるし
      幸い、今ではUTF-8が事実上のデフォルトになっているので、特別な理由がない限り、ほとんどの文書は UTF-8 だと仮定してよい
      エンコーディング不明のテキストファイルを受け取っても UTF-8 である確率は 99.7% くらいだと思うので、今なら再びplain text というものは存在すると言ってよい気がする
    • スライドショーだけでは論旨がつかみにくい
      code page やUTF-16のようなものもすべて plain text だが実はそうではない、という話なら、その主張は 2026 年時点ではかなり時代遅れに感じる
      今では UTF-8 は事実上どこにでもある
    • 以前からその表現は使っていたが、ちゃんとした発表がすでにありそうだという漠然とした感覚だけ持っていた
      こういう資料が実際にあるのを見るとうれしい
    • 自分はその主張に強く同意しない
      Unicodeのように複雑で奇妙なシステムは plain とは呼べず、今でも多くのアプリで Unicode 関連の問題は頻繁に起きる
      本当にどこでもうまく動くテキストシステムは依然としてASCIIだけだと思うし、そのくらいで初めて plain text と呼べるのではないかと思う
      英語中心に制限されるという意味ではあるが、多くの環境ではむしろそれが自然で、自分も英語ネイティブではないがその立場は擁護できる

  • Plain textは本当に素晴らしい
    自分のメモ 20 年分以上を https://github.com/nickjj/notes で管理している
    請求書も 7 年ほど https://github.com/nickjj/invoice で plain text 方式で処理してきた
    収支追跡用には https://github.com/nickjj/plutus もあり、とても満足している
    今では銀行の CSV をエクスポートして Plutus に入れ、数分かけてカテゴリを少し合わせるだけで帳簿が終わる
    このやり方で確定申告も 2 年続けて処理している

  • テキストはLindy 的だ
    時間の試練に耐えてきたし、SQLやTCP/IPと同じくらい広く普及している
    Graydon Hoare の古い記事 Always bet on text も思い出す
    [1]: https://news.ycombinator.com/item?id=8451271
    [2]: https://graydon2.dreamwidth.org/193447.html

  • ここではHNも plaintext に含めるのか気になる
    たしかにサイトは HTML とハイパーリンクでできているが、実際の使用感はクリック可能なテキストインターフェースに近い
    暗号学的には HTML も ascii/utf-8 でエンコードされているので plaintext と言えるが、MIME type では text/plain と text/html が文書構造やスタイル情報を区別している
    ターミナルもよく plaintext と見なされるが、実際には人間がそのまま読むには難しいescape sequenceでメタ情報を含んでいる
    逆にソーシャルメディアには数行の文字が入った画像も多いが、最近のモバイルプラットフォームは画像内テキストを認識して選択までできる
    だとすると、ほかに要素がなく文字だけが載った画像は plaintext なのか、という疑問も出てくる
    結局自分が聞きたいのは、初期実装から数十年が過ぎた今、plaintext の境界をどこに引くのかということだ

    • HN は単なる普通のHTMLなのだから、plaintext と呼んでもそこまで無理はないと思う

  • 本文とは少し違う話だが、テキスト文字ベースの統計チャートを思い出した
    昔、DOS 用の教育版MINITABを使ったことがあるが、テキスト文字で scatter diagram、dotplot、box-and-whisker plot を描いてくれた
    純粋なテキストや ASCII、あるいは DOS の罫線文字をオプションで使えた記憶がある
    正式な統計検定に入る前に、まずデータを探索させるのが狙いだった
    こういう形でちゃんとしたdotplotをターミナルに描いてくれるプログラムが今でもあるのか気になる

  • いちばん上の一覧はもっと長くできそうだ
    https://asciiflow.com/
    https://asciidraw.github.io/
    ほかに知っているツールがあるなら気になる

  • M-x artist-modeもあり、Emacs からそのまま使える

  • plain text はたしかに良いが、構造化が必要になった瞬間に、ファイルごとに毎回ゼロから始めることになりがちだ
    古い Unix ツールを即席で組み合わせて plain text を処理するやり方に郷愁を抱く人は多いが、そうしたアプローチは一時的な場面では役立っても、よく仕様化されたフォーマットの代わりにはならない

    • XML, JSON, YAML, RDF, EDN, LaTeX, OrgMode, Markdown のような構造化 plaintext フォーマットは十分にたくさんある
      行ベースの普通のテキストとして処理できるし、構造化データ変換も可能で、それを WYSIWYG のようにレンダリングしてくれるクライアントやリーダーもすでにそろっている