F# ブート キャンプが開催されます

2016年11月19日に、イギリスのケンブリッジより来日した Tomas Petrics さんが参加する F# Boot Camp が開催されます。Tomas さんは、Microsoft Research で Don Syme さん(F#の言語設計者)と一緒にF#の言語設計に携わっており、F# Foundation の設立メンバーでもあり、F#の啓発活動を幅広く実施されいます。プログラミング言語の開発に携わった方のお話を聞ける機会ですので、ご興味のある方は是非、ご参加ください。 そして、前日の11月18日の夜には、F#談話室が開催されます。F#談話室は、無償の勉強会ですが、Tomasさんが参加されます。通訳者はいませんが、下手な英語でもTomasさんとコミュニケーションしてみませんか?

0

実践F# 関数型プログラミング入門の正誤表の補足

技術評論社さんで「実践F# 関数型プログラミング入門」の正誤表がやっと公開されました。正誤表の公開が遅れまして、本当に申し訳ございませんでした。本当なら、9月には公開されないといけなかったのですが、諸般の事情で遅れてしまいました。公開されて正誤表には掲載できなかった箇所がございますので、以下に追加を掲載させていただきます。分量が多いのですが、ご容赦ください。また、諸般の事情から公開が遅れまして、本当に申し訳ございませんでした。 P14 誤 筆者が考える本書の読み方は、1章から読み進めることも、あるいは興味のある章から読んで、必要に応じて他の章を読むというものです。 正 本書の読み方ですが、1章から順に読み進めてもよいし、興味のある章を読みながら、必要に応じて他の章を読むのもよいでしょう。 P17 誤 参照透過性(参照透明性とも呼ばれます) 正 参照透明性(参照透過性とも呼ばれます) P19  1 誤 アルゴリズム実装には関数型プログラミングに影響を受けて 正 アルゴリズムは関数型プログラミングに影響を受けて P20  1.1 誤 プログラムング言語 正 プログラミング言語 P27  図1-4 誤 高級水準言語 正 高級言語 P27  1.4.1 誤 適材適所で言語が存在するのかということです。 正 適材適所で言語が存在するのでしょうか。 P28  1.4.2 誤 「解くべき問題」ということです。 正 「解くべき問題」です。 P28  1.4.2 誤 解き方をモデル化したのがプログラミング言語であるということです。 正 解き方をモデル化したのがプログラミング言語です。 P29  Column 誤 「Abstract Art」 正 「Abstract…

0

F#の書籍がもう少しで完成します

ブログの更新も滞っていました。やっと、何とかプライベートの時間を使って頑張っていた書籍が最終の段階に入りました。 タイトル:実践F# 関数型プログラミング入門出版社:技術評論社 著者:荒井省三、いげ太 ISBN:4774145165 amazonの書籍タイトルは、まだ暫定のままになっています。この書籍は、足掛け2年ほどかかりまして、私にとっても初めての共著となります。章立てですが、全部で12章となっており、次のような構成になっています。 関数型言語の潮流 F#の基本 F#へようこそ 土台を超えて 強い静的型付け 不純の価値は コレクション! コレクション! コレクション! OOP Mix .NET Frameworkのライブラリを使用する モジュールとシグネチャ ワークフローと非同期ワークフロー F#を拡張するライブラリ 本書の執筆に当たっては、多くの方にレビューへ参加していただきました。忌憚のないご意見に、気付かされたり、落ち込んだりもありましたが、やっと何とか最後の仕上げに入りました。ご協力していただいた多くの方に感謝しています。 F#を使っていただく方のお役に立てれば、幸いです。

1

F# のソースコードのライセンスが変更されました

