Para o seu tribunal, é mais uma questão de artigo, um raciocínio de artigo e, em alguns lugares - perplexidade. Por um lado, recebemos a opinião autorizada de Leslie Lamport, "A programação deve ser mais do que codificação", que coloca a programação e a codificação em uma tabela de classificação improvisada. Do lado oposto, eu, que não tenho status suficiente para disputas com o mestre e a universidade lendária que ele representa ... mas não posso me negar tanto prazer e risco. Espero que camaradas mais experientes corrijam minhas falhas de raciocínio.
Entendo intelectualmente que a codificação no mundo moderno é geralmente vista como o nível mais baixo de atividade de engenharia, que no gráfico evolutivo está mais próximo de um chimpanzé do que de um programador. E talvez este seja o nosso grande erro, porque o código é como o DNA. Apenas quatro nucleotídeos e que biomassa heterogênea na linha de produtos.
Como engenheiros experientes, somos mestres da abstração. Portanto, não será difícil para nós apresentar um programador condicional chamado Leslie Lampport (todos os nomes e correspondências não são aleatórios) e sua principal ferramenta é a máquina de Turing. Ele é um mestre de sua arte, em grande parte graças ao tao de ferro:
- Decida o que o programa deve fazer.
- Determine como exatamente ele deve cumprir sua tarefa.
- Escreva o código apropriado.
O último passo, embora pareça importante para ele, claramente não gosta dele e sugere ignorá-lo. E é difícil argumentar com isso. Mover o ponteiro ao longo da fita sem fim de uma máquina de Turing é um desejo mortal.
E aqui seu gênio é totalmente revelado. Mas esse processo, como um sharpie com dedais, deve ser monitorado com muito cuidado. Ele pega três pontos de seu programa e coloca uma bola com um código abaixo do último. Nós assentimos e fazemos apostas. Então os dedais são deliberadamente misturados lentamente. Onde está o código?
Praticamente não temos dúvida de onde está o terceiro dedal, e o código está ... sob o dedal número 1. Os espectadores estão em choque, o Sr. Lamport também parece perplexo, mas no fundo ele sabe que trapaceou. E justamente nesse momento, quando ele rolou a bola silenciosamente com o código do item 3 do item 1, eu realmente queria pegá-la pela manga.
O que parece um pato se parece com um pato, e mesmo é certo que é mais provável que ele seja. Se você desenvolveu a linguagem TLA + para especificações, gritando com toda sua aparência e comportamento que é um código, é isso. O fato de você o ter utilizado no estágio de especificação do programa, ou seja, o ponto 1 da "decisão sobre o que o programa deve fazer", não eliminou a necessidade do ponto 3 de "escrever o código apropriado".
Vamos interpolar Leslie nos próximos dez anos, durante os quais ele metodicamente usa o TLA + que ele criou para escrever especificações. Penso que, independentemente de analistas, nós, arquitetos ou engenheiros de banco de dados, admitimos relutantemente que estamos nos tornando um codificador no sentido mais rotineiro da palavra. Dialetos diferentes, dicionários diferentes, mas o mesmo aparato de reflexo, que com uma aparência entediada fornece padrões de projeto, diagramas de ER ou especificações no caso de nosso personagem. E agora, sob o ilusório item 1, o autor da tese de que "a codificação não é tão importante" oculta essa mesma codificação.
Para ilustrar, vou convidar outra testemunha, vamos chamá-lo de John McCarthy. Programar uma máquina de Turing é tão irritante para qualquer pessoa quanto John, especialmente quando se trata das tarefas que ele tanto ama no campo da inteligência artificial. E na salvação, ele inventa um novo estilo de codificação declarativo para descrever como a tarefa deve ser executada (parágrafo 2 da lista de Leslie). Vamos chamá-lo condicionalmente de LISP.
Vamos supor que John não tenha escrito um único programa em sua vida, o que, de acordo com a fórmula de Lamport, o coloca no ranking no nível do plâncton, embora ele tenha a relação mais direta com o código. Surge a pergunta: qual é o seu grau de perplexidade e o que ele dirá a ele em uma reunião?
Não vou dar dezenas de exemplos idênticos, mas tentarei oferecer um resumo ao tribunal de colegas. Codificação é o pulso do desenvolvimento. Está presente em todas as etapas, de uma forma ou de outra. Um cardiograma parece chato, mas é um indicador necessário de que o projeto está vivo. Portanto, a redação * -as-a-Code está cada vez mais aparecendo.
Somos todos codificadores. Temos um certo aparato e regras para isso, apenas todo mundo faz isso em seu próprio andar. Não há razão justificada para que uma pessoa que produz código PHP seja um pouco mais estúpida do que um analista que cria especificações executáveis e, juntas, elas perdem para um jovem hacker que pensa imediatamente em códigos de máquina.
A diferença é que alguns de nós verão algo que outros não perceberam e agregarão valor a esse processo. McCarthy - LISP, Lampport - LaTeX e TLA +. E quando você seleciona códigos como o sistema de números decimais, alfabeto Braille, rádio ou emoticons, sua língua não se levanta para dizer que "a programação deve ser mais do que a codificação".
PS Talvez alguém dos visitantes da conferência queira fazer as perguntas levantadas. Se eles parecem bobos para quem fala e para o público, traga tudo para mim.
PPS Aconteceu que eu tenho muitos materiais sobre o tópico de código e codificação e, se esse tópico for de seu interesse, compartilharei com prazer.