Evidência empírica para a escolha do paradigma de programação para resolver um problema

O wiki C2 tem uma discussão sobre evidências empíricas para programação orientada a objetos que basicamente conclui que não há nada além do apelo à autoridade. Isso foi editado pela última vez em 2008. A discussão aqui parece confirmar isso: perguntas sobre se o OO está desatualizado , quando a programação funcional é uma má escolha e as vantagens e desvantagens da AOP são respondidas com a opinião dos colaboradores, sem depender de evidências.

Obviamente, as opiniões de profissionais estabelecidos e de renome são bem-vindas e valiosas, mas são mais plausíveis quando são consistentes com dados experimentais. Essa evidência existe? Eu sei que a engenharia de software baseada em evidências é uma coisa, mas posso praticá-la nesse contexto? Especificamente, se eu tiver um problema específico Pque quero resolver escrevendo software, existe um conjunto de conhecimentos, estudos e pesquisas que me permitiriam ver como o resultado de resolver problemas como esse Pdepende da escolha do paradigma de programação?

Eu sei que qual paradigma aparece como "a resposta certa" pode depender de quais métricas um estudo em particular presta atenção, em quais condições o estudo mantém constante ou varia e, sem dúvida, também em outros fatores. Isso não afeta meu desejo de encontrar essas informações e apreciá-las criticamente.

Torna-se claro que algumas pessoas pensam que estou procurando uma solução "ligue a manivela" - alguma máquina de salsicha na qual coloco informações sobre o meu problema e da qual surge uma palavra como "funcional" ou "estruturada". Esta não é minha intenção. O que estou procurando é pesquisar como - com muitas advertências e suposições que não vou abordar aqui, mas uma boa literatura sobre o assunto - certas propriedades do software variam dependendo do problema e da escolha do paradigma.

Em outras palavras: algumas pessoas dizem que "OO oferece melhor flexibilidade" ou "programas funcionais têm menos bugs" - (parte do) o que estou pedindo é a evidência disso. O resto está pedindo evidências contra isso, ou as suposições sob as quais essas declarações são verdadeiras, ou evidências mostrando que essas considerações não são importantes. Há muitas opiniões sobre por que um paradigma é melhor que outro; existe algo objetivo por trás de algum desses?

Para a versão anterior, consulte a Revisão 1 desta resposta . No entanto, os comentários e edições da pergunta esclarecem melhor o que a pergunta está buscando e permitem que eu seja mais claro.

Sim, a engenharia de software baseada em evidências (EBSE) é uma coisa. Parece haver alguns esforços em relação aos bancos de dados do EBSE, como este na Universidade de Durham e no SEED, iniciado por um professor da Cal Poly . Todos esses esforços, bem como os discutidos em vários documentos, podem ser encontrados no servidor IEEE Xplore ou na Biblioteca Digital ACM(assinatura ou compra necessária para muitos artigos em ambos), são baseadas em medicamentos baseados em evidências. Eles fornecem revisões de literatura de dados empíricos publicados (observação e experimento). De fato, a inclusão de "revisão de literatura" em uma sequência de pesquisa em qualquer pesquisa de publicação gera informações sobre a maioria dos tópicos - mais de 14.000 ocorrências no ACM e mais de 1.000 no banco de dados IEEE (quando limitado a apenas tópicos de computação).

Olhando para os tipos gerais de tópicos discutidos nessas bases de dados EBSE e revisões de literatura, vejo uma discussão comum - eles tendem a ser independentes da tecnologia. A ênfase parece estar principalmente centrada no processo e na metodologia, e não nas ferramentas específicas usadas para conduzir a engenharia de software.

Portanto, esse conceito existe na engenharia de software. A Academia está ciente do conceito baseado em evidências e pode aplicá-lo com sucesso à engenharia de software.

Especificamente, a pergunta aborda a aplicação de técnicas EBSE à seleção de um paradigma parece difícil, devido ao grande número de variáveis ​​envolvidas, forçando suposições a serem feitas, além de reduzir a capacidade de repetir o experimento ou observação. É dito exatamente na pergunta - "qual paradigma aparece como" a resposta certa "pode ​​depender de quais métricas um estudo específico presta atenção, de quais condições o estudo se mantém constante ou varia e, sem dúvida, de outros fatores também" . Embora isso não signifique estudar o paradigma "melhor" em uma determinada situação, torna qualquer tipo de revisão da literatura desses documentos incrivelmente difícil de concluir e ainda extrair informações entre eles.

