Catharsisようこそ。睡眠不足なプログラマのチラ裏です。この広告は、90日以上更新していないブログに表示しています。ありがとうございました。FSharp」というタイトルで発表させていただいたのですが、時間配分がうまくいかずにスライドの最後まで紹介することができませんでした。申し訳ありません(はずかしい)。」とお約束をしていたので、こちらにまとめます。使用したスライドをそのまま公開することも考えましたが、それだと内容が伝わりにくくてあまり価値がなさそうかなと思ったのと、変な誤解をされる恐れもあると考えたので、発表時に話した内容に簡単な補足を加えたり、ときにはざっくり省いたりしたかたちでこちらにまとめることにしました。時間オーバーしただけあってだいぶ長いです(ポエム)。セッションを聞いていただいたかたは、続きのみどうぞ@mayukiさんが作ってくれた画像。別に殺伐とはしていなかったはず。言語遍歴としてはVB(レガシー的なのも含む)、C#、Java、あとはDelphiあたり。その他いろいろさわってますが、よく知られている(一般的な)オブジェクト指向言語をつかって仕事をしていることが多かったです。関数型言語関連の研究をしていたとか、数学が得意だとかでもなく一般の人。C#の会社に所属していながら、F#の話をする。インストールしてくれています。今後使ってくれる)かどうかはわかりませんが。こちらのツイートをみたとき、まゆきさんツンデレだなあと思いました。Games)のF#実装。XML、SXML、FSB(独自形式)の3種類の外部DSLを備えていることです。NuGetである程度DLされているんだけど、使ってみたという話を一度も聞いたことないですね。・UniFSharpUnityエディタ上からMSBuildを実行してF#をビルドするやつ。ScriptをインスペクターにD&Dできたりします。あと、無駄にUnityちゃんがしゃべります。サポートされるようになる日は、まずこなさそうですね。F#に対して「無関心」だった人に関心をもってもらいたい。F#に対してもともと「関心」があった人をより協力者に近づけたい。流行らせたい?単純に良いと思うものは広めたいし。語り合える仲間が増えるのはうれしいよね!というのは当然として、ユーザーが少ないことは問題でしかないと考えるからですね。実際ユーザが少なくてイイことなどまるでないので。開発者が少ないということは、ライブラリやフレームワークの選択肢の幅も狭くなります。書籍も出版されにくいし、Web上でも情報が少なく何かトラブルがあったときに困る可能性があります。んなもんで、ビジネスにも適用されにくくなります。Language)的なアプローチを使った言語設計で研究することが決定したのが2002年らしいので、F#1.0に至るまで約3年かかったということになるのかな。ためのジェネリック機構を作った人。Provider(型プロバイダー)などの新しい(面白い)試みがある。Pattern,(アクティブパターン)なんてのもある。簡単に言うとユーザ指定形式のパターンマッチ。最新版のF#4.0は、3.0からの大きな機能拡張はなくて割と地味な印象がある。細かなバグの修正だったり手触り感の向上があって普通に便利になりました。Studioでインストールされなくなりましたが。他には、毛色が違うけどリアクティブプログラミングもパラダイムのひとつと言って差支えないかな。F#は関数プログラミングに主軸を置いたマルチパラダイム言語です。実用レベルで使用できる関数プログラミングのパラダイムをサポートしている唯一の言語。それ以上でもそれ以下でもないです。C#(VB)はオブジェクト指向プログラミングを主体としたマルチパラダイム言語。いっても、C#(VB)のそれは関数プログラミングを支援している関数型プログラミング言語に比べて、ごくごく限られていて。C#(VB)でできるプログラミングのパラダイムの1つに関数プログラミングを加えるは、ちょっと違うかなと(個人的に)は思うところです。LINQ使用時のラムダ式の利用など関数プログラミングのエッセンスが効果的にとりいれていて、それはオブジェクト指向プログラミングとも非常になじんでいます。Monoがあることによって、いろんなところで動くよ他には、GPUとかブラウザ上とか。さまざまな環境で動くF#さんFsharpbindingプロジェクトってのがあってですね・・・いろんなエディタいろんな環境でつかえるよ。Studio(現時点ではおそらく最強)。拡張機能の充実ぶりがすばらしいので。#いい世の中になりましたC#で作られたライブラリも利用可能、とは言ったものの、F#から使いやすいC#ライブラリとして設計されていないと、だいぶツライ感は否めないですけど。Toolsの機能をいくつか紹介しました。フォルダをきって、階層構造をつくれるようになるのはふつうにうれしい。サンスクリット語でして、日本語(仏教用語)だと般若です。関数型言語っぽさに比例しているかなあと、個人的には考えます。最近のプログラミング言語は、マルチパラダイム化(というか、関数プログラミングの一部の要素が取り入れられる)が進んでいてその境界が割と曖昧になってきている。言語(コンパイラ)や開発環境でどの程度支援されているか(推奨されているか)どうかで、関数型言語と呼んで差支えがないかどうか判断をする感じかなあ。オブジェクト指向プログラミング言語は、オブジェクト指向プログラミングがなんたるかを教えてくれない。かなりのぶぶんで言語そのものから関数プログラミングのスタイルを学ぶことができる。ある面では学習コストは高いけど、そういった面で考えると、頭の中がまっさらならむしろ学習コスト低いのかななんて。理解するのに時間がかかるような難しい理論や概念ももちろんありますが、大部分が誤解かと思います。関数型言語を使って関数プログラミングを学ぶ、その入り口自体には難しい要素はほとんどなく、シンプルかつ堅牢なルールが重んじられる(ことが多い)ので複雑性が少なくなって、むしろ簡単とさえ感じる部分もあるくらいです。少なくとも、可変な値に翻弄される複雑性を減らすことができるので、書きたいプログラムそのものに集中できる時間が増える。いうことは実際に利用してみると実感できるはずです。言語によっては大きくシンタックスが異なる場合があるので、ある程度の抵抗感が生まれてしまうのは事実(しょーがない)。F#も「見た目がきもくて無理」なんて言われることもある。好んで使っているひとは「美しい」って言う人多いのに。(いい意味で)いろいろとゆるいので。みゅーたぶるな値も使い放題だし、手続き的だったりオブジェクト指向なスタイルを残しつつ、少しずつ関数プログラミングのスタイルを取り入れていくことが無理なくできるのではないかな。いう素敵サイトの記事から引用したものですfsharpforfunandprofit.com重要なところも割とさっくりと大胆に省略されていたりしますが、まあイサギヨサがある。コードを見たことがない人も多いのでは?ということで入れました。やるつもりでいたんですが、ここにかなりの時間を費やしてしまったので時間切れになってしまった。リストは、順序が指定されていて変更不可の一連の同じ型の要素を表します。リストを定義するには、セミコロンで要素を区切って角かっこで囲む感じ。単一要素とリストの結合はコロン2つで。リスト同士の結合は@で。キーワードを使用しません。常に関数内の最後の式が返される。最初こそ少しとっつきにくいかもしれないが、シンプルなルールなのですぐに慣れることができるだろうし、実際明確でわかりやすい。Listモジュールに定義されているので、よしなに使う。List.filterはLINQでいうところのWhereのこと。1から100までのリストについて、正方形の面積を求めてその和をだす(なんのために)関数に適用される引数を明確にするためには括弧を用います。この例に関していうと、括弧を書かないとコンパイルが通らないので。正確には前方パイプライン演算子F#ではコードを書きやすく、また見通し良くするためのパイプライン演算子が標準で提供されている。すると楽しい気分を演出するかもしれないし、しないかもしれない完全に一致(ではない)が、似ている。F#ではループの代わりとして利用できる高階関数が数多く提供されている。ループしようと思ったら再帰関数書かなきゃだめなの!?みたいな変な誤解は持たないでほしい。ループ用の構文を必要としない場面が多いということはわかってもらえるはず。LINQの場合は当然、あらかじめ定義されている拡張メソッドなりがある場合のみにメソッドチェーンとして処理を手続き的に書き下すことができる。それに対してパイプライン演算子によるチェーンでは、型さえ合えば自由に関数をチェーンできる。後ろになんでも繋げられることをメリットととらえるか、はたまたデメリットととらえるか。これは、開発のスタイルや重視するプログラミングパラダイムによって意見が変わってくるところだろうと思う。おいては、パイプライン演算子によって後続の処理を好きなだけ連ねることができるのはメリットでしかない。3年前のツイートだったわたしはこれでF#覚えました。これは別に冗談で言っているのではなく結構本気で。(|>)パイプライン演算子という中置演算子を用いることで、関数と引数の順序を逆にすることができる。これによって、関数適用の流れを手続き型的に書き下すことができるので、処理の流れがわかりやすくなります。F#ではこの「パイプライン演算子を使う」ことが基本でありながら、同時に最上級のプラクティスであると言っても過言ではなく。これを好んでよく使うことはおのずとF#の上達に繋がります。複数の値を組みにするやつ。雑に言うと、フィールド名を持たない無名クラスのようなものSystem.Tuple.Create<,>とか書かなくてよいし、Item1,Item2...と付き合わなくてもよいという話。タプル扱いやすく改善されないかなぁと思っているはず。