What's the benefit of separating specialised data from behaviour in an algorithm?

Question

Functional programming strongly suggests to separate data from behaviours (functions). However, I can't see the benefit of this for an algorithm's implementation intrinsically tied with particular settings data.

For example, suppose there's a trait LagrangeAlgorithmOOP with immutable data being the algorithmic settings, problem specification and dependencies on helpers. The trait's methods all use this data to find a problem solution. Their implementation is specific to the algorithm's type. Almost none of would make sense as a stand-alone function.

Specifically, suppose we refactor

 trait LagrangeAlgorithOOP {

       val settings: SettingsLagrange
       val problem: ConstrainedProblem
       val innerMinimiser: Minimiser
       val penaltiesFunction: ConstraintPenaltiesFunction

       def iteration( s: StateLagrange):  Either[String, StateLagrange]
       def lagrangeFunction( lams: Lambdas, pens: Penalties): AugmentedLagrangianFunction
       def estimateLambdas( pens: Penalties, las: Lambdas, cons: ConstraintValues): Option[Lambdas]
       def updatePenaltiesHistory( h: HistoryLagrange): HistoryLagrange
     }   

into this

case class LagrangeData(settings: SettingsLagrange,
                        problem: ConstrainedProblem,
                        innerMinimiser: Minimiser,
                        penaltiesFunction: ConstraintPenaltiesFunction)


trait LagrangeAlgorithmFUN {

  def iteration(d: LagrangeData, s: StateLagrange):  Either[String, StateLagrange]
  def lagrangeFunction(d: LagrangeData, lams: Lambdas, pens: Penalties): Lagrangian
  def estimateLambdas(d: LagrangeData, pens: Penalties, old: Lambdas, cons: ConstraintValues): Option[Lambdas]
  def updatePenaltiesHistory(d: LagrangeData,  h: HistoryLagrange): HistoryLagrange
}

The latter case introduces a data class and an extra parameter into each method. (Instead, I could use a Reader monad, which would, however, also require monad transformers.)

Questions:

1. What is the best refactoring of this algorithm to an FP style?
2. Could some half-way approach work better: eg, to leave some of the data fields in the trait?
3. Is there much difference between the original and refactored versions?
4. What is the benefit of refactoring to FP-style in this case?

Note: I agree with many points in the related post Why is "tight coupling between functions and data" bad?. Still I'm not sure how this applies to immutable settings data that is intrinsic to the functions implementing the algorithm.

Answer 1

If you specify the data of the type as immutable, then there is little difference between your two examples. You say, "The latter case introduces a data class and an extra parameter into each method." But in actuality it doesn't. An OO method implicitly passes the parameter you call an "extra parameter" so it isn't truly extra, just moved from before the function name to after.

Keep in mind that without inheritance the difference between foo.bar() and bar(foo) is purely a syntactic one. When you add the fact that modern OOP practice strongly favors using inheritance only for interfaces (which corresponds closely to FP type classes) you will see that there is a lot of convergence between best practices in both OOP and FP. Given this, we now see that in the "best practices" cases, foo.bar() and bar(foo) (or in an ML language (bar foo)) is merely a syntactic difference even taking inheritance/type classes into account.

Once you allow mutability, then an OO class effectively becomes a specialized IO monad and the OO programmer ends up having to work with lots of these specialized IO monads to get anything done. Here too the current trend is to reduce the number of classes that are explicitly mutable which has lead to an explosion of languages that are "largely" but not purely functional, and with syntax more in the OO style which is familiar to the typical programmer.

So in answer to your questions, the difference is largely syntax but IMO the OO style of obj.func() allows for a more natural chaining of function calls. Instead of c(b(a)), I can do a.b().c() which makes the order of operations more clear because it reads in a left to right order.

The counter argument is that the OO call style necessarily gives precedence to one particular parameter of the function over the others which is true and a good reason to avoid the style if there is no natural preference inferred by the algorithm. For example when comparing two objects for equality, a.equals(b) just feels silly compared to equals(a, b) because there is no reason to preference a over b in that context. All OO languages that I know of, with the exception of Java, allow for "free" functions that follow the more functional style of not giving precedence to one particular parameter. It's even doable in Java through the use of so-called "static" functions that exist inside a class, but don't actually have a implicit this or self parameter.