これは、多彩で興味深いポッドキャストStray PointersのホストであるJim Lawless氏と私が交わした会話を、軽く編集してえーなどの言い淀みを取り除いた文字起こしです。収録は1月15日（米国時間）に行われました。Forth、C、CGI、Python、Go、AWKについて語っています。

音声はエピソードのウェブページまたはYouTubeでお聴きいただけます。

Jim: 今夜はエンジニアリングマネージャー兼ソフトウェアエンジニアのBen Hoytさんをお迎えします。Benさん、番組へようこそ！

Ben: ありがとうございます。

Jim: Benさん、新版『The AWK Programming Language』の技術監修（あるいは技術査読）をされているのを見て、あなたの業績に注目したんです。そこから調べていくうちに、プログラミング言語に関してとても興味深い経歴をお持ちだと分かりました。そこで、プログラミングのバックグラウンドについてお聞きしたいんです。どのように始められたのか、最初に使った言語は何だったのか、といったことを。

Ben: ええ、かなり昔に遡ります。子供の頃、そうですね、80年代後半から90年代初頭に始めました。最初に覚えているコンピュータはSega SC-3000というゲーム機で、キーボード一体型の小さなコンピュータのようなもので、BASICがインストールされていました。父が——今も元気ですが、もう引退しています——本業は牧師で、夜は趣味でプログラミングをする、Forthプログラマでした。

父はそのコンピュータでいろいろといじっていて、確かForthを動かしたり、他にもいろいろやっていたので、私たちもそうしたものに触れる環境にありました。当時はほとんどゲーム、パックマンなどで遊んでいただけでしたが、家にはコンピュータ雑誌が転がっていて、巻末にちょっとしたBASICゲームのプログラムが載っていて、雑誌の後ろのページから全部打ち込まなければなりませんでした。いくつかやってみたのですが、1つでも打ち間違えると全体がまったく動かなくなるので、うまくいったためしがありませんでした。でも、父の興味もあって、そうしたことがきっかけでプログラミングに入っていったのだと思います。

Jim: 特にForthへの興味についてお聞きしたいのですが、まだ10代の頃にHans Bezemer氏と共著でForth Dimensions誌に記事を書かれたそうですね？

Ben: ええ、その通りです。あれが初めて公に発表したテクニカルライティングだったと思います。その後テクニカルライティングがとても好きになり、今はブログも書いています。ただ、あの記事は少し早すぎたかもしれません。あまりきちんとした査読も受けていませんし、まあ当時としては良い出来ではあったのですが。記事の内容はForthにおけるルックアップテーブルの素晴らしさについてで、彼と共著で書きました。

Jim: Hans氏とはどうやって知り合ったのですか？　彼は今ではForth界隈では4tHコンパイラ（数字の4にT-H）でちょっとした有名人ですよね。

Ben: ええ、その通りで、当時からそうだったと思います。彼はもう長く活動しています。それ以来ほとんど話していませんが、ずいぶん昔にcomp.lang.forthかどこかのニュースグループでたまたまつながって、ルックアップテーブルについていろいろやっていて最高だと思っていると私が言ったら、彼もそれが好きだ、一緒にForth Dimensionsに記事を書かないかと言ってくれたんです。どちらから言い出したかは忘れましたが、おそらく彼の提案で共著することになりました。

それは良い機会でした。コードを書いて、他の手法よりどれだけ速いかという知見をまとめました。正直、ちょっとごまかしもあったと思います——指の組み方と微笑み方さえ合えば速くなる、というような条件付きで、実際にはほとんどの場合はそうでもなかったのに、そういうことにしてしまったんです。だから早すぎたと言ったわけです。当時はそれがキラキラして見えて、どうしてもルックアップテーブルをやりたかった。だからそれが答えで、すべての問いに答えるハンマーだったんです。

Jim: なるほど。では、優れたForth使いの例に漏れず、ご自身でもForthを実装されたわけですね。それについて少し教えていただけますか？

