Programação alfabética, metodologia de design bom / ruim

Recentemente, encontrei o conceito de programação alfabetizada . E eu achei isso bastante intrigante. No entanto, não fui encontrado com alegações de que é uma maneira ruim de estruturar um programa. Parece não cobrir muitos lugares. Nem aqui eu pude encontrar alguma dúvida sobre isso.

Minha pergunta não é sobre suas falhas ou maneiras de lidar com a documentação. Considero a documentação um efeito colateral do que isso significaria para o fluxo da programação alfabetizada. Eu sei que o design foi originalmente concebido para facilitar a documentação, bem como o conceito de fluxo de programação direta .

O conceito de dividir o problema em problemas baseados em frases pequenas parece ser realmente uma idéia brilhante. Assim, facilitará a compreensão do fluxo do programa.

Uma conseqüência do método de projeto alfabetizado é também que o número de funções necessárias será limitado à imaginação do programador. Em vez de definir uma função para uma determinada tarefa, ela pode ser criada como scrapno método alfabetizado. Isso produziria a inserção automática do código, em vez de uma compilação de função separada e o requisito subsequente de uma etapa de otimização de compilação entre procedimentos para obter a velocidade equivalente. De fato, a primeira tentativa de Donald E. Knuth mostrou um tempo de execução inferior, devido a esse mesmo fato. Eu sei que muitos compiladores podem ser feitos para isso, mas essa não é minha preocupação.

Então, eu gostaria de receber um feedback de por que alguém deve considerar isso uma metodologia de design ruim / bom?

Isso produziria a inserção automática do código, em vez de uma compilação de função separada e o requisito subsequente de uma etapa de otimização da compilação entre procedimentos para obter a velocidade equivalente

Isso é irrelevante. Já faz décadas. Você pode removê-lo da questão, pois não faz sentido que os compiladores modernos subvertam seus otimizadores.

Então, eu gostaria de receber um feedback de por que alguém deve considerar isso uma metodologia de design ruim / bom?

Não há desvantagem na programação alfabetizada. (Espero dezenas de -1 votos para esse sentimento.) Como praticante, nunca vi nenhum problema.

Existem alguns argumentos contra os quais tudo se resume a "programar em uma linguagem de nível superior é subvertido, aprimorando o código resultante". Direita. Da mesma maneira que a programação em C ++ é subvertida, aprimorando o .oarquivo que é produzido. É verdade, mas irrelevante.

Escrever programas alfabetizados significa apenas combinar design de alto nível e detalhado (nível de código) em um documento, escrito com um conjunto de ferramentas adequado que produz arquivos amigáveis ​​ao compilador e arquivos amigáveis ​​às pessoas.

Quando Knuth inventou a programação alfabetizada, as principais linguagens OO não existiam. Portanto, grande parte da web original e ferramentas de tecelagem permitiram que ele criasse definições de classe para tipos de dados abstratos.

Muito disso é irrelevante hoje em dia. As ferramentas de programação alfabética podem ser bastante simples se estiverem focadas em linguagens de programação modernas (de alto nível) orientadas a objetos (ou funcionais). Há menos necessidade de soluções elaboradas devido às limitações de C (ou Pascal ou Assembler).

A abordagem para escrever programas alfabetizados não é diferente da abordagem para escrever programas analfabetos. Ainda requer um design cuidadoso, testes de unidade e codificação pura. O único trabalho extra é escrever explicações, além de escrever código.

Por esse motivo apenas - a necessidade de escrever explicações coerentes - a programação alfabetizada é difícil para alguns programadores. Há um número razoável de programadores que são bem-sucedidos (seu código passa em todos os testes de unidade, é puro e fácil de entender), mas parece que não consegue escrever uma frase coerente em seu idioma nativo. Não sei por que isso é verdade.

Há um número muito grande de programadores que parecem ter apenas sucesso marginal e somente por acidente. (Existem perguntas ruins suficientes no Stack Overflow que indicam que muitos programadores lutam para entender os fundamentos.) Para programadores que fazem perguntas amplamente incoerentes ao overflow de pilha, sabemos que eles não podem realmente fazer um bom trabalho de programação alfabetizada, porque podem faça um bom trabalho de programação.

O aspecto mais importante da programação alfabetizada (ou mesmo apenas bons comentários) para mim não é tanto que ele forneça documentação, mas sim a intenção do programador. Ao conhecer a intenção declarada, você pode julgar imediatamente se o código a seguir ou não realmente faz o que deveria. Sem intenção, você deve começar com a suposição de que o código está correto e depois provar que está certo ou errado por indução - o que é mais exaustivo e demorado, pois muitas vezes exige que você se familiarize com todo o código ao redor.

A intenção declarada geralmente permite que outras pessoas não familiarizadas com o código entrem rapidamente e encontrem erros sem precisar conhecer o contexto maior que o cerca.

E, é claro, ajuda você a aprender o fluxo e o design básicos do código mais rapidamente também, pois o inglês comum geralmente é mais intuitivo do que a aritmética dos ponteiros para a maioria das pessoas.

Embora eu seja um pouco novo no conceito de programação alfabética (e, portanto, é provável que eu esteja perdendo totalmente o barco), parece muito alinhado com o conceito de DSL .

A idéia por trás de uma DSL é destilar um domínio de problemas em uma gramática simples, orientada para a linguagem natural, que pode ser usada para criar algoritmos para resolver esses problemas.

