Por que a programação alfabetizada não é mainstream? [fechadas]

A programação alfabetizada tem bons ideais. Por que você acha que isso não é popular? É porque não conseguiu entregar?

Eu o vi pela primeira vez em um livro dos escritos de Knuth e achei que parecia arrumado. Depois, tentei usar a tela de programação literária para compreender o que estava acontecendo no programa e achei mais difícil do que parecia. Pode ter sido que eu estava muito acostumado a passar por listagens de programas, mas parecia confuso.

Então eu olhei para o código fonte, e isso me desligou de vez em quando. Eu teria que aprender a escrever programas de uma maneira totalmente nova, com menos correspondência entre o texto do programa e o que o compilador viu, e não viu nenhum benefício correspondente.

Além disso, as pessoas podem escrever argumentos longos e convincentes de que o código está fazendo X quando está realmente fazendo Y, e eu me deparei com minha parte de comentários enganosos. Eu desenvolvi uma predileção por ler o código para ver o que ele está fazendo bastante cedo. A programação alfabetizada é a antítese disso.

Eu culparia o efeito de rede . Para que outras pessoas editem seu código e documentação, elas devem ser capazes de entendê-lo.

Isso afasta as pessoas de algo como cweb / noweb, porque usá-las exigiria que você aprendesse o TeX e a sintaxe específica do programa sobre a linguagem de programação que você está usando para o projeto. Isso pode ser visto como uma enorme perda de tempo, especialmente se eles não precisarem de nenhuma composição matemática que seja um grande atrativo para o TeX. (E para muitos programadores de aplicativos, eles realmente não precisam disso.) Em vez disso, preferem algo como os comentários XML do Visual Studio, porque isso já é popular e bem estabelecido.

Os lugares onde eu vi a programação alfabetizada decolar são na computação científica / estatística, onde a maioria dos programadores tem treinamento significativo (também conhecido como PhDs) em matemática, CS ou estatística e, portanto, já conhece o LaTeX. A documentação que eles escrevem tem mais probabilidade de incluir muitas fórmulas complicadas que são melhor escritas em TeX, e é mais provável que estejam programando em R. A proporção de programadores R que conhecem o SWeave é definitivamente muito maior do que, digamos, o proporção de programadores C que conhecem cweb.

Fiquei fascinado com o conceito de programação alfabetizada no final dos anos 90, enquanto estudava, e ainda estou intrigado com a abordagem de Knuths sobre programação e composição tipográfica. Nada além do melhor fará.

O sistema de programação alfabetizada que Knuth projetou fez muito, muito mais do que imediatamente aparece, ou seja, supera muitas deficiências na linguagem de programação subjacente que a ferramenta de geração de código gerada a partir do documento fonte de Knuths, o Pascal padrão.

Para quem teve a sorte de não ter experimentado o Standard Pascal, aqui estão alguns dos destaques.

• Para tornar mais fácil ter um compilador de passagem única, a especificação da linguagem dizia que todas as declarações tinham que vir em uma determinada ordem. Na página da wikipedia: "Cada procedimento ou função pode ter suas próprias declarações de rótulos, constantes, tipos, variáveis ​​e outros procedimentos e funções, que devem estar nessa ordem". Isso significava que você não podia agrupar suas coisas logicamente no arquivo de origem.
• O manuseio de cordas era mais tedioso do que o simples C.
• Os identificadores não podem ter comprimento arbitrário.
• Muitas outras coisas que não consigo mais lembrar.

Todas essas coisas basicamente significavam que Knuth precisava de uma linguagem de programação melhor (então ele inventou uma) e usou Pascal como sua linguagem assembly.

A maioria das linguagens modernas pode fazer essas coisas sem muito esforço, removendo, portanto, uma GRANDE parte do trabalho que a programação alfabetizada deveria resolver.

As linguagens modernas também são mais expressivas, permitindo que mais pensamento seja inserido no próprio código.

Então, o que resta? A capacidade de gerar uma forma de documentação tipográfica a partir do código-fonte, e ISSO existe hoje.

Pense no JavaDoc - a API de tempo de execução Java é talvez a maior parte da programação alfabética disponível atualmente (exceto que o código não é realmente apresentado, mas poderia ter sido se o Java fosse de código aberto desde o início). Veja, por exemplo, a apresentação da estrutura de coleções em http://download.oracle.com/javase/6/docs/api/java/util/Collection.html

Acredito que existem sistemas semelhantes para .NET e outros programas convencionais.

Uma coisa que descobri quando me envolvi com programação letrada nos anos 90 foi que ela atraiu pessoas muito apaixonadas que queriam fazer exatamente a coisa certa - e isso envolveu escrever seu próprio sistema de programação letrado, porque nenhum existente era bom o suficiente para elas. noweb foi uma boa tentativa de reduzir isso, fornecendo um denominador menos comum o suficiente para todos, embora mesmo assim, eu passasse a maior parte do tempo do meu LP desenvolvendo uma impressora bonita para ele ...

Outra questão é que é realmente anti-ágil. De certa forma, diminuir a velocidade é bom porque obriga a pensar com mais antecedência e a acertar as coisas da primeira vez. Por outro lado, documentar meticulosamente à medida que você avança significa que há uma grande barreira para refatorar seu código. E se você esperar até que seu código seja fortalecido antes de liberá-lo, você terminará com uma tarefa de documentação de vários dias, que poderá realmente impedi-lo.

