ORACLE.COM/JAVAMAGAZINE /////////////////// NOVEMBER/DECEMBER 2016

27

//junit 5 /

Binstock：最近はFacebookで仕事をされているようですが、どのようなことをしているのですか。Beck氏：エンジニア教育に取り組んでいます。正式な肩書きはテクニカル・コーチですので、ペア・プログラミングを行ったり、エンジニアと話したりするというのが仕事の大半です。Binstock：そこでコーチを受けるエンジニアは、ベテランですか。それともこの分野の仕事に就いたばかりの新人ですか。Beck氏：あらゆるレベルのエンジニアです。私はある特定のレベルのエンジニア集団をコーチしていると、その人たちが直面している問題のパターンを見つけようとし始めます。それに正直なところ、同じことを話し、同じ問題を扱うのは退屈です。ですから、そうした問題を扱うためのコースを作るつもりです。私たちには、コースを受講した人たちをエンジニアとして次 と々送りだすことに長けている部門があります。大卒の新人向けのコース、技術指導者に移行するエンジニア向けのコース、外部から中途採用された技術指導者向けのコースがそろっています。Facebookの社風は一般とはかなり違うので、人に命令して従わせる方法ではうまくいきません。Binstock：Facebookのような職場で働いていると、ほとんどの開発者が遭遇しないような違ったスケーリングの次元を経験しているのではないでしょうか。Facebookでは何が違いますか。プログラミングに関するあなたの意見をスケーリングの面から伺うとすれば、意見は違ってきますか。

Beck氏：それはいい質問です。要約するのはとても難しいので、具体的な例を挙げて説明します。ロギングが非常に重要です。場合によっては、パフォーマンスがかなり重要です。わずかなパフォーマンスの低下でサイト全体がダウンすることがあります。資産のほか、CPUや帯域幅やその他すべての面で非常に効率的に運用しようとしているため、余裕がほとんどないことがあります。ですから、特定の複数のチームで、多くのものを失いながらもほんの少し得るものがある、という状況は、普通ではありません。ロギングが重要なのは、何かひどいことが起こっ

た後でデバッグできるからにほかなりません。機能は実際に必要となるまでは追加しないのがよい（YAGNI：You aren't going to need it）とされる従来のエクストリーム・プログラミング方式では、作成されない機能であっても、ここFacebookでは、必要になるだろうと思われるならば、その機能を作ります。最終的にはいらないことになっても、やはり必要なのです。Binstock：なるほど。Beck氏：サービスを事後分析できるオプションが必要ですし、このオプションには、私がこれまで経験したことがないほど大きな価値があります。Binstock：メイン・トランクにコードをコミットするときはどうですか。メイン・ビルドへのチェックインを行う前のそうしたコードに対するテストの量は、通常のビジネス・サイトにおけるテストの量よりはるかに多いのではないでしょうか。実際にはどうですか。Beck氏：ひとくくりにそうだと言うことはでき

ANDREW BINSTOCK

Kent Beck氏インタビューJUnitの生みの親であり、TDDのクリエーターであるBeck氏がプログラミングとテストについて、また、テストに関する自身の考え方がどのように進化したかについて語ります。

Kent Beck氏は、エクストリーム・プログラミングの考案者であり、JUnitの共同開発者です。 その功績により、開発者ベースのテストの人気が高まりました。写真：BOB ADLER/GETTY IM-

AGES

ORACLE.COM/JAVAMAGAZINE /////////////////// NOVEMBER/DECEMBER 2016

28

//junit 5 /

ません。経済学の教授から学んだのですが、可逆性という原則があります。 たとえば、刺激に対して予測できない反応をする複雑なシステムがあるとします。ヘンリー・フォードは、前例のないそのような大工場を築きました。わずかな変化が甚大な影響を及ぼす可能性がある複雑なシステムを作ったのです。彼はその対策として、工場に生じる可能性のある状況の数を減らすことを考えました。たとえば、すべての車を黒にするといったことです。ヘンリー・フォードが支出を抑えようとしたためにすべての車が黒くなったわけではないのです。それは、塗装工場に塗料があるかないかといったような単純なことです。

