Si null est mauvais, pourquoi les langages modernes l'implémentent-ils? [fermé]

Je suis sûr que les concepteurs de langages tels que Java ou C # connaissaient des problèmes liés à l'existence de références null (voir Est-ce que les références null sont vraiment une mauvaise chose? ). De plus, implémenter un type d'option n'est pas vraiment beaucoup plus complexe que les références nulles.

Pourquoi ont-ils décidé de l'inclure de toute façon? Je suis certain que le manque de références nulles encouragerait (ou même forcerait) un code de meilleure qualité (en particulier une meilleure conception de bibliothèque) à la fois des créateurs de langage et des utilisateurs.

Est-ce simplement à cause du conservatisme - "d'autres langues l'ont, nous devons l'avoir aussi ..."?

Déni de responsabilité: Étant donné que je ne connais personnellement aucun concepteur de langage, toute réponse que je vous donnerai sera spéculative.

De Tony Hoare lui-même:

Je l'appelle mon erreur d'un milliard de dollars. C’était l’invention de la référence null en 1965. À cette époque, je concevais le premier système de types complet pour les références dans un langage orienté objet (ALGOL W). Mon objectif était de veiller à ce que toute utilisation des références soit absolument sûre, avec une vérification automatique par le compilateur. Mais je ne pouvais pas résister à la tentation de mettre une référence nulle, tout simplement parce que c'était si facile à mettre en œuvre. Cela a entraîné d'innombrables erreurs, vulnérabilités et pannes système, qui ont probablement causé des millions de dollars de douleur et de dommages au cours des quarante dernières années.

L'accent est à moi.

Naturellement, cela ne lui semblait pas une mauvaise idée à l'époque. Il est probable que cela ait été en partie perpétué pour la même raison: si cela semblait être une bonne idée pour l'inventeur du tri rapide récompensé par le prix Turing, il n'est pas étonnant que beaucoup de gens ne comprennent toujours pas pourquoi c'est mal. Cela s'explique probablement aussi par le fait qu'il est pratique que les nouvelles langues soient similaires aux anciennes, à la fois pour des raisons de marketing et d'apprentissage. Exemple:

"Nous recherchions les programmeurs C ++. Nous avons réussi à en faire glisser beaucoup à mi-chemin de Lisp." -Guy Steele, co-auteur de la spécification Java

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

Et, bien sûr, C ++ a la valeur null car C a la valeur null et il n'est pas nécessaire d'entrer dans l'impact historique de C. Le type C # de J ++ remplacé, qui était l'implémentation de Java par Microsoft, et il a également remplacé le C ++ en tant que langage de choix pour le développement Windows, de sorte qu'il aurait pu l'obtenir de l'un ou l'autre.

EDIT Voici une autre citation de Hoare à considérer:

