- Brian Kernighan relembra The Practice of Programming, escrito com Rob Pike, como um livro que tentou tratar de “como escrever programas bem, de forma profissional” em 1999, quando internet, Python, Perl e Java estavam se espalhando rapidamente
- Alguns exemplos envelheceram com o tempo, mas ele considera que princípios como estilo, depuração e postura ao escrever podem ser aplicados mesmo quando mudam a linguagem e o ambiente
- Parsear CSV continua sendo algo bagunçado, a especificação não é totalmente clara, e o pandas é poderoso, mas pesado e com alto nível de abstração, então às vezes um código Python simples é melhor
- Bell Labs era um ambiente de pesquisa onde trabalhos como Unix, yacc e ferramentas de preparação de documentos foram possíveis graças ao pensamento de longo prazo, colegas excelentes e baixa pressão por produto e receita
- Grandes modelos de linguagem são uma tecnologia que passou a ter enorme impacto de repente após novembro de 2022, e a experiência de Claude gerando quase corretamente código Python relacionado ao spaCy indica uma mudança na forma de trabalhar dos programadores
O ambiente de programação de 1999 e o objetivo do livro
- The Practice of Programming foi publicado cerca de 15 anos depois de The Unix Programming Environment, que Kernighan e Rob Pike haviam escrito juntos anteriormente
- O objetivo do livro era tratar de “como os programas são escritos na prática” e “como escrevê-los de forma eficaz e profissional”
- O ambiente de computação por volta de 1999 era muito diferente do atual
- A internet era algo relativamente novo para o grande público, surgindo por volta de 1995–1996
- Python era uma linguagem relativamente nova, Perl ainda era forte, e Java também era popular
- Exemplos específicos podem ser menos diretos para o leitor de hoje, mas ele considera que os princípios gerais podem ser transferidos para outros ambientes
- Os apresentadores consideraram que os capítulos sobre guia de estilo e depuração continuam especialmente atuais, e acharam interessante que a palavra “bug” já era usada antes da história do computador Mark de Grace Hopper, inclusive em contextos ligados a Thomas Edison e ao fonógrafo
CSV, pandas, memória e abstração
- Ao falar do exemplo de parser de CSV no livro, Kernighan diz que ainda hoje não existe um bom parser de CSV
- No verão passado, ao tentar adicionar suporte a CSV ao awk, ele passou de algumas semanas a cerca de um mês escrevendo “um parser de CSV de verdade”
- Ele considera que a especificação de CSV não é totalmente clara e, em certo sentido, não é realmente padronizada
- O pandas é visto como uma ferramenta pesada
- Em muitos casos, ele diz que é mais simples escrever Python diretamente do que entender os mecanismos implícitos de iteração e seleção do estilo pandas
- O apresentador comenta que pandas é frequentemente escolhido em trabalhos de machine learning e ciência de dados, mas que, quando desempenho de execução é importante, pensa em abordagens mais simples
- O gerenciamento de memória se tornou algo com que, em grande parte da programação atual, quase não é mais preciso se preocupar
- Em C, a memória precisa ser gerenciada manualmente, e isso é muito difícil
- Em C++ também é possível, mas aprender as técnicas para fazer isso corretamente é difícil
- Em Python, ele descreve a experiência como algo que funciona “como mágica” na maior parte do tempo
- Grandes abstrações nem sempre escondem completamente o problema
- Ao processar com spaCy um texto do tamanho de um livro, ele recebeu uma mensagem dizendo que faltava memória porque a cota padrão da tarefa era de 1GB; resolveu dobrando a configuração
- Na época em que Kernighan estava se formando, até kilobytes já eram uma grande quantidade de memória
- Na comunidade de sistemas embarcados, memória e desempenho ainda são tratados como questões muito importantes, e nesse contexto aparecem não só C, mas também linguagens como Rust e Zig
Go, Plan 9 e o ambiente de pesquisa do Bell Labs
- O apresentador diz que as preocupações de The Practice of Programming pareceram uma base para o projeto da linguagem Go
- Kernighan observa que Rob Pike foi um dos três criadores de Go e considera “totalmente plausível” que os incômodos discutidos no livro tenham servido de pano de fundo quando se pensou em uma nova linguagem mais tarde
- Ainda assim, ele diz não se lembrar especificamente de Pike pensando na época em “melhorar o mundo com uma nova linguagem”
- Ele considera que o trabalho com Plan 9 no fim dos anos 1990 e linguagens como Limbo e Alef fizeram parte da linhagem que levou a Go
- A experiência no Bell Labs foi, para Kernighan, algo próximo de um ambiente ideal
- Como aluno de pós-graduação em Princeton, trabalhou duas vezes como estagiário de verão no Bell Labs nos anos 1960, em um grupo ligado ao Multics
- Gostou tanto da experiência que, quando recebeu uma proposta para voltar, não fez entrevistas em nenhum outro lugar
- Ficou no Bell Labs do início de 1969 até por volta de 2000
- Naquele Bell Labs, era possível pensar no longo prazo, com pouca pressão por resultado trimestral ou por entregar produto e receita imediatos
- As pessoas podiam trabalhar com relativa independência naquilo que consideravam interessante e importante
- Como a AT&T fornecia serviço telefônico para a maior parte dos Estados Unidos, era um “ambiente cheio de problemas”, com muito trabalho que podia ser útil para o sistema telefônico
- Ele não conheceu Claude Shannon pessoalmente
- Lembra que Shannon havia saído para o MIT alguns anos antes de sua chegada ao Bell Labs
- Diz, porém, que conviveu bastante com Richard Hamming, que havia dividido escritório com Shannon
Aprendizado, escrita de livros e pensamento de programação
- O aprendizado inicial de Kernighan aconteceu ao ter contato com boas pessoas, boas ferramentas e problemas interessantes no Bell Labs
- yacc era uma ferramenta que facilitava criar novas linguagens de programação, e Kernighan a usou não só na geração tradicional de linguagens, mas também em áreas como preparação de documentos e linguagens declarativas
- Nesse processo, ele diz ter aprendido muito sobre projeto e implementação de linguagens
- Ele também manteve por muito tempo interesse em ferramentas de preparação de documentos
- Foi influenciado pelo runoff, um programa inicial de preparação interativa de texto do MIT
- Em Princeton, escreveu em Fortran um programa parecido para produzir sua própria tese
- No Bell Labs, criou ferramentas para facilitar fisicamente a produção de livros e para evitar que exemplos de programas fossem corrompidos no processo de publicação
- Depois de ir para a universidade, uma parte importante de seu aprendizado passou a ser explicar o que já sabia para alunos de fora da computação
- Precisava explicar a estudantes fortes em literatura ou música como funciona o sistema binário
- Diz que também aprendeu nesse processo que Leibniz foi o inventor efetivo do binário no fim do século XVII e que chegou a criar algo semelhante à notação hexadecimal usando notas musicais em vez de letras
- Ele afirma que a motivação para escrever um livro surge quando há “algo que vale a pena dizer” e “um coautor com quem vale a pena dizer isso”
- A maioria de seus livros foi escrita em coautoria
- Ele considera a colaboração muito mais fácil do que escrever sozinho, porque os autores conseguem complementar e lapidar o conteúdo um do outro
Grandes modelos de linguagem, educação e livros recomendados
- Kernighan cita como desenvolvimentos importantes em sua carreira os sistemas de time-sharing, o Unix, a evolução das linguagens de programação, o aumento de recursos trazido pela lei de Moore e o PC
- O time-sharing foi uma grande mudança porque permitiu trabalhar no próprio ritmo, sem estar fisicamente diante do computador nem esperar o processamento do operador
- Ele vê a computação em nuvem como algo que, em certo sentido, volta a se aproximar do time-sharing, já que o processamento é centralizado e o usuário possui periféricos sofisticados que se comunicam com sistemas distantes
- Entre as tecnologias atuais, ele aponta os grandes modelos de linguagem como as mais interessantes
- Considera notável o fato de terem surgido de repente por volta de novembro de 2022 e causado grande impacto em tão pouco tempo
- Conta que pediu ao Claude, em duas ou três frases, uma tarefa relacionada ao spaCy, e ele gerou código Python cerca de 99,9% correto, com uso de Python mais sofisticado do que o dele próprio
- Ele não acha que os programadores vão desaparecer, mas vê a possibilidade de mudança na forma de trabalhar
- Os LLMs também abrem novas possibilidades para os estudantes
- Um aluno considerou que poderia usá-los para melhorar a tradução de textos de grego antigo
- Ele diz que resultados de OCR de documentos impressos antigos do século XVIII também podem ser melhorados usando o conhecimento linguístico embutido nesses modelos
- Em suas aulas para não especialistas, ele tenta conectar o funcionamento dos computadores aos problemas tecnológicos que aparecem no mundo real
- Muitos alunos vêm de humanidades e ciências sociais e frequentemente cursam a disciplina para cumprir exigências de raciocínio quantitativo
- Ele aborda temas como hardware, software, comunicações, net neutrality, privacy, security e o caso antitruste do Google junto com a base técnica necessária
- Considera que o pensamento de programação, de dividir grandes problemas em partes menores e pensar passo a passo, pode ser levado para outras áreas, como escrever uma tese ou analisar questões jurídicas
- Para iniciantes, é importante encontrar algo que a própria pessoa queira fazer
- Começar por um problema de interesse, como criar jogos, melhorar as finanças pessoais ou analisar textos, pode reduzir a barreira psicológica
- Em aulas para não especialistas, ele usa uma atividade em que os alunos analisam Pride and Prejudice com NLTK e depois escolhem outro livro que queiram explorar da mesma forma
- Os livros recomendados e seus gostos de leitura são variados
- Entre os livros técnicos, ele às vezes revisita The Mythical Man-Month; acha que parte envelheceu bem, mas que certas expressões soam hoje muito sexistas
- Recoding America, de Jennifer Pahlka, é citado como um livro interessante sobre por que software de governo muitas vezes não funciona tão bem quanto se espera e por que os sistemas dificultam melhorias
- Entre leituras não técnicas, ele menciona história, história militar, romances policiais, os romances sobre corridas de cavalos de Dick Francis e Chip War, sobre semicondutores
1 comentários
Opiniões no Hacker News
Este livro é fundamental, então todo programador, especialmente iniciantes, deveria lê-lo.
Como é de se esperar de um livro do Kernighan, as frases são simples, concisas e precisas, e ele reúne só o essencial, sem enrolação, em pouco mais de 200 páginas. Depois de entender os princípios pelos exemplos, basta aplicá-los ao seu próprio contexto.
O ponto forte dos livros de K&P é que eles não esmagam o leitor com teoria; mostram a aplicação prática das técnicas e, depois disso, tornam o estudo da teoria mais acessível.
Por exemplo, eu já tinha experiência com programação de rede e implementação de protocolos quando li este livro, e foi uma revelação ver, no capítulo "Notations", uma rotina de pack/unpack de mensagens de rede que especificava o layout dos pacotes usando strings de formato no estilo
printf/scanf. Aprendi a força de uma boa notação e de pequenas linguagens, e há também trechos de código que mostram ideias de máquinas virtuais, code threading e compilação JIT.O livro mais antigo de Kernighan e Pike, "The Unix Programming Environment", também vale a leitura. O capítulo "Program Development" mostra, em cerca de 50 páginas, todo o processo de criar um compilador para uma pequena linguagem de calculadora usando ferramentas de desenvolvimento de compiladores; até onde sei, é o texto mais enxuto e simples sobre como escrever um compilador.
Em resumo, vale a pena comprar e estudar todos os livros do Kernighan.
Li o livro de C no passado e me lembro de a escrita ser excelente. Além de absorver bastante sabedoria de programação, quero também analisar, do ponto de vista da escrita técnica, por que os livros do Kernighan são tão bons.
Kernighan parece ter estudado bastante escrita, ou pelo menos pensado muito sobre escrita com raciocínio de primeiros princípios. O título "The Elements of Programming Style" também é uma referência ao famoso livro de escrita de Strunk e White, "The Elements of Style".
Pelos padrões atuais é um pouco datado, mas continua sendo um livro fácil de ler.
Não estou sendo sarcástico; quero entender por que ele é leitura obrigatória mesmo para alguém que está seguindo confortavelmente na carreira.
Gosto muito de "The Practice of Programming".
Entre os livros de programação que li até hoje, as lições deste foram as que mais ficaram comigo. Faz anos que não o releio, mas sinto que ele influencia minha prática diária.
Alguns dos exemplos concretos de programação estão bem datados, mas as ideias gerais continuam sólidas.
Gosto do Kernighan. Ele é uma pessoa realmente humilde.
Em um dos vídeos no YouTube, ele contou que, na tese de doutorado, estava resolvendo um problema difícil que depois se revelou ser um problema NP-completo antes de a teoria estar organizada.
Enviei um e-mail pedindo a tese e recebi uma resposta bem rápida; ao lê-la, achei realmente interessante.
Para mim e para muita gente, as ideias dele sobre programação estão entre as mais interessantes e úteis, em grande parte porque ele consegue comunicá-las com muita clareza.
Eu gostaria que as entrevistas hoje avaliassem a compreensão de conceitos presentes neste livro, em vez de LeetCode.
Neste novo mundo absurdo, até Brian Kernighan talvez não passasse em uma entrevista de LeetCode hard.
Eram todos problemas de programação bem práticos. Na Stripe, havia uma entrevista em que eles faziam um fork da biblioteca Java Jackson, inseriam um bug e pediam para encontrá-lo e corrigi-lo. Foi bem incomum, mas muito mais próximo do trabalho real de programação.
Também me lembra o caso de Katalin Karikó, vencedora do Nobel pelo mRNA, que foi rebaixada na UPenn por não conseguir atrair financiamento para pesquisa.
Outro autor que entra na mesma categoria excepcional de Kernighan e seus livros é Jon Bentley, com Programming Pearls e More Programming Pearls.
https://en.m.wikipedia.org/wiki/Jon_Bentley_(computer_scient...
Esse livro é útil para todos os programadores porque ensina a pensar sobre eficiência de cima para baixo, com foco em algoritmos e linguagens.
Livros modernos sobre eficiência, como os de Agner Fog e Fedor Pikus, tratam principalmente de técnicas de desempenho no nível de compilador/sistema operacional/processador; lidos em conjunto, ajudam a formar a visão completa.
pessoal, o g é mudo.
Seria bom trazer Rob Pike para participar. Ele provavelmente faria questão de corrigir a pronúncia. Já consigo até ouvir a voz dele.
Também quero muito trazer o Rob Pike. Estamos tentando, mas o contato é um pouco mais difícil.
Vi só cerca de um terço do vídeo, mas deu para perceber que os apresentadores fazem perguntas perspicazes muito bem
Sou o Carter, um dos apresentadores do vídeo. Fico feliz que estejam gostando. Foi realmente uma grande honra poder conversar com Brian Kernighan
Como esse formato trata de livros, acho que seria bom organizar, na descrição ou em alguns comentários, os livros abordados e, se possível, uma lista de mídias
Coloquei "The Bit Player" (documentário de 2018 sobre Claude Shannon) na minha lista para assistir, e também "Recoding America", "Chip War" e "Endurance: Shackleton's Incredible Voyage" na minha lista de leitura
Seria bom adicionar também Software Tools in Pascal, de Kernighan, à lista de livros a serem abordados no podcast
Tenho esse livro e acho que é bom
Kernighan e Plauger primeiro escreveram "Software Tools" em RATFOR, e depois escreveram "Software Tools in Pascal". E, como uma reação direta a essa experiência, Kernighan escreveu o artigo "Why Pascal Is Not My Favorite Programming Language"
Escrever em Pascal deveria ter sido muito mais fácil do que escrever em RATFOR, mas não foi, e Kernighan refletiu sobre o motivo disso
Ainda é um texto interessante e pode ser lido, por exemplo, aqui: https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pas...
Mas esse texto se refere originalmente ao Pascal padrão. Extensões como Turbo Pascal corrigiram muitos dos problemas. Só que, como ele disse, não havia portabilidade entre as extensões. Ainda assim, como o Turbo Pascal acabou virando a extensão "padrão" de fato, isso também se resolveu até certo ponto
Fiquei impressionado com as ideias e com a escrita, e isso serviu de ponto de partida para eu procurar e ler as outras principais obras de Kernighan
Kernighan também é coautor do livro The Go Programming Language, pelo menos na primeira edição