小さなプログラムと言語

小さなプログラムと言語

ページ開始日: 2025-06-02

ページ公開日: 2026-07-28

私のForthの実装の記事は、特に小さなForth実装の話題について素晴らしいフィードバックを得ました。（そして、私がこれまで見た中で最も小さなForthをいくつかリストアップする口実になりました。）

小さなForth、小さな言語、小さなプログラム、そして一般的に小さなものへの魅力を感じているのは私だけではないと確信しています。一体どうしてなのでしょうか？

小さなプログラムの魅力

小さなプログラムはアプローチしやすいです。

何かが200行のコードだと見ると、2,000行や20,000行のものよりも、それを読む可能性がはるかに高くなります。

さらに、もしそれが20行で興味深いことを行い、私が2,000行を期待していたとしたら、その20行を読むことに非常に、非常に興味を持つでしょう！

RetroVを作成する前にDOM差分ライブラリを調査していたとき、私が調べたリポジトリの1つに、Luke Jacksonによるijkがありました。

当時の私は、JavaScriptの大きなライブラリを見ることに慣れていました。そのため、ijkのソースファイルを開いたとき、本当に驚きました。ソースはこちらです：index.js (githubusercontent.com)。

わずか25行！ 私はすぐに興味をそそられました。

さらに最近、前述のForthの記事への応答の1つとして、Philippe Brochardが46バイトの「Forth」を提示しました。

46バイト！

それはあまりにも小さいので、ヘキサダンプをここにそのまま掲載できます。

50b8 8e00 31d8 e8ff 0017 003c 0575 00ea
5000 3c00 7401 eb02 e8ee 0005 0588 eb47
b8e6 0200 d231 14cd e480 7580 c3f4

確かに、生の機械コードを読む機会に飛びつく人はほとんどいません。しかし、それがまさに私の言いたいことです。これほど小さいものは、それほど怖くないですよね？つまり、46バイトです。努力すれば、いつかはそれがどのように機能するかを理解できるとわかっています。

次の例は、コードが非常に密で恐ろしいため、反例として機能するかもしれませんが、それでも言及せずにはいられません。

私が最も好きなソフトウェアの物語の1つは、Roger K.W. HuiのAn Implementation of Jの付録A「Incunabulum」で、Arthur Whitneyが配列ベースの言語インタープリターを書いたことを説明しています。

「…AT&T 3B1コンピュータ上のインタープリターフラグメント。私はその組織とプログラミングスタイルについて、このインタープリターを約1週間研究しました…」

Huiは、それが単一のページ、122行の信じられないほど難解なCコードであるため、付録全体にインタープリターをリストアップできます。ここでは表示できます。

私はまだ個人的にそのパズルに取り組んでいませんが、もし私が社会から追放され、山奥で一人で暮らすことになったら持っていくであろう、密なコンピュータ関連のもののリストに入っています。

（ちなみに、JはAPLを含む配列言語のファミリーです。簡潔さ、難解なプログラミングパズル、そして高性能な数値計算を楽しむなら、これらの言語はあなたをカバーしています！）

2026年7月更新: Arthur Whitneyといえば、Alex (alexalejandre.com)が私にリンクを送ってくれました。これはここに加える必要があるとすぐにわかりました。これを見てください：https://fall.tr/kos

Whitneyのk配列言語、kdbデータベース、そしてGUIとウィンドウマネージャーを90KBの起動可能なイメージに収めたオペレーティングシステム、kOSを説明したGeo Carncrossの講演のトランスクリプトです。個々のソースコードの統計も同様に印象的です（例えば、前述のGUIとウィンドウマネージャーのCコードは60行です）。そして、kdbはCで100行だそうですか？本当ですか？Whitney Cでさえ、それでも印象的です。今ではkdbに以前よりもさらに興味があります！そして、もしそれが少しでも興味を引くなら、記事Impending kOS (vector.org.uk)もきっと楽しめるでしょう。