黒にすることで全体をより管理しやすくなったのです。Facebookでは、社内にある状況の数を減らすことはできません。私たちはどんどん状況を増やしたいと思っています。実際にそうやって世界とつながっているのです。ですから、状況の数を減らす代わりに、後戻り可能な意思決定を行っています。ヘンリー・フォードの工場の場合、いったん金属を切断してしまうと、切断前の状態に戻すことはできません。Facebookではいつもそんなことをしています。後戻り可能な決定をすれば、今話題にしているような類の厳密さでテストする必要がなくなります。公開するときには注意を払い、問題が発生したらオフにすればいいのです。Binstock：それは興味深い代替アプローチですね。Beck氏：反例もたくさんあります。たとえば、金銭を扱うコードやLinuxカーネルは極めて厳しいテストにかけます。数十万単位のマシンに展開されるからです。

しかし、Webサイトへの変更の場合は、フィードバックがさまざまな方法で返ってきます。コードを手動でテストした場合、内部で使用した場合、サーバーのごく一部にコードを展開した場合のフィードバックを受け取ります。それから指標を観察し、何か問題が起こったらオフにす

るだけです。Binstock：つまり、後戻り不能な決定は非常に厳しいテスト、おそらくはエクストリーム・テストを実施し、それ以外の場合は後戻り可能なために、はるかに荷が軽くなっている、ということですね。Beck氏：そのとおりです。

JUnitの開発Binstock：JUnitの成り立ちについてお話しましょう。JUnitの成り立ちについては、ご自身で作成したさまざまなビデオで何度も説明されています。ということで、ここではその内容をおさらいする代わりに、いくつか質問をさせてください。作業は当初、あなたとErich Gamma氏との間でどのように分担したのですか。Beck氏：私たちはすべてをペア・プログラミングしました。Binstock：では、2人ともプロジェクト全体を通じて関与していたと。 Beck氏：2人そろわなければコードには文字どおり一切触れませんでした。何年もそうでした。Binstock：その当時、TDDの形式を使っていましたか。Beck氏：はい、厳密に。失敗するテストケースなしに、絶対に機能を追加することはありませんでした。Binstock：そうですか。では、JUnitでのテスト実行が可能になるまでは、どのようにテストを実行していたのですか。Beck氏：ブートストラップを使用ました。最初は大変そうに見えました。みなさんもコマンドラインで操作すると思いますが、すぐにテストを実行のための便利な機能が手に入るようになります。しばらくの間は、失敗という正しい結果を得ながら作業を分割します。そしてこう言います。「すべてのテストに合格していますが、たった今変更を加えたので、もうどんなテストも実行しません」。そして再び、ブートストラップに戻ります。誰もがこうした訓練に挑戦すべきです。これは非常に勉強になる訓練です。テストのフレームワークを一から作って、それ自体を使ってテストするのです。Binstock：それ以前にあったのは、SUnit（JUnitに先行するツールで、Beck氏がSmalltalk用に開発したもの）だけでした。概念レベル以外では、JUnitを作成する上であまり役には立ちそうにありませんでしたね。Beck氏：はい、最初から開発しました。

テストはフィードバックの形式の1つにすぎず、実に優れた点がいくつかありますが、状況によっては非常に大きな犠牲が生じることもあります。

ORACLE.COM/JAVAMAGAZINE /////////////////// NOVEMBER/DECEMBER 2016

29

//junit 5 /

Binstock：JUnit5ではどのような形で貢献したのですか私の知るところでは、このリリースにはそれほど関与されていないようですが。 Beck氏：はい、まったく関与していないというのが一番近いのではないかと思います。実際には、ある時、1つのリリースで2種類の変更を行う方法について皆が話していたので、私は「2つのリリースにしてはどうか」と言ったのです。つまり、ちょっとしたアドバイスをしただけだったのです。

