Studi linguistici dinamicamente vs staticamente tipizzati [chiuso]


69

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.


8
@bigown, non mi sembra che i problemi di produttività e difetti si riferiscano alla teoria dell'informatica
Winston Ewert,

2
@ Winston: studiare questo tipo di problemi è compito degli informatici, non dei programmatori.
Maniero,

9
@bigown, sì, è un problema di informatica ma non è un problema di teoria dell'informatica. La teoria CS si occupa essenzialmente di ciò che possiamo dimostrare matematicamente su programmi e informatica. I problemi di produttività del programmatore non sono domande di teoria CS. Ci sono state discussioni sulla tipizzazione dinamica sia qui che su StackOverflow. Non ce n'è stato nessuno su cstheory.
Winston Ewert,

8
La domanda è perfettamente sull'argomento. Questa domanda discute una delle proprietà più importanti degli strumenti che usiamo per programmare.
Frank Shearar,

4
@ Winston: i sistemi di battitura appartengono alla teoria CS, ma gli studi pratici no.
David Thornley,

Risposte:


42

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 a quella dinamica faciliti il ​​rilevamento dei bug. Passo troppi tipi a cercare errori di battitura e piccoli errori come questi in JavaScript o persino nel codice Ruby. E quando si tratta dell'idea che la digitazione dinamica dia un impulso alla produttività, penso che dipenda principalmente dagli strumenti. Se le lingue tipizzate staticamente hanno gli strumenti giusti per consentire la ricompilazione in background e fornire un'interfaccia REPL, allora si ottengono 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ù forte rispetto a molte altre lingue, a parte le lingue ML). Allo stesso modo, non credo di avere una perdita di produttività utilizzando Java o C ++ (a causa della tipizzazione statica), purché utilizzi 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 codificherò in Java in seguito la maggior parte delle cose che faccio. come se gli strumenti fossero migliori per i linguaggi dinamici, la maggior parte dei bug e degli errori di battitura sarebbero stati segnalati in fase di programmazione, ma ciò riflette a mio avviso il difetto nel sistema. Tuttavia, di solito prototipo in JRuby e codificherò in Java in seguito la maggior parte delle cose che faccio. come se gli strumenti fossero migliori per i linguaggi dinamici, la maggior parte dei bug e degli errori di battitura sarebbero stati segnalati in fase di programmazione, ma ciò riflette a mio avviso il difetto nel sistema. Tuttavia, di solito prototipo in JRuby e codificherò in Java in seguito la maggior parte delle cose che faccio.

ATTENZIONE: Alcuni di questi collegamenti non sono affidabili 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.


Quella ricerca di bug - è principalmente a causa di nomi di variabili scritti male, o nomi di metodi o da qualche parte nel mezzo? ( Detesto la dichiarazione di variabile implicita proprio per questo motivo: in Smalltalk, dichiari tutte le tue variabili in alto, quindi sai immediatamente quando hai sbagliato a digitare un nome di variabile. stato usato nell'immagine prima.))
Frank Shearar,

Per quanto riguarda gli strumenti, devo dire che dipende dalla tua lingua - Smalltalk ha strumenti eccellenti, tra cui un browser di refactoring che Eclipse deve (mi viene detto) che non ha ancora raggiunto.
Frank Shearar,

@Frank Shearar, da quando ho iniziato con Ruby (proveniente da Java), mi sono reso conto che ciò che dice @ haylem probabilmente non si applica a Smalltalk. Né il mio mantra sul refactoring automatico è impossibile nei lang tipizzati dinamicamente. Sono completamente d'accordo con la sezione "personalmente" di haylem .... ignorando ovviamente SmallTalk :) Questo è giusto, in una certa misura, dal momento che SmallTalk, sebbene non morto, non sta sicuramente godendo della popolarità che hanno Python o Ruby (ora nell'ottobre 2010 ).
Dan Rosenstark,

3
@haylem, personalmente ti ringrazio per avermi fatto sentire che non sono l'unica persona al mondo che lavora in linguaggi dinamici ma, quando viene scelta, molte volte SCEGLIE linguaggi tipicamente statici (stesso caso, Java vs. JRuby o Groovy).
Dan Rosenstark,

4
È interessante perché la mia preferenza per la digitazione dinamica è per ragioni piuttosto diverse. Voglio dire compilazioni veloci e interprete interattivo sono utili ma non sono il motivo per cui mi piace la digitazione dinamica. Mi piace la tipizzazione dinamica perché trovo molte situazioni in cui i linguaggi di tipizzazione statici rendono difficile l'impossibilità di descrivere un particolare concetto.
Winston Ewert,

