Code dans les documents académiques

Au cours de ma carrière universitaire, j'ai lu plusieurs articles sur divers sujets liés à l'informatique. Beaucoup impliquent une implémentation et une évaluation de cette implémentation, mais j’ai trouvé que très peu d’entre eux publient le code qu’ils ont utilisé.

Pour moi, les avantages d'inclure la mise en œuvre réelle seraient importants, à savoir:

• Extension de la confiance ou de la reproductibilité (testez-le vous-même!)
• Clarification des ambiguïtés (en particulier pour les communications écrites par des locuteurs non natifs)
• Réutilisation du code pour les applications

Alors pourquoi est-ce que si peu de journaux incluent-ils du code?

Je suppose que l’organisation derrière le document a peut-être l’intention d’utiliser l’implémentation dans ses propres applications et ne souhaite donc pas la publier, mais si tel est le cas, pourquoi même écrire le document?

Voici un article bien argumenté de David Donoho et Jonathan Buckheit que j'ai lu lors de mes études supérieures qui aborde exactement ce sujet du point de vue des chercheurs en ondelettes:

"WaveLab et la recherche reproductible"

Leur idée était encore plus ambitieuse: fournir un code permettant de reproduire toutes les figures de leurs papiers dans un paquet Matlab très pratique.

J'aime beaucoup leur idée mais je pense que les problèmes sont évidents.

(1) C’est un travail supplémentaire (nettoyer le code, créer au moins une interface utilisateur rudimentaire, écrire de la documentation, fournir un peu de soutien lorsque des personnes rencontrent inévitablement des problèmes)

(2) Ce n’est pas vraiment requis / attendu par la plupart des conférences / critiques

Mais je ne peux pas m'empêcher de penser que la communauté de la recherche en informatique en bénéficierait si on s'attendait à ce que le code et les données utilisés dans toute publication soient accessibles au public dans un format utilisable. J'avoue que je ne l'ai pas fait moi-même, même si la quantité de travail requise aurait été gérable. Je pense qu'il est difficile de faire l'effort supplémentaire quand il n'y a pas de poussée externe.

Si vous travaillez pour un laboratoire industriel, il peut être beaucoup, beaucoup plus facile de faire approuver un papier que de le faire approuver (même si le papier contient toutes les informations nécessaires à sa réécriture). Blâmez la bureaucratie.

Migré et développé à partir d'un commentaire:

Je pense que cela doit varier selon les sous-domaines. Presque tous les éléments de la théorie B que je connais (et en particulier Haskell, Agda et parfois liés à Coq) incluent du code publié, parfois même en annexe ou, mieux encore, dans le document. Un grand nombre d'articles de, par exemple, ICFP sont au départ des programmes alphabétisés, et leur source dans son intégralité est publiée par les auteurs. Une bonne partie de ceux-ci ont abouti à l'extraction de bibliothèques à distribuer.

Parmi les papiers restants, une bonne quantité n'a jamais eu de code pour commencer. Parmi ceux-ci, il y a probablement deux raisons principales. Il s’agit d’abord des documents dont le contenu principal est constitué d’arbres de vérification, de règles de frappe et de preuves de cohérence associées, etc. Parmi ceux-ci, les progrès de la métathéorie mécanisée ont encouragé au moins certains auteurs à fournir du code dans leur prouveur de théorème de choix (voir les diapositives de Weirich sur POPLmark: http://www.seas.upenn.edu/~sweirich/talks/cambridge-09. pdf). Deuxièmement, il y a ceux qui descendent de l'étoffe Bird-Merteens (bananes et autres). Celles-ci sont généralement traduisibles dans un langage fonctionnel sans trop de travail. Cependant, je soupçonne qu’il ya généralement une perte de généralité et que régler des problèmes concrets de syntaxe et de dactylographie complique inutilement les choses et complique la tâche de suivre le raisonnement équationnel.

