- Leslie Lamport é um dos primeiros desenvolvedores do LaTeX e um pioneiro na área de sistemas distribuídos. Vencedor do Prêmio Turing em 2013
- Em sua keynote na SCaLE 22x, ele enfatiza a importância da abstração e aponta que a maioria dos programadores se concentra em codificação e linguagem, mas que o pensamento abstrato e o projeto antes de codificar são o essencial
Resumo da apresentação
- Vocês podem esperar que eu fale sobre concorrência (Concurrency), mas não tenho nada de novo a dizer sobre isso
- No entanto, os insights sobre escrever programas concorrentes também se aplicam à programação em geral
- Esta apresentação trata de programação de forma ampla
Algoritmo vs. programa
- Algoritmo: uma ideia abstrata independente de linguagem. Um conceito mais abstrato e de nível mais alto do que um programa
- Programa: a forma concreta de implementar um algoritmo em uma linguagem específica. Linguagens de programação são complexas demais para expressar algoritmos
- Algoritmos não são executados e, em geral, são curtos e simples
- Especialmente em código relacionado a concorrência, é preciso definir primeiro o algoritmo correto e só então implementá-lo
Abstração vista pelo exemplo do valor máximo em um array
- Mesmo em um problema simples, é preciso definir com clareza “o que fazer” (What)
- Ex.: “retornar o valor máximo de um array de inteiros” → “retornar o menor número que seja maior ou igual a todos os elementos”
- Também é preciso definir previamente como tratar arrays vazios (ex.: usar
-∞)
- Com essa definição clara, torna-se possível derivar um algoritmo (How) mais simples e robusto
A execução de programas é um fluxo de estados
- A execução de um programa não é apenas uma sequência de instruções, mas uma sucessão de estados (state)
- Cada transição de estado representa a execução de uma parte do código
- Essa visão é importante para provar a correção de algoritmos (uso de invariantes etc.)
Ferramenta para sistemas complexos: TLA+
- Para expressar abstrações com precisão, é necessária uma linguagem exata
- O TLA+ foi projetado para esse propósito
- A Amazon Web Services usou TLA+ para descobrir com antecedência falhas graves de projeto
- O Virtuoso, sistema operacional da sonda Rosetta, também foi projetado com base em TLA+, e o código era conciso e estável
O papel da abstração mesmo com especificações incompletas
- Ex.: em um pretty printer, o critério de alinhamento pode ser subjetivo
- Ainda assim, definir um conjunto de regras abstratas é importante para depuração e manutenção
A relação entre escrita e pensamento
- Colocar os pensamentos no papel ajuda a tornar o raciocínio mais claro
- A abstração não deve ficar só na cabeça; ela precisa ser expressa por escrito para ser eficaz
- Lamport menciona que sua formação em matemática ajudou a desenvolver sua capacidade de abstração
- Matemáticos podem ensinar abstração aos programadores
A visão sobre bibliotecas e bugs
- Na segunda parte da apresentação, “Por que programas precisam ter bugs”, ele aborda o problema da complexidade
- O software moderno depende de muitas bibliotecas, mas elas carecem de descrições exatas e independentes de linguagem
- Por isso, durante a integração, surgem bugs inesperados
- Ex.: sua experiência depurando JavaScript no site de seu curso de TLA+
- A visão baseada em estados é útil para entender essa complexidade
Temas abordados na sessão de perguntas e respostas
- O impacto da IA na abstração
- A desconexão entre open source e a academia
- A realidade em que desenvolvedores negligenciam definições formais (formal definition)
- O mais importante continua sendo “pensar antes de codificar”
Conclusão: a essência da programação é pensar
- Lamport defende que pensamento abstrato e especificações formais devem vir antes da simples codificação
- O esforço inicial é grande, mas no fim leva a software mais robusto e mais fácil de manter
- Codificar é apenas uma parte da programação; a programação de verdade começa com algoritmos precisos e abstração
- Em um mundo moderno com sistemas mais complexos e mais concorrência, abstração é uma competência essencial, e programadores precisam de treino em pensar e abstrair
5 comentários
Eu também concordo com este texto.
Acredito que definir problemas com valores de estado abstraídos é útil para descobrir problemas, e estou tentando criar ferramentas de gerenciamento de estado visual, explícitas e claras, como visualização de estado com diagramas, Unreal Blueprint ou workflow.
Acho que vou precisar olhar primeiro para a linguagem.
Este texto me lembra uma aula da graduação em teoria da computação! Recomendo que quem programa estude isso.
Fiquei curioso para saber o que é TLA
Vou procurar
Eu também fiquei curioso e fui pesquisar.
TLA+ - Uma linguagem avançada para modelar programas e sistemas concorrentes/distribuídos
Opiniões do Hacker News
Os "coders" da demoscene se chamam assim com orgulho, e muitas vezes também são excelentes "programadores" e "engenheiros de software". Seja qual for o nome usado — coder, programador, engenheiro de software — o importante é fazer o computador funcionar do jeito que você quer
O keynote do ano que vem provavelmente será "vibing não é coding, nem programming...; às vezes é uma pirâmide de lixo que meio que funciona". Ainda bem que Dijkstra não está aqui para ver isso. Ele já ficava irritado na sala de estar dos meus pais nos anos 80. Nem dá para imaginar como reagiria ao ver "vibe coding"
Keynote de Leslie Lamport na SCaLE 22x: pensar, abstrair e só depois codificar. Lamport defendeu uma mudança fundamental na forma de programar, enfatizando pensamento e abstração antes do código, algo que se aplica a todo código não trivial
Programar deveria ser um processo intencional em que a implementação (coding) vem depois do projeto cuidadoso (abstração), com foco em especificações claras e no entendimento do comportamento do programa por meio de sequências de estado e invariantes. Pensar é sempre melhor
Um professor de matemática chamava de coding todo ato de transformar conceitos em formas mais precisas e legíveis por máquina. Isso incluía não só escrever em uma linguagem de programação o que você quer que o computador faça, mas também codificar dados. A palavra "encode" deixa isso claro. Ele passava exercícios para definir um esquema de codificação que convertesse árvores binárias em números naturais. A palavra coding é ambígua demais, então ele não a usava muito
Lamport argumenta que é preciso separar o "o quê" do "como". Mas fico me perguntando se, na maioria dos problemas, o "o quê" e o "como" do programa não acabam se misturando em certo grau. Por exemplo, considerações de desempenho fazem parte do "o quê" ou do "como"?
Resumo interessante: algoritmo não é programa, não deve ser escrito em linguagem de programação e deve ser simples. Já um programa precisa rodar rápido em conjuntos de dados potencialmente grandes, então precisa ser complexo. Isso é discutido especialmente porque, em programas concorrentes executados em várias CPUs, a ordem de execução varia
Define-se programação como código que exige pensamento antes de ser escrito, para ser usado por pessoas que não querem ler o código. Essa palestra já vem sendo feita há muito tempo. O exemplo que simplifica encontrar o menor elemento coincide exatamente com "Define Errors Out of Existence", do livro de John Ousterhout
Estou curtindo a ironia de a seção de comentários estar cheia justamente de pessoas que não entenderam a mensagem. O ponto central de Leslie Lamport é que desenvolver a capacidade de pensar abstratamente leva a programas melhores. Abstração, em sentido matemático e lógico, permite remover todos os detalhes irrelevantes. O mesmo vale para desenvolvimento de software guiado por IA
Como era de se esperar em qualquer assunto que envolva rigor, muita gente leu só o título e reagiu negativamente. Um hacker no Hacker News pode ser um programador habilidoso que consegue resolver problemas. Hoje também pode significar "You're a Hack", isto é, alguém incompetente que produz resultados de baixa qualidade
Esta palestra e a discussão são excessivamente minuciosas
Há um bom artigo na ACM no momento dizendo que, embora não haja acordo sobre o que é abstração, ela ainda assim é muito útil. Em geral concordo sobre onde está o ponto importante. Não concordo exatamente sobre o que ele é nem por que é importante. Dá para tirar muita inspiração daí, e isso por si só já tem valor
Hacking não é coding, nem programming, nem desenvolvimento de software, nem engenharia de software. Mas, no fim das contas, muita gente usa esses termos quase como sinônimos, e destacar as diferenças entre as definições que cada um usa pessoalmente raramente é um uso produtivo do tempo