kbilsted / functional-core-imperative-shell Goto Github PK

Article: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/

Argues that functions should not be different between sync and async. But in terms of pure/effectful, maybe it's a good thing that functions cannot be mixed however which way? The "color" of a function might be used to enforce a functional core.

Sometimes you have one shell, sometimes you have more. How to avoid duplicating organizing code when you have many shells? Or is that duplication a good thing, if logic can later diverge?

https://github.com/orourkedd/effects-as-data
https://medium.com/javascript-scene/mocking-is-a-code-smell-944a70c90a6a
https://redux-saga.js.org/
https://erock.io/simplify-testing-async-io-javascript/
https://redux-loop.js.org/docs/tutorial/Tutorial.html
Elm Architecture
https://github.com/dubzzz/fast-check

There's a lot of focus around doing this on the front end. And it's true using UIs are doused in reactivity and asynchrony. Also, React was the iPod moment for functional programming along with Flux/Redux. Anyways, there is plenty of application for this pattern in a sufficiently effectual backend. And for backends that don't even have a lot of effects, lifting them to the top would go a long way to improve the test cases by omitting the mocks.

Instead of writing to the database or file, create an event or closure to deal with it later.

https://martinfowler.com/eaaDev/EventSourcing.html

Hi ho!

I started to think about this pattern again, but this time in more OOP terms, with regard to state, dependencies and pure vs effectful classes. I think it should be possible to distinguish between "functional core" classes and "imperative shell" dito.

Discussion on Reddit here: https://old.reddit.com/r/PHP/comments/n484hv/discussion_a_class_should_have_state_or/

http://olleharstedt.github.io/programming/2022/01/27/on-composability-in-software-design.html