19

Proprio ieri ho trovato questo studio: i test unitari non sono sufficienti. Hai anche bisogno di digitare staticamente.

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 Python open source 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.


4
Verità scomoda della digitazione dinamica.
Den

6
"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.": Con un linguaggio tipizzato dinamicamente devi testare manualmente le proprietà del tuo codice che in modo statico il linguaggio di tipo tipizzato viene controllato automaticamente dal compilatore. Ciò richiede più tempo ed è soggetto a errori. +1
Giorgio

4
Ho risposto a un post su questo link su Reddit. Non credo che le conclusioni tratte dal documento siano ragionevoli.
Veedrac,

Entrambi i sistemi di battitura hanno vantaggi e svantaggi. È come discutere di come portare una mitragliatrice in un combattimento corpo a corpo. Questa è una guerra religiosa lontana dalla fine. Detto questo, sono d'accordo con Veedrac. I linguaggi non statici richiedono più casi di test per rilevare errori causati dai tipi. Questa è la loro natura e contro. Tuttavia, un programmatore deve scrivere test che rilevino errori nel codice causati da uno stato di input imprevisto, non necessariamente test esaustivi per il tipo di input.
Andre Figueiredo,

10
  • 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 (es. 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.

6

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 per volta, indipendentemente dalla lingua. In altre parole, il documento dovrebbe servire da prova empirica a sostegno del fatto che la produttività meccanica (righe di codice scritte) non è una buona misura della produttività funzionale e deve almeno essere normalizzata dal linguaggio.


5
Per le persone non IEEE, qual è il riassunto di base?
Frank Shearar,

1
@ Frank Shearar, la conclusione che traggono è che il linguaggio di programmazione influisce sulla produttività. Stanno misurando le linee di codice per programmatore per lingua all'anno, non sono sicuro che sia una buona misura della produttività.
Winston Ewert,

3
@ Winston: è sicuramente una metrica imperfetta. Scopriresti che COBOL è un linguaggio molto produttivo: ci vogliono molte righe per fare qualcosa di utile, ma sono abbastanza facili da scrivere.
David Thornley,

Winston, David: Sono abbastanza sicuro che gli autori non stiano suggerendo che la produttività delle righe di codice sia una misura della produttività funzionale . Piuttosto, l'articolo sta sfidando la saggezza comunemente ricevuta che, a parità di condizioni, i programmatori scrivono lo stesso numero di righe di codice per volta, indipendentemente dalla lingua. In altre parole, il documento dovrebbe servire da prova empirica a sostegno del fatto che la produttività meccanica (righe di codice scritte) non è una buona misura della produttività funzionale e deve almeno essere normalizzata dal linguaggio.
Pi Delport,

Sono d'accordo. Ma non serve a rispondere alla mia domanda originale.
Winston Ewert,

1

Ho trovato un linguaggio statico contro un linguaggio dinamico: 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, 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.


0

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
  • testing: 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 codice disaccoppiato e collaudi ampiamente ogni funzionalità, allora producerai 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.


2
Se questa è una contro-domanda, dov'è la domanda? :) Concordo sul fatto che altri fattori sono più importanti della tipizzazione statica o dinamica. Tuttavia, i sostenitori della tipizzazione dinamica sostengono una migliore produttività e i sostenitori della tipizzazione statica rivendicano una migliore qualità del codice. Mi chiedevo se qualcuno avesse prove concrete a sostegno delle loro affermazioni.
Winston Ewert,

@ Winston: ho rimosso il bit del contatore: p Come hai già detto, è per lo più affermazioni. Penso che la maggior parte dei sostenitori della digitazione dinamica stia mescolando la facilità d'uso con la digitazione dinamica, mentre la facilità d'uso riguarda principalmente gli strumenti. Concordo sul fatto che la possibilità di scrivere prototipi rapidi da buttare via e di sperimentare comandi brevi usando un interprete sono un aumento della produttività, ma anche Haskell (forse il linguaggio con il sistema di tipi più impressionante del momento) ha un interprete per una rapida sperimentazione: )
Matthieu M.,

Ma fino a quando qualcuno non farà uno studio che considera questa domanda - se la metodologia, gli strumenti hanno un impatto maggiore del linguaggio sui tassi di difetto, sulla produttività - finiamo per confrontare gli aneddoti.
Frank Shearar,

0

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

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.