A programação funcional adiciona complexidade ao código? [fechadas]

Durante todo o ano passado, eu escrevi o código Scala (vindo de Java). Gostei muito de como você poderia criar código mais simples e limpo, com vals, classes de caso, funções map / filter / lambda, implícitos e a inferência de tipo. Eu o usei principalmente para um aplicativo baseado em Akka .

Este ano, estou em um projeto Scala com uma nova equipe, que realmente gosta de programação funcional. Eles usam intensamente o Scalaz , e o código é preenchido em todos os lugares com aplicativos, limites de contexto, mônada de leitor / gravador / estado, até o método principal é "encapsulado" em uma mônada de E / S. O raciocínio deles é que isso faz o compilador "trabalhar para nós" ao afirmar que o código está correto e que cada função está livre de efeitos colaterais.

Mesmo assim, do meu ponto de vista, toda essa sintaxe realmente atrapalha a lógica dos negócios. Por exemplo, um tipo de "MyBusinessObject" é bom, assim como tipos "List [MyBusinessObject]", "Option [MyBusinessObject]" ou mesmo "Future [MyBusinessObject]". Todos eles têm um significado e propósito claros. Por outro lado, código como:

def method[M[_]: Applicative] = {
  case (a, b) => (ca[M](a) |@| cb[M](b)) {
    case t @ (ra, rb) =>
      if (ra.result && rb.result) t.right
      else t.left
  }
}

isso adiciona complexidade ao programa ou sou apenas eu que não estou acostumado a esse modo de programação?

Isso não tem nada a ver com programação funcional - você pode encontrar esse tipo de situação no contexto de qualquer outra linguagem de programação - desenvolvedores que amam tanto as construções avançadas da linguagem "sua" que ignoram qualquer senso comum sobre legibilidade e simplificação. Eu encontrei uma situação dessas em C, C ++, Perl, Java, C #, Basic e outras linguagens não funcionais. Não é a programação funcional que adiciona complexidade ao código - os programadores fazem.

Não me interpretem mal, eu não recomendo evitar recursos avançados de linguagem - mas é importante encontrar o equilíbrio certo no contexto fornecido. Ao escrever uma biblioteca genérica para o uso de> 100.000 desenvolvedores em todo o mundo, existem medidas diferentes a serem aplicadas, como quando você está escrevendo um gerador de relatórios individual apenas para o escritório local.

Eu diria que você não está acostumado com a maneira como eles codificam é pelo menos parte da imagem. Estou em uma situação semelhante a você (vindo de C # para F # e trabalhando com pessoas com background de Haskell) e, embora eu ache uma experiência interessante, tenho momentos em que estou batendo a cabeça na parede, desembaraçando um composição de função sem ponto particularmente complicada apenas para entender o que está acontecendo lá. É uma coisa cultural.

Quanto a saber se esse código específico adiciona complexidade ao programa - eu não sei. Concordou que um pedaço de código genérico pode ser complexo por si só. Mas é um utilitário, não uma parte da lógica de negócios. Se você quiser saber se isso torna a base de código mais complexa ou mais simples, você teria que imaginar como ela ficaria sem essa parte do código. Geralmente é o caso de construções tão genéricas que elas mesmas são complexas, mas é uma complexidade que você pode ajustar em uma única tela. Ao mesmo tempo, eles tornam toda a base de código um pouco mais simples. Este é particularmente o caso das mônadas.

Por outro lado, também pode ser um caso de 'arte pela arte', como sugere @Doc Brown. Também não pode descartar.

Eu argumentaria que, em geral, a programação funcional reduz a complexidade, eliminando o estado mutável, reduzindo assim o número de casos que devem ser considerados ao tentar entender como uma seção do código funciona.

No entanto, a programação funcional possibilita graus mais altos de abstração e, embora um código altamente abstrato possa ser extremamente útil, também pode ser difícil de entender porque, por definição, é separado do contexto que você usaria normalmente para orientar seu entendimento. Seu comentário "Todos têm um significado e propósito claros" sobre objetos de negócios é indubitavelmente verdadeiro, mas é realmente um reflexo do fato de que essa lógica é muito específica para uma necessidade e contexto que você já entende. A existência de um construto como o Monad permite que você faça algo muito útil com pouco esforço, mas a web está repleta de páginas tentando explicar o que é um Monad. Isso é abstração para você.

Além disso, Scalaz foi escrito por pessoas que comem e respiram FP há muito tempo; eles queriam trazer a funcionalidade disponível em Haskell para Scala. Ao fazer isso, eles não tentaram ser pedagógicos. Scalaz faz uso de um vocabulário e estilo que parecem claros e diretos para os autores, mas estranhos para os não iniciados. Os métodos que são intrigantes para o resto de nós pareciam tão óbvios para os autores, dados os antecedentes de Haskell, que nem sequer mereciam um comentário.

Além disso, como uma linguagem de programação funcional, o Scala tem algumas falhas (em parte porque a JVM tem deficiências) que forçaram os autores do Scalaz a escrever código mais feio em alguns casos. Por exemplo, a falta de eliminação geral de chamadas de cauda força o uso de trampolins em algum código, e a falta de um "sistema de tipos" pode complicar as assinaturas de tipos.

E, finalmente, Scalaz faz um ótimo uso de si mesmo. Isso pode ser pensado como um sinal de seu poder, mas para os não iniciados, a fonte pode ser um enigma - qualquer código aleatório que você observe provavelmente fará uso de algo que lhe pareça estranho.

Mantenha-se firme. E isso pode ajudar.

Isso adiciona complexidade ao programa ou apenas você não está acostumado a esse modo de programação?

Por que você acha que essas possibilidades não são a mesma coisa?

Um código bem escrito pode ser lido por pessoas que não estão familiarizadas com a linguagem de programação específica. Algumas linguagens (BASIC, Pascal, etc) podem ser lidas e entendidas por alunos que nunca viram linguagens de programação antes.

Se alguém que tem experiência com outros idiomas e experiência com Scala (e que suponho que trabalhe com Scalaz por pelo menos uma semana e tenha colegas para explicar as coisas mais complicadas) ainda esteja confuso; então isso prova que adicionou complexidade.