3 ms·

It also seems to me that the author is conveniently ignoring the mechanics that aren’t mapping well to FP. To me, belts and buffer chests are much easier to des

It also seems to me that the author is conveniently ignoring the mechanics that aren’t mapping well to FP. To me, belts and buffer chests are much easier to describe as a mutable data structure (FIFO queues). That’s also analogous to how real world applications typically look like: functional core / imperative shell (see also Gary Bernhard’s brilliant ’Boundaries’ talk). It’s a nice article to introduce FP but I get immediately suspicious about statements like ‘Engineering is FP’. FP is a tool, not a unified theory on how to model the world.

lmm 6y ago
FP is a unified theory on how to model the world: as functions, where equivalent inputs will always produce equivalent outputs. If there's something that makes outputs inequivalent, you should (under this theory) represent that with a corresponding input. It's not the only possible way to model the world, but it absolutely is a unified approach that you can apply to a whole system, and it tends to work better when you do - trying to apply "FP as a tool" within a fundamentally mutation-oriented system (for example) gets you a very limited subset of the benefits, IME.
- m_mueller 6y ago
  Real world is dirty. It needs logging, I/O, etc. Yes you can model those with monads in Haskell, but what happens much more frequently is that you’re in a team of Java/Python/Js/C++ programmers and you want to profit from some of the benefits of FP at least (testability, composeability). And that is where the perfect becomes the enemy of the better if you then just give up because you can’t get your single paradigm FP language. As a modeling tool however it is still very powerful, as are some aspects of OOP.
  - lmm 6y ago
    In my experience a codebase that crisscrosses back and forth between FP and mutation-based style ends up worse and buggier than one that commits fully to one or the other; it's not perfect being the enemy of better because it's not better.
    - m_mueller 6y ago
      I think it needs to be thought of as part of an overarching design - again, see Gary Bernhardt. A pure functional core that can be unit tested against, where the tricky logic happens. And a shell where you deal with dirty but dumb things like thread pools, logging, error handling, non-pure libraries etc. And then just be very diligent to separate concerns, i.e. don't put too many smart things into the shell.
      - travv0 6y ago
        "Functional core, imperative shell" is exactly what IO in the Haskell type system enforces.
      - lmm 6y ago
        > I think it needs to be thought of as part of an overarching design Right. Which is very much opposed to your initial "FP is a tool, not a unified theory on how to model the world".
        m_mueller 6y ago
        I don’t think it is? I don’t see the contradiction. My point is FP, imperative and OOP can be combined effectively in one architecture.
        lmm 6y ago
        They can be, but you need to adopt a particular global perspective/worldview to make it work. Treating FP as just a tool in the toolbox that you can use ad-hoc anywhere in the codebase is not effective.
    - rkangel 6y ago
      Criscrossing backwards and forwards would be bad, but the 'functional core, imperative shell' does work well. It is an excellent fit for Erlang/Elixir - you write a lot of pure functional logic (with the equivalently easy tests), and then you 'glue' it to the outside world with as little process machinery and statefulness as possible. We are in Erlang though, so I wouldn't call it 'mutation' necessarily. The stateful bits are individual actors, creating a new internal state in response to messages.
  - haet 6y ago
    What does a functional Python look like? To me, a functional language without tail recursion seems pointless. Is it possible to abstract away whether you are recursive or iterative, like an iterative recursion scheme? One thing that I think would be great is if there was a Python approach to effects systems like Polysemy (free monads); what might an in between be for this?
    - m_mueller 6y ago
      I don't think Python's type system is capable enough (yet) for something like this. However tail recursion optimization to me is a non issue - for something expensive and deeply nested I use an iterative approach, and for everything else python's recursion is good enough. There are not that many usecases like this per code base anyways, in my experience. In my current one there is one central facility to do object loading based on yaml definitions, that's the one place I need it there for example.
    - lmm 6y ago
      > To me, a functional language without tail recursion seems pointless. Tail recursion is a low-level detail IMO. Scala does fine without it.
      - Qem 6y ago
        Pharo too. See https://stackoverflow.com/questions/37089768/does-pharo-provide-tail-call-optimisation https://stackoverflow.com/questions/37089768/does-pharo-prov...
