Se null è male, perché le lingue moderne lo implementano? [chiuso]

Sono sicuro che i progettisti di linguaggi come Java o C # conoscessero problemi relativi all'esistenza di riferimenti null (vedi I riferimenti null sono davvero una cosa negativa? ). Anche l'implementazione di un tipo di opzione non è molto più complessa dei riferimenti null.

Perché hanno deciso di includerlo comunque? Sono sicuro che la mancanza di riferimenti null incoraggerebbe (o addirittura forzerà) una migliore qualità del codice (specialmente una migliore progettazione delle librerie) sia da parte dei creatori di lingue che degli utenti.

È semplicemente a causa del conservatorismo: "ce l'hanno altre lingue, anche noi dobbiamo averlo ..."?

Disclaimer: Dal momento che non conosco personalmente alcun disegnatore di lingue, qualsiasi risposta che darò sarà speculativa.

Dallo stesso Tony Hoare :

Lo chiamo il mio errore da miliardi di dollari. Fu l'invenzione del riferimento nullo nel 1965. A quel tempo, stavo progettando il primo sistema di tipi completo per riferimenti in un linguaggio orientato agli oggetti (ALGOL W). Il mio obiettivo era quello di garantire che ogni uso dei riferimenti fosse assolutamente sicuro, con il controllo eseguito automaticamente dal compilatore. Ma non ho resistito alla tentazione di inserire un riferimento null, semplicemente perché era così facile da implementare. Ciò ha portato a innumerevoli errori, vulnerabilità e arresti anomali del sistema, che probabilmente hanno causato un miliardo di dollari di dolore e danni negli ultimi quarant'anni.

Enfasi mia.

Naturalmente non gli sembrava una cattiva idea in quel momento. E 'probabile che sia stato perpetuato, in parte per la stessa ragione - se mi sembrava una buona idea per l'inventore Turing Award-winning di quicksort, non è sorprendente che molte persone ancora non capiscono perché è il male. È anche probabile in parte perché è conveniente che le nuove lingue siano simili alle lingue più vecchie, sia per ragioni di marketing che di curva di apprendimento. Caso in questione:

"Inseguivamo i programmatori C ++. Siamo riusciti a trascinarne molti a metà strada verso Lisp." -Guy Steele, coautore delle specifiche Java

