<story><title>What’s so great about functional programming anyway?</title><url>https://jrsinclair.com/articles/2022/whats-so-great-about-functional-programming-anyway/</url></story><parent_chain><item><author>fleddr</author><text>I&amp;#x27;m sure this is a wonderful intellectual exercise in computer science and math, but if this is to be the advertisement in favor of functional programming, I wouldn&amp;#x27;t consider myself a customer.&lt;p&gt;You start out with code that will not win any beauty awards but it gets the job done. It&amp;#x27;s easy to understand by programmers of any seniority, it&amp;#x27;s simple to debug and reasonably easy to put in an automatic unit test.&lt;p&gt;Next, you add all kinds of vague, poorly named meta utilities that don&amp;#x27;t seem to solve any tangible real world problem. You even mess with built-in JS methods like map. The code is now harder to understand and more difficult to debug.&lt;p&gt;A massive pain is added for some theoretical purity that few even understand or will benefit from. I&amp;#x27;ll double down on my rebellion by stating that the portability of code is overrated.&lt;p&gt;Here we&amp;#x27;re writing code to format notification objects. In our overengineering mindset, we break this down into many pieces and for each piece consider reusability outside this context to be of prime importance.&lt;p&gt;Why though? Why not just solve the problem directly without these extra self-inflicted goals? The idea that this is a best practice is a disease in our industry.&lt;p&gt;Most code that is written prematurely as reusable, will in fact never be reused outside its original context. And even if it is reused, that doesn&amp;#x27;t mean that outcome is so great.&lt;p&gt;Say that the sub logic to format a user profile link turned out to be needed outside this notification context. Our foresight to have made it reusable in the first place was solid. Now two completely different functional contexts are reusing this logic. Next, the marketing department goes: well actually...you need to add a tracking param specifically for links in the notification context, and only there.&lt;p&gt;Now your &amp;quot;portability&amp;quot; is a problem. There&amp;#x27;s various ways to deal with it, and I&amp;#x27;m sure we&amp;#x27;ll pick the most complicated one in the name of some best practice.&lt;p&gt;After 20 years in the industry, you know how I would write the logic? A single method &amp;quot;formatNotification&amp;quot;. It wouldn&amp;#x27;t weirdly copy the entire object over and over again, it would directly manipulate the object, one piece at a time. Error checking is in the method as well. You can read the entire logic top to bottom without jumping into 7 files. You can safely make changes to it and its intuitive to debug. Any junior would get it in about 2 minutes.&lt;p&gt;Clear, explicit code that requires minimum cognitive parsing.</text></item></parent_chain><comment><author>spc476</author><text>You can apply some FP notions to any code base:&lt;p&gt;1. Don&amp;#x27;t use globals.  Zero global variables should be the goal, that way, you avoid &amp;quot;spooky action at a distance&amp;quot; where some code here changes a global that changes the behavior of code over there.  A function that avoids global variables is easier to deal with than one that doesn&amp;#x27;t.  If you feel you need to use a global, think about why you need one before adding it.  Maybe you can avoid it.&lt;p&gt;2. Parameters to functions are immutable.  That way, you won&amp;#x27;t have to worry about data changing during a function call.  If the parameter can be mutated, can you signal the intent in the function name or signature, so the programmer knows that to expect?  Generally, try to avoid changing parameters in a function.&lt;p&gt;3. Separate I&amp;#x2F;O from processing.  Do input, do your processing, then output.  God, I wish the major component I worked on did that (concurrent DB requests)---it would make testing the business logic so much easier as it can be tested independently from the I&amp;#x2F;O.&lt;p&gt;Those three things can be done in any language, and just by doing those three things, you can most of the benefit of FP without the mathematical jargon (Monads?  How do they work?).  There&amp;#x27;s no need for over-engineered code, and you can be as explicit as you like while keeping the cognitive aspects to a minimum.</text></comment>
<story><title>What’s so great about functional programming anyway?</title><url>https://jrsinclair.com/articles/2022/whats-so-great-about-functional-programming-anyway/</url></story><parent_chain><item><author>fleddr</author><text>I&amp;#x27;m sure this is a wonderful intellectual exercise in computer science and math, but if this is to be the advertisement in favor of functional programming, I wouldn&amp;#x27;t consider myself a customer.&lt;p&gt;You start out with code that will not win any beauty awards but it gets the job done. It&amp;#x27;s easy to understand by programmers of any seniority, it&amp;#x27;s simple to debug and reasonably easy to put in an automatic unit test.&lt;p&gt;Next, you add all kinds of vague, poorly named meta utilities that don&amp;#x27;t seem to solve any tangible real world problem. You even mess with built-in JS methods like map. The code is now harder to understand and more difficult to debug.&lt;p&gt;A massive pain is added for some theoretical purity that few even understand or will benefit from. I&amp;#x27;ll double down on my rebellion by stating that the portability of code is overrated.&lt;p&gt;Here we&amp;#x27;re writing code to format notification objects. In our overengineering mindset, we break this down into many pieces and for each piece consider reusability outside this context to be of prime importance.&lt;p&gt;Why though? Why not just solve the problem directly without these extra self-inflicted goals? The idea that this is a best practice is a disease in our industry.&lt;p&gt;Most code that is written prematurely as reusable, will in fact never be reused outside its original context. And even if it is reused, that doesn&amp;#x27;t mean that outcome is so great.&lt;p&gt;Say that the sub logic to format a user profile link turned out to be needed outside this notification context. Our foresight to have made it reusable in the first place was solid. Now two completely different functional contexts are reusing this logic. Next, the marketing department goes: well actually...you need to add a tracking param specifically for links in the notification context, and only there.&lt;p&gt;Now your &amp;quot;portability&amp;quot; is a problem. There&amp;#x27;s various ways to deal with it, and I&amp;#x27;m sure we&amp;#x27;ll pick the most complicated one in the name of some best practice.&lt;p&gt;After 20 years in the industry, you know how I would write the logic? A single method &amp;quot;formatNotification&amp;quot;. It wouldn&amp;#x27;t weirdly copy the entire object over and over again, it would directly manipulate the object, one piece at a time. Error checking is in the method as well. You can read the entire logic top to bottom without jumping into 7 files. You can safely make changes to it and its intuitive to debug. Any junior would get it in about 2 minutes.&lt;p&gt;Clear, explicit code that requires minimum cognitive parsing.</text></item></parent_chain><comment><author>sfvisser</author><text>You&amp;#x27;re really fighting the wrong fight here. FP is not about prematurely writing reusable code.&lt;p&gt;It&amp;#x27;s about recognizing patterns in code that exist all over the place and &lt;i&gt;reusing those existing patterns&lt;/i&gt; for the new code you&amp;#x27;re writing. This way you can break your new feature into say 20% newly written domain specific code and 80% reusing existing patterns. Patterns that help with composition, enforcing invariants, simplifying writing test-cases, and more clearly signaling intent.&lt;p&gt;For example, if you provide a monad instance for your &amp;quot;formatting notification objects&amp;quot; I will probably understand how to use your library without even reading a single line of implementation at all. Just by scanning a few type signatures.&lt;p&gt;This way you and your team mates have a huge head start in understanding your new addition to an existing code base. This is a great win for everyone!</text></comment>