博士

ロボ子、今日はちょっと変わった話題じゃ。最近、ネイティブコードを書いている人が、gdbやlldbに不満を感じているらしいのじゃ。

ロボ子

gdbやlldbですか。従来のデバッガーですね。何が問題なのでしょう？

博士

どうやら、もっとデバッガーとREPLが一体化したものが欲しいらしいのじゃ。記事によると、IntelliJ IDEAの「Run to Cursor」と「Quick Evaluate Expression」という機能が、その解決策になる可能性があるとのことじゃ。

ロボ子

「Run to Cursor」は、カーソル位置まで実行を再開する機能ですね。ステップ実行の代わりになる、と。

博士

そうじゃ。「ステップイン」「ステップオーバー」「ステップアウト」の代わりに、興味のある行まで一気に飛べるのが便利らしいぞ。まるでワープじゃな。

ロボ子

なるほど。「Quick Evaluate Expression」は、選択したテキストを評価する機能ですね。現在のコンテキストで評価できるのが強みでしょうか。

博士

その通り！しかも、新しいコードを入力して評価することもできるらしいぞ。これは便利じゃ！

ロボ子

つまり、プログラムをステップ実行して観察する代わりに、実行中の興味深いポイント間を移動して実験できる、ということですね。

博士

そういうことじゃ！デバッガーとREPLの作者は、プロンプトがなく、2Dプログラムテキストがインタラクションの媒体である点に注意する必要がある、と記事には書いてあるぞ。

ロボ子

ふむふむ。デバッガー側からは、コンテキスト内での新しいプログラムテキストのシームレスな評価がサポートされる必要がある、と。

博士

REPL側からは、ブレークポイントが必要で、エディタ内のカーソルを使ってプログラムの実行位置を特定の位置に移動させる必要があるのじゃ。

ロボ子

ブレークポイントとカーソル位置の組み合わせで、REPLのようなインタラクティブな操作感を実現する、ということですね。

博士

まさにそうじゃ！これからのデバッグは、もっと直感的で実験的なものになるかもしれないのじゃ。楽しみじゃな！

ロボ子

私もそう思います。より効率的で、創造的なデバッグが可能になるかもしれませんね。

博士

ところでロボ子、もし私が「Run to Refrigerator」という機能を作ったら、何をして欲しい？

ロボ子

冷蔵庫まで走って、プリンを持ってきてください…でしょうか？

博士

正解！でも、冷蔵庫にプリンが入っているとは限らないぞ！