【雑記】 僕とTAKE-DOS、ちょっとだけJava批判

唐突だがちょっとした自慢話につきあってほしい。以下は、MZという8ビットマシンのDISKシステムに関する話だ。

ＭＺ－８０Ｂ、Ｂ２、２０００、２２００、２５００

そのうち、MZ-2000でいわゆる本当にフォーマットが違うのは、地獄の練習問題だけでした。これは、いわゆる400KBフォーマットで、1トラックあたり、1024バイトx5セクタです。
しかも、プロテクトとして一部だったか全トラックだったかに同じセクタ番号が存在して、一つCRCエラーだったと思います。

これ以外は、全部普通の16セクタフォーマットです。
つまり、FDとしても普通の1トラック16セクタ対応+83トラックくらいまで対応していれば、たいてい対応可能です。

(Oh!MZのTAKE-DOSが83トラックあたりまで使用している、MZ-80BF
(だっけ、)だとオーバートラックできなくて動作しないんじゃなかったかと思います。
そもそも、MZ-80BFは70トラックまでしか動作しないことになっており、SHARP BASICは70トラックまでしか使用しない)

　TAKE-DOSは25年前に私がアセンブラで作ったDISK OPERATING SYSTEMだ。（当時16才）こつこつと1年かけて作って、翌年、Oh!MZという雑誌に応募して'85/5号に掲載された。
　そんな昔からアセンブラ書いてたの？とびっくりする人もいるかもしれない。でも、ヲタぶりをカミングアウトすることになってしまうので、よく考えたら自慢にはならない話だな。＞＜；　何やってたんだ？とあきれる人の方が多いだろう。

　実はここからが本題。前記事の言語のところで、信頼性の話をしたのだが、それより重要なのは生産性かもしれないということ。生産性については、アセンブラよりCなどのコンパイラ言語、CよりJavaなどのインタプリタ言語、Javaよりスクリプト言語という順番だと思うが、グローバル変数の扱いやトランザクションなどを考えると、相対的に不具合の発生しにくいのは、やはりJavaなんではないか、ということをいいたかった。
　TAKE-DOSは、わずか数十Kバイトのコードだが、Z80アセンブラだと1年かかった記憶がある。
なぜそんなにかかったかというと、メモリ管理を考慮したサブルーチン化（構造化）ができなかったからだ。アセンブラは全部がグローバル変数のようなものなので今から思えばそうなって当然という感じでもある。最近のスクリプト言語は、さすがにメモリーリークは起きないが、グローバル変数は簡単に扱えるので安易に多用しがちな初心者はドツボに陥りやすい。件名：なぜ「グローバル変数」を使っては、いけないのですか？
　Javaでは普通、グローバル変数は扱わない。そのようなコードを書くと先輩にものすごく怒られるか、後輩にバカにされるかのどちらかである。基本的にJavaは言語仕様がよくできていると思う。しかし問題だなと思うのは冗長なこと。大した処理ではないのに往々にしてソースが長くなりがちである。クロージャがなかったり、文字列や連想配列（ハッシュ）などを簡単に扱えないのも原因の一つではあるが、私が感じるのは、「標準化対応」という重しをプログラマーが常に意識させられるということ。Javaには標準が数多く存在するので、プログラマーはそれを忠実に守ろうとする。Javaプログラマーはまじめで優等生が多いので、無視してしまうと罪悪感を感じ、また劣等感さえ芽生えてくるのだろう。

　Rubyのまつもとさんは短いコードの優位性についてこう述べていた。

「1000行のコードをかいたあとで、「仕様変更です」となると、じゃあこのコードをなんとか修正して、という発想になる。それが、仮に5行で書けるなら、じゃあこれは捨てて新しく書き直そうと思える。その結果、より効率的で変なバグも出にくいプログラムが作れます。」
　私も同じ意見だ。

