> In the years since I wrote this, I have gotten much more bullish about pure functional programming, even in C/C++ where reasonable: (link) > >The real enemy addressed by inlining is unexpected dependency and mutation of state, which functional programming solves more directly and completely. However, if you are going to make a lot of state changes, having them all happen inline does have advantages; you should be made constantly aware of the full horror of what you are doing.
He explicitly says that functional programming solves the same issue as inlining but more directly and completely.
Maybe this is just a subtle semantic thing, but what I took from this is that he is factoring out pure functions where ever possible, within a procedural context. In my mind, that’s not the same thing as “functional programming”.
> In the years since I wrote this, I have gotten much more bullish about pure functional programming, even in C/C++ where reasonable: (link) > >The real enemy addressed by inlining is unexpected dependency and mutation of state, which functional programming solves more directly and completely. However, if you are going to make a lot of state changes, having them all happen inline does have advantages; you should be made constantly aware of the full horror of what you are doing.
He explicitly says that functional programming solves the same issue as inlining but more directly and completely.