wasabiを殺す パート1


この度、敬愛するJoel Spolsky氏のFog Creek社にてwasabiが削除されたとのことを Jacob Krall氏が記載されておりましたので翻訳してみました。
翻訳した記事をあげることを許可してくだった Jacob Krall氏には感謝いたします。
また後押ししてくれた だるい@あぷれんてぃすの友人にも感謝します。

翻訳ですが素人翻訳ですので間違いが多々あるかもしれません。
解説が間違っていた場合には、コメントか@hayabusa333にご連絡くださると嬉しいです。



ForBugz v8.13.104は少しの手間も無く大円団のもと2015年5月末にリリースされました。なぜでしょうか?
リリースノートのリストに書かれているのはバグ修正とマイナーな変更のみとなります。
しかし裏では巨大なリリースがありました。
15年前から作成されたFogBugzの中にあったVBScriptwasabiのコードは1行も含まれていません。
時代の「終焉」です。

知らない方のためにwasabiは私たちの社内の自作.NETコンパイラでした。
この記事では、私たちがwasabiを作成し、なぜ今それを殺すことになったのか、そしてそれを実行できたのかを wasabiの背景を伝えるつもりです。
フォローアップの記事で、wasabiのいくつかの機能についてをオープンソース化しようと私たちは話し合っています。

時間節約の先頭
FogBugzは私たちの最初の製品であり、CityDeskのバグをトラッキング支援し、当社のコンサルティングの仕事をサポートするための内部ツールとして作成されました。
これはVBScriptで記述され、Windowsのみで動いていました。
しかしFogBugzの最初のパブリックリリースにてユーザはLinux版を求めてきました。
我々は既に大規模なコードベースだったものを捨てて、新しいクラスプラットフォームのバージョンをゼロからスタートすることは行いたくありませんでした。
だから我々がThistleを作成するために初めての夏のインターンを雇いました。
ThistleはPHPVBScriptの限られた一部の翻訳を行うJavaで記述されたコンパイラでした。
これはトークナイザ、単純なパーサ、有限状態マシンベースのPHPのジェネレータで構成されていました。
Thistleで実行することができなかったものについては、ASPに直接PHPのコードを埋め込むための特別な構文などがありました。
それは美しくはありませんでしたが、FogBugzを総書き換えせずに、我々がWindowsUnixの両方をサポートすることができるようになりました。

FogBasic:ウサギの穴の下で
2005年ごろに私たちは心を決めてウサギの穴の下へ飛び降りました。
Thistle はFogBasicとなり、私たちはASPを書くための問題の多くを克服するための新しい言語を作成するためのビジョンを持っていました。
この決定には批判がなかったわけではありませんが、出来るだけ多くのプログラムのエラーが実行時ではなくコンパイル時に見つかるように私たちはなんとかしたかったのです。
そのため我々は、より厳密に言語と一致するようにレクサーを更新し、完全抽象構文木を解析し、型推論の追加など言語に多数の機能と拡張機能を追加しました。

2006年の夏には、FogBasicはwasabiとして知られ、我々は改善を続けるようになりました。
この時点では、ほぼすべてのFogBugz v6.0 の新しいコードには1つ以上の wasabi の機能を使用していました。
wasabiASPPHP、クライアント側のJavaScriptを生成することができます。
これは画像の機能をサポートし、コンパイル時のコードジェネレータを介して有効になり、我々はクライアント側のコードを生成することにより、フラグメントキャッシュとMemoizationの書き込みに必要な機能をサポートすることにより重複コードの量を減少させました。
2009年にFogBugz v7 と一緒にwasabi v3 は公開され、インタフェース、列挙型、Try/Catch、基本クラスを試せるような現代的な.NETスタイルの特徴を持っていました。
FogBugz v7は wasabi v3 の新しいCodeDOMベースのコードジェネレータによって生成され、MonoまたはMicrosoft .NETの代わりに、PHPや古いASPで実行されました。

メンテナンス問題
時間が経つごとに、我々は技術的な負債を支払うことになり始めました。
wasabiとそれに関するランタイムライブラリのコンパイラ部分はソフトウェアの非常に複雑な部分です。
我々はwasabiオープンソース化していなかったため、wasabiへの投資は当社の収益を生み出す製品を犠牲にしてまでも行わなければいけないことを意味していました。
我々はエキサイティングな新しいことに取り組んで忙しくなっていたため、wasabiの更新が停止してしまいました。
wasabiのためにフルタイムの開発者が必要なくらい巨大な依存関係でしたが、私たちのサイズの会社には、それは安くない投資でした。
wasabiは人に対してまあまあなコードを出力しましたが、時折ひどいコードを出力しました。
それにコンパイルに時間がかかりすぎます。
VisualStudioにて簡単に編集したり、FogBugzをデバッカをアタッチすることができませんでした。
FogBugzのwasabiに関して当時の開発担当者である Aaron Maenpaa ???機能という項目でwasabiの機能と多くの癖を文章化しようとして2011年に内部向けにリリースされました。