テスト・ファースト Binstock：まだ厳密にテスト・ファーストで作業をしているのですか。 Beck氏：テスト・ファーストではない時もありますし、テスト・ファーストの時もあります。Binstock：そうですか。テスト・ファーストについてどのように考えが変化したのかを教えてください。あなたの著書『Extreme Programming Explained』を拝読すると、テスト・ファーストについてほとんど考えを譲らないような印象でした。考えが変わったのですか。Beck氏：ええ。可変要素があるということを、当時は知りませんでした。自動テストが有益なケースについてのトレードオフで非常に重要な要素です。それは、コード行の半減期です。調査モードにあるときに、プログラムで何ができるのかを探っていて、ほとんどの実験が失敗することになって数時間またはおそらく数日で削除されるような場合、TDDの大半の利点は効果がなく、実験を遅らせてしまいます。「疑い」から「確信」に至る間の時間だけ遅れが発生するのです。そのような時間はできるだけ短縮したいものです。テストによってそうした時間を短縮できる場合はよいのですが、多くの場合は遅れを長引かせます。遅れの有無が影響を及ぼし、コード行の半減期が短い場合は、テストを作成すべきではありません。Binstock：確かに、あれこれ試している間にエラーに直面したら、後戻りしてコードが予定どおりに動くようにテストをいくつか作成するかもしれません。Beck氏：私はフィードバックには多くの形があることを学びました。テストはフィードバックの形式の1つにすぎず、実に優れた点がいくつかありますが、状況によっては非常に大きな犠牲が生じることもありま

す。次に、トレードオフによって一方の側に傾くようなケースの1つなのかどうかを見定めなければなりません。人はルール、絶対的なルールを求めるものですが、私に言わせればそれはまったくずさんな考え方だと思います。Binstock：そうですね。20年を超えるプログラミング経験から得た大きな利点の1つはおそらく、断固として適用される全般的なルールをほとんど信用しなくなったことです。Beck氏：はい。唯一のルールは考えることです。IBMは正しかったですね。Binstock：そういえば、getterやsetterなどの特定のものは、テスト・ファーストで作成する必要はまった

くないとおっしゃっていましたね。Beck氏：そこまで具体的に言ってはいないと思いますが。「テストしなくてはならないものは何もない」というのが私の変わらぬポリシーです。多くの人は、テストなしで大量のコードを作成し、大金を稼ぎ、そして世界に貢献しています。つまり、テストしなければならないものなどないのです。

フィードバックには多くの形があります。テストのトレードオフ式で考慮される要因の1つは、「ミスを犯す可能性はどのくらいか」ということです。ですから、getterを利用している場合、それは単なるgetterであり、絶対に変化しません。もしgetterで失敗するといったことがあれば、また別な議論をする必要があるでしょう。テストではその問題を修復することはできません。Binstock：TDDのルールを最初に作ったとき、土台の1つとなったのは、各反復処理の機能は可能な限りの最小単位にするというものでした。その考え方はどこからきたのですか。可能な限り最小単位にすることの重要性は何ですか。 Beck氏：もし大きくておいしそうなイタリアのサラミがあって、全部食べるまでどのくらいの時間がかかるのかを知りたい場合、効果的な方法は1枚スライスして食べ、その時間を計算することです。1ミリ食べるのに10秒かかれば、300ミリなら3,000秒かかります。まあ、それ以上かかるかもしれないし、それ以下かもしれませんが。ポジティブ・フィードバック・ループ、ネガティブ・フィードバック・ループ、その所要時間を変化させるその他の事項があるかもしれませんが、少なくともそれについて何

ORACLE.COM/JAVAMAGAZINE /////////////////// NOVEMBER/DECEMBER 2016

30

//junit 5 /

かしらの経験はあると思います。 熟練プログラマーとマスターの違

