11 F# 2.0 -- 2007~2010

実際には、Microsoftがサポートする言語になる見通しは爽快でもあり、恐ろしくもありました。どういう意味でしょうか? 誰が何を確約しましたか?誰がプロジェクトを管理するのでしょうか?この言語を研究プロトタイプからどれだけ洗練する必要があるでしょうか? 誰が言語を「サポートする」立場に置かれることになるのでしょうか?誰にどんな約束がされたのでしょうか?社内の関係者は誰でしょうか? 成果はどのような基準に照らして測られるのでしょうか?これらの事柄のどれもが、最初は明白ではありませんでした。

すぐ明らかになったこともありました: (ケンブリッジでも平等に人を雇うという最初の話にもかかわらず)プロセスはレドモンドから実行されるでしょう。 DevDivは、専用の「頭数」を介して資金を提供するでしょう(個々のプロジェクトに予算はありませんでした)。 持続可能で長期にわたるサポートが可能な言語を完成させるのに1~2年かかるでしょう。 適用領域として、「エンタープライズ向けの関数型プログラミング」と「テクニカルコンピューティング」に焦点を当てるでしょう。 2007年12月にニューヨークの金融機関の見学ツアーが予定され、 私はモルガン・スタンレー、バンク・オブ・アメリカ、クレディ・スイスなどの機関の中核となるクオンツ(定量的金融)グループに対して 関数型プログラミングに関するプレゼンテーションを自分が行うことになっていることを知りました1

それから6か月かけて、プログラムマネージャー2のLuke Hoban(2007年11月1日 ~ 2010年6月)、開発者のJomo Fisher(2008年 ~ 2010年)とDmitry Lomov(2010年 ~ 2011年)、 エンジニアリングリーダーのTim Ng、およびQAスタッフのMatteo Tavaggi、Anar Alimov、Daniel Quirk、そしてChris Smithを含む最初のチームがレドモンドに結成されました。 Laurent Le Brunは2011年のインターンとしてケンブリッジでのテストコードの手助けをしました。 そしてJames Margetsonは、ケンブリッジで2011年3月までコンパイラーとツールの作業を続けました。 C# チームのMads Torgerson、Luca Bolognese、Raj Paiが初期計画に関わりました。 私は2008年2月にレドモンドチームと一緒に4週間過ごしました。

しかし、すべてが順風満帆ではありませんでした。 新しい言語の開発は物議を醸すことで、否定的な反応を呼び起こしかねないものです。 DevDivは多くの革新的なプロジェクトを進めていました。 たとえば、Iron RubyやIron Pythonのように、「動的言語ランタイム」によって.NETプラットフォーム上の動的言語を推進するチームが結成されていました。 これらのプロジェクトは、どちらも同胞でありながら、開発リソースの競争相手でもありました。 同様に、.NETにソフトウェアトランザクショナルメモリーを追加するための大規模なプロジェクトが開始されました。これは、一部はMSRの影響によるものです。 世界的な金融危機とその影響の中、Microsoftは2009年1月に従業員数を5,000人削減し、プロジェクトは軒並み危険にさらされ、多くのプロジェクトが2014年までに中止されました3 4 5 6

さらに、.NET自体は、以下に説明するように、その適用可能性のいくつかの限界に達すると、以前ほど純粋に積極的なまなざしを受けられなくなりました。

さらに、Microsoftのプログラミング製品は、プログラミング産業界の中の比較的保守的な層に対して訴求していました: これらの人々は、関数型プログラミング言語を受け入れるでしょうか? C# は非常に強力なツールを備えた非常にアクティブなユーザーベースを持っていました。 Microsoftが長年の成長の後に驚くべきプレッシャーを受けたこのような状況では、産業界に適用可能な言語としてF# を使用することは問題外とまではいきませんが、当然のこととは言えませんでした。

そうだとすると、少なくともMicrosoftに関する限り、F# は何のためのものでしたか? 汎用言語としては、答えは「F# はプログラミングのためのものです」でしたし、今も変わらず明白です。 しかし、切り捨てるわけにいかない確立された製品範囲への追加として見た場合はどうでしょうか。 F# は、現実的には、C# 、C++、およびVisual Basicに代わるものとして、何百万もの既存顧客に提示することはできませんでした。 主な要因は、これらのツールチェーンの「デザイナー」ツールでした。 このツールは、ユーザーインターフェーステクノロジーが変更されるたびに、構築および保守に費用がかかり、継続的な混乱を招いていました。 このツールをF# 2.0で使用できるようにすることは現実的ではないと早い時期に決定されました。 経営陣はF# が「Visual Studioの第一級言語」になるだろうと早くから伝えていましたが、 それを、すべてのVisual StudioツールがC# と同様にF# で動作するように作られるのだと受け取った人たちもいました[Somasegar 2007a]。 2つの立場の間にある不調和は、ツールのためにMicrosoftに依存しているユーザーの間でフラストレーションを引き起こしました7