寿命も邪魔になって
オリジナルのwasabiコンパイラを書いた人は転職していきました。
何人かは、他の場所でパートナーと結婚しました。他の人に関してはFog Creekの他の製品のために移動しました。
もちろん我々はwasabiの事前知識を持つ人を雇うことはできませんでした。2008年に働いていて移動し、4年後に再雇用された私自身を除いてな!
私以外の人はすべからく新規雇用や既存の人々関係なく、wasabiに対して広範囲な学習時間を必要としました。

さらに重要なことに我々は真空の中でいきているわけではありませんでした。
Fog Creekの外ではプログラム言語は進化をし続けていました。
実際、wasabiに追加された機能の多くは、C#2.0に含まれていましたし、その後もC#の主要なバージョンでもいくつも更新されました。
開発者の華麗なアイデアは私たちの小さなwasabi空間の限界によって限定されているように感じるようになりました。

なので、FougBugz Ocelot、FogBugzの最新バージョンの作業とともに私たちはFogBugzからwasabiの削除作業を開始しました
過去にも同じような提案がありました。
過去の提案の1つとして、wasabi 3を起動した時にPythonコンパイルを行う提案もあったが、これは .NETバックエンドを使うことにより否決されました。
2011年、Ted Unangstは「プロジェクトSoy Sauce」という.NETリフレクターとPerlスクリプトの組み合わせにより、可読可能なC#ソースコードwasabiのバイナリ出力をできるようにすることを提案しました。
今回は最終的にRoslynという新たなオープンソースの.NETコンパイラプラットフォームを使うことで最終的に成功しました。

プラグを抜きます
判断するための作業を始めました:

ステップ1:C#に.NETアセンブリからwasabiの出力を変更します。
古い.NETコードジェネレータはSystem.CodeDomなどの最低共通分母抽象構文着から有効なC#VB.NETのコードを生成するとうい古いMicrosoftテクノロジに基づいていました。
我々は必要なコマンドライン引数でwasabiを呼び出し、プリコンパイルステップでFogBugzの作成中の新しいプロジェクトに、そのC#の出力を追加しました。

ステップ2:CodeDOMからRoslynに切り替えます。
私たちはwasabiとの接続を削除し、その時点でCodeDomGeneratorとRoslynGenerator間の機能パリティを接続するために2週間かかりました。

ステップ3:RoslynGeneratorの出力を良くします。
非常に多くの小さなエッジケースを含め、 '!=' や do/while hexリテラルを行う論理演算否定、定数、switch文、簡単な境界を持つループ、他には、ラムダ、初期化子、余分なキャストやカッコのために文字列リテラルwasabiのユニオン・タイプやオプションパラメーターの改善を行いました

ステップ4:wasabiを殺します。
wasabiが出力したC#のファイルをコミットし、FogBugzのリポジトリの先頭からwasabiと.wasファイルを削除します。
また、wasabiが生成していたC#ファイルを生成するための代わりに、ほとんどの言語ファイル生成プログラムを書き換える必要がありました。

学んだ教訓
当社独自のプログラム言語は、FogBugzのVBScriptソースコードからPHPJavaScriptへと、マルチな10年プロジェクトを育成し、最後に.NETの素晴らしい新世界へと移り変わっていくのを手伝いました。
我々は新たな生態系に移植したかった花盛りなコードベースがあったあいだに、wasabiは十年以上多くの意味をなしました。
バックエンドを.NETに切り替えることは2008年には意味がありました。これは管理が容易であり、より高速なプラットフォームにてFogBugzを実行するためです。
我々は単一のバックエンドに統合されたので、手書きのC#のジェネレータを使用してワンタイムコンパイルをする時間に意味があったのかもしれません。
RoslynがリリースされてからはC#に完全に切り替えを行うことへの多くの利点が現れました。

社内でコンパイラを作ることは多くの場合は意味がありません。
これは他の人や会社が使用している標準、オープンな技術に大きく傾けた方が経済的です。
あなたが独自の宇宙を作る場合には長期的に育成していく準備が必要です。
プロジェクトが始まった時、私たちはこれを知らなかったわけではないですが、プロジェクトの途中で言語を切り替えることよりもはるかに簡単です。
新しいプラットフォームへポートしようとするときに自家製のコンパイラは有意義かもしれませんし、私たちはwasabiに数回助けられました。

次の投稿では我々はオープンソース化しているwasabiで新しいRoslynベースのコードジェネレータに関して記載します。
我々はC#のプログラムコードを生成することを検討している誰もがコードジェネレータとしてRoslynを使用することへの道標となることを願っています。