いは私が思うに、マスターは絶対に一度にサラミを全部食べようとしないことです。まず、彼らは常に全体を見て、その後でスライスにします。どこからスライスできるのかを考えることが最初のスキルです。

第2のスキルは、スライスを食べる順序について創造性を働かせることです。左から右へ食べなければと思うかもしれませんが、そんなことはないのです。「出力コードを作成する前に、入力コードを作成しなければ」と誰かに言われたら、「失礼ながら同意しかねるね。自分ならデータ構造をメモリに構築して、そこから出力コードを作成できる」と答えます。つまり、入力コードを作成してから出力コードを作成することも、その逆もできます。

n個のスライスがある場合、そこからn個のスライスを選ぶ順列の数に等しい選択肢があり、中には意味をなさないものもありますが、多くは意味をなします。ですから、マスター・プログラマーは2つのスキルを使って、スライスをより薄く切り、より多くのスライスの順列を実装の順序として考慮します。これらのスキルのいずれも、あらゆる種類の漸近線に達することは決してありません。スライスを薄く切ることはいつでも可能ですし、各種目的に応じて実装を行う順序を多数考案することもいつでもできます。

金曜日にデモがあると言われたら、金曜日に同じプロジェクトで負荷テストを実行しなければならないと言われた場合とは違う順序で実装を行います。別のやり方でスライスし、次の目標に応じてまったく違う順序でスライスを実装するでしょう。 Binstock： では、可能な限りの最小単位というのは、厚いスライスを示唆しない他の要因があるときに適用する原則ということになるのですか。Beck氏： 私は、可能な限りの最小スライスではなく、スライスをもっと小さくする方法を見つけていくことがよいと思っています。考えられる限りスライスを薄くしても、決まってある時点でスライスをその半分のサ

イズにする方法を思いつき、後悔するのです「なぜもっと前に思いつかなかったんだろう。これは1つのテスト・ケースではなく、3つのテスト・ケースだ」と。その後、物事ははるかにスムーズに進展します。 Binstock： 単一責任の原則を非常に厳密に遵守するのであれば、同じ力学をそこで使えるように思えます。つまり、メソッドを使ってこの上なく小さい操作を実行し、小さいBBサイズのメソッドをつなぎ合わせなければならず、それらをまとめ合わせる方法を考えなければなりません。 Beck氏： そうであればひどいことになるでしょう。40または50のクラスを開かなければならない場合、ある時点で違反した結合性について議論することになり、これは凝集性を除去する上で正しい方法ではありません。Binstock： 私たちは同じ方向に向かっていると思います。つまり、スライスにはこれ以上薄く切れない限界があり、そこから先は何の価値も加わらず、他のものを損ない始めることになります。Beck氏： 今日、そして一晩考えて、朝起きて「どうしてそれを思いつかなかったんだろう。スライスを縦ではなく横に切っていたら、もっとうまく事が運んだのに」というところに行きつきます。金曜の午後に外に出て車に乗って家に帰るといったようなことが、思いつくきっかけとなるのです。

コーディングのプロセスBinstock： 何年か前に耳にしたのですが、開発者がコードを作成するときには、そばに紙とペンを用意して、作成中のコードについて下したすべての決定を書き留めることを勧めるそうですね。

私たち全員が書き込みの数にびっくりするだろうとおっしゃっていましたが、まさに私がそうでした。自分でまとめたそれらのリストを見れば見るほど、邪魔が入った場合、中断前の世界観全体を再現できるかどうかは、それまで下してきた小さい決定事項をすべて思い出せるかどうかに大いにかかっているということに気付かされました。時間が長く経つほど、リストを参照してもそれらの小さい決定事項を思い出すことが難しくなります。

それで思うのですが、これらの決定事項を記録するという考えは、コードに関する意識の練習のためではなく、そのリストを便利に活用できるからということで発展してきたのですか。

文芸的プログラミングには保守性があまりありませんというのも、散文、ダイアグラム、コードの結びつきが強すぎるからです。

