Il citato vantaggio di statica digitazione è che ci sono intere classi di errori catturati in fase di compilazione, che non possono raggiungere il runtime. Ad esempio, se hai una classe o un'interfaccia tipicamente tipizzata come parametro di funzione, allora stai dannatamente bene non passare inavvertitamente un oggetto del tipo sbagliato (senza un cast esplicito e non corretto, cioè).
Naturalmente, questo non impedisce di passare nell'oggetto sbagliato del tipo giusto o un'implementazione di un'interfaccia in cui le hai dato le giuste funzioni ma fanno le cose sbagliate. Inoltre, se hai una copertura del 100% del codice, dì la gente PHP/Python/etc, a chi importa se riscontri l'errore al momento della compilazione o in fase di esecuzione?
Personalmente, ho avuto momenti divertenti in lingue con digitazione statica e tempi divertenti in lingue senza. Raramente è il problema decisivo, dal momento che non ho mai dovuto scegliere tra due lingue identiche a parte il tipo di digitazione e di solito ci sono cose più importanti di cui preoccuparsi. Trovo che quando uso linguaggi tipizzati staticamente mi "appoggi al compilatore" deliberatamente, cercando di scrivere codice in modo tale che se è sbagliato, non verrà compilato. Ad esempio, ci sono alcuni refactoring che puoi eseguire apportando una modifica in un punto, e quindi correggendo tutti gli errori di compilazione che risultano, ripetere fino a compilazione pulita. Fare la stessa cosa eseguendo una suite di test completa diverse volte potrebbe non essere molto pratico.Ma non è raro che gli IDE automatizzino gli stessi refact in altre lingue o che i test vengano completati rapidamente, quindi è una questione di cosa è conveniente, non di ciò che è possibile.
Le persone che hanno una preoccupazione legittima oltre la convenienza e la preferenza di stile di codifica sono quelle che lavorano su prove formali della correttezza del codice. La mia impressione ignorante è che la deduzione di tipo statico può fare la maggior parte (ma non tutte) del lavoro che esegue la tipizzazione statica esplicita e consente di risparmiare considerevole usura sulla tastiera. Quindi, se la digitazione statica obbliga le persone a scrivere codice in un modo che faciliti la dimostrazione, quindi potrebbe esserci qualcosa da quel POV. Dico "se": non lo so, e non è come se molte persone provassero comunque il loro codice tipizzato staticamente.
cambiare i tipi di variabili al volo e tale
Penso che sia di dubbia utilità. E 'sempre così forte la tentazione di fare qualcosa di simile (Python/Django):
user = request.GET['username']
# do something with the string variable, "user"
user = get_object_or_404(User,user)
# do something with the User object variable, "user"
Ma in realtà, dovrebbe lo stesso nome utilizzato per cose diverse all'interno di una funzione? Può essere. Probabilmente no. "Ri-usare", per esempio, le variabili intere per altre cose in lingue tipizzate staticamente non sono nemmeno fortemente incoraggiate. Il desiderio di non dover pensare, nomi di variabili descrittive concisi, probabilmente il 95% del tempo non dovrebbe ignorare il desiderio di codice univoco ...
Btw, di solito debole digitazione significa che si verificano conversioni di tipo implicite, e strong digitando significa che non lo fanno. Con questa definizione, C è debolmente tipizzato per quanto riguarda i tipi aritmetici, quindi presumo che non sia quello che intendi. Penso che sia ampiamente considerato che la tipizzazione completa sia più un fastidio che un aiuto, e che "la digitazione completa" (qualsiasi cosa possa essere convertita a qualsiasi altra cosa) è priva di senso nella maggior parte delle lingue. Quindi la domanda è su quante e quali conversioni implicite possono essere tollerate prima che il codice diventi troppo difficile da capire. Vedi anche, in C++, la continua difficoltà nel decidere se implementare operatori di conversione e costruttori di un arg non espliciti.
Cosa intendi per digitazione "forte" e "debole"? Statico e dinamico? Nomi di tipo espliciti o impliciti? Casting esplicito vs implicito? Casting sicuro e non sicuro? – dan04
C è debolmente digitato. –
Com'è C 'fortemente tipizzato'? – chimeracoder