Side Effects and Functional Programming

Side Effects and Functional Programming - Matthew Podwysocki

One of my first posts at CodeBetter was in regards to side effects and how, when unmanaged, can be truly evil. Today, I want to revisit that topic briefly in regards to functional programming and managing side effects. When I was out in Redmond a couple of months ago, I had the opportunity to sit down with Erik Meijer to discuss functional programming among other topics. In there, we discussed a number of issues around managing side effects and state in your code, and how both C# and F# don't intrinsically support such a concept. Languages like Haskell, of course do with IO monads and other such monadic structures. Whether languages such as F# and Erlang are not pure functional programming languages is another matter, due to the fact that you don't have to declare when you are side effecting (reading a database, writing to console, spawning a process, etc).

Side Effecting Functions are Code Smells

Side Effecting Functions are Code Smells - Matthew Podwysocki

I know the title might catch a few people off guard, but let me explain. Side effecting functions, for the most part, are code smells. This is a very important concept in Domain Driven Design (DDD) that's often overlooked. For those who are deep in DDD, this should sound rather familiar. And in the end, I think Spec# and some Design by Contract (DbC) constructs can mitigate this, or you can go the functional route as well.