Qual è il compromesso per l'inferenza del tipo?

Sembra che tutti i nuovi linguaggi di programmazione o almeno quelli che sono diventati popolari usino l'inferenza del tipo. Anche Javascript ha ottenuto tipi e inferenze di tipo attraverso varie implementazioni (Acscript, dattiloscritto ecc.). Mi sembra fantastico, ma mi chiedo se ci siano dei compromessi o perché diciamo che Java o le vecchie buone lingue non hanno inferenza di tipo

• Quando si dichiara una variabile in Go senza specificarne il tipo (usando var senza un tipo o la sintassi: =), il tipo della variabile viene dedotto dal valore sul lato destro.
• D consente di scrivere frammenti di codice di grandi dimensioni senza specificare ridondanti tipi, come fanno i linguaggi dinamici. D'altra parte, l'inferenza statica deduce tipi e altre proprietà del codice, dando il meglio sia del mondo statico che di quello dinamico.
• Il motore di inferenza del tipo in Rust è piuttosto intelligente. Fa di più che guardare il tipo di valore r durante un'inizializzazione. Guarda anche come la variabile viene utilizzata in seguito per inferire il suo tipo.
• Swift utilizza l'inferenza di tipo per elaborare il tipo appropriato. Inferenza del tipo consente a un compilatore di dedurre automaticamente il tipo di un'espressione particolare quando compila il codice, semplicemente esaminando i valori forniti.

Il sistema di tipi di Haskell è completamente inferibile (lasciando da parte la ricorsione polimorfica, alcune estensioni del linguaggio e la temuta restrizione del monomorfismo ), ma i programmatori forniscono ancora frequentemente annotazioni di tipo nel codice sorgente anche quando non sono necessarie. Perché?

1. Le annotazioni dei tipi servono come documentazione . Ciò è particolarmente vero con tipi espressivi come quelli di Haskell. Dato il nome di una funzione e il suo tipo, di solito si può avere una buona idea di cosa fa la funzione, specialmente quando la funzione è parametricamente polimorfica.
2. Le annotazioni dei tipi possono favorire lo sviluppo . Scrivere una firma di tipo prima di scrivere il corpo di una funzione sembra un po 'come lo sviluppo test-driven. Nella mia esperienza, una volta compilata una funzione Haskell, di solito funziona per la prima volta. (Naturalmente, questo non elimina la necessità di test automatici!)
3. I tipi espliciti possono aiutarti a verificare i tuoi presupposti . Quando sto cercando di capire un codice che già funziona, lo aggiungo spesso a quelle che credo siano le annotazioni di tipo corrette. Se il codice viene ancora compilato, so di averlo capito. In caso contrario, ho letto il messaggio di errore.
4. Le firme di tipo consentono di specializzare le funzioni polimorfiche . Molto occasionalmente, un'API è più espressiva o utile se determinate funzioni non sono polimorfiche. Il compilatore non si lamenterà se si assegna a una funzione un tipo meno generale di quanto sarebbe dedotto. L'esempio classico è map :: (a -> b) -> [a] -> [b]. La sua forma più generale (fmap :: Functor f => (a -> b) -> f a -> f b ) si applica a tutti gli Functors, non solo agli elenchi. Ma si pensava che mapsarebbe stato più facile da capire per i principianti, quindi vive accanto al fratello maggiore.

Nel complesso, i lati negativi di un sistema staticamente tipizzato ma inferibile sono più o meno gli aspetti negativi della tipizzazione statica in generale, una discussione ben consumata su questo sito e altri (Googling "svantaggi della tipizzazione statica" ti porterà centinaia di pagine di guerre di fiamma). Naturalmente, alcuni di questi svantaggi sono migliorati dalla minore quantità di annotazioni di tipo in un sistema inferibile. Inoltre, l'inferenza di tipo ha i suoi vantaggi: sviluppo guidato dal foro non sarebbe possibile senza l'inferenza del tipo.

Java * dimostra che un linguaggio che richiede troppe annotazioni di tipo diventa fastidioso, ma con troppo pochi perdi i vantaggi che ho descritto sopra. Le lingue con deduzione di tipo opt-out raggiungono un piacevole equilibrio tra i due estremi.

_{* Anche Java, quel grande capro espiatorio, esegue una certa quantità di inferenza di tipo locale . In una dichiarazione come Map<String, Integer> = new HashMap<>();, non è necessario specificare il tipo generico del costruttore. D'altra parte, i linguaggi in stile ML sono generalmente inferibili a livello globale .}

In C #, l'inferenza del tipo si verifica in fase di compilazione, quindi il costo di runtime è zero.

Per motivi di stile, varviene utilizzato per situazioni in cui è scomodo o non necessario specificare manualmente il tipo. Linq è una di queste situazioni. Un altro è:

var s = new SomeReallyLongTypeNameWith<Several, Type, Parameters>(andFormal, parameters);

senza la quale ripeteresti il ​​tuo nome di tipo molto lungo (e i parametri di tipo) piuttosto che dire semplicemente var.

Utilizzare il nome effettivo del tipo quando esplicito migliora la chiarezza del codice.

Ci sono alcune situazioni in cui l'inferenza del tipo non può essere usata, come dichiarazioni di variabili membro i cui valori sono impostati al momento della costruzione, o in cui si desidera davvero che intellisense funzioni correttamente (l'IDE di Hackerrank non intellisense i membri della variabile a meno che non si dichiari esplicitamente il tipo) .

