A digitação dinâmica não é uma ferramenta de desenvolvimento. Isso é um absurdo (péssimo)



Existem muitas coisas na programação que eu entendo muito mal. Tantos que às vezes me perguntam - no que você é bom?

Entendo os tipos e o design de uma API conveniente e confiável. Mas para uma boa metade dos desenvolvedores, essas coisas não significam nada. Porque eles usam digitação dinâmica e não têm idéia de quais problemas e por que eu resolvo.

Durante a maior parte da minha vida, eu apenas acenei para eles e passei. Esses tolos não entendem as coisas óbvias, e eu não me comprometi a explicar a cada apelido js por que seu código não é desenvolvimento, mas protótipo de brinquedo. Mas o tempo passa, e o número de idiotas ao redor nem pensa em diminuir. Em vez de mover toda a sua indústria front-end para um script de tempo estático, finalmente, esses burros começam a usar todo tipo de coisa, escrevem toneladas de testes e fazem truques imagináveis ​​- só para não entender tipos.

Existem muitas coisas controversas no mundo quando, dependendo do que você deseja obter, a verdade é transferida de uma escala para outra, não deixando lugar para nenhuma verdade última no último recurso. Alguns anos atrás, eu já escrevi sobre digitação, mas então eu era jovem, estúpido e covarde - eu tinha uma posição, mas para não parecer um idiota, eu cuidadosamente a escondi atrás de discussões filosóficas sobre o quão complicado é tudo e o quão difícil é para os adeptos trabalharem. diferentes modelos de digitação juntos.

Mas hoje eu vim aqui para dizer:

A digitação dinâmica é uma merda infernal, e os engenheiros que acreditam nessa abordagem estão seriamente enganados.


Dê uma olhada. A digitação estática é algo que me permite expressar algumas das condições sob as quais o código não pode funcionar como instruções adicionais para o compilador. Ou seja, eu sei que essa função funciona apenas com esses objetos, descrevo-os em sua assinatura e recebo uma garantia - um objeto de um tipo diferente não será transferido para a função. Além disso, os tipos permitem que eu diga ao compilador como meu código funciona. O compilador poderá usar essas informações para realizar otimizações e, por exemplo, para me dar dicas. Diferentes ferramentas de desenvolvimento podem usar informações de tipo para refatorar automaticamente, fazê-lo com segurança e com a garantia de que a porra não se quebra. O próprio código de tipo torna a base de código compreensível e aproxima seus conjuntos de instruções dos processos que você descreve com esse código.

Os opositores à digitação estática dizem que todas essas coisas são desnecessárias. Eles me dizem isso

Os erros que capturam tipos não valem o esforço de escrever código para esses tipos.


A sério? A sério? Estamos com preguiça de escrever personagens? Mano. Você pensa por cinco horas e imprime dez minutos. Você é um engenheiro, então tente descobrir de que tipo de conforto você está falando. E não esqueça que, com ou sem digitação estática, mais de uma vez você descreverá em sua base de código as estruturas dos objetos com os quais irá trabalhar. Mas se você usar estática, o compilador e o IDE poderão fazer o trabalho por você. E verifique seu código quanto a erros que descrevem esses objetos. Se você estiver com preguiça de escrever anotações de tipo em funções - use o idioma da inferência de tipo ou gere-as usando extensões ao IDE.

Se você pisar nessas anotações inflar a base de código - lembre-se, caramba, de todos os nossos princípios sobre o fato de que o explícito é melhor que o implícito, que uma das tarefas importantes da base de código é ser compreensível e legível, tanto por uma pessoa como por uma máquina. Se você está com preguiça de trabalhar em sua cabeça idiota para entender em quais tipos de aplicativos seu aplicativo funcionará, então eu tenho más notícias para você. Para escrever algo funcionando, você ainda precisa fazer esse trabalho. Basta fazê-lo, você não será determinado, mas sob demanda. Como resultado, você descreverá o processo, mas não o colocará na sua cabeça, e a qualidade do seu código responderá. Erros, incoerência e muletas.

