Per me sembra che le ragioni siano due:

• la convinzione che il codice sia solo uno strumento, una particolare implementazione essendo secondaria rispetto all'idea o all'algoritmo,
• il residuo storico (era poco pratico stampare molte pagine; soprattutto perché nessuno poteva copiarlo e incollarlo).

Inoltre:

• molti lo scienziato sembra aver paura di mostrare il proprio codice in pubblico, poiché è consapevole della sua scarsa qualità (vedi anche Perché molti scienziati di talento scrivono software orribile?), quindi non vogliono rischiare la reputazione (sia per la qualità che per la cattura di possibili errori).

Inoltre, le cose relative agli incentivi attuali nel mondo accademico (dove le pubblicazioni, non il codice, sono legate alle proprie possibilità di carriera):

• condividere il codice può comportare il rischio di essere scoperti (invece di mungere lo stesso codice per anni),
• la pulizia del codice richiede tempo, che può essere utilizzato per scrivere altre pubblicazioni.

Le persone devono inviare il loro codice privatamente al r almeno gli osservatori, in modo che possano riprodurre l'esperimento, se possibile.

Tipicamente - no. Se il codice non viene reso pubblico, quasi sicuramente nessun revisore ne ha verificato l'esistenza; molto meno: correttezza.

Tuttavia, molti scienziati stanno iniziando a notare il problema (e vedono come fiorisce la cultura open source). Quindi, ci sono nuove iniziative che affrontano questo problema, come il Science Code Manifesto:

Il software è una pietra angolare della scienza. Senza software, la scienza del ventunesimo secolo sarebbe impossibile. Senza un software migliore, la scienza non può progredire.

O ad es. questo manifesto. Prova a cercare ricerche riproducibili o guarda cose come knitr per R e questa introduzione a IPython Notebook, oppure leggi informazioni sull ' utilizzo GitHub per la scienza. E sembra che stia decollando.

Di quale campo stai parlando? Un documento CS che descrive la progettazione e le prestazioni di un algoritmo di visione artificiale è diverso da un documento di sociologia che utilizzava un foglio di calcolo per elaborare i dati demografici.

La maggior parte delle riviste / conferenze si "fidano" di quelle persone che inviare l'articolo ha davvero implementato la teoria e ottenuto quei risultati esatti?

Sì. La presunzione è sempre che non vi siano frodi scientifiche coinvolte.

Ho sempre avuto l'idea che qualsiasi esperimento dovrebbe essere riproducibile da altri, altrimenti non è scientificamente giustificato.

Se gli algoritmi sono completamente descritti nel documento, il risultato è riproducibile. Per riprodurlo, devi reimplementare l'algoritmo.

Ho appena iniziato a leggere alcuni documenti e ho pensato ora di dare un'occhiata al codice e sono rimasto piuttosto sorpreso dal fatto che la maggior parte dei documenti non abbia alcun codice da guardare, pur rivendicando alcune prestazioni o essendo migliore di altri documenti.

Presumibilmente la migliore prestazione è perché l'algoritmo descritto nel documento è un algoritmo più efficiente. Ad esempio, quando si ordina una grande quantità di dati, un Quicksort è un algoritmo di ordinamento migliore di un Bubble Sort. Il quicksort ha in media prestazioni O (n log n), mentre il bubble sort ha O (n ^ 2), e questo è vero indipendentemente dai dettagli dell'implementazione.

Penso che un problema correlato a quello sollevato da Piotr (+1) è che i finanziamenti per la ricerca non sono generalmente disponibili per coprire i costi di produzione di codice portatile altamente affidabile o i costi di manutenzione / supporto del codice prodotto per la "ricerca qualità". Ho scoperto che questo è un problema significativo quando provo a utilizzare codice rilasciato da altri ricercatori nel mio campo; troppo spesso non riesco a far funzionare il loro codice perché utilizza una libreria di terze parti che non è più disponibile, o che funziona solo su un PC Windows, o che non funziona più sulla mia versione del software perché utilizza alcune deprecate caratteristica della lingua / ambiente. L'unico modo per aggirare questo problema è reimplementare le routine dalla libreria di terze parti in modo che tutto il codice venga fornito come un singolo programma monolitico. Ma chi ha il tempo di farlo in un ambiente "pubblica o muori" sottofinanziato?

