As linguagens estáticas e de tipo dinâmico podem ser vistas como ferramentas diferentes para diferentes tipos de trabalhos?

9

Sim, perguntas semelhantes foram feitas, mas sempre com o objetivo de descobrir 'qual é o melhor'.

Estou perguntando porque eu vim como desenvolvedor principalmente em JavaScript e realmente não tenho nenhuma experiência extensa em escrever em linguagens estaticamente tipadas.

Apesar disso, eu definitivamente vejo valor no aprendizado de C para lidar com operações exigentes em níveis mais baixos de código (o que eu assumo tem muito a ver com estática versus dinâmica no nível do compilador), mas o que estou tentando entender é é se existem contextos específicos do projeto (talvez certos tipos de operações dinâmicas com uso intensivo de dados?) envolvendo outras coisas além do desempenho, onde faz muito mais sentido usar Java ou C # versus algo como Python.

dynamic-typing static-typing

— Erik Reppen
fonte

5

A resposta é sim". Cada tipo de idioma - de fato cada idioma - tem seus pontos fortes e fracos e, portanto, é mais adequado para algumas tarefas do que para outras.

— ChrisF

é interessante que você use C como exemplo, uma vez que é o tipo de linguagem mais fraca que você pode conceder e ainda a chama de estaticamente. C não é rápido por causa do sistema de tipos, as verificações de tipo ocorrem no momento da compilação. C é rápido porque existem poucas ou nenhuma medida de segurança e verificações para impedir que você atire no próprio pé. e porque é compilado em binários nativos.

— Sara

10

Sim definitivamente.
A digitação dinâmica tem vantagens definidas nos casos em que você deseja tratar tudo como um único tipo. Serialização / desserialização é um dos exemplos clássicos. É por isso que tanta programação na Web é feita em linguagens de script de tipo dinâmico: elas são adequadas para uma tarefa que envolve muita conversão de todos os tipos de dados de e para strings.

Por outro lado, para a programação de aplicativos, as linguagens estáticas funcionam muito melhor porque tentar tratar tudo como um único tipo não é frequentemente um requisito. Você geralmente deseja ter estruturas de dados eficientes com os dados representados como eles mesmos e não sendo convertido para outros tipos com muita frequência. Isso torna os recursos da digitação dinâmica uma desvantagem, e não um benefício, e é por isso que os aplicativos são quase exclusivamente escritos em linguagens estaticamente tipadas.

— Mason Wheeler
fonte

3

@Erik: Não tenho certeza se diria isso. As coisas mudam durante o desenvolvimento. Os requisitos podem mudar, ou você descobre que não está implementando um requisito corretamente e o código precisa ser atualizado. Ser capaz de mudar uma coisa e usar os erros do compilador resultantes para mostrar onde encontrar tudo o que precisa ser alterado fornece um enorme impulso à conveniência e à velocidade de desenvolvimento que você perde em idiomas onde essa técnica não está disponível. Essa é uma das razões pelas quais você simplesmente não vê aplicativos complicados desenvolvidos em linguagens dinâmicas.

— Mason Wheeler

9

@Mason Wheeler: resposta muito boa. + 1 Eu acrescentaria que a verificação de tipo estático também ajuda a encontrar erros mais cedo, com a correção do tipo de verificação do compilador. Por exemplo, depurei um programa Ruby de 200 linhas ontem e havia dois erros relacionados ao tipo que eu só consegui detectar executando o programa. Não quero pensar no que acontece em um projeto de 100.000 linhas. Portanto, a digitação dinâmica oferece mais flexibilidade, o que é bom nos contextos que você descreveu, pelo preço que você não consegue encontrar determinados erros no momento da compilação. Portanto, o tipo estaticamente está relacionado não apenas à eficiência, mas também à correção.

— Giorgio

11

