Diferenças arquiteturais entre linguagens dinâmicas e estáticas

Existem grandes diferenças arquiteturais ao projetar aplicativos que serão construídos em linguagens estáticas (como C # ou Java) e linguagens dinâmicas (como Ruby ou Python)?

Quais são as possibilidades de design que podem ser uma boa escolha para um tipo ruim para o outro? Existem recursos úteis que podem ser obtidos com um tipo que não é com o outro (em design e arquitetura, é claro)?

Além disso, existem padrões de design específicos para dinâmicas?

Vamos esclarecer algumas coisas:

1. Script interativo e linguagens estáticas não são mutuamente exclusivas. F # e Haskell têm interfaces REPL.
2. Linguagens dinâmicas e alto desempenho não são mutuamente exclusivos, embora algumas otimizações sejam. Atualmente, o JavaScript é muito rápido na maioria dos navegadores.
3. Mesmo em linguagens dinâmicas, você ainda precisa documentar, lembrar e pensar em tipos.
4. Devido à crescente popularidade da inferência de tipo, muitas linguagens estáticas não precisam mais anotar tipos com mais frequência. Em linguagens estáticas com forte inferência de tipo, o compilador descobre quais são os tipos do seu código, na maioria das vezes, e informa se você faz algo que viola as definições de tipo. No que diz respeito à sintaxe, isso fornece o melhor dos dois mundos.
5. OOP e linguagens dinâmicas não são mutuamente exclusivas. O PHP agora suporta classes e até herança.

Todas essas semelhanças surpreendentes à parte, existem algumas diferenças práticas que influenciam o processo de desenvolvimento:

1. Linguagens dinâmicas permitem maneiras interessantes de transmitir dados no pequeno .
2. Os idiomas estáticos permitem reduzir a quantidade de testes que você precisa fazer, tornando muitos tipos de erros impossíveis.
3. Na mesma linha, linguagens estáticas permitem recursos interessantes de validação e conversão automática, como unidades de medida em F # .
4. Levadas ao extremo, as linguagens estáticas permitem contratos de código e verificação formal, que podem documentar e evitar coisas como possíveis dividir por zeros, loops infinitos, referências nulas, tamanhos ou índices de listas inválidos, erros de intervalo e outros estados logicamente inválidos que você pode definir.
5. Levando esse extremo ainda mais longe, as otimizações da CPU podem ser feitas com base nessas restrições estáticas, o que gera um desempenho ainda melhor.

Há também um tipo de programa que nunca poderia ter sido criado sem a digitação estática: Singularity , um sistema operacional sem limites de processo de hardware. Está escrito em uma pequena quantidade de C, alguns C # e um dialeto de C # chamado Spec #, que suporta contratos de código.

Apesar de ter sido escrito em uma linguagem de coleta de lixo, o desempenho da comunicação multitarefa e interprocessos neste sistema operacional é de fato melhor do que qualquer outra coisa lá fora, devido ao fato de que todos os processos são executados em um espaço de memória e devido às otimizações formais de verificação. Mencionado acima. Você não poderia fazer isso sem a digitação estática, porque, para que os programas não comprometam o restante do sistema, os objetos de comunicação precisam ser estaticamente verificáveis.

Na maioria das vezes, as arquiteturas devem ser muito parecidas. As linguagens estáticas podem facilitar a discussão dos programas em muitos casos, porque os tipos são bem definidos, mas um programa de linguagem dinâmica bem escrito também teria tipos que são, no mínimo, bem definidos na mente dos desenvolvedores.

Há uma diferença arquitetônica significativa. Atuação.

Dependendo do seu orçamento de hardware, carga de trabalho esperada e acordos de nível de serviço, talvez não seja possível atender aos requisitos com um idioma dinâmico.

Na maioria das vezes, a velocidade de desenvolvimento e a flexibilidade fornecidas pelas linguagens dinâmicas compensam os tempos de resposta mais lentos, maior consumo de CPU e memória. Porém, para sistemas maiores com restrições de orçamento ou desempenho, as despesas gerais de uma linguagem dinâmica podem ser altas.

Eu nunca pensei nesse sentido. Então, quando foi feito o Google, o blog de Peter Norvig foi um dos principais hits. Ele afirma que alguns padrões de design são mais fáceis de implementar em linguagens dinâmicas que as linguagens orientadas a objetos tradicionais, como C ++. Eu acho que deveria haver diferenças no design / arquitetura, já que ele observa que a implementação é mais fácil em linguagens dinâmicas. Vou tentar acrescentar mais à resposta à medida que estudar mais.

Existem grandes diferenças arquiteturais ao projetar aplicativos que serão construídos em linguagens estáticas (como C # ou Java) e linguagens dinâmicas (como Ruby ou Python)?

Não.

É um pouco mais fácil escrever estruturas sofisticadas para linguagens dinâmicas. Mas isso não é uma coisa de aplicação.

Quais são as possibilidades de design que podem ser uma boa escolha para um tipo ruim para o outro?

Nenhuma, realmente.

Você pode escrever coisas boas em qualquer idioma.

Existem recursos úteis que podem ser obtidos com um tipo que não é com o outro (em design e arquitetura, é claro)?

Não.

A diferença é que as linguagens dinâmicas são "escrever, executar, corrigir". Você pode experimentar e corrigir rapidamente.

Linguagens estáticas são "escrever, compilar, construir, executar, corrigir". Você não pode experimentar tão facilmente.

Fora isso, eles são quase idênticos em suas capacidades.

Existem padrões de design específicos para dinâmicas?

Talvez. O Python eval()e as execfile()funções - de certa forma - apontam para um recurso de linguagem dinâmica que é difícil (mas longe de impossível) de manusear em uma linguagem estática. Seria muito mais linhas de código para compilar e executar código no mesmo espaço de processo.

Não é específico do idioma dinâmico. É apenas mais fácil.