Ben: はい。父がForthにどっぷり浸かっていて、自作のForthコンパイラをいくつか書いていました。私も本格的にプログラミングを始めたとき、最初に使った2つの言語がx86アセンブリとForthでした。そしてDOS時代に8086アセンブリを使って自分でForthを書いたんです。Forthの素晴らしいところはとても小さいこと。自己ブート可能なコンパイラを、ほんの数千行程度の少ないコードで書けてしまう。アセンブリで書かれた小さなカーネルがあって、そこではプリミティブと呼ばれる、Forthカーネルを構成する基本操作を実装します。その上に残りの部分をForth自身で書いていくんです。最初に作ったものは、確かA86アセンブラというツールを使いました。ご存知かもしれませんが、なかなか優れたツールでした。

Jim: ええ、シェアウェアのアセンブラで、かなり人気がありましたね。

Ben: そうなんです。当時は10代でお金がなかったので、フリー版しか使ったことがありませんでしたが、本当に良いアセンブラでした。最初のバージョンのForthは、A86でカーネルを書き、その上にForthで残りを書くという形でした。その数バージョン後には、Forthコミュニティでメタコンパイルと呼ばれている、ForthでForthを構築する、つまりForthコンパイラをForthでビルドする方法を理解しました。そのためにはForthで書かれたアセンブラがほぼ必須なので、ネットから1つ持ってきて、理解するためにほとんど打ち直すような形でハックしたのを覚えています。当時はそういうふうにして多くのことを学びました。

Jim: Bill Ragsdale氏が6502用の有名なアセンブラをForthで書いて、80年代初頭にDr. Dobb's Journalで発表したものがありますが、あれをモデルにしたのですか？　それともx86向けの別のものを使ったのですか？

Ben: いえ、x86専用のものでした。名前は覚えていません。コードのコメントに残っていないか見てみますが……どうやらこのコードでは出典をコメントに書いていなかったようです。いずれにせよ、x86用のアセンブラをベースにしたもので、どれだったかは思い出せません。

Jim: なるほど。では、そのForthシステムを作った後、Forthで何を作ったのですか？　どんなソフトウェアを書かれましたか？

Ben: それがForthの面白いところで、Forthでは何もソフトウェアを書かず、ただForthコンパイラを書き続けるんですよ。[笑] 何を書いたかというと、小さなゲームやグラフィックス関係ですね。Forthをいじっていたのと並行して、デモシーンにもハマっていました。ご存じないリスナーのために説明すると、デモシーンは自分でグラフィックスや音楽のデモを作って披露することを楽しむプログラマーのサブカルチャーです。4Kデモのようなコンペもあって、凝ったグラフィックスを4Kという容量にどれだけ詰め込めるかを競うんです。ニュージーランドではBBSを通じてそのシーンに少し関わっていました。BBSで学んだことも多く、グラフィックスやゲームっぽいものを作っていて、その一部をForthでやったんです。

あと、Forthでやったもう一つのことは——これは数年後のことですが——386用の自作32ビットOS、つまりForth OSを書いたことです。非常に軽量で、OSと言っても極めてミニマルなキーボードドライバ、ディスクI/O、スクリーンドライバくらいしかないものでした。

Forthは私の考え方を本当に形作りましたし、今もそうだと思います。もう使ってはいませんが、考え方に大きく影響しています。Lispのような、哲学的と言いますか、頭をひっくり返されるようなクールな言語の1つですね。その影響で、私はいつも小さくて速くて軽いもの、カーネルに至るまで全体を上から下まで理解できるようなものに惹かれてきました。

ただ、デモシーンの活動の一環でTurbo Pascalも使うようになりました。シーナー（デモシーンの参加者）の多くが使っていたんです。Cも少し触りましたが、その頃の私にはまだ少し難解でした。ちょうどその頃に高校を卒業して大学で電気工学を学びました。大学の電気工学科にはちょっと変わった制度があって、3年間の課程の最初にプログラミングの授業があって、そこでCの小さなコース、小テストを受けて、Cを書いたり質問に答えたりして、それに合格すれば残りの課程では他のプログラミングの授業を一切取らなくてよい、というものでした。私はそれに合格したのですが、それは失敗でした。プログラムは書けても、ソフトウェア工学やより大きな視点でのことは分かっていなかったからです。だから本当の意味でCを身につけ、大きなプログラムの構造化やソフトウェア工学を学んだのは、大学卒業後に仕事を通じてでした。いわばOJTで学んだんです。Cが私にとって最初の本格的な言語でした。