Definitivamente, não existe uma solução "virar a manivela" para escolher um paradigma.

Dado um paradigma de programação, é possível encontrar estudos nos vários bancos de dados acadêmicos e do setor sobre como esse paradigma influencia vários aspectos do desenvolvimento de software - qualidade, defeitos, eficiência etc. - sob várias condições específicas, variando desde o conhecimento e a experiência do equipe para o domínio do problema. Qualquer artigo rigoroso deve identificar claramente as condições sob as quais os dados foram coletados e as suposições. O problema começa a tentar isolar os fatores que o tornam bom em cada uma dessas condições.

Academicamente, existem algumas afirmações fáceis de pesquisar. Por exemplo, a afirmação de que o paradigma funcional é bem adequado para aplicativos que exigem simultaneidade deriva do teorema de Church-Rosser . Por esse motivo, é provável que um sistema de software escrito em uma linguagem funcional tenha menos defeitos relacionados à simultaneidade do que o mesmo sistema escrito em uma linguagem processual ou orientada a objetos.

No entanto, do ponto de vista prático, uma equipe de software nem sempre pode usar "a melhor" ferramenta ou técnica para o trabalho apenas porque a pesquisa indica. Embora nos esforcemos para produzir sistemas de software da mais alta qualidade, operamos dentro de restrições. Muitas vezes, vejo essas restrições minimizadas (ou mesmo removidas da equação) ao discutir a eficácia de qualquer metodologia.

Como profissional, quando estou envolvido na escolha de tecnologias a serem usadas, tento identificar as melhores ferramentas possíveis. Mas então eu me restrico ao que é conhecido e bem compreendido pela equipe que tenho. Voltando ao meu exemplo anterior, se eu tiver uma equipe versada na criação de aplicativos simultâneos em C ++ e nenhuma experiência em Haskell, não faz sentido propor a criação do sistema em Haskell, pois provavelmente não será possível fazer isso. restrições de cronograma e orçamento, e minha qualidade provavelmente sofrerá devido à falta de experiência no conjunto de ferramentas.

Para recapitular, a engenharia de software baseada em evidências é geralmente uma coisa boa que existe e as revisões de literatura existem e estão prontamente disponíveis. No entanto, há aspectos da engenharia de software em que a aplicação de abordagens baseadas em evidências oferece pouco valor. A seleção de um paradigma de programação para um esforço de desenvolvimento em larga escala é uma delas.

Se você quiser descobrir como a orientação a objetos aborda a reutilização ou defeitos na programação funcional - você encontrará facilmente publicações sobre elas. No entanto, eu não encontrei (nem depositaria muita confiança) em uma publicação capaz de abordar efetivamente a seleção de paradigmas em toda a ampla gama de projetos de engenharia de software do mundo real.

Eu tenho lido The Art of Unix Programming de Eric S. Raymond. Ele tem algumas idéias históricas muito interessantes sobre coisas que agora tomamos como garantidas. Ele cita alguns bons estudos do software IEEE que usam evidências empíricas como densidade de defeitos. Essa pode ser uma boa fonte se você estiver procurando por estudos no estilo acadêmico.

Mesmo técnicas como modularizar usando funções nem sempre eram práticas comuns. Uma das minhas citações favoritas do livro até agora:

Dennis Ritchie incentivou a modularidade dizendo a todos que as chamadas de funções eram realmente muito baratas em C. Todo mundo começou a escrever pequenas funções e modularizar. Anos depois, descobrimos que as chamadas de função ainda eram caras no PDP-11, e o código VAX gastava 50% de seu tempo na instrução CALLS. Dennis havia mentido para nós! Mas era tarde demais; Estávamos todos viciados ...

- Steve Johnson

No entanto, existem realmente dois problemas em ser empírico. A primeira é que a qualidade do código é uma coisa muito subjetiva. O código pode ser terrível e ainda estar correto. A percepção das pessoas sobre um paradigma de programação é uma métrica muito válida, porque o código é escrito para que as pessoas leiam tanto quanto para computadores, se não mais.