@MasonWheeler Dois anos e muito mais C # e Java do que eu esperava mais tarde, agora discordo de algumas coisas. Aplicativos web complexos são feitos inteiramente com idiomas dinâmicos. Compilar vs. tempo de execução não faz sentido quando você pode fazer alterações visíveis imediatamente. E desenvolvi a opinião de que toda a confusão sobre os tipos faz muito mais sentido em uma linguagem processual do que em uma linguagem que deveria ser dirigida pelo OOP, onde os dados não deveriam mudar de mãos constantemente.

— Erik Reppen

11

@Erik: * wince * Primeiro, julgar a digitação estática como conceito por Java é como julgar carros como conceito por Pinto. E segundo, qualquer coisa em que as alterações possam ser "visíveis imediatamente" não é, por definição, um programa muito complexo, porque mesmo com o hardware moderno, programas complexos levam bastante tempo para preparar o código, seja um compilador ou um intérprete ( ou um compilador JIT) fazendo a preparação. Até os aplicativos Web mais impressionantes tendem a ser programas muito simples, apoiados por bancos de dados muito complexos, o que é uma questão totalmente diferente.

— Mason Wheeler

11

A capacidade de fazer abstrações complexas é ortogonal a um sistema estático versus dinâmico, e também ortogonal à velocidade. Existem sistemas de tipo estático por aí que permitem abstrações incrivelmente poderosas (embora às vezes misteriosas). Ter alterações que aparecem instantaneamente também é independente do sistema de tipos: você certamente pode criar intérpretes para idiomas de tipo estaticamente.

— Rufflewind

4

Do jeito que eu vejo, se você pode trabalhar naturalmente em uma linguagem de tipo estaticamente, a digitação estática é o caminho a percorrer. Em geral, o objetivo de um sistema de tipos é impedir que você execute operações com semânticas indefinidas (string) "hello" + (bool) true. Ter um nível extra de segurança impedindo você de executar essas operações pode ser uma boa maneira de evitar erros no seu código, mesmo sem extensos testes de unidade. Ou seja, a segurança de tipo fornece outro nível de confiança na correção semântica do seu código.

Mas os sistemas de tipos são muito difíceis de acertar. Eu não acredito que é um sistema tipo perfeito na natureza no momento da redação deste texto. (Por "sistema de tipos perfeito", quero dizer um sistema de tipos estrito, que não requer anotações de código detalhadas, que não gera erros de tipo falso-positivos e cujos erros de tipo são fáceis para o programador entender.) Além disso, ele pode será difícil entender os sistemas de tipos realmente bons que existem. Quando eu estava aprendendo Haskell, não sei dizer o número de erros de tipo obscuros que recebi ao tentar escrever o que parecia (para mim) o código correto. Normalmente, o código não estava correto (o que é um ponto a favor do sistema de tipos), mas demorou muitode trabalho para entender as mensagens de erro do compilador, para que eu pudesse corrigir os problemas subjacentes. Nas linguagens OO, você pode acabar pensando "esse argumento deve ser contrário ao tipo de entrada, não covariante!" Ou (mais provavelmente) reverter para previsões tipográficas para escapar dos limites do sistema de tipos. Os sistemas de tipos podem ficar muito mais complicados do que você imagina.

Pelo que vale, entendo que a dificuldade em criar bons sistemas de tipos faz parte do que motivou Gilad Bracha a incluir suporte de sistema de tipos conectável no Newspeak.

— Aidan Cully
fonte

Testes de unidade WRT, concordo plenamente. Você sempre vê pessoas dizendo "se você tiver bons testes de unidade, eles podem verificar a correção do tipo para você". Isso sempre me lembrou como Paul Graham (que acredita firmemente que a digitação dinâmica é sempre uma coisa boa) diz que uma linguagem que faz você executar manualmente o trabalho do compilador é uma linguagem defeituosa. Sorta faz você parar e pensar ...

— Mason Wheeler