Jim: 当時は電気エンジニアとして働いていたのですか？

Ben: 電気工学を学びましたが、最初の仕事では自然とコーディングの方に傾いていって、ちょうど会社でもそれが必要とされていたので、それ以来ずっとそちらにいます。電気の方はほとんどやらなくなって、学位は活かしていません。

Jim: それは組み込み系のCだったのですか、それとも一般的なアプリケーション向けでしたか？

Ben: 良い質問ですね。最初の仕事の半分くらいは組み込みで、小さなマイコン用の小さなブートローダーや、極小マイクロコントローラ用のデバイスドライバを書いていました。最近よく耳にする「組み込みLinux」という言葉を聞くと、いや、それは組み込みじゃないだろうと思ってしまいます。2GHzのプロセッサに1GBのRAMでしょう？　私がやっていた意味での組み込みは、2KBのRAMしかない小さな16ビットや8ビットマイコンでの話です。会社で使っていたチップの1つがMSP430で、その後はARM7になって、しばらくして32ビットも扱うようになりました。

Jim: 当時はチームで働いていたのですか？

Ben: とても小さな会社で、チームと言っても、もう一人、とても優秀な電気エンジニア兼ファームウェア開発者がいただけで、彼が最初のメンターで本当に良い人でした。Garyという名前で、プログラミングにおける本当のソフトウェア工学的な側面を学ぶのを助けてくれました。

Jim: 2人の開発チームでそういったことを学べたのですか？　つまり、バージョン管理やソースの共有、ビルドパイプラインといったようなことですが。

Ben: それらはもっと後のことです。彼からはソフトウェア工学や計算機科学の基礎のいくつかを教わりましたし、現場で触れることで学んだこともあります。当時彼はバージョン管理をあまり信じていなかったので、私もそれを学びませんでした。だから、それが当たり前になったのは後のことですが——念のため言っておくと、今は信じています。

Jim: 良いことですよ。

Ben: 素晴らしいものですよ！　今は何でもGitを使っています。バージョン管理やCIなどは、キャリアのかなり後になってからのことです。そこではプログラミングの基礎や構造化について学びました。組み込みの一部ではCを使っていましたが、当時まともに使えるプロフェッショナルな道具はCしか知らなかったので、取り組んでいた気象システムのウェブバックエンドもCで書かなければなりませんでした。ウェブページをレンダリングして綺麗なグラフを描き、GIFファイルを出力する必要があったのですが、知っている言語がCしかなかったので、CベースのCGIスクリプトとして書いたんです。CGIやウェブには最悪の選択でしたが、仕事は果たしてくれました。私が辞めた後を引き継いだ人たちはきっと呪ったでしょうが、当面の問題を何年も解決してくれました。

Jim: 次に学んだプログラミング言語や技術は何でしたか？

Ben: その後、2人の兄弟とスタートアップをやりました。microPledgeという名前で——詳しく話すこともできますが、プログラミングの側面に絞ります——そこでPythonを学びました。それ以前からPythonには興味があって、ウェブアプリケーションを作るならCよりずっと良いだろうと思っていましたし、実際その通りでした。兄弟とのスタートアップを通じてPythonを覚えたんです。

兄弟の1人はその時点ですでにしっかりしたPython開発者だったので、そこでPythonを学び、テストを学び、バージョン管理を学びました——そういったすべてがスタートアップでの経験の一部でした。スタートアップ自体は失敗しましたが、Pythonやソフトウェア工学の面でキャリアに必要なスキルを教えてくれたという意味では成功でした。Pythonがそのときの言語で、今でも使い続けています——今の仕事でもメインの言語です。あれは本当に良い経験でした。

Jim: Pythonのos.scandirにコントリビュートされたとおっしゃっていましたね？

Ben: ええ、それは数年後のことです——タイムラインを確認してみます。2016年にそれについて書きましたが、始めたのはその数年前、そうですね、2012年でした。再帰的にディレクトリ構造を辿る方法を探していて、当時はWindowsで——Windows上のPythonでした。Windowsのエクスプローラーでフォルダを右クリックして再帰的なディレクトリのサイズを取得すると、スキャンしているのが見えるものの、とても速く取得できることに気づいたんです。同じことをPythonでos.walkを使ってやると、かなり遅い。なぜだろうと調べ始めました。Pythonでもエクスプローラーがやっていることと同じくらい速くできるはずだ、と。

ところが、os.walkの設計と実装のせいで、大量の余計なシステムコールを行っていたんです——Windowsがファイル名を取得するために使うFindFirstやFindNext呼び出しに加えて、すべてのファイルに対してos.stat呼び出しをしていたんです。本当はその追加のstat呼び出しは不要でした。Pythonは呼び出しを行って情報の半分を捨て、さらに追加の呼び出しをしていたわけで、scandirを使えば、半分を捨てることなく、ディレクトリを再帰的に辿りながら必要な情報を取得できるようになります。

Jim: とはいえ、これはすべてのプラットフォームに移植可能だったのですよね？

Ben: はい。WindowsとLinuxでは異なるOS呼び出しを使いますが、考え方は同じです。WindowsのFindFirstやFindNextはより多くの情報を返してくれて、ファイルのすべての属性を取得できます。Linuxではサイズなどは返してくれず、ファイルタイプ——ディレクトリかファイルか——だけですが、それでもLinuxで「これはディレクトリか？　そうなら再帰する、違えばしない」を判断するためのos.stat呼び出しを1回節約できます。だからWindowsでは大幅に速くなりましたが、Linuxでもスピードアップしました。ネットワークファイルシステムではさらに速くなります。想像できる通り、ネットワーク呼び出しの回数が減る効果はより大きいからです。

Jim: ではos.walkは非推奨になったのですか？

Ben: いいえ。os.walkはscandirを使って再実装されました。scandirはより低レベルなツールで、全体のアイデアはos.walkを高速化することでした。構造はほぼ同じまま、listdirとos.stat呼び出しを使っていた部分をscandirを使うように書き換えて再実装できたんです。だからos.walkのシグネチャをまったく変える必要がなく、スクリプトでそれを使っている人はscandirの存在を知らなくても自動的にパフォーマンス向上の恩恵を受けられました。これは本当にクールなアイデアとして印象に残っています——中身を完全に変えてしまえる、というのは後から考えれば当たり前のことですが、実装を丸ごと変えることで、みんながただで高速化の恩恵を受けられる。多くのスクリプトがos.walkを使っていたので、たくさんの人が恩恵を受けました。

Jim: CGIプログラムを書いたり、兄弟とスタートアップを立ち上げてPythonでウェブの仕事をされたということでしたが、機能するウェブサイトを作るにはHTMLやJavaScript、データベースといった他の技術も身につける必要があったのではないですか？

Ben: ええ、かなりいろいろと。データベースやHTMLは——まあHTMLはCの仕事で覚えましたが——兄弟とのスタートアップに入ったとき、SQLデータベースは確かに初めてでした。初めてリレーショナルモデルに出会ったときはちょっと頭が混乱しますし、考え方がかなり違います。慣れるまでに少し時間がかかりましたが、本当に強力なもので、それ以来ずっとSQLデータベースを使ってきました。ですから確かにデータベース、そしてJavaScriptにも少し触れました。当時はJavaScriptはまだウェブサイト全体をそれで書くようなものではなく、おまけのような存在でした。今でも、HTMLで済むことが多いのにまずJavaScriptに飛びつく風潮は好きではありません。

Jim: そのことについては「the small web」というエッセイでも触れていますね。

Ben: まさにそうです。それは前に話したことにもつながりますが、私はずっと速くて軽くて小さいものが好きでした。今のウェブはページが肥大化して大きくて遅いものが多いですが、一方で気にかけて画像サイズを小さくしたり、動作を遅くしているJavaScriptの量を減らしたりしている人たちもいて、そういうのは大好きです。今はそれに関するちょっとしたムーブメントもあります。「small web」はそのための緩やかな呼び名で、「indie web」という言葉もあります。みんなが自分のウェブサイトを自作し、より手作りで、基本に立ち返ることを大切にする動きです。

Jim: それはウェブだけの話ではありませんよね。Electronで書かれたアプリケーションが、厚いウェブ技術の上に構築されたデスクトップアプリとして存在し、肥大化をそのままデスクトップに持ち込んでいますから。

