Hacker News Reader

Comment by Twisol | Hacker News Reader

This basic idea has deeply infected how I approach software architecture and design. When someone asks me why I wrote something a particular way, it's usually because I'm trying to keep the imperative/environmental concerns separate from the functional/algorithmic concerns.

I end up recommending this video at least once every year.

(EDIT: Another one from Gary that pairs well is "Boundaries": https://www.destroyallsoftware.com/talks/boundaries . The core idea is that values -- data, not code -- should form the boundaries between distinct systems.)

View on HN

The entire architecture of our iOS app is built around this principle. We have tried to give it a name but keep coming back to “Functional Core, Imperative Shell”. You can find some of the ideas that were implemented here: https://m.youtube.com/watch?v=7AGQ9dhWCX0

Yeah swift lends itself to this style well. Value types, functional aspects etc.

What you seek is actually something a bit different.

It is the observation that all software is built of 3 layers -

Inbound IO, what you call imperative shell Business logic core, what you call functional core Outbound IO, what you call again imperative shell.

The problem with the terms in functional programming is that when they say side effects, in most cases they mean IO.

The functional core does not have to be functional for you to get the benefits - easy testing, easy to reason about, easy to develop. In fact, in some cases, functional programing is the wrong tool while having a business logic core that is separated from IO is still a very valid architecture.

Generally speaking, I find that it is making the "business core" stateless that has the benefits.

In which cases is functional programming the wrong tool for the business logic core?

This is another talk which pairs well with it (values vs. objects, and how to split your code up accordingly): https://academy.realm.io/posts/andy-matuschak-controlling-co...

The actor model is prized in the talk. Yet actor model is not functional. The problem is the message queue of each actor. It is an imperative storage and one can get all nasty problems of imperative code from apparently functional code patterns.

What would a functional approach be?

Function composition

It depends on what is the goal. To take advantage of multicore for computations one can use explicitly parallel functional algorithms. To improve response under load one can do load balancing within application and schedule at the very top (shell level) several independent functional pipelines.

Actor model is even worse, you have no gerentee of a response or error status

There aren't that many ways you can mess up a message queue.

You can build every actor like a miniature program, with its own imperative shell and functional core. In Erlang it's common to have various message handlers that are very imperative, but defer all complicated logic to pure functions that take part of the actor state and return a transformed state.

I've been doing more and more Elixir work, and one of the most important lessons I keep learning is to keep my 'actors' as simple as possible and put the complicated stuff in my 'bags of functions'. I generally try to treat my code as two completely separate layers: the code that does stuff, and the code that orchestrates/isolates all of it.

What I find fascinating is that, at least for me, using GenServers/Agents/Tasks has made this distinction much more obvious than it has been in other languages.

I've built horrifying systems that muddled things together, only to realize quite far in how much of a mess I made, but with my Elixir projects I usually realize what I've done pretty quickly, and I end up course-correcting earlier on.

And his visionary talk on JavaScript, asm.js and others:

https://www.destroyallsoftware.com/talks/the-birth-and-death...

Reply on news.ycombinator.com