Para mim, essa mesma idéia, ou pelo menos a base principal dela, é a mesma ou pelo menos intimamente relacionada à programação alfabetizada.

No mundo do groovy, por exemplo, há um forte impulso para usar DSLs com mais regularidade e criar novos DSLs para resolver problemas comuns. Esse impulso vem das duas ferramentas da linguagem (easy builders), bem como das bibliotecas principais que oferecem suporte a uma API baseada em DSL.

Dado que a tendência, pelo menos naquele canto do mundo, é para a programação alfabetizada, eu diria que é uma boa metodologia para lutar.

Infelizmente, o nível de pensamento necessário para criar um bom dsl está além da maioria dos programadores, pelo que vi. Sei que luto pessoalmente com alguns dos conceitos necessários de tempos em tempos. Pode ser essa dificuldade que impediu que essas técnicas ganhassem uma adoção mais ampla.

É o seu caso clássico de quando usar a ferramenta é uma coisa, mas criá-la é em um nível totalmente diferente.

Para expandir um pouco o meu ponto de vista, não é muito o fato de DSLs serem a mesma coisa que programação alfabetizada, mas o fato de tornar a programação alfabética muito mais possível . Especialmente quando são DSLs de linguagem natural .

Na versão 1.8 do groovy, o recurso DSL em linguagem natural foi substancialmente aprimorado com a adição de cadeias de comando mais poderosas.

Por exemplo, as seguintes linhas de código estão programando , não apenas pseudo-sentenças:

drink tea with sugar and milk
move left by 30.centimeters
sendFrom "Guillaume" to "Jochen"
send from: "Jochen" to "Lidia"
Email.from "Lidia" to "Guillaume" withBody "how are you?"
contact.name "Guillaume" age 33
move left by 30.centimeters
sell 100.shares of MSFT
take 2.pills of chloroquinine in 6.hours
blend red, green of acrylic
artist.paint "wall" with "Red", "Green", and: "Blue" at 3.pm
wait 2.seconds and execute { assert true }
concat arr[0] with arr[1] and arr[2]
developped with: "Groovy" version "1.8-beta-2"

Nota: O exemplo de código vem do blog de Guillaume Laforge

A idéia central por trás da programação alfabetizada é que a linguagem natural é mais compreensível para os seres humanos e é isso que importa. Os recursos DSL de linguagem natural do Groovy tornam essa realidade muito mais próxima, na minha opinião. Especialmente quando essas DSLs são usadas para criar regras de negócios para um aplicativo.

Ser capaz de "codificar" os componentes críticos de um sistema usando linguagem natural é a própria essência da programação alfabetizada. Ter que intercalar a linguagem natural com pedaços de código é uma forma bastardizada de programação alfabetizada. Embora útil, acredito que as DSLs de linguagem natural que permitem usar a linguagem natural como o próprio código representam um grande salto em frente.

Expandir a capacidade de programação em geral é o próximo passo no processo, mas em grande parte as ferramentas para isso já estão em vigor. Sim, ainda não existe uma DSL "geral", mas para domínios menores, a capacidade existe.

Para mais exemplos disso em ação (em nenhuma ordem específica):

• http://www.slideshare.net/glaforge/groovy-dsls-s2gforum-london-2011-guillaume-laforge
• http://docs.codehaus.org/display/GroovyJSR/GEP+3+-+Command+Expression+based+DSL
• /programming/6646811/groovy-1-8-abc-style
• http://svn.codehaus.org/groovy/trunk/groovy/groovy-core/src/test/gls/syntax/Gep3Test.groovy
• http://groovyconsole.appspot.com/script/355001
• http://docs.codehaus.org/display/GROOVY/Groovy+1.8+release+notes#Groovy18releasenotes-CommandchainsfornicerDomain-SpecificLanguages
• http://mrhaki.blogspot.com/2011/05/groovy-goodness-command-chain.html
• http://ice09.wordpress.com/2011/10/07/dsls-made-easy-with-groovys-chain-method-calls-gep-3/
• http://eric-berry.blogspot.com/2011/05/some-dsl-fun-with-groovy-18.html

Eu acho que isso é um erro pensar que LP é algum tipo de DSL. Como o LP é - diário (com diagramas, esquemas, fragmentos de pseudo-código, ou seja, pedaços) de programa desenvolvido, é arquitetura e assim por diante ... É absolutamente análogo ao caderno de papel - muitos desenvolvedores o usam, mas após o término do programa - largue seus 'cadernos, papéis ...

Há muito tempo, cada físico, astonômero, químico / alquimista, matemático tem cadernos próprios, manuscritos com muitos esquemas, informações necessárias, tabelas e, sem eles, você pode entender ou repetir sua experiência bem-sucedida, seus resultados. E sempre entre esses povos existe manuscritos / cadernos de caça.

Hoje muitos programadores escrevem código e, às vezes, adicionam comentários! O programa Byt não é apenas código - são pensamentos, idéias, imaginação, conceitos e, quando o novo desenvolvedor herda o código alienígena - ele quebra todas as idéias e conceitos com frequência, cria diferentes "brechas" e "backdoors", espero que você me entenda :)

Portanto, o principal requisito para o LP (como ferramenta!) Também é permitir que todos eles tenham uma sintaxe simples, leve e legível. Eu tentei muitas ferramentas de LP, mas hoje estou desenvolvendo o próprio - NanoLP ( http://code.google.com/p/nano-lp/ ), cujo objetivo é atender a essa demanda.