Na minha carreira acadêmica, li vários artigos acadêmicos sobre vários tópicos de ciência da computação. Muitos dos quais envolvem uma implementação e alguma avaliação dessa implementação, mas descobri que muito poucos deles publicam realmente o código que usaram.
Para mim, os benefícios de incluir a implementação real seriam significativos, a saber:
- Extensão de confiança ou reprodutibilidade (apenas teste você mesmo!)
- Esclarecimento de ambiguidades (principalmente para trabalhos escritos por falantes não nativos)
- Reutilização de código para aplicativos
Então, por que tão poucos documentos realmente incluem algum código?
Suponho que possa ser a intenção da organização por trás do documento utilizar a implementação em seus próprios aplicativos e, portanto, não gostaria de lançá-lo, mas se for esse o caso, por que escrever o artigo?
soft-question
research-practice
paper-review
Kevin Dolan
fonte
fonte
Respostas:
Aqui está um artigo bem discutido de David Donoho e Jonathan Buckheit, que eu li na pós-graduação que aborda exatamente esse tópico do ponto de vista dos pesquisadores de wavelets:
"WaveLab e pesquisa reproduzível"
A idéia deles era ainda mais ambiciosa: fornecer código para reproduzir todas as figuras em seus artigos em um conveniente pacote Matlab.
Eu realmente gosto da ideia deles, mas acho que os problemas são óbvios.
(1) É um trabalho extra (limpar o código, criar pelo menos uma interface de usuário rudimentar, escrever alguma documentação, fornecer algum suporte quando as pessoas inevitavelmente encontrarem problemas)
(2) Não é realmente exigido / esperado pela maioria das conferências / revisores
Mas não posso deixar de pensar que a comunidade de pesquisa em CS se beneficiaria se houvesse a expectativa de disponibilizar publicamente o código e os dados usados em qualquer publicação em um formato utilizável. Admito que não o fiz, mesmo quando a quantidade de trabalho envolvido seria administrável. Eu acho que é apenas difícil fazer um esforço extra quando não há pressão externa.
fonte
Se você trabalha em um laboratório industrial, pode ser muito, muito mais fácil obter um documento aprovado para liberação do que obter um código aprovado para liberação (mesmo que o documento contenha todas as informações necessárias para reescrever o código). Culpe a burocracia.
fonte
Migrado e expandido de um comentário:
Eu acho que isso deve variar de acordo com o subcampo. Quase todas as coisas da Teoria B com as quais eu estou familiarizado (e especialmente Haskell, Agda e, por vezes, relacionadas à Coq) incluem código publicado, às vezes até como um apêndice ou, melhor ainda, descrito no artigo. Um bom número de artigos de, por exemplo, o ICFP são escritos como programas alfabetizados, e sua fonte na íntegra é publicada pelos autores. Uma boa quantidade desses, por sua vez, resultou em bibliotecas extraídas para distribuição.
Dos papéis restantes, uma quantidade razoável nunca teve código para começar. Dessas, provavelmente existem duas razões principais. Primeiro, são os artigos cujo conteúdo principal são árvores de prova, regras de digitação com provas de integridade associadas e similares. Desses, os avanços na metateoria mecanizada incentivaram pelo menos alguns autores a fornecer código em seu provador de teoremas preferido (veja os slides de Weirich no POPLmark: http://www.seas.upenn.edu/~sweirich/talks/cambridge-09. pdf) Em segundo lugar, são os que descendem do material das aves merteens (banannas & co.). Geralmente, eles são traduzíveis para um idioma funcional sem muito trabalho. No entanto, suspeito que exista uma perda geral de generalidade, e que lidar com questões concretas de sintaxe e digitação complica desnecessariamente as coisas e torna mais difícil seguir o raciocínio equacional.
Eu queria substanciar minhas observações um pouco, assim como uma contagem aproximada dos dois primeiros dias do ICFP 2010. Dos documentos padrão (ou seja, sem relatos de experiência ou palestras convidadas), 12 dos 21 forneceram algum tipo de código. Três forneceram Coq (um quarto reivindicou uma prova parcial, mas não a publicou). Três apoiaram Haskell. Três forneceram a Agda. Um forneceu Scheme, um forneceu Caml e um forneceu Twelf. (Observe que alguns forneceram código para mais de um assistente de prova ou para uma formalização e uma implementação). Dos trabalhos restantes, alguns trabalharam com um nível de abstração alto o suficiente para que implementá-lo em um assistente de prova fosse um trabalho novo em si, e um número razoável de outros trabalhos que eu suspeito que poderiam ter sido implementados em um assistente de prova usando técnicas padrão, mas que certamente exigiriam bastante trabalho para isso.
fonte
Você acredita que o código deve ser publicado, mas pergunta por que os documentos não incluem código. Estas são duas coisas diferentes.
Na maioria das vezes, simplesmente não há espaço suficiente para publicar uma quantidade significativa de código. No meu campo de pesquisa (processamento de imagem), as informações de pseudocódigo ou arquitetura geralmente são muito mais valiosas e nunca me vi preso devido à falta de código em um artigo. É muitas vezes deixado como um exercício para o leitor que compreendeu o artigo.
No entanto, há muito código disponível para ilustrar artigos. Os autores geralmente têm uma página da web e, mesmo que o revisor não tenha a chance de verificar o código, a seleção natural parece funcionar muito bem e os autores que não publicam código são muito menos citados.
fonte
Isso já deve ter sido perguntado há algum tempo, no entanto, sempre me senti fortemente sobre isso, então darei meus dois centavos. Trabalho há anos (não mais) na comunidade do SAT. A maioria dos pesquisadores raramente publica seu código. O artigo é publicado junto com o algoritmo, mas é muito raro ver o código real do SAT Solver (MAXSAT Solver) etc, publicado junto com o artigo.
E a realidade é que, com apenas o código publicado no artigo, você nunca terá a chance de reproduzir os experimentos do autor. Não apenas porque o código publicado não está completo (é claro), mas também porque mesmo o pseudo-código publicado raramente se traduz semi-diretamente no que é realmente implementado.
A razão por trás disso é difícil de saber e pode depender de pesquisador para pesquisador, mas na maioria das vezes é dupla.
Primeiro, o pesquisador tende a trabalhar continuamente em um único solucionador, publicando trabalhos após trabalhos no mesmo solucionador e adicionando novos recursos de forma incremental que se traduzem em novas versões do solucionador. Existe uma obsessão doentia de que a concorrência usará seu solucionador para promover suas carreiras, estendendo-o e publicando artigos sem dar o devido crédito (ou seja, co-autoria).
Em segundo lugar, algum código é realmente (como em todo software) escrito rapidamente. Scripts meio cozidos. Recursos não testados, etc. Ao publicar esse código, o pesquisador sentiria que estaria se envergonhando e prejudicando sua reputação.
Deixo uma referência recente da ACM sobre isso: http://cacm.acm.org/magazines/2011/5/107698-the-importance-of-reviewing-the-code/fulltext
fonte
Historicamente, os artigos científicos tinham que ser impressos em papel e os periódicos eram enviados internacionalmente. Cada página extra usada para adicionar um custo significativo, portanto, os artigos estavam sujeitos a limitações de comprimento, e mesmo o código de trabalho simples geralmente ocupa muito espaço do que uma descrição informal.
Hoje não há uma boa razão para não incluir código em qualquer tipo de artigo que faça referência a um algoritmo.
Também pode ser útil abandonar formatos orientados para impressão, como pdf e postscript, em favor de formatos com reconhecimento mais semanticamente (HTML com MathML ou talvez uma variação de código aberto do Mathematica).
fonte