将以更有效的方式(scalaz)使用Scala会带来性能/可维护性的惩罚？

我目前正在开发一个主要是纯粹的小项目(<10k loc)，但主要依赖于迭代器和重型计算的一些数据结构重用的可变优化。 我想学习更多的功能性编程，并希望获得更多的类型安全性，例如将可变计算包装到状态变压器单体等中。为此，存在scalaz库。 问题一 通过使用所有花哨功能的东西来抽象我的计算，我会介绍一下我不会摆脱的性能杀手吗？喜欢当我的计算包裹在Monads的膝盖？ 问题二 考虑到Scala的有限类型推论，是否可行？我目前正在与非常大的类型签名进行战斗(可能是因为我不知道如何正确摆脱它们)。我认为，更多的“功能性”将引入更多的这种锅炉版代码。 放弃 我不是质疑功能方法是好是坏。对Haskell提出这个问题是毫无意义的。我在质疑Scala是否合理。 根据要求编辑：我的项目中的大型签名的示例 (但这将是一个不同的问题) 以下代码描述了类型参数化输入对象(DiscreteFactorGraph [VariableType，FactorType [VariableType]])上的迭代计算。您可以使用createInitialState构建一个计算对象，并使用advanceState对其进行计算，最后从边缘提取一些信息。 我想要在计算过程中保留因子图对象的类型(及其参数类型)，以便边缘的最终应用产生正确类型的DiscreteMarginals [VariableType]。我认为目前我只需要在计算类型(即TState)中保留变量类型，因此不使用因子类型。但是在不同的地方，我甚至需要DiscreteFactorGraph的类型是可变的，所以我希望将来需要更多的类型信息通过计算。 我很喜欢这部分，我希望有更好的解决方案。目前我有一个非常实用的方法，只有这三个功能。但我必须通过它们链接类型。或者，我可以将其定义为一个类，并使用所有这些类型对类进行参数化，因此我不必为每个方法重复类型参数。

object FloodingBeliefPropagationStepper extends SteppingGraphInferer {
  def marginals[V <: DiscreteVariable,F <: DiscreteFactor[V]](state: FloodingBeliefPropagationStepper.TState[V,F]): DiscreteMarginals[V] =
    BeliefPropagation.marginals(state._1,state._2)

  def advanceState[V <: DiscreteVariable,F]): FloodingBeliefPropagationStepper.TState[V,F] = {
    val graph = state._1
    (graph,BeliefPropagation.computeFactorMessages(
      graph,BeliefPropagation.computeVariableMessages(graph,state._2,graph.variables),graph.factors))
  }

  def createInitialState[V <: DiscreteVariable,F <: DiscreteFactor[V]](graph: DiscreteFactorGraph[V,F],query: Set[V],random: Random): FloodingBeliefPropagationStepper.TState[V,F] = {
    (graph,BeliefPropagation.createInitialVariableMessages(graph,random),graph.factors))
  }

  type TState[V <: DiscreteVariable,F <: DiscreteFactor[V]] = (DiscreteFactorGraph[V,Map[(F,V),DiscreteMessage])
}