it-swarm.it

Studi linguistici dinamicamente vs staticamente tipizzati

Esistono studi condotti sull'efficacia di linguaggi tipizzati staticamente o dinamicamente?

In particolare:

  • Misurazioni della produttività del programmatore
  • Tasso di difetto

Includendo anche gli effetti dell'utilizzo o meno di unit test.

Ho visto molte discussioni sui meriti di entrambe le parti, ma mi chiedo se qualcuno abbia fatto uno studio al riguardo.

71
Winston Ewert

Alcuni hanno suggerito di leggere:

Non esattamente sulla digitazione statica, ma relativa:

Alcuni articoli o saggi interessanti sull'argomento o sull'analisi statica dei programmi in generale:

E per quelli che si chiederebbero di cosa si tratti:

Tuttavia, dubito che qualcuno di questi ti dia una risposta diretta, poiché non fanno esattamente lo studio che stai cercando. Saranno comunque letture interessanti.

Personalmente , ritengo fermamente che la digitazione statica rispetto alla digitazione dinamica faciliti il ​​rilevamento dei bug. Spendo troppi tipi alla ricerca di errori di battitura e piccoli errori come questi in JavaScript o anche nel codice Ruby. E quando si tratta dell'idea che la digitazione dinamica dia un impulso alla produttività, penso che si tratti principalmente di strumenti. Se le lingue tipizzate staticamente hanno gli strumenti giusti per consentire la ricompilazione in background e fornire un'interfaccia REPL, allora otterrai i vantaggi di entrambi i mondi. Scala lo fornisce ad esempio, il che semplifica l'apprendimento e la prototipazione nella console interattiva, ma offre i vantaggi della digitazione statica (e di un sistema di tipi più potente rispetto a molte altre lingue, ML -lingue a parte). Allo stesso modo, non penso di avere una perdita di produttività usando Java o C++ (a causa della tipizzazione statica), purché io usi un IDE che mi aiuti. Quando torno alla codifica solo con configurazioni semplici (editor + compilatore/interprete), mi sembra più facile usare linguaggi più ingombranti e dinamici. Ma cerchi ancora bug. Immagino che la gente direbbe che il problema degli strumenti è un argomento reversibile, come se gli strumenti fossero migliori per i linguaggi dinamici, quindi la maggior parte dei bug e degli errori di battitura verrebbero segnalati al momento della codifica, ma ciò riflette il difetto nel sistema secondo me. Tuttavia, di solito prototipo in JRuby e codifico in Java più tardi la maggior parte delle cose che faccio.

ATTENZIONE: Alcuni di questi collegamenti sono inaffidabili e alcuni passano attraverso portali di varie società di elaborazione utilizzando accessi a pagamento per i membri. Mi dispiace, ho cercato di trovare più collegamenti per ognuno di questi, ma non è buono come mi piacerebbe che fosse.

43
haylem

Proprio ieri ho trovato questo studio: Il test unitario non è abbastanza. Devi anche scrivere in modo statico.

Fondamentalmente l'autore ha utilizzato uno strumento in grado di convertire automaticamente un progetto da un linguaggio di battitura non statico in un linguaggio di battitura statico (da Python a haskell)

Quindi ha selezionato un numero di progetti open source Python che includevano anche una quantità ragionevole di unità di test e li ha convertiti automaticamente in haskell.

La traduzione in Haskell ha rivelato una serie di errori relativi al tipo di variabili: gli errori non sono stati scoperti dalle unità di test.

19
PBrando
  • Link alla discussione del documento ACM " An Experiment About Static and Dynamic Type Systems " (2010) di Stephan Hanenberg articolo (citato da Lorin Hochstein in un post precedente).
  • Conclusione: la produttività per una qualità simile era maggiore in un linguaggio dinamico.
  • Potenziali pregiudizi/problemi di validità: le materie sperimentali erano tutti studenti. Inoltre, una varietà limitata delle attività di programmazione (ai soggetti è stato chiesto di implementare uno scanner e un parser).
  • Documento ACM " I linguaggi di programmazione influiscono sulla produttività? " (2007) di Delorey, Knudson e Chun.
  • Conclusione: JavaScript, Tcl, Perl sono più produttivi di C # C++ e Java. Python e PHP cadono nel mezzo.
  • Potenziali pregiudizi/problemi di validità: nessuna misura di qualità (come i bug scoperti dopo il rilascio). Nessuna misura di affidabilità (il software scritto in linguaggi tipicamente statici è più affidabile?). Bias di esempio: tutti i progetti sono stati aperti presi da repository CVS open source. Inoltre, nessuna distinzione tra linguaggi debolmente e fortemente tipizzati (ovvero puntatori).
  • Tesi " Studio empirico di produttività e qualità del software " (2008) di Michael F. Siok
  • Conclusione: la scelta del linguaggio di programmazione non influenza in modo significativo la produttività o la qualità. Tuttavia, influisce sul costo del lavoro e sulla "qualità nel portafoglio complessivo dei progetti software".
  • Potenziali pregiudizi/problemi di validità: limitati al dominio avionico. I linguaggi di programmazione avrebbero potuto essere tutti digitati staticamente. Non ho letto la tesi, quindi non posso valutarne il rigore.
    La mia opinione. Sebbene ci siano prove deboli che le lingue tipizzate dinamicamente siano più produttive, non è conclusiva. (1) Ci sono molti fattori che non sono stati controllati, (2) ci sono troppo pochi studi, (3) c'è stata poca o nessuna discussione su ciò che costituisce un metodo di prova appropriato.