(Fonte: http://www.paulgraham.com/icad.html )

E, naturalmente, C ++ ha valore nullo perché C ha valore nullo e non è necessario entrare nell'impatto storico di C. In genere C # ha sostituito J ++, che era l'implementazione di Microsoft di Java, e ha anche sostituito C ++ come linguaggio di scelta per lo sviluppo di Windows, quindi avrebbe potuto ottenerlo da entrambi.

EDIT Ecco un'altra citazione da Hoare che vale la pena considerare:

Nel complesso, i linguaggi di programmazione sono molto più complicati di quanto non fossero in passato: l'orientamento agli oggetti, l'ereditarietà e altre caratteristiche non sono ancora stati pensati dal punto di vista di una disciplina coerente e scientificamente fondata o di una teoria della correttezza . Il mio postulato originale, che ho perseguito come scienziato per tutta la mia vita, è che si usano i criteri di correttezza come mezzo per convergere su un design del linguaggio di programmazione decente, uno che non crei trappole per i suoi utenti, e in cui che i diversi componenti del programma corrispondono chiaramente ai diversi componenti delle sue specifiche, quindi puoi ragionare in modo compositivo su di esso. [...] Gli strumenti, incluso il compilatore, devono basarsi su una teoria di cosa significhi scrivere un programma corretto. -Intervista di storia orale di Philip L. Frana, 17 luglio 2002, Cambridge, Inghilterra; Charles Babbage Institute, Università del Minnesota. [ Http://www.cbi.umn.edu/oh/display.phtml?id=343]

Ancora una volta, enfatizzare il mio. Sun / Oracle e Microsoft sono aziende e la linea di fondo di qualsiasi azienda è il denaro. I vantaggi che derivano dall'avere nullpotrebbero aver superato i contro, o potrebbero aver semplicemente avuto una scadenza troppo stretta per considerare pienamente il problema. Come esempio di un errore linguistico diverso che probabilmente si è verificato a causa delle scadenze:

È un peccato che Cloneable sia rotto, ma succede. Le API Java originali sono state eseguite molto rapidamente in tempi ristretti per soddisfare una finestra di mercato di chiusura. Il team Java originale ha fatto un lavoro incredibile, ma non tutte le API sono perfette. Clonabile è un punto debole e penso che le persone dovrebbero essere consapevoli dei suoi limiti. -Josh Bloch

(Fonte: http://www.artima.com/intv/bloch13.html )

Sono sicuro che i progettisti di linguaggi come Java o C # conoscessero problemi relativi all'esistenza di riferimenti null

Ovviamente.

Anche l'implementazione di un tipo di opzione non è molto più complessa dei riferimenti null.

Mi permetto di dissentire! Le considerazioni di progettazione che sono state inserite in tipi di valore nulla in C # 2 erano complesse, controverse e difficili. Hanno portato i team di progettazione di entrambe le lingue e il tempo di esecuzione per molti mesi di dibattiti, implementazione di prototipi e così via, e in effetti la semantica del nulla boxing è stata cambiata molto vicino alla spedizione C # 2.0, il che è stato molto controverso.

Perché hanno deciso di includerlo comunque?

Tutta la progettazione è un processo di scelta tra molti obiettivi sottilmente e gravemente incompatibili; Posso solo dare un breve schizzo di alcuni dei fattori che sarebbero considerati:

• L'ortogonalità delle caratteristiche del linguaggio è generalmente considerata una buona cosa. C # ha tipi di valore annullabili, tipi di valore non annullabili e tipi di riferimento annullabili. Non esistono tipi di riferimento non annullabili, il che rende il sistema di tipi non ortogonale.

• La familiarità con gli utenti esistenti di C, C ++ e Java è importante.

• La facile interoperabilità con COM è importante.

• La facile interoperabilità con tutti gli altri linguaggi .NET è importante.

• La facile interoperabilità con i database è importante.

• La coerenza della semantica è importante; se abbiamo un riferimento a TheKingOfFrance uguale a null significa sempre "non esiste un Re di Francia in questo momento", oppure può significare anche "Esiste sicuramente un Re di Francia, ma non so chi sia adesso"? o può significare "l'idea stessa di avere un re in Francia è senza senso, quindi non fare nemmeno la domanda!"? Null può significare tutte queste cose e altro in C #, e tutti questi concetti sono utili.

• Il costo della prestazione è importante.

• Essere sensibili all'analisi statica è importante.

• La coerenza del sistema di tipi è importante; possiamo sempre sapere che un riferimento non annullabile non è mai stato ritenuto non valido in nessuna circostanza? Che dire del costruttore di un oggetto con un campo non annullabile di tipo riferimento? Che dire del finalizzatore di un tale oggetto, in cui l'oggetto è finalizzato perché il codice che avrebbe dovuto compilare il riferimento ha generato un'eccezione ? Un sistema di tipo che ti mente sulle sue garanzie è pericoloso.

• E la coerenza della semantica? I valori null si propagano quando vengono utilizzati, ma i riferimenti null generano eccezioni quando vengono utilizzati. Questo è incoerente; tale incoerenza è giustificata da qualche vantaggio?

• Possiamo implementare la funzionalità senza rompere altre funzionalità? Quali altre possibili funzioni future la precluderanno?

• Vai in guerra con l'esercito che hai, non quello che ti piacerebbe. Ricorda, C # 1.0 non aveva generici, quindi parlare Maybe<T>in alternativa è un completo non-principiante. .NET avrebbe dovuto scivolare per due anni mentre il team di runtime aggiungeva generici, al solo scopo di eliminare riferimenti null?

• Che dire della coerenza del sistema di tipi? Puoi dire Nullable<T>qualsiasi tipo di valore: no, aspetta, è una bugia. Non si può dire Nullable<Nullable<T>>. Dovresti essere in grado di farlo? In tal caso, quali sono le sue semantiche desiderate? Vale la pena fare in modo che l'intero sistema di tipi contenga un caso speciale solo per questa funzione?

E così via. Queste decisioni sono complesse.

Null ha uno scopo molto valido di rappresentare una mancanza di valore.

Dirò che sono la persona più vocale che conosco riguardo agli abusi di nullità e a tutti i mal di testa e le sofferenze che possono causare specialmente se usati liberamente.

La mia posizione personale è che le persone possono usare valori null solo quando possono giustificare che è necessario e appropriato.

Esempio che giustifica i null:

La data della morte è in genere un campo nullable. Esistono tre possibili situazioni con data di morte. O la persona è morta e la data è nota, la persona è morta e la data è sconosciuta o la persona non è morta e quindi non esiste una data di morte.

Date of Death è anche un campo DateTime e non ha un valore "sconosciuto" o "vuoto". Ha la data predefinita che appare quando si crea un nuovo datetime che varia in base alla lingua utilizzata, ma c'è tecnicamente la possibilità che una persona in realtà muoia in quel momento e si contrassegna come "valore vuoto" se si dovesse usa la data predefinita.

I dati dovrebbero rappresentare correttamente la situazione.

La persona è morta è nota la data di morte (09/03/1984)

Semplice, "3/9/1984"

La persona è morta la data di morte non è nota

Quindi cosa c'è di meglio? Null , '0/0/0000' o '01 / 01/1869 '(o qualunque sia il tuo valore predefinito?)

La persona non è morta la data di morte non è applicabile

Quindi cosa c'è di meglio? Null , '0/0/0000' o '01 / 01/1869 '(o qualunque sia il tuo valore predefinito?)

Quindi pensiamo che ogni valore su ...

• Null , ha implicazioni e preoccupazioni è necessario essere cauti, accidentalmente cercando di manipolare senza confermare che non è nulla prima per esempio sarebbe un'eccezione, ma è anche meglio rappresenta situazione reale ... Se la persona non è morto la data della morte non esiste ... non è niente ... è nulla ...
• 0/0/0000 , questo potrebbe andare bene in alcune lingue e potrebbe anche essere una rappresentazione appropriata senza data. Sfortunatamente alcune lingue e convalide lo rifiuteranno come un datetime non valido che lo rende un non andare in molti casi.
• 1/1/1869 (o qualunque sia il tuo valore datetime predefinito) , il problema qui è che diventa difficile da gestire. Potresti usarlo come mancanza di valore, tranne che cosa succede se voglio filtrare tutti i miei record per i quali non ho una data di morte? Potrei facilmente filtrare le persone che sono effettivamente morte in quella data e che potrebbero causare problemi di integrità dei dati.

Il fatto è a volte si Non ha bisogno di rappresentare niente e sicuro a volte un tipo di variabile funziona bene per questo, ma spesso i tipi di variabili devono essere in grado di rappresentare nulla.

Se non ho mele ho 0 mele, ma cosa succede se non so quante mele ho?

Certamente null è abusato e potenzialmente pericoloso, ma a volte è necessario. È solo il default in molti casi perché fino a quando non fornisco un valore la mancanza di un valore e qualcosa deve rappresentarlo. (Nullo)

Non andrei fino al punto in cui "ce l'hanno altre lingue, anche noi dobbiamo averlo ..." come se fosse una specie di tenere il passo con i Jones. Una caratteristica chiave di ogni nuova lingua è la capacità di interagire con le librerie esistenti in altre lingue (leggi: C). Poiché C ha puntatori nulli, il livello di interoperabilità necessita necessariamente del concetto di null (o di qualche altro equivalente "non esiste" che esplode quando lo si utilizza).

Il progettista del linguaggio avrebbe potuto scegliere di utilizzare i Tipi di opzione e costringerti a gestire il percorso null ovunque che le cose possano essere null. E questo quasi certamente porterebbe a meno bug.

Ma (specialmente per Java e C # a causa dei tempi della loro introduzione e del loro pubblico di destinazione) l'uso di tipi di opzioni per questo livello di interoperabilità avrebbe probabilmente danneggiato se non silurato la loro adozione. O il tipo di opzione è passato fino in fondo, infastidendo i programmatori C ++ dalla metà alla fine degli anni '90 - o il livello di interoperabilità genererebbe eccezioni quando si incontrano null, infastidendo i programmatori C ++ dalla metà alla fine degli anni '90. ..

Prima di tutto, penso che possiamo essere tutti d'accordo sul fatto che sia necessario un concetto di nullità. Ci sono alcune situazioni in cui dobbiamo rappresentare l' assenza di informazioni.

Consentire nullriferimenti (e puntatori) è solo un'implementazione di questo concetto, e forse il più popolare sebbene sia noto per avere problemi: C, Java, Python, Ruby, PHP, JavaScript, ... tutti usano uno simile null.

Perché ? Bene, qual è l'alternativa?

In linguaggi funzionali come Haskell hai il tipo Optiono Maybe; tuttavia quelli sono basati su:

• tipi parametrici
• tipi di dati algebrici

Ora, l'originale C, Java, Python, Ruby o PHP supportavano entrambe queste funzionalità? No. I generici imperfetti di Java sono recenti nella storia del linguaggio e in qualche modo dubito che anche gli altri li implementino affatto.

Ecco qua. nullè facile, i tipi di dati algebrici parametrici sono più difficili. La gente cercava l'alternativa più semplice.

Null / nil / none in sé non è male.

Se guardi il suo famoso discorso fuorviante "L'errore di miliardi di dollari", Tony Hoare parla di come consentire a qualsiasi variabile di essere in grado di contenere un valore nullo sia stato un errore enorme. L'alternativa - mediante le Opzioni - non senza di fatto sbarazzarsi di riferimenti nulli. Invece ti consente di specificare quali variabili possono contenere null e quali no.

È un dato di fatto, con i linguaggi moderni che implementano una corretta gestione delle eccezioni, gli errori null dereference non sono diversi da qualsiasi altra eccezione: lo trovi, lo risolvi. Alcune alternative ai riferimenti null (ad esempio il modello Null Object) nascondono errori, causando il fallimento silenzioso delle cose fino a molto tempo dopo. Secondo me, è molto meglio fallire velocemente .

Quindi la domanda è: perché le lingue non riescono a implementare le opzioni? È un dato di fatto, il linguaggio probabilmente più popolare di tutti i tempi C ++ ha la capacità di definire variabili oggetto che non possono essere assegnate NULL. Questa è una soluzione al "problema nullo" menzionato da Tony Hoare nel suo discorso. Perché il prossimo linguaggio di battitura più popolare, Java, non ce l'ha? Ci si potrebbe chiedere perché abbia così tanti difetti in generale, specialmente nel suo sistema di tipi. Non credo che si possa davvero dire che le lingue commettono sistematicamente questo errore. Alcuni lo fanno, altri no.

Perché i linguaggi di programmazione sono generalmente progettati per essere praticamente utili piuttosto che tecnicamente corretti. Il fatto è che gli nullstati sono un evento comune a causa di dati errati o mancanti o di uno stato che non è stato ancora deciso. Le soluzioni tecnicamente superiori sono tutte più ingombranti che semplicemente consentire stati nulli e risucchiare il fatto che i programmatori commettano errori.

Ad esempio, se voglio scrivere un semplice script che funziona con un file, posso scrivere pseudocodice come:

file = openfile("joebloggs.txt")

for line in file
{
  print(line)
}

e fallirà semplicemente se joebloggs.txt non esiste. Il fatto è che per semplici script che probabilmente vanno bene e per molte situazioni in codice più complesso so che esiste e il fallimento non accadrà, costringendomi a controllare i miei sprechi di tempo. Le alternative più sicure raggiungono la loro sicurezza costringendomi a gestire correttamente lo stato di potenziale fallimento ma spesso non voglio farlo, voglio solo andare avanti.

Esistono usi chiari e pratici del puntatore NULL(o nil, o Nil, o null, o Nothingo come viene chiamato nella lingua preferita).

Per quelle lingue che non hanno un sistema di eccezione (ad es. C) un puntatore null può essere usato come segno di errore quando un puntatore deve essere restituito. Per esempio:

char *buf = malloc(20);
if (!buf)
{
    perror("memory allocation failed");
    exit(1);
}

Qui un NULLritorno da malloc(3)viene utilizzato come indicatore di errore.

Se utilizzato negli argomenti metodo / funzione, può indicare l'uso predefinito per l'argomento o ignorare l'argomento di output. Esempio sotto.

Anche per quelle lingue con meccanismo di eccezione, un puntatore nullo può essere utilizzato come indicazione di errore soft (ovvero, errori recuperabili) soprattutto quando la gestione delle eccezioni è costosa (ad esempio Objective-C):

NSError *err = nil;
NSString *content = [NSString stringWithContentsOfURL:sourceFile
                                         usedEncoding:NULL // This output is ignored
                                                error:&err];
if (!content) // If the object is null, we have a soft error to recover from
{
    fprintf(stderr, "error: %s\n", [[err localizedDescription] UTF8String]);
    if (!error) // Check if the parent method ignored the error argument
        *error = err;
    return nil; // Go back to parent layer, with another soft error.
}

Qui, l'errore soft non causa l'arresto anomalo del programma se non viene rilevato. Ciò elimina il folle tentativo di catch come Java e ha un miglior controllo nel flusso del programma poiché gli errori software non si interrompono (e le poche eccezioni rimanenti non sono in genere recuperabili e non vengono rilevate)

Esistono due problemi correlati, ma leggermente diversi:

1. Dovrebbe nullesistere affatto? O dovresti sempre usare Maybe<T>dove null è utile?

2. Tutti i riferimenti dovrebbero essere nullable? In caso contrario, quale dovrebbe essere l'impostazione predefinita?

   Dover dichiarare esplicitamente tipi di riferimento nullable come string?o simili eviterebbe la maggior parte (ma non tutte) delle nullcause dei problemi , senza essere troppo diversi da quelli a cui sono abituati i programmatori.

Sono almeno d'accordo con te sul fatto che non tutti i riferimenti dovrebbero essere nulli. Ma evitare null non è privo di complessità:

.NET inizializza tutti i campi default<T>prima che possano essere accessibili per la prima volta dal codice gestito. Ciò significa che per i tipi di riferimento è necessario nullo qualcosa di equivalente e che i tipi di valore possono essere inizializzati su un tipo di zero senza eseguire il codice. Sebbene entrambi questi defaultaspetti presentino gravi inconvenienti, la semplicità dell'inizializzazione potrebbe aver superato quelli negativi.

• Ad esempio, puoi aggirare i campi richiedendo l'inizializzazione dei campi prima di esporre il thispuntatore al codice gestito. Spec # ha seguito questa strada, utilizzando una sintassi diversa dal concatenamento del costruttore rispetto a C #.

• Per i campi statici assicurarsi che ciò sia più difficile, a meno che tu non imponga forti restrizioni sul tipo di codice che può essere eseguito in un inizializzatore di campo poiché non puoi semplicemente nascondere il thispuntatore.

• Come inizializzare matrici di tipi di riferimento? Si consideri un List<T>che è supportato da un array con una capacità maggiore della lunghezza. Gli elementi rimanenti devono avere un certo valore.

Un altro problema è che non consente metodi come quelli bool TryGetValue<T>(key, out T value)che ritornano default(T)come valuese non trovassero nulla. Anche se in questo caso è facile sostenere che il parametro out sia in primo luogo un progetto errato e questo metodo dovrebbe restituire un'unione discriminante o forse invece.

Tutti questi problemi possono essere risolti, ma non è facile come "vietare null e tutto va bene".

I linguaggi di programmazione più utili consentono di scrivere e leggere elementi di dati in sequenze arbitrarie, in modo che spesso non sia possibile determinare staticamente l'ordine in cui si verificheranno le letture e le scritture prima dell'esecuzione di un programma. Ci sono molti casi in cui il codice memorizzerà effettivamente i dati utili in ogni slot prima di leggerlo, ma dove dimostrarlo sarebbe difficile. Pertanto, sarà spesso necessario eseguire programmi in cui sarebbe almeno teoricamente possibile che il codice tenti di leggere qualcosa che non è stato ancora scritto con un valore utile. Indipendentemente dal fatto che il codice sia legale o meno, non esiste un modo generale per impedire al codice di effettuare il tentativo. L'unica domanda è cosa dovrebbe accadere quando ciò accade.

Lingue e sistemi diversi adottano approcci diversi.

• Un approccio sarebbe quello di dire che qualsiasi tentativo di leggere qualcosa che non è stato scritto innescherà un errore immediato.

• Un secondo approccio è richiedere al codice di fornire un valore in ogni posizione prima che sia possibile leggerlo, anche se non ci sarebbe modo per il valore memorizzato di essere semanticamente utile.

• Un terzo approccio è semplicemente ignorare il problema e lasciare che tutto ciò che accada "naturalmente" accada e basta.

• Un quarto approccio è quello di dire che ogni tipo deve avere un valore predefinito, e qualsiasi slot che non è stato scritto con nient'altro verrà impostato automaticamente su quel valore.

L'approccio n. 4 è molto più sicuro dell'approccio n. 3 ed è generalmente più economico degli approcci n. 1 e n. 2. Ciò lascia quindi la domanda su quale dovrebbe essere il valore predefinito per un tipo di riferimento. Per tipi di riferimento immutabili, in molti casi avrebbe senso definire un'istanza predefinita e dire che il valore predefinito per qualsiasi variabile di quel tipo dovrebbe essere un riferimento a quell'istanza. Per i tipi di riferimento mutabili, tuttavia, ciò non sarebbe molto utile. Se si tenta di utilizzare un tipo di riferimento modificabile prima che sia stato scritto, in genere non esiste alcun corso di azione sicuro se non quello di intercettare al punto del tentativo di utilizzo.

Semanticamente parlando, se si dispone di una matrice customersdi tipo Customer[20]e si tenta di Customer[4].GiveMoney(23)non archiviare nulla Customer[4], l'esecuzione dovrà essere intrappolata. Si potrebbe sostenere che un tentativo di lettura Customer[4]dovrebbe intercettare immediatamente, piuttosto che attendere fino a quando il codice tenta di farlo GiveMoney, ma ci sono abbastanza casi in cui è utile leggere uno slot, scoprire che non ha un valore e quindi utilizzarlo l'informazione, che fallire il tentativo di lettura stesso sarebbe spesso un grosso fastidio.

Alcune lingue consentono di specificare che determinate variabili non devono mai contenere null e qualsiasi tentativo di memorizzare un null deve attivare una trap immediata. Questa è una funzione utile. In generale, tuttavia, qualsiasi linguaggio che consenta ai programmatori di creare matrici di riferimenti dovrà consentire la possibilità di elementi di array nulli, oppure forzare l'inizializzazione di elementi di array su dati che non possono essere significativi.