渋日記@shibu.jp

Ruby技術者検定試験は、普段毎日Rubyを書いている人なら受かる、というお話でした。それならば毎日Rubyを書けばいい！と。使っているのはJRubyとSWTです。思ったよりも速いですね。継承、モジュール、多種多様な制御構文、データ構造などRubyの要素をなるべく使うようにしています。

続きを読む

オブジェクト倶楽部のライトニングトークスで発表してきました。どういった経緯でこのアウェイなネタができあがったのか、ネタ晴らしをします。

続きを読む

http://itpro.nikkeibp.co.jp/article/Watcher/20080228/295033/

自動車をモデルにソフトウェア開発を考える。まぁ、思考実験として面白いネタかも。

自動車メーカーがやっているのは部品を組み立てて製品にするのはそうなんだけど、シャーシの設計はほとんどのメーカーが自前。シャーシ構造は共有のために共通化することもあります。プラットフォームと呼ばれます。プラットフォームはエンジンの積載性、タイヤ類の可動部分、バネ、衝突安全、居住性、静粛性など、さまざまな要素が絡んできます。当然、(中国がまだ遅れていると言われている)素材技術も重要。このあたりはMotorfanの別冊か何かが本屋に並んでいるので読んでみるのをおすすめします。プラットフォームは、多細胞な自動車会社だと、メーカーを超えて共有されたりします。スマート for4と三菱のコルトが共用している、とかそういうやつね。

ソフトウェアにおけるプラットフォームというと何が考えられるか？WebのシステムだとWebアプリケーションサーバ一式だよね？自動車メーカーはそれぞれ、AセグメントからEセグメントなど、数種類のプラットフォームを持つけど、果たして、NECやらNTTやらFujitsuやらがそういうプラットフォームをいくつも作って使い回す、ということが可能なのかな？この記事はアプリケーションフレームワークから、データベースから何から何までぱちぱち組み立てるとシステムになるぞ、ぐらいの気持ちで言っているような気がする。でも、肝心の部品の所っていまは全然日本には力がないところ。日本全部見渡してせいぜいSeaserぐらい？

あと、自動車とソフトウェアの最大の違いは、自動車は使い方が決まっているということ。ハンドル、アクセル、ブレーキは一緒です。例えタタ自動車のナノであろうと、軽自動車であろうと、ハイブリッドだろうと、メルセデスだろうと、基本は一緒。そして見て比べられる。さわれる。乗って善し悪しを現物で確認できる。でも、一品モノのソフトウェアはそこまで一般化されてない。つまり、部品をぱっと交換どころか、プラットフォーム戦略もすぐには使えないですよね。

それに、あんまり最適化と言い過ぎると、OEMで他社に車を作ってもらって、バッチだけつけて「新型車です」みたいになっちゃいますよ。本当に競争力をつけるには、フレームワークを作ってどんどん公開していく、というのが必要じゃないかな、と思います。

a2cさんのエントリーが気になったので、僕なりの考えをまとめます。決めつけで書いてますが、ご意見があればコメントなりトラックバックなりを頂ければ、と思います。

まず、インスタンスとオブジェクトですが、これは同じモノだと思います。プログラミング言語Rubyには「インスタンスはオブジェクトのおしゃれな言い方」だか「キザな言い方」と書かれています。

僕の中のオブジェクト指向の母はC++。僕の中でオブジェクトというのは「関数ポインタ＋変数のテーブル」です。クラスで定義したメソッド自体はオブジェクトは持っていません。オブジェクトが持っているのは関数のポインタだけ。オブジェクトは自分が使えるメソッドの情報だけ持っています。

オブジェクトを生成する「モノ」がクラス。クラスはオブジェクトではないです。C++では。JavaやPython、Rubyはクラスもオブジェクトです。これはなぜか？クラスという概念を、オブジェクトという仕組みで定義してみた、という言語ごとの都合でしかないと思います。

プロトタイプとは何か？というと、プログラムの中でオブジェクトを組み立てて、それを複製してオブジェクトを作る仕組みです。クラスベースのオブジェクト指向とは違う仕組み。IOとかいくつかの言語が取り入れています。clone()だか、copy()というメソッドを作り、動的にメソッドやデータを追加して、複製して開発していく、というスタイルにしていけばプロトタイプになると思います。

オブジェクト指向って、厳密な定義がなくて、各言語の実装ごとに雰囲気が違うんですよね。だいたい自分が最初に学んだ言語の特徴で「オブジェクト指向ってこうなんだ」と理解している人が多いです。僕はオブジェクト指向は「プログラムを階層構造に整理するための技法」程度にしか考えてません。なので、Pythonの「クラスもオブジェクトもすべて名前空間」というあっさりした考え方が好きです。

C言語でもオブジェクト指向はできます。関数ポインタ＋データテーブルを構造体で定義して、メソッドの第一引数で、その構造体を受け取れるようにしておけばいいから。Gaucheとかのオブジェクト指向実装もそんな感じでした。

僕の考えなので人によって色々だと思います。

Cのコンパイラが、それ自身、C言語で作られていて、コンパイルされて作られる、という再帰性に、言い表せないような神秘性を感じたのが大学時代。そこまで大げさじゃなくても、スタックというデータ構造を使って動作する構造化言語ってなんか美しいよなぁ、と、ふと思いました。

データを積んだら、積んだのと逆の順序で取り出すというシンプルな仕組みなのに、今、普通の人が触れる多くのプログラムを実現しているんだもんね。初めて買ってもらったツインファミコンのマリオ２から、今現在、僕の目の前で動いている最新のWindows Vistaのパソコンまで。ゲームとかもそうだしね。mixiでこのことを書いたら、あまのりょーさんから「逆ポーランド記法の電卓は慣れると楽しかった」とのコメントがありました。確かに、逆ポーランド記法が分かると、急にコンピュータの動作に親しみを感じます。スタックを自分で作成、解くという流れが見えるようになりますからね。

なんで、そう思ったかというと、茶道の動きがちょっとスタックっぽいんだよね。お茶を飲んだら、お椀を洗う。右足から茶室に入ったら、左足から出る。とかね。やった行動に対して、それを巻き戻す動作が入って、また最初の状態に巻き戻っていくんですよね。まぁ、あれだ。マイケル＝ジャクソンの Earth Songのプロモ(環境破壊、戦争などの映像が流れた後に、急速に撒き戻っていく)を見たときの感動がそうかも。

そういうことを思いついたら、スタックという構造ってなんかシンプルで美しいなぁ、と思いました。現実世界では、何かあったら、それが完全に撒き戻るということはないです。エントロピーは増大する一方。そういう意味で、何か神秘的な魔術のような感覚があります。