At the boundaries, applications aren't functional

I think you can say that at the boundaries, applications aren&#x27;t <i>anything</i>.<p>I tend to think of code in a cellular sense, as in, biology. Outside the cell is a big scary world that you don&#x27;t control. There&#x27;s a cell wall where you only permit certain things in. Inside the cell, the cell trusts that only good stuff has been let in. It may also have to package certain things on the way out to the next cell.<p>In this case, the observation I&#x27;d make is about that big scary external world. You don&#x27;t get to impose anything on it, or at least, your control is a great deal less rigid than our code would like. Even if you think you control your internal network, hackers might explain otherwise to you in the worst possible way. You can&#x27;t impose compliance with functional paradigms, imperative paradigms, security levels, soundness of data, whether or not a bit was flipped during transit, that the metadata matches what was sent, or anything.<p>Obviously you can&#x27;t fully write your code that way (even real cells get it wrong sometimes too), but that&#x27;s the principle I try to view the world through. Even within an application where every individual component is, say, compliant with functional programming, the interactions still can&#x27;t be counted on to have any particular properties that you don&#x27;t check somehow.<p>FP, OO, data-driven design, all that sort of stuff, that&#x27;s for what you do inside the cells, and maybe how you choose to structure the code implementing your cell wall. But you almost always end up forced to treat the outside world as bereft of any structure you don&#x27;t rigidly check for and enforce yourself, if not outright hostile (anything with security implications).

&gt; In 2011 I observed that at the boundaries, applications aren&#x27;t object-oriented. For years, I&#x27;ve thought it a natural corollary that likewise, at the boundaries, applications aren&#x27;t functional, either. On the other hand, I don&#x27;t think I&#x27;ve explicitly made that statement before.<p>The next and last paragraph does not then explicitly make that statement, instead ending with:<p>&gt; Functional programming offers an alternative that, while also not perfectly aligned with all data, seems better aligned with the needs of working software.<p>I think that&#x27;s right. OOP is just a disaster, but FP is not. FP is not about making all of a program pure, but, rather, about isolating all the bits that can be pure (thus making them easy to test) and collecting all actual impurity into as small a bunch of code as possible.<p>The impure code you end up having will look very procedural.<p>In Haskell, you do this by running all side-effect-having code &quot;in the IO monad&quot;, and monadic code looks procedural in the same way that PROGN loops procedural in Lisp though PROGN is [or can be] a macro that turns your procedural statements into one singular expression.<p>So it&#x27;s completely fair to say that &quot;at the boundaries, applications are procedural&quot;, because, well, it&#x27;s patently true!<p>FP helps by helping the programmer push impure code as much as possible towards that boundary, leaving the rest to be as pure (and thus easily-tested) as possible.<p>For example, if you have code that uses the time of day for externally-visible effects, then pass it the time of day so as to make it more pure and easier to test. This one is counter-intuitive because we like to just get-the-current-time, but I&#x27;ve done this to make code that does epochal cryptographic key derivation deterministic and, therefore, testable.

At the boundaries are events. &quot;User wanted to change time of meeting&quot;.<p>Once you have recorded events, figuring out what side-effects (often causing new events in other systems) should be triggered from the set of all events input into the system can be coded using whatever flavor of functional&#x2F;relational&#x2F;reactive programming.<p>I think the combination of event sourcing and functional programming, and databases that support this way of working better than today and doesn&#x27;t have OOP as their main target audience, is the future. (And I absolutely don&#x27;t mean Kafka. SQL comes at least closer; to efficiently work with events and implement functional business logic on top of events relations and structure is important.)

To me the big difference between OO and FP is complexity management.<p>In OO complexity is hidden. So you don&#x27;t have to deal with the complexity of the internal state of an object while using the object. It&#x27;s a divide and conquer approach.<p>In FP complexity is constrained. Pure functions and immutable data make it easier to reason about the code. This allows you to see all the workings and not get overwhelmed.

Time to wake up and smell the Flavor Aid:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=535921" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=535921</a>

Correct. In more mainstream language, quoth Gary Bernhardt, &quot;functional core, imperative shell.&quot;<p>Functional programming is a convenient fantasy, a highly restrictive and controlled environment that allows us to make large assertions about bodies of code - &quot;no network IO can take place here&quot;; &quot;your inputs will most assuredly be numbers that can be added together.&quot;<p>It&#x27;s the equivalent of assuming the cow is a sphere [0]. A useful mental model, that ultimately breaks down upon contact with the &quot;real world.&quot;<p>Hence the imperative glue code &#x2F; monadic actions wiring all of the pretty, perfect abstractions together.<p>[0] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Spherical_cow" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Spherical_cow</a>