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

35

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.

Jonas
fonte
3
Eu acho que a digitação estática com inferência de tipo e possível digitação de pato é a melhor maneira possível de fazer as coisas. Também é muito complicado
Casebash
2
Acabei de dar uma olhada na digitação de pato do C # (não uso o idioma) e, embora pareça preencher a definição de digitação de pato, a verbosidade necessária parece derrotar o objetivo. Isso não quer dizer que ocasionalmente não seja útil.
Chinmay Kanchi
3
Sou apenas eu ou há mais críticas às linguagens estaticamente tipadas do que às dinamicamente? Além disso, na minha experiência, as escolhas de idiomas / tecnologia das grandes "empresas" parecem ser ditadas pelas tendências atuais / escolhas seguras, em vez de qualquer mérito técnico real.
MAK
2
@ChinmayKanchi: Verbosidade? Você apenas declara algo como dynamice começa a usá-lo. Não é mais detalhado do que chamadas de método normais ou sobrecargas de operador.
Joey
4
Não posso contar o número de horas que perdi nos erros de depuração da minha empresa atual no código Groovy on Grails, que o compilador teria detectado imediatamente se usássemos o Java.
WKS

Respostas:

46

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.

Paul Nathan
fonte
16
"É grátis, você trabalha nisso!" <- Maior problema com o F / OSS em geral, eu tinha +1, mas estou sem votos :(
Billy ONeal
4
Bom resumo. Vou abordar que tipos bem construídos transmitem significado semântico (eu posso olhar para um tipo e entender o que ele faz, como ele pode ser usado) e pode ser usado para reforçar a correção (eu posso criar um tipo que aceite apenas informações restritas) ), e eu não obter erros mudos de erros de digitação (eu odeio declaração auto-variável)
SMITHCO
4
Você pode obter suporte comercial para qualquer grande projeto de código aberto. As grandes empresas usam PLs dinamicamente digitados para grandes partes (com certeza as adequadas), o Facebook usa PHP (UI) e Erlang (bate-papo), o Twitter usa Ruby (UI), o Google usa Python (não sei o que) e Lisp e Python são sendo usado em muitos projetos de pesquisa sofisticados. Nota: eu sou desenvolvedor de C # que (quase) nunca usei uma linguagem de tipo dinâmico; no entanto, esses pontos não são válidos em uma extensão considerável.
Kaveh Shahbazian
4
Eu gosto da sua resposta, mas Java não for digitado dinamicamente ...
Mehrdad
2
@PaulNathan: Você está pensando demais. A pergunta era sobre linguagens de tipo dinâmico, e esta resposta menciona Java como se fosse de tipo dinâmico.
Mehrdad
24

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!

JeffO
fonte
11
+1 para "... as empresas de amanhã [e] usarão esses idiomas".
Rdmueller
6
"Existem muitas empresas mais jovens que se tornarão as empresas de amanhã e usarão esses idiomas.": Você parece sugerir que os idiomas dinâmicos são bastante novos e precisam de tempo para serem adotados por mais empresas. Por outro lado, as linguagens dinâmicas já existem há muito tempo.
Giorgio
17

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.

Mikera
fonte
11
Não acredito que ninguém tenha votado na sua resposta ainda.
Sebastian N.
11

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.

Timwi
fonte
8
Sério? A última vez que vi, o Google investiu bastante peso e um esforço de desenvolvimento substancial por trás do Python, incluindo a contratação do criador do Python e permitindo que ele gaste 50% de seu tempo trabalhando na linguagem. O Google também contribui com uma boa quantidade de código para o Python, especialmente agora que a transferência sem carga foi mesclada na árvore de origem do Python 3. Isso faz do Python um "grande nome comercial" para mim.
Chinmay Kanchi
13
@Chinmay Kanchi: Interessante como você tira sua conclusão de uma estatística com um tamanho de amostra
460 Timwi
6
Touché. No entanto, algumas de suas conclusões também são falhas. A implementação adequada de uma linguagem dinâmica é muito mais difícil do que a implementação de uma linguagem de tipo estaticamente. A digitação dinâmica certamente não é um "truque do homem preguiçoso", como você diz. Ele permite que os desenvolvedores sejam preguiçosos, mas não a pessoa que escreve o compilador / intérprete. De fato, otimizar uma linguagem de tipo dinâmico é tão difícil que só consigo pensar em uma linguagem que, nos últimos tempos, tenha recebido esse tratamento extensivamente (JavaScript), embora existam projetos de otimização / JIT para outras linguagens (Python, PHP).
Chinmay Kanchi
2
Além disso, se você acha que as linguagens dinamicamente digitadas são as mais usadas em ambientes de código aberto, isso está longe de ser claro. Dependendo da métrica que você escolher, isso pode ser verdade, mas geralmente não é. Medindo linhas de código, C vence de longe. Se você medir quais idiomas são usados ​​em projetos de código aberto, incluindo os de vários idiomas, os idiomas mais populares são JavaScript, C, C ++ e PHP nessa ordem. Se você medir apenas o idioma principal, os idiomas mais populares são Perl, Java, C # e JavaScript. bit.ly/C6xTB
Chinmay Kanchi
7
É claro que escrever um otimizador para idiomas de tipo dinâmico é difícil, mas não um intérprete : você pode acabar com todas as verificações de tipo e o resto é o mesmo. Nenhum criador de linguagem amador pensa em escrever um otimizador. - Com relação ao último bit, não pretendi sugerir que a maioria dos softwares de código aberto seja escrita em uma linguagem de programação de tipo dinâmico, mas sim na maioria das linguagens de programação de código aberto (eu disse "ambientes" porque estou falando sobre compiladores / intérpretes, IDEs, etc.) são de tipo dinâmico.
Timwi
9
  • 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.

