<story><title>What&apos;s functional programming all about? (2017)</title><url>https://www.lihaoyi.com/post/WhatsFunctionalProgrammingAllAbout.html</url></story><parent_chain><item><author>yodsanklai</author><text>As a programmer, I don&amp;#x27;t know if it&amp;#x27;s still relevant to make a strict separation between programming paradigms. You can use immutable types, pure functions, closures and so on in most languages. Conversely, you can define mutable types and imperative code in most functional programming languages.&lt;p&gt;I&amp;#x27;m always surprised reading comments on these topics, people saying they don&amp;#x27;t grasp FP. But don&amp;#x27;t we use higher-order functions, closures, combinators all the time in most mainstream languages? How hard can it be to learn OCaml or Clojure for someone who use closures all over the place in JS?&lt;p&gt;Monads have a steeper learning curve, but besides Haskell, they aren&amp;#x27;t that pervasive. And there are constructs with similar flavor in mainstream languages too (result types in Rust...)</text></item></parent_chain><comment><author>majoe</author><text>True, the conceptual difference of (pure) functional and imperative programming is disguised by the many functional patterns most mainstream languages have absorbed. While these patterns are useful, there is more to say about pure functional programming.&lt;p&gt;I recently gave a talk to some colleagues about that, which was divided into two parts: Practical functional programming patterns we can use today in our codebases (we use mainly C++, Python) and a more abstract part about pure functional programming.&lt;p&gt;The first part basically boils down to using functions as first class &amp;quot;objects&amp;quot;, while the point of the second part was, that there can&amp;#x27;t be implicit state in pure functional language.
The consequence of that is, that there is no strict order of execution, which is in direct contrast to imperative programming, which is all about list of statements, that are executed one after another.&lt;p&gt;I presented small code examples in Haskell and showed corresponding execution graphs to emphasise, that the compiler can easily optimise the execution order.&lt;p&gt;I like that POV, because it clearly distinguishes imperative from functional programming. Starting from there, it&amp;#x27;s also easy to understand the motivation behind monads or elaborate on architectural patterns like &amp;quot; functional core, imperatively shell&amp;quot;.</text></comment>
<story><title>What&apos;s functional programming all about? (2017)</title><url>https://www.lihaoyi.com/post/WhatsFunctionalProgrammingAllAbout.html</url></story><parent_chain><item><author>yodsanklai</author><text>As a programmer, I don&amp;#x27;t know if it&amp;#x27;s still relevant to make a strict separation between programming paradigms. You can use immutable types, pure functions, closures and so on in most languages. Conversely, you can define mutable types and imperative code in most functional programming languages.&lt;p&gt;I&amp;#x27;m always surprised reading comments on these topics, people saying they don&amp;#x27;t grasp FP. But don&amp;#x27;t we use higher-order functions, closures, combinators all the time in most mainstream languages? How hard can it be to learn OCaml or Clojure for someone who use closures all over the place in JS?&lt;p&gt;Monads have a steeper learning curve, but besides Haskell, they aren&amp;#x27;t that pervasive. And there are constructs with similar flavor in mainstream languages too (result types in Rust...)</text></item></parent_chain><comment><author>fire_lake</author><text>Mainstream languages are not expression orientated like true FP languages are. Most people working in mainstream languages aren’t aware of the significance of this and wonder why FP seems awkward in their language, despite it having closures, some immutable types, etc.</text></comment>