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

34

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

E, sim, um dos benefícios das linguagens tipificadas estáticas é que os erros de programação são detectados antes, em tempo de compilação, e não em tempo de execução. Mas também há vantagens com linguagens tipificadas dinâmicas. ( 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 dinâmicas. Essa também parece ser a principal razão pela qual as pessoas no StackOverflow decidem contra o Erlang. Veja Por que você decidiu "contra" Erlang .

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

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

    
por Jonas 01.09.2010 / 21:46
fonte

9 respostas

46

Sim, acredito que sim.

Existem algumas razões que precisam ser consideradas na seleção de um idioma para um novo projeto:

  • Velocidade do tempo de execução. Comparado ao C / C ++ / Fortran, Perl e Python são tão lentos que é engraçado.
  • Velocidade de inicialização. Comparado com os idiomas rápidos acima, o Java cai e chora enquanto a JVM continua carregando e carregando e ... while(1) ....
  • Capacidade de protótipo. Examinar exaustivamente e fazer o trabalho de declaração / definição necessário para C ++ ou Java aumenta o LOC, que é a única métrica conhecida que se correlaciona de maneira confiável com contagens de bugs. Também leva muito tempo. Também requer um pouco mais de reflexão sobre tipos e conexões.
  • Furtividade interna. Mexer dinamicamente com seus internos é ótimo até você começar a depurar seu código de auto-modificação . (Python, Lisp, Perl)
  • Verificação de exatidão. Um compilador pode fornecer uma rápida passagem de semi-correção do seu código em C ++, e isso pode ser realmente legal.
  • Detalhes da análise estática. C e Java têm uma boa análise estática. O Perl não é completamente analisável estaticamente em um nível teórico (possivelmente também em Python). Tenho certeza de que Lisp também não é.
  • Plataformas estranhas só aceitam C, em geral.
  • Cadeia de suporte. Se você pode ter um contrato que irá receber seus erros e trabalhou, isso é enorme .

Se você puder presumir que a organização com a qual você está trabalhando tem o princípio de "Avançar" (há um termo contábil para isso), e não decidirá aleatoriamente não trabalhar na organização software, então você tem um caso muito melhor para usar o software. Uma vez que não há venda de grandes empresas (carregando a implicação de assumir a responsabilidade de mantê-lo) Python / Perl / $ dynamic_language, reduz consideravelmente o risco.

Na minha experiência, os mantenedores de software livre geralmente têm um problema em assumir responsabilidade por correções de bugs e liberação de 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 webapp / startup, que tende a se basear em regras de alto risco / alta recompensa e é muito aberto para ficar na ponta da tecnologia.

    
por 14.09.2010 / 22:19
fonte
24

Você está dando muito crédito técnico para os tomadores de decisão da empresa. Existe um velho ditado: "Ninguém foi demitido por comprar a IBM". Se você seguir um caminho diferente e as coisas ficarem rochosas (elas sempre acontecem), ninguém quer se arriscar a ser culpado. Atenha-se aos padrões e culpe alguém.

Existem muitas empresas mais jovens que futuramente se tornarão as empresas de amanhã e usarão essas linguagens.

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

    
por 17.09.2010 / 21:47
fonte
16

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

As empresas do importam-se com:

  • Custos de manutenção a longo prazo : pode razoavelmente esperar que as coisas continuem a funcionar bem daqui a 10 anos? Na verdade, é bom que a evolução da linguagem seja conservadora e compatível com versões anteriores (como no Java). A tipagem estática é útil aqui porque captura um tipo principal de bugs em tempo de compilação antes que eles entrem em seus sistemas de produção .....
  • Disponibilidade de talentos - você conseguirá encontrar desenvolvedores para manter seu novo sistema brilhante? E se o desenvolvedor original sair, todos entenderão o código? Isso coloca um grande obstáculo na introdução de qualquer linguagem "nova" (especialmente se ela também criar novos requisitos para implantação, sistemas de construção, suporte operacional etc.). Isto dá uma enorme vantagem para as linguagens que são amplamente utilizadas (C, C ++, C # e Java)
  • Custos de integração : é fácil se conectar / integrar com outras tecnologias que você já possui ou pode adquirir? Se você já tiver uma pilha de sistemas J2EE herdados, precisará integrá-los. É provável que uma nova solução Java EE seja muito mais prática para isso do que, por exemplo. Python.
  • Predigibilidade / baixo risco : a plataforma / idioma é comprovada e posso ter certeza de que funcionará? Isso geralmente é mais importante que a produtividade simples. É muito mais fácil para um gerente persuadir seu chefe a dar a ele 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 .....
  • Backup / suporte a empresas - 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 de plataforma - vou ficar preso a um único fornecedor? Ou tenho uma ampla gama de futuras opções 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 seu almoço. Se você está fazendo seu trabalho corretamente como um arquiteto corporativo, precisa pensar pelo menos 5 a 10 anos à frente sobre essas coisas.

Pessoalmente, acho que, se você quiser usar linguagens dinâmicas na Empresa, sua melhor chance é, de longe, usar algo que esteja em segundo plano 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 elas operam dentro e funcionam bem com o restante do ecossistema corporativo Java.

    
por 20.02.2013 / 16:50
fonte
10

The main reason why enterprises don't start to use languages like Erlang, Ruby and Python, seem to be the fact that they are dynamic typed.

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

É lamentável que praticamente não exista uma linguagem com tipagem estática que seja tão popular quanto os nomes das grandes empresas. Por que os ambientes de programação de software livre / código aberto quase sempre são dinamicamente digitados? Isso pode indicar que uma linguagem com tipagem estática não é tão fácil de ser feita, e que a digitação dinâmica é um “truque do homem preguiçoso”. Se for esse o caso, as empresas que decidem contra linguagens tipificadas dinamicamente podem realmente ter um ponto.

    
por 02.09.2010 / 22:08
fonte
9
  • Idiomas dinamicamente tipificados tendem a ser mais lentos do que os primos digitados estaticamente.
  • 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 quanto ao que você pode e não pode fazer. ou seja, você praticamente só detecta erros de sintaxe no estágio de compilação
  • Se você não for muito cuidadoso com o design de uma linguagem tipada dinamicamente, acabará com o Javascript, que é a a linguagem do código cheira

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

    
por 01.09.2010 / 22:22
fonte
8

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

Linguagens dinamicamente tipadas são percebidas como linguagens de script. Você nunca escreveria um aplicativo no bash ou em um arquivo de lote. Todas as linguagens digitadas dinamicamente tendem a ser colocadas em loop nessa categoria (injustamente).

Linguagens dinamicamente tipadas são mais lentas que as linguagens digitadas estaticamente. (Mas vamos ver o quão bem o trabalho no JIT muda)

    
por 14.09.2010 / 20:00
fonte
8

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

Linguagens dinamicamente tipadas são muito diferentes das linguagens estaticamente tipadas. Essas diferenças provavelmente se tornam mais importantes em softwares corporativos pesados do que na maioria das outras aplicações.

Linguagens com tipagem estática tendem a ser muito prescritivas. Um método só receberá uma entrada que corresponda 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 não ambíguas, para impor essas definições.

Idiomas dinamicamente digitados, por outro lado, são muito pragmáticos. As conversões de tipo geralmente acontecem implicitamente, as funções podem até ser executadas se você fornecer o tipo errado de entrada, desde que se comporte de maneira semelhante. Em linguagens como o Python, mesmo os níveis de acesso serão baseados em contrato e não em restrições técnicas (ou seja, é apenas private porque você é solicitado a não usá-lo e tem um nome engraçado).

Muitos programadores preferem linguagens dinâmicas porque (sem dúvida) permitem a criação de protótipos rápidos. O código muitas vezes acaba mais curto (se apenas por causa da falta de declarações de tipo) e se você quer violar o protocolo apropriado porque você precisa de uma solução rápida e suja ou quer testar algo, isso é facilmente possível.

Agora, o motivo pelo qual as empresas "privadas" geralmente preferem as linguagens com tipagem estática é exatamente o fato de serem mais restritivas e mais explícitas sobre essas restrições. Embora, na prática, até o código tipado estaticamente 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 capturados facilmente, sem a necessidade de executar o código ou enviá-lo para o departamento de QA.

O motivo pelo qual os benefícios não superam as desvantagens de muitos programadores fora desse ambiente é que esses são erros que geralmente são facilmente capturados pela inspeção completa do código ou até mesmo pela tentativa de executá-lo. Especialmente ao seguir uma metodologia baseada em testes, esses erros muitas vezes se tornam triviais e fáceis de corrigir. Além disso, com muitas empresas desse tipo 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 corporações corporativas não usam linguagens dinamicamente tipificadas é muito o código legado. Por mais bobo que pareça para nós, nerds, as grandes corporações muitas vezes se apegam a soluções que funcionam, mesmo que estejam bem além do prazo de validade. É por isso que muitas empresas importantes aplicam o Internet Explorer 6 e são lentas para atualizar seus sistemas operacionais. É também por isso que eles freqüentemente escrevem novos códigos em idiomas "antigos" (por exemplo, versões antigas de Java): é muito mais fácil adicionar algumas linhas de código a um software não-vivo do que obter aprovação para uma reescrita completa em um novo idioma.

tl; dr: linguagens estáticas parecem mais com burocracia, portanto, gerentes de empresas iniciantes gostam mais delas.

    
por 19.09.2010 / 18:33
fonte
3

Não, não acho que linguagens digitadas dinamicamente mereçam todas as críticas. (Ou, se preferir, eles merecem tanta crítica quanto os idiomas estaticamente tipados.)

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

A única coisa que realmente me preocupa é 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 tipada dinamicamente ... quando essa técnica foi inventado em, por e para uma linguagem tipada dinamicamente. IDEs? Conversa fiada. Refatoração automática? Conversa fiada. Chamadores de / implementadores de? Smalltalk.

    
por 19.09.2010 / 14:52
fonte
-1

As empresas simplesmente não estão adotando novas linguagens e ferramentas com rapidez suficiente e há boas razões para isso. Mas, quando uma das principais ferramentas como o C # implementa alguns desses recursos, eles vão se infiltrar nas principais empresas ...

    
por 17.09.2010 / 21:57
fonte