Se la società vuole che un codice di alta qualità accompagni ogni documento, allora la società deve mettere a disposizione fondi in modo che i bravi ingegneri del software possano scrivere e mantenerlo. Sono d'accordo che sarebbe una buona cosa, ma non è a costo zero.

Sembra che tu pensi che dovremmo richiedere il codice, perché senza codice, qualsiasi risultato folle, sia esso una frode o un errore onesto, può essere inserito nel giornale. Ma non è così. Includere il codice è una caratteristica piacevole da avere, non una caratteristica indispensabile. Le altre risposte lo presumono silenziosamente e spiegano le ragioni (buone e non così buone) che portano alla situazione attuale del codice insolitamente incluso. Penso di poterli completare spiegando perché non è una caratteristica indispensabile.

Per risultati teorici, non è necessario alcuno strumento empirico come il codice per riprodurli, come altri hanno menzionato (ad esempio, dimostrare che un algoritmo ha un comportamento O maggiore migliore di un altro). Naturalmente, ci sono anche risultati empirici, che non possono essere replicati in questo modo.

Ma i tuoi revisori avranno un'aspettativa di ciò in cui si tradurrà la tua idea. Se la migliore performance attuale per wugging zums è di 3 zums / se aggiungi una piccola modifica e segnali 300 zums / s, il tuo i revisori dovrebbero notare che la tua richiesta è insolita e fare qualcosa (possibilmente chiedere di inviare nuovamente il codice). Questo non è infallibile, ma con più revisori per articolo è efficace, perché l'entità dei risultati più empirici è prevedibile una volta che il revisore vede l'idea e capisce come funziona.

Per questa classe di articoli, sia gli errori onesti che quelli disonesti hanno buone possibilità di essere scoperti, con risultati negativi per gli scienziati onesti (perdita di reputazione, specialmente se scoperti dopo la pubblicazione) e risultati peggiori per gli scienziati disonesti (fine di carriera se provata!). Inoltre, più grave è l'errore (misurato nella dimensione dell'errore), maggiore è la possibilità di essere scoperti. È meno probabile che tu venga scoperto se il tuo algoritmo gestisce 4 zums / se segnali 5 zums / secondo, rispetto a quando segnali 300 zums / s. Quindi, gli scienziati sono disincentivati ​​a presentare documenti errati, lasciando quelli meno errati nel pool presentato, ei revisori prendono molto del resto.

Ci sono casi in cui è totalmente sconosciuto il motivo per cui un'osservazione è così com'è, e in questi casi è molto importante descrivere perfettamente la configurazione esatta del test. Ma non ho mai visto questo tipo di articolo in informatica, è associato alle scienze naturali. Quindi nessun codice lì. Anche se hai ottenuto tali risultati in informatica (ad esempio hai osservato che gli utenti sono in grado di leggere un EULA di 12000 parole in meno di 30 secondi, il che contraddice le comuni osservazioni sulla velocità di lettura e non hai spiegazioni per questo), è improbabile che includa il codice utilizzato per ottenere il risultato sarà pertinente alla replica.

Per metterlo insieme, tra una grande massa di articoli di informatica, quelli teorici e quelli di osservazione dei fenomeni naturali non hanno bisogno dell'inclusione del codice per la replica, e quelli rimanenti conterranno solo un basso percentuale di documenti errati ma non presi. Complessivamente, ciò porta a un livello accettabilmente basso di documenti non corretti inviati. Richiedere il codice per accompagnarli aumenterà la qualità di una classe di carta, ma sarà un aumento di un livello di qualità già elevato. Non è che non avere questa caratteristica renda la qualità attuale troppo bassa.