ORACLE.COM/JAVAMAGAZINE /////////////////// NOVEMBER/DECEMBER 2016

31

//junit 5 /

Beck氏：いいえ、違います。第1に、このことは以前書いたことがありますが、私の記憶力に問題があるからです。ですから、複雑で大きいプログラムはもちろん、小さいプログラムでも記憶に留めておくことがなかなかできません。私がペア・プログラミングのパートナーとしてやっていけるのは、パートナーの記憶力に頼れるからですが、腰を下ろして大きくて複雑なプログラムの開発に挑むようなことはもうできなくなっています。

UNIXコマンドラインでプログラムを作成することはまだできます。全体を見ることができますから。1コマンドずつ作成するなど、1行のコードであれば私にもできるし、プログラミング・タスクを達成できますが、それはずっと使えるコードではなく、すべてその場限りのコードです。私はデータ・マイニングを数多く開発しています。たとえば、Xを処理するサービスを開発する場合、ただ開発すればいいというのではありません。さまざまな年齢の人がさまざまな方法、割合などで関与します。自分が単独で取り掛かってできることではないので、とてもフラストレーションがたまります。Binstock：あなたがおっしゃっていることを踏まえ、小さい決定事項を記録する自分なりの努力について考えていると、 Knuthの文芸的プログラミングなどの素晴らしさを改めて実感する部分が自分の中にあるんです。何をしているのか、何をしようとしているのか、それについてどのような決定を下したのかを実際にコメントの中にとどめておくことができます。実際、この特定のやり方についてお話を伺った後、私はしばらくの間、そんなふうに作業をしていました。いろいろな点で有益な方法でした。その一方で、かなり乱雑になってしまったので、結局は後戻りしてコメントを削除しなければなりませんでした。この話題を取り上げた唯一の理由は、その後あなたがさらに進展したのかどうかを確かめたかったからです。Beck氏：文芸的プログラミングでわかったことは、あまり保守性がないということです。というのも、散文、ダイアグラム、コードの結びつきが強すぎるからです。こんなふうに言ってみたことはなかったのですが、まさに的を射ています。コードに変更を加えたら、コード、それからおそらくテストを変更するだけでなく、それら4つの段落と2つのダイアグラムも変更しなければならず、このデータを再収集して再びグラフに描出しなければなりません。ですから、あまり効率的に保守できるものではありません。非常に安定しているコードがあり、そのコードについて説明したい場合は、そのようなことは関係なく、うまく説明できるでしょう。

Binstock：Ward Cunningham氏と話をしたことがありますが、そのとき彼は、何年も前に実施した、あなたとのペア・プログラミングについて語っていました。彼は、決定ポイントに到達する頻度、そして「この特定のポイントを通過するために、最小限必要なことは何か」を問いかけることによって先に進む、という方法にどんなに驚いたかを話してくれました。常にできるだけシンプルなことから作業を

始めれば、ある時点で後戻りしてリファクタリングを行う必要がなくなり、問題を回避するコードではなく、誇りに思えるようなコードができるようになるのでしょうか。これら2つのバランスをどうとっているのですか。 Beck氏：そうですね。ところで、私は誇りを感じるためにコードを開発してお金を得ているわけではありません。JUnitのような場合は、誇りに思えるコードを書けないのであれば、コードを書きませんでした。納期が存在せず、顧客からお金をもらっているわけでもなかったので、そのような姿勢が可能だったのです。

しかしこのところは、自分が気に入らないコードであっても顧客がその結果を気に入ってくれたら、それは良しとしています。それが仕事であり、その報酬としてお金が得られるのです。ですから、シンプルさを求める理由は他にあります。

一部分にしか適していない決定をしてしまうのは、単に、全体をきちんとわかってないからです。全体を把握し、理解すれば、こうではなくこんなふうに設計すべきだったと気がつくようになります。そのようにして理解した事柄を作成中のコードに組み込む場合は、いつどのように組み込むのかを決定する必要があります。組み込むときもあれば、そうでないこともあるのかもしれません。