Chinmay Kanchi
fonte
11
Embora seja verdade que o compilador não é meticuloso, o intérprete geralmente o é. Na maioria das vezes, o intérprete detecta situações problemáticas e sinaliza erros.
Winston Ewert
17
Adoro digitação dinâmica, mas odeio não ter que pré-declarar variáveis! Muitas vezes, acabo introduzindo acidentalmente uma nova variável porque escrevi incorretamente o nome de uma variável.
Frank Shearar
11
@ Frank: Eu imprimivelmente amo que o Perl tem uma configuração para forçar a declaração de variáveis. É uma das vantagens de Perl, na minha opinião.
Paul Nathan
8

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)

Winston Ewert
fonte
2
"São percebidos por" alguns programadores. Quando tenho argumentos com programadores sobre tipagem dinâmica, eles geralmente acabam admitindo que nunca usaram esse tipo de linguagem.
precisa saber é o seguinte
11
@ Frank Você está dizendo que as pessoas que defendem a inferioridade da digitação dinâmica geralmente não a usam?
Winston Ewert
2
@ Frank: Eu tenho usado esse tipo de linguagem, e na maioria das vezes o resultado tem sido uma bagunça insustentável. (Para ser justo, era PHP e PHP tem outros problemas além de tipagem dinâmica)
Billy ONeal
@ Billy: Eu acho que isso é comum. Eu fiquei com digitação dinâmica por anos por causa da minha experiência com VB - quando finalmente percebi que essa implementação terrível e esquizofrênica da digitação dinâmica não era típica, minha opinião mudou dramaticamente.
Shog9
@Winston: estou dizendo que as pessoas com quem discuti não o fizeram. Tem sido um caso, para mim, "a digitação dinâmica não pode funcionar" ... mas eles usarão com prazer muitas técnicas primeiro desenvolvidas em, por e para linguagens dinâmicas (IDEs, refatoração, no topo da minha cabeça). Além disso, perguntas como esta: stackoverflow.com/questions/2317579 indicam que, embora provavelmente não seja universal, meu caso de discutir com programadores do tipo não pode funcionar, mas não tentei não é isolado. (Me, eu acho que ambas as abordagens têm valor.)
Frank Shearar
8

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.

Alan Plum
fonte
3
Idiomas com regras de digitação imprecisas criam muitas oportunidades para coisas erradas que meio que funcionam. Em JavaScript, por exemplo, passar um número para o código que espera uma string geralmente se comportará como se alguém tivesse passado uma representação de string desse número, mas nem sempre. Tentar, por exemplo, anexar 456 a 123 não renderá 123456, mas sim 579. A menos que seja claro quem é responsável pela conversão de número para string, isso pode ser feito de forma redundante ou não é possível.
Supercat
11
@ supercat, acho que PHP e JavaScript são bons exemplos para as duas maneiras de lidar com esse problema (no que diz respeito aos operadores): no PHP, os operadores são inequívocos - +pegam números e os adicionam, se você quiser concatenação .; em JS, ambas as operações compartilham o mesmo operador - se você não souber como seus valores se comportarão, é esperado que os converta explicitamente. É claro que isso também tem a ver com digitação solta versus digitação estrita (Python é ainda mais rigoroso), mas basicamente você precisa garantir que seus valores tenham o tipo certo ou fazer com que suas operações apliquem os tipos esperados.
Alan Plum
11
Eu não estou muito familiarizado com o PHP, mas parece que ele usa o que eu chamaria de abordagem "certa". Javascript é IMHO abominável de várias maneiras, mas acho que o comportamento de "+" é um dos piores. Na verdade, não estou convencido de que a digitação dinâmica frouxa-goosy teria muita vantagem sobre um sistema de tipos mais forte que permitia a uma interface declarar que coisas de alguma outra classe ou tipo de interface deveriam ser implementadas ou derivadas, com regras específicas sobre como as reivindicações seriam priorizadas. A grande limitação que eu estou ciente de com estruturas estruturalmente digitadas presentes é que ...
supercat
11
... se duas pessoas desenvolvem interfaces semelhantes de forma independente, não há como terceiros escreverem código que possa usá-las de forma intercambiável. Se um terceiro pudesse definir uma nova interface e declarar que as implementações de uma ou de ambas as existentes deveriam implementar automaticamente a nova (usando wrappers fornecidos na nova interface, se necessário), acho que lidaria com 99% do que é semanticamente bom sobre digitação dinâmica.
Supercat #
3

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.

Frank Shearar
fonte
Não queria bagunçar minha resposta com minha postura pessoal, que é a seguinte: a ferramenta certa para o trabalho certo. Qualquer que seja o tipo de linguagem usado, é mais adequado para algumas tarefas e mais adequado para outras do que outro tipo de linguagem.
Frank Shearar
6
Quando o outro programador vem de Haskell, ele já sabe que é a linguagem superior às linguagens Java e dinâmica;)
Andres F.
0

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.

aggietech
fonte
Não sei por que isso foi rebaixado, mas é uma afirmação perspicaz. As empresas são lentas e conservadoras. As pessoas também preferem mudanças graduais (como a palavra-chave dinâmica em C #, que ocasionalmente permite a digitação dinâmica em um idioma estaticamente digitado) a mudanças repentinas (como Ruby).
Vaddadi Kartick