Clojureでやろうとしなくなりました話。

 Clojureでやりたいと思った理由はもちろんいくつもありますが、断念してしまった理由もいくつかあります。致命的と言えなくもないものはあまりなくって、かなり判断に迷ってというかClojure路線を続けたかったのが本音のところでした。
 ちょっと時間も経ってしまって、もはやうろ覚えの顛末を軽くねつ造を交えながら書いていこうと思いますよ。

 今回のプロジェクトは既存のJava製Frameworkのクローンものです。構想としては、Clojureを使って別名で各クラスを実装。そこにFrameworkと同名の薄いラッパークラスを拵えて互換性を確保するというものでした。最初から二段構成を考えていて、これは面倒だけどもある程度仕方がないと割り切っていました。
 そもそもClojureはJavaを置き換えるものではなくって、共存して補完しあうものなんですよね。どこかで開発者の方もそうおっしゃっていたと思います、ソースとかはパッと出せないけど。だから今回みたいにJavaの何かクローンするみたいな事には向いてなかったのかも知れません。新しい何かをJavaを活用しつつ実装するみたいな事に向いているのでしょう。

 まずひっかかったのは、メソッドの引数に自分のクラスを渡そうとすると普通にはコンパイルできない事。どうやら事前に存在確認をするみたいでクラスパス内に.classが存在しないとその時点でエラーになる。自分自身なんだからよしなにしてくれたっていいじゃないと思ったものの納得できなくもないので、ダミーのほぼ空っぽのクラス定義を書いて事前にそちらをコンパイルしてから本クラスをコンパイルする事に。そのダミークラスには処理を実装する必要はありませんでしたが、対応するコンストラクタの定義程度は必要になりました。この時点でかなり揺れました、気持ちが。だって三段やないですか、面倒にも程があるやないですか。いっそPure Javaで……、この言葉が浮かびます。
 しかし、そこはClojureへの気持ちで乗り切ります。互換レイヤーのラッパークラスだってそのまま素通りさせるくらいで、大した手間のかかるものでもないし、少し気をつけてビルド処理を行えばいいじゃないかと。

 次に発覚したのはClojureで実装するクラスには静的変数が定義できないという事。そらまぁ、必要ないんでしょう。ないですよね。関数型言語だもの。でも、一応クローンなので互換性の為にもちゃんと定義しておきたいのです。定義しないといけないのです。
 これもいろいろ対策を考えて、いっそコンパイラの方もソースが公開されているので手を入れてしまおうと、あ、私じゃなくてお相手さまがおっしゃったりしたのですけど、簡単な方法としては互換レイヤーの方へ実装する事ですから、とりあえずその方向で進めておりました。が、矢張りこう釈然としない、Clojureだけでも完結できるような形を目指してたのに、基本的に実装するのはClojureでだけのつもりだったのに。いっそPure Javaで、この言葉が沸き上がります。

 そうしてまたあれこれ考えまして、Javaの方が実装しやすい部分もあるので、もうJavaをメインクラスに据えてClojureはサポートクラス的な位置づけで実装してみてはどうかという話が持ち上がりました。これだと最終的なおさまりが良さそうで、かつClojureでのプログラミングを楽しむ的な部分も確保できそうです。しかし、結果的にはこの決定がトリガーになりました、いっそPure Javaの。
 Javaの方に実装が入り込んでくると、これはJavaでやった方がいいのか、Clojureへ持って行った方がいいのかの判断が必要になります。基本的にClojureでとやっていきましたけど、両方に違う言語で平行して実装をしていかなければならない事にうんざりしてきます。面倒だし、まとまりは悪いし、なんか変なノウハウばかりたまってきている気がするし。あぁ、もうPure Javaで、Javaだけでいいじゃん、好きになろうぜJava、ついにこの言葉へ辿り着きました。

 そんなこんなで無駄に足掻いてグダグダしたあげくに落ち着くべきところへ落ち着きました感じです。けれども、一番大きかったのは某汎用ビルドツールを使っていて依存性とか解決するの辛いよねーって事だったかも。人生いろいろ。違うか。