F#コンパイラなどのライセンスがApache 2.0に変更されているのが、アナウンスされました。F# PowerPackで提供されるソースコードに、F#コンパイラやF#インタラクティブも含まれています(Changeset 53135で確認しました)。microsoft.comのダウンロードできる F# CTPは、Microsoft Research Shared Source License Agreement(MSR-SSL)のままで、更新されていないようですから、整理すると以下のようになります。 F# CTPのバイナリはMS-RSのまま(ダウンロードセンター)。 非商用でのソースコード利用や、バイナリ利用はこの限りではありません。 F# PowerPackはApache 2.0ですから、ビルドしたバイナリもApache 2.0に従う。 Visual Studio 2010に含まれるF#は商用ライセンス。 F#開発チームが以前に約束して公約が果たされたと受け止めてべき、できごとだと思います。

1

T6-501多言語パラダイムによる実装手法に関するフォローアップ

TechEdの「T6-501 多言語パラダイムによる実装手法」に関して、フォローアップとしてお話した内容を記載します。説明した内容は、論点が3つあります。 プログラミング言語と計算モデル 複数の言語を組合わせた具体例 分析・設計のおける考慮点(マルチパラダイムを抽出するために) 最初の「プログラミング言語と計算モデル」では、コンピューターで動作させるモデルとしてチューリングマシンやラムダ計算モデル、並列に特化したDAGやCSPなどのモデルが存在しており、近年のプログラミング言語はマルチパラダイム化しているが、中心となる計算モデルというものが間違いなく存在するということです。従って、汎用言語(GPL)が他の計算モデルへ対応するためにマルチパラダイム化したとしても、現時点では最適化などを考えると最適解には決して成り得ないという話をしました。この理由として、複数の言語が活発に使われているし、新しい言語も開発されていることを取り上げました。現実的に複数の言語を組合わせる時の問題点として、「人材が居ない」とか「新しいことを覚えたくない」とかを良く耳にします。ですが、この論点においては生産性などとのトレードオフで判断すべきだという説明をしました。その理由として、不可能ではないけど頑張れば出来るから頑張って1000行のコードを書いたとして、別の言語を使うと500行で済むことが良くあるからという話をしました。これは、別の言語を知っているかどうかであり、異なるパラダイムでは異なる問題解決アプローチがあるからです。だから、様々な言語を知ることは自分にとって有益になります。 次に具体例として、動的言語と関数型言語を取り上げました。動的言語では、オブジェクトの結合度を弱めるためにObjectコンテナーが、スクリプトでオブジェクトを生成する3種類の戦略をお見せしました。これ以外にも、検証ルールや構成パターンなどをデモでお見せしました。これらの理由は、オブジェクト同士の結合度を弱めることで、変更が起きる可能性をスクリプトなどへ隠ぺいすることで、保守容易性や変更容易性を向上することができます。 続いて、非同期パターンを組合わせた場合にプログラムが複雑化していくという説明をしました。この問題を解決するために、F#の非同期ワークフローが有益であり、同時実行などを考えた場合はアクターモデル(メッセージ エージェント)を使うと簡単になるというデモをお見せしました。さらに、デモの中ではWPFで作成したUIへイベントを通知するモデルを用意することで、非同期+リアクティブ プログラミングという組み合わせの重要性を説明しました。.NET Frameworkの非同期処理で、Begin系メソッドで呼ばれるコールバックメソッドは、Beginメソッドを呼び出したスレッドとは異なるスレッドで呼ばれます。このためコールバックメソッド内で、イベントを発生させるとコールバックメソッドが動作しているスレッドになってしまいます。このままだと、UIスレッドとは異なるためWPFではDispactherを使わなければならなくなり、この形式は良くありません。何故なら、イベントの利用者がDispactherを意識する必要があるからです。この問題を解決するには、同期コンテキストを使ってイベントを呼び出し側スレッドに同期させるのが良いリアクティブ プログラミングとなります。 最後に説明した分析・設計における考え方では、以下のような考え方をベースに説明をしました。 メンタルモデル(James.O.Coplien) Domain Driven Design (Erick Evans) DCI(Data Context Interaction) この中でご説明したこととして、現在のOOA&Dではプログラミング言語が持つ制約としてのクラスを抽出することに重きを置いており、ユーザーの目的を支援する本来のオブジェクトになっていないということです。このギャップを埋めるために、Agileの様々な手法が使われています。その例として、XPにおけるユーザーの参加と早期のフィードバックを踏まえた動くソフトウェアを素早くリリースするというプラクティスを取り上げました。この考え方からCoplienのDCIアーキテクチャに繋がっており、彼の考え方によればクラスのしての設計時点の振る舞い(Methodfull Role)と、オブジェクトが動作する場(コンテキスト)において異なる振る舞い(Methodless Role)が出てくるということです。従ってDCIでは、ユーザーのゴールを「ドメインオブジェクトに対する操作」ではなく「目的を達成するためのタスクフロー」に置いています。 一方、DDDの世界においてはEric Evansなどのその後の研究や実践した結果から、書籍としてのDDDに定義されていないことなどを学習していき、DDDを再定義しようとする動きに繋がっています。これらの動きが、DDD eXChange 2010の資料などから読み取ることができます。DDDの再定義から提唱されているのが、以下のような考え方です。 Event Sourcing Process Integration Event Sourcingでは、CQRS(Command Query Responsibility Segregation-コマンドとクエリーの分離)という考え方でオブジェクトの振る舞いを分離していきます(この考え方が、T1-502の萩原さんのセッションでも説明がありました)。また、DDDのビルディングブロックとして、Entities、Value Objects、Services、Domain Events(非同期イベント)、Aggregates、Modulesなどが定義されると再定義しています。これは、EvansなどのDDDの考え方をクラウドを含めたシステムに対応できるように考え方を洗練させていったことにより出てきたものと考えられます。このビルディングブロックやCQRSを組み合わせると、ドメインモデルにはコマンド系のメソッドしか残らなくなります。こうなると、今までのドメインモデルとは異なったものに変化していきます。EvansのDDDの世界で重要なポイントと私が考えているのが、Bound ContextとContext Mapになります。モデル(オブジェクトと言い換えても良い)が意味を成す領域がBound Conetxtであり、これに関連するContextとの対応関係がContext Mapとなります。よって、このことはContextによってモデルの振る舞いが決定されることを意味します。このようなEvansなどの考えに気が付いた時に私が思い出したのが、Martin Fowlerの「Development of Further Patterns of Enterprise Application Architechure」になります。つまり何が言いたいかといえば、ドメインモデルを現在のシステム形態(Key-Valluesストレージなどのクラウド技術を含んだもの)へ対応させるにはどうしたら良いかという動きが、今まさに始まっているということです。 Evansのこのような考え方は実装により近いのではないかということを私は考えており、Coplienはもっと上流(別の言い方ではユーザーより)から考えているように私は感じています。これはどのような視点でシステムを見ているかによるものです。そして、もっと重要だと私が考えるのは、システムにおける共通性と可変性を識別し(ドメイン工学のFODAなど)、可変性をどのように実現していくかということです。それが、DCIアーキテクチャや再定義されつつあるDDDの前提になっていると私には思えます。 分析・設計論として、簡単な結論があるわけではありません。考えるべき事柄が多岐に渡っており、それらの要素に気が付くというのが本セッションの大きなテーマでもありました。このような雰囲気が参加者に伝えようと意図したのが、今回の私の発表になります。 PS.これらの考え方は、今回のセッション資料を作成するに当たって萩原さんと何度もディスカッションをして得られた気づきによるものです。これらのディスカッションは、TechEdの期間中も何度も行っており、その中でお話する内容が決まっていきました。これらの理由から、公開している資料には本エントリーで記載さしたようなキーワードが含まれいないのです。

