Skip to content

Instantly share code, notes, and snippets.

@gabriel-fallen
Created November 26, 2014 14:49
Show Gist options
  • Save gabriel-fallen/042b05747725b6e49748 to your computer and use it in GitHub Desktop.
Save gabriel-fallen/042b05747725b6e49748 to your computer and use it in GitHub Desktop.
Articles vs. Programs

Статьи против Программ

На днях заметил, что читать статьи (по computer science) гораздо сложнее, чем читать/писать программы. Кажется парадоксальным, но вполне объяснимо — всё дело в пресловутом управлении сложностью.

Как известно, объём "кэша" у человека сильно ограничен — одновременно можно думать всего о 5-9 вещах. Может быть, некоторые могут думать об 11 вещах одновременно, но едва ли больше. Если учесть, что как правило нужно помнить не только отдельные объекты, но и связи между ними, то получится удержать в сознании всего 3 (+ 3 связи = 6) или 4 (+ 6 связей = 10) сущности.

При разработке программ (по крайней мере, когда я это делаю) количество сущностей, которые необходимо держать в голове, определяется программистом. Это называется "модульность" и "абстракция" — те самые средства управления сложностью. Например, если функция раздулась, так что объекты, которыми она манипулирует, и связи между ними перестали укладываться в голове, можно вынести часть работы в подфункции, абстрагировавшись таким образом от каких-то деталей обработки и начав думать в более высокоуровневых терминах, которых стало меньше и связи между которыми проще (мы специально определяем подфункции так, чтобы их было поменьше и связаны они были максимально простым образом). Не всегда такое преобразование легко осуществить, но так или иначе сам разработчик управляет этим процессом.

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

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

Почему нельзя переписать чужую статью? Во-первых, так не принято (по крайней мере, в западной академической культуре). Во-вторых, есть и принципиальный момент — откуда взять уверенность, что после переписывания статья выражает ту же самую мысль, что и до него?

На этом месте можно снова перевернуть медаль и спросить, откуда мы знаем, что чужой код после переписывания продолжает (или наконец-то начинает) работать правильно? По-хорошему, у нас должны быть инструменты проверки правильности: тесты, система типов, формальное доказательство корректности. Ну или по крайней мере мы можем "пройти" код пошагово в отладчике и убедиться, что он делает то, что требуется в терминах элементарных шагов или эффекта на систему (меняет нужные объекты требуемым образом и не меняет ничего лишнего).

Теперь же глядя на статьи можно с недоумением спросить, почему для них до сих пор нет никаких инструментов проверки правильности? Вообще-то, есть один — называется peer review. Так что верный вопрос — почему нет автоматических инструментов проверки правильности статей? Или почему статьи не являются выполнимыми (или вычислимыми) артефактами, которые сами проверяют свою правильность?

Честно говоря, для начала я бы согласился даже на меньшее — чтобы статьи были интерактивными артефактами, содержащими механику, необходимую для их понимания. Примерно об этом говорил Bret Victor и даже наглядно [продемонстрировал] 1.

Вообще, я считаю, что будущее статей (по computer science и математике, как минимум) — полная интеграция с системами автоматического доказательства теорем и/или формат наподобии [Wolfram CDF] 2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment