12 ms·

Right, I can think of many situations where a new business requirement is like "oh, and for this client, when we do X, we also need to send them an email." OOP,

Right, I can think of many situations where a new business requirement is like "oh, and for this client, when we do X, we also need to send them an email." OOP, for all its faults, makes this kind of extensibility trivial, where I can't imagine easily making such a change in the context of a statically typed effects system. "This function was pure and now it's not" almost certainly leads to a refactor. That's not to say that statically typed FP can't be written in such a way to allow this kind of arbitrary modification, but then you get into the realm of finding the perfect abstraction in the type system, which is exactly the same kind of maintenance problem that OO architecture astronauts bring to a code base. This is all to say -- we should be writing Clojure, which allows a tight focus on actual business requirements while still being flexible enough to allow you to bail out of FP patterns when necessary. :)

yakshaving_jgt 8y ago
I’m super confused by this. 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.
- 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.

yakshaving_jgt 8y ago

I’m super confused by this. 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.

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.