0

プログラミング F# が発売されました

先週でTechEdが終了しました。私が話した内容のまとめも、次回位に投稿したいと考えています。今回は、新しく発売された書籍をご紹介したいと思います。 タイトル:プログラミングF# ISBN:978-4873114668 出版社:オライリージャパン オライリー様のご厚意から本書を私は頂きましたが、本書の原書(2009/10)を読んだことがあります。まだ、詳細には読めていませんが、翻訳をされた鈴木さんの気遣いが良く表れていると感心しています。というのは、本書の中にある画面イメージやサンプルコードを動かしている所などが、Visual Studio 2010製品版に差し替わっているからです。原書は、ベータ2というタイミングで書かれたものであり、翻訳段階で製品版と齟齬がでないように気遣っているのが、ざっと眺めただけでも私は感じることができました。これから熟読させて、いただく予定でいます。内容的には、関数型言語の考え方や.NET Frameworkとの関係を含めて多岐に渡っていますので、読み応えがあると私は感じています。 この書籍の発売を記念して、著者であるChris Smith氏のトークイベントが行われます。先着20名限定でサインをしていただけるそうです。もし、行かれる場合は予約をされることをお勧めします。 PS.私がF#で愛読しているのは「Expert F# 2.0」になります。この書籍は、今年の6月に発売されたもので、前作をVisual Studio 2010対応へ更新したものになります。これらを愛読している理由も含めてですが、まだ書籍タイトルが決まっていませんがF#に関する書籍を執筆すべき奮闘しているのと、関数型言語の特徴を理解しようと頑張っているからです。

