2025/02/04 08:22
paradoxparanoic
2025年にこのような議論が必要というのが関数型言語ブームの敗北。人類に叡智を与えることは無理だった
2025/02/04 09:16
hogeaegxa
全件処理するなら何も考えずこのへんを使ったほうがいいと思うが、性能やらなんやらの理由で途中でbreakする分岐がある処理では、ギミックで頑張るとかせず普通にforで回したほうが奇麗なコードになると思う
2025/02/04 10:17
mole-studio
修正例見てもforで良かったな。変数増やして名前に頭ひねるよりifの上にコメント書く方がマシに感じる
2025/02/04 10:22
ssig33
例が全然読みやすくなってないよくあるやつだ、類似例: qiita.com
2025/02/04 10:38
lyiase
Python 使い過ぎて「は？mapやfilterの方が断然読み辛いじゃん」って思ったのは秘密です
2025/02/04 10:45
turanukimaru
もっとシンプルに xs.filter(x->x.isA()).map(x->x.toY()) くらいにしておけば良かったのに。高階関数ではなく stream の話になってしまうが。なお最大値、例えば一番高い商品にクーポンを適用するみたいなのは3秒考えてforで書いた。
2025/02/04 11:02
civiliza
フォントの可読性が低い気がするが今はこういうのが流行ってるのかね。===とか≡≡≡かと思った。
2025/02/04 11:11
KoshianX
what と how を分離できるのがメリット、という話はわかりやすくてよかった
2025/02/04 11:18
surume000
スライドより普通のブログ形式のほうが読みやすいと感じるわたし
2025/02/04 11:26
delphinus35
「読み辛い」みたいな、linterで弾けないようなあやふやな理由ではレビューで指摘しないようにしている。明確に性能差が出るのでなければfor / ifだろうがmap / filterだろうが好みの問題です。
2025/02/04 11:28
takahashim
高階関数じゃなくても for (const product of products) { if (capDiscount(product)) { result = [...result, discount(product)]; }} みたいにするのが読みやすくて良いですよ、というふつうの話ではありますよね
2025/02/04 11:30
yojik
リスト内包が最適と思う。集合内包表記はmap/filterよりも宣言的だし関数型的といえるし、多重ネストもシンプルに書けるし
2025/02/04 11:32
nemoba
抽象より具体の方が読みやすいって主張じゃないかな？ので、答えは、抽象を導入しやすいが、読みやすいかはお前の力量しだいだ。だと思うよ
2025/02/04 11:35
monorod
forだとかmapだとかの前にまず三項演算子をネストして書いてるのをやめてほしいと思ってしまった。早期リターンとか使って判定処理を関数に切り出してよおねがい
2025/02/04 11:54
wordi
コードだけでさらっと書いてるけど早めのfilterも大事
2025/02/04 12:00
morita_non
breakや途中リターンしたいのじゃよ。。。(継続使えって？)。まあ高階関数なければ関係ないのだけどな。
2025/02/04 12:05
rAdio
『map や filter などの集合操作の高階関数は、ループという具体的な How を隠蔽し、そのコードで表したい What を宣言的に書けるようにします』
2025/02/04 12:08
ghostbass
普通のページだと思ってざっと眺めようとしたらちょっとびっくりした
2025/02/04 12:13
NetPenguin
「リストをぐるぐる回したいわけじゃない、中身を変形したいだけ」みたいな事をJavaのStream導入時によく説明していた。
2025/02/04 12:31
bonoumamire
AIに書いてもらえばいいじゃない
2025/02/04 12:40
myr
そもそもmapってハッシュテーブル的なデータ構造だと思ってたから別に古典的なのでは？？？
2025/02/04 12:40
lainof
中身を書き換えるなら最初に書き換えて比較しないとフェアじゃない。filterは条件に一致するものを除くのか抽出するのか分かりにくい。
2025/02/04 12:47
nirasan
この例そもそもProduct型がcanDiscountとかdiscountPriceをメソッドなりなんなりで持ってる方が自然じゃない？
2025/02/04 12:52
yorkfield
jQueryの構文だと考えると、これももはや古典と言えるかも知れない。
2025/02/04 12:52
deb
理系的(技術論)っていうより文系的なコードの読みやすさや柔軟性(仕様変更やスケールのしやすさ)の話
2025/02/04 12:54
tor4kichi
愚直にforに書き下すほうが見通しがいいし性能も関数呼び出し減る分デメリットが生じにくい。または高階関数じゃなくてイテレータとして概念を認識してlinq.js などのヒューマンリーダブルなライブラリを使うことが大事
2025/02/04 12:57
pakila
えっブコメでは不評だけど、普通に書き換え後のほうが読みやすいんだけど？
2025/02/04 12:58
Eiichiro
解説がもったいない。Productの内部関数に持てば、「product.」が全部消せるので、それが出来るならやる。このリファクタだと中途半端に感じる。breakやreturnは、fillter(やreject)で書ける場合が高いので、できる限り使わない。
2025/02/04 13:01
Windymelt
良い記事。高階関数のキモは「一度に一つのことしかするな」ということだと思う。一度に色々やってしまっているループが表現しづらくなるのでちゃんと分解することを要求する。その過程でメンタルモデルが整理される
2025/02/04 13:03
PrivateIntMain
文脈による。単純なSELECT-FROM-WHEREに意味を付けるぐらいならいい。でもすごいチェーンしてたり途中経過を無理やり発生させたりしてまで使うものではないと思う。
2025/02/04 13:11
te2u
mapやfilterは「何をしたいか」がシンプルでないとわかりにくくなる。分かりやすさを考慮すると、ループ処理自体を何度か繰り返すことになるけど性能面を考慮しなければならない。その過程で別法が見つかることがある。
2025/02/04 13:19
takilog
これぐらいの例ならforでいいじゃんって思ってしまいます
2025/02/04 13:25
toro-chan
Pythonの内包表記でも同じ感じ。長く書きすぎて分からなくなってた。しかも短くするよう、関数にすると単にforにした方が分かりやすい。。
2025/02/04 13:35
btei
ページのソースを表示にすると読みやすい/要素数増えたときの破壊的操作とか、遅延評価とかメモ化とかへの最適化が魔術化していき
2025/02/04 13:35
tohokuaiki
mapの中でロジック回されると発狂しそうになります。
2025/02/04 13:41
nunulk
map（写像）はループとは別の概念なのに、こうやってコードに書くと大差ない（あるいは認識に個人差がある）感じになってしまうのが面白い
2025/02/04 13:44
y2q_actionman
高階関数にはexportできるような名前がついている関数だけを渡すようにしてる。それが出来なくて lambda式を渡したりし始めると大抵読みにくくなって、loopで書いたほうがましになる。
2025/02/04 13:52
fishma
三項演算子をネストするみたいな、1行にいっぱいの情報詰め込むの大嫌い
2025/02/04 13:55
toyama_gf
条件（三項）演算子ネストってあって念のため本文確認したけどただのチェーンだった。チェーンの可読性は単にフォーマッタの問題かな ／ テストのために関数化しろ→ついでにif文に書き換えたほうがよい、なら分かる
2025/02/04 14:00
mohno
ドキュメントよりスライドの方が読みやすいと感じるあなたへ、かと思ったら BuriKaigi の資料なのか。
2025/02/04 14:05
Aodrey
コメント書こうよ。
2025/02/04 14:11
raamen07
ネストがなくなるとそれだけでだいぶ読むの楽になったりはすると思う
2025/02/04 14:17
w1234567
適度に説明変数・関数を作ってまとめてくれるならいいんだけど、map→filter→map→filter…みたいになってると馬鹿に刃物を渡すなってなる
2025/02/04 14:26
bfoj
ラムダ式をきちんと設計すればよいのだ
2025/02/04 14:37
koseki
ためになった
2025/02/04 14:46
dada_love
ifとforしか使えません！😭
2025/02/04 14:52
at_yasu
リーダブルコードを読んだら良いんじゃない、とぼんやり。
2025/02/04 14:56
da-yoshi
Scala の for yield 式は書きやすかったな
2025/02/04 15:00
yamadadadada2
forは中で何でもできちゃうけど、filterやmapは何をするか決まってるから読みやすくなるという話ではない？
2025/02/04 15:04
kyukyunyorituryo
filterがreturn false/trueというのに気づくまで時間がかかった。reactでfilterとmapをつかったほうがみやすくなった。　99nyorituryo.hatenablog.com
2025/02/04 15:13
kakei-akihiko
TypeScriptとか大抵の言語はmapやfilterがいいけど、Pythonだとmapは使いにくくてリスト内法表現は鬼畜でforループが見やすい。
2025/02/04 15:20
ymchng
mapやfilterはシンプルに使えるところでは可読性上がると思う。それらを使うことが目的化してわかりにくくなるのは本末転倒。まあいずれにしても枝葉の話かなと。クソ設計はそれらを簡単に帳消しにする。
2025/02/04 15:22
kkobayashi
ケチを付けるわけじゃないけど、その例ならcanDiscountとdiscountを使ってfor文書いてもいいよな。。／処理の目的が明確になる、というのは確かにそうかもね
2025/02/04 15:42
onesplat
こういうプログラムの書き方みたいな話、どんどん価値なくなっていくと思う
2025/02/04 15:45
Crean
高階関数よりfor文？貴方の脳みそ、アセンブラでコーディングしてるのですか？時代遅れのその思考、宇宙の塵にも劣るのだ！
2025/02/04 15:50
stabucky
元のコードがすでに読みにくい。
2025/02/04 16:02
smeg
この記事自体がリーダブルじゃない。中心部分をさっさと読ませろ。
2025/02/04 16:17
Filone
良いサンプルコードって書くの難しいよな。今回の場合も、説明のためにシンプルにしようとしたせいでforでいいじゃんとなってしまう。本当は、シンプルには説明がしづらいような時にこそ出番があったりする。
2025/02/04 16:18
cl-gaku
見逃せないほどの記述量の差でなけりゃどっちも変わらんよね
2025/02/04 16:22
NLPer
イマイチ趣旨がわからない。場合に依るのではないか？
2025/02/04 16:28
NOV1975
重要な部分が関数化されると必要性がわかんなくなるな。
2025/02/04 16:44
aike
たとえばやっかいなバグのあるfor文とmapでどっちがバグを発見・修正しやすいかみたいな比較を読みたい。デバッガとREPLの比較まで含めて。
2025/02/04 16:48
takafumiat
関数型で書くと面倒だから嫌いだよ。
2025/02/04 17:00
Shinwiki
なんかかっこいいから使ってる
2025/02/04 17:10
inatax
高階関数かループかとか以前に、&&や三項演算子で連なった条件分岐が非常に読みづらい
2025/02/04 17:16
megumin1
いかにもJS等しか触ったことがない人が書きそうな記事。JS等だと、高階関数はゼロコストではなく、関数呼び出し等のオーバーヘッドがありすぎて、しょうじき微妙すぎ。ゼロコスト抽象化があるRust等で使いましょうね。
2025/02/04 17:18
FreeCatWork
高階関数？難しいにゃ！for文の方がシンプルで分かりやすいにゃ！猫にも優しいにゃ！ 人間のプログラム、もっとシンプルに作ってほしいにゃ！
2025/02/04 17:34
mag4n
forを使ったオレオレイテレータはバグの温床にしかならん。ちゃんと既存関数あるんだからそれ使えでFixだろこんなん。forしか使えんのは単なる勉強不足。
2025/02/04 17:39
mollifier
canDiscountとかする前のfilter,mapを使ったやつが好き。forは中で何でもできるので読む負荷が高い。filterやmapはできることが制限されてるので読むのが楽
2025/02/04 17:52
work996
他の言語だとresultを不変に出来る安全性が第一義だと思うが、JSだとconstで配列を定義しても後で変更出来るからこういう若干ポエミーなメリットくらいしか無くなっちゃうのかな。
2025/02/04 18:24
cad-san
可読性の文脈よりは、仕様変更容易性の面の利点が大きいかな？DSLに近しい設計にすることで、実装よりも仕様に寄せることが出来る。DSLに寄せるなら大枠はfor文でも構わないと思うけど
2025/02/04 18:49
kowa
ループは形でわかるけど関数は文字を読んで認識しないとわからないからでは。画像的認知は効率いいからな
2025/02/04 19:01
otoan52
より多くの意味が残るのが高階関数で書くことの良さだと思うよ。全件をなめるのだという意図が明白になる。for文だと繰り返しと終了条件の組み合わせの結果、全件をなめることになります。と読み取らないといけない。
2025/02/04 19:30
kabakiyo
この三項演算子を読みにくい人がいるとは！
2025/02/04 19:38
n_vermillion
高階関数か否かより適切な関数切り出しの形の話のような…。
2025/02/04 19:44
habarhaba
mapやfilterが読みづらいと思ったこと無いな。for文でも良いのにreduceを使ってるのは一瞬止まることはある
2025/02/04 20:03
atsushieno
GCあり言語ではコレクションの完全コピーを回避するラッパーは十分に「ゼロコストに近い」と考えて良いので、values()に言及しているこの記事は十分配慮している。values()が機能を表さない名前なのは筆者の責任ではない。
2025/02/04 20:21
Insite
関数型プログラミングは機能ごとに切り分けないと読みにくい。for文の中に手続きをダラダラ書いたままのは手続き的プログラミングとしては読みやすい。
2025/02/04 20:33
mushus
めっちゃ分かる、そしてループでbreakが必要なパターンはだいたい別のこと一緒にやってたりするし、イテレーターのfilterとかmap以外の関数で代用できる
2025/02/04 20:38
fut573
if(pj要員が実務経験3年以上の直接雇用に限定できる)｛｝を最初に判定しないと
2025/02/04 20:58
spark7
他人に見せるコードでしょうもないリガチャ効かせたフォント使ってると（個人的にだが）信頼度がだいぶ下がる
2025/02/04 21:08
Yagokoro
使ってるフォントが読みにくいがｗ
2025/02/04 21:10
objectiveworker
普通のmarkdownで書いて文章で説明してほしい。ナイトクラブで流すモーションタイポグラフィかと思ったわ。
2025/02/04 21:18
hryord
高階関数以前の問題としてifや三項演算子の書き方が酷い。頭いい人が書く独りよがりなコードっぽい。
2025/02/04 21:21
kagerouttepaso
IDiscountDecorator的なインターフェースで価格操作処理を抽象化するときなんかはこういう考え方必須になってくる。そこまでじゃないときは任意かなぁ、高階関数を使うというより抽象化の境界を意識する的な。
2025/02/04 21:32
ryunosinfx
非同期処理のjsの前ではあまりにも無力…※jsの仕様上なかなかしんどい
2025/02/04 21:45
shingo-sasaki-0529
WHATとHOWを分離する例、個人的にはすごく読みやすくなったと思うし、切り出したHOW部分を単体テスト出来るというのもポイント高い。
2025/02/04 22:05
thesecret3
動けばいいよ。在庫管理がしたいだけだ。
2025/02/04 22:06
mayumayu_nimolove
読みやすいというより処理が早いんだよ。あと読みやすいとかもう無くなるから。
2025/02/04 23:09
kiyo_hiko
息をするようにmapcar使ってるのでforは読みづらい…気がするでもforってCommon Lispのdoマクロと似てるっちゃ似てるから読める。条件演算子のこの書き方はPerl Best Practice読んで慣れたのでとても読みやすいと思う。
2025/02/04 23:19
nida3001
これは単にmapとfilterっていうセマンティクスが理解しやすくよくできているのが主要因で、fold系の動作になると途端に難しくなるよ
2025/02/04 23:23
zgmf-x20a
LISPの時は気にならなかったけど、Rだとsapplyの中でのスコープがうまく使えずスクリプトが汚い私。
2025/02/05 00:01
dorapon2000
“map や filter などの集合操作の高階関数は、ループという具体的な How を隠蔽し、そのコードで表したい What を宣言的に書けるようにします”
2025/02/05 00:13
hanagesan
可読性を保ちながら並列化を導入する場合は使うけど、それ以外は個人の趣味の範疇を出ないので使わない
2025/02/05 01:11
ftype
なおBiomeはforEach非推奨なんだよな〜
2025/02/05 03:53
hidea
読みにくいと思ったことなかった
2025/02/05 09:19
suien42
この議論、実際はプログラムに限らない「まず大枠から話してくれ」vs「頭から順を追って話してくれ」という対立なんじゃないかと思っている。
2025/02/05 10:28
strawberryhunter
自分の基準ではどうでもいいコードでは使ってるかな(Java, JavaScript)。forも for eachよりインデックスを使うパターンが結構ある。ついでにdo whileもたまに使う。
2025/02/05 18:58
hatest
WHATとHOWを分離する話 と 高階関数 vs for文の話 は別ですよね？2つのテーマを分離したほうが読みやすいよ
2025/02/06 11:49
sa-yama321
map/filterはforより全く読みやすくていいんだが、reduceはだめなんだよな。reduceがだめだとわからない人のコードはコードリーディングが数秒遅れるから、なかなか苦い
2025/02/06 22:55
zyzy
fold・reduce系も用途は一つなので、全てを曖昧にぶちこんだforでごちゃつかせるよりは整頓出来て分かりやすいと思うよ。大域脱出がある奴はforがいいが（flatMap駆使して出来る場合もあるけど、流石に面倒くさくなりがち）