Learning Functional Programming can provide immediate benefits. However, FP practitioners tend to be bad at teaching/explaining (to non-mathematicians) and even

Learning Functional Programming can provide immediate benefits. However, FP practitioners tend to be bad at teaching/explaining (to non-mathematicians) and even worse at marketing[0]. I've attached a list of good resources on FP at the end of this comment. I also wrote an article on the benefits of functional programming: https://blog.leftium.com/2023/04/more-performant-testable-code-with_28.html https://blog.leftium.com/2023/04/more-performant-testable-co... Functional programming is more of a spectrum; not an "all or nothing" concept. You can write FP-style programs in non-FP languages. (And you can use non-FP style in FP languages.) Understanding FP will help you write better non-FP code. Simple example: I have switched from declaring an empty array [], then filling it via a loop to declaring the same array with values from a functional expression (like map). This has two benefits: 1. The array can be declared const, and its contents possibly even declared read-only. 2. TypeScript can automatically infer the type/shape of the array contents. The other example usually cited is that FP will help you understand recursion better, even in non-FP languages. FP is a paradigm that can be applied at many levels. You can apply it: - at the code level: removing logical branching in code (https://youtu.be/GyYME8btMHE?t=1473 https://youtu.be/GyYME8btMHE?t=1473) - at the high-level design level: event sourcing (https://youtu.be/8JKjvY4etTY https://youtu.be/8JKjvY4etTY) Although FP languages make it more convenient to write functional-style code, notice the examples above don't need "functional" programming languages. In fact, many "non-functional" languages have borrowed the best parts of functional languages (first-class (lambda) functions, map, reduce, etc)[1]. One of the most valuable, but misunderstood concepts of FP is immutability (functional purity). Grokking Simplicity[2] states it most elegantly: it's not about avoiding mutation because "mutation is bad." In fact, mutation is usually the desired result, but care must be taken because mutation depends on when and how many times it's called. So good functional programming isn't about avoiding impure functions; instead it's about giving extra care to them. After all, the purpose of all software is to cause some type of mutation/effect (flip pixels on a screen, save bits to storage, send email, etc). Impure functions like these depend on the time they are called, so they are the most difficult to get right. --- Here's a short list of my top introductions/explanations of FP: - Grokking Simplicity: https://www.manning.com/books/grokking-simplicity https://www.manning.com/books/grokking-simplicity - Functional Core, Imperative Shell: https://hw.leftium.com/#/item/18043058 https://hw.leftium.com/#/item/18043058 - ScottWlaschin: https://hw.leftium.com/#/item/21879368 https://hw.leftium.com/#/item/21879368 - Greg Young on Event Sourcing: https://youtu.be/8JKjvY4etTY https://youtu.be/8JKjvY4etTY - https://project-awesome.org/stoeffel/awesome-fp-js https://project-awesome.org/stoeffel/awesome-fp-js [0]: https://youtu.be/nuML9SmdbJ4 https://youtu.be/nuML9SmdbJ4 [1]: https://hw.leftium.com/#/item/21280429 https://hw.leftium.com/#/item/21280429 [2]: https://www.manning.com/books/grokking-simplicity https://www.manning.com/books/grokking-simplicity