3

TechEdの準備に追われています

いよいよ来週は、TechEd Japan 2010の開催です。私が担当するのは「T6-501 多言語パラダイムによる実装手法-動的言語、関数型言語を含めたプログラミング言語の有効活用へ-」というセッションになります。参加者向けにPPTが公開されていますので、おおまかなアウトラインを確認することができると思います。実は、まだ設計論に関しては色々と検討をしている最中です。この資料の作成に関しては、何度も萩原さんとディスカッションしたり、色々な資料(論文や書籍だったり)を読み漁ったりしています。中でも参考にしているのは、以下の3つになります。 Domain Driven Design : Eick Evans Lean Software Archtechture:James.O.Copplien 萩原さんの過去の講演資料(クラスにまたがる散乱ともつれ合い) 複数のプログラミング パラダイムを組合わせる上で重要だと考えるのは、如何以下に設計上でパラダイムを発見するかということです。この目的のために大切なことが、ドメイン、ユースケース(振る舞い)、コンテキストではないかというのが私の考えです。実世界のオブジェクトの振る舞いは、コンテキスト(その時の目標と言い換えても良いです)に左右されると考えているからです。この当たりの考え方は、当たり前と云えば当たり前なんですが、どうも実現が難しいように感じています。これを実現する1つの手法が、Agile Dvelopmentの本質だとも考えています。 話は変わって、TechEdでは「BOF-06 Let’s Dynamic」というBOFがありまして、イスラエル在住のMVPであるShay Friedmanが参加してくれます。彼は、IronRuby Unleashedという書籍の著者でもあります。IronRuby関係で知り合って、今回のBOFへの参加に当たって彼と何度も連絡を取り合っています。TechEdに参加される方で、Rubyにご興味のある方は是非ともご参加ください。 それから、F# 2.0 CTPですが2010 Augustが公開されました。このビルドには、以下の内容が含まれていました。 .NET Framework 2.0対応のバイナリ ソースコード .NET Framework 4対応のバイナリ Windows Phone 7向けのバイナリ 中でも.NET Framework 4向けのF#対話型シェル(fsi.exe)は、日本語の入力もできるようになっています。多分、対話型シェルの標準入力用のパーサーがユニコード対応になったと思います。これでVisual Studio 2010 Professional以上を持っていなくても日本語を使ってF#を試せるようになります。 追記:書き忘れましたが、TechEdのセッションの難易度は高く設定させていただいています。このため、オブジェクト指向分析&設計はもちろんのこと、デザインパターン、アジャイル開発などの知識は必須となります。用語を知っているという前提となりますので、ご容赦ください。 追記:F# 2.0 CTPの.NET Framework 4向けの対話型シェルですが完全な日本語入力に対応しているというものではなく、ユニコード対応のお蔭で日本語の入力もできるという程度のものです(いげ太さんのご指摘により、追記しました)。

