- Gerald Sussman diz que, desde 1962, passando por ambientes de computação iniciais como IBM 7094, PDP-6, Mac Hack 6 e Maxima, continua se apegando ao prazer de programar em si
- Programar não é codificar mecanicamente uma especificação em código, mas está mais próximo de um projeto abstrato de engenharia, no qual se buscam juntos especificação e implementação possíveis sob objetivos incompletos
- Ao colocar lado a lado a estrutura eval/apply do Lisp e a interação nas equações de Maxwell, ele vê a programação como uma atividade criativa que lida com problemas conceituais profundos, como a física, a matemática e a filosofia
- Bugs não são apenas falhas simples, mas oportunidades de aprendizado que surgem quando humanos finitos resolvem problemas com planos simplificados, e fazem parte da “resolução de problemas por depuração de um plano quase correto”
- A diferenciação automática, a extensão de operações genéricas em Scheme e a experiência de expressar a mecânica clássica como programas executáveis mostram que a programação pode tornar outras disciplinas mais claras, e ele enfatiza que a diversão se completa quando isso é compartilhado como free/libre software
Projeto e exploração além da codificação
- Sussman teve contato com computadores desde o ensino médio, em 1962, quando conheceu computação no Columbia Science Honors Program
- Os primeiros computadores eram máquinas da linha IBM 7094 que custavam milhões de dólares, conseguiam endereçar apenas 2^15 palavras de 36 bits e operavam com ciclo de cerca de 2 microssegundos
- Depois de entrar no MIT, ele teve contato com computadores como o DEC PDP-6, e esse sistema conseguia endereçar 2^18 palavras de 36 bits
- Uma memória grande era necessária para sistemas iniciais de manipulação simbólica como o Maxima
- O MIT encomendou uma memória grande à Fabritek, cuja fabricação levou um ano e custou, segundo registros, cerca de 380 mil dólares
- Como essa memória era enorme para a época, recebeu o nome de Moby, em referência a uma baleia
- Ele se envolveu com inteligência artificial, novos projetos de computadores, invenção de linguagens de programação, simulação numérica em mecânica celeste e escrita de grandes sistemas simbólicos, mas no centro de tudo continuou existindo seu amor pela programação
- Programar não é um trabalho mecânico de transformar uma especificação bem definida em código executável
- Boas especificações normalmente não descem prontas de cima
- Primeiro se explora o que é implementável, e depois se escreve a especificação de acordo com o que de fato pode ser alcançado
- Por isso, programar é uma exploração conjunta em busca de especificações e implementações possíveis rumo a objetivos parcialmente definidos
- Ao contrário da engenharia física, a programação é limitada menos por restrições materiais, como tolerâncias, curvaturas de corte ou erros de resistência, e mais pela capacidade de organizar o pensamento
- O programador lida com uma enorme máquina virtual ao escolher representações, algoritmos e níveis de abstração
Programação como arte criativa
- Para explicar a sensação de programar, Sussman cita um texto em que Edgar Allan Poe descreve como escreveu "The Raven"
- Poe afirma que a obra não foi concluída por acaso ou intuição, mas passo a passo, como um problema matemático, expondo um processo complexo de escolha, remoção, inserção e revisão
- Esse processo se aproxima muito mais da sensação real de programar do que da ideia de converter uma especificação em código
- Programar está mais perto de uma arte criativa, como arquitetura, música, matemática e física teórica
- A matemática é uma atividade de inventar belos teoremas
- A física teórica é uma atividade de inventar explicações para o mundo físico
- A programação também é uma atividade de inventar e lapidar ideias e estruturas
A estrutura mostrada por eval/apply e pelas equações de Maxwell
- A experiência de aprender Lisp 1.5 e o interpretador eval/apply no primeiro ano do MIT foi, para Sussman, um ponto de virada em sua vida
- eval recebe uma expressão e um ambiente, avalia operador e operandos para produzir um procedimento e argumentos, e apply recebe o procedimento e os argumentos, associa os argumentos aos parâmetros formais e então retorna à avaliação do corpo
- Sussman vê essa estrutura como algo que vale para todas as linguagens de computador e até para o modo de funcionamento dos próprios computadores
- Na mesma época, ele teve outra forte impressão ao estudar as equações de Maxwell em uma disciplina de eletromagnetismo
- Maxwell adicionou o termo de corrente de deslocamento para resolver a inconsistência entre a conservação de carga e as equações existentes
- Como resultado, surge a equação das ondas eletromagnéticas e a conexão de que a luz é uma onda eletromagnética
- Há uma profunda semelhança entre a interação de eval/apply e a estrutura em que campo elétrico e campo magnético geram mudanças um no outro nas equações de Maxwell
- Essa semelhança também se conecta à relação entre variáveis duais, como posição e momento, energia e tempo
- A programação encontra problemas filosóficos no cotidiano
- Não é simples explicar como o nome
Chicagodentro de um programa se refere à cidade real - A identidade de dois objetos se revela ao verificar se, ao alterar um deles, o outro também muda; por isso, mutação (mutation) se conecta ao problema da identidade
- Em programas puramente funcionais, não há mutação, então a identidade precisa ser vista de outra forma
- Dentro de uma expressão citada, o princípio de que “iguais podem ser substituídos por iguais” pode deixar de valer
- Proposições como “todos os corvos são pretos” dificultam o sentido da evidência, como mostra o Paradoxo do Corvo de Hempel
- Não é simples explicar como o nome
Como lidar com bugs
- Sussman vê bugs não como fracassos vergonhosos, mas como oportunidades de aprendizado
- Ele diz que depurar com boas ferramentas pode ser tão divertido quanto uma aventura, e que bugs deveriam ter nomes, como fencepost error ou reader-writer bug
- Bugs também são resultado de estratégias poderosas de projeto
- Como humanos não conseguem pensar em tudo de uma vez, fazemos planos
- Planos exigem simplificações, e simplificações criam partes omitidas
- Como resultado surgem bugs, e depurar se torna o processo de ajustar um plano quase correto até a direção desejada
- Sussman chama isso de “resolução de problemas por depuração de um plano quase correto”
- O exemplo de projeto de filtros elétricos mostra essa estratégia
- Para criar um filtro com resposta entre 30Hz e 3kHz, fatoriza-se a função do sistema
- Combinam-se resistores e capacitores para montar os subcircuitos necessários
- Mas cada subcircuito parte da suposição de que “não sai corrente”, então, ao conectá-los, surge um loading bug
- Um patch com amplificador pode resolver esse problema em algumas situações
- Nem todo bug é divertido
- Sussman critica C e C++ por serem cheios de armadilhas
- Ele também associa a necessidade frequente de novos kernels a bugs de gerenciamento de memória em código escrito em C
- Em Python, ele cita inconsistências como
{}ser um dicionário, mas{1}ser um set, e o fato de tuple ser definido por vírgula, não por parênteses
Diferenciação automática e física executável
- Em 1992, Sussman passou um período no Caltech com o grupo de Kip Thorne, onde aprendeu relatividade geral e disse ter usado programas como meio de armazenar conhecimento
- Junto com Dan, projetista de chips de ponto flutuante da Hewlett-Packard, ele acabou redescobrindo de forma independente a diferenciação automática em modo direto (forward-mode automatic differentiation) ao pensar na derivada de funções
- O objetivo não era nem diferenciação simbólica que olha dentro da função, nem aproximação numérica
- O núcleo da ideia era a chain rule
- Ao estender números para objetos diferenciais com uma parte finita e uma parte infinitesimal, a chain rule passa a funcionar automaticamente na composição de funções
- Como usava Scheme, ele pôde redefinir os operadores aritméticos primitivos para se adequarem aos objetos diferenciais, e Sussman diz que implementou isso durante a noite em um “hack attack”
- Depois, várias pessoas contribuíram para refinar derivadas de funções de ordem superior, derivadas múltiplas e a extensão dinâmica de operações primitivas em Scheme
- Abelson ajudou a organizar a teoria correta para derivadas múltiplas
- Jeff Siskind, Barak Pearlmutter e Alexey Radul depuraram bugs sutis nas derivadas de funções de ordem superior
- Hansen criou uma forma eficiente de estender dinamicamente operações primitivas de Scheme
- Esse trabalho levou ao sistema Scmutils, usado com Jack Wisdom para ensinar e pesquisar mecânica clássica e geometria diferencial
- O livro de Sussman e Wisdom, Structure and Interpretation of Classical Mechanics, é uma tentativa de tornar mais clara a compreensão da mecânica clássica por meio de técnicas computacionais
- A notação tradicional das equações de Lagrange é ambígua sem conhecimento cultural prévio e também apresenta problemas do ponto de vista dos tipos das funções
- Quando escrita com notação funcional e código Scheme, a ideia matemática se transforma em um programa executável e claro
- No exemplo do oscilador harmônico, calcula-se a equação correta do movimento e a relação da frequência angular a partir de massa, constante da mola e posição
A diversão só se completa quando é compartilhada
- Sussman organiza a diversão de programar em vários aspectos
- O prazer de descobrir semelhanças profundas entre mundos diferentes
- O prazer de encontrar, no trabalho real, problemas com os quais filósofos pensam há muito tempo
- O prazer da caçada ao rastrear bugs
- O prazer de descobrir boas ideias e abstrações
- O prazer de tornar outras disciplinas mais claras por meio de programas
- A diversão da programação se completa quando o trabalho é compartilhado com outras pessoas, e ele recomenda usar e produzir free/libre software
- Sussman lamenta ter precisado gravar por Zoom e diz que queria um software que pudesse ser lido, modificado e compartilhado novamente
- Sobre software livre e liberdade de software, ele recomenda ver a filosofia do software livre da GNU e pede participação e doações para a Free Software Foundation
1 comentários
Comentários do Hacker News
Gostei muito desta parte: “Escrevo programas como uma forma de lembrar algo. Minha memória são os programas que escrevi. Quando aprendo coisas como matemática, física ou biologia e escrevo programas que as expressam, depois posso lê-los sem ambiguidade e entendê-los com facilidade; é assim que armazeno conhecimento”
https://www.infoq.com/presentations/Expression-of-Ideas/
O tema é muito próximo da citação acima e trata de como a programação ajuda a compreender mais profundamente assuntos como matemática e física
Por exemplo, o modo como analgésicos funcionam ajuda a entender keyloggers ou ataques man-in-the-middle, e observar a “revisão gramatical” do DNA durante a mitose pode ensinar compilação de modo geral
O comportamento de um filhote de cachorro de engolir qualquer coisa que vê acaba dando ao sistema imunológico dados de teste suficientes sobre o ambiente ao redor, algo parecido com aprendizado de máquina; e muitos conceitos de cibersegurança também podem ser entendidos pela biologia
Como penso por imagens, era difícil entender matemática de verdade, mas programar me permitia criar imagens e relações na cabeça
Tive sorte de descobrir isso quando criança; sem isso, acho que teria ficado perdido
Problemas, decisões, motivos, fatos que serviram de base e alternativas avaliadas são todos conhecimento; e cada comando digitado em uma linguagem de programação também é uma decisão
O design de software pode durar tempo suficiente para que decisões anteriores e seu contexto sejam esquecidos, e também tempo suficiente para que pessoas saiam, o conhecimento desapareça e pessoas novas cheguem sem conhecimento suficiente
Fazer o computador entender o código-fonte não é a parte difícil; o mais difícil é permitir que outras pessoas entendam o que foi feito e consigam trabalhar melhor e mais rápido
Quando a cabeça e a memória não bastam, é preciso usar tecnologias como escrita, impressão e software para lembrar e organizar conjuntos maiores de conhecimento
O maior problema na matemática também era eu não poder confiar que não cometeria erros, nem confiar que os encontraria
Um compilador ou interpretador me faz perceber
Anos atrás, assisti a uma palestra de Sussman no subsolo da NYU junto com uns 20 doutorandos em neurociência
Ele já falava sobre interpretabilidade em IA muito antes de o assunto virar moda
Fiz uma pergunta, e ele percebeu imediatamente que havia alguém formado em engenharia elétrica na sala; foi até o quadro ao lado e mostrou que era possível descobrir, a partir de primeiros princípios, como um amplificador operacional funciona
A energia e a inteligência daquele homem eram enormes, e ele certamente deixou uma impressão profunda
Ainda não vi o vídeo, mas me lembrei imediatamente da citação de Alan J. Perlis que Sussman e Abelson usaram na dedicatória do SICP
Ela diz que, na ciência da computação, é muito importante preservar a diversão da computação, e que no começo ela era realmente divertida
Às vezes os clientes saíam prejudicados, e começamos a levar suas reclamações a sério, mas a visão é que não somos responsáveis pelo uso bem-sucedido, sem erros e perfeito dessas máquinas
Pelo contrário: nossa responsabilidade é forçar as máquinas ao limite, enviá-las em novas direções e manter a diversão; a ideia central é esperar que a ciência da computação não perca o senso de diversão e não passe a agir como missionários ou vendedores de Bíblias
Não devemos sentir que a chave para uma computação bem-sucedida está apenas em nossas mãos; o que temos nas mãos é inteligência, isto é, a capacidade de ver as máquinas como algo maior do que eram quando as encontramos e de torná-las maiores
Para a maioria do restante de nós, que fazemos programas para contar feijões, do ponto de vista de quem paga o salário, não perder um único feijão é muito mais importante do que o quanto nos divertimos ou o quanto expandimos as possibilidades
Ou seja, não é bug; é uma pequena porção de diversão /s
Um título melhor seria algo mais próximo de “ciência da computação acadêmica é divertida, ou deveria ser”
O ponto central é que descobrir analogias, pensar filosoficamente, depurar, ter boas ideias e obter clareza são coisas divertidas, mas isso é sobretudo um luxo de professores que são pagos para fazer esse tipo de atividade e parece não se encaixar muito bem no mundo de “o cliente quer isso até o fim de semana”, exceto pelo prazer controverso da depuração
A maior parte da “programação” provavelmente deveria ser vista mais como uma disciplina de escola técnica, como soldagem
Desenvolver uma nova técnica de soldagem de fato é um tema de pesquisa em nível de pós-graduação, mas a maioria dos soldadores e programadores trabalha com ferramentas bem conhecidas e sistemas relativamente simples
Um aluno de escola técnica talvez não queira perder tempo aprendendo MIT/GNU Scheme, algo que nunca mais usará na vida profissional; para um aluno acadêmico, porém, isso pode ser gratificante como um estudante de linguística aprender a ler e escrever Linear B
Qualquer trabalho pode ser divertido, mas no fim pesam mais condições como a competência e a estabilidade emocional de colegas e gestores, o projeto e a segurança do espaço de trabalho, uma remuneração que permita viver e a existência ou não de uma cultura organizacional que deixa passar trabalho malfeito; o mesmo vale para outras profissões especializadas, como programação de sistemas de controle industrial
Você descobriria que pessoas curiosas, ponderadas e instruídas, autodidatas ou não, fazem um trabalho melhor em qualquer profissão do que pessoas que não são assim
Muito tempo atrás, quando trabalhei como soldador, pessoas inteligentes, motivadas e curiosas se saíam melhor do que aquelas que só estavam cumprindo horas
Então concordo que programação se parece com soldagem, mas de um jeito diferente do que você quis dizer
SICP mudou completamente a forma como eu pensava sobre código, abstração e modularidade, ao lado de colegas que hackeavam em Pascal ou C
Enquanto com Lisp/Scheme eu conseguia criar um modelo mental do problema, meus colegas precisavam fazer a abstração na cabeça e depois implementá-la em uma linguagem que exigia foco em baixo nível
Por isso sou eternamente grato por ter conhecido SICP cedo
Dependendo da linguagem em que você programa, isso pode ser mais divertido ou mais confortável
Acho que provavelmente nunca vou me sentir à vontade com C++
É bom poder ouvir a visão sobre programação de um dos autores de SICP, e as anedotas dos primeiros minutos também são legais
Quando disse que precisava muito do livro porque encontraria Sussman no dia seguinte, o funcionário ligou para a Harvard co-op; disseram que havia um exemplar em estoque, então peguei um Uber até a livraria de Harvard e comprei SICP
No dia seguinte, fui ao escritório de Sussman no MIT e, por acaso, Abelson também estava lá e estava prestes a sair; os dois assinaram meu SICP
Sussman acrescentou: “Se você tivesse chegado 15 minutos mais cedo, minha esposa também teria assinado!”, e até então eu não sabia que a esposa dele tinha sido a revisora de SICP
Também tenho uma foto incrível com esses dois magos e o livro roxo que eu acabara de receber autografado
Quero muito assistir a esse vídeo
Ainda não passei por SICP de verdade, mas peguei o livro emprestado e ouvi as aulas enquanto reformava a casa
Costumo incluir em apresentações de arquitetura uma citação de Sussman das aulas de SICP sobre entender coisas complexas, e é sempre aquele slide que as pessoas copiam freneticamente
Sinceramente, por muitos anos eu amei programar, e por um tempo isso foi meu principal hobby
Eu costumava experimentar novas linguagens ou softwares, ler livros de programação e participar de vários chats como libera/freenode
Mas, ao virar freelancer e passar a me concentrar em entregar rapidamente código decente em contextos menores, essa paixão diminuiu
No geral, isso pode ter sido bom para mim como engenheiro, mas muita diversão e aprendizado desapareceu do trabalho do dia a dia
Freelance e consultoria normalmente consistem em resolver problemas — até mesmo em “atirar” em problemas — removendo-os o mais rápido possível, e elegância não é obrigatória
Se você quer ser um builder que cria ferramentas, acho que isso não acontece muito no freelance; talvez seja possível ao migrar para um papel de consultor
Como consultoria tende a ser uma relação mais de longo prazo, vale considerar isso como o próximo passo