Je voulais un peu corroborer mes observations, de même que le décompte approximatif des deux premiers jours de la conférence ICFP 2010. Parmi les documents standard (c.-à-d. Pas les rapports d'expérience ou les conférences invitées), 12 sur 21 ont fourni un code quelconque. Trois ont fourni Coq (un quatrième a réclamé une preuve partielle mais ne l'a pas publiée). Trois proposa Haskell. Trois ont fourni Agda. Un fourni Scheme, un fourni Caml et un fourni Twelf. (Notez que certains ont fourni du code pour plus d'un assistant de preuve, ou pour une formalisation et une implémentation). Parmi les documents restants, quelques-uns ont fonctionné à un niveau d'abstraction suffisamment élevé pour que sa mise en œuvre dans un assistant de preuve soit un nouveau document en soi, et un nombre beaucoup plus important de travaux que je soupçonne auraient pu être mis en œuvre dans un assistant de preuve en utilisant techniques habituelles, mais qui auraient certainement nécessité pas mal de travail.

Vous pensez que le code devrait être publié, mais vous demandez pourquoi les documents n'incluent pas de code. Ce sont deux choses différentes.

La plupart du temps, il n’ya tout simplement pas assez de place pour publier une quantité importante de code. Dans mon domaine de recherche (traitement d'image), les informations de pseudocode ou d'architecture sont souvent beaucoup plus utiles et je ne me suis jamais retrouvée bloquée à cause du manque de code dans un document. C'est souvent un exercice laissé au lecteur qui a compris l'article.

Pourtant, il y a beaucoup de code disponible pour illustrer les articles. Les auteurs ont généralement une page Web et même si le relecteur n'a pas l'occasion d'essayer de vérifier le code lui-même, la sélection naturelle semble fonctionner plutôt bien et les auteurs qui ne publient pas de code sont beaucoup moins cités.

Cette question a peut-être déjà été posée il y a un certain temps, mais j'ai toujours été très sensible à cela et je vais donc donner mon prix. J'ai travaillé pendant des années (plus maintenant) au sein de la communauté SAT. La plupart des chercheurs publient rarement leur code. Le papier est publié avec l'algorithme, mais il est très rare de voir le code du solveur SAT (MAXSAT), etc., publié avec le papier.

Et la réalité est qu'avec le seul code publié dans le document, vous ne pourrez jamais reproduire les expériences de l'auteur. Non seulement parce que le code publié n'est pas complet (bien sûr), mais aussi parce que même le pseudo-code publié se traduit rarement de manière semi-directe par ce qui est réellement implémenté.

La raison derrière cela est difficile à comprendre et cela peut dépendre de chercheur à chercheur, mais le plus souvent, c'est double.

• Premièrement, le chercheur a tendance à travailler continuellement dans un solveur unique, publiant des documents après les documents du même solveur et ajoutant progressivement de nouvelles fonctionnalités qui se traduisent par de nouvelles versions du solveur. Il existe une obsession malsaine de penser que la concurrence utilisera votre solution de résolution de problèmes pour poursuivre sa carrière en la prolongeant et en publiant des articles sans vous accorder suffisamment de crédit (signification, co-auteur).

• Deuxièmement, certains codes sont réellement écrits (comme tous les logiciels). Des scripts à moitié cuits. Fonctionnalités non testées, etc. En publiant ce code, le chercheur aurait l’impression d’être embarrassant et de nuire à sa réputation.

Je vous laisse avec une référence récente de ACM à ce sujet: http://cacm.acm.org/magazines/2011/5/107698-the-importance-of-reviewing-the-code/fulltext

Historiquement, les articles scientifiques devaient être imprimés sur du papier et les revues étaient expédiées à l'international. Chaque page supplémentaire entraînant un coût important, les articles étaient soumis à des limitations de longueur. Même un simple code de travail prend généralement beaucoup plus de place qu'une description informelle.

Aujourd'hui, il n'y a aucune bonne raison de ne pas inclure de code dans un type d'article faisant référence à un algorithme.

Il peut également être utile d’abandonner les formats orientés sur l’impression tels que pdf et postscript au profit de formats plus compatibles avec la sémantique (HTML avec MathML ou peut-être une variante opensource de Mathematica).