F＃の使用がC＃よりも適切な領域はどこですか？
過去数年間で、F＃は、OCaml、ML、Haskellで培われた多くのアイデアを採用したMicrosoftの完全サポート言語の1つに進化しました。
過去数年にわたって、C＃は、より多くの機能的な言語機能を導入することにより、汎用機能を拡張しました：LINQ（リスト内包表記）、ラムダ、クロージャー、匿名デリゲートなど...
これらの機能的な機能のC＃の採用と不純な機能言語としてのF＃の分類（必要に応じてフレームワークライブラリにアクセスしたり、関数が呼び出されたときに共有状態を変更したりできる）ことを考えると、2つの言語には強い類似性があります独自の極反対の主な強調。
実稼働ポリグロットプログラムでこれら2つの言語を採用し、過去1年間にF＃で記述した実稼働ソフトウェア（Webアプリ、クライアントアプリ、サーバーアプリ）内の領域で成功するモデルに興味があります。 C＃で書かれています。
私は、発電所のポートフォリオの国内発電スケジュールとエネルギー会社の取引ポジションのバランスをとるアプリケーションを作成しました。クライアントとサーバーのコンポーネントはC＃でしたが、計算エンジンはF＃で記述されていました。
このアプリケーションの中心にある複雑さに対処するためのF＃の使用は、エンタープライズソフトウェア内の言語のスイートスポット、つまり、大きなデータセットのアルゴリズム的に複雑な分析を明確に示しています。私の経験は非常に前向きなものでした。特に：
測定単位私が働いている業界には単位が散らばっています。私が実装した方程式（多くの場合、幾何学的性質のもの）は、時間、電力、エネルギーの単位を扱いました。型システムに関数の入力および出力の単位の正確性を検証させることは、テストとコードの読み取り/理解の両方の点で非常に時間の節約になります。これは、以前のシステムで起こりがちだったエラーのクラス全体を根絶します。
探索的プログラミングスクリプトファイルとREPL（F＃Interactive）を使用して、従来の編集/コンパイルよりも実装をコミットする前にソリューションスペースをより効果的に探索することができました。/run/test loop：プログラマーが問題とプレイ中の設計の緊張についての理解を深めることは非常に自然な方法です。
単体テスト副作用のない関数と不変のデータ構造を使用して記述されたコードは、テストする喜びです。物事を台無しにする複雑な時間依存の相互作用や、あざけるべき依存関係の大きなセットはありません。
相互運用 C＃で計算エンジンへのインターフェイスを定義し、F＃で計算を実装しました。計算エンジンは、相互運用性についてまったく心配することなく、使用する必要のあるC＃モジュールに挿入できます。シームレス。 C＃プログラマーは決して知る必要はありません。
コード削減計算エンジンに供給されるデータの多くは、ベクトルと行列の形式でした。高階関数は、これらを最小限の手間と最小限のコードで朝食に食べます。綺麗な。
バグの欠如関数型プログラミングは奇妙に感じることがあります。私はアルゴリズムに取り組んで、コードが型チェッカーをパスするように一生懸命努力することができますが、型チェッカーがそれを満たすと、それは動作します。ほとんどバイナリで、コンパイルできないか、正しいです。奇妙なEdgeのケースエラーは最小限に抑えられており、再帰関数と高階関数はEdgeのケースエラーを引き起こす多くの簿記コードを削除します。
並列性結果の実装の機能的な純度により、データのベクトルの処理に固有の並列性を活用するのに適しています。 .NET 4がリリースされたので、ここで次に行きます。
Microsoft Researchでのインターンシップ中に、Visual Studio IntelliSense for F＃（それ自体はF＃で記述されています）の一部に取り組みました。以前のC＃プロジェクトでIntelliSenseを使用した経験があるため、この2つを比較できると思います。
Visual Studioの拡張性は依然としてCOMに基づいているため、非常に素晴らしい.NETオブジェクトではない（そして間違いなく機能しない）オブジェクトを扱う必要がありますが、C＃とF＃の間に大きな違いは感じません（スムーズに動作します） F＃から）
F＃でプログラムコードを表すために使用されるデータ構造は、ほとんど差別化された共用体（C＃では合理的な方法でサポートされていません）であり、 hugeこの種のアプリケーションの違い（プログラムコードなどのツリー構造を処理する必要がある場合）。差別化されたユニオンとパターンマッチングにより、コードをより適切に構造化できます（仮想メソッドのすべての場所に関連する機能を保持するのではなく、関連する機能を1つの場所に保持します）
以前は、F＃のCodeDOMプロバイダー（F＃で記述されている）にも取り組みました。私は実際に最初にC＃で実験しましたが、その後コードをF＃に変換しました。
CodeDOMプロバイダーは、.NETオブジェクトを使用して表される構造をトラバースする必要があるため、独自のデータ表現（F＃がニースの利点を提供できる領域）を発明するためのスペースはあまりありません。
ただし、タスクを簡単にする多くの小さなF＃機能がありました。文字列を生成する必要があるため、文字列を構築するためのカスタム演算子を定義し（
StringBuilderを使用）、それらと高次関数を使用してコードを実装しました（指定された文字列などを使用してオブジェクトのリストをフォーマットするなど） 、これにより多くの繰り返し（および退屈なforeachループ）が削除されました。
これらは2つの比較的具体的な例ですが、どちらもプログラムの表現、式、またはより一般的には複雑なツリーのようなデータ構造の操作に関連しています。この領域では、F＃は間違いなく良い選択だと思います（C＃の機能的機能に関係なく）。
F＃（ F＃for Visualization ）と2番目（ F＃for Numerics ）で書かれた世界初の商用製品と、F＃に関する最初の商用文献（- F＃.NET Journal ）およびF＃の現在のバージョンに関する唯一の本を書いて発行します（ Visual F＃2010 for Technical Computing ）。
C＃で記述された同様のライン（例： this ）に沿って製品を出荷していましたが、OCamlの商用利用にも強いバックグラウンドがありました。 F＃が2006年にまだ研究のプロトタイプであった頃、私たちはF＃の熱狂的な初期の採用者でした。結果は信じられないほどの成功であり、F＃は私たちの高い期待をはるかに超えています。
私たちにとって、F＃にはさまざまな利点があり、さまざまなアプリケーションに使用しています。本番環境には数十万行のF＃コードがあります。現在、LOBアプリのallにF＃を使用しています。クレジットカードトランザクションはF＃コードを使用して処理され、製品通知はF＃コードを使用して送信され、サブスクリプションF＃コードを使用して処理され、アカウントはF＃コードなどを使用して処理されます。おそらく、ここで配当を支払う主な言語機能はパターンマッチングです。 F＃を使用して、最新の本を強調する構文に色を付けました...
私たちの視覚化ライブラリは大売り手であり、その機能はVisual Studioで実行されるF＃インタラクティブを中心にしています。私たちのライブラリは、最小限の労力でインタラクティブな2Dおよび3D視覚化を生成する機能でこれを強化します（たとえば、サイン波をプロットするためのPlot([Function sin], (-6., 6.))だけ）。特に、すべてのスレッドの問題は完全に自動化されているため、ユーザーはUIスレッドとディスパッチについて心配する必要はありません。ライブラリのこの部分を書くとき、一流の関数と怠dataは非常に価値があり、代数データ型は他の場所で広範囲に使用されました。お客様がWPFのヒットテストでパフォーマンスバグに遭遇し、10,000倍のパフォーマンス向上のためにF＃で関連するコードを簡単に再実装できる場合、予測可能なパフォーマンスもここで重要であることが判明しました。この製品のGUIは自由形式であるため、GUIデザイナーとC＃は有益ではありませんでした。
私たちの仕事の多くは、私たちの商業図書館と本の両方を含む数値的手法を中心に展開しています。 F＃は、パフォーマンスのペナルティを最小限に抑えて高レベルの抽象化（高階関数など）を提供するため、この領域ではC＃よりもはるかに強力です。このコンテキストで最も説得力のある結果は、LAPACKのリファレンス実装からのFortranコードより20倍短く、ベンダーが調整したIntel Mathよりも最大3倍速い、線形代数からのQR分解の単純で一般的な実装の作成でしたカーネルライブラリとより汎用的です。これは、コードがシンボリックマトリックスを含むあらゆるタイプのマトリックスを処理できるためです。
現在、F＃（ガッツ用）とC＃（シム用）を組み合わせたWPF/Silverlightコンポーネントを開発し、ソフトウェア製品のインタラクティブマニュアルとして機能するWPFアプリを構築しています。新しい本、Multicore F＃を書いています。 .NETでの共有メモリ並列プログラミングの決定的なガイドになります。
過去6か月ほどで、Visual Studio 2010のVimエミュレーションレイヤーに取り組んできました。これは、すべてのソースがgithubで自由に利用できる無料の製品です
- GitHub： http://github.com/jaredpar/VsVim
- VsVim on Visual Studio Gallery
このプロジェクトは、個別のレイヤーを表す3つのDLLに分割されています。各層には、対応する単体テストdllがあります。
- Vimエンジン：F＃
- 装飾とエディター統合のためのWPFレイヤー：C＃
- Visual Studio統合レイヤー：C＃
これは、私がF＃で行った最初の主要なプロジェクトであり、この言語が大好きだと言わざるを得ません。多くの点で、私はこのプロジェクトをF＃の学習方法として使用しました（そして、この学習曲線は、プロジェクトの歴史を通して見ると非常に明白です）。
F＃で最も素晴らしいと思うのは、言語の簡潔さです。 Vimエンジンはロジックの大部分を占めていますが、全体のコードベースの30％しか占めていません。
F＃Visual Studioコンポーネントの単体テストの多くはF＃で記述されています。 VSの外部で実行され、さまざまなVisual Studioビットをモックします。インターフェイスを実装する匿名オブジェクトを作成する機能は、モック作成フレームワーク/ツールの代わりに役立ちます。私はただ書くことができます
let owpe : string list ref = ref []
let vsOutputWindowPane =
{ new IVsOutputWindowPane with
member this.Activate () = err(__LINE__)
member this.Clear () = owpe := []; 0
member this.FlushToTaskList () = VSConstants.S_OK
member this.GetName(pbstrPaneName) = err(__LINE__)
member this.Hide () = err(__LINE__)
member this.OutputString(pszOutputString) = owpe := pszOutputString :: !owpe ; 0
member this.OutputStringThreadSafe(pszOutputString) = owpe := pszOutputString :: !owpe ; 0
member this.OutputTaskItemString(pszOutputString, nPriority, nCategory, pszSubcategory, nBitmap, pszFilename, nLineNum, pszTaskItemText) = err(__LINE__)
member this.OutputTaskItemStringEx(pszOutputString, nPriority, nCategory, pszSubcategory, nBitmap, pszFilename, nLineNum, pszTaskItemText, pszLookupKwd) = err(__LINE__)
member this.SetName(pszPaneName) = err(__LINE__)
}
DoSomethingThatNeedsA(vsOutputWindowPane)
assert( !owpe = expectedOutputStringList )
私の例が必要なときIVsOutputWindowPaneは、最終的にOutputStringおよびClearを呼び出す他のコンポーネントに渡して、string list ref予想される出力が書き込まれたかどうかを確認するためのテスト終了時のオブジェクト。
F＃のLex-Yacc実装を使用してカスタムルールエンジン言語を作成しました
コメント応答を含めるための編集
C＃にはLex/yaccの実装はありませんでした。 （私たちが知っていた限り、F＃1はそうでした）
それは可能でしたが、解析を自分で構築するのは実に苦痛でした。
このトピック は外部ライブラリなど、他のいくつかの提案を示していますが、主任アーキテクトは関数型言語の古い手であるため、F＃を使用する選択は簡単でした。
個人的な経験ではありませんが、DNRのエピソード（ this one だと思います）で、Microsoftの人々にF＃について話を聞くことができます。彼らはFboxを使用して、Xbox Liveスコアリングシステムの大部分を作成しました。システムは数百台のマシンに大規模に拡張され、非常に満足しています。
WebSharper の人々は、Webプログラミング用のF＃を中心とした製品全体を構築しました。これについての記事は次のとおりです。
以下は、F＃とC++/COMを併用する銀行に関するケーススタディです。
http://www.Microsoft.com/casestudies/Case_Study_Detail.aspx?CaseStudyID=4000006794
本番かどうかわかりませんが、「The Path of Go」のAIはF＃で書かれています。
http://research.Microsoft.com/en-us/events/techvista2010/demolist.aspx#ThePathofGo
The Path of Go：Xbox 360向けのMicrosoft Researchゲーム
このデモでは、Microsoft Research Cambridgeで社内で制作されたGoのゲームに基づいたXbox 360ゲームを紹介します。 Goは東アジアで最も有名なボードゲームの1つで、4000年前に中国で生まれました。ゲームの見かけ上の単純さの背後には、非常に複雑なものが隠されています。習得するには数分しかかかりませんが、習得するには一生かかります。チェスのコンピューターは人間のスキルを上回っていますが、Goに競争力のあるAIを実装することは研究課題のままです。このゲームは、Microsoft Research Cambridgeで開発された3つのテクノロジー、つまりGoをプレイできるAI、F＃言語、およびオンラインプレイヤーにマッチするTrueSkill™によって強化されています。 AIはF＃で実装され、Xbox 360の.netコンパクトフレームワークで効率的に実行するという課題に対処します。このゲームは、視覚的に素晴らしい3Dシーンの数々にあなたを導きます。 XNA環境を使用してマネージコードで完全に開発されました。
（他の誰かがすでに「TrueSkill」に言及しています。）