Por que as linguagens de programação antigas continuam sendo revisadas?

46

Esta questão não é, "Por que as pessoas ainda usam linguagens de programação antigas?" Eu entendo isso muito bem. Na verdade, as duas linguagens de programação que conheço são C e Scheme, ambas datadas dos anos 70.

Recentemente eu estava lendo sobre as mudanças em C99 e C11 versus C89 (que parece ser a versão mais usada de C em prática e a versão que aprendi com K & R). Olhando em volta, parece que toda linguagem de programação em uso pesado recebe uma nova especificação pelo menos uma vez por década. Mesmo Fortran ainda está recebendo novas revisões, apesar do fato de que a maioria das pessoas que o usam ainda está usando o FORTRAN 77.

Compare isso com a abordagem, digamos, do sistema de composição TeX. Em 1989, com o lançamento do TeX 3.0, Donald Knuth declarou que o TeX era completo e versões futuras conteriam apenas correções de bugs. Mesmo além disso, ele afirmou que após a sua morte, "todos os erros restantes se tornarão recursos" e absolutamente nenhuma atualização adicional será feita. Outros são livres para usar o TeX e fizeram isso, mas os sistemas resultantes são renomeados para indicar que são diferentes do TeX oficial. Isso não é porque Knuth pensa que o TeX é perfeito, mas porque ele entende o valor de um sistema estável e previsível que fará a mesma coisa em cinquenta anos do que agora.

Por que a maioria dos designers de linguagem de programação não segue o mesmo princípio? Naturalmente, quando uma linguagem é relativamente nova, faz sentido que ela passe por um período de mudança rápida antes de se estabelecer. E ninguém pode se opor a pequenas alterações que não fazem muito mais do que codificar pseudo-padrões existentes ou corrigir leituras não intencionais. Mas quando uma língua ainda parece precisar de melhorias depois de dez ou vinte anos, por que não apenas forçar ou começar de novo, em vez de tentar mudar o que já está em uso? Se algumas pessoas realmente querem fazer programação orientada a objetos em Fortran, por que não criar "Objective Fortran" para esse propósito, e deixar o Fortran sozinho?

Suponho que se poderia dizer que, independentemente das revisões futuras, o C89 já é um padrão e nada impede que as pessoas continuem a usá-lo. Isso é verdade, mas as conotações têm consequências. O GCC irá, em modo pedante, alertar sobre a sintaxe que é obsoleta ou tem um significado sutilmente diferente em C99, o que significa que os programadores C89 não podem simplesmente ignorar totalmente o novo padrão. Portanto, deve haver algum benefício no C99 que seja suficiente para impor essa sobrecarga a todos que usam o idioma.

Esta é uma questão real, não um convite para discutir. Obviamente, tenho uma opinião sobre isso, mas no momento estou apenas tentando entender por que isso não é apenas como as coisas já são feitas. Eu suponho que a pergunta é:

What are the (real or perceived) advantages of updating a language standard, as opposed to creating a new language based on the old?

    
por Ian 01.11.2012 / 18:24
fonte

5 respostas

14

Acho que a motivação dos designers linguísticos para revisar as linguagens existentes é introduzir inovação, garantindo que sua comunidade de desenvolvedores alvo permaneça unida e adote a nova linguagem: mover uma comunidade existente para uma nova revisão de um idioma existente é mais eficaz do que criar uma nova comunidade em torno de um novo idioma. É claro que isso força alguns desenvolvedores a adotar o novo padrão, mesmo se eles estivessem bem com o antigo: em uma comunidade, você às vezes tem que impor certas decisões a uma minoria se quiser manter a comunidade unida.

Além disso, considere que um idioma de propósito geral tenta servir o maior número possível de programadores e, muitas vezes, ele é aplicado em novas áreas para as quais ele não foi projetado. Então, em vez de buscar simplicidade e estabilidade do design, a comunidade pode optar por incorporar novas ideias (mesmo de outras linguagens) à medida que a linguagem se move para novas áreas de aplicação. Nesse cenário, você não pode esperar acertar na primeira tentativa.

Isso significa que os idiomas podem sofrer mudanças profundas ao longo dos anos e a última revisão pode parecer muito diferente da primeira. O nome do idioma não é mantido por razões técnicas, mas porque a comunidade de desenvolvedores concorda em usar um nome antigo para um novo idioma. Portanto, o nome da linguagem de programação identifica a comunidade de seus usuários, e não a própria linguagem.

IMO a motivação por que muitos desenvolvedores acham isso aceitável (ou mesmo desejável) é que uma transição gradual para uma linguagem ligeiramente diferente é mais fácil e menos confusa do que um salto para uma linguagem completamente nova que levaria mais tempo e esforço para dominar . Considere que há vários desenvolvedores que possuem um ou dois idiomas favoritos e não estão muito interessados em aprender novos idiomas (radicalmente diferentes). E mesmo para aqueles que gostam de aprender coisas novas, aprender uma nova linguagem de programação é sempre uma atividade difícil e demorada.

Além disso, pode ser preferível fazer parte de uma comunidade grande e um ecossistema rico do que de uma comunidade muito pequena que usa uma linguagem menos conhecida. Então, quando a comunidade decide seguir em frente, muitos membros decidem seguir para evitar o isolamento.

