Por que a verbosidade é ruim para uma linguagem de programação? [fechadas]

Eu tenho visto muitas pessoas reclamando sobre verbosidade nas linguagens de programação. Acho que, dentro de alguns limites, quanto mais detalhada for uma linguagem de programação, melhor ela será entender. Penso que a verbosidade também reforça a escrita mais clara APIpara esse idioma específico.

A única desvantagem em que consigo pensar é que isso faz você digitar mais, mas quero dizer, a maioria das pessoas usa IDEs que fazem todo o trabalho para você.

Então, quais são as possíveis desvantagens de uma linguagem de programação detalhada?

O objetivo é compreensão rápida

"Detalhado" significa "usa muitas palavras". A questão é o que é "demais".

Um bom código deve ser fácil de entender rapidamente. Isso é mais fácil se a maioria dos caracteres atender diretamente ao objetivo do código .

Signal vs Noise

Se um idioma é detalhado, mais do seu código é ruído. Compare o "Hello World" de Java :

class HelloWorldApp {
    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}

... com Ruby:

print "Hello World!"

O barulho desperdiça energia mental.

Cryptic vs Clear

Por outro lado, a excessiva discrepância em uma língua também custa energia mental. Compare estes dois exemplos do Common Lisp :

(car '(1 2 3))   # 3 characters whose meaning must be memorized
# vs
(first '(1 2 3)) # 5 characters whose meaning is obvious

Afeta a quantidade de código que você pode ver e analisar de uma só vez

x++ ao invés de set(x,Integeradd(get(x),1))

ps. Não é apenas uma questão de ler código. Nos dias de telas de 40x25, os idiomas do tipo APL, ou Perl, eram úteis em Cobol ou Fortran para a quantidade de código que você poderia ler / página. Mas agora é mais sobre o seu próprio cache interno - se uma instrução tiver um único operador, é mais fácil para o meu cérebro envelhecido analisar do que um com 3 símbolos e 4 chamadas de função.

Se a verbosidade do idioma prejudica a legibilidade do código, isso é ruim.

Algumas linguagens têm uma sintaxe tão detalhada que a compreensão do significado do código leva mais tempo (estou pensando em VB.NET versus C #):

If something Then
End If

if(something)
{}

Realmente se resume ao que um codificador está familiarizado e confortável.

Vá ao AppleScript , uma das linguagens mais detalhadas que eu posso pensar que poderia ser considerada atual , tente escrever algo trival e volte e tente argumentar que a verbosidade é uma boa característica em uma linguagem.

Tentar lembrar toda a semântica de onde as palavras-chave vão e o que elas são não é trivial se você não fizer isso todos os dias.

Basta olhar para todo o ruído da palavra - chave neste exemplo trivial:

tell application "Finder"
    if folder "Applications" of startup disk exists then
        return count files in folder "Applications" of startup disk
    else
        return 0
    end if
end tell

se a mesma coisa bashcom as ferramentas tradicionais do Unix fosse concisa, mas enigmática para a maioria dos usuários do OSX, existe um equilíbrio que deve ser alcançado.

Acho que você precisa virar a questão e perguntar: Por que algumas pessoas pensam que o código conciso é bom?

Minha resposta seria que existem duas razões básicas:

Razões pelas quais o Terse pode ser melhor

Isso inclui ser mais legível, da mesma maneira que uma sentença curta pode ser mais compreensível do que uma sentença florida e detalhada. Muitas vezes, as linguagens de programação que tentam emular a gramática do idioma inglês acabam sendo terrivelmente longas, exigindo grandes extensões de código para executar as ações mais simples. Frequentemente, você descobrirá que quanto mais um idioma emula um idioma escrito, mais difícil é convencê-lo a executar operações logicamente complexas.

Razões pelas quais o Terse pode ser pior

Algumas línguas (e estou pensando em Perl) usam uma matriz de símbolos estranhos, que parecem ter sido quase arbitrariamente selecionados, como parte de sua sintaxe. Para quem não conhece esses hieróglifos, o idioma se torna impenetrável. Também fica fácil cometer erros de digitação que não são vistos com facilidade. Expressões regulares talvez sintetizem esse tipo de concisão.

Além disso, algumas pessoas gostam de se exibir escrevendo código conciso porque, francamente, acham que isso as faz parecer inteligentes. Você vê isso algumas vezes no StackOverflow, onde as pessoas geralmente enviam respostas extremamente compactas à custa da legibilidade. Esse é um tipo de "impressionar seus colegas" com o quanto você conhece a filosofia, mas bons programadores percebem que o " código de golfe " não é o caminho para criar software sustentável.

@ frowing, eu sugeriria que uma maneira de analisar a questão da verbosidade é perceber que a programação é sempre uma mistura de dois estilos bastante diferentes de encontrar e expressar uma solução.

O primeiro e mais detalhado estilo é a programação orientada à linguagem (linguística). Esse estilo combina palavras semelhantes a substantivos e palavras verbais em estruturas semelhantes a sentenças e destina-se a ser lido e compreendido da mesma maneira que um parágrafo bem escrito. A programação linguística é o estilo mais universal de programação, pois a própria linguagem é universal. Pelo mesmo motivo, o suporte a longo prazo do programa sempre precisa de um componente linguístico poderoso, pois a primeira coisa que um novo programador procurará é o entendimento conceitual do que está sendo feito. Como regra geral, quanto mais você se afasta do contexto em que criou um programa, mais importante será o estilo linguístico de programação para garantir que suas suposições e conceitos não sejam mal compreendidos pela próxima pessoa que tentar entender seu código. .

O segundo e mais conciso estilo é a programação orientada a matemática (matemática). Esse estilo de raciocínio também se baseia na linguagem, pois, por exemplo, variáveis ​​são análogas a substantivos e operadores a verbos. No entanto, o raciocínio matemático aproveita a incrível e altamente paralela capacidade de nossos cérebros de realizar transformações espaciais complexas em objetos que estão dentro de nossa linha de visão. Ao representar substantivos e verbos como símbolos compactos e distintos que podem ser organizados em objetos imaginários bem estruturados - equações -, podemos usar nossas capacidades visuais altamente paralelas para realizar rotações, substituições, movimentos, inversões e outras transformações nesses imaginários. objetos. O resultado é uma enorme amplificação do número de casos com os quais podemos lidar ao mesmo tempo, pois cada símbolo pode representar classes inteiras de objetos intimamente relacionados.

Observe que, para aplicar o processamento visual de maneira eficaz, você precisa manter seu objeto imaginário o mais semelhante possível em tamanho e recursos a um objeto real. Se o campo de visão necessário for muito amplo, ou os símbolos não puderem ser usados ​​como marcas móveis em um objeto, ou se você precisar "ler letras" e convertê-las em palavras, a capacidade de realizar transformações complexas com segurança cairá. rapidamente, mesmo para um matemático muito bom.

É por isso que as pessoas imersas profundamente no estilo matemático de programação podem ficar seriamente infelizes se uma equação for espalhada e expressa no que eles chamariam de estilo lingüístico "detalhado". Não é porque a equação tenha sido alterada significativamente, é porque espalhá-la dessa maneira pode tornar quase impossível aplicar um estilo visual de entendimento a ela. No entanto, ao mesmo tempo, um novo programador que não esteja familiarizado com os símbolos curtos provavelmente preferirá uma versão mais detalhada que forneça mais informações linguísticas para entender inicialmente o que o código faz.

Então, o que eu recomendaria?

Use os dois estilos, mas preste muita atenção ao motivo de usar cada estilo.

Por exemplo, qualquer coisa que tenha a chance de interagir com o mundo externo deve ser intensamente detalhada em algum nível, mesmo que apenas na forma de comentários embutidos misturados ao código, e também inclua verificações automatizadas para o uso correto. As notações enigmáticas e especialmente incompletamente definidas não têm nada a ver com essas interfaces, uma vez que é quase garantido que elas serão mal compreendidas em algum momento. A perda de 1999 do Mars Climate Obiter devido a uma falha em reconhecer se as unidades de interface de software foram expressas em libras ou em Newtons é um exemplo particularmente apontado dos perigos de depender muito casualmente de números brutos nas interfaces de software ou hardware.

Por outro lado, qualquer forma de programação profundamente algorítmica e matemática é um bom candidato a uma programação sucinta que suporta o estilo matemático de raciocínio. Se alguém novo deve manter esse código, geralmente seria melhor aprender as notações matemáticas em vez de tentar transformar o código em formas mais detalhadas. É claro que sempre deve haver documentação facilmente disponível para explicar as partes matemáticas do código disponível para esses desenvolvedores, mas esse é um problema separado.

Entre esses extremos, existem muitos casos em que o programador tem considerável discrição. Eu sugeriria examinar como o código será mantido a longo prazo e tentar acomodar as necessidades das pessoas com maior probabilidade de manter o código a longo prazo.

Várias pessoas sugeriram algo que eu acho que provavelmente deveria ser declarado explicitamente.

A verbosidade tende a favorecer a compreensão no nível microscópico - geralmente leva a uma declaração individual ser fácil de ler e entender. A verbosidade também tende a reduzir o grau de familiaridade com o idioma necessário para entendê-lo (pelo menos em algum grau). As linguagens mais detalhadas (por exemplo, COBOL) podem ser pelo menos um pouco legíveis, mesmo por não programadores completos.

A concisão tende ao contrário: ajuda a entender no nível macroscópico, especialmente por programadores com a mais íntima familiaridade com esse idioma em particular. Ao mesmo tempo, a falta de familiaridade com essa linguagem específica pode impedir um entendimento ainda mais rudimentar, mesmo de programadores com alguma experiência.

Como tal, a legibilidade varia muito, dependendo do público-alvo. Por um lado, considere um projeto grande e complexo sendo escrito e mantido por pessoas que trabalham quase exclusivamente nesse projeto, a maioria das quais com formação e educação substanciais em programação (por exemplo, muitos PhDs). Isso tenderá a favorecer uma linguagem mais concisa.

No extremo oposto, considere um projeto consideravelmente mais simples (embora possivelmente ainda muito grande), mantido principalmente por pessoas realmente especializadas nos negócios associados ao software, e não no próprio software. Isso certamente favorecerá uma linguagem muito mais detalhada.

Em vez de ir a um livro técnico, volto aos Elementos do Estilo *, de Strunk e White. O conceito subjacente é "Seja preciso" e "Não diga mais do que o necessário". Tudo o resto é comentário.

Aplicado à programação, trata-se de ser muito preciso, mas não ter cotão desnecessário. O cotão extra pode ser sintaxe, mas também pode haver mais palavras do que o necessário para transmitir significado. (É claro que não são poucos os que permitem ambiguidade)

• Cito a versão original, pois é a mais concisa. :-)

No final do dia, qualquer coisa que seja 'diferente' fará com que as pessoas uivem. Eu me sinto à vontade com a sintaxe no estilo C e, portanto, aceito com outras linguagens que compartilham sintaxe semelhante (C ++, Java, C #). Então, eu tendem a favorecer esse estilo em particular.

Os idiomas tendem a encontrar um equilíbrio entre descritivo o suficiente e não detalhado.

Perl é um exemplo de onde você pode escrever um código muito conciso. Para os não iniciados, o código escrito por um ninja Perl é nada menos que mágica.

COBOL é um exemplo de muito detalhado.

Li em algum lugar uma vez que grande parte do debate detalhado vem de novos programadores versus velhos. A analogia usada foi que, quando aprendemos algo novo, contamos a nós mesmos uma "história" para superar isso (pense em quando você aprendeu álgebra no SH). À medida que adquirimos experiência, vamos além da necessidade de uma história explicando componentes individuais e compreendemos uma quantidade maior. Nosso código se torna mais denso e mais conciso, com comentários explicando apenas os itens necessários, em vez de reiterar o que o código diz.

Eu descobri que isso é verdade entre mim e um colega de trabalho. Ela escreve código com muitos comentários explicando quais são as linhas de código e muito espaço em branco. Se estou lendo, acho que só consigo encaixar algumas linhas de código em uma tela por causa disso. Isso facilita muito a compreensão de cada linha individual, mas o grokking de toda a função se torna muito mais difícil.

Costumo escrever código sem o espaço em branco extra ou comentários. Isso torna a visualização do todo muito mais fácil, mas você precisa simplesmente "obter" o código individual "palavras". Se você tentasse ler essa resposta com cada palavra na sua própria linha, com muitos espaços em branco / comentários / verborragia extra, seria muito mais fácil entender cada palavra individualmente, mas muito mais difícil entender o todo.

Einstein acertou: "Torne as coisas o mais simples possível, mas não mais simples".

Isso se aplica ao código também. Se você pode simplificar o código removendo elementos repetitivos e desnecessariamente detalhados, isso é uma coisa boa.

Além disso, alguns estudos de caso sugerem que a produtividade do programador medida em linhas de código é mais ou menos constante. Assim é o número de bugs por LOC. Portanto, mudar para um idioma que permita fazer mais por linha de código pode ser considerado uma melhoria de produtividade, se todas as outras coisas permanecerem iguais.

Dito isto, há uma tendência nesse setor de projetar demais e complicar o que deveria ser coisas simples. Coisas simples, como preencher detalhes de contato em um banco de dados relacional. Eu já vi algumas soluções ridiculamente complicadas e equivocadas ( tosse MDA) para esse problema em particular. Idiomas como Scala e Ruby são bons exemplos de ferramentas poderosas que, nas mãos de certas pessoas, resultam em código ininteligível, excessivamente complicado e com pouca manutenção. Só porque você pode usar vários níveis de indireção com apenas alguns toques de tecla não significa que você precisa acertar todos os pregos à vista com esse martelo em particular.

Quando usado corretamente, você obtém um bom código limpo, curto e fácil de entender. Quando mal utilizado, é melhor limitar o indivíduo em questão ao uso do visual basic ou de uma linguagem igualmente limitada para evitar mais danos.

A verdadeira habilidade reside em fazer coisas complexas de uma maneira simples, não em fazer coisas simples de uma maneira complicada.

Algo que ninguém mais atingiu é a quantidade de código que você pode ajustar em uma tela. Ajuda por vários motivos:

• Menos rolagem para frente e para trás quando você está trabalhando (ou lendo) várias funções em um arquivo.
• Rolagem menos horizontal (pare de ler, clique e arraste a barra de rolagem, pare de ler, clique e arraste a barra de rolagem ...).
• Verificação mais rápida, pois há menos sintaxe inútil no caminho para encontrar o que você deseja.

Porque mais código significa mais tempos de desenvolvimento e mais erros.

Se você escrever 100 linhas de códigos em vez de 300 linhas de códigos. Isso significa quase 1/3 dos tempos de desenvolvimento necessários e 1/3 dos possíveis erros que você poderá encontrar.

Na maioria das circunstâncias, é necessário equilibrar a eficiência e a concisão, pois escrever menos códigos significa que a máquina precisa fazer mais coisas e isso diminuirá a eficiência.

Normalmente, as pessoas preferem linguagens legíveis / verbais em detrimento das criptas / concisas. No entanto, acho que a maioria das pessoas assimilou "verbosidade" com "desordem", que não são a mesma coisa.

Por exemplo: while(<>){print if($.==2 || $& && !$x++); $.=0 if (/^--+$/)}

é uma afirmação muito concisa. Ele contém tudo o que você deseja saber. No entanto, por causa de sua concisão, é difícil de entender. Por outro lado, uma versão um pouco mais detalhada do mesmo programa seria bastante simples de entender porque é mais legível. Obviamente, isso não é uma propriedade da linguagem em si, mas algumas linguagens tendem a ter mais verbosidade, enquanto outras tendem a ter mais concisão em sua maneira de programar.

Para o outro extremo da verbosidade, está http://en.wikipedia.org/wiki/Literate_programming , que considero um conceito bastante interessante.

Um outro aspecto é a "verbosidade indesejada", também chamada de "desordem". Itens que você deve adicionar por motivos técnicos, falta de açúcar sintático, APIs inchadas e assim por diante.

Eu acho que uma sintaxe clara e intuitiva é muito importante. Também deve ser detalhado o suficiente para facilitar uma leitura fácil. Declarações muito curtas e repletas de lógica muitas vezes podem levar a mais tempo para decifrar do que suas contrapartes um pouco mais longas. Por outro lado, códigos inchados e inúteis, cheios de linhas padronizadas para fazer algo absolutamente simples, é igualmente um incômodo.

A verbosidade é uma tendência ao uso de grandes quantidades de texto, e a dispersão o uso de muito pouco texto ...

A verbosidade é ruim porque:

1. introduz mais oportunidade para erro tipográfico
2. dificulta a leitura de código na tela ou no papel e / ou entra no cartão perfurado
   1. isso aumenta os tempos de depuração
   2. isso dificulta a compreensão do código para atualização / manutenção
   3. isso pode levar à duplicação de código não intencional
3. aumenta um pouco a probabilidade de erro de sintaxe
4. diminui a flexibilidade de codificação, pois a maioria das linguagens verbais é altamente estruturada e não possui várias maneiras de dizer a mesma coisa.
5. aumenta o tempo de codificação e compilação
6. pode levar mais espaço de armazenamento.

Um certo nível de verbosidade é essencial para a clareza, no entanto ...

um nível mínimo de verbosidade é bom porque:

1. é mais fácil para os humanos ler e anexar valor semântico ao código puramente simbólico
2. Na nomeação de variáveis ​​e funções, facilita a depuração, porta e manutenção do código
3. nas operações de idioma de nível básico e nas palavras-chave de idiomas complexos, isso leva a menos atribuições incorretas de operação / palavra-chave.

Alguns exemplos maravilhosos de comandos excessivamente concisos para muitas pessoas incluem as antigas esperanças BASIC de val(x$), str$(x)e chr$(x)... retornam um número de sua representação de string, retornam uma string para um número e retornam um único caractere com o valor ASCII x como uma string.

Ou o ponteiro C / C ++ e por operadores de referência &e *versus a byrefpalavra-chave BASIC . No C / C ++, posso ter uma variável X e passar um ponteiro para essa variável, mas preciso lembrar qual é o ponteiro e qual é o "use o ponteiro como a variável para a qual ele aponta"; no básico, simplesmente passo a referência com uma palavra-chave byref na chamada de função, que é mais clara, mas menos flexível:

def fn Foo(x byref as float) foo= (x += x+1)
...
Foo(x)

Nesse código, o conteúdo de x é modificado devido ao sinalizador byref. Alguns sabores permitem byref na chamada, outros na definição, alguns em qualquer um.

A verbosidade é importante para programadores casuais poderem usar o simbolismo mais facilmente; BASIC ou python são mais legíveis por humanos e mais detalhados que C / C ++ e, portanto, muito mais úteis para programadores casuais; a dispersão do C / C ++ torna muito melhor para programadores mais experientes, que precisam ver mais código e código mais complexo em uma tela, mas tiveram que aprender as várias convenções de estrutura simbólica. No outro extremo está o APL, que é quase completamente humano ilegível.

Uma questão intimamente relacionada é a clareza - o código conciso geralmente não é claro e o código excessivamente detalhado (como no AppleScript) pode ser igualmente obscuro. A familiaridade com uma determinada linguagem aumenta a clareza do código conciso dentro dessa linguagem - um iniciante bruto, enfrentando o código C ++, provavelmente será capaz de analisar apenas as fórmulas, e mesmo muito código BASIC ou Python funcional é muito conciso para a compreensão, mas o AppleScript pode ser confundido, geralmente, sem recorrer a dicionários de idiomas. O menos claro que encontrei sem ofuscação intencional é o Inform 7 ...

Nos velhos tempos

Outra consideração importante no passado, mas que não é mais tão importante para o codificador de hobby, é a operação e o espaço de armazenamento. (Ainda é vital para os avançados.) Tendo em mente que muitos idiomas foram interpretados, especialmente os sabores do BASIC, e muitos outros foram compilados em tempo de execução, o espaço do código era importante, especialmente quando os discos mantinham apenas 128KiB e os punchcards individuais, apenas 80B.

Existiam várias soluções - a tokenização era extremamente comum no BASIC; as palavras-chave do idioma individual foram reduzidas a uma palavra de 1 ou 2 bytes no espaço superior de 128 ou no caractere de controle. A tokenização também leva à compilação de bytecodes (como no Inform e na Z-Machine).

A compilação e a vinculação de vários arquivos de objetos também foram usadas para contornar as limitações de espaço. Uma seção de código Pascal de 100KiB pode ser compilada para apenas 5KiB; ao vincular vários arquivos compilados, era possível criar aplicativos massivos sem ter acesso a unidades de grande formato (lembrando que 10MiB eram surpreendentemente grandes e comprar um carro novo).

Linguagens mais concisas, no entanto, inseriram mais código em um determinado pedaço de disco e ram e, assim, compilaram pedaços maiores de cada vez. Lembre-se: os "minicomputadores" do início da década de 1970 podem ter apenas 64KiB de ram (o Honeywell 800 tinha uma instalação básica de 4 bancos cada um com 2048 palavras de 8B cada). O APL e linguagens simbólicas similares aproximaram-se de 1B por instrução mais seus operandos, em comparação com os muito maiores 3B-10B por instrução mais operandos. (Foi um pesadelo digitar em cartões perfurados, especialmente porque os símbolos eram essencialmente uma fonte na bola tipo, e muitos perfuradores de cartões não tinham os símbolos nas teclas ...)

Além disso, lembre-se de que os cartões não podem ser apagados ... e muitos programas foram inseridos nos cartões. Embora não seja caro individualmente, quanto mais compactado o código puder estar no cartão, menos você precisará e quanto maior o programa, ou menos caro. Isso é parte do motivo pelo qual o BASIC tem uma concatenação de várias instruções por linha na maioria dos sabores - foi introduzido para economizar em cartões perfurados. (É o que diz meu texto de programação do Vax Basic.) Embora eu não tenha programado para um leitor de cartão, já perfurei um cartão Honeywell 800 em FORTRAN, BASIC, APL e algumas outras linguagens altamente simbólicas.

Como muitas outras coisas, a resposta depende da definição concreta de "verbosidade". Se a definição é tal que a verbosidade implica redundância, eu diria que é sempre ruim. Observe que, com essa definição, o programa Java hello world frequentemente citado não se qualificaria como "detalhado", porque não há nada nele que seja redundante.

Os programadores tendem a gostar de linguagens com poder expressivo, pois permitem codificar as coisas simples, que geralmente precisam ser feitas com frequência, em pequenos pedaços de código. Linguagens verbais tendem a significar que muitas e muitas linhas de código precisam ser usadas para fazer a mesma coisa repetidamente. No entanto, pode haver um preço a ser pago com linguagens expressivas, pois elas podem não ser tão rápidas de executar quanto os idiomas de alto nível mais simples. Se eu posso dar um exemplo no contraste entre C e C ++. O C ++ dá um poder mais expressivo aos escritores de código - eles podem encapsular a ideia de objetos do mundo real nas classes. Os programadores em C podem obter as mesmas coisas, mas eles têm o poder expressivo da construção de classe para ajudá-los - com freqüência eles precisam escrever um código mais longo e mais complicado (para entender). Mas esse código pode muito bem ser executado mais rapidamente (embora isso seja altamente dependente da qualidade do compilador e assim por diante) porque não usa a "ligação tardia" do C ++ (isto é, refatoração em tempo de execução) para executar o código. C apenas executa o código compilado e vinculado, o C ++ precisa tomar uma decisão (em determinadas circunstâncias) em tempo de execução sobre quais partes do código executar.

Acredito que exista uma resposta para a questão enraizada em uma questão mais fundamental e teórica do que a legibilidade, e essa resposta está relacionada à teoria da informação algorítmica fundada por Gregory Chaitin: http://en.wikipedia.org/wiki/Algorithmic_information_theory . Em poucas palavras, "o conteúdo da informação de uma string é equivalente ao comprimento da menor representação possível possível dessa string". Isso implica que o programa mais curto (ou seja, em termos de comprimento lexicográfico) resolva de perto um determinado problema corresponde à complexidade intrínseca do problema ao qual ele fornece uma solução e, portanto, depende mais da natureza do problema e menos da representação do problema.