Eu acho que muitas das preocupações sobre os 'perigos' das linguagens dinamicamente tipadas não levam em conta como escrevemos essas coisas. Grande parte do Python e JS pode ser escrita no estilo console. Parafuso de compilação vs. tempo de execução, posso testá-lo agora e ver o que acontece. Eu acho que você está em um ponto muito bom, no entanto. Nada me deixa mais louco no desenvolvimento da Web do lado do cliente do que quando todos os supostamente bons fornecedores de navegadores dão uma passagem confusa em código horrível, enquanto o IE6 ou 7 faz o inesperado, que é uma porcaria quando deveria e não apenas ... sugando de uma maneira mais típica.

— Erik Reppen

Os tipos de incompatibilidade @ mason-wheeler são erros trivalentes, e não é que linguagens dinâmicas não verifiquem os tipos, é apenas em tempo de execução. Minha experiência é que a maioria das linguagens estáticas tem o mesmo nível de cobertura dos testes de unidade, elas não estão perdendo nenhum teste ao fazer o compilador verificar os tipos com antecedência, e as linguagens dinâmicas não precisam adicionar testes específicos para verificar os tipos , o sistema de tempo de execução verifica seus tipos, se seu teste de unidade cobrir seu método, eles serão detectados.

— Jbtule 12/08

4

São ferramentas diferentes, mas não é por desempenho. É tudo uma questão de complexidade .

As linguagens dinâmicas geralmente visam a flexibilidade máxima e traz falta de validação e uma espécie de garantia. Então, é muito poderoso em programas de pequena escala, mas torna-se quase impossível manter programas de grande escala (complexidade).

Os idiomas estáticos geralmente visam a validação máxima. Seu primeiro objetivo é geralmente capturar erros (ou bugs) o mais cedo possível. Muitas garantias são feitas para a validação. Então é mais difícil aprender e iniciar, mas, à medida que os programas aumentam, ele fornece uma melhor validação do programa com muito menos custo (esforços de codificação).

Como resultado, as linguagens dinâmicas geralmente são adequadas para programas pequenos (quero dizer, muito pequenos), como páginas da Web dinâmicas, DSL do navegador da Web (não para aplicativos de navegador!) Ou scripts de shell. As linguagens estáticas se adaptam melhor às programações do sistema ou a qualquer outro material.

As descrições acima são sobre linguagens estáticas ou puramente dinâmicas. A maioria das linguagens da vida real está entre elas e mostra várias características.

Consulte aqui para obter mais detalhes: https://softwareengineering.stackexchange.com/a/105417/17428

— Eonil
fonte

11

"linguagens dinâmicas geralmente se encaixam em programas pequenos (quero dizer, muito pequenos)": Na minha experiência, você pode usar linguagens dinâmicas também para aplicativos de tamanho médio (e, é claro, existem pessoas que os usam com sucesso para aplicativos grandes). Concordo que quanto maior a base de código se tornar, mais você poderá lucrar com verificações estáticas fornecidas por linguagens estáticas.

— Giorgio

2

@ Giorgio Bem, isso é talvez porque eu sou viciado em coisas de validação estática. É tão doce para mim, e eu literalmente não pode viver sem eles, mesmo em pequena escala: p

— Eonil

Vejo as vantagens das linguagens estáticas (e votei na sua resposta). Recentemente, tenho usado Python e Common Lisp e admito que, na prática, você obtém bons resultados se usar um design limpo e, principalmente em Python, se escrever testes suficientes. Essas linguagens podem ser muito eficazes para criar um protótipo que pode ser facilmente transformado em seu código de produção. Mas, sim, para os projetos mais complexos, gostaria de ter a maior ajuda possível, por isso prefiro uma linguagem estática.

— Giorgio

1