Como um comentário lateral, acho que o argumento de permitir evolução mantendo compatibilidade com código legado é bastante fraco: Java pode chamar código C, Scala pode facilmente integrar com código Java, C # pode integrar com C ++. Há muitos exemplos que mostram que você pode facilmente interagir com código legado escrito em outro idioma sem a necessidade de compatibilidade com código-fonte.

OBSERVAÇÃO

De algumas respostas e comentários, pareço entender que alguns leitores interpretaram a pergunta como "Por que as linguagens de programação precisam evoluir".

Acho que esse não é o ponto principal da questão, pois é óbvio que as linguagens de programação precisam evoluir e por quê (novos requisitos, novas ideias). A questão é: "Por que essa evolução tem que acontecer dentro de uma linguagem de programação em vez de gerar muitas novas linguagens?"

    
por 09.11.2012 / 19:27
fonte
22

Compatibilidade retroativa é sua resposta. Um dado idioma, particularmente um amplamente usado como o C, pode ter código em operação, inalterado, por décadas. Se houver necessidade de manutenção, é útil ter compiladores que ainda possam direcionar esse tipo de plataforma enquanto executam em sistemas modernos para o trabalho de desenvolvimento. As padronizações e atualizações de versão de idiomas ajudam a manter as práticas de programação atualizadas, ao mesmo tempo em que proporcionam um senso de familiaridade para os programadores veteranos, que podem ser resistentes a aprender um idioma "novo" inteiro.

Tenha em mente que muitos dos idiomas atualizados são menos atualizados do que "novos bits brilhantes". As bestas de outrora muitas vezes ainda se escondem por dentro.

No que diz respeito a Knuth, lembre-se de que ele é acadêmico e que o TeX só é comprovado como correto, e não atualizado.

    
por 01.11.2012 / 18:28
fonte
5

Eu acho que a resposta óbvia é que ainda estão sendo feitos progressos em design de linguagem e arquitetura de sistema, e pessoas suficientes se preocupam com as linguagens mais antigas que querem tirar proveito de novas técnicas (múltiplos núcleos, melhor segmentação ou modelos de memória) eles são aparafusados ou assados no padrão de idioma. Também ajuda ter "uma forma verdadeira" de fazer coisas (por exemplo, análise de XML, acesso a banco de dados) com as quais você pode contar, independentemente de qual compilador ou plataforma você esteja, em vez de depender de terceiros. biblioteca que pode ou não ser instalada (e pode ou não ser a versão que você precisa, etc).

    
por 01.11.2012 / 20:50
fonte
1

Os conceitos ou objetivos fundamentais em que uma linguagem de propósito geral é construída não perdem relevância; no entanto, pequenas alterações no ambiente de trabalho ou no hardware exigem que atualizações ou pequenos recursos sejam adicionados a um idioma.

A forma como os algoritmos são expressos em uma linguagem não será alterada, embora possa precisar de suporte mais limpo para tipos de 64 bits ou mais suporte a expressões regulares padrão ou suporte mais robusto para novos tipos de sistemas de arquivos.

Existem alguns casos em que os 'novos' recursos estão sendo adicionados aos idiomas existentes, mas em muitos casos essas alterações equivalem a simplificações de coisas que as pessoas já estavam fazendo da maneira mais difícil. (Veja C ++ usando funções de alta ordem em vez de ponteiros de função e functores.)

    
por 01.11.2012 / 20:53
fonte
-2

Isto é um pouco como uma consideração da linguagem falada.

No passado, havia palavras que não eram usadas tão frequentemente como são agora (ou usadas para um significado diferente).

por exemplo. bom: em (muito antigo) o inglês tem o significado quase inverso do que usamos hoje, especialmente quando usado para descrever o personagem de alguém.

Ruim: não muito tempo atrás, o mal só tinha um significado, agora pode significar algo que é "super incrível" (é usado de maneira fesica (eu provavelmente sinto falta de soletrado)!

outro novo desenvolvimento é o celular "Fala de texto" para idiomas escritos.

Eu pessoalmente não vejo por que uma linguagem de programação não vai se desenvolver de maneira similar, palavras e funções especificaram significados / ações, e é necessário mudar de modo a incorporar novas idéias, novas metodologias. / p>

Eu conheço pessoas que falam muitas línguas diferentes, e elas geralmente sugerem que depois do terceiro ou quarto dia fica mais fácil aprender uma nova.

Eu não sei se existem programadores que tenham uma experiência semelhante, eu não ficaria surpreso se houvesse.

Eu sei que me sinto feliz em programar em JAVA (por mais que eu me sinta feliz em falar em inglês) Isso não significa que eu não possa me comunicar em 'american english' ou 'australian english' embora haja algumas 'pegadinhas' para tem cuidado com. Assim como ir de Java para PHP para Perl, as construções são semelhantes, mas há pequenas dicas para me pegar e me fazer bater a cabeça contra a parede.

Isso é diferente de mudar do inglês para o francês ou do Java para o SAS. estes são tão diferentes que leva um bom tempo para se tornar proficiente neles.

De qualquer forma, essa é a minha opinião sobre isso.

    
por 30.11.2012 / 17:02
fonte