Perché ad alcuni ricercatori non piace pensare al mondo reale e i revisori non vogliono il fastidio.

(Il prossimo è un po 'uno sproloquio)

Ho ha recentemente svolto un sondaggio su un tipo specifico di algoritmi relativi alla geometria. In tutti i documenti il ​​programma veniva descritto come funzionante perfettamente, ma una volta che ho richiesto il codice sorgente a una dozzina di autori le cose sono diventate brutte.

Il 50% del software mancava di importanti caratteristiche pubblicizzate. Ad esempio, il software funzionerebbe solo in 2D mentre il documento mostrava esempi 3D. (Che nel mio caso rende davvero le cose molto più difficili). Dopo aver chiesto il motivo per cui queste funzionalità mancavano, di solito non erano mai state implementate o erano state implementate ma si sono rivelate instabili / non funzionanti. Per essere chiari: era impossibile al 100% generare i risultati mostrati nel documento con un software che spesso veniva persino migliorato dopo il rilascio del documento.

Il 75% del software non funzionava perfettamente in casi normali . Nel mio caso questo di solito è dovuto al fatto che l'algoritmo è stato progettato pensando ai "numeri perfetti", ma l'algoritmo è stato implementato utilizzando normali numeri in virgola mobile e quindi ha avuto problemi di rappresentazione che hanno portato a grandi errori. Solo pochi articoli hanno menzionato questi problemi e solo due hanno cercato di risolverli (parzialmente).

L'85% del software non funzionerebbe in scenari progettati specificamente per trovare casi di problemi. Diciamo la verità; se un "semplice" studente riesce a trovare in poche settimane uno scenario che rompe totalmente il tuo algoritmo, probabilmente lo sai già.

Non fornire codice rende possibile mentire e con mio disgusto (sono nuovo al mondo accademico) questo viene fatto molto spesso. Il mio supervisore non era nemmeno sorpreso. Tuttavia, testare il codice è molto faticoso, quindi questo comportamento probabilmente rimarrà deselezionato per un po 'più a lungo.

In qualità di editore associato di una rivista (che collega statistiche e psicologia), ho chiesto agli autori di inviare il codice quando hanno proposto nuovi algoritmi e procedure, quindi ho inviato il codice agli esperti nel pacchetto statistico per verificare che (un ) il codice fa ciò che descrive l'articolo e (b, secondario) che è un buon codice (robusto per input non validi, efficace dal punto di vista computazionale, ecc.). Mi è stato anche chiesto di rivedere alcuni documenti per Stata Journal il cui focus è il codice, e ho fatto lo stesso. Ci sono stati momenti in cui (a) ha fallito, quindi ho dovuto restituire l'articolo e dire che gli autori dovevano allineare la metodologia e il codice. Ci sono stati momenti in cui (b) falliva, e nel caso di Stata Journal, ciò significherebbe anche restituire il documento. Ci sono stati momenti in cui il codice non arrivava.

La maggior parte delle volte sarei felice di condividere il mio codice, ma è abbastanza complicato (con controlli interni basati sui metadati, output personalizzato, ecc.) che un ricercatore meno esperto con i pacchetti Io uso non sarò in grado di modificarlo per farlo funzionare sul loro computer.

Tornando alla tua domanda principale: i revisori sono pigri a corto di tempo e hanno il loro proprie ricerche da spingere alle loro riviste, così pochi di loro si impegnano per verificare completamente i risultati. È così che va il mondo. Forse questi professori ordinari potrebbero richiedere il codice e darlo ai loro studenti laureati con cui giocare, interrompere e fare il debug, poiché questa sarebbe una buona opportunità educativa per questi ultimi. Ma ancora una volta questo non accade molto spesso, poiché le clausole di riservatezza per accettare il ruolo di revisore di solito precludono la condivisione del documento con qualcun altro.

Vorrei aggiungere un punto di vista leggermente diverso da un campo sperimentale (chimica / spettroscopia / analisi chemiometrica dei dati).
Qui lo studio inizia in laboratorio (o forse sul campo), con un tipo di taccuino antiquato. Tipicamente vecchio stile ancora carta + penna. L'analisi dei dati viene spesso eseguita con programmi GUI in modo interattivo. Le registrazioni vengono conservate proprio come in laboratorio: carta + penna. Forse con alcune figure salvate e / o stampate. Poiché già la parte in laboratorio è stata registrata in questo modo, non avere un file di registro o anche uno script di analisi dei dati non è visto come un problema. Ad ogni modo, chiedere la pubblicazione del codice è solo una parte di ciò di cui hai bisogno per rieseguire l'analisi: avresti anche bisogno dei dati effettivi.
Già il suggerimento di digitare l'analisi dei dati e almeno di salvare uno un registro della sessione matlab / R o digitarlo in forma di script è ancora un po 'nuovo (anche se le persone adorano i report generati da knitr che produco ...). Ma IMHO le cose si stanno muovendo abbastanza velocemente ora. Direi che con strumenti come git e knitr i maggiori ostacoli pratici sono quasi risolti almeno per il tipo di persona che preferisce il codice al clic. Tuttavia, non è che tutto funzioni già senza intoppi (considera dati binari grezzi di grandi dimensioni e git , e ammetto francamente che non ho idea di come impostare praticamente un server di database "reale" in modo efficiente che tiene traccia delle modifiche). Questo è dal mio punto di vista di scienziato che ha solo bisogno di strumenti per la riproducibilità come utente - e quindi capisco i miei colleghi non programmatori che tuttavia devono analizzare i loro dati: semplicemente non hanno di) gli strumenti che consentirebbero loro di registrare le proprie analisi con uno sforzo ragionevole.