Les langages de programmation sont dans l’ensemble beaucoup plus compliqués qu’ils ne l’étaient: orientation objet, héritage et autres fonctionnalités n’ont pas encore été vraiment réfléchies du point de vue d’une discipline cohérente et scientifiquement fondée ou d’une théorie de la correction correcte . Mon postulat initial, que j'ai suivi toute ma vie en tant que scientifique, est que l'on utilise les critères de l'exactitude comme moyen de converger vers une conception de langage de programmation décent, qui ne crée pas de piège pour ses utilisateurs, et lequel les différents composants du programme correspondent clairement aux différents composants de sa spécification, vous pouvez donc raisonner en composition. [...] Les outils, y compris le compilateur, doivent être basés sur une théorie de ce que signifie écrire un programme correct. Entretien avec l'histoire orale de Philip L. Frana, 17 juillet 2002, Cambridge, Angleterre; Institut Charles Babbage, Université du Minnesota. [ Http://www.cbi.umn.edu/oh/display.phtml?id=343]

Encore une fois, soulignez le mien. Sun / Oracle et Microsoft sont des entreprises et l’argent est au cœur de toute entreprise. Les avantages pour eux d’avoir nullpu l'emporter sur les inconvénients, ou bien ils ont peut-être eu une échéance trop serrée pour examiner pleinement la question. Voici un exemple d'erreur de langage différente qui s'est probablement produite à cause des délais:

C'est dommage que Cloneable soit brisé, mais cela arrive. Les API Java d'origine ont été réalisées très rapidement dans des délais très courts pour pouvoir respecter une fenêtre de marché proche. L'équipe Java originale a fait un travail incroyable, mais toutes les API ne sont pas parfaites. Clonable est un point faible et je pense que les gens devraient être conscients de ses limites. -Josh Bloch

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

Je suis sûr que les concepteurs de langages comme Java ou C # connaissaient l'existence de références nulles.

Bien sûr.

De plus, implémenter un type d'option n'est pas vraiment beaucoup plus complexe que les références nulles.

Je ne suis pas d'accord! Les considérations de conception incluses dans les types de valeur nullable en C # 2 étaient complexes, controversées et difficiles. Ils ont pris les équipes de conception des langues et de l'exécution plusieurs mois de débat, de mise en œuvre de prototypes, etc., et en fait, la sémantique de la boxe annulable a été modifiée de manière très proche de l'envoi du C # 2.0, ce qui était très controversé.

Pourquoi ont-ils décidé de l'inclure de toute façon?

Toute conception est un processus de choix parmi de nombreux objectifs incompatibles de manière subtile et flagrante; Je ne peux donner qu'un bref aperçu de quelques-uns des facteurs à prendre en compte:

• L'orthogonalité des caractéristiques linguistiques est généralement considérée comme une bonne chose. C # a des types de valeur nullables, des types de valeur non nullables et des types de référence nullables. Les types de référence non nulles n'existent pas, ce qui rend le système de types non orthogonal.

• La connaissance des utilisateurs existants de C, C ++ et Java est importante.

• Une interopérabilité facile avec COM est importante.

• Une interopérabilité facile avec tous les autres langages .NET est importante.

• Une interopérabilité facile avec les bases de données est importante.

• La cohérence de la sémantique est importante. si nous avons la référence TheKingOfFrance égale à null, cela signifie-t-il toujours "il n'y a pas de roi de France à l'heure actuelle", ou peut-il aussi signifier "Il existe bel et bien un roi de France; je ne sais tout simplement pas de qui il s'agit maintenant"? ou peut-il vouloir dire "l'idée même d'avoir un roi en France est absurde, alors ne posez même pas la question!"? Null peut signifier toutes ces choses et plus encore en C #, et tous ces concepts sont utiles.

• Le coût de performance est important.

• Être disposé à une analyse statique est important.

• La cohérence du système de types est importante; pouvons - nous toujours savoir qui est une référence non annulable jamais en aucun cas observés invalide? Qu'en est-il dans le constructeur d'un objet avec un champ de type référence non nullable? Qu'en est-il dans le finaliseur d'un tel objet, où l'objet est finalisé parce que le code qui était censé remplir la référence renvoyait une exception ? Un système de type qui vous ment sur ses garanties est dangereux.

• Et que dire de la cohérence de la sémantique? Les valeurs nulles se propagent lorsqu'elles sont utilisées, mais les références nulles émettent des exceptions lorsqu'elles sont utilisées. C'est incohérent Cette incohérence est-elle justifiée par un avantage?

• Pouvons-nous implémenter la fonctionnalité sans en casser d'autres? Quelles autres fonctionnalités futures possibles la fonctionnalité exclut-elle?

• Vous allez faire la guerre à l'armée que vous avez, pas à celle que vous souhaitez. N'oubliez pas que C # 1.0 n'avait pas de génériques. Par conséquent, le fait de parler Maybe<T>d'alternative est un non-débutant. .NET aurait-il dû glisser depuis deux ans pendant que l'équipe d'exécution ajoutait des génériques, uniquement pour éliminer les références nulles?

• Qu'en est-il de la cohérence du système de types? Vous pouvez dire Nullable<T>pour n'importe quel type de valeur - non, attendez, c'est un mensonge. Tu ne peux pas dire Nullable<Nullable<T>>. Devriez-vous pouvoir? Si oui, quelle est la sémantique souhaitée? Vaut-il la peine de donner à tout le système de types un cas particulier juste pour cette fonctionnalité?

Etc. Ces décisions sont complexes.

Null sert un objectif très valable de représenter un manque de valeur.

Je dirai que je suis la personne la plus éloquente que je connaisse au sujet des abus de null et de tous les maux de tête et de souffrances qu’ils peuvent causer, en particulier lorsqu’ils sont utilisés généreusement.

Ma position personnelle est que les personnes peuvent utiliser des valeurs nulles uniquement lorsqu'elles peuvent justifier qu'elles sont nécessaires et appropriées.

Exemple justifiant des valeurs nulles:

Date de décès est généralement un champ nullable. Il y a trois situations possibles avec la date du décès. Soit la personne est décédée et la date est connue, la personne est décédée et la date est inconnue, soit la personne n’est pas morte et, par conséquent, la date du décès n’existe pas.

Date of Death est également un champ DateTime et n'a pas de valeur "unknown" ou "empty". La date par défaut qui apparaît lorsque vous créez une nouvelle date / heure varie en fonction de la langue utilisée, mais il est techniquement possible que cette personne décède à ce moment-là et qu'elle soit considérée comme votre "valeur vide" si vous deviez utilisez la date par défaut.

Les données devraient représenter la situation correctement.

La personne est morte la date du décès est connue (3/9/1984)

Simple, '3/9/1984'

La personne est morte date inconnue

Alors quoi de mieux? Null , '0/0/0000' ou '01 / 01/1869 '(ou quelle que soit votre valeur par défaut est?)

Personne n'est pas la date morte du décès n'est pas applicable

Alors quoi de mieux? Null , '0/0/0000' ou '01 / 01/1869 '(ou quelle que soit votre valeur par défaut est?)

Alors réfléchissons à chaque valeur ...

• Null , cela a des implications et des préoccupations dont vous devez vous méfier, essayer accidentellement de le manipuler sans confirmer que ce n'est pas nul d'abord, par exemple, jetterait une exception, mais cela représenterait également le mieux la situation réelle ... Si la personne n'est pas morte la date du décès n'existe pas ... ce n'est rien ... c'est nul ...
• 0/0/0000 , Cela pourrait bien se passer dans certaines langues et pourrait même constituer une représentation appropriée sans date. Malheureusement, certaines langues et validations rejetteront cela comme une date / heure invalide, ce qui en fait un non-lieu dans de nombreux cas.
• 1/1/1869 (ou quelle que soit votre valeur date / heure par défaut) , le problème est qu'il devient difficile à gérer. Vous pouvez utiliser cela comme valeur de valeur nulle, sauf ce qui se passe si je veux filtrer tous mes dossiers pour lesquels je n'ai pas de date de décès? Je pourrais facilement filtrer les personnes décédées à cette date, ce qui pourrait causer des problèmes d'intégrité des données.

Le fait est parfois vous ne doivent représenter rien et que parfois un type de variable fonctionne bien pour cela, mais les types souvent variables doivent être en mesure de représenter rien.

Si je n'ai pas de pommes, j'ai 0 pommes, mais que se passe-t-il si je ne sais pas combien de pommes j'ai?

Bien entendu, null est utilisé de manière abusive et potentiellement dangereux, mais il est parfois nécessaire. Ce n'est que par défaut dans de nombreux cas car jusqu'à ce que je fournisse une valeur, l'absence d'une valeur et quelque chose doit la représenter. (Nul)

Je n'irais pas aussi loin que "d'autres langues l'ont, nous devons l'avoir aussi ...", comme si c'était comme suivre les Jones. Une caractéristique clé de tout nouveau langage est la capacité d'interopérer avec des bibliothèques existantes dans d'autres langages (lire: C). Puisque C a des pointeurs nuls, la couche d'interopérabilité a nécessairement besoin du concept de zéro (ou de tout autre équivalent "n'existe pas" qui explose lorsque vous l'utilisez).

