Functional Programming: a New Way of Programming - the Basics

影片中使用的Icons: www.flaticon.com
插圖來源：www.irasutoya.com/
B roll來源：envato elements
0:00 Intro
3:57 Pure Functions
6:15 Immutability
8:31 recursions over loops？
10:59 imperative vs declarative
14:57 more advanced concepts!
15:35 Questions about FP
19:29 is FP better than OOP?
23:21 Ending - my story with FP

[@james-kool]

滿多人問關於遞迴的效能問題，FP語言通常有tail call optimization可以處理這問題： stackoverflow.com/questions/310974/what-is-tail-call-optimization zh.wikipedia.org/zh-tw/%E5%B0%BE%E8%B0%83%E7%94%A8 這未來我會做一集影片講，如果有興趣可以看一下上面這篇。基本上只要使用tail recursion，那遞迴跟使用loop編譯出來的東西是一樣的，不會有效能差異。（如果非FP語言，不一定會有這個保證）

[@nanman_chief]

各位有興趣的話，可以看看學界新的東西，比純粹 TC 更先進的做法，可以參考 Perceus: Garbage free reference counting with reuse 跟 Tail Recursion Modulo Context 這兩個文章，包含記憶體空間重複使用，所以微軟的兩個實驗型程式語言 Koka 跟 Lean 4 的紅黑樹跑得快跟 C++ 差不多快，卻不用寫任何回收，不過目前這項研究的缺點有判別不了外部造成的循環引用以及 RC 會有鎖這兩個問題。Algebraic Effects / Effect Handlers 也能理解一下，很多人嫌 FP 的 Effect 難寫 (Monad ..)，不過 Effect Handlers 確實解決了這個困擾，當一般用 Koka 的時候甚至會覺得用起來跟普通的指令式語言差不多。但是實驗性質的語言到實際能被接受運用，都是很漫長的路 ((遠望

[@schiang]

真的很感謝有大佬們不斷的研究以及實作各種最佳化手法，軟體工程師才能有更人性更好用的語法可以用

[@user-ny8qv9ze4d]

然后现实还是有很多recursion都没办法转成tail recursion

[@johnlin7439]

immutable + declarative 使得 FP 程式可以極大化平行處理。因為 declarative，任何大的運算都可以拆解成小的子運算，複雜的運算就可以分派給一百台電腦去執行，每台電腦又可以拆解給 128 核 CPU 去執行；加上 immutability，每個被拆解的子運算都不必參考到外部的變數，因此子運算之間都無須交換資訊。這樣拆解分派（map）再彙總得到結果（reduce）的運算模式很需要程式設計師先把問題用 FP 定義清楚

[@johnlin7439]

9:40 基於上述觀點，recursion 只是描述大運算如何拆解成子運算，子運算不一定要暫存在 stack，也可以傳給其它電腦或是多核 CPU 來平行計算，效率會大幅提升

[@testyoutubetest5910]

同意，fp 最大好处是，数据局部化，利用stack局部化数，没有全局数据，可以乱序或并行执行函数，得到一致的结果。一句化fp，是一种利用stack将数据局部化的方法而已。它只是一种对分布式友好的算法。有些地方如前端人机界面，用不上分布式，fp就显得画蛇添足，或自己画地为牢了

[@user-vn4jw3ch8w]

能真正做到fp 的要有很強數學和算法根基

[@aetheruszhou1526]

能用 map-reduce 来平行处理的运算必须至少满足结合律（associative），最好也能满足交换律（commutative）。某些运算（比如求中位数和 percentile）就不能用 map-reduce 解决了。实际工作中总是碰上这种需求😂

[@samho321]

FP 和 OOP 我是混用的，FP 主要用在顆粒和小型和常用和很好預知的地方，如format/convert/generate，OOP 主要用在處理複雜和上下文和鏈式和比較動態和抽像的地方，如parser/connector/validator。 重點是不論創建fn或class之前，要先想清楚日常怎樣去用這個東西，好不好用直接決定項目的DX(開發體驗)，好的DX往往都有好的維護性

[@pishen]

太精采了，很多觀念都講得簡單扼要，是很好的推坑素材，期待之後的影片！

[@mamuwu7873]

而且者整個影片的架構節奏個人覺得都掌握得很好，真的值得一個大大的讚！ 補充：Paradigm 從我比較熟的傳播人機互動領域好像都是翻成典範

[@yojaychang]

講解的很不錯，不過有些疑點： 1.當程式不再touch記憶體，指標，暫存器，那這個程式無法像C那樣成為很大程度的通用程式，比如無法開發作業系統(unix，android等)，驅動程式等。 PS.之所以會這麼問是因為程式語言百百種學不完，但只要掌握C(C++)，幾乎就可以做出所有運用(作業系統，驅動程式，網路程式，資料庫(如Oracle實作)，各種遊戲，各種桌面應用程式等)，不用再學其他第三代語言了。 2.介紹OOP的特點都不是OOP的重點(反而是結構化程式設計的特點)，因為非OOP的程式也都存在for loop(比如C)，OOP的重點觀念是在封裝，繼承，多型...等等，以及其演化出的design pattern。我意思是for loop，mutable不是OOP的本意(應歸於結構化程式設計)，OOP應不與FP衝突。

[@donkeystan]

寫C的人一看你的留言就很有感XD

[@user-tx5dh5gg2j]

推

[@lzh97]

1. 理解機器模型很重要，夜路走多了總有一天會碰到，所以學 C 跟組合語言都是重要基本知識。新的程式語言概念對老的語言會有幫助，像是先學 Rust 的人再學 C，用指標的時候腦袋可能會比較清楚，因為以前被 Rust 編譯器罵過幾百次了。然後 C 語言也有一些 lib 是從新語言的概念來的，像是 Glib 的 GObject 物件系統。還有 mimalloc 同個作者做的 libhandler，是從 FP 語言的 algebraic effect 來的，可以用來做 exception 跟 coroutine 之類的控制流 (底層就是包裝過後的 setjmp，但比赤裸的 setjmp 好用)。 2. 確實，像 Erlang (分散式純函數式語言、以前北歐電信業系統用的) 也喜歡說自己是 OOP 語言 XD 不過多型對 FP 跟 OOP 來說都是核心特性，高階語言之所以高階就是

[@RockyDong]

嗯，很有道理。其实FP的很多概念内部都是用 OOP 来实现的，例如 Functor，Monad。

[@q19950129]

很清楚的解說~對我這個Rust初學者很有幫助，期待下一集

[@user-jc5kq6nd7o]

簡單易懂的教學影片，讓我有興趣看完外，對於學習之前從未聽過的概念也不會有負擔！

[@chengyang1380]

太優質的影片了，內容言簡意賅，舉了許多簡單的小例子，很容易理解，感謝分享 🎉

[@user-mineke]

不知不覺就聽完，講解清晰流暢，受益良多，感謝~

[@kuo2322]

謝謝 James，影片的節奏很好，期待後續有更多 FP 的影片 🙏

[@drew-lee]

這系列太棒了🎉🎉 期待Functional Programming 各種後續

[@lchang2422]

加油~~ 期待您之後實驗探索的心得分享😊😊

[@sinshiu919]

非常棒的說明 含金量很高 謝謝說明長久以來對於fp 的一些疑問🎉

[@wmiyu5163]

之前瀏覽過相關文章，覺得一知半解。這部解釋的超好，非常感謝🙏

[@TigerTiger-gb1xn]

很高興演算法推薦我這個影片. 影片講得很不錯. 我在北美也寫了大概快九年的 FP. 但是這裡我想要就 immutability 平反他 deep copy 複製耗費的問題. 就 List 而言,要避免 deep copy. 其實只要搭配 Pattern Matching 跟 decomposition 的方式 來達成 "Data Sharing": 這樣可以 reference data 來重新建構 List (reconstruct the list without deep copying data). 有關計算能力的問題. FP 更是在 Lazy Evaluation 上體現了他的強大. 我們可以透過 Lazy Evaluation 達成 By Need Evaluation. 優雅的解決 Streaming 的問題. 關於利用 compiler 這點. Type Class 可以變出許多魔法. 但是,這也是最強大跟爭議的地方. 我覺得 FP 的語言本身沒問題. 但是 ecosystem 比較要考慮. 譬如: 每家 Cloud Provider 都有 Python, Java 的 SDK. 但是沒有 Haskell 跟 Scala 的. 還有某些特定 Database 或 Cache 的 Driver 通常要仰賴 open source. 其版本的更新也可能比較慢. 另外 FP 的 project 很難找到 軟體工程師. 純 FP 工作也較少. 要做 FP 的 Project 最好是到 FP shop (以 FP 為主的團隊或公司). 否則後續維護會發生困難(如果找不到程度相當的工程師接手). 盡量適度使用 FP 而不要過度使用黑魔法. 但是 FP 的能力通常會幫你找到比較有挑戰性的大型系統 project.

[@ShaneIsNotMyName]

非常棒的影片！ 解决我对FP效能的疑惑！

[@charlottehong1276]

關鍵可能在於現代編譯器不同於以前的編譯器，FP的那些看似浪費效能的寫法實際上正好是可以被優化的 如何在超高階語言的便利與效能間銜接，這可能是個很好的解法 用事先約定好的特定暗號(FP)，讓編譯器可以優化超高階語言的邏輯 對於讀寫代碼的人說，因為是特定暗號其實只要學好了記住了閱讀也不至於太卡 舉那個迴圈的例子來說，雖然C++會優化簡單for迴圈成"一個值"，但是要是裡面多塞東西，編譯器也拿你沒輒沒辦法直接編成"一個值" 照這邊影片所說的，可以寫成遞迴的可能就代表他可以等於"一個值"，也就是上面提到的這是一個約定好的暗號，代表這個區塊他是"一個值" 這真的是個很厲害的發想。

[@techpo6556]

學習了，感謝製作！期待後續！

[@ilovelctr]

订阅James好久了，又是一支超棒的影片，深入浅出，好喜欢！

[@buvnypb]

"Clean Architecture: A Craftsman’s Guide to Software Structure and Design" part II mentions > Structured programming is discipline imposed upon direct transfer of control. > Object-oriented programming is discipline imposed upon indirect transfer of control. > Functional programming is discipline imposed upon variable assignment.

[@ryanzhouff]

非常棒的视频，学到了关于函数式编程的许多概念，感谢分享

[@linisacwu6163]

終於看到國內有工程師來介紹FP了👍 其中一個很有名的語言是Haskell 很喜歡這種把程式設計思考為數學函數的感覺

[@philiphsinh9214]

好喜歡你的講解，通俗易懂！

[@lilylily6123]

影片的質感越來越好了

[@user-fr2jr6hd4i]

加油，請繼續製作這個系列的其他影片，謝謝

[@lzh97]

我覺得 FP 永遠都在做 "依賴注入" 跟 "組合" (原諒我拿OOP設計模式的名詞來比喻一下)，在 FP 寫程式幾乎所有東西都是純(無副作用的)的，至於不純跟需要變化的東西，就留一個 "洞" 在那裡等著最後由依賴項填補。不管是 closure、 monad 還是 continuation，或是比較新潮的 effect handler，都是在幫助 FP 語言做這種事情，開一洞讓留著以後填入變化狀態。 我認為 FP 跟 OOP 在抽象精神上有點殊途同歸，唯一的差別可能只是 OOP 要 "照顧" imperative programming 是一個過渡的角色，但 FP 從一開始就不管 imperative 與否了

[@dickgg]

OO 的依賴注入得要用物件加介面 , FP 用的是 function type。另外 FP 也不只關心 function 也注重型別, A -> B 裡面的 Type A, B 也是要定好的,不是有物件結構就是 OO。有一個點是狀態 OO 會放在物件內，但 FP 會想外顯用 Monad 表現出來。不過的確往往開發上都是混用，求的是在生產力、安全性、可維護性達到一個平衡點

[@atony8155]

超棒，麻煩你持續出影片

[@hongkaichen9340]

讲得好清晰！太感谢了

[@artinlin]

太強了已跪🙇

[@dukecheng6400]

影片質感大提升

[@ZackAlumi]

1. 我第一個聯想到的語言是 Forth！ 2. 我對標題所下的 改變程式思維 讓我想起當年的組合語言老師所說的，隨著經驗的累積，你所寫的 C 會從 basiC 變成 pasCal 再變成 C 最後 C++。

[@KorthLuo]

支持，這個題目很有趣

[@marschen2007]

超棒的 非常感謝！

[@Wilkao036]

喜歡這類型的影片 希望以後多做一點

[@terrylee6092]

偶然看到这个视频，内容和制作太棒了

[@jslu0413]

敲碗期待 FP 進階篇！！！

[@Rabbyte0857]

期待後續！

[@vanessalin3778]

讚讚讚讚期待下一集

[@jui-shuyeh6807]

想學多一點，感謝您的分享

[@Visual160]

優質推推

[@yuweiliu9045]

1. 00:26 Paradigm 我覺得「派典」或許是個不錯的中文說法~ 2. 16:05 "imuutability" > "immutability" Great video to get started with!

[@yichenwu6117]

简体中文通常翻译为编程“范式”

[@Nothing86620]

其實paradigm在其他學科也常提到，一般都是翻譯類似典範之類，強調是相關領域的基本規則這樣😂

[@1947_gout_key_d_lai]

新創一個沒人聽過的名詞「派典」不如使用現有的名詞 paradigm。有些名詞根本沒必要翻譯，硬要翻譯還翻出一個沒人聽過的名詞，讀者還要再查詢一遍，那還不如直接用原文，讓讀者去查原文。

[@ZX320320]

感謝分享~ 很受用

[@hungjoyee]

James 你這個教學很好 對我曾經在大學學過到現在不明白地方 來一個溫故之新 把一些當年不懂地方 完全解釋到 有時候大學教師很少去解釋這些東西 只是叫你做 但沒有解釋用在哪個地方

[@nonalcoho]

說得真好！ 我現在工作寫Java就是混用了這兩種的感覺 基本架構是OOP，但在做某些邏輯處理的時候會避免用for 而是用stream的filter或是map來直接處理 好處就是不用再多宣告一次變數然後操作的邏輯真的可以一目了然！

[@ryanwoon5019]

OOP和FP可共存。

[@hungjoyee]

沒錯 我看過spring framework 教學例子 都是混用

[@mickyyang6652]

這不能說是 FP，只能說是借自 FP 的函式，使用 pipeline 的方式來處理更為清楚，也在 Linux 行之有年了(?

[@albertwang5974]

FP: 站在变化的角度来解决问题 OOP：站在结构的角度来解决问题 我的建议：什么让你容易理解就用什么，没必要去追求纯粹的FP或者OOP。

[@ollieyoung8721]

好的中文程序影片太少了 非常喜歡你慢條斯理地清楚教學😊 希望以後多處

[@lchang2422]

真的，中文的太少了

[@nifalconi]

Thanks for the subtitles, your videos are excellent!

[@iamjoy658]

受益良多，謝謝。

[@youzark]

简洁优雅的讲解

[@singmantkpss]

declarative vs imperative 那裡講得真好

[@yuhsu4444]

未看先推

[@thejimmylin]

Imperative vs declarative 的部分講得挺好耶

[@user-zd3kt5zw6p]

감사합니다! 매우 유익한 영상이네요

[@samlin2903]

謝謝分享! 想看更多FP介紹~

[@panzhang9162]

非常明了，感谢~

[@louisyang6905]

水喔 講得很清楚 想要了解更多🥹

[@jamietse8539]

忍不住要讚一下！你真的講得很清楚呢！😃我是OOP 新手，一直在用function programming,不知道為什麼youtube教學的人要用const,

[@yenhachi]

感謝分享！ 學到好多

[@snowethan8615]

推~ 學到很多~

[@user-xw4tp4yw7p]

因為工作上用到kotlin，kotlin是FP語言，但是也保留了很多JAVA OOP的優點，是OOP還是FP的確是光譜兩端的概念，不是0和1

[@user-ir5bu1qi3v]

很好的教学

[@im-9527]

表達得很清楚

[@weia4335]

感謝講解！

[@marksu22]

結論的幾個問題，其實介紹中就提到了一些關鍵因素： 第1個是compiler，語言可以越抽象，就越依賴compiler。大多數情況，compiler都比我們清楚這個語言，我覺得依賴compiler比較好 XD 延續下來，第2個因素就是語言框架本身，語言本身對FP或OOP自然是有偏好的，甚至在語言演化上都可能改變偏好。但我們選擇語言框架的因素很多，如果選定了，自然跟著語言偏好採用FP或OOP才是最佳的選擇。

[@lzong]

Functional Programming 超讚，宣告式的寫法超爽，理解這些後幾乎就直接進入到計算理論的核心概念之一-- Lambda 演算了

[@CornuDev]

感謝分享 很有趣

[@fenix20075]

覺得FP和OOP最大差異並不是程式碼整潔程度(那只是單純的表象)，作為老鬼表示看得明白for loop但每次見到recursive lambda只能靠估的( 覺得自己差不多要退休了……orz)，所以FP的可讀性和預測性是反而更差，尤其是對新手而言 (只需記上一個for VS filter、recursive...等不同功能名，還有一堆變態在一條return short hand上寫上大量short hand，中間還要插recursive…… )；而兩者最大差異是回歸基本部：既然是程式語言，實際上本體不是程式而是語言，即是文法問題：FP的寫法實際上就是將動詞變成數學公式，編寫員可以把不同的變數放進公式內運行然後得出結果，於是程式就要照顧所有可能被插入的變數類別而變成萬能插頭 (weak type最喜歡這個)，而OOP的寫法就是將動詞與名詞掛鈎，把動詞塞進名詞裏當成名詞內的一個功能，編寫員就是要睇餸食飯必須了解名詞內的動詞如何被召喚 (strong type……)，所以這根本是數學家與語言學家之爭 XD 但我有聽過實際效能上FP運行速度是遠快於OOP，尤其是python這種專門處理數學運算的語言，而編寫速度也是FP快過OOP，因為節省了定義的時間，只是其可讀性奇差無比，所以世界趨勢是FP的寫法慢慢會佔優，畢竟最近是人工智能掛帥，背後就是數學家在用的居多。

[@jefftu6926]

看到這就讓我想起Emacs的Lisp,我得說過度FP結果就像Emacs一樣掛外掛掛到超吃記憶體。 此外FP可以訓練讓演算法類習慣性簡化，擠出部份效能，但別過度，因為有可能導致菜鳥或腦殘時踩雷。 本人我還是習慣For迴圈方式，因為年紀逐漸大，怕半年后忘了為什麼簡成這樣的。 我記得最好的程式語言名言是，程式語言有兩種情況下「沒bug」，一個是複雜到找不到bug，一個是簡單到看不出bug。

[@ctoid]

今天剛好想看一下FP到底怎麼回事就剛好有這麼詳細的影片可以看，你會讀心術吧

[@8pm]

關於 FP vs OOP，我是這樣看的： 因爲 FP 語言都支持 first-class functions 和 closure，所以很容易可以模仿 OOP 寫出 class 和 object，而且可以很簡潔，甚至可以最準確的限制裏面變數的訪問和修改。 通常 OOP 語言要模仿 FP 通常就麻煩很多，要用 class 模仿一個 callable object，另外還要搞個 object 做 environment 以模仿 closure。 在這個比較中，可以看出 FP 語言的表達能力比 OOP 語言強。 但必須強調一點，不管是哪種 FP 語言或是 OOP 語言，只要是 turing complete 的，在計算能力上是一樣的，並無強弱之分。 我個人認爲 FP 的程式設計通常更優雅，即使在傳統多使用 OOP 的設計的場景（比如 game programming 中用 object 代表 entity），如果用 FP 設計，因爲 pure function，所以可以使用 pipeline 的設計，reuse，改動和搭配都很方便而且不容易有 bug，因爲 entity 只是 stupid data，沒有 method 產生 side effect。

[@kailiao6341]

遊戲用FP的話，GC應該會直接爆炸吧

[@8pm]

@@kailiao6341 看設計，直接用 int，float，str 等代表狀態的 plain data structure 和內部帶 state 的 object 比起來，前者丟掉即可，後者 GC 時還需要 deconstruct 等開銷。

[@lzh97]

@@kailiao6341 要看編譯器支援程度啦，你在一個 OOP 語言用 FP 寫遊戲會爆炸很正常 XDDD 但是在 FP 語言裡面都有專門針對這個做最佳化，甚至 Clean 語言跟 Koka 語言不需要追蹤式的垃圾回收器，Clean 的做法跟 Rust 算是同掛的，就是 ownership 那套線性邏輯。Koka 的做法是能分析出那些變數可以重用而不用 clone 新的東西出來，然後能幫你自動搞 reference counting，但跟其他用 RC 的語言相比不會有環狀引用的問題，例如 Python 也用 RC，但是因為 Python 程式裡面環狀引用很常見，還需要一個追蹤式 GC 撿漏。

[@samuelchung8439]

很好👍

[@ilakeo]

有看有推

[@SunShiNnneEee]

講得好好! 寫了很多scala但常常還是用很OOP的方式去寫，看完影片對FP的基礎概念有更清晰的理解! 敲碗Monad!

[@yuan.pingchen3056]

現在的小朋友學寫程式不是用C語言入門的 會難以理解非物件導向的觀念遞歸最大的壞處就是stackoverflow

[@SunShiNnneEee]

@@yuan.pingchen3056 對耶XD 我的確不是C入門的 先python後來學JAVA 然後SCALA

[@yuan.pingchen3056]

@@SunShiNnneEee 以前的電腦只有一個CPU是單核心的,reset狀態也就是CPU上電或是RESET接腳被拉低後的狀態是CS:IP=FFFF:0也就是bios第一個被執行的指令 BIOS執行完一系列POST程序以後會載入開機硬碟的MBR 著名的開機病毒米開朗基羅就是藏在這裡的 對這個年代的人來說 順序式的程式設計反而比較符合常識

[@qinghu9213]

Scala是FP语言，Scala的程序应该尽可能用FP写（尽管也可以写成Java style，但应该避免这样写）。

[@SunShiNnneEee]

@@qinghu9213 謝謝你的建議!! 有想做到這樣，但常常思維轉不過來最後都會寫成java style

[@alexfu2422]

对我有帮助，谢谢

[@mamuwu7873]

謝謝～很喜歡，聽你在講一次才發現之前對 fp 還是有許多誤解

[@EddieCheng174]

太神啦，只能訂閱了

[@Phantom_Blox]

謝謝講解 :D

[@tsunningwah3471]

我好喜歡

[@user-wd9mg6vp4f]

雖然我是寫LabVIEW 的碼農~不過從影片中的概念跟自己的開發經驗中可以得到某些類比~感謝你的解說

[@samho321]

我自己兩種都有用，要看情況用吧。想說影片的解說速度剛剛好，因為一邊聽會一邊思考，現在這個語的確是非常好，可以慢慢令觀眾思考和反應。

[@CALee-zn9ch]

讚讚推

[@tangjiasheng8327]

一个影片解释的东西比我大学一整个学期还要仔细👍

[@gns880134guy]

支持更新

[@ccchang2023]

謝謝 在FP基礎上比較有概念了 畢竟還沒有很多同事要討論 這篇下面也感謝其他前輩分享見解，這是一部吃飯時間拿來看覺得很棒很開心的影片

[@have-bear]

講的非常好 FP 的核心理念就是盡量避免 side effects 要比較 FP 跟 OOP 還需要考慮他們是怎麼實現多型 (ad hoc polymorphism) 這部份 FP 主流有兩種方法, 一種是 typeclass, 另一種是 modular implicit 個人認為 FP + typeclass 的確是比 OOP 還要好的編程範式 在這個框架下重新思考程式設計的各種原則 可以發現大部分的 design patterns 都是為了「修補」 OOP 造成的缺點 FP 也並非沒有缺點, 這也是為什麼 pure functional programming language (像是 haskell) 這麼難寫難懂 而 Rust 作為結合 FP 與 imperative programming 的程式語言 再加上其他因素, 可以說是目前最好的程式語言

[@ck-dl4to]

所以FP能寫遊戲引擎嗎？渲染引擎呢？

[@xdimplendidx]

忘記第一次是在哪裡看到 FP。那時候還覺得不可思議，畢竟從小看書的流程好像就是了function -> class 的感覺，不斷聽到 OOP 的好處和重複使用程式碼。但真的寫多了才發現，不管是測試還是重複使用都是 FP 比較方便。

[@Bryan-bo2kg]

一部影片挖了好多坑

[@qiyings]

支持，想看!

[@不要稱讚我]

之前修過LISP，lambda套好幾層，短短幾行要想一整天，讓我好想念OOP的C

[@leo-bonucci]

james 老铁牛逼！！！

[@ian-ks]

分享兩個談論OOP的影片 第一個影片的這裡討論Four main possibilities of competing paradigms kzbin.info/www/bejne/h36Umoiba66inK8 Imperative VS Functional (mutate states whenever feel like to VS doesn't deal with states) Procedural VS OOP (No explicit association your data types and your functions VS ties functions to your data types) (這個影片也花了常篇幅解釋他認為的OOP的問題，以及他猜測為什麼OOP不好卻很普及 等等） 第二個影片大概是說 Procedural, OOP各有各的好，而OOP最大的問題是"speculative generalization"，就如同我們會希望避免"premature optimization". kzbin.info/www/bejne/Zprcc2OVprWpjc0

[@james-kool]

第一個我看過，原來他後來還有出新片XD

[@james-kool]

我看完了，speculative generalization真的說得非常精準。寫OO的確很常感覺到需要「預測未來」，但通常未來都跟預測的不一樣。OO把behavior跟data綁在一起，也會造成refactor更加困難。而procedural則等「未來需要」，再做調整。 我覺得如果要用非純FP語言做東西，他說的module oriented的方式也是我覺得比較好的方式

[@ian-ks]

期待接下來進階的functional影片！

[@ian-ks]

被KZbin推薦OOP起源的Ted talk，有趣分享個 kzbin.info/www/bejne/lZu3lGR4iauXf9E

[@aetheruszhou1526]

我自己是一个 FP 的爱好者，但是在实际工作中用 FP 语言（我用的是 Elixir）时还是会发现不少性能问题。 1. 在 imperative 语言里，最常见的线性容器是 array，由于它是一片连续的内存，很多时候可以直接把一个 array 或它的一部分放进 CPU Cache 来提高执行效率。但是在 FP 语言里，最常见的线性容器是 linked list，因为它不保证是一片连续的内存空间，所以往往无法把它放进 CPU Cache，于是 CPU 就要频繁地访问内存来获取数据，性能也就比较低了。当然这对于 I/O bound 的程序不是什么大问题。 2. Imperative 语言里有基于 array 的 hash table，按 key 的增删改查都是 O(1) 的时间复杂度。但是在 FP 语言里最多只有 hash array mapped trie （因为如果用 array 来实现 map 的话会破坏 structural sharing），导致按 key 的增删改查都是 O(log n) 的操作。 3. 在 FP 里很难做 caching，尤其是对于深层嵌套的数据结构，要对处在叶子位置的 struct 的某些 field 做 lazy loading （数据来源是 I/O）就很头疼。 不过总体来说，用 FP 语言编程比用 imperative 语言少了很多 bug，而且写起来更爽，阅读别人的代码也很爽，code review 也轻松很多很多，所以我还是更倾向于用 FP 编程。

[@stevenwinsir6229]

前端react就鼓励首选函数式组件，之前的类组件同样功能会复杂很多

[@TheSolidsnake2001]

I learned about FP is through finding out that WhatsApp, Discord were coded in Elixir/Erlang. Erlang is one the least well-known but widely used language designed by 3 engineers in Ericsson 1986 and Elixir story is even more fascinating...

[@HantaoCui]

谢谢分享！订阅了！

[@closer76]

Mutability 對於 loops 的重要性，不是只有「實用」而已，而是「必要」。因為除非是要寫無限迴圈，迴圈結束的條件都是要檢查某個狀態。如果狀態不會變化，那迴圈就永遠無法跳出。

[@yojaychang]

除了無窮迴圈，還有隨機結束，與時間結束或計時結束，計數迴圈對計數器為mutable是必要

[@closer76]

@@yojaychang Random number generator 和 timer 本質也算是 mutable 吧？甚至是 volatile 的（如果是透過硬體產生的話）。對 Haskell 來說，它們都在純函數的界線之外。

[@yojaychang]

@@closer76 我的觀點是不用宣告變數去儲存，不過也可視為Global 另一種是條件結束，比如把作業系統視為無窮迴圈持續運作系統程式，當有人把電腦關機，那意味著系統程式也跟著結束了。

[@yourliemerald1005]

FP 适合迭代时逻辑清晰或者说是一个结果与上一个结果的有关系并且关系简单，例如斐波那契数列，他的推导式就非常简单，及 下个数值是 前两个数字的和；OOP更偏向于流水化处理流程，及我知道对每个元素怎么去处理，但是这个元素的处理与其他元素并没有直接的关系。最佳的实践表示，代码可读 大于 一切，所以无所谓FP或OOP的优劣，易于读易于理解才是本身，就好比你举得那个例子直接改成表达式，在现实生活中去写往往会被主管骂死！

[@MrSnakePi]

非常好的影片，不知道functional programming 能不能和machine learning结合

[@qinghu9213]

Scala就是一种把两者整合在一起的语言，掌握以后对两者都能得心应手。

[@nienlin]

great, thanks

[@nienlin]

可以多一些例子嗎？所有的程式都可以用 FP 來寫？