オープンデベロッパーズカンファレンス(ODC)2024 での発表資料

関数型プログラミングを silver の bullet としてなりふり構わず振り回していましたが、 ちょっと真面目に学ぶ機会を設けてみました。 関数型プログラミング(Functional Programming)を学んだ参考書の紹介と 私の浅い見解についてまとめていきます。 参考書のご紹介 Functional-Light-JS 筆者曰く、筆者の数学的知識は一般レベル、Scheme/Clojure/Haskell は未経験。 そのため関数型本来の意味や各用語の学術的な意味合い等は記載しておらず、 実用的なアプローチと共にお送りする文書とのこと。 いわゆるボトムアップ。 functional-programming-jargon こちらは打って変わって関数型に関する jargon についてまとめています。 1 番ありきでこちらを付加資料として読むと見識が深まるかと思います。 いわゆるトップダ
tl; dr 普段はTypeScriptを書いているオタクが、すごいH本を読んだ📖 Haskellには便利な機能や考え方がたくさんあり、その一部はTypeScriptみたいなプログラミング言語でも表現できることがわかった TypeScriptでHaskellみたいなことをしようと思うと、いわゆるモナドライブラリが便利であり、中でもfp-tsが良さそうだった 以下にはfp-tsについて具体的な解説などをコードを交えて書く。 はじめに 前職で、TypeScriptのコードに type Either<Left, Right> = ... みたいなtype aliasを書いていたエンジニアさんにHaskellを勧められ、すごいH本を読んでみた。 Haskellはすごかった。もの凄く強力なチカラを2つ持っている。ガチガチな静的型付けと、モダンな関数型プログラミング技法である。美しく、型安全で、無駄
きっかけ FunctionalOptionPattern MethodChaining MethodChaining の問題点 Error フィールドによる解決方法 Error フィールドによる解決方法の問題 1. 各メソッドでエラーが発生しないような印象を受ける 2. エラーチェックを忘れそう その1 3. エラーチェックを忘れそう その2 FunctionalOptionPattern による解決方法 MethodChaining としての解決方法 Error フィールドの問題点は本当に問題なのか? どちらを使うべきなのか? まとめ きっかけこの記事を書くきっかけは以下のブログで、 MethodChaining の代わりに FunctionalOptionPattern を利用したという記事。 https://www.calhoun.io/using-functional-option
Monads are all about function composition and hiding the tedious part of it. After 7 years of being a Go programmer, typing if err != nil can become quite tedious. Every time I type if err != nil I thank the Gophers for a readable language with great tooling, but at the same time I curse them for making me feel like I am Bart Simpson in detention. I suspect I am not the only one, but Monads are no
###オプション パッケージを作る際、柔軟性を持たせるためにオプションを持たせたい時がしばしばあります。 しかしオプションは知っての通り設定しないことが少なくありません。 単にコンストラクタに並べるようでは無用な複雑さをはらむことになります。 JavaなどではOptional Parameterなどのように、デフォルト値が指定できる機能があります。 機能の厳選されたgo言語ではそのような機能はありませんが、 "Self Referential Functions Design"というテクニックがあり、 それについての記事がRob Pike氏の記事を筆頭にいくつか説明されています。 オプションと相性が非常に良いため、合わせて"Functional Option Pattern"とも呼ばれています。 Dave Cheney氏の記事を参考におおまかに説明したいと思います。 ###様々な解決策 あ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Functional and Reactive Domain Modelingとは、ドメイン駆動設計(DDD)の関数型プログラミング(FP)とリアクティブプログラミング(RP)によるアプローチを書いた本 1. 関数型ドメインモデリング:イントロダクション 変更可能なステートを避ける - 変更可能なステートは管理が難しく、非決定性につながる 参照透過性 - FPは、参照透過なモデルコンポーネントを設計する能力を提供する。モデルの振る舞いが純粋関数で構築されていることで合成性を得られ、小さな関数から大きな関数を作ることができる 自律的成長
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? LambdaConfがツイートにて関数型プログラミングのレベル分けを発表していました。今後LambdaConfから発信される発表にはこのレベルが表記され, 自分のレベルにあったコンテンツが探しやすくなるようです。このレベル分けはプログラマの優劣を付けるようなものではなく, 広く深い関数型プログラミングの世界で自分が今どのレベルにいるのかを適切に理解し次にどこに向かうべきなのかを知るのにたいへん役に立つものだと思います。 表を眺めてみると関数型プログラミングというよりかはHaskellのレベル分けのような印象も受けますが、広く知られるべき
This book is a balanced, pragmatic look at FP in JavaScript. The first edition is now complete. Read here online for free, or: "Functional-Light JavaScript" explores the core principles of functional programming (FP) as they are applied to JavaScript. But what makes this book different is that we approach these principles without drowning in all the heavy terminology. We look at a subset of FP fou
オブジェクト指向を知っている人々に、「関数型もオブジェクト指向と大差ないよ、大丈夫だよ」とお誘いする記事は大いに存在意義があると思います。 関数型プログラミングはオブジェクト指向の正当な後継である 上記の記事は、そういう目的を持って書かれたのでしょう。その内容(目次)は次のようです(僕のこの記事の目次じゃないよ)。 対象読者 なぜこの記事を書こうと思ったのか? なぜ関数型プログラミングはわかりにくいのか? オブジェクト指向の負の遺産を捨てよう 関数型プログラミングの概要 「阿吽の呼吸」とも言うべき使いやすさの拡張 型にまつわる考察 まとめ 最初のほうを読むと、言ってることはまっとうで好感を持てます。が、「5. 関数型プログラミングの概要」の節あたりから雲行きが怪しくなって、ちょっと何言ってるかわかんない((c)サンドウィッチマン)。 檜山のこの記事の内容: 真面目なポエム モナドっておいし
はじめに これは自分用の関数型プログラミングお勉強ノートです。 Atom や CoffeeScript に少し退屈してきたので別のお勉強をすることにした。 関数型プログラミングを学ぶことにした。 時々、Qiita の記事とかは読んでいたが、ガーッと調べてやりだしたのは半月程前の 2016年の6月の初旬から。 しばらく続けてみようと思う。 調べ物がどんどん拡散して行くので整理の意味でここに dump しておく。 自分が使う用。 自分が読んで良かった or 良さそう、なリンクに絞ってある。 リンク集としては既にとても豊富で、簡単に消化し尽くせないので自分用としてはこれで十分だ。 ちゃんと消化していくには相応の時間がかかるだろう。 同じように関数型プログラミングを初歩から学ぼうとしている人の参考になるかもしない。 俺のプログラミング勉強法は、これまでの経験上、以下の様なパターンがある。 今は 1
Goでプログラムを書いていると、汎用的なmap関数やfold関数(reduce関数)のようなものがあれば便利なのに、という場面が結構あります。 そういうときは、それぞれの型専用の関数を一通りあらかじめ用意しておく、というような方法でお茶を濁すことが多いと思いますが、そんなものではHaskellやLispな人はもちろんRubyやPythonに慣れたLL脳な人にも満足できないはずです。 そこで本記事では、ジェネリックな高階関数をリフレクションを駆使して実装することで、Goで関数型プログラミングを試みようと思います。 単純な実装のmap関数 最初に、関数を引数にとる関数を単純に実装した場合をみてみます。 例えば、sliceのすべての要素に対して関数を適用した結果を新たなsliceで返すMap関数を考えてみます。 package main import ( "fmt" ) var ( ints =
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く