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

46

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?


fonte
2
Muitos compiladores podem ser chamados com comutadores que imporão padrões mais antigos (por exemplo, --std=xcomutador do GCC ); portanto, não é como se a criação de novos padrões resultasse em ferramentas que desestabilizassem códigos antigos.
Blrfl
2
Como você define "um novo idioma baseado no antigo"? Eu diria que o Fortran 90 é uma "nova linguagem" baseada no antigo F77. Mudou completamente a maneira como você programa - fonte fixa versus livre, memória dinâmica versus estática, etc. Você também pode argumentar que o Fortran 2003 é uma "nova linguagem" baseada no F90 - adicionou programação orientada a objetos, mantendo a compatibilidade com o F90. Parece que a relação entre C ++ e C.
tpg2114
1
Penso que esta questão é muito importante e não entendo por que alguns querem encerrá-la. É um fenômeno muito interessante que provavelmente tem alguma explicação. Alguns (20?) Anos atrás, eu estava lendo sobre novos recursos do Fortran e me perguntei: se os programadores do Fortran precisam desses recursos, por que eles simplesmente não mudam para C? Recentemente, tive uma consideração semelhante em relação ao C ++: se os desenvolvedores do C ++ querem usar lambdas, por que não mudar para, digamos, OCaml ( linux-nantes.org/~fmonnier/ocaml/ocaml-wrapping-c.php )? Por que eles preferem criar um novo idioma e ainda o chamam de C ++?
Giorgio1
3
@ tpg2114 A diferença entre (FORTRAN 77: Fortran 90) e (C: C ++) é que se considera que o Fortran 90 substituiu o FORTRAN 77, a ponto de dizer às pessoas: "Se você deseja aprender o Fortran, aprenda o Fortran 2003 ou pelo menos 90, porque esse é o padrão agora. " Ninguém diria algo como "Se você quer aprender C, aprenda C ++ porque esse é o novo padrão", porque eles são apresentados em duas linguagens diferentes. Como eu disse, conotações têm consequências.
6
PORQUE C NUNCA MORRE
Adel

Respostas:

13

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

Giorgio
fonte
Essa resposta faz mais sentido para mim do que eu já vi aqui: atualizar um idioma permite herdar (pelo menos parte) da comunidade, bibliotecas, etc. Lembro-me de ler que o maior problema do Lisp é o grande número de dialetos incompatíveis que dificultam a manutenção de uma comunidade; atualizar um idioma existente pode ser uma maneira de evitar fragmentar outras comunidades da mesma maneira.
@ SunAvatar: Até onde eu sei, o Lisp tem vários dialetos, mas alguns são mais bem-sucedidos do que outros (Common Lisp, Scheme, Racket, Clojure). Sempre que você inicia um novo idioma, corre o risco de que apenas uma comunidade muito pequena se reúna em torno dele. Na comunidade Lisp, isso parece uma prática comum: se alguém tem uma nova idéia, ele se ramifica e vê o que acontece. Para os criadores de outros idiomas, perder a comunidade não é uma opção.
Giorgio
@ SunAvatar: Não vejo a herança de bibliotecas existentes como um argumento forte. Você não precisa de compatibilidade com o código-fonte para isso. Veja, por exemplo, como Clojure e Scala podem usar código Java.
Giorgio
1
Os idiomas não morrem, apenas os programadores que os utilizam.
Evan Solha
@SunAvatar: Também existem comunidades que tentam seguir uma política diferente: um nome identifica um idioma e, se uma parte da comunidade cria um dialeto que diverge demais, eles usam um novo nome para evitar confusão. Veja, por exemplo, racket-lang.org/new-name.html
Giorgio
21

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.

