この動画でこれまでわからなかった所の霧が晴れた気がします！ありがとうございました！
いつもわかりやすい動画助かってます！データ構造のスタックやキュー、ヒープ、木などの動画も見たいと思っています！検討よろしくお願いします！
Excelの関数と似ていますね。Excelの場合副作用のあるhyperlink関数のみ例外という。
手続き型の例に問題はないとして、宣言型の例としてsum関数をそのまま使うのはちょっとどうかなぁ...誤解を招く可能性がある気がします。この例なら、C++でも組み込みのsum関数（accumulate）を使えば関数型プログラミングですか？と思ってしまいます。sumの例で宣言型を説明するなら、sum [] = 0 -- 空リストの場合ゼロsum (x:xs) = x + (sum xs) -- そうでない場合、先頭要素＋（それ以降の要素の和）というコードの説明をした方が宣言型という言葉の意味が伝わりやすいかと思います。手続き型のコードより圧倒的にシンプルで、可変変数を使用することもなく、sumという関数が「何であるか」を必要十分量淡々と定義するだけで、それをどう計算するかまでは明示的に書かないのがミソかと。とはいっても、が実際にどう計算されているかを理解しないで上記のコードを書くのは難しいと思いますが。
なんか強引な決めつけが多いですね。mutableが優れていると言いたげですが、手続き型でimmutableな変数を使う方が自然な場合は多々あります。例えばビッグデータをインメモリでソートするのにimmutable を使うのは間違っているでしょう。Rustのデフォルトがimmutableでmutで可変に宣言できるのはいい落とし所だと思います。またコーヒーメーカーの例も変で、枯れたライブラリを使えば手続き型も「コーヒーメーカー」だし「オートマ」です。最後に手続き型と関数型は補完関係にあるとトーンダウンしてしまっていて、最初の主張がボケてしまっているように思えます。これだとハイブリッド型がいいという結果になってしまいます。純粋型を選ぶ理由が知りたいので色々と調べているのですが、なかなか見つからないRustaceanです。
全体的に俯瞰できていて面白いと思います。ただ残念なのはFORTRANのスペルが間違っていたこと。FORmula-TRANslator ですから、FORTLANではなくFORTRANですね。
かつてはプログラム規約等でプログラマが管理していたことに対してレベルの低下したプログラマ（コーダ）のミスを減らすべく言語の方で対策した結果のひとつと考えればよい。
多分、実際のプログラミングではもっと大きい枠で捕えなければならないでしょうね。ここは関数型プログラミング、そこはその裏方のプログラミング、みたいに一人で二役やる事も必要かもしれません。もっと大きい枠で、バグのないコード、見やすいコード、副作用の無いコードを書くにはどうすればいいか。という目的に対して関数型プログラミングは一つの方法であるというくらいに思っていた方がいいのかな。 それと例としてどうなのかなと思ったのは、constなデータを操作する関数じゃない方が良かったんじゃないかな。定数を扱うのだったら定数が返って当たり前じゃないかと思ってしました。 それより、フェボナッチ数を求める漸化式なら、関数型プログラミングが引き立つのじゃないでしょうか？必ずn項目には同じ数値が返ってきますが、命令語型言語ならこうなります、関数型言語ならこうなりますと、コードを示していただけましたら、なるほどとなったのかもしれません。
ここでも オブジェクト指向を間違って理解してる オブジェクト指向を巨大化 させるのは 犬がワン 猫がニャーなのが原因なんだろうなぁ犬もワンも猫もニャーもオブジェクトだよOSのない世代だからかぁオブジェクト指向をブラックボックス化して気にせず作ってるのかそれやると結局巨大化するんだけどねぇ
この動画でこれまでわからなかった所の霧が晴れた気がします！ありがとうございました！
いつもわかりやすい動画助かってます！
データ構造のスタックやキュー、ヒープ、木などの動画も見たいと思っています！検討よろしくお願いします！
Excelの関数と似ていますね。Excelの場合副作用のあるhyperlink関数のみ例外という。
手続き型の例に問題はないとして、宣言型の例としてsum関数をそのまま使うのはちょっとどうかなぁ...誤解を招く可能性がある気がします。
この例なら、C++でも組み込みのsum関数（accumulate）を使えば関数型プログラミングですか？と思ってしまいます。
sumの例で宣言型を説明するなら、
sum [] = 0 -- 空リストの場合ゼロ
sum (x:xs) = x + (sum xs) -- そうでない場合、先頭要素＋（それ以降の要素の和）
というコードの説明をした方が宣言型という言葉の意味が伝わりやすいかと思います。
手続き型のコードより圧倒的にシンプルで、可変変数を使用することもなく、sumという関数が「何であるか」を必要十分量淡々と定義するだけで、それをどう計算するかまでは明示的に書かないのがミソかと。
とはいっても、が実際にどう計算されているかを理解しないで上記のコードを書くのは難しいと思いますが。
なんか強引な決めつけが多いですね。mutableが優れていると言いたげですが、手続き型でimmutableな変数を使う方が自然な場合は多々あります。例えばビッグデータをインメモリでソートするのにimmutable を使うのは間違っているでしょう。Rustのデフォルトがimmutableでmutで可変に宣言できるのはいい落とし所だと思います。
またコーヒーメーカーの例も変で、枯れたライブラリを使えば手続き型も「コーヒーメーカー」だし「オートマ」です。
最後に手続き型と関数型は補完関係にあるとトーンダウンしてしまっていて、最初の主張がボケてしまっているように思えます。これだとハイブリッド型がいいという結果になってしまいます。
純粋型を選ぶ理由が知りたいので色々と調べているのですが、なかなか見つからないRustaceanです。
全体的に俯瞰できていて面白いと思います。ただ残念なのはFORTRANのスペルが間違っていたこと。FORmula-TRANslator ですから、FORTLANではなくFORTRANですね。
かつてはプログラム規約等でプログラマが管理していたことに対して
レベルの低下したプログラマ（コーダ）のミスを減らすべく
言語の方で対策した結果のひとつと考えればよい。
多分、実際のプログラミングではもっと大きい枠で捕えなければならないでしょうね。ここは関数型プログラミング、そこはその裏方のプログラミング、みたいに一人で二役やる事も必要かもしれません。もっと大きい枠で、バグのないコード、見やすいコード、副作用の無いコードを書くにはどうすればいいか。という目的に対して関数型プログラミングは一つの方法であるというくらいに思っていた方がいいのかな。
それと例としてどうなのかなと思ったのは、constなデータを操作する関数じゃない方が良かったんじゃないかな。
定数を扱うのだったら定数が返って当たり前じゃないかと思ってしました。
それより、フェボナッチ数を求める漸化式なら、関数型プログラミングが引き立つのじゃないでしょうか？必ずn項目には同じ数値が返ってきますが、命令語型言語ならこうなります、関数型言語ならこうなりますと、コードを示していただけましたら、なるほどとなったのかもしれません。
ここでも オブジェクト指向を間違って理解してる オブジェクト指向を巨大化 させるのは 犬がワン 猫がニャー
なのが原因なんだろうなぁ
犬もワンも猫もニャーもオブジェクトだよ
OSのない世代だからかぁ
オブジェクト指向をブラックボックス化して気にせず作ってるのか
それやると結局巨大化するんだけどねぇ