Coders at Work

Языковые системы держатся на трех китах — язык, библиотеки и инструменты. Успешность языка зависит от сложного взаимодействия между этими тремя вещами. Python — отличный язык, у него отличные библиотеки и практически никаких инструментов.

Сейчас я считаю, что путь к ПО, которое с большей вероятностью будет делать то, чего мы от него хотим, лежит не через использование утверждений или индуктивных утверждений, а через использование более качественных, более мощных и глубоких декларативных систем обозначения.

Одна школа, которая, как мне кажется, весьма близка к воззрениям экстремального программирования, по сути говорит, что поскольку требования все равно постоянно меняются, не стоит ожидать от ПО долговечности. Если требования изменятся, вы создадите что-нибудь новое взамен. В этой мысли, на мой взгляд, есть определенная доля мудрости.

Требования всегда меняются, они всегда как минимум предпринимают попытку измениться в направлении, о котором ты даже не подозреваешь.

Конечно, у нас есть люди, прекрасно работающие на любом уровне и в любом возрасте. Дело в том, что надо держать в голове всю программу целиком, всю задачу, надо уметь концентрироваться. А это проще делать в молодости — лучше работают мозги или просто меньше отвлекаешься. Если есть семья, дети и так далее, просто нет возможности посвятить этому столько времени подряд, сколько нужно. Это да. С другой стороны, годы приносят опыт, и он отчасти уравнивает шансы: просто знаешь, что нужно делать.

Мне кажется, знать язык ассемблера уже необязательно. Нужно понимать архитектуру. Нужно понимать, что такое язык ассемблера, понимать, что есть иерархия памяти и что сбой в переходе с одного уровня на другой сильно отражается на работе программы. Но это понимание может быть и на абстрактном уровне.

Мне кажется, программы в высшей школе медленно адаптируются к реальности. Кое-где есть подвижки, но в целом работать в команде учат мало. Да и этому подходу со сборкой из готовых кусков тоже не особо учат. Однако ребята как-то набираются всего этого, так что в общем дело обстоит неплохо.

Работа в исследовательской сфере хороша еще и тем, что надо мной не стоит менеджер, которому нужен результат через неделю. Я могу спокойно сесть и подумать: «Здесь должен быть какой-то хороший выход».
Поэтому я много времени уделяю рефакторингу, вожусь с интерфейсами, создаю новые типы или полностью переписываю большие куски, чтобы их улучшить.

После трудной части — придумывания того, как это сделать, — вы думаете о том, как это выразить. И здесь транзакционная память — абсолютный чемпион. Она превосходит и блокировку, и переменные условия для выполнения параллельных программ.

Вероятно, для хорошей работы отладчики требуют еще больше циклов разработки. Но зато в итоге получается образцово полезная вещь.

Если вы хотите поменять кусок своего кода трехлетней давности — не подретушировать одну процедуру, а переписать коренным образом, — то системы типизации будут крайне полезны.

Сейчас мне кажется, что ленивые вычисления важны, так как позволяют сохранить чистоту. Я уже говорил об этом по другим поводам. Я люблю эти вычисления и, если есть выбор, всегда возьму ленивый язык. По-моему, они полезны в какой угодно области программирования.

С усложнением программных систем становится всё важнее справляться с последствиями неконтролируемых побочных эффектов, иметь больше гарантий корректности и лучше использовать параллелизм. Думаю, стрелка на шкале «цена-качество» постепенно смещается.

Главное оправдание для людей вроде меня, которые занимаются чисто функциональным программированием, состоит в том, что с ним связаны большие надежды. Программисты не обязательно пойдут именно по этой дороге, но с функциональным программированием связаны большие надежды. Песчаник императивного программирования выветривается, и под ним обнаруживается гранит функционального программирования.

Хороший Си-программист будет успешно работать и с Erlang, это очень надежный показатель. Есть, конечно, исключения, но умственные навыки, необходимые для работы с одним языком, можно применить и к другим.

Я люблю компактный код, хорошо сбалансированный и структурированный. Удаляешь одно, другое, и настает момент, когда удалить больше ничего нельзя — программа не будет работать. Вот в этот момент она прекрасна. Любое возможное изменение может ухудшить алгоритм, но сейчас он прекрасен.

Кто-то из компьютерных теоретиков сказал: «Если у вас плохо с английским, вы никогда не станете хорошим программистом».

В каком-то смысле написание документации — тоже забота о типах. Начинается со связки «есть». «Мелодия есть последовательность нот». Хорошо. Мелодия есть последовательность аккордов, каждый из которых является сочетанием нот равной длины. Простыми определениями терминов в документации — такое-то есть то-то — вы делаете своего рода анализ типов и декларативно размышляете о структурах данных.

Некоторые говорят: «Хотите знать, что делает программа? Читайте код». Думаю, это непрофессиональный подход. Код показывает мне, что программа делает, а не то, что она должна по идее делать. Код — это решение задачи. Если нет спецификации или какой-либо документации, приходится догадываться о задаче по решению. Догадка может быть неверной. Я хочу иметь объяснение — в чем состоит задача.