📸 🤹🏿 🐰 Paul Graham: Brevidade = Força 👨🏿 🧑🏿‍🤝‍🧑🏾 🚄

Hoje, no HackerNews, levantamos uma discussão sobre o artigo de 2002 de Paul Graham e decidimos ressuscitar sua tradução da inexistência.

"A quantidade de significado compactada em um espaço pequeno
por sinais algébricos é outra circunstância que facilita
os raciocínios que estamos acostumados a seguir com a ajuda deles".
- Charles Babbage (1791-1871)

Na discussão em torno do artigo LL1 Revenge na lista de discussão LL1, Paul Prescod fez uma observação que não estava fora de minha cabeça.

O objetivo do Python é regularidade e legibilidade, mas não brevidade.

À primeira vista, uma linguagem de programação provavelmente não deveria ser. Pelo que entendi, concisão (concisão, concisão, compacidade) = força. E se sim, então, fazendo uma substituição, obtemos:

O objetivo do Python é regularidade e legibilidade, mas não poder.

que, por sua vez, não é um compromisso muito bom (se é realmente um compromisso), que vale a pena fazer. Parece que se você disser: o objetivo da linguagem Python não é ser uma linguagem de programação eficaz.

Brevidade = força? Essa parece ser uma pergunta importante, talvez a pergunta mais importante para os envolvidos no desenvolvimento de idiomas. Ainda não tenho certeza de que a resposta seja apenas "sim", mas, para começar, essa é uma boa hipótese.

Hipótese

Minha hipótese é que brevidade é poder, ou eles são tão próximos que, com exceção de casos patológicos, você pode aceitá-los por algo idêntico.

Parece-me que a brevidade é para que as linguagens de programação são criadas. Os computadores ficariam igualmente felizes se recebessem instruções diretamente em linguagem de máquina. Eu acho que a principal razão pela qual vamos desenvolver linguagens de alto nível é obter a vantagem de expressar (e mais importante, pensar) dez linhas em uma linguagem de alto nível, o que exigiria 1000 linhas de código de máquina. Em outras palavras, o principal objetivo das linguagens de alto nível é reduzir o código-fonte.

Se o código-fonte mais curto é o objetivo das linguagens de alto nível, e a força de alguma coisa é uma medida de quão bem o objetivo é alcançado, a força da linguagem de programação é o quanto isso reduz seus programas.

Por outro lado, uma linguagem que não reduz seus programas faz um trabalho ruim de uma linguagem de programação, assim como uma faca que corta mal ou impressão ilegível.

Métricas

E em que sentido é menor? A medida mais comum do tamanho do código-fonte é o número de linhas. Mas essa medida é comum apenas devido à simplicidade da medição, e não acho que alguém acredite que seja um bom teste do tamanho do programa. Os idiomas têm convenções diferentes sobre o que pode ser colocado em uma linha; algumas linhas em C podem ter apenas um ou dois separadores.

Outro teste simples é o número de caracteres no programa, mas este não é muito bom; alguns idiomas (como Perl) têm identificadores mais curtos que outros.

Eu acho que a melhor medida do tamanho de um programa pode ser o número de elementos, onde o elemento é algo que pode se tornar um vértice separado na árvore de origem. O nome de uma variável ou função é um elemento; um número inteiro ou um número real é um elemento; um segmento literal de texto é um elemento; um elemento de uma diretiva de padrão ou formato é um elemento. Existem casos de fronteira ("-5" é um elemento ou dois?), Mas acho que a maioria deles é a mesma em todos os idiomas, portanto eles não afetarão muito a comparação.

Essa medida deve ser concretizada e pode exigir interpretação adicional no caso de algumas linguagens específicas, mas parece-me que ela está tentando medir a coisa certa: o número de partes do programa. A árvore de origem é o que você desenha em sua mente para representar o programa e, portanto, o tamanho dessa árvore é proporcional à quantidade de trabalho necessário para escrevê-lo ou lê-lo.

Projeto

Essa medida nos permitiria comparar diferentes idiomas, mas esse não é, pelo menos para mim, seu valor básico. E o valor do teste de brevidade é um guia para o design de idiomas. A comparação de idioma mais útil é comparar duas variações possíveis do mesmo idioma. O que posso fazer no idioma para tornar os programas mais curtos?