Buona domanda!

1. Poiché il tipo non è esplicitamente annotato, a volte può rendere il codice più difficile da leggere, portando a più bug. Naturalmente usato correttamente rende il codice più pulito e più leggibile. Se sei un pessimista e pensi che la maggior parte dei programmatori sia cattiva (o lavori dove la maggior parte dei programmatori è cattiva), questa sarà una perdita netta.
2. Mentre l'algoritmo di inferenza del tipo è relativamente semplice, non è gratuito . Questo genere di cose aumenta leggermente il tempo di compilazione.
3. Poiché il tipo non è esplicitamente annotato, il tuo IDE non può indovinare anche cosa stai cercando di fare, danneggiando il completamento automatico e aiutanti simili durante il processo di dichiarazione.
4. In combinazione con i sovraccarichi di funzione, è possibile che occasionalmente si verifichino situazioni in cui l'algoritmo di inferenza del tipo non è in grado di decidere quale percorso intraprendere, portando a brutte annotazioni sullo stile del casting. (Questo succede un po 'con la sintassi della funzione anonima di C # per esempio).

E ci sono più lingue esoteriche che non possono fare la loro stranezza senza un'annotazione esplicita del tipo. Finora, non ne conosco nessuno che sia abbastanza comune / popolare / promettente da menzionare se non per caso.

Mi sembra fantastico, ma mi chiedo se ci siano dei compromessi o perché diciamo che Java o le vecchie buone lingue non hanno inferenza di tipo

Java sembra essere l'eccezione piuttosto che la regola qui. Anche il C ++ (che credo sia qualificato come "buon vecchio linguaggio" :)) supporta l'inferenza di tipo con la autoparola chiave dallo standard C ++ 11. Funziona non solo con la dichiarazione variabile, ma anche come tipo di ritorno di funzione, che è particolarmente utile con alcune funzioni di template complesse.

La digitazione implicita e l'inferenza di tipo hanno molti buoni casi d'uso, e ci sono anche alcuni casi d'uso in cui davvero non dovresti farlo. Talvolta è questione di gusti e anche argomento di dibattito.

Ma che ci sono indubbiamente buoni casi d'uso, è di per sé una ragione legittima per qualsiasi linguaggio per implementarlo. Inoltre, non è difficile implementare funzionalità, nessuna penalità di runtime e non influisce in modo significativo sul tempo di compilazione.

Non vedo un vero svantaggio nel dare l'opportunità allo sviluppatore di usare l'inferenza del tipo.

Alcuni rispondenti ribadiscono quanto a volte la digitazione esplicita sia buona e hanno certamente ragione. Ma non supportare la digitazione implicita significherebbe che un linguaggio impone sempre la digitazione esplicita.

Quindi il vero svantaggio è quando una lingua non supporta la digitazione implicita, perché con ciò afferma che non c'è motivo legittimo per lo sviluppatore di usarla, il che non è vero.

La principale distinzione tra un sistema di inferenza di tipo Hindley-Milner e un'inferenza di tipo Go è la direzione del flusso di informazioni. In HM, digitare i flussi di informazioni in avanti e indietro tramite l'unificazione; in Vai, digita solo i flussi di informazioni in avanti: calcola solo le sostituzioni in avanti.

L'inferenza di tipo HM è una splendida innovazione che funziona bene con linguaggi funzionali tipicamente polimorficamente, ma gli autori di Go probabilmente sosterrebbero che cerca di fare troppo:

1. Il fatto che l'informazione fluisca sia in avanti che all'indietro significa che l'inferenza di tipo HM è un affare molto non locale; in assenza di annotazioni di tipo, ogni riga di codice nel programma potrebbe contribuire alla digitazione di una singola riga di codice. Se hai solo una sostituzione diretta, sai che l'origine di un errore di tipo deve essere nel codice che precede l'errore; non il codice che viene dopo.

2. Con l'inferenza di tipo HM, tendi a pensare vincoli: quando si utilizza un tipo, si vincolano i possibili tipi che può avere. Alla fine della giornata, potrebbero esserci alcune variabili di tipo che sono lasciate totalmente senza vincoli. L'intuizione dell'inferenza del tipo HM è che quei tipi non contano davvero, e quindi vengono trasformati in variabili polimorfiche. Tuttavia, questo polimorfismo extra può essere indesiderabile per una serie di ragioni. In primo luogo, come alcune persone hanno sottolineato, questo polimorfismo extra potrebbe essere indesiderabile: HM conclude un tipo fasullo, polimorfico per un codice fasullo, e porta a strani errori in seguito. In secondo luogo, quando un tipo viene lasciato polimorfico, ciò può avere conseguenze sul comportamento in fase di esecuzione. Ad esempio, un risultato intermedio eccessivamente polimorfico è il motivo per cui 'spettacolo. leggere 'è considerato ambiguo in Haskell; come altro esempio,

Fa male la leggibilità.

Confrontare

var stuff = someComplexFunction()

vs

List<BusinessObject> stuff = someComplexFunction()

È particolarmente un problema quando si legge all'esterno di un IDE come su github.