Degli esperimenti controllati, solo tre mostrano un effetto abbastanza grande da avere un significato pratico. Lo studio Prechelt che confronta C, C ++, Java, Perl, Python, Rexx e Tcl; lo studio di Endrikat confrontando Java e Dart; e l'esperimento di Cooley con VHDL e Verilog. Sfortunatamente, hanno tutti problemi che rendono difficile trarre una conclusione davvero forte.
Nello studio Prechelt, le popolazioni erano diverse tra lingue dinamiche e tipizzate e anche le condizioni per i compiti erano diverse. C'è stato uno studio di follow-up che ha illustrato il problema invitando Lispers a trovare le proprie soluzioni al problema, che ha comportato il confronto di persone come Darius Bacon con studenti casuali. Un follow-up al follow-up comporta letteralmente il confronto tra codice di Peter Norvig e codice di studenti universitari casuali.
Nello studio di Endrikat, hanno specificamente scelto un compito in cui pensavano che la tipizzazione statica avrebbe fatto la differenza e hanno attinto i loro soggetti da una popolazione in cui tutti avevano preso lezioni usando il linguaggio tipicamente statico. Non commentano se gli studenti abbiano o meno esperienza nella lingua tipizzata in modo dinamico, ma sembra sicuro supporre che la maggior parte o tutti abbiano meno esperienza nella lingua tipizzata in modo dinamico.
L'esperimento di Cooley è stato uno dei pochi che ha attirato persone da una popolazione non studentesca, il che è fantastico. Ma, come con tutti gli altri esperimenti, il compito era un compito giocattolo banale. Mentre sembra dannoso che nessuno dei partecipanti al VHDL (linguaggio statico) sia stato in grado di completare il compito in tempo, è estremamente insolito voler finire un progetto hardware in 1,5 ore ovunque al di fuori di un progetto scolastico. Si potrebbe sostenere che un'attività di grandi dimensioni può essere suddivisa in molte attività più piccole, ma un controprogramma plausibile è che ci sono costi fissi utilizzando VHDL che possono essere ammortizzati in molte attività.
Per quanto riguarda il resto degli esperimenti, il principale da asporto che ho da loro è che, in base alla specifica serie di circostanze descritte negli studi, qualsiasi effetto, se esiste, è piccolo.
Passando ai casi di studio, i due casi di ricerca di bug rendono interessante la lettura, ma in realtà non fanno un caso a favore o contro i tipi. Uno mostra che trascrivere i programmi Python su Haskell troverà un numero diverso da zero di bug di gravità sconosciuta che potrebbero non essere trovati attraverso test unitari orientati alla copertura di linea. La coppia di articoli Erlang mostra che è possibile trovare alcuni bug che sarebbero difficili da trovare attraverso qualsiasi tipo di test, alcuni dei quali sono gravi, utilizzando l'analisi statica.
Come utente, trovo conveniente quando il mio compilatore mi dà un errore prima di eseguire strumenti di analisi statica separati, ma questo è minore, forse anche inferiore alla dimensione dell'effetto degli studi controllati sopra elencati.
Ho trovato il case study di 0install (che ha confrontato varie lingue con Python e alla fine si è basato su Ocaml) per essere una delle cose più interessanti che ho incontrato, ma è il tipo di cosa soggettiva che ognuno interpreterà in modo diverso, che puoi vedere guardando .
Questo si adatta all'impressione che ho (nel mio piccolo angolo del mondo, ACL2, Isabelle / HOL e PVS sono i tester più comunemente usati e ha senso che le persone preferirebbero più automazione quando risolvono problemi nell'industria), ma questo è anche soggettivo.
E poi ci sono gli studi che estraggono i dati da progetti esistenti. Sfortunatamente, non sono riuscito a trovare nessuno che facesse qualcosa per determinare la causalità (ad esempio, trovare una variabile strumentale appropriata), quindi misurano solo le correlazioni. Alcune delle correlazioni sono inattese, ma non ci sono abbastanza informazioni per determinare il perché.
L'unico studio di data mining che presenta dati potenzialmente interessanti senza ulteriore esplorazione è la recensione di Bugshire su Python, ma non ci sono abbastanza informazioni sulla metodologia per capire cosa significhi realmente il suo studio, e non è chiaro perché abbia accennato a guardare dati per altre lingue senza presentare i dati3.
Alcune notevoli omissioni dagli studi sono studi completi che utilizzano programmatori esperti, per non parlare di studi che hanno una vasta popolazione di programmatori "buoni" o "cattivi", guardando qualsiasi cosa si avvicini a un progetto significativo (in luoghi in cui ho lavorato, un progetto di tre mesi sarebbe essere considerato piccolo, ma che è più ordini di grandezza più grandi di qualsiasi progetto utilizzato in uno studio controllato), usando linguaggi "moderni" tipicamente statici, usando la digitazione graduale / opzionale, usando gli IDE mainstream moderni (come VS ed Eclipse), usando gli IDE radicali moderni (come LightTable), usando editor di vecchia scuola (come Emacs e vim), facendo manutenzione su una base di codice non banale, facendo manutenzione con qualsiasi cosa che assomigli ad un ambiente realistico, facendo manutenzione su una base di codice che già conosci, ecc.
Se guardi il commento su Internet di questi studi, molti di questi vengono passati in giro per giustificare un punto di vista o un altro. Lo studio Prechelt su dinamico vs. statico, insieme ai follow-up su Lisp sono i favoriti perenni dei sostenitori del linguaggio dinamico, e lo studio di mining github è recentemente diventato alla moda tra i programmatori funzionali.