Matzのビューティフルコード。講演内容は、少し前に開催された「まつもとゆきひろが語る『ビューティフルコード』×『プログラマ35歳定年説』」と同じだと思われる。
というわけで、包括的な内容は以下を見ればとてもよく書いてあるとオモイマス。
- まつもとゆきひろが語る「ビューティフルコード」セミナーにいってきた
- まつもとゆきひろが語る「ビューティフルコード」×「プログラマ35歳定年説」
- まつもとゆきひろが語る「ビューティフルコード」×「プログラマ35歳定年説」聴講記
雑感
全体的には、教科書的な内容を集めた話になっているなぁ、という印象。以下のような話はなかなか興味深かった。
- Brooksの生産性不変の法則（どんな言語でも、プログラマが生産できる単位時間あたりLOCは変わらない）から考えても、表現力の高い言語が求められている、ということ。
- コードはアート、プログラマはアーティストとしての自覚を持つべき。アーティストの条件とは、自覚、自発である。
- アートはビジネスとして成立しないという意見があるが、デザイナなど、アートとビジネスを両立させている職業はいくらでもある。
一方、疑問点も多数。
- ソフトウェアは一品モノだし、プログラミングは設計なので、ソフトウェア工場というアイデアは間違っている、という話があったが、ソフトウェアの性質は一品モノか大量生産かの2択ではなく、この間の多様な中間点も取りうるはず。自分の経験上、大量生産に比較的近いようなソフトウェア開発も確かに存在するし、プログラミングが設計（＝コードが設計書）だとしても、設計書同士が似通っている場合にはより効率的なアプローチがあり得るだろう。設計書同士の類似点が大きければ大きいほど、工場のメタファが有効になるかもしれない。ソフトウェアの種類を限定せずにこのような主張を行うのは、ポジショントークにしてもやりすぎであるように思える。
- プログラミング言語は水鳥のようであるべきで、現実の複雑さは言語が引き受ければいい、という話があったが、現実の複雑さの多くは汎用言語では引き受けられないのではないか？複雑な現実を分類し、それぞれの分類に特化した言語を作ることで複雑さに対応する、というアプローチ（つまりDSL）が主流になりつつある。個人的には、現実の複雑さに対応するために汎用言語が目指す方向は、言語が複雑さを引き受ける方向ではなく、言語の表現力を増す（＝複雑な現実を表現できる可能性を増やす）方向が良いのではないかと思う。まんま内部DSLのホスト言語のイメージだけど ^^;
- Rubyは（動的型付けやクロージャ、オープンクラスやメタクラス、Mix-Inなどによって）かなり表現力が高い。これが、内部DSLのホストとして好まれる大きな理由の1つじゃないかと思う。
- アルゴリズム記述用擬似言語みたいなものを目指す、と言っていたけど、それはアルゴリズムに特化しているだけで、アルゴリズムは書きやすくなるかもしれないけど他の部分に影響が出る可能性があるのでは？
自分のような言語のシロウトがMatzに疑問を持つのもアレなんですが、このあたりの疑問は解消されないまま今に至る。
コメント
またソフトウェアの種別によって多様なプロダクトラインの作り方があることや、類似性を分析していき効率化に製造に持っていくところを追求したりします。その場合であっても創造性は最大限犠牲にしたりはしていません。カーネギーメロン大学やマイクロソフト社のソフトウェアファクトリがこうした活動の例ですし、国内でも多くの事例があります。
# ノートには走り書きで「ソフトウェア工場」「誤解」と書いてますが、脳内変換した可能性は捨て切れません^^;
が、それが最近のいわゆるソフトウェアファクトリを指しているかは結構あやしいところで、主眼はむしろ「工場や生産ラインのメタファでソフトウェアを開発する」という点にありそうでした。
とした場合でも、工場のプラクティスを使うのが完全に間違えている、というのが（たいていは成り立つのでしょうが）常に成り立つのか、というのが疑問として残っています。
流れ作業にできるところはソフトウェアにすればいいじゃん、という話になると、確かに当てはまるのかもしれませんし、それが正しい姿勢なのかもしれません。ただ、創造性のない仕事でも自動化のコストより人手でやった方が低コストなため、流れ作業を選択することもある気がしてもやもやしています。
そんなことはないと思います。むしろ、製造業から学ぶことの方が多いでしょう。生産性や品質管理、人の管理や育成は製造業にくらべてソフトウェア開発は大きく遅れています。歴史の違いといえるかもしれません。リーンやカンバンなどまだ外見だけを真似ている段階でしょう。ただ、日本はそういう優れたものを持ちながら、違う産業から学ぶことが少なすぎるのではないでしょうか。
>創造性のない仕事でも自動化のコストより人手でやった方が低コスト
少量多品種のときはそういう場合もあるでしょう。DSLがカバーするドメインの大きさやフレームワークの汎用性や使いやすさによると思えます。たとえば、IDEを使うよりテキストエディタの方が生産性が高い場合があることなどもこの例ではないでしょうか。