Linguagens dinâmicas x idiomas estáticos para sites [fechado]

Esta declaração sugere que idiomas de tipo estaticamente não são ideais para sites:

Vou contrastar isso com a construção de um site. Ao renderizar páginas da web, geralmente você tem muitos componentes interagindo em uma página da web. Você tem botões por aqui e pequenos widgets por lá, e há dezenas deles em uma página da Web, além de possivelmente dezenas ou centenas de páginas no seu site, que são dinâmicas. Com um sistema com uma área de superfície realmente grande como essa, o uso de uma linguagem de tipo estaticamente é realmente bastante inflexível. Acharia doloroso provavelmente programar no Scala e renderizar uma página da Web com ele, quando eu quiser apertar interativamente os botões e o que não estiver. Se todo o sistema precisa ser coerente, como o sistema inteiro, digite check apenas para poder mover um botão, acho que isso pode ser realmente inflexível.

^{Fonte: http://www.infoq.com/interviews/kallen-scala-twitter}

Isso está correto? Por que ou por que não?

Eu discordo totalmente. À medida que os sistemas crescem, as linguagens estaticamente garantidas garantem robustez no nível do componente e, portanto, flexibilidade no nível do sistema.

Além disso, o exemplo dado pelo autor realmente não faz sentido. Parece que esse cara não sabe que o polimorfismo pode ser alcançado por outros meios que não a digitação com patos.

Existem várias pessoas que afirmam que as linguagens dinâmicas são superiores, mas isso geralmente se baseia na falta de experiência com sistemas de tipos expressivos que, por exemplo, suportam subtipos estruturais, tipos de dados algébricos e funções de primeira ordem.

Primeiro, lembre-se de que o autor da declaração acima está falando sobre o desenvolvimento de sites. Então, ele está preocupado com o desenvolvimento da apresentação , e é aí que ele acha que Scala não seria uma boa escolha ...

Dito isto, eu tenho uma boa experiência com desenvolvimento web. Eu trabalhei por pelo menos 8 anos exclusivamente com ele, 5 dos quais em agências digitais.

E, sim, na minha experiência, uma linguagem compilada estaticamente na camada de apresentação pode ser um grande obstáculo. O conteúdo precisa ser alterado constantemente, com muito mais frequência do que os requisitos de negócios. E geralmente isso precisa ser feito por uma equipe distinta (os desenvolvedores "front-end"). Eles normalmente sabem muito sobre HTML, JavaScript, padrões da Web, CSS, mas não muito sobre linguagens do lado do servidor, como Java e C #. Eles também assumem que qualquer tipo de alteração em um modelo está disponível imediatamente ; eles não são usados ​​para compilar e digitar erros. E eles estão certos: linguagens de tipo estaticamente são muito boas para requisitos complexos e difíceis, como acesso a dados e regras de negócios, mas não tão boas para o desenvolvimento de interfaces.

Esse é, de fato, um dos principais benefícios do uso de uma linguagem de modelo especializada e interpretada como o Velocity . Seu fácil de usar, poder e flexibilidade são adequados para os desenvolvedores da camada de apresentação. E então os funcionários do lado do servidor são livres para usar uma linguagem séria e tipicamente estática em qualquer outro lugar ...

No entanto, também concordo que Scala é um pouco diferente. Sendo ao mesmo tempo muito menos detalhado e muito mais expressivo que o Java, acredito que poderia ser usado para o desenvolvimento de apresentações - então talvez possa ser usado com sucesso como uma linguagem de modelo. E se também pudesse ser combinado a uma estrutura como o Play (que compila o site automaticamente após cada alteração), poderia ser um IMHO vencedor. Ainda assim, mesmo o Play optou por uma linguagem de modelo do tipo Groovy (dinâmica), o que não é um bom sinal.

Resumindo: o problema com o Scala está muito mais relacionado ao fato de ele ser compilado. De fato, seu mecanismo de inferência de tipo faz com que você quase esqueça que também é digitado estaticamente.

(E desculpe pelo meu inglês. Deixe-me saber se algo não estiver claro, vou tentar consertar.)

Eu acho que o texto (e a maioria das respostas) está misturando idiomas tipicamente estatísticos e idiomas excessivamente detalhados . Obviamente, a interseção é muito grande (especialmente quando se considera apenas os idiomas mais populares); mas existem alguns exemplos interessantes de linguagens não verbais e de tipo estatístico: Go, Haskell, Scala, Rust…

Encorajo-vos a ler Strong Typing vs. Strong Testing de Bruce Eckel . Seu principal argumento é que a qualidade do software se resume a testes. Você pode testar de várias maneiras diferentes. Os compiladores testam algumas coisas no momento da compilação: tente armazenar uma string em uma variável int e ela provavelmente latirá para você. Em linguagens dinâmicas, muitos testes ocorrem em tempo de execução. Por fim, não importa quando o teste ocorre. Isso só tem que acontecer. O tempo que você ganha ao não compilar em idiomas dinâmicos perde o teste em tempo de execução. Você testou tudo de forma robusta, certo?

Dado isso, uma preferência por linguagens compiladas com sistemas de tipos rígidos versus linguagens dinâmicas é exatamente isso - uma preferência. Como boxeadores versus cuecas ou tangas versus calcinhas francesas. Não há resposta certa ou errada. Vesti-los com a atitude certa e só é incrível.

Concordo com isso na maioria dos casos, porque, se você lida com clientes em uma plataforma da Web, a flexibilidade é essencial.

As linguagens de tipo estático são mais robustas e seguras que as de tipo dinâmico, mas quando você começa a adaptar o código para agir de uma maneira que não deveria ser e você precisa rápido, as soluções parecem um pouco complexas e rígidas.

Portanto, se você tiver a alteração para mesclar tecnologias, recomendo criar um núcleo em uma linguagem de tipo estaticamente (o núcleo não muda muito) e usá-lo dinamicamente para a interação do usuário.

Eu acho que o autor deste post não analisou o próprio Scala. Embora eu concorde que Java e C # tenham limitações e sejam um pouco inflexíveis para o desenvolvimento da Web, o Scala é uma linguagem de tipo estaticamente bastante diferente do que você normalmente pensa quando ouve isso. O Scala permite a digitação de patos, bem como uma versão segura do tipo de aplicação de patches de macaco (através de conversões implícitas). Isso torna as bibliotecas de programação um pouco mais complexas, porque você terá que pensar em tipos, mas se você usar uma biblioteca como o Lift, ela se parecerá com uma linguagem dinâmica, exceto que o compilador informará sobre erros óbvios nos quais você não a usa. certo. Pessoalmente, acho que a estrutura da web de elevação não precisa se esconder do ruby ​​on trilhos ou similar. Dê uma olhada nos exemplos de código aqui ou aquie decida por si mesmo. Eu desenvolvo o elevador por um bom tempo agora e nunca tive uma situação em que tive um erro de tipo e pensei "Ah, cara, se isso fosse dinâmico, funcionaria" ... porque se fosse dinâmico, simplesmente não teria me dito que houve um erro até travar durante o tempo de execução.

Pessoalmente, acho que o que eles dizem é verdade para qualquer sistema, não apenas para sites. Você precisará digitar estática quando falar com o hardware, pois todo o resto a digitação dinâmica tem as mesmas desvantagens e benefícios, independentemente do que você faz, e o que é melhor depende do gosto e dos problemas específicos de cada projeto.

Resposta rápida prática: depende do tamanho e da complexidade do tamanho da web. Site pequeno, programa dinâmico. lang., site grande e complexo, programa estático lang.

Resposta chata estendida: Muitos desenvolvedores insistem que um site deve ser feito com um progresso dinâmico. langr. mas a verdade é que, eventualmente, as ferramentas de desenvolvimento da Web tendem a usar ou emular linguagens estáticas de tipo.

Eu trabalhei com PHP várias vezes e, mais cedo ou mais tarde, tivemos que adicionar muito código que verifica os tipos dos dados fornecidos, que estão implícitos em um programa de tipo estático. lang.

Lagn digitado. também ajuda o uso de IDE (s), que requer muita verificação de tipo.

(apresentado por seu vizinho programador & designer de compiladores ;-))

Eu meio que concordo. Quando eu olho para a maioria dos códigos C # front-end da Web, há muitas transmissões de strings e serialização de dados para strings. Basicamente, o HTTP como protocolo é um bom ajuste para linguagens dinâmicas.