makotan _at_ gmail dot com

始まるまでの長い道のり

c11t

某S社で作ってたプロダクトBを開発してたメンバーと離ればなれになって、困ったのがプロダクトBを使える場が無くなったこと。それに、その頃プロダクトBが依存してたライブラリSのコミュニティー活動全体のアクティブ度に変化が起きてて、ライブラリBも含めて長期的にプロダクトBにも不安が出てきた。
とはいえ、プロダクトBが本来持ってたとてつもない将来性を失うのは惜しいなぁ〜って思いつつ


新たなプロダクトBを作る計画B-1をスタートした。
B-1はプロダクトBと同じ方向性、プロダクトBが依存してたライブラリ群の大幅な変更
という感じで検討と初期開発を始めたものの、依存ライブラリ群が変わっただけで本質的な変化をしてなかったので、途中で新しいライブラリ群の足回りの準備の無さが足枷になってしまった。
よく考えたらプロダクトBはそれまでのいろんな底辺ライブラリ群の上に作り上げたんだったと。
すなわちライブラリSが・・・
という流れで計画B-1は終了


新たなプロダクトBを作る計画B-2をスタートした。
B-2はプロダクトBとB-1の問題点の依存ライブラリ群を大きく変える方針を打ち出して・・・
使えそうなライブラリのリストアップなどをしてみたら、ライブラリの種類も数も全然足りない(ToT)
不足分を作ろうにもそれだけで相当時間がかかるぞと。
という流れで計画B-2は終了


ここまでで最大の問題は依存ライブラリ群って事が明確になったので、適切な依存ライブラリを探し回る旅をしてみた
平行してプロダクトBの本質、プロダクトBが持ってたメリットを抽出をがんばってた
その頃言語Jのブームは過ぎ去り、言語RとかPlatformNがブームになりつつあった


それから新たなプロダクトCを作る計画をスタートした
重要ポイントは

  • 制限としての依存ライブラリを無くす
  • プロダクトBの特徴点数個を残して他の特徴は全部削除
  • プロダクトCに関してはプロダクト自体の生産性を高める
  • 入力フォーマットも全面的に見直す

という流れで、とりあえず流行りつつあった関数型言語に手を出してみたりした。


プロダクトCのための定義言語Xを考え始める
プロダクトCで必要な特徴を洗い出し、それに必要な定義言語Xを計画し始める。
定義言語Xの特徴は言語Jでやると相当面倒になるし、言語Sも理想からは遠い事が判明
他の言語Rや言語jなども調査をしてみた結果自分の知ってる殆どの言語、定義言語類が定義言語Xの特徴を持っていないことが判明
定義言語Xの開発を始めようかと思ったときに、見つけた遺跡言語Lが適合度が非常に高い事が判明
言語Lの特徴をもつPlatformJの言語を探し、勉強してみたら定義言語Xの特徴と完全に一致し定義言語が決定
ついでなので、その言語で全体を書くことにした


ということで、採用されたのはClojureでしたとさ。
めでたしめでたし