munchbunny 6y ago
I think the core of the issue is that, while you can take a FP based view on how Factorio works, typically the interesting problems to model in Factorio aren't really "FP" problems. They're not really "imperative" problems either. Really, I don't think they're programming problems, even if they kind of look like programming problems.

lmm 6y ago

FP is a unified theory on how to model the world: as functions, where equivalent inputs will always produce equivalent outputs. If there's something that makes outputs inequivalent, you should (under this theory) represent that with a corresponding input. It's not the only possible way to model the world, but it absolutely is a unified approach that you can apply to a whole system, and it tends to work better when you do - trying to apply "FP as a tool" within a fundamentally mutation-oriented system (for example) gets you a very limited subset of the benefits, IME.

m_mueller 6y ago
Real world is dirty. It needs logging, I/O, etc. Yes you can model those with monads in Haskell, but what happens much more frequently is that you’re in a team of Java/Python/Js/C++ programmers and you want to profit from some of the benefits of FP at least (testability, composeability). And that is where the perfect becomes the enemy of the better if you then just give up because you can’t get your single paradigm FP language. As a modeling tool however it is still very powerful, as are some aspects of OOP.
- lmm 6y ago
  In my experience a codebase that crisscrosses back and forth between FP and mutation-based style ends up worse and buggier than one that commits fully to one or the other; it's not perfect being the enemy of better because it's not better.
  - m_mueller 6y ago
    I think it needs to be thought of as part of an overarching design - again, see Gary Bernhardt. A pure functional core that can be unit tested against, where the tricky logic happens. And a shell where you deal with dirty but dumb things like thread pools, logging, error handling, non-pure libraries etc. And then just be very diligent to separate concerns, i.e. don't put too many smart things into the shell.
    - travv0 6y ago
      "Functional core, imperative shell" is exactly what IO in the Haskell type system enforces.
    - lmm 6y ago
      > I think it needs to be thought of as part of an overarching design Right. Which is very much opposed to your initial "FP is a tool, not a unified theory on how to model the world".
      - m_mueller 6y ago
        I don’t think it is? I don’t see the contradiction. My point is FP, imperative and OOP can be combined effectively in one architecture.
        lmm 6y ago
        They can be, but you need to adopt a particular global perspective/worldview to make it work. Treating FP as just a tool in the toolbox that you can use ad-hoc anywhere in the codebase is not effective.
  - rkangel 6y ago
    Criscrossing backwards and forwards would be bad, but the 'functional core, imperative shell' does work well. It is an excellent fit for Erlang/Elixir - you write a lot of pure functional logic (with the equivalently easy tests), and then you 'glue' it to the outside world with as little process machinery and statefulness as possible. We are in Erlang though, so I wouldn't call it 'mutation' necessarily. The stateful bits are individual actors, creating a new internal state in response to messages.
- haet 6y ago
  What does a functional Python look like? To me, a functional language without tail recursion seems pointless. Is it possible to abstract away whether you are recursive or iterative, like an iterative recursion scheme? One thing that I think would be great is if there was a Python approach to effects systems like Polysemy (free monads); what might an in between be for this?
  - m_mueller 6y ago
    I don't think Python's type system is capable enough (yet) for something like this. However tail recursion optimization to me is a non issue - for something expensive and deeply nested I use an iterative approach, and for everything else python's recursion is good enough. There are not that many usecases like this per code base anyways, in my experience. In my current one there is one central facility to do object loading based on yaml definitions, that's the one place I need it there for example.
  - lmm 6y ago
    > To me, a functional language without tail recursion seems pointless. Tail recursion is a low-level detail IMO. Scala does fine without it.
    - Qem 6y ago
      Pharo too. See https://stackoverflow.com/questions/37089768/does-pharo-provide-tail-call-optimisation https://stackoverflow.com/questions/37089768/does-pharo-prov...

munchbunny 6y ago

I think the core of the issue is that, while you can take a FP based view on how Factorio works, typically the interesting problems to model in Factorio aren't really "FP" problems. They're not really "imperative" problems either. Really, I don't think they're programming problems, even if they kind of look like programming problems.