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

Esta pergunta não é: "Por que as pessoas ainda usam linguagens de programação antigas?" Eu entendo isso muito bem. De fato, as duas linguagens de programação que conheço melhor 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 ainda ser a versão mais usada do C na prática e a versão que aprendi com a K&R). Olhando em volta, parece que toda linguagem de programação em uso pesado recebe uma nova especificação pelo menos uma vez a cada década. Até o Fortran ainda está recebendo novas revisões, apesar do fato de a maioria das pessoas ainda estar 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 estava completo e os lançamentos futuros conteriam apenas correções de bugs. Mesmo além disso, ele afirmou que, após sua morte, "todos os bugs restantes se tornarão recursos" e absolutamente nenhuma atualização adicional será feita. Outros são livres para distribuir o TeX e o fizeram, mas os sistemas resultantes são renomeados para indicar que são diferentes do TeX oficial. Isso não ocorre porque Knuth acha 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 que faz agora.

Por que a maioria dos designers de linguagem de programação não segue o mesmo princípio? Obviamente, quando um idioma é relativamente novo, faz sentido passar por um período de rápidas mudanças antes de se estabelecer. E ninguém pode realmente se opor a pequenas mudanças que não fazem muito mais do que codificar pseudo-padrões existentes ou corrigir leituras indesejadas. Mas quando um idioma ainda parece precisar de melhorias depois de dez ou vinte anos, por que não forçar ou recomeçar, em vez de tentar mudar o que já está em uso? Se algumas pessoas realmente querem fazer programação orientada a objetos no Fortran, por que não criar o "Objective Fortran" para esse fim e deixar o Fortran sozinho?

Suponho que se possa dizer que, independentemente de futuras revisões, 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, no modo pedante, avisa sobre a sintaxe que está obsoleta ou que tem um significado sutilmente diferente no C99, o que significa que os programadores do 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 pergunta real, não um convite para discutir. Obviamente, tenho uma opinião sobre isso, mas no momento estou apenas tentando entender por que não é assim que as coisas já são feitas. Suponho que a pergunta é:

Quais são as vantagens (reais ou percebidas) de atualizar um padrão de idioma, em vez de criar um novo idioma com base no antigo?

Eu acho que a motivação para os designers de idiomas revisarem os idiomas existentes é introduzir inovação e garantir que a comunidade de desenvolvedores alvo permaneça unida e adote o novo idioma: 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. Obviamente, isso força alguns desenvolvedores a adotar o novo padrão, mesmo que eles estejam bem com o antigo: em uma comunidade, às vezes você precisa impor determinadas decisões a uma minoria se quiser manter a comunidade unida.

Além disso, considere que uma linguagem de propósito geral tenta atender ao maior número possível de programadores e, frequentemente, é aplicada em novas áreas para as quais não foi projetada. Portanto, em vez de buscar a simplicidade e a estabilidade do design, a comunidade pode optar por incorporar novas idéias (mesmo de outros idiomas) à medida que o idioma 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 profundas mudanças ao longo dos anos e a revisão mais recente 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.

A motivação da OMI por que muitos desenvolvedores acham isso aceitável (ou até desejável) é que uma transição gradual para um idioma ligeiramente diferente é mais fácil e menos confusa do que um salto para um idioma completamente novo que levaria mais tempo e esforço para dominar. Considere que existem vários desenvolvedores que possuem um ou dois idiomas favoritos e não gostam muito de aprender novos idiomas (radicalmente diferentes). E mesmo para quem gosta 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 de um ecossistema rico do que de uma comunidade muito pequena usando um idioma menos conhecido. Assim, quando a comunidade decide seguir em frente, muitos membros decidem seguir para evitar o isolamento.

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

NOTA

A partir 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"?

Eu 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 idéias). A questão é: "Por que essa evolução precisa acontecer dentro de uma linguagem de programação em vez de gerar muitas novas linguagens?"

Compatibilidade com versões anteriores é a sua resposta. Uma determinada linguagem, particularmente uma amplamente usada como C, pode ter código que está em operação, inalterado, por décadas. Se houver necessidade de manutenção, é útil ter compiladores que ainda possam atingir esse tipo de plataforma enquanto rodam em sistemas modernos para o trabalho de desenvolvimento. Padronizações e atualizações de versões de idiomas ajudam a manter as práticas de programação atualizadas, ao mesmo tempo em que proporcionam uma sensação de familiaridade aos programadores veteranos que podem resistir ao aprendizado de uma linguagem "nova" inteira.

Lembre-se de que muitos dos idiomas atualizados são menos atualizados tanto quanto "têm novos bits brilhantes". Os animais de antigamente ainda espreitam por dentro.

No que diz respeito a Knuth, lembre-se de que ele é um acadêmico e que o TeX está comprovadamente correto, não atualizado.

Eu acho que a resposta óbvia é que ainda está sendo feito progresso no design da linguagem e na arquitetura do sistema, e muitas pessoas se preocupam com as linguagens mais antigas que desejam tirar proveito das técnicas mais recentes (múltiplos núcleos, melhores modelos de encadeamento ou memória) que são aparafusadas ou cozido no padrão de idioma. Também ajuda a ter "uma maneira verdadeira" de fazer as coisas (por exemplo, análise de XML, acesso ao banco de dados) com as quais você pode confiar, independentemente do compilador ou plataforma em que estiver, ao contrário de depender de terceiros. biblioteca que pode ou não estar instalada (e pode ou não ser a versão necessária, etc).

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 maneira como os algoritmos são expressos em um idioma não será alterada, mesmo que seja necessário um suporte mais limpo para tipos de 64 bits, mais suporte a expressões regulares padrão ou suporte mais robusto para novos tipos de sistemas de arquivos.

Existem alguns casos em que novos recursos são adicionados aos idiomas existentes, mas em muitos casos essas mudanças significam simplificações das coisas que as pessoas já estavam fazendo da maneira mais difícil. (Consulte C ++ usando funções de alta ordem em vez de ponteiros e functores de função.)

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

No passado, havia palavras que não eram usadas com tanta frequência como são agora (ou usadas para um significado diferente).

por exemplo. nice: em inglês (muito antigo) tem um significado quase inverso ao que usamos hoje, especialmente quando usado para descrever o caráter de alguém.

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

outro novo desenvolvimento é o 'Text speak' do telefone móvel para idiomas escritos.

Pessoalmente, não vejo por que uma linguagem de programação não se desenvolverá de maneira semelhante, palavras e funções especificaram significados / ações, e é necessário mudar para incorporar novas idéias, novas metodologias.

Conheço pessoas que falam muitos idiomas diferentes e geralmente sugerem que depois do terceiro ou do quarto fica mais fácil aprender um novo.

Não sei se existem programadores que têm uma experiência semelhante, não ficaria surpreso se houvesse.

Eu sei que me sinto feliz programando em JAVA (tanto quanto me sinto feliz falando em inglês) Isso não significa que não posso me comunicar em 'inglês americano' ou 'inglês australiano', embora haja algumas 'dicas' a serem observadas . Assim como passar de Java para PHP e Perl, as construções são semelhantes, mas existem algumas dicas para me pegar e me fazer bater a cabeça contra a parede.

Isso é diferente de passar 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.

Enfim, essa é a minha opinião sobre isso.