2

[TechDays 2010] Visual Studio 2010 でプチパラダイムシフトへ

TechDays 2010 では、「CM-204 Visual Stduio 2010 でプチ・パラダイムシフトせよ!」というBOFがありました。このBOFを担当していた小島さんと原さんに本番の15分前にお願いして、参加させていただきました。小島さんの言われるパラダイムシフトを借りて、私なりに自分の考えをまとめたいと思います。 最初に手続型のパラダイムは、以下のように表現することができます。 手続型でプログラミングする時は、頭の中が手続(手順)で一杯になっています。これが、現在の主流であるオブジェクト指向では、以下のようになります。 頭の中はオブジェクトで占められて、少しだけ手続のことが残っています。オブジェクトの占める割合で、オブジェクト脳の完成度が決まるといわれるのかな?ここで、パラダイム論でオブジェクト指向を説明するとすれば、オブジェクト+手続という組み合わせた考え方ということになります。なぜなら、オブジェクト指向で実現するオブジェクトには、メソッドやプロパティがあります。メソッドなどの実装は、手続で行いますので手続を忘れたわけじゃないのです。 ここで唐突ですが、チューリングマシンを思い出してください。別の言葉でいえば、ノイマン型コンピュータです。これらの動作原理を単純に説明すれば、以下のようなものになります。 プログラムカウンタを使って命令を読み込む。 命令をデコードして実行。 プログラムカウンタをカウントして、1へ戻る。 単純化していますが、ノイマン型コンピュータは手続きを使ってプログラムを実行していることが理解できると思います。次にジョン・バッカスという人の話をします。ジョン・バッカスは著名な数学者であり論理学者で、FORTRANを設計した人物です。これ以外にもBNF記法などを考案した人です(BNFは、標準規格など様々なところで使われています)。彼は、その功績によりチューリング賞を受賞します。この受賞講演で「Can Programming be Liberated from the von Neumann Style?”(プログラミングはフォン・ノイマン的スタイルから解放されるか?)」という内容を話しています。内容はともかく、この講演がきっかけで様々な関数型プログラミングの研究が行われていったのです。つまり、ノイマン型プログラムではないというのが、関数型言語の源流だったと考えることもできます。 話を元に戻すとノイマン型コンピュータである限り、手続型から逃れることはできないということを私は言いたかっただけです。CPUがムーアの法則に従って高速化やメニーコア化したとしても、CPU自体がノイマン型ですから実行は手続に則って行われているということです。よって、処理速度の速いプログラムになるような最適化は、手続に従って行われていくということです。逆に非ノイマン型コンピュータは、一般的に使われているのかという疑問が出ると思います。もちろん存在はしますが、一般的になっていないということができると思います。ここで最近、話題に聞く関数型言語はどうなんでしょうか。HaskellやErlangなどの話題を良く聞くと思います。BOFの中で小島さんは、Haskellを使って、ソートなどのアルゴリズムを実装するプログラムを見せてくれました。Haskellと同等なプログラムをC#で記述した場合も見せてくれました。この時のプログラムの脳内模型がどのようになっているかと言えば、以下のようなものになります。 言い方が良いかどうか私にはわかりませんが、良く「本物のプログラマは関数型言語を使う」というような話を耳にします。手続型言語を使うよりも短く、簡潔に記述できるのが関数型言語だという話です。この手のプログラムを読むと、関数型パラダイムが理解できない自分には、なかなかプログラムの意図を理解できなかったりしますが…関数型プログラムの特徴は色々とありますが、代表的なものを以下に列挙します。 宣言型である。 ラムダ式を記述する。 不変(Immutable)。 パターンマッチ 遅延評価がある。 副作用がない。 小島さんが説明してくれたHaskellの例では、式(厳密にはラムダ式)を宣言していくだけプログラムが記述されるため、宣言した順序が実行される順序ではないということです。つまり.NETのLINQのように遅延実行が行われるということです。こうなると、ソースコードを読むときに遅延実行を考慮しなければ、実行順序がわからなくなるということです。このような言語に取り組むには、パラダイムシフト(考え方を変える)が必要になるのではないうかということです。 関数型言語を考えた時に、「副作用が無い」という特徴から並列実行に適しているのではないかと良く考えられています。このことを私は、「その通り」と考えていまして、宣言した関数が参照透過性(同じ引数を与えれば、同じ値が返るという性質)を持つのであれば、参照透過性を持つ単位で並列実行するタスクとして切り出すことが可能だと考えています。このことにプラスアルファで、「不変」という特徴を組み合わせると、共有メモリのロックの問題が解消されると考えています。これらの事から私が説明したいのは、参照透過性などを意識せずに獲得しやすい言語を使うことで並列化を考えやすくなるのではないかということです(並列化を意識した言語として、GoogleさんからGo言語が発表されています。このような新しい並列対応の言語が作成されることもあるでしょう)。また私は例としてお話させていただいたのが、JavaScriptは関数型言語だという話です。もっとも関数型としてよりも手続型としてJavaScriptを使われている方のほうが多いですが… 今度はオブジェクトというものを考えてみたいと思います。一般的にオブジェクトは、その状態をカプセル化して、振る舞いをメソッドなどで公開します。このオブジェクトを複数のタスクが同時にアクセスすることは易しいでしょうか。同期化プリミティブなどを使ってスレッドセーフティにしなければ、並列操作することは難しいと言えるでしょう。極論すれば、並列操作とオブジェクトは相性が悪いということができます。 次に関数型言語はオブジェクトも使用できますので、どうなるかと言えば、標準が不変なオブジェクトになります。どういうことかと言えば、オブジェクトの状態をインスタンスを作成してからは変更することができなくなります(厳密には、プロパティに対する代入ができないということです)。F#で.NETのオブジェクトを使用する場合に、この問題が発生します。このためF#では、.NETのオブジェクトを束縛する場合に書き換え可能(Mutable)と宣言して、この制約を回避します(この性質から非純粋関数型言語と呼ばれます)。では純粋関数型言語(不変しか取り扱えない)であるHaskellなどでは、どうしたら良いでしょうか。この時に行う方法が、関数が新しい状態を持ったオブジェクトを生成して値として返すという方法になります。このように言語が変われば、考え方を変えるとことで同じようなことを実現できるようになります。これには、パラダイムを変える必要があります。このようにBOFで説明して、参加者の方からメモリが大量に必要になりガベージコレクタが活躍しますよねという質問がありました。答えは「その通り」ということなのですが、JavaにしろCLRにしろGCを備えた実行環境が現実的に使用できているのが現在のコンピュータですよね。さらにメニーコア化し、ギガ単位のメモリを搭載している現在のPCでは、関数型言語も実用域に入っていると考えても良いのではないでしょうか。逆説的に大量のCPUコアやメモリリソースを使い切って高速化するというパラダイムがあっても良いように思います。 このBOFで簡単なF#のサンプルを私がお見せしました。このサンプルは、並列タスクの例として用意したものです。並列化したF#のクラスとC#のクラスで、F#が130行前後でC#の166行前後となっており、実現したいことに適したパラダイムを使うことでプログラム自体が簡潔になりますという話をさせていただきました(自分のセッションでは、時間が足りなくなってお見せできなかったデモなんですが)。 全ての場面で関数型プログラミングを使用する必要はなく、適材適所で言語を使い分けることで少ないコードで目的を達成できる可能性を持たせるために、Visual Stduio 2010 に関数型言語である Visual F#が入ったと考えることができるのではないでしょうか。もちろん関数型言語としてF#を使って、WindowsアプリやASP.NET Webアプリ、或いはSilverlightアプリまで作成していらっしゃる強者もいらっしゃいます。私自身は、そこまでの関数型脳になっていないので、並列化や大量の集合を扱った計算を行う場面で F# を使用するだけです。このためには、自分の関数脳をもっと鍛える必要があるのは言うまでもありません。 皆さんも、今迄と違うパラダイムを使ってみませんか。 PS.脳内モデルは、BOFで説明された小島さんに引用を快く承諾していただいて感謝しています。おもしろいモデルだと私は思っています。関数型パラダイムですが、GoogleさんのMap Reduceフレームワークが関数型のMap関数とReduce関数をC++で実装したというのは有名な話ですよね。Map Reduceフレームワークから私が学んだのは、関数型パラダイムから他の言語へ応用できる考え方が沢山あるということです。

