3 ms·
Business logic is pure and stateless. Lifting to IO is a breaking change that may or may not require non-trivial refactoring. You shouldn't be putting business
by james-mcelwain 8y ago
Business logic is pure and stateless. Lifting to IO is a breaking change that may or may not require non-trivial refactoring. You shouldn't be putting business logic in your HTTP handlers.
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.
- yakshaving_jgt 8y ago> Business logic is pure and stateless. 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.