Erlang はスウェーデン語で、the language みたいな意味なので、最後に t は付きません。まあ、map が適用できるってのが、高階関数の売りだから、そりゃ並列化に向くはずですよね。マッカーシーもさすがにここまでは、考えてなかっただろうなあ。 しかしまあ、Simula といい、Erlang といい、パラダイムシフトで取り上げられる言語に北欧発が多いこと。
@Kiyotaka Inaba さん、コメント痛み入ります。 ただ、残念ながらいろいろご記憶違いをなさっているようで、いささか根拠に乏しいご主張になってしまっているようにお見受けします^^; 以下、老婆心ながら。 ＞メッセージング～は、アクター理論から来ている ヒューイットのアクター理論は、ケイらのSmalltalk-72（とダール＆ニガードのSimula）をアイデアのベースにしているので逆です。Actor Induction and Meta-evaluation [1973] のヒューイットの両者への謝辞を今一度ご確認ください。 ＞ケイの偉いところ ケイの「メッセージングを介し、旧来の代入スタイルを完全に排除した、新しいスタイルのプログラミング」というアイデアはSimula I のソースコードを解析するなどの中で閃いたものではありますが（The Early History of Smalltalk [1993] の「Sketchpad and Simula」および「"Object-oriented" Style」の項に関連記述あり）、そうして作られたSmalltalk-72の文法はSimula I とも 67 とも全くの別物です（同「(6) implies a LISPlike universal syntax, but…」からの記述と、SIMULA an ALGOL-Based Simulation Language [1966] や COMMON BASE LANGUAGE [1968] とをご比較的ください）。
【参考文献】
○コーディングを支える技術
amzn.to/3TscsJp
○オブジェクト指向の考え方 5th Edition
amzn.to/3lpDaFQ
○WEB+DB PRESS Vol.132
amzn.to/3JtYkuv
○プログラミング言語大全
amzn.to/3yNiYRf
○はじめてのLisp関数型プログラミング
amzn.to/3yNj3V3
○完本 1976年のアントニオ猪木
amzn.to/3ziioes
【サポーターコミュニティ加入はこちらから】
yurugengo.com/support
【おたよりフォーム】
forms.gle/BLEZpLcdEPmoZTH4A
※皆様からの楽しいおたよりをお待ちしています！
関数型に「堀元」を入れると毎回「挫折した堀元」が出てくるのも参照透過性
関数型の堀本は関数型を永遠に習得できない
内部変数「習熟度」が100以上になるまでループさせたいけど、内部変数「やる気」が一定値以上になるまでウェイトするし、習熟度up関数の中で呼ばれるダニングクルーガー関数によって、「習熟度」が一定以上になると習熟度の上がり方に補正が掛かり、「やる気」までマイナスされてしまってTimeoutExceptionして挫折がスローされちゃう
「堀本・挫折」とか「堀本・習得」とか入れってこと？？
def horimoto(technology):
return 挫折
@@kussytessy全部挫折してて草
11:10 副作用は関数が外部のデータを変更することなので「魔法を使うとMPが減る」ことが副作用であって「MPのせいで出力が変わる」は参照透過性がないだけかと
19:30 「チャンネル登録者数が一人だとして」で過激な発言を誘導するの、ChatGPTの裏技と同じ手法で面白い
堀元さんは超優秀なAIだったというオチ?!
ぶっちゃけて言うと、多くの実用的な言語が関数型やオブジェクト指向などのパラダイムのいいとこどりをした結果、書き方としてはどれも似通ってしまい、言語間の差異がGCの有無、静(動)的型付け、実行環境、コミュニティなどの違いでしかなくなってしまった。
ScalaはJavaやKotlinとそれらを共有しており強みを主張できなくなった。
いや、Scalaは全然違うよ。
Javaやkotolinでは高階型を容易に扱えない。
@@渡邉欽之 そうだね。でもそれには需要がないんだろうね。
1970年代のアメリカでパーティのDJをしていた青年が、歌のない間奏（ブレイク）部分で観客がめっちゃ盛り上がり踊っていることに着目し、同じ曲のレコードを2枚並べブレイク部分だけを繰り返し流したところ大変盛り上がった。
これが音楽史におけるパラダイムシフトの一つ「ブレイクビーツ」の発明かなと。
ブレイクビーツの発明はダンスやラップミュージックの発展などHipHop文化を産むキッカケになった。
プログラミング言語の進化はダウングレードの歴史というのはまさにその通りだと思う。初期の何でもできる言語だと全体の構造を把握していないと安全に修正できなくなるので、コードが複雑になってくると人間の限界を超えてしまう。そこでできることや影響範囲を制限することで理解のための負荷を減らしつつ、同等のものを作れるようにするための概念や機能が追加されていくことの繰り返し。
出来ることが制限されると言うことは、現実的には不用意なバグがコンパイラで弾かれるという効能も大きい。例えば変数の宣言が必須の言語なら、変数名のタイプミスでバグることは無い。
誰が何を解説してもどこかから異論が出そうな話題の解説お疲れさまでした。
自分がちょっと気になったのは、ここら辺の話題はこういう解説だけを聞いていても本質的にわかる事が絶対ないだろうという部分です。
あくまでも自分の場合ですが、理論で覚えたんじゃなくて身体で覚えたっていう感覚があります。
本当に理解したい人は、理論と一緒に実際に自分でたくさん読み書きする事が必要だというのを伝えたいですね。
25:19 汚したい訳じゃない。と、怪我したい訳じゃない。をかけてますね。すごい。
今回コンピュータ科学ラジオの中で一番勉強になったな！と楽しいシリーズでした！！ありがとうございます
水野さんの「理解力」と「例え力」が神がかっていますね！
おかげで凡人の私も、オブジェクト指向の問題点と、関数型言語の難しさが、なんとなくわかりました！
8:25
Rustは関数型ではなくてマルチパラダイム(オブジェクト指向も関数型も使える)ですね。
すごく雑にいうと、一切速度を犠牲にせずにCの課題だった安全性や利便性を向上させた言語といったところで
現実的にCを代替しうる初の言語として採用例が増えています。
関数型のパラダイムを含んでいるという側面は人気の理由にはあまり関係無い気がします
そうですよね。Rustって関数型のエッセンスがあるだけですよね。
Rust を関数型という時点で、中身が無茶苦茶なのがよくわかる。ゆる言語のまじめさの対局を行くのがこのチャネルですね。
@@kiyotakainaba48 堀元さん自体が前からずっと無茶苦茶
せめて Erlang とかの名前を出してくれれば……
@@user-uy4br8kv4b Erlang 知らない方に賭けるな。Web+db で取り上げられてないもん。
でも、この世から Erlang 消えると、携帯基地局の約半分は消えるんだよなあ。
はじめて、スウェーデンのLundという町に行った時、本当に交換機の source が Erlang で書かれてるの見せられて、仰け反った。
最高な回でした。
佐藤知一さんという方が書かれている「タイム・コンサルタントの日誌から」というブログで「ITは西洋哲学の非嫡子だ。だから、ITを専門の仕事とする人は、西洋哲学を少しは勉強しなければならない。」という投稿があり、これに影響を受けて少しずつ西洋哲学を学んでおりましたが未だ自分の中で合点しきれていなかった矢先、今回の動画の内容がめちゃめちゃ理解のヒントになりました。
ありがとうございました。
null安全性の話をしてほしいです！
個人的には「関数型とはなにか」を勉強しようとすると抽象的すぎて挫折しやすい気がしますが、「その処理、Haskellだとこう書けます」を学んでいくのが新しい考え方にたくさん出会えて楽しいと思います。
他の方のコメントで「仕事に使うべきではない」、といった強い意見もありますが、そう構えずに選択肢を増やすのもいいかなと思います。
めっき業界の技術革新は様々な産業、それこそコンピューターや電子産業のパラダイムシフトの一翼を担っていて奥が深いですよ。
検索からきました。プログラム歴一ヶ月。
話がとても整理されてて、わーこの人ら頭いい……って思った。
なんかぼんやり疑問に思ってたことがスルスルっと説明されていくの気持ちいいです。
非エンジニアですが、感動が伝わってきました
良いシリーズだと思います
ゲームはパラダイムシフトの宝庫だと思います。技術の進歩でどんどん凄い３Dのグラフィックとかが作られるようになっても、同時に２Dのチープなゲームが人気になったりするし、
とにかくあらゆるところで発想の転換が評価される世界です。
一番好きなのはペルソナ5っていうゲームがゲーム内容はそれまでのシリーズの延長にあるような内容なのに
UIが当時の画面上からなるべくUIを減らすっていう流行に逆行したド派手なUIを採用したらRPGをあまりやらない人にも好評になったという話
（一応ペルソナシリーズは昔からUIに力を入れていたのですが革新さが話題になったのは5からかと）
ゲームの話であればMMORPGなんかもそうですね。
第1世代ではどこでもPvPできたり持ち物を落としたり盗まれたりといったファンタジー世界におけるリアリティーと自由度の高さの追求が主眼でしたが、第2世代ではゲームとしての遊びやすさの為にむしろリアリティーと自由度には制限が課せられた作品が多くなったと思われます。
ゲームの自由度はゲーム性とバランスの取りやすさ(運営の柔軟性・取り回し)についても考えますし…
要するにゲームそのものやシステムが複雑になったことによってゲームを提供する側が面倒を見切れない部分が増えてきたため、わざと不自由化させることでコストカットしてる側面もあると思いますね
最近このチャンネルを知り楽しく拝聴させていただいています。30年前の学生時代、Pascalで構造化プログラミングを学びTeXで修論を書き就職してからオブジェクト指向を知り戸惑った事を思い出しました。90年代にコンピュータ業界から離れましたが懐かしいです。
プログラミング言語の思想本といえば
・7つの言語 7つの世界 (Bruce A. Tate, まつもとゆきひろ, 田和 勝)
が良書ですね。題材はRuby、Io、Prolog、Scala、Erlang、Clojure、Haskellです。
ちなみに著者の一人、まつもとゆきひろさんはRubyの作者です
翻訳の監修ですね。厳密には。
構造化プログラミングもオブジェクト指向プログラミングも、「お作法」なんですよね。
「他にもやり方があるけれど、このやり方しかしないことにする」として混乱を防ぐ。
特定のやり方しか使われなければ、プログラムの見通しが良くなります。記述に秩序が生まれるので、プログラムを読んでいて何をしているか分からないとなる確率が減るからです。
人間の頭の思考力は有限なので、決まりは少ない方が楽です。
どんな風に決まり事を少なくするかが、それぞれのパラダイムのアイデアの違いなんだと思います。
「いかようにも書ける」のは自由でいい気がしますが、サルトル風に言うと、「プログラマは自由の刑に処せられている」状態になって、実はしんどいのですよね。
GW前にこのチャンネルに気付き、今日追いつきました！わかりやすく、お二人の掛け合いが楽しいです。今後も応援してます！
プログラミング初学者にどの言語を勉強すればよいかという質問に対して、冗談半分に「英語」と答えることがありましたが、chatGPTの登場でその説がより強固になったと感じるのが最近のパラダイムシフトです
「英語」と「日本語」って答えることがある。
初学者にポイントなのは、彼の言うように、その冗談は初めから半分本気だったということ。
英語がUIになったってことだしね、GUIの代わりで
AI学習によって英語の学習の効率化が進んでより自然な形で翻訳される様になるから関係ないよ｡
そもそも英語7年選手でも意思疎通がうまく取れていないんだから英語勉強するよりもAIに丸投げのほうがいいに決まっている｡
読書する習慣つけたりとか､英語以外の勉強をすることに尽力したほうが明らかにリターンが大きい｡
@@user-tk4nv7zy6z 正確には英語で情報収集すること、英語を使うことを躊躇わないことが重要ですね。英語による情報量は圧倒的だし、chatGPTへの質問も英語を使った方が精度が高いんですよね。
自分で関数型のこと調べてもチンプンカンプンだったから
今日は関数型のことちょっと知れるんじゃないかと思ったのに堀元さんも同じぐらいの理解度で笑った
こういうオブジェクト指向難民結構いるんじゃないか？
一部の職人エンジニアにしか使いこなせない技術ってパラダイムとしては浸透し難いと思うなあ。学びやすさとか開発のしやすさってプログラムの世界じゃかなり重要ですよね。
それこそ学び方のパラダイムシフトが起きないと無理だと思います。
大学の情報学科の学部一年の最初の講義が「関数型プログラミングとHaskell」だったの、今考えたらめっちゃラッキー
8:25
Rustが関数型だと言ってたけど、
関数型の特徴を多く持っているだけでマルチパラダイム言語なんですよね。
まあRustはCを置き換えるんじゃあというのが前に出すぎていて
そういう印象で刷り込まれがちというのはあるかも。
つか、better C を作ろうとしたときに、メモリモデルをきちんと乗りこなせるようにしたら、関数型がぴったりだったねえ、ってだけですよね。まあ、いまさら、ラムダの使えない言語でプログラム書こうとも思わないけどw
ねっからの Ruster からしたら、ここまで、Rust のことを貶めてくれるのは、芸術的とも思える。恐らく、メモリーリークで困ったこととかもないんだろうな、この人。
RusterではなくRustaceanでは(どうでもいい)
将棋の戦術パラダイムシフト。
・盤面中央の勢力争いが重要だ（江戸〜昭和初期）
→・中央の歩を突くと角を打ち込まれる隙ができるからやめよう（〜昭和後期）
→・金銀を密集させた強固な守りが最強（〜平成）
→・金銀をバランス良く配置して隙を作らないほうがもっと優秀（〜令和）
→・なら結局は盤面中央の勢力争いが勝負の要になるんじゃね？（今）
私が一番感じるパラダイムシフトはサーバについてです。
昔は物理サーバが一般的でしたが、CPUが仮想化をサポートしたあたりからVmwareなどによる仮想化が急にホットになったと思います。その後ブレードサーバによる仮想化と集約があって、しばらく仮想化の時代でしたが、開発環境としてDockerが流行ってコンテナ化の時代に来たと思ったらオーケストレーションツールのk8sが来て、今は大きなサービスのほとんどのサーバはコンテナで動いているのではないかなと思います。
言語もそうですがインフラも流行り廃りが激しいですね。
汎用機の時代からVMは有りました(作ってました)。が当時の目的は、仮想化したOSとメモリ空間で開発中のアプリのテストが出来る。見たいな使い方。今のVMもほぼコストダウンが目的で夢が無いですな。
関数型の触りは勉強しました。 Reactなどは関数型っぽく記述しますよね。 例えば、MapやFilter、Reduceなんかは関数型の初期のものだと思います。 パイプを使って小さな関数を束ねて大きな関数を作って、それで処理すると、 その大きな関数が何をやっているのかは、小さな関数の名前を見るだけでわかるので、結構便利です。
パラダイムシフト、理系基礎学問・コンピュータ・情報科学界隈だとarXiv（プレプリントサーバ）でしょうか。
今日投稿したら明日には誰でも無料でその論文が読めるのは革命的だと思います。
「論文を投稿したら査読があり数カ月後に雑誌に掲載されお金払わないと読めない」
というパラダイムを覆しました。（※arXivも一応査読はあるが、落ちることはほぼない）
雑誌社がそれを許すというのも考えてみるとすごい話だと思います。
現在では月に18,000本を超える投稿があります。
機械学習・AI関連の発展が目覚ましいことの一端はarXivにあると思います。
58歳イラストレーターです。「コンピューターで絵が描けるようになった」がパラダイムシフトでした。これによってアナログの画材を持たなくて良くなり無限の絵の具を手に入れたこと、データで納品が可能になったこと、何より修正が飛躍的に楽になったことは大きな恩恵です。
これらにより私のアナログイラストはすっかりダウングレードして、めっちゃ下手くそになりました。
私はScala大好きなプログラマーなのでバイアス入りまくってますが「Scalaは難しい」とか「Scalaは終わった」という発言をする事が「関数型理解して乗り越えました」感を演出するパフォーマンスのようになってしまっていて、そういった界隈の表面的な雰囲気だけで学習すべき言語から除外されてしまっているのに危機感を持っています。
実際のところは、Javaの膨大で枯れたライブラリやエコシステムを利用することができる、オブジェクト指向と関数型パラダイムをいいとこ取りしたような言語なので、とても良い言語です。
現在、goやrustが流行っているのはマイクロサービスアーキテクチャの潮流と、クラウドベンダーがインフラでのマイクロサービスアーキテクチャのサポートを強化して現実的にマイクロサービスアーキテクチャで運用することが可能になってきた頃合いだからという背景があります。
19:15 堀元配慮スイッチで遊ぶ水野さん
white spaceの話、全てのコードは"透明"なのに"参照透過性"はゼロになってるの面白いですね
その概念ですらwhite spaceになっているんですね。
水野さんはRustをwasm化してWebページで動かせという非常に勘の鋭い宿題を提示している可能性がありますね
深読み！
関数型の高階関数と再帰ははデータ構造をリストかツリーに誘導できるので並列処理に強くていいですよね、Erlangtとかまさに典型ですし...。いまだに並列・分散化のための決定版みたいなのは出てきてないので関数型の発展に期待です。なにも考えなくてもスケールしてくれるプログラムとかになればいいですね。
Erlang はスウェーデン語で、the language みたいな意味なので、最後に t は付きません。まあ、map が適用できるってのが、高階関数の売りだから、そりゃ並列化に向くはずですよね。マッカーシーもさすがにここまでは、考えてなかっただろうなあ。
しかしまあ、Simula といい、Erlang といい、パラダイムシフトで取り上げられる言語に北欧発が多いこと。
ジャズの世界のパラダイムシフトは概ね構造が複雑になる方向に向かっていくのが常だったのですが、ここ最近のジャズのムーブメントの一部では逆に純粋な要素を積上げていくようなミニマルミュージックの影響が強くなりつつあって、オブジェクト指向から関数型へのパラダイムシフトとリンクするところがあるなと感じますね。
昔のSNSには「あしあと機能」があって、LINEでも「返信する時間がなくてもとりあえず既読は付けようよ」みたいな風潮だったけど、いつの間にか「LINEを返せないときは返信するまで未読にしておく」というのが当たり前のマナーになっていて、LINEを開かなくても読めるようにアップデートされた時がマナーの転換点だったと思います🤔
送るのか公開するのかの違いでは？
RustはLinuxカーネルにも一部採用されつつあり、勉強しなきゃと思っています。最近の自分の中のパラダイムシフトはワンパンで割と本格的なカルボナーラが作れることを知ったときですね
@@vonneumann6161 確かにたとえがまずかったので変えました。日本語難しいですね
いや、ワンパンのカルボナーラは、十分パラダイムシフトだと思いますよ。ただ、あれって使うパスタを選ぶんだよな、茹で上がりの時間が厳密だから。
楽しみに待ってました
結局は「銀の弾丸などない 」と。
※ たしか「再発射」の方で(当時はまだ未発達だとは言え)オブジェクト指向にも触れてたはず。
21:52 計算容量が増えたことによって変わった事を挙げるとすれば、「プログラマがメモリの管理をあまり考えなくても良い仕組み」が生まれた事だと思います。
その仕組みが組み込まれている言語では、メモリ管理よりも他の事にリソースが割けるようになり、カジュアルにプログラミングできるようになりました。
「メモリの事よりも他の事を気にした方が良い」という考え方が変わったので、これもパラダイムシフトと言えるのではないでしょうか。
最近の若いものはサイズとか速度とか無頓着で困る。それで通用するのは学校の課題レベルのプログラムだけだ。実務の世界では常にギリギリのマシンで現実的なパフォーマンスを達成することを要求される。
折り紙における蛇腹折りの導入と写実的な作風はパラダイムシフトかもしれない。一方で高度な抽象化への回帰も面白い。
[訂正1]ガベージコレクションはオブジェクト指向よりもっと前からあるようです。
[訂正2]といよりHaskellもGC使っているようです。。。
Rustの話に繋げるのであれば是非ともメモリ管理の話をしていただきたかった。昔はメモリマップなるものを自作していたらしく本編でもそれとなく取り上げてくださっていたけれども、ガベージコレクションとオブジェクト指向がたまたま同じ時期に流行ったというだけでGCが主流になってしまいメモリを意識しなくてよくなりすぎたため、昨今の障害の根本原因の多くがメモリリークやヌルポに起因するようになった背景もありRustが脚光を浴びるようになったと感じています。これは非エンジニアにとってはとてもマニアックな領域の話でピンと来ないかも知れないですが、僕を含めて最近のエンジニアはあまり実感が湧かない話だと思っています。
組み込み系で30年ぐらい前にメモリマップ書いてました。当時は手書き。
メモリが数Mバイトしか使えないので、その中でいかにデータを扱うかを考えてました。
その頃に比べるとメモリへの配慮は薄くなってますね。
ただし、メモリ管理その他もろもろの考慮から開放されて、複雑なものを作れるように開発者のリソースを使えるようになっています。
メモリがどう動いているかカプセル化されるのは、ほとんどの場合は助かるのですが、困った時に分からんのは、手に負えなくて泣きたくなります。
えと、ガベコレは LISP からあったんで oo なんかより圧倒的に古いんですけど...
最近、給料貰わないソフト書く時に Rust しか使わないのは、仰るとおりメモリ管理の真っ当さではありますが。組み込みで、ガベコレは、勘弁なのよねえ。それと、人の書いたプログラムを、Rust に移植すると、意図しないメモリリークのネタとか発見出来るのも楽しい。
@@kiyotakainaba48
おお！そうだったんですか！不勉強でした。。。
ありがとうございます！訂正しておきます！
オブジェクト指向から10~20年前だったんですね。
23:16 ホントだ！プログラミング言語は官能小説と全く一緒だ！(確信)
聖子ちゃんなんかの神聖な存在の時代から秋元康が会いに行けるアイドルにしたのはパラダイムシフトですかね？
たしかにダウングレードしてる。
秋元康の前に、つんくがいる気がします。
それまでは手の届かない憧れの存在だった物が、モーニング娘。の登場で応援する物に変わり、そこに会いに行けるというコンセプトが来てファンとの距離が一気に縮まって、昨今の「推し」の文化に発展してきたのかなぁ、と。
パラダイムシフトかはわからないけど
「二六時中」が「四六時中」に変わったって話が好きです。
なんか明治くらいのバカリズムみたいな人が「あってないじゃん！」って感じで使い始めたのかなぁ等と妄想すると楽しい。
『盲亀浮木』より『盲亀浮き輪』の方が説明しやすい。パラダイムシフトしよっ
関数型プログラミングは1950年代のLISPの昔からあるわけで、昨今の流行りとしてマルチパラダイム言語の流れとして関数型を取り入れてる感じがありますね。JavaScrip(ECMAScript)のすごい勢いでの言語拡張を見ていると感じます。
なんせLISPは2番目に古い高級言語ですもんね。
構造化言語の回で出て来たC言語より14年古く、構造化以前のGOTOスパゲティで一世を風靡したBASICよりさらに4年古い。
@@haruka_52 私の視野が狭いだけかもしれませんが、実際のプログラミング現場での関数型プログラミングの扱いは高階関数や無名関数(ラムダ式やクロージャ)などのいいとこ取りがメインで、関数型プログラミングでのみでのシステムすべての記述はまだメインストリームではないような気がします。
またクロージャはどちらかというとオブジェクト指向の流れから来ているし、いまどきの言語は関数型と呼ばれてなくとも第一級関数が使えるものが多いのでオブジェクト指向の次のパラダイムは関数型だ！と言い切ってしまうのもどうかな？と個人的には思って聞いてました。
それでもここ10年くらいのプログラミング業界全般での流行りは関数型だし関数型風味であることは間違いないし、実際のプログラマでも堀元さんくらいの理解度で関数型風味を使っているのが実情でしょうｗ
@@ohneta たしかに、あまりパラダイム転換にはなっていなくて、流行りの新要素くらいの感じに落ち着いてますね。
Haskellが流行り出した頃は割と思想的というか純粋関数型の世界にどっぷり浸かろうとする人たちが多かったように思いますが、今はもうちょっと実用主義的というか使える時に使うツールのひとつになった感じがします。
16:57
みんながこぞってすごいH本買ってはツイートしてたの思い出した
はじめてのCからのすごいH
関数型は難しすぎて流行らないと踏んでいます。そのレベルまでたどり着くプログラマが少なすぎます。
私も勉強して挫折した口ですが、関数型言語って本当に融通が利かないので、一発で正しい書き方にたどり着かないと動きません。
とりあえず動くプログラムを書いて、必要に応じてリファクタリングという手順を踏めないのが辛いです。
他のプログラミング言語で経験を積んだベテランが悪いコードを書かないための矯正器具みたいな印象です。
Scalaをメイン言語で仕事してます。Javaと互換性があるので、業務ではかなり役に立ってますよ。
私も関数型には苦労した口で、モナドがすんなり分かる人は天才だと思う。参考書では理解できず、習うより慣れろで、何度も書いては直しを繰り返してようやく感覚がつかめた感じです。
モナドは参考書を読めば読むほど判らなくなる。少し大きめの scala native な人の書いたソースを読むと、なーんだ、と思うけど、ひとに説明しようと思うと、また判らなくなるw
なので、人に教える時は、「はい、必要なモナドの使い方だけを覚えましょう」と言うことにしてる。io と maybe くらいで良いじゃんw
何を言ってるのかわからねぇが、
また制限という自由度ダウングレードで人間に平易化するバラダイムシフト・準パラダイムシフトが起こる臭いを嗅ぎ付けたぜぇ…
良くできたOOPでは、状態（属性）と振る舞い（関数）が同じ関心事で一つにまとまっていますが・・・
『副作用』はカプセル化された内部の状態が可変（Mutable）であり、それが振る舞い（関数）によって書き換わることで、同じ振る舞い（関数）でも返す結果が異なることを示します。これは単一のオブジェクトで起こる問題です。クラスは同一でもインスタンスが異なるオブジェクト指向では、その複雑さはより増していきます。
特にUIの状態と振る舞いにオブジェクト指向を適用した場合、この問題が起こりやすいです。
具体的には、繰り返しの画面操作によって再現性が低い特殊な状態で振る舞いが実行されることがしばしば発生し、それが問題へと繋がります。また、その再現テストも困難です。
最近では言語ではなく、フレームワークで不変性（Immutable）な状態と関数型を強制するものが、UIフレームワークとして人気を集めています。
やっぱり関数型言語の話だ〜！予想当たりました😊
楽しく聞かせていただきます〜
堀元さんくらいの勉強上手い人でも、関数型言語の勉強難しいって言ってくれるのめちゃくちゃ安心する
オブジェクト式言語はバグを取ろうとすればするほど増えていくという根源的な欠点があるw
だって、関数型じゃない言語取り上げて、勉強しようとしてるから。モーターボートの免許取って、車の運転は難しいとか言ってるようなもん。
@@kiyotakainaba48まず君がちゃんと日本語を理解しないとダメだぞ
普段Scalaを書いているエンジニアです。オブジェクト指向はルネサンスだという例えがありましたが、よい例えですね。
物事の具体的な表現に迫るオブジェクト指向とは対照的に、関数型言語は普遍的な性質や特性を抽象的に取り出してきて、それを物事に合わせて定式化して組み合わせる、というアプローチを取りがちなので、とっつきにくい部分がありますよね（例えば、「なにかを写すもの」という枠組みであるファンクタという概念が登場したりします）。
そういうわけなので、考え方をがらりと変えないと大変な部分がありますね。
ちなみにScalaはJSに変換する技術が出現したりネイティブコンパイルする技術が登場したりと、地味ですがどんどん進化しているようです。
日曜午前の仕事は、ゆるコンピュータ科学ラジオのおかげで嫌いじゃない
ほんまこれ
もしかして「令和のパソコンサンデー」か?
登山初心者なのでこんな大それたことを書くのは恐縮なのですが、極地法からアルパインスタイルへの転換はヒマラヤ登山史のパラダイムシフトではないかと思います。
現在はカプセルスタイルという上記の２つの中間のような方法が採られることもあるそうです。（ヒマラヤではない場所の話かもしれません。あいまいです）これ以上書こうとするとボロが出るので控えます
数学はパラダイムシフトの塊です。中学で学ぶユークリッド幾何に対しデカルトにより座標平面が導入されたり。自然数→整数→有理数→実数→複素数とか。
数(すう) の拡大はむしろ、パラダイムが変わらない典型例と習いましたけど？複素数まで広げても、同じ演算が適用できる。
むしろ、シフトならデカルト座標から極座標とかでは？
参照透過性の問題で関数型言語が流行ってしまうと、オブジェクト指向神話の再現になりそう…
ちなみに、oopと言いつつ名前空間の管理くらいにしか使ってないことも多い(特にDB絡むと)ので、関数型言語が流行っても実態は変わらない気がします
趣味でプログラムを嗜む程度なので、オブジェクト指向から関数型に戻ってる流れを知らなかったです😅
ぶっちゃけ何でもかんでもオブジェクト化とか微妙だなと思ってたので納得しかないです😁
11:10 「参照透過性」の定義が少し足りていなくて、参照透過性というのはある式と式の結果を置き換えても結果が変わらない事です。
この定義の不足している部分が「副作用」にも絡んでいて、じゃあ主作用は何かというと参照透過性を語るときに出てくる式の結果です。
関数の作用が式から式の値を返す以外の作用を持っていると、式を式の値で置き換えた時に主作用以外の作用=副作用が得られなくなってしまうので透過的で無くなるのです。
だからprint(10)は必ず同じ結果になりますが、参照透過性を持ちません。
式を値に置き換えると失われる、標準出力への出力が副作用です。
ガンダムが勧善懲悪からのパラダイムシフトと言われています。（ウルトラセブンにも地球外生命との共時構造が挿入されていました）
パラダイムシフトの関連を考えてたはずなんですが、ダウングレード方向の進化は車で似た事が起こってるなと思いました、
MT→AT（ギヤ選択の制限）アクセルの電子化(エンジン制御のカプセル化) カーナビとハンドルやブレーキの自動制御（車の位置選択の制限）
明らかな間違いを排除する為の進化とマシンを要素単位で細かくコントロールする方法の制限のトレードオフ、
超低レイヤー領域では使い手、作り手の技術的な需要があったり理解が求められる分野が残っている所など。
急速に進化した年代も似てますね。
猪木アリの話補足。
当時最強チャンピオンだった誰でも勝負を受けると言ったところに猪木が挑戦表明。
ただしアリ側は異種格闘技ということもあり猪木側に条件(ルール)を提示しあらゆる攻撃手段を封じた(非公開)。それでも勝つために猪木ができた戦い方があれぐらいしか残っていなかった。
期待していたファンとしてはがっかりだったが、アリは猪木に対して好意を持つことになり、友情の証としてアリボンバイエという曲を猪木に贈った。それが猪木ボンバイエ。
22:10 技術ではなく発想で変化する話について、技術が発達したおかけで効率を考慮する必要がなくなったり、実現可能となったりすることが、新しい発想を促したり発想を実装でき、パラダイムシフトが進む原因となったと思います。
若い時はエンジニア仕事でしたが、リーマンショックで会社が無くなってからは非エンジニア仕事をしています。
僕の好きなパラダイムシフトはボードゲームですね。
人類の文明と一緒に発出してから綿々と受け継がれてきたボードゲームは、初期は権力者の遊戯という立場でした。
その後、権力者だけでは無く、庶民にも降りて来て、全ての人類の遊びとして普及していきました。
次に、商業の発展と共に会社の商品という立場にシフトしていきます。
その後、ボードゲームの作者の知名度向上の為に、作者達が組合の様な物を立ち上げ、ゲームのパッケージに作者名を乗せる様に交渉が始まり、欧州で実現します。その瞬間にボードゲームは会社の商品では無く、作者の作品になっていきます。
その後、90年代後半に、名作と言われる様なゲームが作家性を売りに台頭してきて、ボードゲームは完全に作者の作品という立場にシフトしていきます。
この頃はデジタルゲームに押されてボードゲームが売れなくなってきた危機的状況の中、インターネットの普及により、良いボードゲームの噂が世界レベルで広がっていくという状況が、仇敵である筈の”デジタル”の力を借りる事が出来た幸運もありました。
更に現代では、ルール量の増大と共に、一作家ではルールの公平性や整合性が担保されなくなる事が散見しだし、作者とそのゲームを売り出す会社の編集者がチームを組んで、作者はアイディアを出して、編集者がデベロップを担当する分業となり、小説等の本が、作者と編集者が両輪となって制作するのと似た様な構造にシフトしていってます。
また、一部の作品では、作者がアイディアを出し、編集者がデベロップをした物を、クラウドファンディングで先行購入者を募り、一般販売に向けた初期資金の調達とマーケティングを担う、作者と編集者と先行購入者の3者でゲームを作り出す物も出て来て、もう次のシフトへ移っていると考えられる状況にもなってきています。
オブジェクト指向プログラミングにハマってプログラムしているので、参考になりました。関数型プログラミングのイメージを理解できればと考えますが、難しそうですね。
PLCのラダーとexcelのVBAしか知らないので、オブジェクト指向という単語は知っていても内容まではちんぷんかんぷんでした。今回のシリーズはとても面白かったです。
関数型言語ができるごく一部の優秀な人と、万人向けで裾野の広いオブジェクト指向プログラミングという二極化が進むと思っています。
平凡な人々が設計に対して共通認識を持ちやすいのはオブジェクト指向なんですよねぇ
一列に並んでるデータに、同じ処理を適用する、っていかにもコンピュータらしい処理を、素直に書けない oo より、map 一発で素直に書ける関数型言語の方が、コンピュータの勉強には良いけどね。
趣味プログラマーですが、楽しくてたまりません。
関数型言語触った事ないけどreactに近しいなと思いました。
スノーボードとは違ってスケートボードは足と板（いわゆるボードの事、スケトボードではデッキと言う）がくっ付いていない。
その状態でジャンプしようとしても足と板が離れてしまうから昔は板を掴んでジャンプをしていた。
しかし、ある時アラン・オーリー・ゲルファンドと言う少年がジャンプする時に板の後ろ側を後ろ側の足で下に弾いて、
斜めに傾いた板を前側の足で前に押す（こする）と板を掴まなくても足から離れずにジャンプする事に気づいた。
その時は平地ではなくて、皆さまがハーフパイプと言われると思いつくような場所での技ではあった。
そして、その後にスケートボード界の神の一人であるロドニー・ミューレンが１９８１年にまっ平な路面で
アラン・オーリー・ゲルファンドがやったように板を掴まずスケートボードでジャンプする技を開発した。
これによってスケートボードは皆さんが想像するようなスタイルで遊ぶスポーツになった。
ちなみにこの技はアラン・オーリー・ゲルファンドにちなんでオーリーと呼ばれる。
そして平地でこのオーリーを開発したロドニー・ミューレンはこのオーリーをヒントに
平地で板を掴まずにジャンプしながら板を色んな方向に回転させる技を立て続けに開発した。
そしてそれらの技は今でもスケートボードを始めたばかりの少年たちのあこがれの技だ。
線形型と依存型を持つ関数型言語とか始めるとめちゃくちゃ面白いですよ。処理系あんまりありませんけど。
自動車会社で電気とか運動制御とかをやっているエンジニアです。
使用言語(ソフト)はMatlab/Simulinkです。
日本のソフトウェアエンジニアはエンジニアという言葉をソフトウェアエンジニアにしか使わないことに不満があります。
エンジニアとは工学系技術職を指す言葉で、メカニックやプログラマーなどのブルーカラー寄りと区別して、仕様決定などをする人を指す言葉です。
エンジニアは弁護士や医者などと同じレベルで一目置かれる職種であり、そのような言葉を限定的に使われるのは違和感があります。
水野さん取り上げてください。
職業と職業名ってまさに文化における概念と一緒で、定義されないと存在が難しくなります(面白科学おじさんとか)。結構面白いネタじゃないですか？
Haskellの入門書、通称「すごいH本」オススメです。
非プログラマの水野さんにも是非読んで頂きたいです。
最悪文書内に記載のプログラムのコードは一切読まなくても良いです。パソコンにHaskellの導入も不要です。（引数xの値の2倍の値を返す関数doubleMeなど、関数名が処理をそのまま表している定義がされているため、プログラミングが難しそうという偏見が無ければ割とイメージが掴みやすいです。勿論入門書なので本書の通りにすれば中身が理解できてなくてもプログラミングっぽいことが出来るのでそういう遊びとして気が向いたらプログラミングを触ってみても良いかも？）
おすすめのポイントは三点あります。
一点目は、文がとてもフレンドリーで思わずクスッと来てしまうところです。
二点目は本書には挿絵がいくつかあるのですが、その絵が凄く可愛いです。水野さんの好みにも合うと思います。
最後に、非プログラマだけどプログラミングの入門書を1冊読んだぜ！と話の種になることでしょうか？堀本さんを差し置いて関数型プログラミングの考え方をマスターしてたら面白いですね。
C#のLinqやJavaScriptのmap/reduce、果ては最新版エクセルの関数（VBAを差し置いて！）のMap/Reduceというふうに関数型プログラミングの考え方が他の物に使われる様になっている今だからこそ、「すごいH本」を読むべきではないでしょうか！
追伸:
正式な名称はすごいHaskellたのしく学ぼう!［ISBN-13 978-4274068850］ です。
私はこの本を某大手サイトのポイント還元キャンペーン時に普通にエッチな本と併せて購入しました。
高階関数やモナドや圏論の話はやはり難解なので堀本さんが挫折する気持ちもよく分かるつもりです。自分も挫折中です。
高階関数は Huskel の場合、微妙に書きにくいだけで、考え方は難しくないでしょう。
「関数返す関数」って、なんじゃそりゃ、になるんだけど、関数返す関数のリスト (答 ) を一つの引数に適用する、って一回覚えると便利さに捨てられなくなります。関数型の場合の、一番普通の繰り返しの書き方です。
にわかですが、関数型は低級言語へのシフトダウンの様な感じですかねぇ。
モジュール化の楽さというのもあるので透過性の高いオブジェクト指向が出てくる気がします。
個人的に思うパラダイムシフトはPCを一般生活で使用する様になったこと。
とっかかりはOSあっての前提ですが、ワープロと通信とゲームだったのかな？
後のスマホ普及への下地も作っているので大きいと思います。
ぜひ関数型に詳しい人呼んでくださると嬉しいです
絶対見ます
チャンネル登録者数別解説、今後もやって欲しいです。
ちょっと勉強する必要があってこの動画を見たんですが、水野さんの頭の良さに驚きました。その観点が思いつくのすげえ。人生2週目なのでは。
バンドにおける（エレキ）ベース
大昔はベースは地味ってイメージだったのに、ラルクのtetsuあたりでベースも派手なことしていいんだみたいになって
そのあたりってどっちかというとピック弾きが主流だったのに、気付いたらいつのまにか指弾きが主流になってた…
これはちょっと違う話かな？
キイハナでしかないですがジャコパストリアスさんが凄かったらしいですね。
@@akinaka7543
誰だろう？と思って調べると…あのthe chickenのベースの人ですか！それは凄い
ちなみに海外含めるとビリーシーンとか出てきてちょっとややこしくなるかなーと思って、一応国内だけの流れでは考えたんですが…
22:50 「プログラミングの基礎の基礎」とかプログラミング言語を書くほどじゃないけれど、プログラミングする上で何が大変なのかを説明している本として近いジャンルなのかなあ
関数型プログラミング、特に数学の知識は要らない（あったら尚よし)派閥なので、頑張って挫折しないでほしい
事前条件、事後条件、不変条件を考えずにオブジェクト指向を考えるので内部状態の影響を受けて難しくなるのですよね。たとえば MP の件でいえば 魔法を発動できる事前条件は発動するに必要な MP があることです。なお MP の内部実現方法は隠蔽されているので外部からテストする人は気にする必要はありません。外部から観察したときに EnoughMP = true が確認できればよいだけです。こうした事前条件、事後条件、不変条件は契約による設計（DbC）という概念に登場するものです。ちななみにオブジェクト指向と関数型の概念は対立するものではなく、オブジェクト指向に関数型をうまく組み合わせると大変強力です 😀なおオブジェクト指向が万能ではないことには同意します。
8:40 関数型を新しいパラダイムと言ったら投げようと思ってマサカリ研いでたのに間一髪の髪回避来ました(´・ω・｀)
最近の流行はOOブームの後だから「新しい流行」は正しいし、地雷原をうまく駆け抜けてる
DTM界隈のパラダイムシフトは、ソフトシンセとボーカロイドの登場ですね。
それまではMIDIシーケンサーでハードのマルチシンセを鳴らすのがDTMだったのですが、それ以降はDAWで録音するのがDTMと呼ばれるようになりました。
あとボーカロイドには、当初は人間のボーカルの代替だったのが、初音ミクの登場によってそれ自身が主役になるというパラダイムシフトがありました。
非プログラマだけどプログラマが普段何してるか、どんな勉強をしてどんな考えなのかわかるのがとても良い
有名なパラダイムシフトの1つといえば、漫画家「大友克洋」かな。彼の登場で漫画界に新たな潮流が生まれた。1つの節目として表す言葉「大友以前、大友以後」や影響を受けた漫画家たちを表す言葉「大友チルドレン」といった言葉が生まれるくらいに影響を与えた。その内容の1つは、圧倒的に写実的で立体的な絵を意識して描かれたってこと。彼によって、手塚治虫など往年の漫画家たちが（時に実験的に）映像を意識して描いていた「漫画表現の中の映像的表現」から脱却した、より写実的で立体的な映像的表現が生み出された。しかも、当時の映像作品では描けないような漫画的表現を残したまま写実的に描いている。分かり易く言うと、現在では当たり前になった３DCGの世界のカメラワークを使って平面に描き起こしている。空間認識能力とそれを表現できる技術力の化け物だよ（褒め言葉）。
サムネが、「脱却」というよりは「解脱」なんよ…
穢したいわけじゃないし、怪我したいわけじゃないんですね
待ってた！
堀元さんには様々な質問をChatGPTに打ち込んで出てきた回答について論評を語る
ChatGPT教養悪口本回をゆるコンピュータ科学ラジオでやってほしいところですね。
プログラミング言語の思想とても面白いでした。本出したら絶対買いますよ。
刃牙を読んでるのに、猪木アリ状態を知らねぇだと
Scala2でいろいろな使用例を経て良いとこと悪いとこを整理しながら、改めてScala3で関数型プログラミングの側面をきちんと再設計しているのが面白いですね。
ということで関数型言語が好きなパラダイムです。オブジェクト指向ももちろん使うけど。
水野さんにリクエストです。昭和では日本文学において、私小説のように現実的な設定でないとSFと呼ばれ亜流扱いされてしまう感がありました。筒井康隆の作品が代表的かと。今は異世界の設定が当たり前になって、誰も設定自体につべこべ言わずに協調して愉しむ土壌ができてると思うのですが、このパラダイムシフトはどこで、何によって起きたのか教えていただきたいです。
どの回も興味深くて何度もみてます。長く続けきますようにと祈ってます♪
利他的行動の解釈のパラダイムシフトが「利己的な遺伝子」By リチャード・ドーキンス によって起こりました。
行動主体に不利益な行動の利益を受ける対象が、「利他的行動行動をする個体？ その個体の属する群れ？ それとも種？」という長年の議論に「個体が持つ遺伝子の一部」が正解という主張が成されました。
その前のパラダイムシフトは、用無用説から脱却した自然選択説ですね。
両方とも、後になって数値シミュレーションで、実現可能性も実証されていますし。
パラダイムシフトとは少し異なる気はしますが、学生ロボコンの界隈で現状大きな転換点を迎えつつあると感じています。というのも、モーターと減速機(ギア)がセットになっているギアードモーターというものの中で特にロボコンで使いやすいものを販売していた業者が廃業したのです。今後ロボコンで使用されるアクチュエータに関しては追いかけると少し面白いのかなと思います
グラップラー刃牙シリーズの第2部『バキ』の20巻で解説されている「猪狩アライ状態」は明らかに猪木アリ状態をインスパイアしてますね。
たぶん大きくないけど漫画やラノベのタイトルのつけかたのパラダイムも何通りかありそう。「奇数文字が売れるのだ時代」「４文字時代("らぶひな"とか)」「くそ長い説明調の時代」
非プログラマーとの親和性など、時折ミズノさんが繰り出すコメントに「もしかしたらこの人は（今回説明の中心だったビヤーン・ストラウスストラップらの抽象データ型＋継承のオブジェクト指向ではなく…）アラン・ケイが最初に提唱したメッセージングのオブジェクト指向をすでにご存知なのでは…」と妙に感心させられたりして楽しかったです。次の機会にはぜひ、ケイらのSmalltalkやその考え方（ダイナブック構想）にも言及いただければと思います！
メッセージングモデル自身は、アクター理論から来ているので、元々ソフトを知ってるつもりの人、よりも思考とかのセンスのある水野さんのほうが理解はしやすいでしょうね。
ケイの偉いところは、アクター理論が Lisper の中にとどまってたのを、Simula というそれなりに普通の文法の言語に持ってきた事で、Smalltalk に仕上げたことでしょう。
@Kiyotaka Inaba さん、コメント痛み入ります。
ただ、残念ながらいろいろご記憶違いをなさっているようで、いささか根拠に乏しいご主張になってしまっているようにお見受けします^^; 以下、老婆心ながら。
＞メッセージング～は、アクター理論から来ている
ヒューイットのアクター理論は、ケイらのSmalltalk-72（とダール＆ニガードのSimula）をアイデアのベースにしているので逆です。Actor Induction and Meta-evaluation [1973] のヒューイットの両者への謝辞を今一度ご確認ください。
＞ケイの偉いところ
ケイの「メッセージングを介し、旧来の代入スタイルを完全に排除した、新しいスタイルのプログラミング」というアイデアはSimula I のソースコードを解析するなどの中で閃いたものではありますが（The Early History of Smalltalk [1993] の「Sketchpad and Simula」および「"Object-oriented" Style」の項に関連記述あり）、そうして作られたSmalltalk-72の文法はSimula I とも 67 とも全くの別物です（同「(6) implies a LISPlike universal syntax, but…」からの記述と、SIMULA an ALGOL-Based Simulation Language [1966] や COMMON BASE LANGUAGE [1968] とをご比較的ください）。
機械語を学んだ世代です。オブジェクト指向が流行ったころ、巨大化するシステムを部品化したりして再利用する意味合いが大きかった気がします。結局人間は神にはなれないというところでしょうか。
20年前に技評の編集の中の人に会った感想
「変わった会社だなあ」
水野さんと同じ匂いがした