As linguagens dinâmicas digitadas merecem todas as críticas? [fechadas]

Eu li alguns artigos na Internet sobre a escolha da linguagem de programação na empresa. Recentemente, muitas linguagens dinâmicas digitadas foram populares, como Ruby, Python, PHP e Erlang. Mas muitas empresas ainda permanecem com linguagens estáticas, como C, C ++, C # e Java.

E sim, um dos benefícios das linguagens estáticas de tipo é que os erros de programação são detectados antes, no tempo de compilação, e não no tempo de execução. Mas também há vantagens com linguagens dinâmicas digitadas. ( mais na Wikipedia )

A principal razão pela qual as empresas não começam a usar linguagens como Erlang, Ruby e Python, parece ser o fato de serem de tipo dinâmico. Essa também parece ser a principal razão pela qual as pessoas no StackOverflow decidem contra Erlang. Veja Por que você decidiu "contra" Erlang .

No entanto, parece haver uma forte crítica contra a digitação dinâmica nas empresas, mas eu realmente não entendo por que é tão forte.

Realmente, por que existem tantas críticas contra a digitação dinâmica nas empresas? Isso realmente afeta tanto o custo dos projetos ou o quê? Mas talvez eu esteja errado.

Sim, acredito que sim.

Existem alguns motivos que precisam ser considerados na seleção de um idioma para um novo projeto:

• Velocidade em tempo de execução. Comparado com C / C ++ / Fortran, Perl e Python são tão lentos que são engraçados.
• Velocidade de inicialização. Comparado às linguagens rápidas acima, o Java cai e chora enquanto a JVM continua carregando e carregando e ... while(1)....
• Capacidade de protótipo. Fazer exaustivamente o trabalho de declaração / definição exigido para C ++ ou Java aumenta o LOC, que é a única métrica conhecida que se correlaciona de maneira confiável com as contas de erros. Também leva muito tempo. Também requer um pouco mais de reflexão sobre tipos e conexões.
• Violabilidade interna. Mexer dinamicamente com seus internos é ótimo até você começar a depurar seu código auto-modificável . (Python, Lisp, Perl)
• Verificação de correção. Um compilador pode fornecer uma passagem rápida e semi-correta do seu código em C ++, e isso pode ser muito bom.
• Detalhes da análise estática. C e Java têm uma análise estática muito boa. Perl não é completamente estaticamente analisável em nível teórico (possivelmente também em Python). Tenho certeza de que Lisp também não.
• Plataformas estranhas levam apenas C, em geral.
• Cadeia de suporte. Se você pode ter um contrato no qual seus erros serão analisados ​​e trabalhados, isso é enorme .

Se você pode presumir que a organização com a qual trabalha está com o princípio "Avançar" (existe um termo contábil para isso) e não decide apenas aleatoriamente não trabalhar no software, é melhor que você usando o software. Como não há vendas de grandes empresas (implicando em assumir a responsabilidade de mantê-lo) Python / Perl / $ dynamic_language, isso reduz consideravelmente o risco.

Na minha experiência, os mantenedores de código aberto geralmente têm um problema em assumir total responsabilidade por correções de bugs e liberar atualizações. "É grátis, você trabalha nisso!" não é uma resposta aceitável para a maioria das empresas (não suas principais competências, entre outras coisas).

Claro, eu não estou falando sobre o mundo dos webapp / startup, que tende a seguir regras de alto risco / alta recompensa e é muito aberto a permanecer na ponta da tecnologia.

Você está dando muito crédito técnico aos tomadores de decisão da empresa. Há um ditado antigo: "Ninguém foi demitido por comprar a IBM". Se você seguir uma rota diferente e as coisas ficarem difíceis (como sempre), ninguém quer correr o risco de ser responsabilizado. Atenha-se aos padrões e culpe outra pessoa.

Muitas empresas mais jovens se tornarão as empresas de amanhã e usarão esses idiomas.

E não vamos esquecer as buggillion linhas de código escritas em VBA!

A razão pela qual as empresas usam C, C ++, C # e Java não é porque elas são estaticamente tipadas (pelo menos não diretamente). Os tomadores de decisão empresariais não estão fazendo esse tipo de escolha com base em uma comparação objetiva dos sistemas de tipos, garanto.

Empresas fazer preocupam:

• Custos de manutenção a longo prazo : você pode esperar razoavelmente que as coisas continuem a funcionar bem em 10 anos? Na verdade, é bom que a evolução da linguagem seja conservadora e compatível com versões anteriores (como no Java). A digitação estática é útil aqui, pois captura um grande tipo de bugs no momento da compilação antes que eles entrem nos seus sistemas de produção ...
• Disponibilidade de talentos - você poderá encontrar desenvolvedores para manter seu novo e brilhante sistema? e se o desenvolvedor original sair, todos os outros entenderão o código? Isso coloca um grande obstáculo na introdução de qualquer linguagem "nova" (especialmente se também cria novos requisitos para implantação, construção de sistemas, suporte operacional etc.). Isso oferece enormes vantagens para as linguagens amplamente usadas (C, C ++, C # e Java)
• Custos de integração : é fácil conectar-se / integrar-se a outras tecnologias que você já possui ou provavelmente adquire? Se você já possui uma pilha de sistemas J2EE legados, precisará integrar-se a eles. Uma nova solução Java EE provavelmente será muito mais prática para isso do que, por exemplo, Python.
• Previsibilidade / baixo risco : a plataforma / idioma é comprovada e posso ter certeza de que funcionará? Isso geralmente é mais importante que a simples produtividade. É muito mais fácil para um gerente convencer seu chefe a dar-lhe um grande orçamento para a mão de obra para construir um novo sistema do que para ele voltar mais tarde e dizer que não funcionou ...
• Suporte / suporte corporativo - as principais organizações internacionais estão comprometidas em oferecer suporte ao idioma e à plataforma? Eles assinarão um contrato para me apoiar, para que eu tenha alguém para ligar se as coisas derem errado?
• Neutralidade do fornecedor / independência da plataforma - vou ficar preso a um único fornecedor? Ou tenho uma ampla variedade de opções futuras de fornecedores / caminhos de transição disponíveis? Você não quer ficar preso em um beco sem saída arquitetônico, incapaz de progredir enquanto seus concorrentes comem o almoço. Se você está fazendo seu trabalho corretamente como arquiteto corporativo, precisa pensar pelo menos 5 a 10 anos à frente nesse assunto.

Pessoalmente, acho que, se você deseja usar linguagens dinâmicas na empresa, sua melhor chance é de longe usar algo que retribua em um ecossistema corporativo existente. Os mais notáveis ​​são as novas linguagens dinâmicas da JVM: por exemplo, JRuby, Groovy, Clojure. No que diz respeito ao gerenciamento de TI, essas são opções de linguagem dinâmica "seguras", porque operam dentro e funcionam muito bem com o restante do ecossistema corporativo Java.

A principal razão pela qual as empresas não começam a usar linguagens como Erlang, Ruby e Python, parece ser o fato de serem de tipo dinâmico.

Eu acho que essa é apenas a principal desculpa deles. A verdadeira razão é que as empresas realmente não as levam tão a sério e sentem que talvez sejam um pouco amadoras demais. Java e .NET são "nomes de grandes empresas", têm um bom marketing comercial, suporte comercial ao cliente e, portanto, são amplamente levados muito a sério.

É lamentável que praticamente não exista uma linguagem de tipo estatístico que seja tão popular quanto os nomes das grandes empresas. Por que os ambientes de programação de código aberto / software livre quase sempre são digitados dinamicamente? Isso pode indicar que uma linguagem de tipo estaticamente não é tão fácil de criar e que a digitação dinâmica é um "truque do preguiçoso". Se for esse o caso, as empresas que decidem contra idiomas de tipo dinâmico podem realmente ter razão.

• Os idiomas de tipo dinâmico tendem a ser mais lentos que os primos de tipo estatico.
• Os erros são mais difíceis de detectar e podem ser mais difíceis de depurar
• O compilador / intérprete tende a ser muito menos exigente com o que você pode ou não fazer. ou seja, você praticamente só captura erros de sintaxe no estágio de compilação
• Se você não for muito cuidadoso com o design de uma linguagem de tipo dinâmico, você acaba com Javascript, que é a linguagem dos cheiros de código

Edição: devo mencionar que minha principal linguagem de programação no momento é Python, que é digitado dinamicamente. Pessoalmente, adoro a liberdade resultante de não ter de pré-declarar variáveis, mas às vezes seria bom especificar (por exemplo) que tipo de parâmetros uma função leva para detectar erros mais cedo do que tarde.

Linguagens tipadas dinamicamente são percebidas (por alguns programadores / chefes) para produzir código que não funciona tão bem. O fato de um programa digitado dinamicamente ser compilado informa muito pouco sobre sua correção. O fato de uma linguagem de tipo estaticamente ser compilado informa muito mais. (Por outro lado, ainda há um longo caminho entre compilar e fazer a coisa certa; portanto, isso pode ser menos significativo do que parece)

Linguagens de tipo dinâmico são percebidas como linguagens de script. Você nunca escreveria um aplicativo no bash ou em um arquivo em lotes. Todos os idiomas digitados dinamicamente tendem a ser colocados em loop nessa categoria (injustamente).

Os idiomas digitados dinamicamente são mais lentos que os idiomas estaticamente. (Mas veremos quão bem o trabalho no JIT muda isso)

Nota: isso é principalmente subjetivo e baseado em minhas experiências e impressões.

Os idiomas de tipo dinâmico são muito diferentes dos idiomas de tipo estaticamente. Essas diferenças provavelmente se tornam mais importantes no software corporativo pesado do que na maioria dos outros aplicativos.

Linguagens de tipo estático tendem a ser muito prescritivas. Um método aceita apenas entradas que correspondem exatamente à sua assinatura. Os níveis de acesso tendem a ser muito importantes e as interfaces são definidas explicitamente, com restrições detalhadas mas inequívocas para impor essas definições.

Línguas dinamicamente tipadas, por outro lado, são muito pragmáticas. As conversões de tipo geralmente acontecem implicitamente, as funções podem ser reproduzidas se você fornecer o tipo errado de entrada, desde que se comporte de maneira semelhante. Em linguagens como Python, mesmo os níveis de acesso serão baseados em contrato e não em restrições técnicas (ou seja, é apenasprivate porque você disse para não usá-lo e ele tem um nome engraçado).

Muitos programadores preferem linguagens dinâmicas porque (indiscutivelmente) permitem prototipagem rápida. O código geralmente acaba mais curto (mesmo que por causa da falta de declarações de tipo) e se você deseja violar o protocolo adequado porque precisa de uma solução rápida e suja ou deseja testar algo, isso é facilmente possível.

Agora, a razão pela qual as empresas "empreendedoras" geralmente preferem linguagens estaticamente tipificadas é exatamente o fato de serem mais restritivas e mais explícitas sobre essas restrições. Embora na prática, mesmo o código estaticamente digitado possa ser quebrado por idiotas com um compilador, muitos problemas serão muito mais visíveis muito antes no processo (ou seja, antes do tempo de execução). Isso significa que, mesmo que a base de código seja grande, monolítica e complexa, muitos erros podem ser detectados facilmente, sem a necessidade de executar o código ou enviá-lo para o departamento de controle de qualidade.

A razão pela qual esse benefício não supera as desvantagens de muitos programadores fora desse ambiente é que esses são erros que geralmente são facilmente detectados por uma inspeção completa do código ou mesmo pela tentativa de executá-lo. Especialmente ao seguir uma metodologia orientada a testes, esses erros geralmente se tornam triviais de capturar e fáceis de corrigir. Além disso, com muitas dessas empresas tendo um ciclo de lançamento muito mais curto, a produtividade geralmente é mais importante que a rigidez e muitos testes (básicos) estão sendo feitos pelos próprios desenvolvedores.

A outra razão pela qual as empresas corporativas não usam muito as linguagens dinamicamente digitadas é o código legado. Por mais tolo que possa parecer para os nerds, as grandes corporações costumam aderir a soluções que funcionam, mesmo que tenham passado o prazo de validade. É por isso que muitas empresas importantes aplicam o Internet Explorer 6 e demoram a atualizar seus sistemas operacionais. É também por isso que eles costumam escrever um novo código em linguagens "antigas" (por exemplo, versões antigas do Java): é muito mais fácil adicionar algumas linhas de código a um pedaço inexistente de software do que obter aprovação para uma reescrita completa em um novo língua.

tl; dr: as linguagens estáticas parecem mais com a burocracia, por isso os gerentes corporativos gostam mais deles.

Não, acho que as linguagens dinamicamente digitadas merecem todas as críticas. (Ou, se preferir, eles merecem tantas críticas quanto as linguagens com tipos estatísticos.)

Na minha experiência (e não tento tentar generalizar essa afirmação), os programadores que criticam linguagens dinâmicas não as usaram. A conversa geralmente continua "mas com a digitação estática, o compilador detecta tantos erros!" e eu digo "bem, isso não é um problema, na minha experiência". (Normalmente, os outros programadores são de Java, Delphi ou experiência semelhante; não conheço nenhum programador de Haskell ou ML.)

A única coisa que realmente me incomoda é quando alguém afirma que a técnica Foo não pode ser executada (ou pode ser muito difícil de fazer) em uma linguagem tipicamente dinamizada ... quando essa técnica foi inventada, por e para uma tipografia dinamicamente língua. IDEs? Conversa fiada. Refatoração automática? Conversa fiada. Chamadores de / implementadores de? Conversa fiada.

As empresas simplesmente não estão adotando novos idiomas e ferramentas com rapidez suficiente e há boas razões para isso. Mas, quando uma das ferramentas principais, como o C #, implementa alguns desses recursos, elas entram nas empresas comuns.