The Origin of LINQ to SQL を訳してみた

.NET

「The Wayward WebLog」より Matt Warren の『The Origin of LINQ to SQL』
昨日そばを食べてから作業を初めて，本当は昨年中に終えたかったんですが，結局ずれ込んでしまいました．意訳全開ということもあって，だいぶ誤読・誤訳が混ざってそうなのにご注意を．ここまで必死に英文読んだのは大学の入試勉強以来かも．細かいところの見直しはちゃんとやっていないので，後で気付いたらなおします．

LINQ to SQL の起源 (原文)

LINQ to SQL，こいつは恐らくマイクロソフトが 10 年挑戦してきた中で初めて実際に出荷される Object/Relational Mapping だけど，かつてこれは存在するとさえ思われていなかったんだ．
それはちっぽけな Visual Studio Project として私のデスクトップ機で始まったんだ．遡ること 2003 年の秋，それについて誰かが耳にする遙か前に，次に何が訪れるかを誰かが考える遙か前にね．このブログの読者を除いては．もちろん，復号に使う正しいワンタイムパッド*1があれば，私が何を考えていたか想像できたかも，というぐらい私の投稿は長ったらしく飲み込みにくい，そして時にサイケデリックな蛇行運転だったんだけど．私は来るべき何かに備えるそのプロジェクトを必要としていた．私には expression trees と基本的な SQL の間のトランスレータが必要だった．C# のコードベースを手にとり，それを別の言語，気分転換に実際何か面白いことをしてくれる言語，どのように query をするか知っている言語，に変えるその日に備えてね．(ここで FoxPro ファンに合図！)
ラッキーなことに，基本的な部分を動かすのにそれほど時間はかからなかった．知っての通り，私がありあわせの材料で ORM を作ったり，言語を弄ってクエリ能力を加えたりするのは最初のことじゃない．ObjectSpaces，そして C-Omega の一部が既にデザインを終えていたので，私は確かに仕事を終えることができたんだ．幸いにも，“次に” 何かをデザインして作るときにはもっと簡単になる．特に前にデザインしたのがキミ自身で，キミが新たにやり直す機会をつかんだのであれば．LINQ to SQL は ObjectSpaces vNext，あるいは vNextNext として始まったと言えるかもしれない．なぜって私は実際に ObjectSpaces が 1 つの形に落ち着くまでに異なる 3 つの動作するプロトタイプを作ってたし，その後 C-Omega の基礎となるもうひとつのシンプルなものを作ったから．
でも，私は本当に全てを兼ね備えた ORM system の作成に取りかかっていたわけじゃなかったんだ．私は単に LINQ のタイヤを回すための何か，いわば mock LINQ Provider を必要としていただけだった．そのとき我々みんなが考えていたのは，結局 ObjectSpaces，そして WinFS ですら，我々が捻出したパターンを受け入れるだろうってことだった．だから私は単純に ObjectSpaces とともに始めることにした．そして正直なところ私はそうしたかったんだ．でも私は，LINQ が少し別の何かを必要とするだろうことも知っていた．ご存じのように ObjectSpaces は元々 Whidbey なんかよりずいぶん前に登場するはずだった．その本来のターゲットは Everett (.NET 1.1) だったんだ．Luca*2 と私がそのプロジェクトを始めたのがそもそも .NET 1.0 の出る数年前だと理解していれば，そんなにおかしな話には聞こえないよね．(当時，私のマネージャはObjectSpaces の後に何が来るかをそれだけを私に尋ねたんだ．次に来る大きなものは何だ？ って．プログラミング言語への統合がまさにそれだ，とすぐに思い至った．文字列からクエリを外に出して，コンパイル時の型チェックを取り戻してそれからインテリセンスとそれに似た奴．私がそれほど聡明でも先見の明があったわけでもないんだけど，私たちは既に新しいデータベースプログラミング言語のためのアイディアの肉付けに取り組んでいたから，彼のオフィスに行くまでにはその事で心がいっぱいだったんだ） ObjectSpaces の大きな欠点は，そのクエリ能力の制限されていて（述語だけ），文字列の中のクエリにだけ注目していて，そして Generics による強い型付けを欠いていることだった．たとえ ObjectSpaces が遅れて Whidbey あたりを目標に設定し直したとしても，劇的な変更について考え初めるにはデザインという点で彼らは既に遠くまで来すぎていた．ついでに私が言語にしようとしていたことはどれも，彼らが出荷してから長いこと経つまで彼らに影響を与えないことだった．だから，彼らは LINQ に着手するのは次のバージョンで，ということにしたんだ．
そう私が LINQ に食わせてやる必要があったのは，まさにコンパイラによって生成される強く型付けされたクエリツリーによって，リレーショナルに完全なクエリを処理する，Generics と IEnumerable 周りについてデザインし直された，言語に統合された ObjectSpaces だった．まさにそれこそが， 結果的にObjectSpaces v2がそうなって欲しいと私が願ったものだった．でも私にはまさにそのとき，LINQ をデザインし制作する対象としての何かが必要だった．
なぜ WinFS と始めなかったかって？ 結局のところそのときそいつは SQL Server 党の間で大流行していた．残念なことに ObjectSpaces と同じ話さ．彼らは我々より先に出荷しようとしていた．我々は彼らのレーダーの中にはいなかった．彼らは我々よりもプライドに凝り固まっていたんだ．言うまでもなくWinFS は私が証言できる最大の失態だと信じているけど，まあそれは別のお話．
それでも，その話の一部は LINQ to SQL を実際の製品にする原動力だったんだ．
WinFS のクライアント API は， ObjectSpaces のコードベースをまるまるコピーするところからまあ始まって，全て同じ限界を持っていた．そいつはただ，社内勢力図のなかの高いところにいるお方に指揮されていたからより強い政治的影響力をもっていて，そして壮大な内部の縄張り争いを生み出す流れの中に位置づけられていたんだ．外から見ている私たちは，かつて WinFS のことををこう言っていた． ブラックホール，永遠に大きくならなくて，利用できるリソースを全て飲み込んで，何も脱出できなくて，そして最後には別の現実に通じるゲートウェイ以外の何も生み出さない．我々の多くの友人と同僚が既に飲み込まれていた．そして毎週のレポートと失敗談は恐ろしいものだった．結局それは ObjectSpaces も飲み込んでしまった．やめにする過程で WinFS v2 が何もかも「整列」できるように．
このとき，LINQ をデザインしていた我々はそれほど心配していなかった．開発部門で WinFS のミッションを信じていた人はそう多くはなかったんだ．大衆向け開発ツールには，ローエンドをターゲットとしたシンプルな何かであることが重要だから．かつてそうだった ObjectSpaces は，今や過去のものだけど． WinFS v2 が結局正しさを取り戻して使いやすい一般的な ORM ツールになるという可能性はかすかに残ってた．でも全ての希望は Vista から WinFS が引き抜かれるときに打ち砕かれ，存在自体が危うくなってしまった．彼らはすぐに引き返して ObjectSpaces を持ってきて，それは確かに動くものではあったけど，でも間の数ヶ月で，ObjectSpaces は .NET 2.0 の一部になるための引き返し限界点よりうしろに滑ってしまっていたんだ．SQL 党の中での人事異動はコントロールを失ってぐるぐる回り，そして ORM について何でも知っている専門家の大半は既に逃げ出していた後だった．
そのとき我々は選択肢がないことに気付いたんだ．LINQ が成功するには，立つための足が何本か必要だった．私が作っていた Mock の ORM はかなり良い競技者になりつつあった．C# 3.0 のデザイングループの一部として，LINQ と歩調を合わせながら我々はそれを一緒にデザインし，本当にそれは一人前の実装になったんだ．我々はそれを本当に製品として出荷するとは思ってなかったんだ．単にそれは，今や存在しない製品のための代役として働くはずだった．そして，LINQ と一般の開発者のために，公式に我々は ORM の松明を掲げたんだ．我々が何を考えているか内部にアナウンスし，その後 3 年間の私の人生となる政治的な悪夢の幕を開けながら．

あわせて読みたい

*1:訳注:乱数鍵を１回だけ使う暗号の暗号表

*2:訳注: [http://blogs.msdn.com/lucabol/:title=Luca Bolognese] か