O segundo problema é que 50% dos desenvolvedores têm talento abaixo da média na programação. Não importa se o seu desenvolvedor de topo é mais produtivo usando programação funcional se as lutas "ralé" para escrever trabalhando software de usá-lo, vamos software sozinho lindos e bem arquitetado. Da mesma forma com as linguagens de programação TMTOWTDI , seu desenvolvedor principal ainda escreverá um código modular e limpo, mas codificadores menos talentosos gravarão ruído de linha devido à falta de estrutura imposta.

É por isso que acho que a OOP subiu ao topo em popularidade, apesar de suas deficiências. Não é tão restritivo que atrapalha os mais talentosos, mas sua estrutura fornece uma maneira concisa de se comunicar e impor bons princípios de design aos menos talentosos.

Em nossa linha de trabalho, temos a tendência de avaliar uma solução baseada apenas em seus méritos técnicos. Um empreendimento bem-sucedido também deve levar em consideração o lado humano da equação.

Existem concursos de programação que usam um sistema de classificação por computador e permitem escrever em vários idiomas e publicar todos os tipos de resultados e coisas. Aposto que eles têm bons dados para você. Aqui está uma lista de 8: http://www.makeuseof.com/tag/8-onlineprogramming-contests-challenge-win/

Imagino que você possa fazer comparações significativas de soluções para problemas muito simples e claros, como soma de quadrados ou séries de Fibonacci, ou desenhar uma linha reta usando o algoritmo de linha de Bresenham. A maioria das tarefas de programação do mundo real não possui postagens claras e cada idioma tem seus pontos positivos. Grande parte do benefício de um idioma é subjetivo. Você pode encontrar dados mais significativos pesquisando a felicidade do programador e do cliente do que contando linhas de código ou número de defeitos.

Lembro que, quando passei meio dia escrevendo um dos meus primeiros programas do Awk, pensei que levaria uma semana inteira para fazer a "mesma coisa" em Java. Mas isso é porque minha solução Java teria se concentrado em ser robusta, onde a solução Awk era rápida e suja e exigia alguns ajustes manuais na entrada e na saída e era realmente descartável quando eu terminava. Awk e Java são ótimos, mas não para as mesmas coisas.

Acho que o que estou dizendo é que, para aplicativos do mundo real, comparar linguagens ou ferramentas de maneira significativa é extremamente difícil - o problema das maçãs e laranjas antigas. Boa sorte! Eu adoraria ver o que você descobriu.

Estou estudando maneiras diferentes de desenvolver software há mais de 30 anos. Há uma escassez de boas evidências publicadas sobre a escolha de um paradigma.

Eu montei uma grande bibliografia ASCII pesquisável. Isso inclui muitos papéis e artigos do IEEE e ACM. Eu identifico os itens com o tipo de evidência fornecida. Aqui estão as tags mais comuns:

...
133 =EXPERIMENT
177 =HISTORY
233 =IDEA
267 =SURVEY
338 =ESSAY
395 =THEORY
454 =ADVERT
491 =EXPERIENCE
500 =DEMO

Agora pesquise PARADIGM e conte as tags

  1 =ESSAY
  1 =EXPERIENCE
  1 =HISTORY
  1 =IDEA
  1 =POLEMIC
  1 =SURVEY
  1 =TALK

Se você quiser ir mais fundo, http://cse.csusb.edu/dick/lab.html e espero que ajude ...

Parece que, em muitos casos, não existe um corpus de pesquisa grande o suficiente ou de qualidade alta o suficiente para permitir tirar conclusões gerais sobre se uma prática em engenharia de software é melhor que outra. Eu estava procurando especificamente uma pesquisa para trabalhar em diferentes paradigmas, mas a falta de disponibilidade não se limita a essa arena, portanto, enquadrarei minha resposta em um sentido mais amplo.

Um artigo de 2004, Engenharia de Software Baseada em Evidências , de Kitchenham et al. , Aborda de maneira sucinta os benefícios a serem derivados de uma abordagem baseada em evidências e os problemas com a implementação na engenharia de software. Não discutirei os benefícios aqui (está claro na pergunta que eu gostaria de poder trabalhar dessa maneira), mas os problemas são relevantes como resposta à pergunta que fiz.

