Разработка / [Перевод] Тьюринговская трясина

Бойтесь Тьюринговской трясины, в которой всё возможно, но ничего конкретного нельзя сделать просто.
Алан Перлис

Что такое Тьюринговская трясина? Это состояние, в котором программа становится столь могущественной, столь обобщенной, что усилия по решению с её помощью какой-либо конкретной задачи равны или превосходят затраты на написание с нуля программы, которая решает только данную задачу.
<a rel="nofollow" name="habracut">
Я частенько страдаю от желания пойти поплавать в этой трясине. Начинается всё с необходимости решить какую-то конкретную проблему. Я смотрю на существующие инструменты и вижу в каждом из них своих недостатки. И вот, забыв о первоначальной задаче, я уже набрасываю архитектуру универсального инструмента, который будет решать общий класс подобных задач, будет невероятно гибким, универсальными и… Особенно опасна эта трясина для создателей языков программирования. Есть огромный соблазн урезать язык до супер-элегантного и общего функционала, способного (в теории) решить любую задачу.

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

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

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

В программировании всё, что мы делаем, является всего-лишь частным случаем более общей проблемы. И иногда мы осознаём это слишком быстро.
Алан Перлис

Попытка понять отношение вашей конкретной проблемы и общего класса подобных проблем может действительно помочь увидеть некоторые скрытые ранее детали. Порой вы вполне можете найти пару поводов крикнуть «Эврика!» — и это прекрасные моменты. Таким образом, я верю, что в идеальном случае вы должны быть всегда готовы пройтись по краю Тьюринговской трясины, но в то же время иметь железную силу воли, чтобы не свалиться в неё. Лично у меня подобной силы воли нет, и, что еще хуже, есть огромное любопытство. Для хоть какой-то борьбы с этим всем я придумал ряд эвристик по определению края трясины:

• Помните мысль Алана Кэя: «Мы стараемся сделать простые вещи простыми, а сложные — возможными». Когда решение общей задачи делает сложные вещи возможными — это хорошо. Но не ценой потери простоты простых вещей.
• Сколь бы высоко вы не летали в облаках теории, время от времени спускайтесь на грешную землю. Лично я всегда имею в наличии определенное количество пожеланий пользователей и регулярно возвращаюсь к ним с вопросом «а поможет ли этот восхитительный виджет решить вот эту банальную практическую проблему?».
• Не занимайтесь самобичеванием, когда вдруг обнаружите, что всё-таки погрязли в трясине. Даже если Вы начали решать проблему А и вдруг обнаружили себя решающим общий класс задач С, который даже не включает А, снова вспомните Алана Кэя: «Успешная технология создаёт проблемы, которые только она и может решить». Не будьте сразу уверенными в том, что создали что-то ненужное. Если осталось немного — закончите и посмотрите, что вышло. Вы никогда не узнаете, полезная ли получилась штука, пока не начнёте пользоваться.

Уверены ли вы, что все эти свистелки и дуделки, все эти восхитительные средства, составляющие ваш «мощный язык программирования», на самом деле являются частью решения проблемы, а не частью самой проблемы?
Эдсгер Дейкстра

Комментарий переводчика

Тьюринговская трясина на самом деле встречается чаще, чем кажется. И ладно бы в неё затягивало лишь великие академические умы, решающие задачи вселенского масштаба. Но нет — универсальные инструменты стараются создавать все! Каждая программа по записи DVD зачем-то обзаводится своими аудиовидеофото-редакторами, средствами создания обложек, плеерами и конверторами. Каждый мессенджер считаем своим долгом поддерживать все возможные протоколы связи, вплоть до электронной почты, социальных сетей, СМС, бумажных писем и отправки сообщений внеземным цивилизациям. Все операционки лезут на все типы устройств, каждый кодек-пак включает в себя тонну хлама, документация на некоторые консольные программы имеет по 150 страниц формата А4 и пару тысяч ключей командной строки. Каждый второй сайт в интернете обрастает мхом из погодыгороскоповзнакомствработычатовфорумов. Стараясь привлечь лишнего пользователя новой фичей, программы и сайты теряют десяток других, которые заколебались выискивать в образовавшейся куче хлама то рациональное зерно, ради которого когда-то эта программа или сайт были выбраны.

Серебряных пуль нет. Лично мне единственным способом не скатится из полезного узконаправленного средства в разрозненный набор малофункциональной чуши кажется система плагинов. Хорошими примерами являются современные браузеры, некоторые онлайн-игры, IDE и другие модульные программы (я уверен — вы сможете дополнить список), которые, оставаясь весьма аскетичными в своей основе, дают тем не менее возможность сотворить боевой комбайн любого уровня сложности.
Перед тем как добавить в свою программу новую фичу — подумайте, а нужна ли она хотя бы четверти пользователей? Если нет — может быть стоит просто вывести наружу API и дать возможность желающим написать и подключить плагин?

Автор: tangro