5

[TechDays 2010]並列タスクのデモについて

今回は時間が足りなくなってお見せできなかった、並列タスクに関して記述します。最初にウォームアップということでConcurrent(同時実行)に関して説明します。 最初にご説明したのは、インフラストラクチャという観点でした。 OS 1)32ビットカーネルであれば、スレッド単位でスケジュールされていること。 2)64ビットカーネル(Win7以降)はユーザーモードスケジューラ(UMS)によって、スレッドの中にあるユーザー空間とカーネル空間を別個に管理することでコンテキストスイッチの切り替えが少なくなるようにスケジュールします。この機能によってスケジューラの速度を向上させています。 CLR 1)CLR 2.0までは、スレッドプールはグローバルキューのみでスレッドを管理していること。 2)CLR 4では、スレッドプールはグローバルキューとローカルワークスティーリングキューで構成されていて、動作しているスレッドが存在する場合にローカルワークスティーリングキューにタスクがキューイングされます。スレッドが空いた場合に、ローカルワークスティーリングキューから取り出して実行する仕組みになっています。この時のキューからの取り出し方が、CPUのL0キャッシュを考慮した取り出し方になっているためプロファイリングなどで調べると木目細かくスケジュールされていることがわかります。さらに補足すれば、実行されるスレッドは64ビットカーネルではUMSでスケジューリングされますのでOSのスケジューラとの相乗効果が得られます。 次に.NET Framework 4で強化されたものとしてライブラリがあります。強化された主なものとしては、以下のものがあります。 並列LINQ(System.Linq) 同期プリミティブやキャンセルの仕組み(System.Threading) 並列タスク(System.Threading.Tasks) ロックフリーコレクション(System.Collections.Concurrent) 並列リンク(PLINQ)に関しては、前回にデモの内容を補足しました。処理の並列化を考える上で重要になるのがアルゴリズムになります。アルゴリズムを大別すると、一般的に以下のようになります。 データ並列(PLINQなど) タスク並列(前回の解説では、ForAllを使った並列実行など) ここでデモとしてお見せしようと考えていたのが、タスク並列だったのです。が、時間の関係でお見せできなかったのです。用意していたデモは、以下のようなものになります。   このプログラム(PhotoViwer.exe)は、Windows AzureのBlobストレージサービスからデータを取得して表示するという動作を行います。内部的には、AzureImageDownloaderクラスを使ってテンポラリーにイメージファイルを生成し、ビューワーがFileSystemWatcher で監視して表示するようになっています。このようなプログラムを用意した理由は、一般的に並列化する場所は処理速度に大きな差のある個所を選択することで全体のスループットを向上しやすいからです。このプログラムには、以下のような機能を用意してあります。 同期:一般的なプログラミングモデルです。 非同期:CLRの非同期パターン(Begin/End)。 タスク:並列タスクを利用したパターンです。 エージェント:メッセージエージェントを利用したパターンです。 エージェント+アルファ:メッセージエージェントと並列タスクを利用したパターンです。 同期方式で行う方法は、多くの方が予測がつくことでしょう。問題は非同期パターンにあるのですが、何を問題にしているかといえばCloudBlobクラスの非同期ダウンロードとFileStreamクラスの非同期I/Oを組み合わせていることです。複数の非同期I/Oを組み合わせると、面倒な作業が多くなるという点に気付かれた方が多いことでしょう。このためにC#では、以下のようなコードを利用して非同期パターンを実現しています。 DownloadState state = new DownloadState()        { CurrentImage = 0, Blobs = this.container.ListBlobs().ToArray(), Container = this.container, Folder = this.Folder }; state.Iterate(); このコードは、非同期操作をラップするためにDownloadStateクラスを用意していることを示しています。そしてIterateメソッドによって、Blobリストを使って非同期操作(CloudBlobとFileStream)を行っています。 次にタスクを処理しているコードを以下に示します。 Action action…