• Em primeiro lugar, se você não é membro do ACM, provavelmente não consegue ler o link acima, o que cobre o primeiro problema: nem toda a pesquisa existente está realmente disponível para os profissionais.
• muita prática de engenharia de software continua em segredo como parte de processos comercialmente confidenciais, portanto não há visibilidade do que funcionou ou não para essas pessoas.
• engenharia de software é uma prática hábil, por isso é difícil (não impossível, apenas difícil) organizar um estudo adequadamente cego.
• as diferentes partes do ciclo de vida do software afetam os resultados uns dos outros em uma extensão difícil de controlar em qualquer experimento.
• como evidenciado pelas discussões aqui, muitos profissionais não vêem "a literatura" (ou o lado acadêmico da engenharia de software em geral) como relevante para o seu trabalho.

Portanto, a resposta que procuro é "não", a evidência que estou procurando provavelmente não existe. Eu deveria escolher meu paradigma com base nos critérios populares existentes do que eu sei, do que é legal e da opinião de especialistas.

Não acredito que esse tipo de estudo exista. Alguém poderia acreditar que não é o paradigma de programação que importa tanto quanto o algoritmo real que é usado. Por exemplo, dado que qualquer sistema não trivial, um que dependa de algoritmos de espaço pequeno, versus um que dependa de algoritmos de tempo pequeno, geraria métricas diferentes. Aquele que tiver o melhor tempo provavelmente seria considerado mais válido, a menos que o espaço seja um problema, o inverso é verdadeiro. Acho que é semelhante a pavimentar uma estrada. Embora o algoritmo ou a receita para a fabricação de materiais seja constante em todos os processos, seria possível que uma empresa pense que pavimentar duas faixas ao mesmo tempo (uma de cada lado da estrada) é melhor do que pavimentar duas faixas ao mesmo lado da estrada ao mesmo tempo . No final do dia, não importa, pois o processo de fazer o top preto ainda é o mesmo, a única diferença é a abordagem. Voltando à programação, se você tiver uma equipe de desenvolvedores C, escreva o código de maneira processual, se você tiver uma equipe de desenvolvedores Java, escreva-o no OO. Não se prenda tanto ao paradigma quanto à implementação do algoritmo. Porque no final do dia, você pode escrever Java como C e tentar escrever C como Java.

ATUALIZAR

Para responder ao comentário, graham me deixou:
Suponho que por arquitetura você quer dizer paradigma de programação. Se você for usar o Clojure, talvez você deva contratar uma equipe de programadores do Clojure. No entanto, com base em uma pesquisa rápida, o Clojure é uma linguagem baseada em Java que, por acaso, é funcional. Dada essa informação, eu pegaria os programadores Java (já que tecnicamente eles podem escrever Java e isso fornecerá os mesmos resultados) ou procurar programadores funcionais, como os desenvolvedores Haskell. Agora, em termos de escolha do que é melhor, é completamente dependente da sua equipe. Eu nunca teria uma equipe de especialistas em bancos de dados relacionais organizando uma solução em nuvem para mim, nem uma equipe de programadores funcionais criaria uma solução orientada a objetos para mim. Você tem que usar os pontos fortes da equipe e não ter a visão glorificada que tem em sua mente para o que uma equipe "deveria"

Diferentes paradigmas levam a diferentes soluções. Qual ajuste é 'melhor' depende em grande parte:

• a solução
• a equipe de desenvolvimento
• o ambiente operacional

Não conheço nenhum estudo definitivo e, mesmo que houvesse um, não confiaria nele.

Esse é o trabalho do arquiteto.

Substituir a sabedoria do arquiteto pelas conclusões possivelmente irrelevantes de um estudo é uma receita para o desastre.

Nota: um comentário menciona a decisão sobre o "algoritmo" e a escolha do idioma. Algoritmos são o mecanismo estrutural central para linguagens procedurais. Linguagens orientadas a objetos se concentram em classes e padrões de colaboração / comunicação. Se você está convencido (como arquiteto) de que uma solução centrada em algoritmos é "a melhor", fique com linguagens procedurais ou funcionais.

Adendo: não confiar em estudos não é 'superstição', é senso comum. Os experimentos científicos devem ser objetivos e repetíveis. Os projetos de software são altamente subjetivos, mas ainda pior, são experimentos irrepetíveis . Você simplesmente não pode implementar um projeto X com a equipe Y, medir os resultados e reverter o tempo, apagar memórias e refazer o mesmo projeto com a mesma equipe. As informações descobertas ou implícitas pelos estudos podem ser úteis para o arquiteto, mas nunca podem ser definitivas.