Роб Пайк (Rob Pike) — разработчик операционных систем и языков программирования, работавший c 1980 года в
Bell Labs, где работал в паре с
Кеном Томпсоном над графическим терминалом Blit для
Unix, и также позднее участвовал в создании операционных систем Plan 9 и Inferno. Один из создателей кодировки UTF-8.
Автор текстовых редакторов Sam и Acme.
В соавторстве с
Брайаном Керниганом написал книги:
«The Practice of Programming» («Практика программирования»),
«The UNIX Programming Environment» («UNIX. Программное окружение»).
Роб Пайк является гражданином Канады. В настоящее время работает в компании
Google, где участвует в создании языка программирования Go.
Цитаты
UNIX не только мёртв, но и пахнуть уже начинает действительно плохо (1991).
«Unix никогда не говорит `пожалуйста`.» («Unix never says `please.'») .
Ценный совет по программированию
Год или два, с момента начала работы в Bell Labs, я работал в паре с Кеном Томпсоном над интерактивным графическим языком, разработанным Джерардом Хольцманом. Я печатал быстрее, поэтому я сидел за клавиатурой, а Кен стоял позади меня. Мы работали быстро, и когда компилятор выдавал ошибку, я рефлективно начинал закапываться в проблему, изучая стек вызовов, вывод программы, запускал отладчик и так далее. Но Кен просто стоял рядом и думал, игнорируя меня и код, который мы только что написали. Вскоре я заметил закономерность: Кен зачастую понимал, в чем проблема, раньше меня и произносил: "Я знаю, что не так". Обычно он был прав. Я понял, что Кен выстраивал ментальную модель кода и, когда что-то ломалось, это была ошибка в модели. И думая о том, как эта проблема могла возникнуть, он выяснял, в каком месте модель была неверна или где наш код мог неправильно эту модель отразить.
Кен научил меня, что думать перед отладкой чрезвычайно важно. Если вы начинаете погружаться в ошибку, с большей вероятностью вы устраните локальную проблему в коде, но если вы сначала подумаете об ошибке, каким образом она могла возникнуть, вы найдете и исправите в коде ошибку более высокого уровня, что позволит улучшить архитектуру и предотвратить появление подобных ошибок в будущем.
Я понимаю, что это больше вопрос стиля. Некоторые настаивают на построчной отладке всего на свете специализированными инструментами. Но я теперь верю, что думать, не глядя в код, — это лучший инструмент отладки, потому что он ведет к лучшему программному обеспечению.
© greenmile
В начало
