Размер видео: 1280 X 720853 X 480640 X 360
Показать панель управления
Автовоспроизведение
Автоповтор
素晴らしい動画です。IT系のこういう動画、最近プログラムをちょっとやってわかったかのような解説が多い中、本当に鋭いです。ちゃんと本を読み込んで正しいことを理解されていますね。どこかみんな自分が使っている言語が素晴らしいとか他の言語ディスったりとかするんだけど、そんなことはどうでもいいシステム思考として、全体最適化するプログラム思想をしっかり持っている必要があり、様々な言語の成り立ちやなぜ、その言語を作られたか、時代背景などを知ると、プログラムの面白さやシステムのやりがいが見えてきますね。ラムダ式を学ぶことや、マイクロコンピューティング、AWSのLamdaなど上手に使えばモノリシックにならないので、バグがあっても見つけやすいし、機能変更などがあっても、コーディングしやすい。いろいろなメリットがありますね。そのうちの一部ですが、言いたいことを正しく伝えてくれている動画だと思います。素晴らしいです。これからもちょこちょこ拝見します。
めちゃくちゃわかりやすかったです！！他にも読まれた本を紹介してほしい!!!
すごく有益でした
具体例をしっかりあげて説明してくれているので、個人的には、わかりやすく、ためになりました。こういう、技術や1つのテーマに特化した動画も、好きなので、また上がるの期待してます。
ありがたいです！動画のターゲットがかなり絞られますが、こう言った難しめの動画もまた出して行きたいです。
関数型のスタイルを1年以上前から取り入れている趣味プログラマです。関数型は、部分適用、カリー化、も知ると、さらに柔軟に書けるため、ワクワクできると思います。魅力が伝わると良いですね！
素人質問で恐縮なのですが、要するに「コールバック関数を積極的に使った方がコードを簡略化できて計算量も減っていいよ」ということでしょうか？
C++しか使ってないのですが、言語が違ってもアルゴリズムとかは変わる事は無いのでJAVAを超えた俯瞰的な視点で見た感想を述べますと、適切な場所に適切に使えば品質の高いコードが書けるなという印象を受けました。しかし、全てが関数型プログラミングで書けるわけではないので、自ら律して書く事が重要だろうなと思います。
関数型のF#は結構速いし、静的型付けの型安全だし、オブジェクト指向兼関数型だから両方の良いところを取り入れることができる(オブジェクト指向の手続き型部分が関数型に変わったイメージ)。関数型と静的型付けの相性は非常に良いと感じる(完全な型推論と実行速度)。Rustとか速いと聞いたが、関数型の利点を言語上に組み込んでいるのもあるのではないのかと思う。関数型はかつてないほど盛り上がっているとはいえ、今だにマイナーの地位にいるのは、コペルニクス的転回が必要で難しいからなのだろうか？
実務で冗長にしか書けなかった関数がstrategyパターンでスマートになりそうで見てよかったです！ありがとうございます😂
javaで高階関数っぽいことができるのか。便利だな。
3:39ここのtoList()から返ってくるものの型はListじゃないですか？
その通りですね。。訂正ありがとうございます！
4:06 10:04 10:39 11:01 12:2715:1317:5218:31
コンパイラが最適化してくれてるみたいな話は本当でしょうか？あくまで単純に関数の裏で関数オブジェクトが処理されているだけではないのですか？parallelでなければ、forの方が速いのでは？Javaは詳しくないので間違ってたらすみません
この動画の参考文献である「Javaによる関数型プログラミング ―Java 8ラムダ式とStream」によると、JavaのStream APIはCPU依存の計算を自動でMultiprocessingしてくれるので高速化してくれるとのことです。
@@kaigai-engineer返信ありがとうございます14:40 で並列処理してくれるとおっしゃっていますが、parallelとは書いてないので、その場合も適応されるのか気になりますまた、少し調べたのですが、parallelはstream apiで構築された処理オブジェクトをchunkに分け、プールされたスレッドに処理を分配する機構であって、コンパイラがしてくれるという言い方が適切かどうかに疑問があります返信内容を見るに参考文献には「javaのコンパイラが〜してくれる」というような記述は無さそうです？すみません、揚げ足取りかもしれませんね
5:15 辺りの文脈だと「歩け」は式と言いたげですが違います。複数の文を合わせてサブルーチン化しただけです。「歩け」だと関節が動くなど副作用が発生し、直前の関節の角度などによって参照透過性が失われるはずだと思いますが。
確かにそこまでのニュアンスまで考えられてなかったです。直立から歩きはじめて直立で終わると定義しても、「座標の位置が変わるから参照透明性がない」となってしまいますね。ご指摘ありがとうございます。
@@kaigai-engineer 例え話は難しいですね。必ずどこかで矛盾が出てきます。偉そうに突っ込みましたが、私自身、圏論に取り組んでは玉砕を繰り返しています。圏論自体は難しいとは感じないのですが、なかなか関数型プログラミングと繋がらない。
関数型スタイルの書き方の方が読みやすいと思ってしまった自分はロボットなのかもしれない、となった
いえいえ、関数型のメリットの一つがまさに「読みやすさ」です！
むっずいっす
RUclipsで解説となると前提知識を省略しなきゃいけないので、こういう難しいのは向いてない説ありますね。
C言語では関数型プログラミングできなさそうなことはわかりました。
最低でもJavaのstreamのような遅延評価してくれるAPIがないとできない（やるデメリットが多すぎ）ですね。。
覚えないと行けないの多すぎてしんどそう
でも並列処理がされるところは便利ーって思った
でもまって？それってCPU使用率めっちゃ高くならない!?
100万個の配列があったら全部3桁かチェックしながら同時に100万個全部大文字にしてるってこと？？？それってなんかヤバそう😮
でもどうせCPU使用率上がってもそんなにCPU使う処理ならIOとかのが時間かかるから大した問題ちゃうか確かに速度早い方が大切かも
Reactやってると今は関数型にせざるおえないと思う。
Reactはそうですね！
haskellがむずすぎてトラウマ、、
今までやった中で一番難しい言語ですね笑
@@kaigai-engineer 興味をそそられたのでコード書いてみました。import Data.Charimport Data.Maybenames = ["Brad", "Kate", "Kim", "Jack", "Joe"]mbHead :: [a] -> Maybe ambHead [ ] = NothingmbHead (x:_) = Just xfromMaybe "" $ mbHead . map(map toUpper) . filter((==3).length) $ names-- => "KIM"type Asset = (String, Int);assets :: [Asset]assets = [ ("bond" , 1000) , ("bond" , 2000) , ("stock", 3000) , ("stock", 4000) ]totalAssetsValue :: (Asset -> Bool) -> [Asset] -> InttotalAssetsValue f lst = sum $ map snd $ filter f lsttotalAssetsValue ((=="bond" ).fst ) assets -- => 3000totalAssetsValue ((=="stock" ).fst ) assets -- => 7000totalAssetsValue ((> 2000 ).snd) assets -- => 7000totalAssetsValue ((even.(`div`1000)).snd) assets -- => 6000totalAssetsValue ((> "" ).fst ) assets -- => 10000
説明が全体的にあやふやと感じました。最初の奇数の例ですが関数型の書き方にした場合、一目でループ変数iに関するコードが消えているのが明確ですし、(配列の長さや配列の範囲外アクセスの問題が消えている)コード量で言えばさほど変わってませんし、むしろ行数だけで言えば減ってます。パフォーマンスに関して言えば実装依存ですね。「回りくどい」っていうのは主観的な感覚でコードを見ているように感じます。後半は関数型の話じゃなくデザインパターンの話になっちゃってませんか？この動画そもそも関数型の話では？参考にした本では関数型を5大要素とかで説明しようとしていますが、数学的テクニックを使ってプログラムすると理解したほうがいいと思います。副作用等の話は数学の大前提として必要だからと。最後に、本当に関数型学びたいならjvm言語でもjavaみたいな古い仕様じゃなくてClojure,Scalaとかのほうをおすすめします。
素晴らしい動画です。IT系のこういう動画、最近プログラムをちょっとやってわかったかのような解説が多い中、本当に鋭いです。ちゃんと本を読み込んで正しいことを理解されていますね。
どこかみんな自分が使っている言語が素晴らしいとか他の言語ディスったりとかするんだけど、そんなことはどうでもいい
システム思考として、全体最適化するプログラム思想をしっかり持っている必要があり、
様々な言語の成り立ちやなぜ、その言語を作られたか、時代背景などを知ると、
プログラムの面白さやシステムのやりがいが見えてきますね。
ラムダ式を学ぶことや、マイクロコンピューティング、AWSのLamdaなど上手に使えばモノリシックにならないので、バグがあっても見つけやすいし、機能変更などがあっても、コーディングしやすい。
いろいろなメリットがありますね。
そのうちの一部ですが、言いたいことを正しく伝えてくれている動画だと思います。素晴らしいです。
これからもちょこちょこ拝見します。
めちゃくちゃわかりやすかったです！！他にも読まれた本を紹介してほしい!!!
すごく有益でした
具体例をしっかりあげて説明してくれているので、個人的には、わかりやすく、ためになりました。
こういう、技術や1つのテーマに特化した動画も、好きなので、また上がるの期待してます。
ありがたいです！
動画のターゲットがかなり絞られますが、こう言った難しめの動画もまた出して行きたいです。
関数型のスタイルを1年以上前から取り入れている趣味プログラマです。
関数型は、部分適用、カリー化、も知ると、さらに柔軟に書けるため、ワクワクできると思います。魅力が伝わると良いですね！
素人質問で恐縮なのですが、要するに「コールバック関数を積極的に使った方がコードを簡略化できて計算量も減っていいよ」ということでしょうか？
C++しか使ってないのですが、言語が違ってもアルゴリズムとかは変わる事は無いのでJAVAを超えた俯瞰的な視点で見た感想を述べますと、適切な場所に適切に使えば品質の高いコードが書けるなという印象を受けました。
しかし、全てが関数型プログラミングで書けるわけではないので、自ら律して書く事が重要だろうなと思います。
関数型のF#は結構速いし、静的型付けの型安全だし、オブジェクト指向兼関数型だから両方の良いところを取り入れることができる(オブジェクト指向の手続き型部分が関数型に変わったイメージ)。関数型と静的型付けの相性は非常に良いと感じる(完全な型推論と実行速度)。Rustとか速いと聞いたが、関数型の利点を言語上に組み込んでいるのもあるのではないのかと思う。関数型はかつてないほど盛り上がっているとはいえ、今だにマイナーの地位にいるのは、コペルニクス的転回が必要で難しいからなのだろうか？
実務で冗長にしか書けなかった関数がstrategyパターンでスマートになりそうで見てよかったです！
ありがとうございます😂
javaで高階関数っぽいことができるのか。便利だな。
3:39
ここのtoList()から返ってくるものの型はListじゃないですか？
その通りですね。。訂正ありがとうございます！
4:06
10:04
10:39
11:01
12:27
15:13
17:52
18:31
コンパイラが最適化してくれてるみたいな話は本当でしょうか？
あくまで単純に関数の裏で関数オブジェクトが処理されているだけではないのですか？
parallelでなければ、forの方が速いのでは？
Javaは詳しくないので間違ってたらすみません
この動画の参考文献である「Javaによる関数型プログラミング ―Java 8ラムダ式とStream」によると、JavaのStream APIはCPU依存の計算を自動でMultiprocessingしてくれるので高速化してくれるとのことです。
@@kaigai-engineer
返信ありがとうございます
14:40 で並列処理してくれるとおっしゃっていますが、parallelとは書いてないので、その場合も適応されるのか気になります
また、少し調べたのですが、parallelはstream apiで構築された処理オブジェクトをchunkに分け、プールされたスレッドに処理を分配する機構であって、コンパイラがしてくれるという言い方が適切かどうかに疑問があります
返信内容を見るに参考文献には「javaのコンパイラが〜してくれる」というような記述は無さそうです？
すみません、揚げ足取りかもしれませんね
5:15 辺りの文脈だと「歩け」は式と言いたげですが違います。複数の文を合わせてサブルーチン化しただけです。
「歩け」だと関節が動くなど副作用が発生し、直前の関節の角度などによって参照透過性が失われるはずだと思いますが。
確かにそこまでのニュアンスまで考えられてなかったです。
直立から歩きはじめて直立で終わると定義しても、「座標の位置が変わるから参照透明性がない」となってしまいますね。
ご指摘ありがとうございます。
@@kaigai-engineer 例え話は難しいですね。必ずどこかで矛盾が出てきます。
偉そうに突っ込みましたが、私自身、圏論に取り組んでは玉砕を繰り返しています。圏論自体は難しいとは感じないのですが、なかなか関数型プログラミングと繋がらない。
関数型スタイルの書き方の方が読みやすいと思ってしまった自分はロボットなのかもしれない、となった
いえいえ、関数型のメリットの一つがまさに「読みやすさ」です！
むっずいっす
RUclipsで解説となると前提知識を省略しなきゃいけないので、こういう難しいのは向いてない説ありますね。
C言語では関数型プログラミングできなさそうなことはわかりました。
最低でもJavaのstreamのような遅延評価してくれるAPIがないとできない（やるデメリットが多すぎ）ですね。。
覚えないと行けないの多すぎてしんどそう
でも並列処理がされるところは便利ーって思った
でもまって？それってCPU使用率めっちゃ高くならない!?
100万個の配列があったら全部3桁かチェックしながら
同時に100万個全部大文字にしてるってこと？？？
それってなんかヤバそう😮
でもどうせCPU使用率上がってもそんなにCPU使う処理ならIOとかのが時間かかるから大した問題ちゃうか
確かに速度早い方が大切かも
Reactやってると今は関数型にせざるおえないと思う。
Reactはそうですね！
haskellがむずすぎてトラウマ、、
今までやった中で一番難しい言語ですね笑
@@kaigai-engineer
興味をそそられたのでコード書いてみました。
import Data.Char
import Data.Maybe
names = ["Brad", "Kate", "Kim", "Jack", "Joe"]
mbHead :: [a] -> Maybe a
mbHead [ ] = Nothing
mbHead (x:_) = Just x
fromMaybe "" $ mbHead
. map(map toUpper)
. filter((==3).length) $ names
-- => "KIM"
type Asset = (String, Int);
assets :: [Asset]
assets = [ ("bond" , 1000)
, ("bond" , 2000)
, ("stock", 3000)
, ("stock", 4000) ]
totalAssetsValue :: (Asset -> Bool) -> [Asset] -> Int
totalAssetsValue f lst = sum $ map snd $ filter f lst
totalAssetsValue ((=="bond" ).fst ) assets -- => 3000
totalAssetsValue ((=="stock" ).fst ) assets -- => 7000
totalAssetsValue ((> 2000 ).snd) assets -- => 7000
totalAssetsValue ((even.(`div`1000)).snd) assets -- => 6000
totalAssetsValue ((> "" ).fst ) assets -- => 10000
説明が全体的にあやふやと感じました。
最初の奇数の例ですが関数型の書き方にした場合、一目でループ変数iに関するコードが消えているのが明確ですし、
(配列の長さや配列の範囲外アクセスの問題が消えている)コード量で言えばさほど変わってませんし、
むしろ行数だけで言えば減ってます。パフォーマンスに関して言えば実装依存ですね。
「回りくどい」っていうのは主観的な感覚でコードを見ているように感じます。
後半は関数型の話じゃなくデザインパターンの話になっちゃってませんか？この動画そもそも関数型の話では？
参考にした本では関数型を5大要素とかで説明しようとしていますが、数学的テクニックを使ってプログラムすると理解したほうがいいと思います。副作用等の話は数学の大前提として必要だからと。
最後に、本当に関数型学びたいならjvm言語でもjavaみたいな古い仕様じゃなくてClojure,Scalaとかのほうをおすすめします。