関数型まつり 1st DAY

関数型プログラミング言語に関する技術カンファレンス『関数型まつり』を聴講してきました。
プログラミング言語 Scala をあつかった『Scalaまつり』から発展した技術カンファレンスだそうですが、 F#, SML, Haskell などさまざまな関数型プログラミング言語のお話を聞くことができました。

会場は中央線 中野駅近くの中野セントラルパーク。1階と2階には飲食店が入居したオフィスビルにある綺麗な会議施設でした。

朝の新幹線は空いているだろうと自由席にしたところ高崎まで立つことになってしまいました。けれども開場時間の30分ほど前に会場に到着できたので、建物の目の前の公園でのんびり時間を過ごして差し引きゼロになりました。
型システムを知りたい人のための型検査器作成入門 by 遠藤侑介 さん
ちょっと変なプログラム "放射線耐性Quine" のデモが始まりました。ちょっと変ではありません。とっても、とっても変態です。褒めてます。 😅 #fp_matsuri_a
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025
『型システム入門』は購入して積んだままなので手を挙げられませんでした。最後まで読んだ人の手を挙げる質問があるのなら、最初だけは手を挙げたのに。とっても場所をとる書籍なので、どこかに埋もれたりはしません。 😅 #fp_matsuri_a
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025
「抽象構文木(AST)は聞いたことがある人も多いと思いますが…」 そういう(変態的な)聴講者が対象の発表なんですね。😅 #fp_matsuri_a
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025
"TypeScript"の再帰関数定義。相互再帰定義記述の後に呼び出すと予想通りにオーバーフローが発生する。しかし相互再帰関数定義の合間で呼び出すと型チェックはパスして実行時エラーになる。型チェックから見ると不自然ですが、移植性を優先したんでしょうね、と言う遠藤さんの解説。 #fp_matsuri_a
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025
TypeScriptで記述した型検査器はエラーを検出できるのだけれども/だから、プログラミング言語としてのTypeScriptは、たとえば「文字列と整数の加算」を認めているため、型検査器を実行できると言うマニアックな質問と回答。 #fp_matsuri_a
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025
Rust世界の二つのモナド──Rust でも do 式をしてプログラムを直感的に記述する件について by konn さん
午後のセッションは 「Rust 世界の二つのモナド」を聴講。お腹がいっぱいで眠たい時間帯ですが頑張っていきましょう! #fp_matsuri_a
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025
『プログラミングとはEDSL(埋込ドメイン特化言語)を作ることである!』という、パンケーキを作るために鉄板から作り始めるような変態的なセッションを聴講します! 😅 #fp_matsuri_a
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025
「見通しが良い」はプログラミングにとって大事! 😆 #fp_matsuri
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025
「それはモナドの合図!」 このセッションが終わったら、なにか購入せずにはいられない、契約せずにはいられない、キャッチーな合言葉です。 😅 #fp_matsuri_a
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025
糖衣構文を戻すことを "脱糖" や "desugar" と呼ぶのですね。知らなかった。というか、プログラミングの実務ではあまり使う場面がない??? #fp_matsuri_a
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025
産業機械をElixirで制御する by 菊池 豊 さん
「産業機械をElixirで制御する」
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025
高知工科大学 菊池 豊 先生 #fp_matsuri_b
「PLCは高価である」 たしかにそうですね。計算速度とか記憶容量ではなく、暑くても、寒くても、振動しても、埃っぽい環境でも壊れない機械ですからね… 😅 #fp_matsuri_b
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025
スキー場の湧水をつかった省電力発電は有望そうですね。人工降雪機のために大きな水源と湧水池をつくっているため、スキーシーズン以外の有効活用として面白いかもしれません。 #fp_matsuri_b
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025
Excelで関数型プログラミング by はけた さん
「Excelで関数型プログラミング」
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025
気のせいでしょうか? パンケーキを作るために、鉄板から作り始める話に対して、本セッションはパンケーキをお好み焼き粉で作る話みたい… 😅 #fp_matsuri_c
Excelで純粋関数型プログラミング。とても面白い発表でした。実践するつもりはありませんが… 😅 #fp_matsuri_c
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025
XSLTで作るBrainfuck処理系 ― XSLTは関数型言語たり得るか? by MakKi さん
「XSLTで作るBrainfuck処理系」
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025
このセッションは古古米で美味しいスシ飯を作ってみようと言う話でしょうか? ちょっとトゲのある例えかな… 😅 #fp_matsuri_c
みんな「私プログラミング言語」を作るのが好きですね。でも、こんなカンファレンスに参加すると参加者が次々に感染して新たなプログラミング言語をつくることになるのでしょうね。(褒めています😅) #fp_matsuri_c
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025
What I have learned from 15 years of functional programming by Scott Wlaschin さん
イミュータブルとパイプラインの関係がとてもわかりやすい説明でした。まさに目から鱗です。 #fp_matsuri
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025
ループを回して結果を導くやりかたをパイプラインに置き換えた例が腑に落ちました。いままで何となくサンプルコードをコピペして、こんなものだとコーディングしていましたが、こういう背景、目的があるのですね。 #fp_matsuri
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025
ループを回して結果を導くやりかたをパイプラインに置き換えた例が腑に落ちました。いままで何となくサンプルコードをコピペして、こんなものだとコーディングしていましたが、こういう背景、目的があるのですね。 #fp_matsuri
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025
"I" が並んだ文字列(原始的なローマ数字) を"V" や "X" に置き換えていくアルゴリズム、パイプラインの使い方としては、たしかに関数型プログラミングの有用性を示す例としてバッチリですね。 #fp_matsuri
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025
"継承" は使わずに "パイプライン" で一方向に流す。 #fp_matsuri
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025
関数型における『型』が "集合" である。という説明が、ここで回収されるのか。巧みな説明。 #fp_matsuri
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025
コンストラクタで1回検証されて、イミュータブルであるから、あとから書き換えられることはない。 #fp_matsuri
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025
Swiftにおける Optional型 が、こんなところから影響を受けていたんですね。一生懸命、非Optional型にしようとしていましたが、必ずしもそれが正解というわけではなかったのですね。😥 #fp_matsuri
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025
検証というのは演算結果の最後の出口で行うものだと思っていましたが、最初のコンストラクタで実行するんですね。目から鱗。 #fp_matsuri
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025
パイプラインを使うと、コンストラクタの後ろにコンストラクタがいて、さらにその後ろにコンストラクタがいるから、つぎつぎに検証が実行されることになるのでしょうが… 😅 #fp_matsuri
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025
「鉄道指向プログラミング」 さっそく明日から使ってみよう! 言ってみたいだけの人です。 😅 #fp_matsuri
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025
非決定的(Non-deterministic) コードは書くな! #fp_matsuri
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025
入力から出力が一意に決まる(決定される)関数を書きましょう! #fp_matsuri
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025
"Pure core" というのは、そういう意味だったのですね。 決定的関数がビジネスロジックとしてアーキテクチャの中心に位置する。 #fp_matsuri
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025
『レゴ (LEGO)』 の例えが何度も出てきますね。レゴと鉄道はエンジニアの必須教養かな? 😅 #fp_matsuri
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025
『レゴ (LEGO)』 の例えが何度も出てきますね。レゴと鉄道はエンジニアの必須教養かな? 😅 #fp_matsuri
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025
「コアコードに I/O は存在しない。」これはユニットテストを簡潔に実現するためには必須のルールですね。 #fp_matsuri
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025
Scott Wlaschin さんの招待講演で説明のあった "Railway Oriented Programing" は日本語訳は『プラレール指向プログラミング』だと思ったのは私だけでしょうか? 有志でスコットさんにプラレールを贈ってレゴと並んでプラレールを流行らせてみませんか? 😃 #fp_matsuri #関数型まつり
— YOSHIDA Takehiko (@chihayafuru) June 14, 2025