3 ms·

> Imperative code often devolves into writing things that exponentially expand the state space of your program and hoping you can find a happy path through your

> Imperative code often devolves into writing things that exponentially expand the state space of your program and hoping you can find a happy path through your newly-expanded space without wrecking up too many of the other happy paths There's a good reason for this: it is the only way to run a business where the needs of customers and management changes on a constant basis. > Functional programming generally involves slicing away the state space until it is just what you need. This may be great idea for academics, but this approach is contraindicated in the field of software engineering, where the preferred solution is not the one with the "smallest state space", but the one that can deliver the most business impact with the least amount of effort. If I have to re-architect the entire program every Monday, that's not going to make leadership very happy.

monooso 2y ago
> There's a good reason for this: _it is the only way_ to run a business where the needs of customers and management changes on a constant basis. (Emphasis mine) And yet there are businesses which run on Haskell.
HPsquared 2y ago
The most widely-used functional programming environment in the world - Excel - is very adaptable and used in business. FP lets you add things freely without worrying about side effects.
- account-5 2y ago
  And likely the cause of a lot of business errors too. But at least it's not like parts of the human genome needed renamed because of it... Wait...
  - deleted 2y ago
    [deleted]
naasking 2y ago
> If I have to re-architect the entire program every Monday, that's not going to make leadership very happy. Good thing FP doesn't require that then.
- eyelidlessness 2y ago
  I think a more objective analysis would admit that it does require this, albeit sometimes not every Monday. And the article makes exactly this concession toward the end, to which I suspect GP’s comment was a glib reference. The objective counterpoint to this glib interpretation IS NOT that, in FP, one never has to rearchitect the logic narrowing a program’s state space. Instead, an objective counterpoint might be more along the lines of this: Yes, sometimes business rules evolve in a way that diverges from business logic. Yes, in a codebase that narrows its state space according to the prior business rules, that evolution may require revision to how state space is narrowed. But once that’s done, it is done. It doesn’t require adjusting dozens of special cases incidental to the previous business rules’ implementation: it only requires adjusting the special cases inherent to the business rules. That’s objective. And it’s also objective to say that whether it’s compelling will depend on the business’s tolerance for that objectivity (or in lucky cases: its embrace of same).
prerok 2y ago
I mean, isn't the problem you are mentioning because of the functionality that is assuming too much? In the sense of functions that are behemots of assumptions? It's actually easier if those functions are broken down into smaller pieces so when requirements change, you don't have to rearchitect: you just recombine them differently. And I am not speaking academically but practically: have learned the hard way to not produce the behemots but to combine functions to the desired effect in business setting(s).

monooso 2y ago

> There's a good reason for this: _it is the only way_ to run a business where the needs of customers and management changes on a constant basis. (Emphasis mine) And yet there are businesses which run on Haskell.

HPsquared 2y ago

The most widely-used functional programming environment in the world - Excel - is very adaptable and used in business. FP lets you add things freely without worrying about side effects.

account-5 2y ago
And likely the cause of a lot of business errors too. But at least it's not like parts of the human genome needed renamed because of it... Wait...
- deleted 2y ago
  [deleted]

naasking 2y ago

> If I have to re-architect the entire program every Monday, that's not going to make leadership very happy. Good thing FP doesn't require that then.

eyelidlessness 2y ago
I think a more objective analysis would admit that it does require this, albeit sometimes not every Monday. And the article makes exactly this concession toward the end, to which I suspect GP’s comment was a glib reference. The objective counterpoint to this glib interpretation IS NOT that, in FP, one never has to rearchitect the logic narrowing a program’s state space. Instead, an objective counterpoint might be more along the lines of this: Yes, sometimes business rules evolve in a way that diverges from business logic. Yes, in a codebase that narrows its state space according to the prior business rules, that evolution may require revision to how state space is narrowed. But once that’s done, it is done. It doesn’t require adjusting dozens of special cases incidental to the previous business rules’ implementation: it only requires adjusting the special cases inherent to the business rules. That’s objective. And it’s also objective to say that whether it’s compelling will depend on the business’s tolerance for that objectivity (or in lucky cases: its embrace of same).

prerok 2y ago

I mean, isn't the problem you are mentioning because of the functionality that is assuming too much? In the sense of functions that are behemots of assumptions? It's actually easier if those functions are broken down into smaller pieces so when requirements change, you don't have to rearchitect: you just recombine them differently. And I am not speaking academically but practically: have learned the hard way to not produce the behemots but to combine functions to the desired effect in business setting(s).