Statico / tipizzazione forte e refactoring

Question

Mi sembra che la cosa più preziosa di un linguaggio di programmazione statica / fortemente tipizzato è che aiuta refactoring:. Se / quando si cambia qualsiasi API, il compilatore vi dirà cosa che il cambiamento si è rotto

Posso immaginare la scrittura di codice in un / linguaggio debolmente tipizzato runtime ... ma non riesco a immaginare il refactoring senza l'aiuto del compilatore, e non riesco a immaginare la scrittura di decine di migliaia di righe di codice, senza refactoring.

E 'vero?

Answer 1

Credo che tu stia confondendo quando tipi vengono controllati con come stanno controllati. tipizzazione runtime non è necessariamente debole.

Il principale vantaggio di tipi statici è esattamente quello che dici: sono esaustive. Si può essere sicuri tutti i siti delle chiamate conformi al tipo semplicemente lasciando che il compilatore fa è cosa.

Il limite principale di tipi statici è che sono limitati a vincoli che possono esprimere. Questo varia per lingua, con la maggior parte dei linguaggi avere sistemi relativamente semplici di tipo (c, Java), e altri con i sistemi estremamente potenti di tipo (Haskell, Cayenne).

A causa di questo tipo di limitazione da soli non sono sufficienti. Ad esempio, nei tipi di Java sono più o meno limitato a controllare i nomi tipo di corrispondenza. Questo significa che il significato di ogni vincolo si desidera controllato deve essere codificato in uno schema di denominazione di qualche tipo, quindi la pletora di indirections e piastra caldaia comune a codice Java. C ++ è un po 'meglio in quanto modelli consentono un po' più espressività, ma non venire vicino a quello che si può fare con tipi dipendenti. Non sono sicuro di quello che gli aspetti negativi per i sistemi di tipo più potenti sono, anche se chiaramente ci deve essere qualche o più persone sarebbero li utilizzeranno nell'industria.

Anche se si sta utilizzando tipizzazione statica, è probabile che non è sufficientemente espressivo per controllare tutto ciò che interessa, quindi avrai bisogno di scrivere test troppo. Sia tipizzazione statica consente di risparmiare più sforzo che si richiede in boilerplate è un dibattito che ha imperversato per secoli e che non credo che ha una risposta semplice per tutte le situazioni.

Per quanto riguarda la seconda domanda:

Come possiamo ri-fattore in modo sicuro in una lingua runtime tipizzato?

La risposta è test. I test devono coprire tutti i casi che contano. Strumenti possono aiutare a misurare come esaustivo i test sono. strumenti di copertura verifica farvi sapere linee wether di codice sono coperti dai test o meno. strumenti di test di mutazione (giullare, Heckle) può sapere se i test sono logicamente incompleta. Prove di accettazione farvi sapere quello che hai scritto requisiti di partite, e infine test di regressione e di performance garantire che ogni nuova versione del prodotto mantiene la qualità degli ultimi.

Una delle grandi cose di avere una corretta sperimentazione in atto vs basandosi su indirections tipo elaborati è che il debugging diventa molto più semplice. Quando si esegue il test si ottiene specifiche asserzioni fallite all'interno di test che esprimono in modo chiaro quello che stanno facendo, piuttosto che dichiarazioni di errore del compilatore ottusi (si pensi c ++ errori di modello).

Non importa quali strumenti si utilizzano: la scrittura di codice che siete sicuri nel richiederà impegno. E 'molto probabile che sarà necessario scrivere un sacco di test. Se la pena per i bug è molto alta, come l'aerospaziale o software di controllo medico, potrebbe essere necessario utilizzare metodi matematici formali per dimostrare il comportamento del software, il che rende tale sviluppo estremamente costoso.

Answer 2

Sono totalmente d'accordo con il tuo sentimento. La stessa flessibilità che le lingue dinamicamente tipizzati si suppone di essere bravo in realtà è ciò che rende il codice molto difficile da mantenere. In realtà, c'è una cosa come un programma che continua a funzionare se i tipi di dati vengono modificati in modo non banale senza modificare il codice?