Na minha humilde opinião, muitas empresas têm uma cultura oposta aos objetivos da programação alfabetizada: desejam resultados mais rápidos (só choram por qualidade quando o aplicativo está em produção). De acordo com minha própria experiência, meus chefes se recusaram a entender que resultados mais rápidos não significam "um programa executável no dia seguinte ao pedido". Para eles, se um desenvolvedor não está ocupado digitando no teclado, ele não está trabalhando, está "desperdiçando seu tempo no design, sem sentido". Sim, eu sei, meu chefe é um idiota.

Codificadores escrevem código não em inglês.

Os codificadores não gostam de escrever documentação, porque isso não ajuda a execução do código.

Os codificadores não são bons em escrever documentação porque é um meio ruim para expressar suas idéias.

A programação alfabética parece ser a idéia de levar a documentação para o próximo nível, em que o código é mais uma reflexão tardia. Talvez funcionasse, mas para a maioria dos codificadores parece uma documentação desagradável.

Principalmente porque as pessoas são MUITO ESTÚPIDAS. Um testemunho óbvio do qual é um fluxo interminável de suposições e mal-entendidos expressados ​​pelos jovens sobre a natureza dessa técnica simples.

As pessoas consideram o LP o seguinte: (a) um método de documentação (b) um método de redação de alguns ensaios polidos que exigem habilidades ou talentos especiais (c) simplesmente não têm idéia - como criador do editor de programação Leo, por sua própria admissão etc etc. etc.

O LP, no entanto, é simplesmente: (1) escrever programas em uma mistura de códigos e frases em uma (= qualquer) linguagem humana, onde estes representam outros trechos de código e / ou frases incluídas. É exatamente isso que os autores de inúmeros livros didáticos de programação fazem .. e (2) é um pré-processador simples que expande essas frases em humano (que se tornou como se fossem nomes de sub-rotinas incluídas) para desvendar o resultado NA ORDEM EXIGIDA PELO COMPILADOR (ou intérprete). Caso contrário, pode-se expandir o texto escrito com outro pequeno utilitário para incluir símbolos de formatação para transformar a "fonte alfabetizada" em um texto legível e bem formatado.

Os jovens nunca tentam essa idéia extremamente simples - e fantasiam ou imaginam razões falsas pelas quais nunca tentam ou fazem.

Basicamente, a idéia principal de programar "em pseudocódigo", escrita em uma linguagem humana, e depois expandi-la com um simples utilitário de pré-processador. em funções / sub-rotinas, necessárias para você não se perder nos detalhes, mas totalmente desnecessário para a execução da máquina.

Há 2 aspectos da programação alfabetizada que eu não desejo foram incorporados na programação principal - imagery incorporado (por exemplo, diagramas de design) e ponteiros para as tentativas anteriores e alternativos (por exemplo, "A razão é como este é porque eu tentei este outro caminho e não funcionou porque ... "). Ambos os aspectos podem ser tratados com comentários de documentos e URIs.

Porque a lógica dos programas não funciona da mesma maneira que falamos. Um programa possui um fluxo, condições e loops bem especificados.

Depois de ter codificado no lote, EU PENSO nesses termos. Meu cérebro transforma problemas no domínio de destino do código executável. E é muito mais eficiente para mim escrever isso em uma linguagem geralmente de programação, do que ter que fazer a etapa extra de transformação para tornar meus programas alfabetizados.

Na verdade, eu acredito que meus programas já são alfabetizados ... identificadores falantes, bons nomes de funções, comentários onde eu fiz alguma invasão que eu não compreenderia imediatamente depois de alguns meses.

Para concluir: Meu código Java é mais alfabetizado por si só, como toda programação "alfabetizada" deseja.

Eu vim para alfabetizar programação ao contrário - eu sonhava ter o código organizado conforme ele se encaixa na minha mente, não como o compilador exige. Achei Leo quase ideal para esse fim. Ele também suporta acompanhar os arquivos alterados fora. Esses arquivos não precisam conter nenhuma marcação especial, para que eu possa usar o Leo sozinho, sem a necessidade de outros membros da equipe. Esse recurso - "@shadow trees" - é muito promissor, embora ainda com um pouco de bugs, precisa de mais olhos. E também corrige o problema "oh não, tudo em um arquivo grande", organizando tudo no contorno da árvore e apoiando arquivos externos.

Para mim, ao contrário do nome, a "programação alfabetizada" não é sobre documentação. Não tenho mais documentação do que antes. É sobre ter uma estrutura que me ajuda a não me perder . Eu juro por ele especialmente ao gerenciar arquivos JSP gigantescos (e, apesar de o Leo ter sido originalmente destinado principalmente ao Python e não ter suporte para a linguagem JSP - eu tenho que dividir o arquivo na árvore do Leo manualmente!).

Eu vejo isso como uma valiosa ferramenta de ensino, onde uma dissertação sobre código pode ser escrita e, em seguida, trechos de código de trabalho intercalados nele para instruir os leitores sobre como, o que é e por que do código.

Fora de um ambiente puramente educacional, acho que apenas Knuth realmente entende a melhor maneira de usá-lo.

É o pior de todos os mundos - você precisa escrever um programa de computador altamente correto e altamente específico em um idioma muito inespecífico = inglês. Portanto, você deve escrevê-lo cuidadosamente usando exatamente as frases corretas - para que você possa apenas escrever o código.