Le concepteur de langage aurait pu choisir d’utiliser les types d’option et de vous obliger à gérer le chemin nul où les choses puissent être nulles. Et cela conduirait presque certainement à moins de bugs.

Mais (surtout pour Java et C # en raison du moment choisi pour leur introduction et de leur public cible), l’utilisation des types d’options pour cette couche d’interopérabilité aurait probablement nui, voire torpillé, leur adoption. Soit le type d’option est transmis jusqu’à la fin, gênant énormément les programmeurs C ++ du milieu à la fin des années 90 - ou la couche d’interopérabilité jetterait des exceptions lorsqu’elle rencontrait des valeurs nulles, énervant énormément les programmeurs C ++ du milieu à la fin des années 1990. ..

Tout d'abord, je pense que nous pouvons tous convenir qu'un concept de nullité est nécessaire. Il y a des situations où nous devons représenter l' absence d'information.

Autoriser les nullréférences (et les pointeurs) n’est qu’une des implémentations de ce concept, et peut-être même le plus populaire, bien qu’il soit connu pour avoir des problèmes: C, Java, Python, Ruby, PHP, JavaScript,… utilisent tous le même null.

Pourquoi ? Eh bien, quelle est l'alternative?

Dans les langages fonctionnels tels que Haskell, vous avez le type Optionou Maybe; cependant, ceux-ci sont construits sur:

• types paramétriques
• types de données algébriques

Les versions C, Java, Python, Ruby ou PHP d’origine prennent-elles en charge l’une ou l’autre de ces fonctionnalités? Les génériques défectueux de Java sont récents dans l'histoire du langage et je doute que les autres les mettent même en œuvre.

Voilà. nullest facile, les types de données algébriques paramétriques sont plus difficiles. Les gens ont opté pour la solution la plus simple.

Null / nil / none n'est pas mauvais en soi.

Si vous regardez son célèbre discours trompeur "L'erreur d'un milliard de dollars", Tony Hoare explique à quel point le fait d'autoriser une variable à conserver la valeur null était une énorme erreur. L'alternative - à l' aide des options - ne pas en fait se débarrasser des références nulles. Au lieu de cela, il vous permet de spécifier quelles variables sont autorisées à contenir null et celles qui ne le sont pas.

En fait, avec les langages modernes qui implémentent le traitement des exceptions, les erreurs de déréférencement nul ne sont pas différentes des autres exceptions: vous les trouvez, vous les corrigez. Certaines alternatives aux références nulles (le modèle Null Object, par exemple) cachent les erreurs, ce qui entraîne l'échec silencieux des choses jusque beaucoup plus tard. À mon avis, il vaut beaucoup mieux échouer rapidement .

La question est donc de savoir pourquoi les langues ne parviennent pas à implémenter Options. En fait, le langage sans doute le plus populaire de tous les temps, le C ++, est capable de définir des variables d'objet qui ne peuvent pas être attribuées NULL. C’est une solution au "problème nul" que Tony Hoare a mentionné dans son discours. Pourquoi le prochain langage typé le plus populaire, Java, ne l’a-t-il pas? On pourrait se demander pourquoi il a tant de défauts en général, en particulier dans son système de types. Je ne pense pas que vous puissiez vraiment dire que les langues font systématiquement cette erreur. Certains le font, d'autres pas.

Parce que les langages de programmation sont généralement conçus pour être pratiques plutôt que techniquement corrects. Le fait est que les nullétats sont fréquents en raison de données incorrectes ou manquantes ou d'un état qui n'a pas encore été décidé. Les solutions techniquement supérieures sont toutes plus lourdes que de simplement autoriser les états nuls et d’absorber le fait que les programmeurs font des erreurs.

Par exemple, si je veux écrire un script simple qui fonctionne avec un fichier, je peux écrire un pseudo-code comme:

file = openfile("joebloggs.txt")

for line in file
{
  print(line)
}

et cela échouera simplement si joebloggs.txt n'existe pas. Le problème, c’est que, pour les scripts simples, c’est probablement correct et que, dans de nombreuses situations de code plus complexe, je sais qu’il existe et que l’échec ne se produira pas. Me forcer à vérifier me fait perdre mon temps. Les alternatives plus sûres atteignent leur sécurité en m'obligeant à gérer correctement l'état de défaillance potentiel, mais souvent je ne veux pas le faire, je veux juste continuer.

Il existe des utilisations claires et pratiques du pointeur NULL(ou nil, ou Nil, ou null, Nothingou de quelque manière que ce soit appelé dans votre langue préférée).

Pour les langues qui ne disposent pas d'un système d'exception (par exemple C), un pointeur NULL peut être utilisé comme marque d'erreur lorsqu'un pointeur doit être renvoyé. Par exemple:

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

Ici, un NULLretour de malloc(3)est utilisé comme marqueur d'échec.

Lorsqu'il est utilisé dans les arguments de méthode / fonction, il peut indiquer use default pour l'argument ou ignorer l'argument de sortie. Exemple ci-dessous.

Même pour les langues avec mécanisme d'exception, un pointeur null peut être utilisé comme indication d'erreur logicielle (c'est-à-dire d'erreurs récupérables), en particulier lorsque la gestion des exceptions est coûteuse (par exemple, 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.
}

Ici, l'erreur logicielle ne provoque pas le blocage du programme s'il n'est pas intercepté. Ceci élimine le try-catch fou comme Java et permet de mieux contrôler le déroulement du programme, car les erreurs logicielles ne s'interrompent pas (et les quelques exceptions matérielles restantes ne sont généralement pas récupérables et ne sont pas récupérées)

Il y a deux problèmes liés, mais légèrement différents:

1. Devrait nullexister du tout? Ou devriez-vous toujours utiliser Maybe<T>où null est utile?

2. Toutes les références doivent-elles être nulles? Si non, quelle devrait être la valeur par défaut?

   Avoir à déclarer explicitement les types de référence nullable comme string?ou similaires éviterait la plupart des problèmes (mais pas tous) null, sans être trop différent de ce à quoi les programmeurs sont habitués.

Je suis au moins d’accord avec vous pour dire que toutes les références ne devraient pas pouvoir être annulées. Mais éviter la nullité n’est pas sans complexité:

.NET initialise tous les champs default<T>avant d’être accessibles en premier par le code managé. Cela signifie que pour les types de référence dont vous avez besoin nullou quelque chose d'équivalent, les types de valeur peuvent être initialisés à une sorte de zéro sans exécuter de code. Bien que ces deux solutions présentent des inconvénients graves, la simplicité d’ defaultinitialisation a peut-être dépassé ces inconvénients.

• Par exemple, vous pouvez contourner ce problème en imposant l'initialisation des champs avant d'exposer le thispointeur au code géré. Spec # a choisi cette voie en utilisant une syntaxe différente de celle du constructeur par rapport à C #.

• Cela est plus difficile pour les champs statiques , à moins que vous ne posiez de fortes restrictions sur le type de code pouvant s'exécuter dans un initialiseur de champ, car vous ne pouvez pas simplement masquer le thispointeur.

• Comment initialiser des tableaux de types de référence? Considérez un List<T>qui est soutenu par un tableau avec une capacité supérieure à la longueur. Les éléments restants doivent avoir une certaine valeur.

Un autre problème est qu'il n'autorise pas les méthodes telles bool TryGetValue<T>(key, out T value)que return, default(T)comme valuesi elles ne trouvaient rien. Bien que, dans ce cas, il soit facile de soutenir que le paramètre out est une mauvaise conception en premier lieu et que cette méthode devrait renvoyer une union discriminante ou peut - être à la place.

Tous ces problèmes peuvent être résolus, mais ce n'est pas aussi simple que "interdire la nullité et tout va bien".

Les langages de programmation les plus utiles permettent d’écrire et de lire des éléments de données en séquences arbitraires, de sorte qu’il sera souvent impossible de déterminer de manière statique l’ordre dans lequel les lectures et les écritures auront lieu avant l’exécution d’un programme. Il existe de nombreux cas où le code stocke effectivement des données utiles dans chaque emplacement avant de le lire, mais il est difficile de le prouver. Ainsi, il sera souvent nécessaire d'exécuter des programmes où il serait au moins théoriquement possible au code d'essayer de lire quelque chose qui n'a pas encore été écrit avec une valeur utile. Qu'il soit légal ou non de le faire, il n'y a pas de moyen général d'empêcher le code de tenter le coup. La seule question est ce qui devrait se passer quand cela se produit.

Différents langages et systèmes adoptent des approches différentes.

• Une approche serait de dire que toute tentative de lire quelque chose qui n'a pas été écrit déclenchera une erreur immédiate.

• Une deuxième approche consiste à exiger que le code fournisse une valeur dans chaque emplacement avant de pouvoir le lire, même s’il n’y aurait aucun moyen que la valeur stockée soit sémantiquement utile.

• Une troisième approche consiste simplement à ignorer le problème et à laisser ce qui arriverait "naturellement" simplement.

• Une quatrième approche consiste à dire que chaque type doit avoir une valeur par défaut, et tout emplacement qui n’a pas été écrit avec quoi que ce soit d’autre aura par défaut cette valeur.

L'approche n ° 4 est beaucoup plus sûre que l'approche n ° 3 et est en général moins chère que les approches n ° 1 et n ° 2. Cela laisse alors la question de ce que la valeur par défaut devrait être pour un type de référence. Pour les types de référence immuables, il serait souvent judicieux de définir une instance par défaut et d'indiquer que la valeur par défaut pour toute variable de ce type doit être une référence à cette instance. Pour les types de référence mutables, cependant, cela ne serait pas très utile. Si vous tentez d'utiliser un type de référence mutable avant qu'il ne soit écrit, il n'y a généralement pas de solution sûre, sauf pour intercepter au point de tentative d'utilisation.

Sémantiquement, si l’on a un tableau customersde type Customer[20]et que l’on essaie Customer[4].GiveMoney(23)sans rien stocker dans l’ Customer[4]exécution, il va falloir exécuter. On pourrait argumenter qu'une tentative de lecture Customer[4]devrait intercepter immédiatement plutôt que d'attendre que le code le tente GiveMoney, mais il y a suffisamment de cas où il est utile de lire un emplacement, de découvrir qu'il ne contient pas de valeur, puis de l'utiliser. informations, que l'échec de la tentative de lecture serait souvent une nuisance majeure.

Certaines langues permettent de spécifier que certaines variables ne doivent jamais contenir null, et toute tentative de stockage d'une valeur null doit déclencher une interruption immédiate. C'est une fonctionnalité utile. En général, cependant, tout langage permettant aux programmeurs de créer des tableaux de références devra soit permettre la possibilité d’éléments de tableau nuls, soit obliger l’initialisation d’éléments de tableau à des données qui ne peuvent pas avoir de sens.