La stima tradizionale di dove si nascondono le grandi difficoltà si concentra anche sulla parte di laboratorio. Penso che molti ricercatori semplicemente non siano consapevoli dei problemi di riproducibilità con i calcoli / analisi dei dati. Ad essere onesti, di solito condivido questo punto di vista: IMHO in biospettroscopia uno dei grandi problemi importanti è il numero troppo basso di individui negli studi. Se hai solo 4 topi nello studio, la gestione precisa dei dati non può influenzare troppo le conclusioni pratiche. C'è una zona grigia in cui non eseguire una corretta convalida può influenzare le conclusioni, ma ancora: tutti quelli che conosco che eseguono la convalida secondo la pratica più nota lo spiegano in modo molto esplicito - quindi di nuovo (e accettando qualche rischio di falsamente scartando pochi documenti come "probabilmente non riproducibili") tendo a pensare che le conclusioni pratiche siano difficilmente influenzate.

D'altra parte, guardando i requisiti che ad es. le comunicazioni chimiche messe in campo se una nuova sostanza chimica deve essere pubblicata, non vedo perché non possano esserci riviste di informatica che richiedono il codice in modo simile.
Come ad es. il Journal of Statistical Software lo fa. (Sono abbastanza sicuro che esistano altre riviste simili, ma non le conosco.)

Per me questo rientra in un campo molto più ampio di questioni di riproducibilità. Naturalmente, se l'analisi dei dati non può essere riprodotta, ci sono grossi problemi.

Ancora un altro punto: sebbene le pubblicazioni sul software siano ancora molto rare nel mio campo, di recente ho avuto un documento del genere per la revisione. Sfortunatamente, si propone di distribuire il software contattando uno degli autori - cosa che, in quanto revisore anonimo, ovviamente non ho potuto fare.
Pertanto, il software vero e proprio potrebbe essere ancora meno accessibile per i revisori che per i lettori normali!

Penso che la maggior parte dei lettori / revisori troverebbe un algoritmo sufficientemente dettagliato abbastanza. Scrivi il tuo articolo mostrando, oh, codice C ++, e io uso SPSS nel mio negozio - il tuo codice è inutile per me. Non che la maggior parte dei lettori si divertirà a reimplementare il codice (specialmente per i documenti non CS), ma con un codice specifico che gira su una piattaforma specifica, ci sarà sicuramente un sacco di disordine da attraversare. Un algoritmo lo riduce all'essenziale.