Nel frattempo, si potrebbe verificare il tipo di variabile essere passato, e in qualche modo riuscire se non è del tipo previsto. Farebbe ancora necessario eseguire il codice per sradicare questi casi, ma almeno qualcosa lo direi.

Credo che gli strumenti interni di Google effettivamente fare una compilation e, probabilmente, tipo il controllo per la loro Javascript. Vorrei avere questi strumenti.

Answer 3

Per cominciare, io sono un programmatore Perl nativo in modo da un lato non ho mai programmato con la rete di tipi statici. OTOH ho mai programmato con loro quindi non posso parlare con i loro benefici. Quello che posso parlare è cosa vuol dire refactoring.

Non trovo la mancanza di tipi statici ad essere un problema refactoring WRT. Quello che trovo un problema è la mancanza di un refactoring Browser . linguaggi dinamici hanno il problema che non so davvero che cosa il codice è davvero intenzione di fare fino a che realmente esegue. Perl ha questo più di altri. Perl ha l'ulteriore problema di avere una molto complicato, quasi non analizzabile, sintassi. Risultato: nessun strumenti di refactoring (anche se stanno lavorando molto rapidamente su quella ). Il risultato finale è che devo refactoring a mano. Ed è quello che introduce bug.

Ho le prove per la cattura di loro ... di solito. Faccio trovarmi spesso di fronte a un mucchio fumante di codice non verificabile non testato e quasi con il problema di pollo / uova di dover refactoring del codice, al fine di testarlo, ma di dover testare al fine di refactoring. Ick. A questo punto devo scrivere alcune molto stupida, di alto livello "fa l'output del programma la stessa cosa ha fatto prima" sorta di test solo per assicurarsi che non mi rompere qualcosa.

tipi statici, come previsto in Java o C ++ o C #, in realtà risolvere solo una piccola classe di problemi di programmazione. Garantiscono le interfacce sono passati bit di dati con l'etichetta giusta. Ma solo perché si ottiene una collezione non significa che la raccolta contiene i dati si pensa lo fa. Perché si ottiene un numero intero non significa che hai il numero intero a destra. Il vostro metodo prende un oggetto d'uso, ma è che l'utente loggato?

Classico esempio: public static double sqrt(double a) è la la firma per la funzione radice quadrata Java . Radice quadrata non funziona su numeri negativi. Dove si dice che nella firma? Non è così. Ancora peggio, dove fa dire quello che fa anche quella funzione? La firma dice soltanto quali tipi che ci vuole e cosa restituisce. Non dice nulla di quello che succede nel mezzo ed è lì che vive il codice interessante. Alcune persone hanno cercato di catturare la piena API utilizzando disegno di contratto, possono essere genericamente descritti come incorporamento test run-time di ingressi del funzionali, uscite e gli effetti collaterali (o mancanza) ... ma questa è un'altra spettacolo.

Un'API è molto più che solo le firme di funzione (se non fosse stato, non avrebbe bisogno di tutto che la prosa descrittiva nella Javadocs) e refactoring è molto più di un semplice, anche cambiando l'API.

Il più grande vantaggio di refactoring una, compilato staticamente, la lingua non dinamico staticamente tipizzato ti dà la possibilità di scrivere strumenti di refactoring per fare refactoring piuttosto complessi per voi, perché sa dove tutte le chiamate ai vostri metodi sono. Sono abbastanza invidioso di IntelliJ IDEA .

Answer 4

Direi refactoring va oltre ciò che il compilatore può controllare, anche in lingue staticamente tipizzati. Refactoring è solo cambiando un programmi struttura interna senza influenzare il comportamento esterno. Anche in linguaggi dinamici, ci sono ancora cose che ci si può aspettare che accada e prova per, semplicemente perdere un po 'di assistenza da parte del compilatore.

Answer 5

Uno dei vantaggi dell'utilizzo di var in C # 3.0 è che si possono spesso cambiare il tipo senza rompere alcun codice. Il tipo ha bisogno di guardare sempre la stessa - gli oggetti con gli stessi nomi deve esistere, deve ancora esistere metodi con lo stesso o simile firma. Ma si può davvero passare a un tipo molto diverso, anche senza usare qualcosa come ReSharper.