In the Haskell systems I write, this change would be trivial. It’s a single line change. Maybe it’s just a benefit of the particular pattern I’m using (standard Yesod handler, which if I remember correctly is just the ReaderT IO pattern), but still, it seems completely wild in my view to trash an entire language and indeed an entire paradigm because you can’t imagine making the change in your example.
Regardless, the point is not that it's impossible to make such a change in a Haskell code base, just that it may or may not require non-trivial breaking changes, while such a change in an OO enterprise code base will always be trivial.
There's lots and lots wrong with OO patterns, but being able to respond to changing and arbitrary whacky business requirements is a clear strength.
Why? From where did you invent this completely arbitrary constraint?
> You shouldn't be putting business logic in your HTTP handlers.
Why not? How else could this work? The user has to interface with the business logic somehow.
There’s nothing at all wrong with a HTTP handler that takes in a request, delegates to a few different business logic things, and then sends a response.
Not only are you moving the goalposts with your argument, you’re also coming up with things that are completely false.
There’s nothing about OOP that inherently makes extending some code to send an email easy. Likewise, there’s nothing about FP that inherently makes the same task hard.