Atualmente, programa em linguagens estáticas (C # e F #), mas gosto de programar em linguagens dinâmicas (Smalltalk, Ruby). Existem muitos prós e contras que as pessoas associam a um tipo versus outro que são mais sobre o idioma do que quando você aplica tipos. Por exemplo, linguagens dinâmicas geralmente têm uma sintaxe mais limpa e concisa, no entanto, F # e OCaml com seu sistema de inferência de tipo têm uma sintaxe tão limpa quanto qualquer linguagem dinâmica. E com a digitação estática, você tem refatorações automáticas reais e preenchimento automático, mas o Smalltalk, com todo o código-fonte em um banco de dados e cada método compilado separadamente, foi o primeiro idioma a ter refatorações automatizadas sérias e funcionou muito bem. Por fim, hoje em dia, as linguagens dinâmicas e estáticas modernas são seguras ao tipo, que é o aspecto mais importante do seu sistema de tipos,

— jbtule
fonte

Às vezes, suspeitava que a digitação estática é apenas uma pequena parte da equação do que torna uma linguagem mais ou menos flexível. Acho que o que também estou começando a perceber é que muitos desenvolvedores preferem um conjunto confortável de trilhos para guiá-los, em vez de ter liberdade para fazer coisas absurdamente perigosas, como sobrecarregar os operadores. O VS me faz querer chutar filhotes às vezes, mas eu definitivamente tenho curiosidade sobre F # e o que você disse sobre isso me deixa ainda mais curiosa. Suponho que isso seja algo mais do que apenas a coisa de C # em que você pode converter para um tipo mais inclusivo implicitamente.

— Erik Reppen

@erik, Oh sim mais de digitação implict e var: F # Tipo de inferência

— jbtule

-1

Estamos em 2015 agora, o que adiciona alguns trechos interessantes à conversa:

Partes significativas do mundo de back-end corporativo estão considerando ou começando a usar Python (dinâmico) em vez de Java (estático estrito)
O mundo do frontend corporativo está vendo coisas como o AngularJS v2, com base no TypeScipt: uma extensão digitada do Javascript.

Portanto, os caras do backend estão cansados da camisa de força desnecessária da digitação estrita, enquanto os caras do frontend estão cansados do caos da digitação dinâmica.

Bastante irônico: eu me pergunto se eles se encontrarão no meio, ou passarão um pelo outro com o boom sônico de um prazo passando ...? ;)

— Cornel Masson
fonte

A menos que você forneça alguma prova, eu diria que, no pior dos casos, o mundo back-end está em transição para o Go, mas Deus proíba qualquer material de script dinâmico. O mito de que uma linguagem de programação estática sempre tem um monte de cerimônia tem sido desmascarado com sistemas de inferência mais potentes e implementações REPL sólidos

— Den

Há muitas back-ends digitados dinamicamente em uso em grandes escalas. O Django, em particular, é muito popular no jornalismo e administra o back-end do NYT, do Guardian e do Washington Post. O Walmart está rodando no Node. O único mito é a idéia de que você não pode escrever em escala sem tipos estáticos. E, depois de ter passado algum tempo pensando em alguns desastres de código legado em Java que encontrei, acho que as pessoas que estão à vontade para fazê-lo ficam melhor se estiverem trabalhando com estática ou dinâmica.

— precisa

Na verdade, eu prefiro ter uma equipe Python qualificados no meu projeto de grandes empresas, em vez de um pobre Java one.Just para esclarecer a minha posição: eu postei a resposta acima como uma avaliação da

— Cornel Masson

Na verdade, eu prefiro ter uma equipe especializada em Python no meu grande projeto corporativo, do que um projeto pobre em Java. Apenas para esclarecer: publiquei a resposta acima como uma observação sobre as tendências que estou vendo na minha base de clientes, rede do setor e pesquisa geral. O back-end tradicionalmente estrito está adotando menos rigidez, o front-end tradicionalmente mais flexível, mais. Nem sequer é uma opinião sobre o que é "certo" (se houver) - não sei por que fui votado. Talvez a ironia esteja perdida ...

— Cornel Masson