10
ahoffer

Ecco un punto di partenza:

L'articolo mette in discussione la saggezza comunemente ricevuta secondo cui, a parità di condizioni, i programmatori scrivono lo stesso numero di righe di codice alla volta, indipendentemente dalla lingua. In altre parole, il documento dovrebbe servire come prova empirica a sostegno del fatto che la produttività meccanica (righe di codice scritte) non è non una buona misura della produttività funzionale e deve almeno essere normalizzato dalla lingua.

6
Pi Delport

Ho trovato un Linguaggi statici vs. dinamici: una revisione della letteratura , che elenca alcuni studi sull'argomento e fornisce un bel riassunto su ogni studio.

Ecco il riassunto esecutivo:

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, tutti hanno 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 l'attività 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 asporto che ho da loro è che, in base alla specifica serie di circostanze descritte negli studi, qualsiasi effetto, se esiste, è piccolo.

Passando ai casi studio, i due casi studio 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 Python su Haskell troveranno 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 documenti Erlang mostra che puoi trovare alcuni bug che sarebbero difficili da trovare attraverso qualsiasi tipo di test, alcuni dei quali sono gravi, usando 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 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 tutti interpretare diversamente, 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 Small== di Python, ma non ci sono abbastanza informazioni sulla metodologia per capire cosa significhi realmente il suo studio, e non è chiaro il motivo per cui ha accennato a guardare i 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 con cui hai già familiarità, 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.

1
Mr.WorshipMe

Eccone alcuni:

  • Stefan Hanenberg. 2010. Un esperimento su sistemi di tipo statico e dinamico: dubbi sull'impatto positivo dei sistemi di tipo statico sui tempi di sviluppo. In Atti della conferenza internazionale ACM sui linguaggi e le applicazioni dei sistemi di programmazione orientata agli oggetti (OOPSLA '10). ACM, New York, NY, USA, 22-35. DOI = 10.1145/1869459.1869462 http://doi.acm.org/10.1145/1869459.1869462

  • Daniel P. Delorey, Charles D. Knutson, Scott Chun, "I linguaggi di programmazione influiscono sulla produttività? Un caso di studio che utilizza i dati di progetti open source", floss, pp.8, Primo seminario internazionale sulle tendenze emergenti nella ricerca e sviluppo FLOSS (FLOSS '07: Workshop ICSE 2007), 2007

  • Daly, M .; Sazawal, V., Foster, J .: Work in Progress: uno studio empirico sulla tipizzazione statica in Ruby, Workshop sulla valutazione e l'usabilità di linguaggi e strumenti di programmazione (PLATEAU) presso ON-WARD 2009.

  • Lutz Prechelt e Walter F. Tichy. 1998. Un esperimento controllato per valutare i vantaggi della procedura Verifica del tipo di argomento. IEEE Trans. Softw. Ing. 24, 4 (aprile 1998), 302-312. DOI = 10.1109/32.677186 http://dx.doi.org/10.1109/32.677186

0
Lorin Hochstein

Onestamente non penso che la tipizzazione statica vs dinamica sia la vera domanda.

Penso che ci siano due parametri che dovrebbero venire prima:

  • il livello di competenza nella lingua: più sei esperto, più conosci i "gotchas" e più hai probabilità di evitarli/rintracciarli facilmente. Questo vale anche per la particolare applicazione/programma su cui stai lavorando
  • test: adoro la tipizzazione statica (diavolo mi piace programmare in C++: p) ma c'è così tanto che un compilatore/analizzatore statico può fare per te. È impossibile essere sicuri di un programma senza averlo testato. E sono tutti per i test fuzzy (quando applicabile), perché non puoi proprio pensare a tutte le possibili combinazioni di input.

Se hai dimestichezza con la lingua, scriverai codice e rintraccerai facilmente i bug.

Se scrivi il codice disaccoppiato e collaudi ampiamente ogni funzionalità, allora otterrai un codice ben rifinito e quindi sarai produttivo (perché non puoi qualificarti come produttivo se non valuti la qualità del prodotto, vero? )

Ritengo pertanto che il dibattito statico vs dinamico in materia di produttività sia piuttosto controverso, o almeno ampiamente superato da altre considerazioni.

0
Matthieu M.