5 ms·
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 b
by Twisol 8y ago
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 https://www.destroyallsoftware.com/talks/boundaries . The core idea is that values -- data, not code -- should form the boundaries between distinct systems.)
- monocularvision 8y agoThe 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 https://m.youtube.com/watch?v=7AGQ9dhWCX0
- tylerc230 8y agoYeah swift lends itself to this style well. Value types, functional aspects etc.
- yoava 8y agoWhat 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.
- cellularmitosis 8y agoThis 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-complexity/ https://academy.realm.io/posts/andy-matuschak-controlling-co...
- ttflee 8y agoAnd his visionary talk on JavaScript, asm.js and others: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- fpoling 8y agoThe 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.
- msangi 8y agoWhat would a functional approach be?
- yoava 8y agoFunction composition
- fpoling 8y agoIt 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.
- yoava 8y agoActor model is even worse, you have no gerentee of a response or error status
- shrimpx 8y agoThere aren't that many ways you can mess up a message queue.
- ramchip 8y agoYou 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.
- mercer 8y ago