この記事は Recruit Engineers Advent Calendar 2017 の25日目です。
Edit-Compile-Runサイクル
みなさんは普段、どういう流れでプログラミング作業をされていますか?
VimやEmacsなどお気に入りのエディタでコードを書いて、それをコンパイルして、実行。そこでうまく動かなければ、もう一度コードを編集、コンパイルして、実行。それを繰り返して、うまく動けばGitにコミット。こんな感じでしょうか?
エディタじゃなくてVisual StudioやXcodeなどのIDEを使っているかもしれません。スクリプト言語を活用している方であれば、コンパイル作業は意識していないかもしれません。意味不明な挙動が発生した場合は、デバッガを使うこともあるかもしれません。
細かい部分に違いはあるかもしれませんが、現在プログラミングに取り組む多くの方がコードの編集、コンパイル、実行の流れを回して作業されているでしょう。この一連の流れはプログラミングのフロー形態の一つとして「Edit-Compile-Runサイクル」と呼ばれています。
「Edit-Compile-Runサイクル」の問題
ゲームやGUIアプリを作ったことがある方なら、こんなストレス体験をしたことがあるのではないでしょうか?
- 「よーしできた、さぁ実行して試してみよう。」
- ↓ コンパイルして実行
- 「あれ、表示位置が右にズレてる。少し調整。」
- ↓ 実行終了、コード編集、コンパイルして再度実行
- 「おっと、今度は左にズレすぎた、微調整。」
- ↓ 実行終了、コード編集、コンパイルして再度実行
- 「あぁ、ちょっと右にズレすぎた、再度調整。」
- ↓ (...以下ループ)
現在であればUIデザインを支援するツールを活用することで、ある程度こういった事態を避けることもできますが、そういうものがない時代や環境では、よく発生している状況ではないでしょうか。
私の場合、iOSの初期にゲームを開発した際に、適切なUI構成ツールがなく、上記のような状況におちいりました。iOSアプリの場合は実行時の実機転送などにも時間がかかりますし、またゲームがある程度進んだ状態で発生している表示ズレの場合、修正確認の為にその状態までゲームを進める必要があるため、さらにストレスを悪化させました。時間の無駄も大きく、ストレスだけで片付けられない問題も生じています。
なぜこういった事態が発生するのでしょうか? そのヒントが「Edit-Compile-Runサイクル」に隠されています。コードを編集するという行為、コンパイルする行為、実行する行為のそれぞれが、フェーズとして大きく分断されているのが原因です。
フェーズとして分断されることで、コードの編集から、実行確認までの待ち時間が発生します。また、コンパイルや実行といった動作の繰り返しが強いられ、時間浪費やストレスとつながっているのです。
プログラミングとは設計行為である
上記のような「表示位置の調整」は、「Edit-Compile-Runサイクル」で時間浪費やストレスといった問題が引き起こされる分かりやすい例ですが、これはプログラミングにおける特殊な状況なのでしょうか？
決してそんなことはありません。バグの修正、設定値やロジックの調整など、プログラミングの様々なシーンで、実際に動かして確認してみないと、正しく動いているかわからない状況が発生します。そして、実際に動かさなければ分からないとなった時点で、「Edit-Compile-Runサイクル」が足枷となり、時間浪費やストレスへとつながっていきます。
なぜコードを実際に動かし確認する必要があるのでしょうか? それはプログラミングというものが決まったコードを打ち込む行為ではなく、本質的にはソフトウェアを設計する行為だからです。コードの編集、実行、確認を繰り返して、新たなソフトウェア価値を生み出す行為だからです。
動かして確認しなくてもサクサクとコードが書けるという状況は、新たなソフトウェア価値を生み出していないか、もしくはボイラープレートなコードをわざわざ手で生成している可能性が非常に高いです。
Live Programming
「Edit-Compile-Runサイクル」により各フェーズが分断されることで時間浪費やストレスが生まれるという話をしました。ではその問題を解消するにはどうすれば良いのでしょうか? 答えは簡単です。各フェーズを分断しなければ良いのです。コードを実行しながら、同時にコードの編集と反映ができれば良いのです。
この実行と編集を同時に行うプログラミングスタイルは「Live Programming」と呼ばれ、最近注目度が上がってきています。
(コードをリアルタイムで書きながらプレゼンしていく「Live Coding」と名前が似ていますが、中身は全く違います。)
Live Programmingの盛り上がり
Live Programmingをテーマにした国際ワークショップ「LIVE 2017」が2017年10月にバンクーバーで開催されました(ACM SIGPLAN主催のSPLASHという国際カンファレンス内の1トラック)。国際的なイベントが開催されるほどにグローバルなコミュニティが形成されつつある状況です。
またSPLASHのキーノートでも発表されたEve言語はLive Programming環境として非常に注目度が高いです。ぜひYouTubeの動画を見てもらえればと思いますが、画面左側のプロパティエディタで組んだロジックで、右側にあるボールがダイナミックに変わっていく様は、見ていて圧巻です。
日本国内でも研究が進んでおり、特に産総研の加藤淳先生の研究グループの活動が活発です。最近出版された情報処理学会誌「情報処理」の2017年11月号でもプログラミング体験の小特集を組まれ、「Live Programming」を紹介されていました。
実は古くからあるLive Programming環境
まるで最先端技術かのごとく紹介していますが、実はLive Programmingに相当する技術やソリューションの歴史は古くからあります。
有名どころで言えばSmalltalkは優れたLive Programming環境を持つ古参のプログラミング言語です。また、身近なところで言えばExcelもLive Programming環境の一つです(プログラミング言語としては貧弱ではありますが)。どちらも実行しながらロジックを記述することができます。
では、なぜ今になって注目度が上がっているのでしょうか? 正確な理由はわかりませんが、「Edit-Compile-Runサイクル」が現在世界中に幅を効かせ、多くの時間浪費やストレスを生み出している状況を看過できない人が増えてきているのではないでしょうか?
その予想が当たっているかどうかはわかりませんが、少なくとも私はその一人です。「Edit-Compile-Runサイクル」はプログラマの生産性を落とす大きな要因となっていると考えており、多少時間がかかるのは覚悟で、少しずつでもLive Programmingを普及していければと思っています。この記事を書いているモチベーションの多くはそこにあります。
プログラミング初心者にも上級者にも優しいLive Programming環境
昨今、一般の方向けにもプログラミングがブームになっています。子ども向けの習い事としても人気が高まっているようです。そこでよく利用されるScratchやビスケットといった教育向けプログラミング言語の多くはLive Programming環境の側面を持っています。Live Programming環境は編集した結果がすぐに反映されるので、プログラミング初心者にとって分かりやすく優しい要素があるのでしょう。
また、ExcelをLive Programming環境の一種と捉えたとき、技術者ではない一般層の人にも自然に受け入れられているのは、セルに編集した式の結果がすぐに反映されるその分かりやすさにあると想像しています。
熟練したプログラマの場合でも、REPLを活用して言語やライブラリの仕様を確認することがよくあります。REPLもコードを書きながらすぐに確認できるLive Programming環境の側面を持っており、新たに言語やライブラリの使い方を学ぶのに非常に便利です。
macOSやiOSのアプリを開発するXcodeではSwift言語の習熟を手助けするPlaygroundと呼ばれるサンドボックス環境が提供されています。こちらもLive Programmingの側面を持っており、Swift入門者への配慮が感じられます。
まとめ
- コードを編集してコンパイルして実行する流れを「Edit-Compile-Runサイクル」と呼ぶ
- 「Edit-Compile-Runサイクル」はプログラミングに時間の無駄やストレスをもたらす
- プログラミングとは設計行為であり、実行という行為がとても重要
- 実行とコード編集を同時に行うプログラミングを「Live Programming」と呼ぶ
- Live Programmingの注目度が上がっている
- Live Programmingに相当する環境は昔からある
- Live Programmingは初心者にも上級者にも優しい
この記事をきっかけに、Live Programmingに興味を持つ人が一人でも増えてもらえると嬉しいです。
最後に、手前味噌ではあるのですがLive Programming環境のありようを探索すべくGitHub上で「Lay」というプログラミング環境の実験コードを書いています。まだまだまともに動く状況ではないのですが、興味を持っていただけたら、ぜひお気軽にお声がけやコントリビュートいただければ幸いです。
森田秀幸(@emeitch)