でも、私は別の方法を知りません。みんな「リファクタリングを行わなければならないのではないか」と聞きます。それはそうです。では、その代替手段は何でしょうか。

デンマークでワークショップを開いたことがありますが、反復の素晴らしさについて1日中熱のこもった話をしました。ある男性がその日ずっと前列に座って私のことを見ていたのですが、その表情は時間とと

私はテキストのソース・コードを除去して、抽象構文ツリーで直接動作させる方法を大いに信頼しています。

ORACLE.COM/JAVAMAGAZINE /////////////////// NOVEMBER/DECEMBER 2016

32

//junit 5 /

もに不安さを増していきました。そろそろ終わりというときになって、その男性はついに手を挙げて、「それは1回目できちんとやった方が簡単なのではないでしょうか」と言いました。私は彼にハグしたくなりましたよ。それでこう言いました「まったく同じ意見です。その方が簡単ですね。それ以外に答えようがありません」。Binstock： いい質問ですね。Beck氏：一度、飛行機でNiklaus Wirth氏の隣に座ったことがあります。私は彼の付き添いの人に話しかけ、Niklaus Wirth氏と自分は同業者であることを伝え、隣の席に座らせてもらえるように頼んでから、ストーカーのようですが、憧れていたことを伝えました。でもいいんです。Niklaus Wirth氏の隣に座るチャンスがあったら、誰でもそうするでしょうから。私たちは話を始めました。TDDやインクリメンタル設計のことを話したら、彼は「ソフトウェアの設計方法を知らないのなら、それはまったく素晴らしい話だと思う」と答えました。Binstock：それはいかにもWirth氏が言いそうなことですね。Beck氏：こう答えるしかありません「ええ、そうですね、私は知らないんです、ありがたいことに！あなたはソフトウェアの設計を知っておられますが、私は知りません。どうしたらいいんでしょう。あなたのふりはできませんからね」。

今日のテストBinstock：マイクロサービスについて話をしましょう。一部のサービスを機能させるには、他のサービス一式が必要になるという点で、マイクロサービスのテスト・ファーストは複雑になりそうですが、そう思われますか。Beck氏：1つの大きいクラスにするか、多数の小さいクラスにするかという一連のトレードオフと同じに思えます。Binstock：ええ、ただしその場合、特定のサービスをテストできるシステムを設定するには、非常に多くのモックを使う必要があると思います。 Beck氏：私はそうは思いません。命令型であれば、多くのモックを使わなければなりません。関数型であれば、外部の依存関係が呼出しチェーンに積み上げられるので、モックは不要だと思います。単体テストよりも多くをカバーすることができると思います。Binstock：現在、UIは過去のどの時代よりもはるかに重要になっています。過去と現在において、UIに対してどのように単体テストを実行して

きましたか。FitNesseなどのフレームワークを使っていたのですか。それともテストの結果をただじっと見つめていたのですか。Beck氏：これまで満足のいく答えを得たことがありません。こんなふうに説明しましょう。私は多くのものを試しました。統合テスト・フレームワークを構築しましたし、他の人たちのツールを使いました。また、テスト的に安定した方法でUIがどのように表示されるのかをさまざまな方法でまとめてみようとしましたが、どれもこれもだめでした。Binstock：現在の立ち位置もほとんど同じですよね。Beck氏：はい、根本から変化したことは何もありません。すべてはfalse positiveとfalse negativeになります。テストの結果で、すべて合格という割合と、すべてが不合格という割合はどのくらいでしょうか。これが、テストでの信頼を損ねているのです。テスト・フレームワークにより、どこかに問題があるという結果が出る頻度とすべて良好という結果が出る頻度はどのくらいありますか。よくあることですが、ピクセルが1つずれると色がごくわずかに変わります。テストをすべて中断し、1つずつ調べてみる必要があります。都度、「ああ、いや、これでいいんだ」といいながら。こんなことを何度も繰り返すことはしませんよね。テストを中止するだけです。Binstock：その代償は、時間と信頼の損失ですね。Beck氏：はい。