Os opositores à digitação estática dizem que os erros de captura precoce não são tão importantes.


Alo. Seu quadro de tarefas está repleto de bugs permitidos pelos desenvolvedores. Reparar bugs é uma grande parte de todo o trabalho do setor. Gastamos bilhões de horas humanas para corrigir erros ridiculamente ridículos. Você escreve código sem bugs? ou você só tem bugs inteligentes? Sim, o inferno nadou lá. Se o compilador não verificar se você fechou a chave, acredite, teríamos centenas de bugs com uma chave aberta.

Quando você pensa sobre onde o bug pode potencialmente ocorrer e onde não, uma ilusão perigosa parece que você está no controle da situação e prevê todos os casos. Trabalho há sete anos, nunca houve tal coisa que previ todos os casos. Como esse é um caso especial do problema do vendedor ambulante - NUNCA é possível prever todos os casos. Você nem pode considerar o mais comum e provável. Quando, quem e em que situação escreverá o código com um bug crítico, em qual módulo e como ele fará isso - você, caramba, não faz ideia. Tudo o que você pode fazer é reduzir a chance de um bug. Então reduza, você recebe dinheiro louco por isso.

Opositores de tipos de contraste de digitação estática com testes.


Não direi que eles são idiotas, direi que eles simplesmente não pensaram bem sobre isso. Aqui está a verdade óbvia para você - os testes registram que o código existente funciona sob certas condições. E os tipos garantem que o código que ainda não foi gravado será gravado sob certas condições. Testes são necessários. Tipos são necessários. Você ainda reduz as chances de que tudo caia. Em um mundo em que temos um orçamento para discutir com a equipe por cinco horas o que há de errado com o nosso Edge, haverá tempo para adicionar anotações e alguns testes.

Os nerds do mundo dinâmico dizem que a digitação estática priva o código de flexibilidade.


Não entendo que tipo de flexibilidade eles estão falando. Mesmo no empobrecido C #, o sistema de tipos me permite não ter controle sobre os tipos de dados cujo tipo não me interessa. Eu sempre posso provar para o idioma que aqui, eles dizem, ouça aqui, não consigo descrever o que é isso, mas tenho certeza de que ele tem um campo desse tipo ou desse tipo. E eu vou trabalhar apenas com ele. Qualquer linguagem digitada estaticamente permite isso. E flexibilidade e liberdade para escrever código que simplesmente não funciona - não preciso dessa flexibilidade.

Os adolescentes JS dizem que a digitação estática muda o foco da tarefa para a descrição do tipo.


E eu digo que a descrição dos tipos é a descrição do processo que você automatiza. Na programação orientada a objetos, na programação funcional, em qualquer outra programação, descrevemos coisas do mundo real e nosso código contém o conhecimento sobre elas, sem o qual não pode funcionar. Você ainda estará fazendo este trabalho.

Se o sistema de tipos de um idioma específico não permitir que você descreva seu domínio de maneira correta e segura - esse é um problema de um idioma específico e não da digitação estática em geral. Isso é normal e, especificamente nesse idioma, você usa todos os tipos de objetos e dinâmicas em alguns locais, mas onde quer que você possa obter garantias, você as obtém.

Escrevi código com digitação dinâmica e estática. Com estrito e não estrito, com estrutural e nominativo.

Somente a dinâmica me fez sentir fortemente que estava escrevendo um pseudocódigo infantil que só funcionaria se as estrelas convergissem.


A digitação dinâmica é um brinquedo, algo que funcionará quando você decidir codificar algo em um e esquecer. Quando você planeja desenvolver, quando outras pessoas trabalharão com seu código, quando o código sair no produto e começar a resolver problemas do usuário, atualizando uma vez por semana - a digitação dinâmica é absolutamente inaceitável. Lembre-se disso e altere as extensões dos seus arquivos de .js para .ts.



E veja meu podcast - há um novo problema

All Articles