Ben: ええ、まったくその通りです。あの技術を再利用することの価値は分かります。部分的にはパッケージングの問題だと思います。Electronを取り込むのではなく、OSネイティブのブラウザ技術や、すでにマシンに入っているブラウザを使ってデスクトップアプリにする、という取り組みも見かけます。ツール名は忘れましたが、そちらに進むのであればより良い方向だと思います。

Jim: その後、技術的なスキルセットはさらに進化しました。次に学んだ技術は何でしたか？

Ben: そうですね、少し先に飛ばすと、PostgresやJSONといったウェブ技術もありましたが、長年ほとんどのことはPythonでやっていました。ただ、確か——いつだったか、ブログによると2017年ですが——2017年にGoogleのGoプログラミング言語を学びました。個人プロジェクトのために学んだのですが、そのすぐ後に次の仕事でGoを多用していて、仕事の面でもとても役に立ち、それ以来ずっと役立っています。

Jim: なぜGoを手に取ったのですか？　学べる言語はたくさんある中で、Goの何が良かったのですか？

Ben: 見た目が気に入ったんです。背後にベル研究所の古参の人たちがいるのも良かった。たぶんThe Go Programming Languageという本がBrian Kernighan氏と、今もGoogleのGoチームにいるAlan Donovan氏によって書かれているのを見たのもあります。Brian Kernighan氏の名前がそこにありましたし、Goを作った3人のうち2人はベル研の人たちでした。Goを設計した3人はKen Thompson氏、Rob Pike氏、Robert Griesemer氏で、そのうち2人は古くからのUnixやベル研の人たちだったと思います。

ただ、最初に目を引いた理由はそれではありません。Hacker Newsなどで見かけていて、設計思想が好きだったんです。シンプルな構文で、言語設計に対するKeep It Simple, Stupid的な姿勢がありながら、当時からツール群がとてもプロフェッショナルで優れていた。Goの人たちもそれをはっきり言っています。言語自体に新しいものは何もない、と。独自の概念がいくつかあるとはいえ、革命的、画期的なものは何もない。一番の売りはツール群や全体のまとめ方、ライブラリの品質だ、と。コンパイラの速さ。go testと打てば自動的にすべてのテストを実行してくれること。go buildと打って環境変数を設定するだけでクロスコンパイルできること——そういったことです。

Jim: Goで仕事を見つけたとおっしゃいましたが、Goを使う仕事を探したのですか、それとも単なる幸運な偶然でしたか？

Ben: 幸運な偶然でしたが、最終的には彼らがGoを使っていたこともあって選んだ部分もあります。ある程度は向こうも私を選んでくれたわけで、面接もGoベースで、Goの問題を解いたのを覚えています。Goのスキルを評価してもらえました。

Jim: その後、Goを使ってAWKプログラミング言語のインタプリタとトランスレータを作られましたね。AWKには最初にどこで出会ったのですか？

Ben: AWKに最初に出会ったのはどこだったか？　AWKの存在自体は長いこと知っていました。70年代の古いツールですが、あまり使ったことはありませんでした——私の経歴がDOSやWindowsで、LinuxやUnixではなかったこともあって。だからAWKはあまり身近になかったのですが、存在は知っていて、その後UnixベースのMacや、ちゃんとしたLinuxで開発するようになって、AWKをより目にするようになりました。

本当に火がついたのは、Brian Kernighan氏とA.W.K.の3人——Al Aho氏、Peter Weinberger氏、Brian Kernighan氏、AWKの3人の生みの親——によるThe AWK Programming Languageの最初の数章を読んだことでした。彼らが共著で書いた本です。主にBrian氏が書いたのだと思います——あくまで私の印象ですが——その本を読み始めて、The C Programming Language、いわゆるK&R本と同じスタイルだと感じました。簡潔で、中身がぎっしり詰まっている。

第2章の終わりまでにAWKのすべてが分かる、AWKのすべてを教えてくれて、残りの章では詳細に入り、AWKで小さなコンパイラを書いたり、小さなデータベースシステムを書いたりします——AWKでできることとして、なかなかクールな内容です。よく見かける難解なワンライナー構文というイメージから、AWKは「各行を読み込み、フィールドに分割し、フィルタにマッチすればアクションを実行する」という実はとてもシンプルな概念なんだと視野が広がりました。シンプルな概念ですが、その下には完全なプログラミング言語がある。そこで私の歯車が回り始めたんです。