コード開発環境Binstock：自宅でも職場でもけっこうですが、現在のお気に入りのプログラミング環境はどんな感じですか。Beck氏：プログラミングのような作業はすべてUNIXのコマンドラインかExcelでやっています。Binstock：Excelですか。Beck氏：はい、すべてを把握できるので。Binstock：どういうことでしょうか。Beck氏：たとえば変換です。私は数値同士の変換のようなデータ変換をUNIXコマンドラインで実行し、Excelを使って図にしています。Binstock：データ・マイニングに関係のないプログラミングをしている場合、調査にはまだSmalltalkを使っていると先ほどおっしゃっていましたが。Beck氏：はい。私にとってSmalltalkの利点は、APIをずいぶん前に頭に入れているので、いまだにその詳細すべてにアクセスできる点です。

ORACLE.COM/JAVAMAGAZINE /////////////////// NOVEMBER/DECEMBER 2016

33

//junit 5 /

Binstock：普段は複数のスクリーンで作業をしていますか。Beck氏：はい、ピクセル数は多いほどベターです。Terry Pratchettが面白いことを言っていました。「Macにスクリーンを6台接続しているのはなぜかと聞かれたら、スクリーンを8台接続できないからだと答えているんだ」と。Oculusのような仮想現実は、びっくりするようなことを引き起こすでしょうが、どんなふうになるのかは誰にもわかりません。Binstock：仮想現実が、実際にコード開発を助ける役割を見出すまでには、そのようなことを幾度となく繰り返さなければならないでしょうね。Beck氏：そうです。私はテキストのソース・コードを除去して、抽象構文ツリーで直接動作させる方法を大いに信頼しています。私は友人のThiago Hiraiと一緒に、Pruneという実験的なコード・エディタを作成しました。見たところテキスト・エディタのようでしたし、実際にテキスト・エディタのようにレンダリングされましたが、抽象構文ツリーのみで操作を実行でき、その方がはるかに効率的で格段にエラーが少なかったのです。認識の努力はあまり必要ありませんでした。この経験から、こうしたものが将来のトレンドになるだろうと確信しました。それが5年後になるか、25年後になるかはわかりませんが、近いうちに誰もが構文ツリーで操作を実行するようになります。 Binstock：ええ。あらゆるものが変化と進歩を遂げている中で、コードを作成する際の要件は、インクと紙レベルからあまり進歩を遂げていません。 Beck氏：そう、いまだにパンチ・カードでコードを作っています。順に重ねてレンダリングされますが、まったく代わり映えしませんBinstock：プログラマーが最初に活動する場はほとんど進歩していません。素晴らしい機能のIDEなどは開発されましたが、物理的な作業はいまだに昔とほとんど変わりません。最後にもう1つ。あなたはミュージシャンですよね。コードを作成しているときに音楽を聴いたりします

か。Beck氏： はい。Binstock： コードを作成しているときはどのような音楽が一番合いますか。Beck氏： エネルギーのレベルを調整するような目的で音楽を聴いていますが、少し生き返った気分になったら、今度は何か心が落ち着くような音楽を聴きます。私のお気に入りはThomas Tallisの「エレミアの哀歌」です。この曲は中世音楽で、非常に流麗な四重唱です。少し落ち込んでいて気持ちを盛り上げたいときには、ゴーゴー・ミュージックを聴きます。これはワシントンDCのファンク・ネイティブから派生した音楽です。Binstock： そうなんですね。私は聴いたことがありません。 Beck氏： 私にとっては、これが元気の出る音楽です。Binstock： 素晴らしいですね。今日はどうもありがとうございました。 </article>

（コードの作成中に）少し生き返った気分になったら、今度は何か心が落ち着く音楽を聴きます。私のお気に入りはThomas Tallisの「エレミアの哀歌」です。