ti-enxame.com

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

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 tipadas 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 capturados mais cedo, em tempo de compilação, em vez de em 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 na StackOverflow decide contra Erlang. Consulte 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 é que é forte.

Realmente, por que há 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.

35
Jonas

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 é engraçado.
  • Velocidade de inicialização. Comparado às linguagens rápidas acima, Java cai e chora enquanto a JVM continua carregando e carregando e ...while(1)....
  • Capacidade de protótipo. Examinar exaustivamente e executar o trabalho de declaração/definição necessário para C++ ou Java aumenta o LOC, que é a métrica conhecida somente 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.
  • Fiddlability interno. 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 realmente Legal.
  • 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 um nível teórico (Possivelmente Python também). Tenho certeza de que o LISP também não.
  • Plataformas estranhas levam apenas C, em geral.
  • Cadeia de suporte. Se você pode ter um contrato no qual você irá fará com que seus erros sejam analisados ​​e trabalhados, isso é enorme.

Se você pode presumir que a organização com a qual você está trabalhando tem o princípio "Avançar" (existe um termo contábil para isso) e não vai apenas decida aleatoriamente não trabalhar no software , você terá um argumento muito melhor para usar o software. Como não há grandes empresas venda (implicando em assumir a responsabilidade de mantê-la) Python/Perl/$ dynamic_language, 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 que é aceitável para a maioria das empresas (não para 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 estar muito aberto a permanecer na margem da tecnologia.

46
Paul Nathan

Você está dando muito crédito técnico aos tomadores de decisão da empresa. Há um velho ditado: "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.

Existem muitas empresas mais jovens que acabarão se tornando empresas de amanhã e usarão esses idiomas.

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

24
JeffO

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

Empresas faça se preocupam com:

  • 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. É provável que uma nova solução EE Java $ seja 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 do que 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 ...
  • Apoio/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 os novos idiomas dinâmicos 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 empresarial Java.

18
mikera

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. O verdadeiro motivo é 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", possuem 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 homem preguiçoso". Se for esse o caso, as empresas que decidem contra idiomas de tipo dinâmico podem realmente ter razão.

11
Timwi
  • 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 o Javascript, que é o idioma do cheiro de código

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

9
Chinmay Kanchi

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 gravaria 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 como o trabalho no JIT muda isso)

8
Winston Ewert

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, porém inequívocas, para impor essas definições.

Por outro lado, linguagens de tipo dinâmico 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, até os níveis de acesso serão baseados em contrato e não em restrições técnicas (ou seja, é apenas private porque você é instruído a 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, o motivo pelo 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 linguagens dinamicamente digitadas é o código legado. Por mais tolo que possa parecer para os nerds, as grandes empresas geralmente se apegam 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, então os gerentes corporativos gostam mais deles.

8
Alan Plum

Não, acho que as linguagens dinamicamente digitadas merecem todas as críticas. (Ou, se você preferir, eles merecem tantas críticas quanto as línguas de tipo estatístico.)

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 pega 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 possivelmente ser feita (ou pode ser muito difícil de fazer) em uma linguagem de tipo dinâmico ... quando essa técnica foi inventada em , por e para um idioma digitado dinamicamente. IDEs? Conversa fiada. Refatoração automática? Conversa fiada. Chamadores de/implementadores de? Conversa fiada.

4
Frank Shearar

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.

0
aggietech