A tragédia do Common Lisp: por que as línguas populares aumentam em complexidade

Adaptado da discussão em 2015 . Aqui, o Common Lisp é apenas um dos muitos bons exemplos.


O futuro do JavaScript?

Trabalho no JavaScript Standards Committee (TC39) desde 2007. Agradecemos a simplicidade do idioma, mas com o tempo perdemos a vigilância. A complexidade começou a crescer incontrolavelmente. Devemos descobrir por que isso acontece naturalmente, qual é o preço e o que fazer sobre isso. Este artigo é dirigido não apenas aos colegas do TC39, mas também a todos que desejam influenciar o caminho de desenvolvimento do JavaScript ou qualquer padrão que tenha enfrentado pressão semelhante. Aprenda com nossos erros!

Algol, Smalltalk, Pascal e Early Scheme eram amados como línguas pequenas e bonitas. C cedo e JavaScript foram justamente criticados por muito e raramente chamados de bonitos. Mas eles também eram pequenos e foi muito apreciado. Quando o idioma é pequeno, nossa avaliação geralmente é determinada pelo sentimento: “Eu posso aprender tudo e dominar” e depois: “Eu sei tudo. Gosto que não restem detalhes desconhecidos . Mas no caso de C e JavaScript, é improvável que alguém tenha um senso de domínio completo da linguagem, já que os detalhes eram realmente diabolicamente complexos. No entanto, o sentimento de uma "linguagem pequena" de várias maneiras determinou a satisfação do uso diário.

A estética do minimalismo JavaScript foi preservada no padrão EcmaScript-5. Participei ativamente do desenvolvimento do EcmaScript-5 e EcmaScript-2015 e, nos dois casos, tenho orgulho da minha contribuição. O EcmaScript-2015 cresceu significativamente em tamanho, mas trouxe melhorias. Dado o local onde começamos, era impossível melhorar o JavaScript sem esse aumento de tamanho. Não me arrependo da maioria dos complementos que levaram ao aumento do EcmaScript-5 para o EcmaScript-2015. Se você voltar, provavelmente em muitos casos eu sugeriria adições semelhantes.

Cada uma das adições teve que superar uma barra muito alta. Psicologicamente, isso fazia sentido, porque analisamos o minimalismo do EcmaScript-5. Quando o idioma é pequeno, cada função adicional é intuitivamente sentida como um aumento percentual significativo no tamanho do idioma. Os benefícios específicos de um recurso são sempre visíveis para seus proponentes. Para um idioma pequeno, a contribuição do novo recurso para o aumento no total também é visível para todos.

Assim que uma linguagem ultrapassa uma certa complexidade - digamos, LaTeX, Common Lisp, C ++, PL / 1, Java moderno - a programação se torna mais como cortar um subconjunto de funções para uso pessoal de um mar infinito de funções, a maioria das quais nunca dominaremos e reconciliaremos com isso. Quando o idioma é percebido como "infinito", os benefícios específicos do novo recurso ainda são entendidos. Mas os custos gerais associados à complexidade adicional não são mais óbvios. Eles não são mais sentidos por aqueles que discutem um novo recurso.

$$ .

Mesmo $$ .

É a morte de mil cortes, o que faz com que esses monstros cresçam sem nenhuma restrição.

Portanto, peço a todos que influenciam o idioma que considerem uma barra mais alta ao considerar uma nova função do que "é bom ter essa oportunidade, não é?". Acredito que o EcmaScript-2015 esteja localizado no território da fronteira, onde o crescimento desenfreado ainda pode ser evitado, mas somente se começarmos a restringir-nos com altos padrões para qualquer novo recurso proposto. Como comunidade, precisamos de um senso mais geral de pânico sobre o tamanho que o EcmaScript 2015 já atingiu. Idealmente, com o crescimento da língua, quando o tamanho se aproxima do ponto sem retorno, o pânico deve aumentar, não diminuir.

Algumas diferenças

Mantenha pressão mínima desigual

A relevância do minimalismo diminui à medida que passamos de uma linguagem base para as bibliotecas. O idioma padrão como um todo pode ser representado como a seguinte estrutura:

• Sintaxe fundamental : formulários especiais que não podem ser expressos com precisão pela extensão local para outra sintaxe.
  
• Estado semântico : um estado que é manipulado pela computação.
  
• Componentes internos do kernel : parte da biblioteca interna que fornece funcionalidades que o código personalizado não pode fornecer por si só.
  
• Intrínsecas que não são do kernel: bibliotecas internas que podem ser implementadas em JavaScript, mas o estado ou módulos semânticos criados no kernel dependem deles. Por exemplo, através de um proxy, você pode implementar uma matriz no código do usuário. Mas outros módulos embutidos no kernel já dependem do Array, o que confere a esse array em particular uma posição privilegiada sobre qualquer substituição proposta.
  
• Açúcar sintático : sintaxe que pode ser expressa por extensão local à sintaxe fundamental.
  
• Bibliotecas globais por conveniência : podem ser implementadas com código de usuário sem privilégios, mas levando em consideração os caminhos de nomes globais padrão no espaço para nome global original.
  
• Módulos padrão por conveniência : módulos desenvolvidos pela comunidade aprovados como padrão.

Listei-os em ordem, de acordo com meu senso de aumentar os custos de crescimento e a necessidade urgente de minimalismo. Tudo isso requer disciplina. Somente no último ponto podemos permitir um crescimento ilimitado, mas é aconselhável que os candidatos sejam testados pela comunidade e aceitos primeiro de fato. Idealmente, o comitê do TC39 deixará de ser um gargalo, uma vez que os processos externos de fato e de direito poderão desenvolver de forma independente módulos padrão por conveniência.