0

[TechDays].NET Framework 4 時代の言語を担当します

Tech・Days 2010では、「.NET Framework 4時代の言語」というセッションを担当します。概要にも記載していますが、扱うテーマは以下の3つになります。 Dynamic (動的) Declarative (宣言型) Concurrent (同時実行) 最初のテーマであるDynamicについては、DLRが提供されることで何ができるかというのがメインテーマになります。ここでお見せする予定のデモとしては、C#<->IronPython、C#<->IronRubyなどの静的言語と動的言語間の相互利用になります。両方を組み合わせることで、どういうことが実現できるかについて説明ができればと考えています。 2番目のテーマとしては、宣言型プログラミングの定義に従って XAML と Visual F#を取り上げます。XAMLについては、.NET Framework 4で提供される System.Xamlを説明する予定です。 F#は、関数型言語としての基本的な部分をご説明することを考えています。 3番目のテーマに関しては、これが一番難しいと感じています。Concurrentという単語を「同時実行」と訳していますが、「並行」と訳す場合もあります。Parallelという単語では、並列と訳するわけです。一般的に並列プログラミングと呼んでも、並行プログラミングと呼ばれることは少ないわけです。並列か並行かというのは、言葉の定義が大切なのですが、並列プログラミングに関するトピックはMSDN ライブラリの中では、Advanced Topicになっているため、一般の人には理解しにくいのではないかと考えています。従って、どのように説明するかという点に関しては、未だに検討しています。 すべてのテーマに関して考えていますのは、 今迄がどうだったのか .NET Framework 4 でどうなるのか ということです。たとえば、Dynamicですが今迄は提供されていませんでしが、これからは提供されるわけです。そうすると、モックオブジェクトと本番オブジェクトを入れ替える場合に「Dynamic」を使うことで依存性を気にしないで入れ替えることが可能になります。もちろんプログラミング的には、インターフェース継承などを使って入れ替える方が、記述ミスの少ないプログラムを記述できますし、実行速度も速くなります。ですが、オブジェクトのインスタンスを作成するFactoryクラスなどを用意する必要があるわけです。これをDynamicにすることで、FactoryクラスがDynamicオブジェクトを返すことで、どのようなオブジェクトでも扱えるようになるわけです。もちろん、知らないメンバーを呼び出すことはコストがかかりますので、呼び出すメンバーの名前に関しては知っている必要がありますが、インターフェースを使うことなく実行時に解決できるのが、DLRのメリットになります。また、2度目以降の呼出しは、サイトバインダーによってキャッシュされていますから、速度の向上も望めるわけです。Dynamicを使用しなかった場合との違いは、「コンパイル時にメンバーを解決するか」「実行時に文字列でメンバーを解決するか」ということです。 この速度面の課題を許容するのなら、オブジェクトを作成するコンテナとしてDLRを活用する価値があるのではないかと、私は考えています。スクリプト系の言語が、色々なところで使われている状況を考えると、使っても問題ないと考えることができます。もちろん、絶対的に速度を重視する場合では、目的を達成するために別の手段をつかうべきだと思います。 PS.考えることが多くて、資料を読み込むのも大変な状況にいます。

0