こう言う事情があり、F# に関連する実践的な方法論を特徴付けるために、「関数優先」プログラミングという用語を作りました。 まず 関数型プロトタイピング があり、その後に、(ソフトウェア工学と相互運用性のための) オブジェクトプログラミング と(パフォーマンスのための) 命令型プログラミング という要素が続くものです。 当時の指針としてのスローガンは、「F# はエンタープライズ向けの関数優先プログラミング」です。 さらに、一般的な経済情勢にもかかわらず、Microsoftは2010に開始した新しい「Technical Computing Initiative」(TCI)に投資しました。 これは最終的に300人を雇用し、まったく新しいプログラミング言語Exieを含んでいましたが、結局リリースされませんでした。 F# はこれに直接関与せず、そしてTCIは3年後に主要な製品をひとつも作ることなく再編成されましたが、 しかし、F# はその公開コンテンツの一部と緩やかに連携していました。 そのため、「F# はテクニカルコンピューティング向け」、あるいは単に「F# は数学的なこと向け」というミームが生まれました -- その言い方は正しくもあり、同時に間違ってもいました。 F# の使用が成功した多くの例は技術分野にあり、特に大規模システム内に「計算エンジン」を実装するというものでしたし、 F# は、適切なライブラリーを備えていれば、MATLABまたはPythonのような言語として直接使用することも可能でした。 Harropによる "F# for Scientists" のような本は優れた初期資料であり、F# は金融業界ですでに採用されていました。 DTU(デンマーク工科大学)やコペンハーゲン大学などの大学では、関数型プログラミングのコースにF# を採用するようになり、Michael Hansenは教科書"Functional Programming Using F#"[Hansen and Rischel 2013]を執筆しました。 バイオテクノロジーでは、F# はJoint Genome InstituteでDNA分析に使用されていました[Syme 2006c]。 関数型言語と「数理型プログラミング」との関連付けは、長い間続いてきました。 そして、私たちはそれを避けようと努力しましたが、この通り名はしばらくの間F# に適用され続けました8

Expert F# の最初の2つの版の執筆は、2007年から2010年にかけて正確な言語詳細を洗練するのに重要でしたし、F# 2.0言語仕様の作成も同様でした。 それは、C# 言語仕様の形式で、非公式ではあるけれども厳密な200ページの文書として書かれ、多くのQA作業の基礎として使用されました[Syme 2020]。 言語仕様を執筆し、言語を「校正する」プロセスの間に、F# のコードは簡潔だという強い印象が私に生まれました。 当時、F#のコードは対応するC#のコードよりも常に3倍から10倍短くなっていました -- これは、同じ.NETライブラリーを使用したコードサンプルを単純に翻訳した時に経験したことです9

この間、文字通り何千もの設計提案が fsbugs@microsoft.com を介して寄せられました。当時のMicrosoftにとっては、チームと顧客の間の非常に直接的な経路です。 一方では、これは言語が発売時までに詳細に実証されていたことを意味しましたが、他方ではチームがユーザーの要求に対応することを引き起こしました。 何百ものバグが修正され、多くの設計が改良され、そして複数の「ベータ」バージョンがリリースされました。 この間に、チーム内の役割も変わりました。 私はもっと「プロダクトアーキテクト」のようになる必要がありました。言語の構成に関する最終的で詳細な決定を下す役割です。 2008年からプロジェクトの重心はレドモンド(つまりアメリカ)に移り、オンライン作業とレドモンドチームに直接対面することの両方が非常に重要でした。 品質の重要性が非常に高まり、私たちは削除する機能を探すようになりました。 最終的には、F# 2.0の機能セットはF# 1.9の機能セットによく似ていましたが、言語仕様、設計、実装、およびツールの品質は劇的に向上しました。

2010年4月12日に、アイスランドの火山活動のさなか、そしてすべての関係者にかなりの負担をかけた困難な2年間の後で、 公式にサポートされた最初のバージョンである "Visual F# 2.0" はVisual Studio 2010の一部としてリリースされました[Wlaschin [n.d.]]。 実際のところ、「ビジュアルな」F# は誤称です: 私たちが提供したのは、Windowsエコシステムでの採用に適した、強く型付けされたコード指向の関数型プログラミング言語でした。 これは大きな前進であり、強く型付けされた関数型プログラミングの産業界における注目度を引き上げました。 しかし、それ以上のものが必要になりそうでした。


インデックスへ戻る


  1. 振り返ってみると、これらのクオンツグループは、2007年後半にはもっと重大な心配事を抱えていました。あるときニューヨークで、筆者が世界市場の構造的な問題について質問したところ、F# のクオンツは「そうだ、それを見抜くべきだった」と言い、世界的な金融危機に「個人的な責任」を感じていると付け加えました -- これは、筆者が金融業界で働いてきた経験の中でも、個人的な責任を認めた珍しいケースでした。 

  2. 2008年当時のマイクロソフトでは、プログラムマネージャーは、製品の提供、お客様との対話、仕様策定など、幅広い責任を担っていました。このことは、PMが開発組織に対して「お客様を代表する」と言って要約されることが多く、製品化戦略や、製品が社内でうまく位置づけられるようにすることに大きな責任を負っていました。 

  3. 記事「Microsoft、ソフトウェアトランザクショナルメモリーに関する実験を終了」[Allen 2010]。 

  4. 記事「MicrosoftはIron言語を切り離す」[Clarke 2010]。 

  5. 記事「MicrosoftはDryadを捨て、ビッグデータではHadoopに移行」[Foley 2011] 

  6. 記事「Microsoft、シリコンバレーの研究所を閉鎖」[Foley 2014] 

  7. この問題が本当に適切に解決されたのは、2017年にF# のツールが大幅に改善されたことと、同時期にマイクロソフトの製品ラインアップで「Visual」プログラミングの比重が下がったことによります。 

  8. 2015年頃、F# がオープンソースのクロスプラットフォーム言語として発展し、Webやクラウドのプログラミングに強いというストーリーを持つようになると、ようやく重視されなくなりました。現在のF#は、あらゆる種類のプログラミングに対応しています。 

  9. 簡潔さについて完全に制御された状態で比較することは難しいのですが、F# とC# を使って似たようなシステムを実装した2つのチームについてSimon Cousinsが後から分析を行い、納入されたプロジェクトに関しては、実装サイズが350,000コード行(C#)から30,000コード行(F#)に減少したことを明らかにしました[Cousins 2016]。 


Last Update: 2021-09-25 19:00:12