Lensを始めとするOpticsがプログラミングをどう変えるか / 複雑なデータのモデリングをサボるには - Lambdaカクテル
仕事でLensを使う機会があった。Lensは複雑で入り組んだデータ構造の読み書きに非常に効果的な手法であるにもかかわらず、関数型プログラマ以外にはあまり知られていないように思える。 そこでこの記事では、Lensとは何なのか、なにが良いのか、具体的にどのようなケースでLensが役立ったか、そしてLensの亜種について紹介する。業務でも使ってます！ AIくんが考えるLens 前提条件 Lensとは Lensの使いどころ データをモデリングする場合 (とても つらい) Lensを使う場合: Lensはアクセスパスである Lensと愉快な仲間たち Lensの合成 -- andThenでひっつけよう Lens Law Monocleの便利機能 Lensの自動生成でサボる Focusでもっとサボる Lensがもたらしたもの まとめ あわせて読みたい 前提条件 この記事ではLensを紹介する言語としてS
『なっとく！関数型プログラミング』は読者の理解度の進捗を先読みして作り込まれた”プログラミング入門”の良書 - Magnolia Tech
なっとく！関数型プログラミング 作者:Michał Płachta翔泳社Amazon 良い、買おう、読もう、（コードを）書こう、以上！ めっちゃ良いですよ、この本 中盤のプリミティブじゃやりづらい→直積→直和→二つ合わせてADT→値を取り出すためのパターンマッチの解説の流れの疾走感がいいですね— magnoliak🍧 (@magnolia_k_) 2023年8月6日 『なっとく！関数型プログラミング』は、2022年に出版された『Grokking Functional Programming』の邦訳版で、主にScalaを題材として関数型プログラミングを学んでいくための入門書("Grokking"は、完全に理解する、という意味)。あくまで関数型プログラミングの考え方、コードの書き方、良い設計の指針の解説が主眼に置かれているので、Scalaの言語機能の入門書ではない。Scalaの言語仕様を網羅
不要なクラス宣言、やめちゃおっか？ - タオルケット体操
今回のエントリは特定の言語に向けて書いているわけではありませんが、関数をサポートしていない言語では必然的にクラスをベースに実装していくことになるのである程度は対象となる言語は絞られます*1。 また特に説明がなければサンプルはTypeScriptで書きます。 さて、あくまで傾向としてではありますが関数を作れる言語の経験が短い人（例えばJavaやRubyですと、関数ではなくクラスに対するメソッドという形で実装することになります）は、単機能の振る舞いを実装するためだけであっても以下のようなコードを実装しがちです class DoSomethinger { constructor(private something: Domething) {} public doSomething() { return dooo(something); // do something } } これは const
💣Webフロントエンドにおける関数型「風」プログラミングに関する個人的まとめ - Qiita
ここ数年の流れについて 技術的側面 Webフロントエンド（ほぼTypeScript＆React界隈）において、オブジェクト指向（厳密に言うとクラスの利用）から脱却する流れがあります。原因は以下の2点。 クラスの継承の問題点が（IT業界全体に）広く定着したこと JS/TSの進化、Reactの進化、関数型言語の考え方などの影響により、クラスを用いてデータと関数群を紐づけるメリットが薄くなったこと 現状、設計レベル（実務的にはどの関数を纏めてモジュール化するのか、モジュール同士をどう繋ぎ合わせるのか、フォルダ割りどうするのか等）のノウハウがまだ固まっておらず、既存の設計論はそれなりに有効です。 コミュニティ的側面（政治） これらの流れはWebフロントエンドの中でもTypeScript＆Reactの界隈が主導しており、そのノウハウは長年絶対視されてきたオブジェクト指向を解体するような内容であったた
システムの複雑さはどこから来るのか – Out of the tar pitを読む - Uzabase for Engineers
Uzabase Saas Product Divisionフェローの矢野です。 この記事は、Rich Hickey（プログラミング言語Clojure作者）のプレゼンテーションSimple Made Easyへと繋がっていく、Ben MoseleyとPeter Marksによる「Out of the tar pit」というシステム設計について論じた論文の内容について説明したもので、ユーザベースのSaas Productでのテック発表の一つとしてプレゼンしたものを、ブログとして再度まとめたものです。プレゼン自体は25分くらいでしたので、おそらくこの記事の方がプレゼンよりも詳しいと思います。 ソフトウェア危機 ソフトウェアは本質的に複雑 ソフトウェアの複雑さはどこから来るのか？ 複雑さは、別の複雑さを産む 複雑さを分類する 本当に必要な複雑さと、そうでないものがある どうやって複雑さを扱うのか
「オブジェクト指向プログラミングと関数型プログラミングは対立するものではなく直交する」という主張があります。私は常々この主張は詭弁であると考えており、それは自己回答で補足します。如何思われますか？
回答 (4件中の1件目) 質問者です。 まず、「オブジェクト指向プログラミングと関数型プログラミングは対立するものではなく直交する」という主張についてです。 このトピックにおいて「直交」という数学的な用語が、自分が知る限り、少なくとも日本国内で表明されたのは、 「関数型言語」に関するFAQ形式の一般的説明 - Qiita という記事が最初であると記憶しています。 ちなみに蛇足を先に処理しておくと、この記事は、モナドって？の章にしてもモナドの定義も説明内容も完全に間違っているし（書き手が理解できていない、モナドについて正しい知識は、30分でわかるJavaScriptプログラマの...
Algebraic Structures: Things I wish someone had explained about functional programming
This is part 2 of a four-part series: Things I wish someone had explained to me about functional programming Part 1: Faulty Assumptions Part 2: Algebraic Structures Part 3: Type classes Part 4: Algebraic Data Types Algebraic Structures are something I wish I’d understood better, sooner. I had a hazy idea of what they were, but didn’t know the correct terminology. That was a massive barrier to find
継承によらないポリモーフィズム実現手法 - Qiita
ポリモーフィズム(polymorphism; 多態, 多相)」というとオブジェクト指向プログラミングにおける継承(インターフェースの継承)による実現手法がよく知られている。 しかし、ポリモーフィズムを実現するための手法はオブジェクト指向的な型階層によるものに限らず様々なものがある。 ここでは、Expression Problemに対する解決策として挙げられる、継承によらないポリモーフィズムの代表的な実現手法として、 型クラス(type class) プロトコル(protocol) マルチメソッド(multimethod) による実装を複数言語で試してみた。 いずれの方法も明示的な継承関係を必要とせず、拡張に対して開いているため、既存の型(例えば言語組み込み型)に対しても容易に拡張可能なことが特徴的で、ある種のインターフェース定義に対する実装を追加することで、いつでも適用範囲を拡大できる。
モダンなソフトウェア設計の書籍 - kawasima
型駆動設計から始まるフォーマルなアプローチもカバーしているが、フォーマルな方法の簡単な紹介も含まれているもの。
break可能なループを書こう - 関数型プログラミングのテクニック - Qiita
手続き型言語を使う人に「F# のループ (for/while) は break できない」というと驚かれるかもしれません。筆者は驚きました。途中で終了する可能性のあるループを書けなくて困りそうですが、その心配は不要です。F# では 末尾再帰関数 を使って、break や continue のあるループと同じことができるからです。 例1: 無条件の無限ループ まずは最も簡単な例を挙げます。break も continue も使わないループを、末尾再帰関数を使って書いてみましょう。ひたすら yes を出力するだけの、通称 yes コマンドです。C# だとこうですね。 public void YesAll() { while (true) { Console.WriteLine("yes"); } }
オブジェクト指向の呪いと、その避け方 - mizchi's blog
このテーマで書く前に、まず、最初に自分に多少の偏りがあることを認めておかなくてはなりません。 オブジェクト指向より、関数指向寄り オブジェクト指向のアプローチは有用だが、ただしそれを実現する手段はクラスと継承ではない。 階層化されたツリー構造(GUI/リレーショナルな参照構造)に埋め込まれる状態はコード品質を悪化させるので、できるだけ出現するべきではない。 ただし、状態は確実に存在する。だからこそ慎重に扱うべきだ、という派閥です アンチパターン: 特に理由もないクラスメソッドへの所属 何かのバリデータを実装したいとします。 その関数がどこに所属するかについて、よく見るこれらの実装は全部アンチパターンといっていいと思います export class Validator { static validate() {...} } export class Validator { validate(
現代のオブジェクト指向の class の割れ窓化と宣言的プログラミング
オブジェクト指向には、カメラがやっとついたころのガラケーのイメージがある - きしだの Hatena の件。基本的には同意。ただちょっと切り口が違うので自分の意見を言っておく。ただ、このテーマで何度か書こうとして失敗していて、今回も成功しているとはいえない。 宣言的プログラミングの時代 現代の主流は「宣言的プログラミング」であると思っている。これはリソースの宣言と、その状態遷移の手続きや振る舞いの付与が中心にある。 宣言型プログラミング - Wikipedia その代表的な例がフロントエンドの React と、バックエンドの k8s で、どちらも時系列に基づいた状態の宣言と、フレームワーク側による状態遷移処理、 Reconcillation(調停) が基礎にある。 フロントエンドとバックエンドという両極端な世界で、この変化が起きたのがこの時代を反映したものであると思う。 例えば、jQuer
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
関数型プログラミングとオブジェクト指向の抜き差しならない関係について整理して考える
関数型プログラミングが『銀の弾丸』であるという非常識な常識2022
Clojure作者のリッチ・ヒッキーは「オブジェクト指向言語では『時間』を正しくモデル化できない」と述べています。「時間を正しくモデル化する」とはどういうことですか？
https://ubiteku.oinker.me/2017/09/08/oo-and-functional-are-orthogonal-or-not/
関数型言語F#を使ったDDDとCQRS
モナドについて学んでいるのですが、mapやflatMapは圏論ではどの概念にあたるのですか？
Converting Iterative Code to Recursive Code - Solving Problems with Recursion in Python
General way to convert a loop (while/for) to recursion or from a recursion to a loop?