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


10

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?


2
Em Zeroth, criei a tag de programação alfabética e adicionei um resumo com base no artigo da Wikipedia. Ajude a expandir o tag wiki com informações relevantes.
precisa saber é

@YannisRizos vou adicioná-lo aqui, não tenho privilégios de edição.
Zeroth 31/01

11
Bem, eu também não :) Eu adicionei alguns recursos (o artigo da Wikipedia e os links em sua pergunta), eles aparecerão quando a edição for revisada e aceita por pares (?!). É uma abordagem intrigante e, como você já a está explorando, volte e melhore o wiki de tags sempre que encontrar algo que você acha que vale a pena mencionar lá.
yannis

11
Eu recomendaria ao autor do site Literate Programming que visite o site UX stackexchange - as cores são muito ruins para a leitura.
Danny Varod

11
Para sua informação, também existe uma literate-programmingtag no StackOverflow. Há mais conteúdo lá, embora ainda não seja muito.
Ross Patterson

Respostas:


9

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.


7
Um grande número de programadores é pouco coerente ao explicar algo em qualquer meio, formal ou informal, seja em programação alfabetizada, escrevendo comentários ou até mesmo um e-mail. É uma maravilha que o software funcione :)
Andres F.

3

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.


1

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):


2
Ponto de vista interessante. Na minha perspectiva, não se alinha muito bem com uma DSL. Como a programação alfabetizada está em alguma linguagem não DSL. E as ferramentas também não são muito parecidas com uma DSL. Eles não são orientados para o domínio do problema. Você poderia fornecer um exemplo de como você acha que a programação alfabetizada é como uma DSL? Um link ou uma referência a um exemplo pode ajudar a esclarecer sua resposta.
S.Lott

Um exemplo disso são as cadeias de comando no Groovy 1.8 que permitem que você "programa" com coisas como turn left then rightou paint wall with red, green and yellow: docs.codehaus.org/display/GROOVY/...
cdeszaq

@ S.Lott - Eu concordo que definitivamente há uma diferença entre DSLs e programação alfabetizada, mas acho que as DSLs podem ser uma ferramenta para alcançar uma programação alfabética verdadeira , na qual você pode digitar uma linguagem natural e expressar o algoritmo desejado. Para mim, misturar linguagem e código naturais é uma forma bastardo de alfabetização.
Cdeszaq

"você pode digitar uma linguagem natural e expressar o algoritmo desejado" é improvável na melhor das hipóteses. Há antecedentes, justificativas, provas de correção, asserções de complexidade (big- O ) e muita documentação de suporte não alogrítmica que não faz parte de um esquema DSL. Não sei se concordo com o paralelo agora que você o esclareceu.
S.Lott

11
"explicação da lógica do programa". Não é a própria lógica. Mas uma explicação. A lógica raramente é auto-explicativa. Ele nunca contém uma prova de correção (que é difícil e às vezes impossível). Raramente contém uma justificativa para a complexidade do big-O. E isso raramente explica as alternativas que têm desempenho inferior ou mais memória. Então, eu sugiro que o DSL fique aquém da "explicação".
S.Lott

-2

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.