私がその孤独な山に持っていくコレクションに間違いなく含めるべきもう一つのものは、William Byrdの講演「The Most Beautiful Program Ever Written」で、そのタイトルによると、LispインタープリターをLispで書いたものです。

(define eval-expr
  (lambda (expr env)
    (pmatch expr
      [`,x (guard (symbol? x))
        (env x)]
      [`(lambda (,x) ,body)
        (lambda (arg)
          (eval-expr body (lambda (y)
                            (if (eq? x y)
                                arg
                                (env y)))))]
      [`(,rator ,rand)
       ((eval-expr rator env)
        (eval-expr rand env))])))

再現か、根本的な真実か？

さて、コードゴルフ（wikipedia.org）がプログラマーのレクリエーションゲームであり、単に楽しみのためであることは皆知っていますよね？

しかし、これらは実際に役立つのでしょうか？

私は「はい」と言います。そして、さらに一歩進みます：それらは意味があるのです。

ビジネスカードに収まるレイ・トレーサー（fabiensanglard.net）を見ると、レイ・トレーサーはビジネスカードに収まるものであると気づかされます！

それはレイ・トレーサーの最小複雑性に関する実際の事実です。

「…あるオブジェクトを出力する（所定のプログラミング言語での）最短コンピュータプログラムの長さ。」

（コルモゴロフ複雑性については、カート・ゲーデルに関する本で学びました。それは、そうでなければ非常に乾燥して憂鬱な本の中で私の好きなものでした。）

これからの意味は、コードゴルファーが、全人類のために、プログラムの最小複雑性を表すバージョンを生成しているということです。コードゴルファー、よくやった！

Lispプログラミング言語の根本的な複雑性について、私たちは何を知っていますか？

それは、ガベージコレクションを持つLispに関する事実です。他のすべてを取り除いた場合、本質を436バイトにまで絞ることができます！

これは、概念がこの手持ちサイズにまで煮詰められることを意味するので、私はこれに慰めを感じます。そして、それは私がそれを自分の頭に収めることができるだろうという意味です。

Frank Forceのおかげで、3Dブラウザゲームが2KBの（信じられないほど圧縮された）JavaScriptソースに収まることがわかっています：2KBのJSに収まる3Dゲーム (frankforce.com)

そして、1980年代からコンピュータ向けのデモシーンが提供するものについては、まだ表面をかすめただけです。以下は良い出発点です：https://demoscene.assembly.org/

ミニチュアなものは楽しく、役立ち、そして意味があるのです。

私の言いたいことは、ミニチュア化/ゴルフ化されたプログラムの複雑な時計仕掛けを実際に研究する必要はないということです。ミニチュアは、その概念がビジネスカードに収まり、あなたの頭に収まることができるということを証明するのに役立ちます。読みやすいバージョンを見つけて研究してください。（ミニチュアは多くのことを教えてくれるでしょうが、そのうちのいくつかはミニチュアプログラムの作り方に関するものになるでしょう。）

小さな言語

小さなプログラムは興味深いです。しかし、私は小さなプログラミング言語にも興味があります。

一般的に言えば、言語が小さいほど、表現力は低くなります。

最もよく知られており、最も表現力の低い言語の1つはアセンブリです。

アセンブリ言語は、構文的にも概念的にも非常にシンプルです。言語はほとんどありません。それは主にオペコードニーモニックの厳格なシーケンスです。マクロを使っても、アセンブリでのコーディングは主に特定のCPUの命令セットアーキテクチャ、つまりISAのパズルを理解することです。（CISCとRISCプロセッサのアセンブリの構文を比較することでこれを証明できます。パズルは完全に異なりますが、言語は実質的に変更されません。）

ここでは、SNOBOLに名誉ある言及をしなければなりません。これは、上記の厳格な構文上の理由と、同様の制御フローの課題を提示するという点で、アセンブリ言語に似ています。CPUのように、ジャンプとコール/リターンしか理解しません。（他のすべての点では、SNOBOLは文字列マッチングと置換言語であるため、大きく異なります。奇妙で楽しく、非常に効果的です。）

構文的に小さな「高レベル」言語に進むと、これら3つは素晴らしいです。

• Forthは、ほぼすべての「小ささ」コンテストで優勝します。唯一の構文構造はスペース文字です。Forthは、まったく disturbingly な方法で、驚くほど柔軟で強力です。
• Lisp（特にScheme？）は、非常にシンプルな構文と巨大な表現力と柔軟性を持つ小さなコア言語を持っています。
• Tclは、ForthやLispと共に言及される価値があります。Tclはワイルドです。なぜなら、すべてが文字列であるという点は、最初は理解するのが難しいからです。ForthやLispと同様に、Tclで独自の言語を構築できます。

Forth、Lisp、Tclは、少数のコアアイデアを理解するだけで、無限の力を提供してくれます。これらの言語の構文コアは、インデックスカード1枚以下に収めることができます。

しかし、これらのツールを効果的に使いこなすには、「通常の」Algolライクな手続き型言語に慣れている場合、思考の大きな転換が必要です。

では、小さく、シンプルで、血の犠牲を必要としないものについてはどうでしょうか？

Luaプログラミング言語は、この条件を満たすと思います。コア言語の小ささを見てください。

このドキュメントの印刷版を持っていますが、薄い本です！Lua言語は冒頭でカバーされており、わずか27ページです。27ページ！ 私が持っているゲームのマニュアルよりも長いです。

C言語はかなり小さいです。Cで効果的かつ安全にプログラミングするのは非常に簡単だとは思いませんが、そのサイズにしてはコンパクトでかなり表現力豊かであることは否定できません。

新参者のZigはCライクです。しかし、私はそれが実際にはかなり大きいと思っており、効果的に使用するには多くのことを知る必要があります。（私もZigのファンであり、それだけの価値があると思っています。サイズには理由があります。）

JavaScriptは、かなり小さいコア言語を持っています。おそらくLuaと同等でしょう。関数、配列、オブジェクト（辞書として使用）は、私が使用するJSのほぼすべてであり、私はそのようにそれを気に入っています！

自然言語と同様に、より大きなプログラミング言語とのトレードオフは、うまくいけば、より大きな表現力です。

David Ungar（wikipedia.org）の素晴らしい講演「Self and Self: Whys and Wherefores」では、彼はSelfの多重継承の誤りを嘆いています。

「システムを少し単純にしすぎて、人が追加のコードを書く必要がある方が、奇妙に動作して誰も理由を理解できないシステムよりもはるかに良いです。したがって、単純さは表現力に勝ります。」

わかりましたか？スライドの箇条書きを覚えておくのに役立つように示します。

［画像: スライドの抜粋。「単純さは表現力に勝る」と書かれています］

小さな言語は、非常に、非常に慎重な設計があれば、かなり表現力豊かにもなり得ると私は思います。Forth、Lisp、Tclを思い出してください。

マイクロワールド: 小さく、自己完結型で、学習可能なプログラミング環境というアイデアも、彼の講演を見ているときに発見したDavid Ungarとの関連があります。「Microworlds」カードの「ARK」を参照してください。（SmithとUngarは、プログラミングにおける重要なマイルストーンであり、今日まで活発に開発が続けられているSelf言語（selflanguage.org）を共同で作成しました。）

フル機能のインタラクティブIDEが付属する言語は、明らかなマイクロワールドの候補です。

しかし、従来のテキストファイルベースのプログラミングもマイクロワールド体験を提供できると私は思います。そのためには、言語はコンパイラ/インタプリタと一緒にインストールされる高品質のドキュメントを備えている必要があります。そして、初心者でも理解できるエラー出力を目指すべきです。これには、何が間違っていたのかの説明や、修正方法、または詳細情報を見つける場所が含まれます。

ライブラリ: プログラミング言語の見た目のサイズで容易に見過ごされがちなもう一つの側面は、「標準ライブラリ」の関数、データ構造、メソッドです。

関数ライブラリも、サイズ対表現力の課題と全く同じ課題に直面していると思います。

例えば、JavaScriptのRamda（ramdajs.com）関数型プログラミングライブラリを学ぶことは、新しいプログラミング言語を学ぶのと非常に似ており、私はそのすべてを学ぶことができませんでした。Ramdaの合成可能性とカリー化された関数の整合性は、私にとって非常に啓発的でした。私の助言：Ramdaは少しで十分です！

フィーリング: 私たちのツールにおける簡潔さには、ユーティリティを超えたある種の品質があります。小さなものは喜びを spark させますよね？

なぜ小さなものがそれほど楽しいのでしょうか？

一般的な小さなものの魅力

私は常にミニチュア、ジオラマ、小さなスケールモデルに魅了されてきました。

私だけではないと確信しています！

Stephanie M. Langin-Hooper、『Figurines in Hellenistic Babylonia』の著者、Tiny Things and Why We Love Them（cambridgeblog.org）で次のように書いています。

「…等身大のものを小さなスケールに縮小する行為は、影響力のある効果があります。そのオブジェクトは今やキュートで、よりアプローチしやすく、より繊細で、「squee」です。それはまた、より無力であり、したがって制御可能であり、その小さなサイズのために慰めとなり、完全に脅威ではありません。」

これは、私が有用なコードの小さな断片を見たときの反応と全く同じです。

また、「制御可能」という言葉はコンピュータの文脈では非常に気に入っていますが、段落の感情は、例えば人形について話す場合、少し変わります。

小さなスケールは、「大きな」ものをアプローチしやすくするのに役立ちます。

「現実世界の等身大の世界では恐ろしいかもしれないことを、ミニチュアではより管理しやすく、より想像しやすくすることができます。」

小さなものは、「低リスクの実験を可能にします」。そのため、スケールアップする前に物事の小さなモデルを構築することがよくあります。

Simon Garfield、『In Miniature: How Small Things Illuminate the World』の著者も、同じような答えをたくさん持っています。彼はSmall world: Why we love tiny things（theguardian.com）で次のように書いています。

「答えは、私たちの習熟と解明への欲求にあります。規模を縮小した秩序と照明を、そうでなければ制御不能と感じるかもしれない混沌とした世界にもたらすことによって、人生を豊かにする能力は過大評価できません。[…] 最も単純には、ミニチュアは、より少ないもので、より多くを見る、学ぶ、そして感謝する方法を示してくれます。」

私はこれが、Assembly Nightsで私が得るものの大きな部分だと考えています。小さなスケールと秩序だった論理、そして内部の一貫性があります。広大で深遠な現実世界とは異なり、オフラインのコンピュータは、もし十分な時間努力すればすべてを理解できると信じることができるファンタジーの世界です。

「小さなものを観察することからの満足感は、小さなものを作りたいという欲求になります。そして、両方の段階が、理解と秩序への人間の欲求に応えます。私たちは巨大で不吉な宇宙に生きており、そのごく一部を制御することは、私たちの秩序と価値の感覚を回復させます。」

私はしばらくの間コンピュータの歴史を研究してきましたが、表面をかすめたにすぎません。しかし、私が発見したことの1つは、私たちの分野の「大きな」成果の多くは、個人が「小さな」問題を新しい方法で解決してきた多くの「小さな」勝利の蓄積にすぎないということです。

「私たちは、すべてを排除して自分自身を埋めることができる小さな宇宙を創造します。ドールハウスのモデラーからジグソーパズル愛好家、大人の塗り絵まで、献身的な家庭的趣味の前提条件である現実世界を一時的に遮断することは、瞑想的で、静かで、視野が狭く、そして不可欠です。世界がそれに依存しているかのように小さな詳細にしゃがみ込んでいる人々は、単に彼らの世界がそれに依存しているからそうしているのです。」