当時、パースやプログラミング言語のインタプリタでいろいろいじっていたので、その2つを組み合わせて、これの小さなサブセットをGoで書けるんじゃないかと思ったんです。そして実際にやってみました——単一のフィルタと単一のアクションだけを取る、非常にミニマルなAWKバージョンを書き始め、そこからどんどん機能を追加していって、ある日、ああ、これはいっそ完全なPOSIX実装にしてしまおうと思い至りました。それはニューヨークにいた頃のことで、妻と家族で10年ほどニューヨークに住んでいて、毎日職場までバスと地下鉄で1時間かけて通勤していました。朝のバスの中で30〜40分、GoAWKプロジェクトをハックしていたんです。つまり、本当にニュージャージー・トランジットのバスの中で、ニューヨークへ向かう途中に書かれたものなんです。

Jim: 新版、第二版の『The AWK Programming Language』に携わることになった経緯は何だったのですか？

Ben: ええ——Brian Kernighan氏との最初のやり取りは、彼がAWKについて語り、自分の——いわゆる「one true AWK」と呼ばれる——AWKのバージョンをCSV（カンマ区切り）ファイル対応にアップデートしていると話していたインタビューを見たことだったと思います。それは私もGoAWKに追加したいと思っていたことでした。あるいはその時点でもう追加していたかもしれません。時系列は忘れましたが、GoAWKには追加したのは確かで、正確な時期は覚えていません。ただ、そのインタビューを見て、わあ、自分と同じことをやっていると思ったんです。

そこでBrian氏、Kernighan氏のコードを見始めて、これは素晴らしい、同じことをやっていると思いました。そして、彼のUTF-8の扱いに関して、パフォーマンス上の問題だと思われるもの——今思えば実際に正当な問題だったと思いますが——を見つけたんです。彼がやっていたもう一つのことは、CSVと、長年を経てAWKにUTF-8、つまりUnicode対応を追加することでした。余談ですが、AWKはUTF-8を処理する限りUnicodeを問題なくサポートしています。というのも、UTF-8はUnicodeの8ビットエンコーディングなので、Unicode文字を1文字ずつ処理しない限り、すべて問題なく動くからです。だからほとんどのAWKスクリプトは古いバージョンのAWKでもすでに問題なく動くのですが、1文字ずつ処理する必要がある特定の機能があり、彼が追加していたのはそういった部分でした。

文字列の長さを取得する場合、Unicodeで1文字ずつ扱うときは、バイト数ではなく文字列中のUnicode文字数が欲しいわけです。そこでパフォーマンス問題が生じました。strlen関数——AWKでいうlength関数——が、文字列の長さに対してオーダーNの、つまり線形時間の操作になってしまうんです。バイトを1つずつ数えてUTF-8をデコードして何文字あるかを数えなければならないからです。

つまり、文字列に対するlength操作が、超高速な定数時間（オーダー1）の操作から、文字列長に対して線形時間の操作に変わってしまうわけです。たいていは文字列が短いので問題ありませんが、AWKでJSONファイルを処理したり、本来AWKでやるべきではないようなクレイジーなこと——長い文字列を扱うようなことをする人もいますが——をやっていて、繰り返しlengthを呼び出すと、すぐにN二乗の問題になりかねません。ループの中でlengthを呼んでいたら、突然、意図せずN二乗になってしまうんです。長くなりましたが、要するに私はこの点を指摘したわけです。

私もGoAWKを同じようにUnicode対応に変更して、lengthをオーダーNの操作にしたことがありました。するとGoAWKを使っていたある人から、「ああ、これでスクリプトが壊れた。小さなJSONプロセッサが中くらいのJSONファイルで25分もかかるようになった！」という声が上がったんです。この指数的な振る舞いのせいでした。そこで私はGoAWKでのその変更を元に戻して、いや、これは難しすぎる、バイト単位に戻そうと決めました。そして、すでにGoAWKでその失敗を経験していたので、Kernighan氏に連絡して、「GoAWKでこのパフォーマンス問題に遭遇しました。JSONの処理のような特定のAWKの使い方でパフォーマンスが台無しになるかもしれませんよ」と伝えたんです。彼はそれが問題であることを認めましたが、元に戻すことはしないと決め、「この挙動を維持したい。影響を受けるスクリプトはそう多くないと思う」と言いました。おそらく彼は正しいでしょう——ほとんどの実際の用途には影響しませんが、そこにはちょっとしたパフォーマンストラップがあるわけです。

