O princípio do terceiro excluído na prática
Trabalhando com verificação formal de sistemas há uns quinze anos, aprendi que o princípio do terceiro excluído não é só uma curiosidade de aula de lógica. Ele aparece todo dia em código, em bases de dados, em testes automatizados. E quando você pula sobre ele sem pensar, o sistema quebra de um jeito que demora horas para diagnosticar.
O princípio diz que para qualquer proposição P, ou P é verdadeira ou não-P é verdadeira. Não há terceira opção. Em notação clássica: P ¬P. O que parece óbvio vira problema quando você tenta aplicar isso em contextos que não seguem a lógica bivalente.
Como usar o princípio do terceiro excluído em código real
Aqui vai a parte que ninguém conta nos livros. A lógica clássica te ensina o princípio como se ele fosse universal. Na prática, você encontra situações onde ele não se aplica. Eu tive um caso específico com NULL em SQL que me custou três dias de debugging. Tinha uma query que usava WHERE coluna IS NOT NULL E condição_válida. Parece seguro, certo?
O problema é que NULL em SQL não é falso. NULL é desconhecido. Quando você trata NULL como se o princípio do terceiro excluído se aplicasse, a query retorna linhas que você não esperava. A workaround que funcionou foi mudar a lógica de três valores para dois, explicitamente. Em vez de confiar na inferência do otimizador, eu escrevia CASE WHEN coluna IS NULL THEN 'desconhecido' ELSE... Assim eu controlava exatamente o que acontecia. Ganhou-se tempo, perdeu-se elegância. Valeu a pena.
O mesmo problema aparece em linguagens construtivas. Em intuiçãoísmo, o princípio do terceiro excluído não é aceito. Você precisa provar que P ou que ¬P, não basta saber que uma delas existe.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Limitações e quando o princípio falha
Eu vou ser objetivo aqui. O princípio do terceiro excluído funciona bem em lógica clássica. Ele quebra em vários contextos práticos. Primeiro, em computação quântica. Um qubit em superposição não é nem |0> nem |1>. Ele está numa combinação dos dois. Aplicar o princípio do terceiro excluído aqui te dá respostas erradas.
Segundo, em programação lógica construtiva. Se você usa Prolog com cuts mal posicionados, o sistema pode terminar sem responder nada. O princípio te faria acreditar que a resposta existe quando ela não existe. Terceiro, em bancos de dados com dados faltantes. O princípio do terceiro excluído não lida bem com NULL. Você precisa de três-valued logic, não de booleano simples.
Se o seu domínio tem essas situações, recomendo usar lógica fuzzy ou lógica devalue gap. Elas são mais lentas, mas menos propensas a bugs silenciosos.
Insights contra-intuitivos que aprendi na prática
Vou compartilhar duas coisas que ninguém ensina em curso introdutório. Primeira: o princípio do terceiro excluído não é o mesmo que a lei da não-contradição. A primeira diz P ¬P. A segunda diz ¬(P ¬P). Elas parecem equivalentes, mas em lógica intuicionista a primeira não se aplica enquanto a segunda continua válida.
Segunda: em teoria da prova, usar o princípio do terceiro excluído te dá provas não-construtivas. Você sabe que algo existe, mas não sabe como construir o exemplo. Em engenharia de software, isso é um problema real. Um bug que existe na teoria não existe na prática. Eu usei isso em um sistema de validação de certificados digitais. A prova clássica dizia que o certificado era válido. A construção prática mostrou que o certificado nunca existiu. Demorei duas semanas para entender a diferença. O princípio do terceiro excluído foi útil na teoria, inútil na prática.
Se você está começando agora, recomendo estudar lógica de Kleene. Ela é uma alternativa prática quando o princípio do terceiro excluído falha. Você ganha controle sobre os casos de borda, perde controle sobre a elegância da prova. Em resumo: o princípio do terceiro excluído é uma ferramenta poderosa. Ela quebra em contextos que não são bivalentes. Use com critério.