Engenheiro Mundial
fonte
14
O domínio do problema Tex = formatar texto de artigo científico não mudou muito. O domínio das linguagens de programação = encontrar novos usos para novos computadores é bastante mais abrangente. É pela mesma razão que o latim não adiciona tão muitas palavras novas como Inglês
Martin Beckett
Não acho que a compatibilidade com versões anteriores seja uma razão válida: o Scala pode ser facilmente integrado ao código Java existente, mas não é um superconjunto de Java. Então, em geral, não é necessário que um novo idioma seja compatível com um antigo no nível do código-fonte. É suficiente ter um mecanismo bem definido para chamar o código herdado do novo código.
Giorgio1
@ Martin Beckett: "O domínio do problema de Tex = formato de texto de artigo científico, não mudou muito.": Acho que você está perdendo o objetivo da pergunta. O OP não está perguntando se deve haver inovação em linguagens de programação (ninguém pode negar que a inovação é necessária), mas por que as linguagens antigas são revisadas em vez de criar novas.
Giorgio
Os sistemas são construídos com base em investimentos de tempo, dinheiro e conhecimento (experiência adquirida em um idioma específico). Novos esforços custam significativamente mais do que os esforços de manutenção (nas três categorias). Sem aprimoramentos no idioma e na plataforma em geral, o custo da manutenção aumenta e, em seguida, o custo de um novo sistema é mais atraente, e a genuína re-hospedagem que o COBOL aplica em uma plataforma totalmente diferente pela oitava vez na vida pode não parecer como muito mais.
236 JustinCelebr1
Se não fosse pelos padrões atualizados da linguagem COBOL e dos implementadores de ferramentas COBOL, adicionando recursos próprios ao longo do caminho, isso melhorou a linguagem e melhorou a capacidade de operar em plataformas mais amplas, tradicionais e modernas; o aplicativo não teria sobrevivido a 60 anos. Embora os custos relativos certamente tenham aumentado mais tarde em sua vida, devido a uma escassez cada vez maior de experiência, o esforço geral foi de um centavo por dólar, comparado a uma reescrita regular quando a linguagem do momento surgiu.
perfil completo de JustinC
5

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).

TMN
fonte
Portanto, se "um número suficiente de pessoas se preocupa com os idiomas mais antigos" é o motivo, você diria que sua resposta pode ser reformulada como "apego sentimental aos idiomas existentes"? Não estou dizendo isso pejorativamente, apenas tentando entender sua resposta.
Avner Shahar-Kashtan
Não, eu quis dizer que os idiomas ainda estão em uso ativo e são usados ​​por pessoas que desejam aproveitar as técnicas mais recentes. Acho que ninguém adicionará suporte a multithreading ao ALGOL porque (AFAIK) não está sendo usado ativamente. FORTRAN e COBOL, no entanto, ainda são usados ​​para desenvolver novos sistemas, portanto suas especificações de idioma são atualizadas periodicamente para incorporar novas técnicas e tecnologias.
TMN
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 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.)

Ben
fonte
1
As mudanças que você descreve no segundo parágrafo são bastante inquestionáveis ​​(pelo que quero dizer não apenas que não faço objeções, mas que ninguém pode objetar seriamente). Quanto aos lambdas, não posso comentar sobre a utilidade deles em C ++, mas por que se preocupar em adicioná-los para não alterar a maneira como os algoritmos são expressos?
Oh, eles são incrivelmente úteis. Não me interpretem mal. Eles são a adição mais importante em C ++ (IMO). Eu acho que não estava claro sobre o que eu quis dizer lá. Geralmente, escolhe-se C ++ para ter acesso direto à memória, desempenho determinístico e alto potencial de otimização. Isso não muda com as adições recentes. Simplificamos muitas das outras tarefas de programação sobre o motivo de você escolher o C ++, mas o C ++ ainda é válido e útil pelos mesmos motivos. O esquema é atualizado com regularidade, mas o código como dados e lispy-ness não mudam, portanto, você escolhe o esquema pelos mesmos motivos hoje, há 20 anos.
Ben
"Quanto aos lambdas, não posso comentar sobre a utilidade deles em C ++, mas por que me dar ao trabalho de adicioná-los para não alterar a maneira como os algoritmos são expressos?": Eu vou ainda mais longe: por que adicioná-los ao C ++ em vez de mudar para uma linguagem que teve-os desde o começo?
Giorgio
2
@Giorgio Ter controle dos recursos de cache e abstração no idioma. Se nenhum idioma existente fornecer os dois, você não poderá mudar de idioma sem sacrificar um. Você precisa modificar um idioma ou criar um novo.
precisa saber é o seguinte
@ Mike: O que você quer dizer com "recursos de cache"?
Giorgio
-2

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.

DaveM
fonte
Eu acho que você está pensando em "facetious".
uliwitness