Se null é ruim, por que as linguagens modernas o implementam? [fechadas]

Tenho certeza de que designers de linguagens como Java ou C # conheciam problemas relacionados à existência de referências nulas (consulte Referências nulas são realmente ruins? ). A implementação de um tipo de opção não é realmente muito mais complexa que as referências nulas.

Por que eles decidiram incluí-lo assim mesmo? Tenho certeza de que a falta de referências nulas incentivaria (ou forçaria) um código de melhor qualidade (especialmente um melhor design de biblioteca), tanto dos criadores quanto dos usuários.

É simplesmente por causa do conservadorismo - "outras línguas têm, temos que ter também ..."?

Isenção de responsabilidade: Como eu não conheço nenhum designer de idiomas pessoalmente, qualquer resposta que eu der será especulativa.

Do próprio Tony Hoare :

Eu chamo de erro do meu bilhão de dólares. Foi a invenção da referência nula em 1965. Naquela época, eu estava projetando o primeiro sistema abrangente de tipos para referências em uma linguagem orientada a objetos (ALGOL W). Meu objetivo era garantir que todo o uso de referências fosse absolutamente seguro, com a verificação realizada automaticamente pelo compilador. Mas não pude resistir à tentação de colocar uma referência nula, simplesmente porque era muito fácil de implementar. Isso levou a inúmeros erros, vulnerabilidades e falhas no sistema, que provavelmente causaram um bilhão de dólares de dor e danos nos últimos quarenta anos.

Ênfase minha.

Naturalmente, não lhe parecia uma má ideia na época. É provável que tenha sido perpetuado em parte pelo mesmo motivo - se isso pareceu uma boa ideia para o inventor do quicksort, vencedor do Turing Award, não é de surpreender que muitas pessoas ainda não entendam por que isso é mau. Também é provável, em parte, porque é conveniente que os novos idiomas sejam semelhantes aos idiomas mais antigos, por razões de marketing e de curva de aprendizado. Caso em questão:

"Estávamos atrás dos programadores de C ++. Conseguimos arrastar muitos deles até a metade do Lisp." -Guy Steele, co-autor da especificação Java

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

E, é claro, o C ++ tem nulo porque C é nulo, e não há necessidade de entrar no impacto histórico do C. O C # substituiu o J ++, que foi a implementação do Java pela Microsoft, e também substituiu o C ++ como a linguagem de escolha para o desenvolvimento do Windows, para que pudesse ser obtido em qualquer um.

EDIT Aqui está outra citação de Hoare que vale a pena considerar:

As linguagens de programação em geral são muito mais complicadas do que costumavam ser: orientação a objetos, herança e outros recursos ainda não estão sendo pensados ​​do ponto de vista de uma disciplina coerente e cientificamente fundamentada ou uma teoria da correção . Meu postulado original, que venho buscando como cientista a vida inteira, é que se usa o critério de correção como meio de convergir para um design decente de linguagem de programação - um que não crie armadilhas para seus usuários e outros quais os diferentes componentes do programa correspondem claramente aos diferentes componentes de sua especificação, para que você possa argumentar sobre a composição. [...] As ferramentas, incluindo o compilador, devem se basear em alguma teoria sobre o que significa escrever um programa correto. - Entrevista na história oral de Philip L. Frana, 17 de julho de 2002, Cambridge, Inglaterra; Instituto Charles Babbage, Universidade de Minnesota. [ Http://www.cbi.umn.edu/oh/display.phtml?id=343]

Mais uma vez, enfatize a minha. Sun / Oracle e Microsoft são empresas, e o resultado final de qualquer empresa é dinheiro. Os benefícios para eles de ter nullsuperado os contras, ou podem simplesmente ter um prazo muito apertado para considerar completamente o problema. Como exemplo de um erro de linguagem diferente que provavelmente ocorreu devido a prazos:

É uma pena que Cloneable esteja quebrado, mas isso acontece. As APIs Java originais foram feitas muito rapidamente, dentro de um prazo apertado, para atender a uma janela de fechamento do mercado. A equipe original do Java fez um trabalho incrível, mas nem todas as APIs são perfeitas. Cloneable é um ponto fraco, e acho que as pessoas devem estar cientes de suas limitações. -Josh Bloch

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

Tenho certeza de que designers de linguagens como Java ou C # conheciam problemas relacionados à existência de referências nulas

Claro.

A implementação de um tipo de opção não é realmente muito mais complexa que as referências nulas.

Eu peço desculpa mas não concordo! As considerações de design que entraram em tipos de valor anuláveis ​​em C # 2 eram complexas, controversas e difíceis. Eles levaram as equipes de design das linguagens e do tempo de execução por muitos meses de debate, implementação de protótipos etc. e, de fato, a semântica do boxe anulável foi alterada muito perto do envio do C # 2.0, o que foi muito controverso.

Por que eles decidiram incluí-lo assim mesmo?

Todo design é um processo de escolha entre muitos objetivos sutil e grosseiramente incompatíveis; Só posso fazer um breve esboço de apenas alguns dos fatores que seriam considerados:

• A ortogonalidade dos recursos da linguagem é geralmente considerada uma coisa boa. O C # possui tipos de valores anuláveis, tipos de valores não anuláveis ​​e tipos de referência anuláveis. Os tipos de referência não anuláveis ​​não existem, o que torna o sistema de tipos não ortogonal.

• A familiaridade com os usuários existentes de C, C ++ e Java é importante.

• A fácil interoperabilidade com o COM é importante.

• A fácil interoperabilidade com todas as outras linguagens .NET é importante.

• A fácil interoperabilidade com bancos de dados é importante.

• A consistência da semântica é importante; se tivermos referência TheKingOfFrance igual a null, isso sempre significa "não existe rei da França no momento" ou também pode significar "definitivamente existe um rei da França; eu simplesmente não sei quem é agora"? ou pode significar "a própria noção de ter um rei na França não faz sentido, então nem faça a pergunta!"? Nulo pode significar todas essas coisas e muito mais em C #, e todos esses conceitos são úteis.

• O custo do desempenho é importante.

• Ser passível de análise estática é importante.

• A consistência do sistema de tipos é importante; podemos sempre saber que uma referência não anulável nunca é, sob nenhuma circunstância, considerada inválida? E o construtor de um objeto com um campo não anulável do tipo de referência? E no finalizador de um objeto desse tipo, onde o objeto é finalizado porque o código que deveria preencher a referência lançou uma exceção ? Um sistema de tipos que mente para você sobre suas garantias é perigoso.

• E quanto à consistência da semântica? Valores nulos se propagam quando usados, mas referências nulas lançam exceções quando usadas. Isso é inconsistente; Essa inconsistência é justificada por algum benefício?

• Podemos implementar o recurso sem interromper outros recursos? Quais outros possíveis recursos futuros o recurso impede?

• Você vai à guerra com o exército que você tem, não com o que você gostaria. Lembre-se, o C # 1.0 não possui genéricos, portanto, falar Maybe<T>como alternativa é um completo não-inicializador. O .NET deveria ter caído por dois anos enquanto a equipe de tempo de execução adicionou genéricos, apenas para eliminar referências nulas?

• E a consistência do sistema de tipos? Você pode dizer Nullable<T>para qualquer tipo de valor - não, espere, isso é mentira. Você não pode dizer Nullable<Nullable<T>>. Você deveria ser capaz? Em caso afirmativo, quais são as semânticas desejadas? Vale a pena fazer com que todo o sistema de tipos tenha um caso especial apenas para esse recurso?

E assim por diante. Essas decisões são complexas.

Nulo serve a um propósito muito válido de representar uma falta de valor.

Eu direi que sou a pessoa mais vocal que conheço sobre os abusos do nulo e todas as dores de cabeça e sofrimento que eles podem causar, especialmente quando usados ​​generosamente.

Minha posição pessoal é que as pessoas podem usar nulos única quando eles podem justificar que é necessário e adequado.

Exemplo que justifica nulos:

Data da morte normalmente é um campo anulável. Existem três situações possíveis com a data da morte. A pessoa morreu e a data é conhecida, a pessoa morreu e a data é desconhecida ou a pessoa não está morta e, portanto, não existe uma data de morte.

Date of Death também é um campo DateTime e não possui um valor "desconhecido" ou "vazio". Ele tem a data padrão que aparece quando você cria um novo datetime que varia de acordo com o idioma utilizado, mas existe tecnicamente uma chance de que a pessoa de fato morra naquele momento e sinalize como seu "valor vazio" se você quiser use a data padrão.

Os dados precisariam representar a situação corretamente.

A pessoa com data de falecimento da morte é conhecida (9/3/1984)

Simples, '9/3/1984'

A pessoa está morta, a data da morte é desconhecida

Então, o que é melhor? Nulo , '0/0/0000' ou '01 / 01/1869 '(ou qualquer que seja o seu valor padrão?)

Pessoa não está morta data da morte não é aplicável

Então, o que é melhor? Nulo , '0/0/0000' ou '01 / 01/1869 '(ou qualquer que seja o seu valor padrão?)

Então, vamos pensar em cada valor ...

• Nulo , tem implicações e preocupações das quais você precisa ter cuidado, tentar manipulá-lo acidentalmente sem confirmar que não é nulo primeiro, por exemplo, lançaria uma exceção, mas também representa melhor a situação real ... Se a pessoa não estiver morta a data da morte não existe ... não é nada ... é nula ...
• 0/0/0000 , isso pode ser bom em alguns idiomas e pode até ser uma representação apropriada sem data. Infelizmente, alguns idiomas e validação rejeitarão isso como um data / hora inválido, o que o torna um impedimento em muitos casos.
• 1/1/1869 (ou qualquer que seja o valor padrão da data e hora) , o problema aqui é que é complicado lidar com isso. Você pode usar isso como valor de sua falta de valor, exceto o que acontece se eu quiser filtrar todos os meus registros pelos quais não tenho data de falecimento? Eu poderia filtrar facilmente as pessoas que realmente morreram nessa data, o que poderia causar problemas de integridade dos dados.

O fato é que às vezes você Não precisa representam nada e certeza às vezes um tipo de variável funciona bem para isso, mas muitas vezes os tipos de variáveis precisam ser capazes de representar nada.

Se não tenho maçãs, tenho 0 maçãs, mas e se não souber quantas maçãs tenho?

Por todos os meios, o nulo é abusado e potencialmente perigoso, mas às vezes é necessário. É apenas o padrão em muitos casos, porque até eu fornecer um valor a falta de um valor e algo precisa representá-lo. (Nulo)

Eu não iria tão longe quanto "outras línguas têm, temos que ter também ..." como se fosse algum tipo de acompanhamento dos Jones. Um recurso importante de qualquer novo idioma é a capacidade de interoperar com as bibliotecas existentes em outros idiomas (leia-se: C). Como C possui ponteiros nulos, a camada de interoperabilidade precisa necessariamente do conceito de nulo (ou algum outro equivalente "não existe" que exploda quando você o usa).

O designer do idioma poderia ter escolhido usar os Tipos de opção e forçá-lo a manipular o caminho nulo em todos os lugares em que as coisas poderiam ser nulas. E isso quase certamente levaria a menos erros.

Mas (especialmente para Java e C # devido ao tempo de sua introdução e seu público-alvo), o uso de tipos de opção para essa camada de interoperabilidade provavelmente prejudicaria se não prejudicasse sua adoção. O tipo de opção é passado até o fim, irritando muito os programadores de C ++ de meados ao final dos anos 90 - ou a camada de interoperabilidade lançaria exceções ao encontrar nulos, irritando os programadores de C ++ de meados ao final dos anos 90. ..

Antes de tudo, acho que todos podemos concordar que um conceito de nulidade é necessário. Existem algumas situações em que precisamos representar a ausência de informações.

Permitir nullreferências (e ponteiros) é apenas uma implementação desse conceito, e possivelmente a mais popular, embora se saiba que há problemas: C, Java, Python, Ruby, PHP, JavaScript, ... todos usam um similar null.

Por quê ? Bem, qual é a alternativa?

Em linguagens funcionais como Haskell, você tem o tipo Optionou Maybe; no entanto, essas são baseadas em:

• tipos paramétricos
• tipos de dados algébricos

Agora, o C, Java, Python, Ruby ou PHP original suportavam algum desses recursos? Não. Os genéricos falhos de Java são recentes na história da linguagem e, de alguma forma, duvido que os outros os implementem.

Aí está. nullComo é fácil, os tipos de dados algébricos paramétricos são mais difíceis. As pessoas optaram pela alternativa mais simples.

Nulo / nulo / nenhum em si não é mau.

Se você assistir ao seu famoso discurso enganador chamado "The Billion dollar Mistake", Tony Hoare fala sobre como permitir que qualquer variável seja capaz de manter nulo foi um grande erro. A alternativa - usando Opções - na verdade não se livra de referências nulas. Em vez disso, permite especificar quais variáveis ​​podem manter nulas e quais não.

De fato, com linguagens modernas que implementam o tratamento adequado de exceções, os erros de desreferência nula não são diferentes de nenhuma outra exceção - você encontra, corrige. Algumas alternativas para referências nulas (o padrão Objeto Nulo, por exemplo) ocultam erros, fazendo com que as coisas falhem silenciosamente até muito mais tarde. Na minha opinião, é muito melhor falhar rapidamente .

Portanto, a questão é: por que os idiomas não conseguem implementar as Opções? De fato, a linguagem indiscutivelmente mais popular de todos os tempos C ++ tem a capacidade de definir variáveis ​​de objeto que não podem ser atribuídas NULL. Esta é uma solução para o "problema nulo" Tony Hoare mencionado em seu discurso. Por que a próxima linguagem digitada mais popular, Java, não possui? Pode-se perguntar por que ele tem tantas falhas em geral, especialmente em seu sistema de tipos. Eu não acho que você pode realmente dizer que os idiomas cometem sistematicamente esse erro. Alguns fazem, outros não.

Como as linguagens de programação geralmente são projetadas para serem praticamente úteis, e não tecnicamente corretas. O fato é que os nullestados são uma ocorrência comum devido a dados incorretos ou ausentes ou a um estado que ainda não foi decidido. As soluções tecnicamente superiores são todas mais difíceis do que simplesmente permitir estados nulos e sugar o fato de que os programadores cometem erros.

Por exemplo, se eu quiser escrever um script simples que funcione com um arquivo, posso escrever pseudocódigo como:

file = openfile("joebloggs.txt")

for line in file
{
  print(line)
}

e simplesmente falhará se joebloggs.txt não existir. O problema é que, para scripts simples que provavelmente estão bem, e para muitas situações em código mais complexo, eu sei que ele existe e a falha não ocorrerá, forçando-me a verificar desperdício de tempo. As alternativas mais seguras alcançam sua segurança, forçando-me a lidar corretamente com o estado de falha em potencial, mas muitas vezes não quero fazer isso, só quero continuar.

Existem usos claros e práticos do ponteiro NULL(ou nil, ou Nil, ou null, Nothingou o que for chamado no seu idioma preferido).

Para os idiomas que não possuem um sistema de exceção (por exemplo, C), um ponteiro nulo pode ser usado como sinal de erro quando um ponteiro deve ser retornado. Por exemplo:

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

Aqui, um NULLretorno de malloc(3)é usado como um marcador de falha.

Quando usado em argumentos de método / função, pode indicar o uso padrão para o argumento ou ignorar o argumento de saída. Exemplo abaixo.

Mesmo para os idiomas com mecanismo de exceção, um ponteiro nulo pode ser usado como indicação de erro leve (ou seja, erros recuperáveis), especialmente quando o tratamento da exceção é caro (por exemplo, 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.
}

Aqui, o erro leve não causa uma falha no programa se não for pego. Isso elimina o try-catch louco como o Java tem e tem um melhor controle no fluxo do programa, pois os erros de software não são interrompidos (e as poucas exceções duras restantes geralmente não são recuperáveis ​​e não são capturadas)

Existem dois problemas relacionados, mas um pouco diferentes:

1. Deveria nullexistir? Ou você deve sempre usar Maybe<T>onde nulo é útil?

2. Todas as referências devem ser anuláveis? Caso contrário, qual deve ser o padrão?

   Ter que declarar explicitamente tipos de referência anuláveis ​​como string?ou semelhantes evitaria a maioria (mas não todas) das nullcausas dos problemas , sem ser muito diferente do que os programadores estão acostumados.

Pelo menos, concordo com você que nem todas as referências devem ser anuláveis. Mas evitar nulo não deixa de ter suas complexidades:

O .NET inicializa todos os campos default<T>antes que eles possam ser acessados ​​pelo código gerenciado. Isso significa que, para os tipos de referência, você precisa nullou algo equivalente e que os tipos de valor podem ser inicializados para algum tipo de zero sem executar o código. Embora ambos apresentem desvantagens graves, a simplicidade da defaultinicialização pode ter superado essas desvantagens.

• Por exemplo, campos, você pode contornar isso exigindo a inicialização dos campos antes de expor o thisponteiro ao código gerenciado. O Spec # seguiu essa rota, usando sintaxe diferente do encadeamento do construtor em comparação com o C #.

• Para campos estáticos, garantir que isso seja mais difícil, a menos que você coloque fortes restrições sobre que tipo de código pode ser executado em um inicializador de campos, pois você não pode simplesmente ocultar o thisponteiro.

• Como inicializar matrizes de tipos de referência? Considere um List<T>que é apoiado por uma matriz com uma capacidade maior que o comprimento. Os elementos restantes precisam ter algum valor.

Outro problema é que ele não permite métodos como os bool TryGetValue<T>(key, out T value)que retornam default(T)como valuese não encontrassem nada. Embora, neste caso, seja fácil argumentar que o parâmetro out é um design ruim, em primeiro lugar, e esse método deve retornar uma união discriminadora ou talvez um substituto.

Todos esses problemas podem ser resolvidos, mas não é tão fácil quanto "proibir nulo e tudo está bem".

As linguagens de programação mais úteis permitem que os itens de dados sejam gravados e lidos em seqüências arbitrárias, de modo que muitas vezes não será possível determinar estaticamente a ordem na qual as leituras e gravações ocorrerão antes da execução do programa. Existem muitos casos em que o código realmente armazena dados úteis em todos os slots antes de lê-los, mas é difícil provar isso. Assim, muitas vezes será necessário executar programas onde seria pelo menos teoricamente possível para o código tentar ler algo que ainda não foi gravado com um valor útil. Seja ou não legal o código fazer isso, não há uma maneira geral de impedir que o código faça a tentativa. A única questão é o que deve acontecer quando isso ocorrer.

Diferentes idiomas e sistemas adotam abordagens diferentes.

• Uma abordagem seria dizer que qualquer tentativa de ler algo que não foi escrito provocará um erro imediato.

• Uma segunda abordagem é exigir que o código forneça algum valor em todos os locais antes que seja possível lê-lo, mesmo que não haja como o valor armazenado seja semanticamente útil.

• Uma terceira abordagem é simplesmente ignorar o problema e deixar o que acontecer "naturalmente" acontecer.

• Uma quarta abordagem é dizer que todo tipo deve ter um valor padrão e qualquer slot que não tenha sido gravado com mais nada será padronizado para esse valor.

A abordagem nº 4 é muito mais segura que a abordagem nº 3 e, em geral, é mais barata que as abordagens nº 1 e nº 2. Isso deixa a questão de qual deve ser o valor padrão para um tipo de referência. Para tipos de referência imutáveis, em muitos casos, faria sentido definir uma instância padrão e dizer que o padrão para qualquer variável desse tipo deve ser uma referência a essa instância. Para tipos de referência mutáveis, no entanto, isso não seria muito útil. Se for feita uma tentativa de usar um tipo de referência mutável antes de ser gravada, geralmente não haverá um curso de ação seguro, exceto para interceptar o ponto de tentativa de uso.

Semanticamente falando, se alguém tem uma matriz customersde tipos Customer[20]e tenta Customer[4].GiveMoney(23)sem ter armazenado nada Customer[4], a execução terá que interceptar. Alguém poderia argumentar que uma tentativa de leitura Customer[4]deve interceptar imediatamente, em vez de esperar até que o código tente GiveMoney, mas há casos suficientes em que é útil ler um slot, descobrir que ele não possui um valor e depois usá-lo informações, que a falha na tentativa de leitura seria muitas vezes um grande incômodo.

Alguns idiomas permitem especificar que determinadas variáveis ​​nunca devem conter nulo, e qualquer tentativa de armazenar um nulo deve desencadear uma interceptação imediata. Esse é um recurso útil. Em geral, porém, qualquer linguagem que permita aos programadores criar matrizes de referências terá que permitir a possibilidade de elementos nulos da matriz ou forçar a inicialização dos elementos da matriz a dados que não podem ser significativos.