Se a carga conceitual de um programa é proporcional à sua complexidade, e um determinado programador pode suportar uma certa carga conceitual, é o mesmo que perguntar: como ajudar os programadores a fazer mais? E isso, parece-me, é o mesmo que perguntar: como criar uma boa linguagem?

(A propósito, a falsidade deste já barbudo ditado "todas as línguas são equivalentes" é mais claramente vista ao projetar línguas. Quando você cria uma nova linguagem, você constantemente compara duas línguas - uma na qual eu faria X e a outra na qual não faria - para que decida o que é melhor. Se fosse uma pergunta sem sentido, você também poderia jogar uma moeda.)

Ter uma meta de brevidade parece uma boa maneira de encontrar novas idéias. Se você encontrar uma maneira de tornar os programas mais curtos, isso não é coincidência: você provavelmente encontrou uma nova abstração útil. Você pode até escrever um programa que buscaria pedaços repetidos no código-fonte. Novas idéias podem ser encontradas entre os idiomas que têm reputação de serem concisos: adiante, alegria, ícone.

Comparação

O primeiro a escrever sobre essas coisas foi, até onde eu sei, Fred Brooks com seu livro Mythical Man-Month. Ele escreveu que os programadores geram a mesma quantidade de código, independentemente da linguagem. Quando li pela primeira vez aos 20 anos, foi uma grande surpresa e pareceu-me que isso tinha enormes consequências. Isso significava que (a) a única maneira de escrever programas mais rapidamente é usar uma linguagem mais curta e (b) quem se deu ao trabalho de fazer isso perguntaria aos concorrentes que não o fizeram.

A conjectura de Brooks, se verdadeira, pode ser a própria essência do hacking. Desde então, ao longo dos anos, prestei atenção a tudo o que seria relevante para a questão: de estudos teóricos a histórias sobre projetos individuais. Não vi nada que contradisse essa hipótese.

Mas não vi nenhuma evidência clara e não espero vê-las. Estudos como a comparação das linguagens de programação Lutz Prekelt, embora produzam os resultados esperados, tendem a usar tarefas muito pequenas para um teste significativo. O melhor teste para um idioma é o que acontece em programas escritos em um mês. E se você está convencido, como eu, de que o principal objetivo dos idiomas é ser um bom idioma em que eles pensam (em vez de um idioma em que eles dão instruções ao computador depois que você pensa sobre isso), o teste real para o idioma é Que novidade você pode escrever sobre isso. Portanto, comparar idiomas com base em uma especificação predefinida está um pouco errado.

O verdadeiro teste para o idioma é como você pode encontrar e resolver novos problemas, mas não as tarefas formuladas por outra pessoa. Estes são critérios diferentes. Na arte, ferramentas como bordado e mosaico funcionam bem se você sabe com antecedência o que deseja obter, mas absolutamente indecente se não sabe. Se você quiser revelar uma imagem no processo de escrever uma imagem (o que você deve fazer ao revelar coisas complexas, como, por exemplo, a imagem de uma pessoa), use uma ferramenta mais flexível, como lápis, tinta ou óleo. Obviamente, tapeçarias e mosaicos são feitos assim: primeiro uma imagem é criada e, em seguida, apenas é copiada.

Isso significa que é improvável que tenhamos uma comparação adequada da força relativa das linguagens de programação. Teremos comparações exatas, mas não corretas. Em particular, estudos voltados explicitamente para comparações de idiomas provavelmente usarão pequenas tarefas e necessariamente usarão um conjunto predefinido de tarefas e, portanto, tenderão a subestimar as linguagens mais poderosas.

Os relatórios nessa área, embora sejam menos precisos que os estudos "científicos", provavelmente serão mais significativos. Por exemplo, Ulf Viger, da Ericsson, conduziu um estudo e chegou à conclusão de que Erlang é 4-10 vezes menor que o C ++, e a velocidade de desenvolvimento de software é proporcionalmente maior:

