Coders at Work

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

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

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

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

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

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

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

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

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

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