そうしてKernighan氏とAWKのことで話すようになり、数年後、彼はGoAWKで私の名前を見てプロジェクトを評価してくれていたようで、著書『The AWK Programming Language』の第二版を改訂する際にメールで連絡をくれて、「この本をレビューして、技術査読者の一人になってくれませんか？」と言ってくれたんです。

Jim: それは素晴らしい気分だったでしょうね。

Ben: ええ、本当に素敵でした。Kernighan氏の本の技術査読者に自分の名前が載るというのは、ちょっと誇らしい瞬間です。

Jim: もちろんです。では、Ben Hoytさんの今後の展望は何ですか？

Ben: 今はCanonicalで働いていて、そこではGoとPythonがよく使われています。実はCanonicalにもGoAWKプロジェクトを通じて採用されました。私にとっては単なるサイドプロジェクトだったのですが、Canonicalのかなり上の立場の人が連絡をくれて、「君のGoAWKプロジェクトをCanonicalでのちょっとしたサイドプロジェクトで使っているんだ。とてもクールだね。ところで、仕事を探しているかい？」と言ってくれたんです。

当時はちょうど仕事を探しているところで、目を配っていたので、それがきっかけでCanonicalで働くことになりました。GoAWK自体は仕事で使ったことはなく、Canonicalで本格的に使われているわけでもありませんが、それが仕事につながったんです。今やっているのはそういうことです。Canonicalでクラウドやネットワーキング、インフラ関係の仕事をしていて、今は主にPythonですが、Goも広く使われているので、関わっているプロジェクトの中にはGoのものもあります。メインの2つの言語を両方使っています。

Jim: RustやZigといった、最近人気が出てきている言語には興味がありますか？

Ben: Rustは注目していて、その可能性は好きなのですが、構文は嫌いなんです。定義上というか型システムによる安全性や、所有権などを追跡する仕組みといった可能性は好きです。ただ、学んだことがないのであまりコメントはしません。学習曲線が非常に急だと言われていて、Rustを学んだ人たちもそう認めていますから。構文もかなり多いですし、そういう意味ではあまり惹かれませんが、使い始めている人たちには拍手を送りたいです。

ただZigは、私が見た限りでは自分のメンタルモデルにすごく合っているんです。だからZigにはかなり惹かれています。私のざっくりした捉え方では、Zigはより良いCで、Rustはより良いC++といった感じです。Zigは好きです。まだ使ったことはありませんが、見たものは気に入っています——明示的であること、メモリ確保がすべて明示的になっているところとか。Goからいくつかの機能を取り入れてもいます。Zigは見た目が好きで、ぜひ学んでみたいと思っています。

Jim: 他に征服したい世界はありますか？

Ben: そうですね——GiftyWeddings.comという小さなサイドプロジェクトがあって、結婚式の引き出物登録サイトなんですが、しばらく運営している楽しい小さなプロジェクトです。月に数ドルの収入にはなりますが、金額としては小遣い程度です——ただ、主に新しい言語やツールを試すための実験台として使っています。だから時々バックエンドやフロントエンドを書き直して新しいツールを試すんです。それがなかなか面白くて——Goを学んだのもそのサイドプロジェクトを通じてでした。

最近はhtmxというライブラリというかツールキットに注目しています。ご存知ですか？　かなり人気が出てきているようで、仕組みが気に入っています——既存のバックエンドツールやHTMLをそのままにして、それを拡張するようなやり方で、「全部JavaScriptに置き換えよう」というのとは違う。今でもJavaScriptは使いますが、かなり異なるモデルで——ええ、htmxは見た感じが好きです。ぜひ試してみたいと思っていて、Gifty Weddingsのプロジェクトで試すかもしれません。

Jim: とても良いですね。Benさん、今夜はお時間をありがとうございました。お話できてとても楽しかったです。