Quando meu amigo e eu fomos para a escola e apenas sonhamos em nos tornar desenvolvedores, pensamos em fazer algo juntos - um jogo ou um programa super útil.
Comecei a aprender os profissionais e C #, é JavaScript. Nós terminamos o ensino médio, estudamos na universidade, servimos no exército, conseguimos um emprego. Estávamos cheios de desenvolvimento industrial, aqui e ali, e quando ambos nos cansamos, nos lembramos de onde começamos.
Tendo reunido desenvolvedores já experientes, finalmente decidimos fazer nosso próprio projeto - um videogame bidimensional. Como o amigo era uma frente limpa e eu estava com uma pilha cheia, o navegador se tornou a plataforma óbvia para nós. Eu desenvolvia a frente apenas no TypeScript e pensamos que não havia problema, o TS é apenas um superconjunto de JavaScript. Pegue e tudo corra bem. Não importa como. Quando começamos a discutir o trabalho, nos deparamos com um incrível abismo de entender mal um ao outro.
Então eu vi a tarefa de fazer um jogo. Eu sou assim - sim, nós temos um tipo de "jogo", um tipo de "inventário", um tipo de "coisa", um tipo de "mapa", um tipo de "localização". Eu posso imaginar como eles trabalham juntos, descrevê-los, montar um projeto e tudo funciona. O compilador me verificou, fiz tudo certo. Em seguida, começo a escrever o código que usa esses tipos. Devido ao fato de serem, é muito mais fácil para mim. O IDE informa e verifica se há erros. Se o projeto está indo - provavelmente está funcionando. Passei muito tempo com descrições de tipos, e foi bom. Aqui está a minha abordagem.
Meu amigo queria fazer o oposto - escrever imediatamente o código e não descrever nenhum tipo. Ele não estava pronto para definir o problema como uma família de tipos. Eu não queria desenvolver isso, não vi a tarefa como um conjunto de classes, tipos, registros ou qualquer outra coisa assim. Pareceu-me simplesmente impensável. Nós dois estávamos certos de várias maneiras, apenas a correção de cada um de nós excluía o outro.
Sério, conversamos por horas, mas cada um falou por si próprio, como se estivesse em diferentes idiomas. E você não pode escrever que nossos cérebros não são flexíveis. Há apenas um ano, mudei sem dor para o mundo funcional a partir da orientação a objetos e vice-versa. Além disso, passei muito tempo aprendendo JS, e ele estava aprendendo várias linguagens estaticamente tipadas.
Mas a tecnologia, que se tornou a primeira tecnologia de “combate” para desenvolvedores, os define tão fortemente que duas pessoas adultas experientes simplesmente não estão prontas para ouvir uma à outra. Ao longo dos anos estudando o desenvolvimento, nossa visão evoluiu de maneira muito diferente e as abordagens para resolver problemas não funcionaram juntas.
Como resultado, abandonamos a ideia de trabalhar um com o outro. O pensamento imediatamente vem à mente que o problema está apenas em nós dois. Talvez, mas já vi isso com outras pessoas na indústria.
A digitação estática e dinâmica têm uma diferença irreconciliável fundamental
Meu código responde à pergunta "Como trabalhar com isso" e como um código para desenvolvedores que estão acostumados à digitação dinâmica - "Como funciona". Ambas as abordagens têm direito à vida e existem ferramentas para ambas, mas apenas uma pode estar na vanguarda.
Static é bom para projetos grandes que realizaram centenas de anos de desenvolvimento e dinâmico para equipes pequenas, para tarefas em que geralmente é necessário código somente para gravação. Com a dinâmica, você economiza tempo e esforço no início do desenvolvimento e com estática no final.
A idéia de colocar os tipos na vanguarda influenciou seriamente meu pensamento sobre o desenvolvedor.
Escolhendo o C # no início da jornada, preguei a tipografia estática na minha visão de mundo, da qual agora estou sofrendo. Tendo visto algum problema, tento apresentar sua solução como um conjunto de tipos e princípios de sua interação. Quando desenvolvo um módulo, primeiro determino em quais tipos ele opera e quais interagem com seu ambiente. Eu nem me lembro de como eu lidei com a solução de problemas antes.
Todo o treinamento em programação Java é treinamento no design e uso de tipos. .NET CLR - Tempo de execução C # - baseado em tipos e por tipos. A digitação estática está no centro do design da programação orientada a objetos (olá, aulas de JS, decidi que não era necessário). As implementações canônicas da maioria dos padrões de POO estão repletas de Interface, que é completamente sem sentido em uma linguagem de tipo dinâmico.
Os próprios padrões são uma coisa entre idiomas, mas alguém pode me dizer por que o padrão de "estado" é necessário em uma linguagem de tipo dinâmico? E o construtor? Esses padrões não são sobre desenvolvimento, são sobre tipos. Tipos e POO estão inextrincavelmente vinculados.
Você não pode criar sua lógica de negócios com base nos tipos, mas não sabe nada sobre eles no processo de desenvolvimento. É por isso que existem fornecedores de front-end que cobrem seu código com um número inimaginável de testes de unidade, que apenas verificam a base de código quanto à ausência de erros de tipo.
Todos sabemos muito bem que a segurança através da cobertura é uma ilusão. Os testes são escritos manualmente, por definição, são menos confiáveis do que o sistema de verificação de tipo incorporado ao idioma.
Isso não significa que não sejam necessárias linguagens de tipo dinâmico (na verdade, acho que não são necessárias). Isso significa que, ao usá-los, você precisa abandonar o POO como o paradigma dominante. Toda essa unidade de dados e operações neles é para pessoas que têm uma verificação estática.
Os desenvolvedores com quem lidei não acreditam que a presença de digitação estática altere a abordagem do desenvolvimento e escrevem o mesmo código que nas linguagens dinâmicas, adicionando verificação de tipo. Eu acho que isso é fundamentalmente errado. E isso é mais perceptível exatamente no caso de um front-end moderno.
Eu sei que criticar frentes é um assunto tabu. Um dia, eu e meu amigo iniciamos uma IA, que trolla todo mundo no Twitter, e Brendan Ike o interrompeu. Sério, o criador do javascript lutou com a nossa rede neural nos comentários.
Por alguma razão desconhecida, esses caras simplesmente não estão prontos para viver em um mundo onde sua visão contém lacunas sérias. Portanto, critico apenas aqueles que correm para o meu projeto de tipo definitivo e faço seus próprios pedidos lá.
Teríamos vivido em nossos pequenos mundos, mas o TypeScript nos empurrou
Então, eu estou escrevendo um código que, devido aos tipos, não pode ser usado incorretamente. No projeto, espero que outros usem tipos também. Então meu código funcionará como eu pretendia. E não abordo conscientemente todos os casos de uso indevido desse código (porque a digitação exclui isso). Mas um apelido JS entra no projeto, pega esse tipo de mina, envolve-o em qualquer um e começa a usá-lo incorretamente, o que leva a erros sutis.
Os desenvolvedores de JavaScript estão convencidos de que o Typescript ainda é o mesmo JS, mas com a capacidade de adicionar a verificação estática de tipo, se necessário. Isto não é verdade. O script é cem vezes mais poderoso, e eles estão interessados apenas em três por cento de suas capacidades.
O argumento mais prejudicial é o TypeScript, que é apenas um superconjunto de JS. Mas, na prática, você não pode deixar de considerar o TypeScript como uma linguagem independente, mesmo se você for o maldito rei dos front-renderizadores. Porque aqui precisamos de uma abordagem diferente - estática, não dinâmica.
A principal vantagem da digitação estática é a garantia. Se você usá-lo em um módulo, mas não em outro, você gastou tempo e esforço na descrição e no desenvolvimento de tipos, mas não recebeu nenhuma garantia.
Parece para muitos que o TypeScript é um compromisso entre sistemas de tipos entre JS e Java. Ele não é um compromisso, seu sistema de tipos é apenas especial.
Tudo é agravado pelo fato de que hoje cada segundo trabalho na frente exige conhecimento de TS. Isso leva ao fato de que os desenvolvedores de JS estudam superficialmente os recursos do Typescript e começam a escrever código nele, criando um grande número de práticas prejudiciais. Uma situação surge quando eles realmente não precisam de verificação estática de digitação, mas eles a impuseram e a arruinaram. Finalmente, deve-se reconhecer que as abordagens de desenvolvimento com tipagem dinâmica e estática se contradizem, não são coisas que possam ser misturadas.
JavaScript, a meu ver, é uma ferramenta muito boa para escrever código que resolve o problema sem destacar abstrações desnecessárias. O caso mais flagrante é o padrão da fábrica de gelo. Você pode alimentar esta instância com suas instâncias e ela as cobre com imunidade de tempo de execução. Se eu processar meu objeto com esta fábrica, ele me dará o mesmo, mas quando eu tentar alterar o valor de uma das propriedades, receberei uma exceção. Apenas WAT?!?
O padrão surgiu porque as frentes liam em algum lugar sobre imunidade fria e decidiram arrastá-lo para o próprio idioma, que não era de forma alguma destinado à imunidade. No Typescript, eu posso fazer a mesma fábrica, mas com uma proibição de mutações no tempo de compilação, e sem nenhuma exceção.
Por outro lado, isso não é necessário, porque existe uma programação funcional pura. Pegue F #, Haskell, OCaml, vou dizer, ReasonML - são proibidas mutações fora da caixa. Mas receio que, se você der o front-end a uma linguagem funcional, ela imediatamente começará a modernizá-la e fazer o comportamento parecer JS.
Porque a escolha da digitação é um caminho sem retorno. Todas as soluções de compromisso dão apenas a ilusão de compromisso. Você coloca os tipos na vanguarda ou não. Não sei como tudo acabaria, comecei a aprender C # e JavaScript simultaneamente e paralelo um ao outro. Mas agora estou tão cravado no meu pensamento que não vejo e não quero ver as vantagens da digitação dinâmica. Eles estão, mas fora da minha vista, e tudo o que resta para mim é fechar os olhos para eles, como para quaisquer manifestações do mundo estranhas para mim com as quais eu tenha que viver. Entendo que estou errado, mas preciso trabalhar aqui e agora e não há orçamento correndo entre os polos.
Portanto, não quero buscar compromissos, mas falo diretamente. Se você está apenas começando a aprender o desenvolvimento, comece com a digitação estática.