Con una tipizzazione statica sufficientemente avanzata, quali sono i vantaggi dei sistemi di tipo dinamico? [chiuso]

Question

Con una tipizzazione statica sufficientemente avanzata, quali sono i vantaggi dei sistemi di tipo dinamico? [chiuso]

#1 da (3 voti)

5

Questa domanda sembra essere abbastanza bene, ad esempio:

Tuttavia, molte domande e risposte sembrano confrontare linguaggi tipizzati staticamente come Java e C ++ con linguaggi tipizzati dinamicamente come Python e JavaScript. Questo sembra essere un confronto diverso: Java e C ++ sono prolissi, non interattivi e generalmente difficili da gestire per ragioni esterne ai loro sistemi di tipi.

Sono più interessato all'utilizzo di linguaggi statici come Swift o Haskell come base del confronto.

Queste lingue hanno REPL, codifica interattiva o equivalenti
Queste lingue hanno inferenza di tipo (come C ++)
Queste lingue hanno "generici" facili da usare
Queste lingue hanno ADT, che risolvono problemi come l'analisi JSON

Possiamo immaginare una variante di Swift con una forma di Digitazione strutturale , dove:

func foo(bar) { return bar.baz() }

È una sintassi valida per qualsiasi chiamata in cui viene passato un oggetto con un membro baz() e il tipo restituito è baz() dell'oggetto - creando effettivamente un protocol Foo<T> anonimo con membro func baz() -> T .

Questo può essere tradotto in JavaScript da s/func/function/g , ma tutto il tipo di sicurezza andrebbe perso.

Qual è il vantaggio della digitazione dinamica, rispetto a un linguaggio tipizzato statico con un buon sistema di tipi?

type-systems static-typing dynamic-typing

posta charl 05.06.2015 - 17:59

fonte

1 risposta

Leggi altre domande sui tag type-systems static-typing dynamic-typing

Creazione di riferimenti a oggetti bidirezionali e mantenimento dell'integrità dei dati In che modo le applicazioni distribuite verificano che i dati siano stati elaborati correttamente?

score 3 · Answer 1

Fondamentalmente, se il sistema di tipi è lì, il programmatore deve occuparsene. Può essere reso piuttosto "flessibile" (vale a dire, rimane fuori dalla tua strada in situazioni in cui il sistema di tipo come Java sarebbe un dolore) e implicito (quindi le annotazioni di tipo possono essere tralasciate quando non aggiungono valore), ma il programmatore deve occuparsene. Anche se ogni programma pratico e corretto non ha bisogno di annotazioni di tipo e "semplicemente funziona" (un IMHO di sogno di pipa), i programmatori scrivono programmi sbagliati - cogliere questi errori è l'intero punto di un sistema di tipi, dopotutto.

Presentato con un errore di tipo, il programmatore deve quindi comprendere il sistema di tipi per comprendere l'errore. In generale, i sistemi di tipo che consentono più implicità e sono più flessibili (nel senso indicato sopra) sono più complessi e difficili da comprendere. Naturalmente, per un dato livello di implicatezza e flessibilità, un buon design e buoni messaggi di errore possono fare la differenza, ma c'è un limite. Questo non vuol dire che questo è un cattivo compromesso, ma è un compromesso.

In pratica, i sistemi di tipi che tu chiami non soddisfano la condizione di cui sopra dei programmi corretti "appena funzionanti". Potresti sostenere che impongono lo stile di programmazione migliore e sono d'accordo, ma rifiutano programmi validi dello stile che le persone scrivono effettivamente. Ciò causa l'attrito. Ci sono molti aspetti positivi, ovviamente, ma sembra suggerire che si possa semplicemente smettere di scrivere JavaScript e ottenere gratuitamente tutte le garanzie di correttezza. Questo non è vero, bisogna capire il sistema dei tipi e abituarsi ai programmi di fraseggio in un modo che il sistema di tipi comprende. Ad esempio, in Haskell non puoi avere solo sottotipi ed eredità. Questo è un compromesso che offre ad Haskell alcuni vantaggi, ed è una scuola di design perfettamente valida, ma rende anche più difficili da implementare diversi progetti.