3 ms·

Don't be pedantic, this is super simple code that is easy to analyze. Side-effects are not the terror that haskell programmers make of it.

• imoverclocked 6y ago
  After working on and maintaining several very large codebases, I would strongly disagree. When large blocks of code start being called only for their side-effects then refactoring/deleting old code gets pretty tricky. Conversely, when writing green-fields code, side effects are extremely convenient and make developers more productive in the very short-term.
  • mpweiher 6y ago
    (Side) effects are the reason you write code in the first place. So I'd agree that focusing on the reason you are writing the code makes everyone more productive, though not just in the short term. ¯\_(ツ)_/¯ Now how you organize your code so that you don't mix things up willy-nilly is a different, more nuanced and, I think, more interesting question. I am a big fan of hexagonal architecture, where you have a very localized and super-testable core with, ideally, all the complex functionality, surrounded by adapters that are as trivial as possible and communicate with the outside world, be that the user, persistence, network etc. FP is one way of achieving this, but certainly not the only one.
• nindalf 6y ago
  A better reading of his comment is this. You can analyze side effects easily in a small function or system. Not so easily in a large system. That's why it's better to avoid side effects.