Se il mio articolo mostra il miglioramento della velocità del mio nuovo metodo Quicksort rispetto allo standard Bubble Sort, mostrare algoritmi per i due metodi renderebbe più facile supportare le mie affermazioni per O (n log n) rispetto a O (n ^ 2) accelerazione. Se il mio articolo riguarda la distribuzione dell'età della popolazione nelle economie ricche rispetto a quelle in via di sviluppo, a meno che non ci sia un trucco davvero accurato che ho usato per elaborare i dati, la maggior parte dei lettori probabilmente non si preoccuperebbe nemmeno dell'algoritmo, tranne che in pennellate molto ampie.

Dipenderà dall'area tematica (generale, diciamo, Informatica) e dalla sottoarea specifica (diciamo, metodi di ordinamento), nonché dall'impatto che l'algoritmo utilizzato ha sui risultati, dal fatto che l'algoritmo sia necessario. Se mostro le differenze del compilatore nel codice Fortran, sarebbe bene includere il codice effettivo. Altrimenti, il codice stesso è raramente interessante.

Questa è una visione di Computer Science / Theoretical Computer Science / Mathematics.

Chiediti: qual è il pubblico di destinazione di un articolo accademico?

non gli utenti finali. Sono i revisori ! I revisori vogliono il codice? Dipende dalla situazione. A volte lo fanno. Spesso non lo fanno.

Pensa a questo: perché i matematici non forniscono dimostrazioni formali ma usano argomenti informali?

È costi contro benefici. Fornire una prova formalmente verificata è possibile, ma di solito richiede troppo lavoro, lavoro per il quale gli autori non sono formati e con cui non hanno molta esperienza. D'altra parte, cosa ci guadagnano gli autori? Aiuta a convincere i revisori della correttezza dei risultati? No, di solito i revisori preferiscono una breve spiegazione informale che consenta loro di capire e vedere perché il risultato è vero. Una prova formale di solito non aiuta molto. Ci sono persone a cui non piacciono le prove assistite dal computer che non possono essere verificate e comprese direttamente dagli esseri umani.

Lo stesso pensiero sui costi e sui benefici si applica ai programmi. Se fornire il codice non aiuta a convincere il revisore della correttezza dell'articolo, perché sprecare risorse (tempo / denaro / pagine / ...) per farlo? I revisori hanno il tempo di leggere codici con migliaia di righe per verificare che non ci siano bug in essi?

D'altra parte, a volte il software risultante dalla carta è di interesse primario. Avere il codice è utile per verificare i reclami. Per esempio. affermi di avere un algoritmo più veloce per SAT. Quindi è utile fornire il codice. In questi casi gli autori forniscono il loro codice. Questo è principalmente in parti più sperimentali. Non ci interessa la correttezza del codice ma ottenere risultati migliori rispetto agli algoritmi esistenti. In tali situazioni ci sono tipicamente benchmark standard per confrontare gli algoritmi. (Vedi ad esempio competizioni SAT.) Se non ci sono benchmark stabiliti, perché pubblicare codice? Se è un risultato teorico in cui i benefici asintotici si verificano su istanze troppo grandi per essere testate, qual è il vantaggio di avere il codice? Tanto più considerando il fatto che il codice di grandi dimensioni sviluppato da programmatori non professionisti è altamente probabile che sia difettoso? Impiegare sviluppatori di software professionisti per sviluppare codice di qualità è costoso ( il reddito annuale medio per una persona con uno scapolo in CS è di circa 100.000 negli Stati Uniti) (tranne forse come studenti laureati;) e in genere non lo fa avere dei profitti in seguito.

Ma il codice deve essere incluso nei documenti? Ovviamente no! Esistono modi migliori per pubblicare codice, ad es. avere un collegamento nel giornale a una copia online (sul loro sito web o un repository pubblico come github). Perché si preferisce includere un codice con migliaia di righe all'interno di un documento che dovrebbe essere letto da esseri umani ?

