1. 22
  1.  

  2. 4

    It’s come to really annoy me that ‘functional programming’ has come to mean ‘pure functional programming’ to so many people. There’s a lot of value in embracing functions as first class objects (which is what, in conjunction with lexical closures, ‘functional programming’ properly means) without subscribing to the ‘no side effects’ paradigm. Most of the value of pure functional programming comes from.. well.. functional programming, not necessarily the purity, and definitely not pervasive mandatory purity that forces you to write state-mutating code in a weird monadic style instead of just making some variables mutable.

    What this article is talking about really doesn’t have anything to do with ‘functional’ anything, it’s not about functions! In fact, it’s quite explicitly not about pure functional programming either (which is what they mean when they say ‘functional programming’). It’s about using purity in specific bits of your programme, which is exactly the opposite approach to pure functional programming, which is about mandating purity everywhere. It’s about having well-defined modular components with well-defined interfaces between them. This is basic software design stuff that people have been talking about for decades.

    I think what this article actually has to say is really good, though! It presents the ideas in a clear way and justifies its claims fairly well.

    1. 3

      I think there’s a lot of value in this sort of design.

      For a lower-level treatise, if yall haven’t read it, the Finagle paper has a lot of insight that might compliment this post. https://monkey.org/~marius/funsrv.pdf