A comparação de projetos internos na Ericsson revela produtividade semelhante em linhas de código por hora, incluindo todas as fases do desenvolvimento, independentemente da linguagem usada (Erlang, PLEX, C, C ++ ou Java). Diferenças nos idiomas - apenas na quantidade total de código fonte.

Este estudo também indica claramente que não aparece no livro de Brooks (uma vez que media apenas linhas de código depurado): programas escritos em linguagens mais poderosas tendem a conter menos erros. Isso já é suficiente e, provavelmente, em tarefas como comutadores de rede, isso é mais importante que o desempenho do programador.

Gostos

No final, você pode confiar em seu instinto. O que é programação nesta linguagem? Penso que, para criar uma linguagem melhor, você deve se tornar hipersensível ao quão bem a linguagem permite que você pense nela, e depois escolher ou desenvolver uma linguagem que lhe pareça mais adequada. Se alguma propriedade do idioma for inconveniente ou restritiva - não se preocupe, você saberá sobre isso.

Mas essa hipersensibilidade resultará em idiomas desajeitados tornando-se insuportáveis para você. Acho a programação em linguagens que não possuem macros insuportavelmente restritivas, como se alguém acostumado à digitação dinâmica considerasse insuportavelmente restritivo o retorno às linguagens, onde os tipos devem ser descritos para cada variável declarada e é impossível declarar uma lista composta por elementos tipos diferentes.

E eu não estou sozinho. Conheço muitos hackers Lisp com quem algo semelhante aconteceu. De fato, a medida mais precisa da força relativa de uma linguagem de programação pode ser a proporção de programadores que conhecem uma determinada linguagem que realizarão qualquer trabalho em que essa linguagem deva ser usada, independentemente da área de assunto.

Limitações

Provavelmente, muitos hackers sabem como é quando o idioma parece restritivo. Essa é provavelmente a mesma sensação de quando você fica preso em um engarrafamento na rua que deseja dirigir e precisa fazer um longo desvio. Você quer dizer algo e o idioma não permite que você faça isso.

De fato, uma linguagem limitadora não é uma linguagem sucinta. O problema não é que você não possa expressar algo, mas que o desvio que essa linguagem o força a fazer é muito longo. Faça esse experimento: você deseja escrever algum tipo de programa, e a linguagem não permite que você faça como planejado, mas, ao contrário, diminui a duração. Pelo menos para mim isso não seria muito restritivo. Como se um policial o direcionasse de um engarrafamento para uma estrada mais curta, em vez de um longo desvio. Uau!

Parece-me que o sentimento de limitação basicamente (em 90%?) Decorre do fato de você ser forçado a prolongar o programa no idioma em que está escrevendo, comparado com o idioma em que pensa. A limitação é basicamente concisão insuficiente; portanto, quando um idioma parece ser limitador, significa que não é curto o suficiente.

Legibilidade

A citação com a qual comecei também menciona duas outras qualidades: regularidade e legibilidade. Eu realmente não entendo o que é regularidade e quais são os benefícios do código regular e legível em comparação com o código legível. Mas acho que sei o que se entende por legibilidade, e também me parece que isso tem a ver com brevidade.

Aqui, devemos ter cuidado com os conceitos de legibilidade de uma única linha de código e a legibilidade do programa como um todo. Somente o último é importante. Concordo que uma linha no BASIC provavelmente é mais legível do que uma linha no Lisp, mas um programa escrito no BASIC terá mais linhas do que o mesmo programa escrito no Lisp. Ler o programa BASIC exigirá mais esforço.

esforço total = esforço para ler uma linha * número de linhas

Não tenho tanta certeza de que a legibilidade seja proporcional à brevidade, mas definitivamente a brevidade é um fator de legibilidade (veja a fórmula acima). Portanto, não faz sentido dizer que o objetivo da linguagem é a legibilidade, mas não a brevidade.

Para um usuário que vê um determinado idioma pela primeira vez, a legibilidade linha por linha significa que esse idioma parecerá inofensivo para ele. Portanto, a legibilidade linha a linha pode ser uma boa decisão de marketing, embora seja uma má decisão de design. É isomórfico no que diz respeito ao método de pagamento parcelado: em vez de ser intimidado por um grande depósito, você oferece ao comprador um pequeno pagamento mensal. O pagamento em partes é, em última análise, inútil para ele, assim como a legibilidade linha por linha - para o programador. O comprador deve fazer muitos pagamentos pequenos, assim como o programador deve ler muitas linhas legíveis separadamente.

