最適化は別に関数型のパラダイムとは無関係に適用できるし（C23以前でもSSAベースのdead code eliminationやarray bound check removalなど無数にある）、処理順序の可換性みたいな思考モデルへの影響のほうが有意義だと思う。
バグの典型的なパターンとして副作用の有無がよく語られると言うだけで最適化視点での分類とは文脈が違うと思う
Date.now()はくだらなくないだろ。明確に悪でテストや再利用性を阻害する。 def func(now: Date) = hogehogeと書くだけで純粋になるんだからそうするべき
「関数に副作用がある/ない」をもっと細分化すると
"副作用が「ある」か「ない」という分類はコンパイラーにとっては粗すぎる。" それはそう。文脈を明示して語ろう
C言語のコンパイラだって、グローバル変数、staticで修飾されていない、引数にポインタが使われていないの条件で最適化できるので、最適化と副作用は別の議論では？ないことがわかってれば最適化は楽だけど。
その getTime は TDD やクリーンアーキテクチャや DI で出てくる典型的なアンチパターン。その関数を使う処理のテストが書けないというめちゃくちゃ大きな副作用がある。せめてデフォルト引数で Date.now() を使う様にすべき。
作者がコンパイラ実装者の立場で、と言っていることを尊重しよう
なるほど
そう、黒板に式を書いて結果も黒板に書いて完結する数学と、キーボード入力関数やメモリ共有書き換え関数できるコンピュータは世界が違うし。foo()の結果が3ならfoo()を全部3に文字列置換する最適化はもう黒板数学。
flixだとポリモーフィックエフェクトを採用していて、引数がeffectも持つか否かで処理分岐させて、effectなしなら並列処理、effectありならシーケンシャルみたいなことができる。ユーザーサイドでできる最適化
「関数の副作用の有無」よりも大事なもの | 雑記帳
最適化は別に関数型のパラダイムとは無関係に適用できるし（C23以前でもSSAベースのdead code eliminationやarray bound check removalなど無数にある）、処理順序の可換性みたいな思考モデルへの影響のほうが有意義だと思う。
バグの典型的なパターンとして副作用の有無がよく語られると言うだけで最適化視点での分類とは文脈が違うと思う
Date.now()はくだらなくないだろ。明確に悪でテストや再利用性を阻害する。 def func(now: Date) = hogehogeと書くだけで純粋になるんだからそうするべき
「関数に副作用がある/ない」をもっと細分化すると
"副作用が「ある」か「ない」という分類はコンパイラーにとっては粗すぎる。" それはそう。文脈を明示して語ろう
C言語のコンパイラだって、グローバル変数、staticで修飾されていない、引数にポインタが使われていないの条件で最適化できるので、最適化と副作用は別の議論では？ないことがわかってれば最適化は楽だけど。
その getTime は TDD やクリーンアーキテクチャや DI で出てくる典型的なアンチパターン。その関数を使う処理のテストが書けないというめちゃくちゃ大きな副作用がある。せめてデフォルト引数で Date.now() を使う様にすべき。
作者がコンパイラ実装者の立場で、と言っていることを尊重しよう
なるほど
そう、黒板に式を書いて結果も黒板に書いて完結する数学と、キーボード入力関数やメモリ共有書き換え関数できるコンピュータは世界が違うし。foo()の結果が3ならfoo()を全部3に文字列置換する最適化はもう黒板数学。
flixだとポリモーフィックエフェクトを採用していて、引数がeffectも持つか否かで処理分岐させて、effectなしなら並列処理、effectありならシーケンシャルみたいなことができる。ユーザーサイドでできる最適化