4 ms·
If you do only one thing then following the "functional core, imperative shell" idea of application development will set you up nicely for easy refactors in the
by eckesicle 6y ago
If you do only one thing then following the "functional core, imperative shell" idea of application development will set you up nicely for easy refactors in the future.
https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell https://www.destroyallsoftware.com/screencasts/catalog/funct...
In short. Keep mutations to the edges of your application and keep your business logic purely functional.
Day 1 may be too soon to introduce queues etc, but having a clean separation between application logic and attached resources (like your storage layer) will greatly help with maintainability, testability and extensibility from the get go
- jpcooper 6y agoI've been mostly functional throughout my career, so that method would have appealed to me before. The idea is to never mutate but always create a copy of data to prevent race conditions. Fundamentally though, you are mutating data. We have to accept this. Creating copies at each iteration does not change this. The question then is what abstraction allows mutation without allowing data races. Recently I was looking into how I would implement a simple TCP protocol in C++. I think Boost's ASIO (asynchronous IO) provides the correct abstraction for this. It allows you to write your code as if it were single-threaded. Code which needs to be serialised can run on the same "strand". Strands simply serialise code, even if the code runs on separate threads. I think this abstraction would work for the example in your link as well.