コードの短さ
2024.10.22
パラメトリック・ボイス
コンピュテーショナルデザインスタジオATLV 杉原 聡コンピュータ・プログラミングにおいて複雑な処理を行う場合コードは長く複雑になりがちだ
が、必ずしも長いコードが価値のあるコードであるとは限らず、コードの短さが価値となる場
合もある。今回はそれにまつわる話を記す。
今年3月の建築情報学会WEEKにおいて筆者はラウンド・テーブル・セッション「建築プログラ
ミング開発が設計プロセスにもたらす効果と魅力」に登壇した。セッション・オーガナイザー
である夏目大彰氏の司会で、プログラミングを駆使して建築を実践する登壇者らにより、建築
の分野においてプログラミングすることの効果と魅力が議論された。
その際に筆者が発表した建築プログラミングの魅力の一つとして、コードの最適化の楽しさを
挙げた。コードの最適化とは既に書かれたコードを改良して実行速度やメモリ消費など、何ら
かの点で効率を上げることである。発表で挙げた最適化例の一つは、1Dスケールの幾何学処理
を行うコードの最適化である。1Dスケールは、RhinocerosにおけるScale1Dコマンドのように
1次元方向の拡大・縮小を行う処理である(図1)。
筆者が開発をしているコンピュテーショナル・デザイン・ライブラリiGeoのベクトル演算ライ
ブラリでもscale1dメソッドが実装されており、曲線や曲面、BREPなどのscale1d処理は、各
制御点にベクトル演算のscale1dを適用することで実現される。原点を中心とした一つの点の
1Dスケールは、拡大方向を定めるベクトルを正規化(長さを1にする)してから、内積を用いて
投影を行い、投影後のベクトルを指定された倍率(factor)で拡大・縮小し(図2の水色の矢
印)、そして投影時の差分ベクトルを引いて、投影で失われた直行成分を戻す(ピンク色の
矢印)ことで計算できる。この処理は図2の上段のような疑似コードで書けるが、この数式の
代入や変形によって、下段のように短く最適化できる。
なぜこのような最適化を行うかといえば、効率化されて多少は処理が速くなるのは確かだが、
私にとっての一番の理由は楽しいからである。あまり多くの人がこれを楽しいと思わないであ
ろうが、コードのピースを並び替えて一番コンパクトな形に整頓しつつ出力は全く同じにする
という、パズルを解いているような楽しさがあるように感じられるのである。
またそれと同時にコードの最適化は、行っている処理の意味の本質を抽出することもある。図2
下段の最適化後の1Dスケールのコードの意味は、拡大方向に投影したベクトルをfactor-1倍し
たもの(赤い矢印)の分だけ元の点を動かす、ということであり、最適化前の投影、拡大・縮
小、逆投影という幾何学処理手順よりも簡略化されている。
アントニオ・ガウディ亡き後のサグラダ・ファミリアの建設に携わり、断片的に残された図面
や模型に込められているガウディの設計の論理をコンピュテーションの論理によって解釈して
再現したマーク・バリーの仕事*1を見ると、ガウディの設計の本質を見極めるために、最も簡
潔に純化された設計の数理を模索している様子がうかがえる(図3, 4)。設計のコードが簡潔
であると設計の論理が純粋なものになり、それにより設計されたものにも純粋さやシンプルさ、
一貫性という価値が生まれるという考え方が窺える。
また、コンピュータ・プログラミングによりアニメーションやグラフィックなどの表現を追求
するクリエイティブ・コーディングの分野(図5)では、コードの短さ、またはある限られた
長さのコードでどこまでの表現が可能であるかが追求されることがある。X(旧ツイッター)
において、#つぶやきProcessingや#dwitterのタグで投稿される作品には、Xの制限文字数以
下の長さのコードで可能な表現が追求されている。これらの多くはJavascript、または
Javascriptで記述されたProcessingであるp5.jsで書かれており、100~200文字程度のコード
で驚くほど複雑な作品が生成される。しかし、これらのコードは過剰にコードが詰め込まれて
いたり、コードの機能を変えずに変数名や記述方法を変えて自動的にコードを短くするツール
が適用されていることがあり、それらのコードは読解が困難である。通常のプログラミングに
おいては、読みにくい、分かりにくいコードは良くないコードとされるが、ここではそれより
も出力される表現が優先されている。こちらの記事では、#つぶやきProcessingで投稿された、
極めて複雑な表現がなされる作品の短いコードを読解しようとする過程が記されている。
また、コードのまた別の価値として堅牢さもある。数学及び暗号学の教授であるダニエル・
ジュリアス・バーンスタイン氏の開発したメール・サーバqmailのコードは、例えハッカーの
攻撃を受けてメモリの一部が改竄されてプログラム中の変数の値がありえない値になったとし
ても、できるだけ問題を引き起こさないよう配慮がされた堅牢なものとなっている。
このように、プログラミングにおけるコードには、それが達成する機能・出力、簡潔さ、読み
やすさ、保守性、堅牢さのように様々な価値があり、クリエイティブ・コーディングの例のよ
うに表現(出力)と簡潔さのために読みやすさや保守性が犠牲になるように、どの価値が重視
されるかはケースバイケースである。今後AIによるプログラミング支援やコード生成が活発に
なって行くとき、どのような価値が誰によって重視されたコードが生まれていくのであろうか。
また多様な側面において価値を持つ建築においても、画像生成AIに限らず設計や建設の様々な
過程が今後自動化されていく際に、何故、誰によってどのような価値が重視されどのような価
値が重視されないのかを常に意識することは大切なことであるように思われる。
*1 Burry, Mark, ed. Scripting Cultures: Architectural Design and Programming.
AD Primers, Wiley and Sons. 2011.