また、プログラム一つだけなのに、それを動かすのにJarが20～30必要で、サイズも十数Ｍになったりする。自分は数十行しか書いていないのに、いつのまにか十数Ｍってどういうことなんだ？　それから、不必要なJarコードにクラスパスを通すことに何の違和感を感じない人が多いのも問題だ。それは一つの文化なんだろうが本当によくないので改めるべきだ！
　一度Seasarを使ったあるプロジェクトでどうしてもBugが取れないことがあった。自分の書いたコードは悪くなさそうだったので、dependしているJarの何かがおかしいだろうということで洗いざらい調査することになった。案の定、diconファイル（設定ファイルの一種）が含まれているJarが見つかって修正することで解決できたのだがこれに約3日も潰してしまった。このとき思ったのは、「Jarの中の誰も見ないところに入れるなんて、diconを肥溜めに隠すようなものじゃないか。」（下品で申し訳ない）
　そもそもSeasarはファイルゼロ、無設定を売りにしていたはずで、diconファイルがあるのはおかしい。diconファイルは設定ファイルというより、インジェクションのフローに関わる重要な部分である。むしろプログラムに近く、動作の一部を肩代わりしているものだと思うので、開発者は必然的に意識することになる。ということであれば、やはり設定ファイルではなくて、Java言語内で解決すべきところなんじゃなかろうか。当初は敢えてJava言語外に定義することで、開発者に意識させないつもりだったのだろう。しかし実質的に大きく関係しているため、開発者にdiconを意識させなければならない結果となった。むしろ関係をよく知らない開発者は、先ほどのBugは3日でも解決できなかったかもしれない。「diconはプログラムとは別ものであり設定ファイルとは考えたくないのでJarファイルに入れた。プログラマはプログラムだけに集中すればよい。」＜＝これは私に言わせれば、臭いものに蓋をしているにすぎない。Seasarに限らない話だが、DIでは、一見関係なさそうなところが実は関係しているということがよくある。中途半端な依存関係が原因で起こる不具合の対応は恐ろしく時間がかかり難しい。場合によっては肥溜めまで調査しなければならなくなる。まるで探偵が推理をやるように、事件(Exception)から容疑者(Class)を見つけ出さなければならない。jarを含めた森羅万象をすべて把握している神のような者か、私のような何事も信じない性格の悪い人間でないと務まらないだろう。

　それから、アノテーションの多用で、意味不明のコードが多く見られるようになったことも問題だ。Javaを進化させるつもりが言語仕様を歪め、まるで癌のように蝕んでいる。アノテーションは基本的に廃止すべきである。言語仕様に限界があるのなら、小手先のアノテーションじゃなくて、いっそのことGroovyのようにプリコンパイラにすべきだと思う。Javaはグローバル変数の扱いや進化したトランザクション管理などもあって信頼性を高くしたが、逆に冗長性やアノテーションによって綻びはじめているのが現状といったところだろう。

　画面についてはもう終わっているので言及しない。Strutsを改善して生産性を上げようなんて無駄なことは考えない方がいいし、そもそも、Javaで画面を作るべきではない。

＜ちょっとだけJava批判：まとめ＞

　　１．プログラムは努めて短くすべき
　　２．Jarファイルへの依存を少なくすべき
　　３．依存を完全把握できないのならＤＩは使うべきではない
　　４．アノテーションをなくすべき
　　５．画面は作るべきではない

１．３.の解決策として、私はgroovyがあると思う。DIが生産性向上を目的とするならgroovyで十分。あるいは、J2EEコンテナ代わりというのであればReflexで十分だ。依存関係をなくして完全分業したいのであれば設計モデルを含んだ話になる。私は既存の設計モデルではできないと思うので、RESTful SOAによる設計モデルが必要と考えている。いずれにしても、DIはいらない。
２．への対応はプログラマーの意識改革が必要だろう。
それから、５．は主にStruts、JSPのことをいっている。実は今sMashを使っていて、groovyのちょっとした画面編集ができるのだが、これは大変気に入っている。groovyはJavaであってJavaではない。話せば長くなるので別の機会に説明したい。

ところで、「TAKE-DOS MZ」というキーワードでGoogleを検索すると、こんなの＝＞MZ-2000 & FDD が出てきた。TAKE－DOS付きのMZ-2000、最高に欲しい！ちなみに、C-DOSというのは、CarryLabの平野さん（現インフォテリア社長）作のOS。ずいぶん前になるが平野さんと話す機会があって当時のことで盛り上がったのを覚えている。TAKE-DOSのことはご存知だった。