Essa proporção existia mesmo antes do advento das linguagens de programação. Se você lê romances e artigos de jornal, sua primeira experiência lendo um artigo em matemática pode ser assustadora: ler uma página leva meia hora. No entanto, tenho certeza de que o problema não está na notação, como pode parecer à primeira vista. Um artigo em matemática é difícil de ler porque as idéias são complexas. Se você expressar as mesmas idéias em prosa (como os matemáticos fizeram antes de pensar em uma breve notação), não seria mais fácil lê-las, porque essa página única se tornaria um livro inteiro.

Em que grau?

Alguns discordaram da ideia de brevidade = força. Penso que, em vez de discutir se é assim, seria mais útil perguntar até que ponto brevidade é poder? Porque é claro que a brevidade é um dos principais objetivos das linguagens de programação. E se não, qual é o seu propósito e qual a importância dessas outras funções?

Proponho isso para não tornar a discussão mais civilizada. Eu realmente quero saber a resposta. Quando, se isso acontecer, o idioma se tornará conciso o suficiente?

A hipótese com a qual comecei foi a de que, exceto em alguns casos patológicos, a brevidade é idêntica à força. Eu quis dizer que eles serão idênticos em qualquer idioma desenvolvido por alguém, mas se alguém quiser criar um idioma especificamente para refutar essa hipótese, provavelmente isso funcionará. Mas também não tenho muita certeza disso.

Programas, mas não programas

Deve ficar claro que estamos falando sobre a brevidade das linguagens, não sobre programas individuais. Obviamente, alguns programas podem ser escritos com muita força.

Eu escrevi sobre isso no livro “About Lisp”. Para que a macro se justifique, ela deve economizar muitas vezes mais espaço em relação ao seu próprio comprimento. Se alguma macro volumosa salva dez linhas de código toda vez que você a usa, e a própria macro consiste em dez linhas, você obterá economia de linhas se usá-lo mais de duas vezes. Mas essa ainda é uma péssima jogada, pois as definições de macro são mais difíceis de ler do que o código comum. Pode ser necessário usar a macro 10 ou 20 vezes antes que a legibilidade melhore.

Estou certo de que, em qualquer idioma, esses compromissos são possíveis (embora eu suspeite que os riscos aumentem em idiomas fortes). Todo programador já viu um código extremamente reduzido devido a técnicas de programação duvidosas.

Portanto, é indiscutível - pelo menos para mim - que os programas podem ser concisos o suficiente. A questão é: os próprios idiomas podem ser curtos? As linguagens podem forçar os programadores a escrever brevemente (em elementos) ao custo da legibilidade?

Uma das razões pelas quais é difícil imaginar uma linguagem muito concisa é que, se houver uma maneira excessivamente compacta de expressar algo, provavelmente haverá uma maneira mais longa. Por exemplo, se lhe parecer que o uso de macros ou funções de alto nível no Lisp é muito denso, você pode escrever um código isomórfico no Pascal. Se você não deseja expressar o fatorial na linguagem do Arc como uma chamada para uma função de alto nível,

(rec zero 1 * 1-)

também pode escrever uma definição recursiva:

(rfn fact (x) (if (zero x) 1 (* x (fact (1- x)))))

Embora não possa dar exemplos tão imediatamente, estou interessado na pergunta: a linguagem pode ser muito curta? Existem idiomas que forçam você a escrever código ilegível? Se alguém tiver algum exemplo, eu ficaria feliz em vê-los.

(Lembre-se: estou interessado em programas que possuem alta densidade de acordo com a medida dos "elementos" descritos acima, mas não em programas curtos apenas porque podem ser omitidos com separadores e tudo tem nomes com um caractere.)

Foi publicado pela primeira vez aqui .

Aprenda os detalhes de como obter uma profissão procurada desde o início ou suba de nível em habilidades e salário fazendo cursos on-line SkillFactory:

Paul Graham: Brevidade = Força