Di solito le "prestazioni" del codice si riferiscono a "quanto bene si adatta alla dimensione del problema". Ciò significa, a mio parere, che un documento che afferma che "l'algoritmo A è più veloce dell'algoritmo B" deve mostrare i tempi sia per A che per B _ per problemi di dimensioni diverse_. Sebbene possano ancora esserci inefficienze (ed errori) nelle implementazioni, questo dimostrerà almeno se l'algoritmo sottostante è più efficiente (basso big-oh).

Dove il software è la chiave del documento (il prodotto, non lo strumento) mi aspetto che sia disponibile (github o altro). Quindi un documento che dice "Posso ordinare in ordine 1 / n kerfugling il numero dargibold" deve mostrare come è stato fatto; il documento che afferma "quando ho ordinato questi due set di dati, quello di Whoville aveva flubbit più grandi" non ha bisogno di mostrare come è stato ordinato il codice - devono concentrarsi sullo spiegare cosa c'è di significativo nei flubbit di Whoville.

Tratto dal libro SKIENA, S. The Algorithm Design Manual: Springer. 2008:

Dopo una lunga ricerca, Chazelle [Cha91] ha scoperto un algoritmo tempo lineare per triangolare un semplice poligono. Questo algoritmo è sufficientemente disperato da implementare da qualificarsi più come una prova di esistenza.

[Cha91] CHAZELLE, Bernard. Triangolazione di un semplice poligono in tempo lineare. Discrete & Computational Geometry , 1991, 6.3: 485-524.

Penso che gli autori considerino costi e benefici ed evitino la presentazione di codice quando i costi superano i vantaggi.

Secondo David W. Hogg i costi sono:

1. potresti essere preso
2. puoi essere imbarazzato dal tuo brutto codice, o dalla tua incapacità di commentare o documentare
3. dovrai rispondere a domande (e spesso stupide o irrilevanti) sul codice e passare il tempo a documentare
4. dovrai prendere in considerazione le richieste pull o comunque mantenere il codice, possibilmente lontano nel futuro
5. potresti dover abbattere risultati negativi e errati generati con il tuo codice
6. la tua reputazione potrebbe risentirne se il codice viene utilizzato in modo errato
7. potrebbero esserci problemi legali (inclusi quelli militari) e di licenza

I vantaggi sono:

1. più scienza viene fatto, vengono scritti più documenti; tutte le misure di aumento dell'impatto
2. ottieni la motivazione per pulire e documentare il codice
3. i risultati diventano (più) riproducibili e (più) affidabili
4. gli estranei trovano bug o apporta miglioramenti al codice e invia richieste pull
5. ottieni credibilità e visibilità e costruisci una community
6. i tassi di citazione potrebbero aumentare
7. il codice viene preservato
8. il codice diventa ricercabile (anche da te!) e sottoposto a backup
9. ci sono buoni siti per l'archiviazione a lungo termine e l'interfaccia
10. può stabilire la priorità su un'idea o arte anteriore su un metodo

Perché in verità la maggior parte dei ricercatori accademici in campi tecnici non può programmare per salvare le proprie vite. Nella visione artificiale, hanno semplicemente hackerato qualcosa insieme in un singolo file Matlab. A loro piace pensare che la programmazione sia per gli studenti universitari. Credono che sia inutile sprecare il loro tempo in queste banalità. La maggior parte di loro non ha mai imparato buone pratiche di ingegneria del software e non ha una comprensione della complessità e delle abilità necessarie per scrivere un buon codice.

Il problema principale è che questo è supportato dai ricercatori perché tutto il mondo accademico si preoccupa è l'editoria, la quantità sulla qualità. Il successo è misurato da quante citazioni hai, non da quanto sono buoni i tuoi contributi. Alla fine della giornata, quando le uniche persone che ti citano non producono nulla di utile, non importa. Non è più scienza quanto è "ricerca per il bene di fare ricerca".