Existe algum mecanismo para tornar a linguagem de programação mais estável (compatível) para alterações?

Há um grande número de linguagens de programação. Alguns deles crescem e se tornam muito populares. As pessoas usam esses idiomas mais e mais frequentemente. O fundador dessa linguagem (ou organização / comunidade fundadora) pode tentar implementar mudanças para melhorar a linguagem. Mas às vezes é difícil fazer algumas alterações devido à compatibilidade com versões anteriores e coisas tão feias já existem no idioma há anos e são usadas por muitos usuários.

Existem princípios ou etapas de arquitetura, durante a fase de design da linguagem, que podem ajudar a torná-la mais estável, para que os designers da linguagem não tenham tanto medo de quebrar a compatibilidade com versões anteriores?

A estabilidade da linguagem não é uma decisão técnica. É um contrato entre o autor do idioma e os usuários.

O autor anuncia uma determinada versão como mais ou menos estável. Quanto menos estável a linguagem, mais alterações o autor pode fazer. Cada usuário interessado no idioma pode decidir se deseja investir tempo para aprender novos recursos ou desenvolver aplicativos que podem ser quebrados pela atualização do próximo mês.

O uso de uma linguagem instável pode ser interessante porque você está interessado em um novo conceito ou deseja ajudar, enviando seus comentários. Se você é um negócio, pode preferir esperar que uma tecnologia seja mais estável antes de investir seu tempo nela. Você se importa mais com coisas como tempo de lançamento no mercado e experiência do usuário.

Portanto, este é um problema de comunicação e confiança. Veja o desenvolvimento da linguagem ferrugem. Eles são claros sobre o que estão mudando e o que estão mantendo. Quando eles querem adiar uma decisão sobre um determinado recurso, eles usam o que chamam de portão de recurso. Por outro lado, a equipe angular enfrentou muita raiva pelo anúncio 2.0, porque as mudanças foram maiores que o esperado.

Até o autor das bibliotecas precisa se comunicar sobre a estabilidade de suas APIs. Praticamente qualquer tecnologia usada por outras pessoas precisa encontrar um equilíbrio entre estabilidade e perfeição. Um fabricante de carros não pode mudar a posição dos pedais, e um designer de laptop não inventa um novo layout de teclado pelo mesmo motivo: você não está ajudando seus usuários se não puder tomar uma decisão sobre a maneira como eles usarão seu produto.

• Esteja ciente de que os idiomas mudam ao longo da vida, independentemente de quão bem eles possam ser projetados. Em vez de tentar enviar imediatamente a linguagem mais impressionante do mundo, primeiro tente ser útil e extensível. Uma linguagem medíocre que eu realmente posso usar vale mais do que qualquer linguagem de programação maravilhosa que só existe na teoria.

• Considere facilidades para tornar a sintaxe extensível, por exemplo, macros. As macros não são automaticamente boas e podem ser muito poderosas. Alguns idiomas têm uma sintaxe muito flexível desde o início, o que reduz a necessidade de macros. Alguns cenários a serem considerados:

  • Posso introduzir um novo operador, como |>sem sair do idioma? Posso escolher precedência e associatividade para este operador?
  • Quanta cerimônia eu tenho que passar para uma função embutida / lambda / encerramento?
  • Posso usar a sintaxe de idioma existente para implementar uma sintaxe de loop foreach? Por exemplo, Ruby e Scala podem fazer isso através de sua sintaxe de chamada de método flexível com lambdas.

• Considere as instalações para manter a semântica extensível. As necessidades comuns são:

  • Sobrecarga de operador, em que tipos definidos pelo usuário podem atribuir seu próprio significado aos operadores existentes. Isso torna uma linguagem muito mais agradável em aplicativos pesados ​​em matemática.
  • Sobrecarga literal. Posso fazer literais de string serem do meu próprio tipo de string? Posso fazer com que todos os literais numéricos no escopo atual sejam bignums?
  • Protocolos meta-objetos. Se o idioma não tiver características, posso implementá-las dentro do sistema de objetos atual? Posso implementar uma ordem de resolução de método diferente? Posso trocar a maneira como os objetos são armazenados ou como os métodos são despachados?
• Faça testes de regressão. Muitos testes. Não apenas escrito pelos designers da linguagem, mas também pelos usuários. Quando a adição de um recurso quebra esses testes, avalie cuidadosamente os benefícios desse recurso em relação ao benefício da compatibilidade com versões anteriores.
• Versão do seu idioma. Não apenas na sua documentação, mas também no próprio código-fonte. Depois de fazer isso, a única parte do seu idioma que não pode ser alterada é a sintaxe pragma desta versão. Exemplos: a raquete permite especificar um dialeto. O Perl permite use v5.20, o que habilita todos os recursos incompatíveis com versões anteriores do Perl v5.20. Você também pode carregar recursos únicos como explicitamente use feature 'state'. Similar: Python'sfrom __future__ import division .
• Considere projetar seu idioma de maneira a resultar em poucas palavras reservadas. Só porque classintroduz uma classe não implica que eu não seria capaz de ter uma variável local chamada class. Na prática, isso resulta em palavras-chave que introduzem declarações de variáveis ​​ou métodos, contrariando a tradição do tipo C de usar nomes de tipos para introduzir declarações. Outra alternativa é usar sigils para você $variables, como em Perl e PHP.

Partes desta resposta são influenciadas pelo discurso de Guy Steele “Growing a Language” (1998) ( pdf ) ( youtube ).

Eu acho que um passo muito importante é promover um gerenciador de pacotes que também possa gerenciar a versão do próprio idioma.

Por exemplo, eu uso o SBT para Scala ou Leiningen para Clojure. Ambos me permitem declarar qual versão do idioma eu quero usar, por projeto . Portanto, é muito fácil iniciar projetos ecológicos na versão mais recente do idioma, enquanto atualiza os projetos existentes em um ritmo mais confortável, se é que alguma vez.

Obviamente, dependendo do idioma, isso ainda pode deixar você com a necessidade de esperar que as bibliotecas relevantes sejam portadas para a versão que você precisa (isso acontece, por exemplo, no Scala), mas facilita as coisas.