Пользователь
115,4
рейтинг
7 марта 2012 в 12:14

Разработка → Тьюринговская трясина перевод

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

Что такое Тьюринговская трясина? Это состояние, в котором программа становится столь могущественной, столь обобщенной, что усилия по решению с её помощью какой-либо конкретной задачи равны или превосходят затраты на написание с нуля программы, которая решает только данную задачу.

Я частенько страдаю от желания пойти поплавать в этой трясине. Начинается всё с необходимости решить какую-то конкретную проблему. Я смотрю на существующие инструменты и вижу в каждом из них своих недостатки. И вот, забыв о первоначальной задаче, я уже набрасываю архитектуру универсального инструмента, который будет решать общий класс подобных задач, будет невероятно гибким, универсальными и… Особенно опасна эта трясина для создателей языков программирования. Есть огромный соблазн урезать язык до супер-элегантного и общего функционала, способного (в теории) решить любую задачу.

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

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

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

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

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

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

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

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


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

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

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (42)

  • 0
    Написание API это возврат к трясине, и снова все по кругу
    • –6
      TDD помогает держать API в узде.
    • 0
      Если API не релизить, то можно тихонько закопать, пока никто не видел.
  • +1
    Сижу пишу класс. Понял, что я в трясине.
    Так, не заниматься самобичеванием, не заниматься…
  • +13
    Есть чувство, что автор статьи немного уклонился от темы. Тьюринговская трясина — это о языках и вычислимости. Другими словами, есть много «языков», на которых можно реализовать все, что и на обычном языке программирования типа С. Строго говоря — тьюринг-полных языков. Но делать это непрактично, хотя иногда и интересно.

    Хороший пример — брейнфак.
    Еще один пример — клеточный автомат, та же игра «жизнь». Выставляя определенным образом значения на поле мы можем просчитать любую (вычислимую) функцию.

    Но решать с помощью этого практические задачи нет смысла.
    • +6
      Точно. Мне в качестве примера трясины больше нравится sendmail — где конфиг это настоящий язык программирования, оперирующий на самом низком уровне обработки почты. В результате пользоваться им (языком конфигурации) практически невозможно, поэтому пришлось сочинять надстройку на макропроцессоре m4 для создания конфигураций.
      • +1
        Да вы садомазохист =)
        • 0
          Отнюдь. Лично я давно пользуюсь postfix-ом. Просто еще помню sendmail по началу нулевых.
  • +5
    Естественно, что разработчики платного софта пытаются получить преимущества перед конкурентами.
    Недавно искал простую, казалось бы, программу для наложения водяных знаков на фотографии.
    Их десятки, сотни. Большинство из них платные. Так вот в платных чего только нет. Навороченные редакторы водяных знаков, с какими то супер пупер градиентами и прочими плюшками. Стоит это все 99$ pro лицензии.
    Среди всех программ не нашел ни одной, которая мне подходила.
    Мог бы за пару часов в фотошопе решить эту задачу, но сел за написание программы. Ушло три дня (включая написание документации, официальной страницы программы), и первоначальную задачу решил за 10 минут. Теперь зато есть новая и уникальная бесплатная программа )
    • +3
      > Теперь зато есть новая и уникальная бесплатная программа

      Респекты вам за это, но можно плз в двух словах пояснить в чем киллер-фича (и кстати ссылка на упомянутую страницу была бы очень кстати :)), т.е. почему не подошло например вот такое решение:

      www.imagemagick.org/Usage/annotating/#wmark_image
      • +2
        Допустим, нам надо поставить ватермарк на 50 фотографий. Подобрав положение и размер для первой фотографии, на второй он может уже не так смотреться. Для первой фотографии снизу слева, для второй сверху слева и повернутый на 90 грудусов, на третьей должен быть инвертирован (белый на темной фотографии или черный на белой фотографии). Плюс фотографии могут иметь разный размер, и водяной знак должен быть пропорционален.
        101watermark.igor-k.ru (осталось пару недоделок, к вечеру будут исходники. Написано на python).
        Программа позволяет все это сделать быстро и пакетно, предусмотрены хоткеи.
        • 0
          ссылка на исходники не работает (404)
          • 0
            Ну я же написал, исходники выложу вечером.
            Да и нет там ничего интересного, так, новичкам поучиться по мелочам)
            • 0
              Мне просто хотелось бы под linux запустить.
              • 0
                Запустите, обещаю, и даже работать будет)
                Правда GUI страшноватое получается ((
            • 0
              Забирайте. Специально для Вас протестил под Ubuntu (чуть чуть подправить пришлось платформоспецифичные мелочи).
              Для работы нужен python>=2.6, пакеты python-tk,python-ttk,python-imaging,python-imagingtk
        • +5
          Отлично! Теперь добавьте список с вотерматками, чтобы можно было на лету выбирать: иногда я использую просто инициалы, иногда полное написание Гельветикой, а иногда с Бодони. Эффекты для вотермарков, рамочки и сепию. И продавайте по $99.
      • +4
        Сам люблю для себя все автоматизировать с помощью скриптов. Бывает написать что то самому быстрее, чем найти готовое решение.
    • 0
      Так а где она?
      • 0
        Чуть выше смотрите
  • +1
    Забавно. Столько раз сталкивался с такой ситуацией и даже не знал, что у нее есть официальное название. Спасибо за ликбез.
  • +6
    «Я думаю, язык программирования должен быть большей частью самоопределяем. Спецификация языка должна быть разделена на 2 части: небольшое ядро операторов (которые выполняют роль аксиом) и остальная часть языка, которая, как теоремы, определяется в терминах аксиом.»
    FORTH.
    • +5
      Или LISP.
    • +1
      Пол Грэм же! Известный евангелист лиспа.
  • 0
    Вот многие задумались о том, что сами когда-то рождали монстров на языке программирования.
    Но на самом деле все дело в мышлении человека и его «запасливости». Все делается с запасом на будущее — а будущее часто поворачивает в такую сторону, в которую люди и не могли подозревать.
    • +1
      Для этого как раз и нужны архитекторы и менеджеры по развитию, которые определят, какая фича может потребоваться в будущем и станет конкурентным преимуществом, а какая сожрет кучу времени на разработке, но станет «приятным дополнением».
  • +3
    комментарий не в тему. Речь шла не про bloatware, а про инструменты программистов.

    А вообще, да, есть такое.
    • 0
      +1. Переводчику лучше было промолчать в конце :) Как в известной поговорке
      • 0
        Вы абсолютно правы, иногда лучше промолчать.
  • +63
    Напомнило историю:

    Шел рыцарь по пустыне. Долгим был его путь. По пути он потерял коня, шлем и доспехи. Остался только меч.

    Рыцарь был голоден, и его мучила жажда. Вдруг вдалеке он увидел озеро.

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

    И тогда из последних сил дракон спросил:
    — Рыцарь, а ты чего хотел-то?
    — Воды попить.
    — Ну, так и пил бы…
  • +2
    Это не обобщённость и могущественность, а переусложнённость.
    Обобщённость и могущественность — это математика.
  • +6
    Программа, которая делает все и ничего:
    void*MegaFunction(void*(*f)(void*),void*arg)
    {
    return f(a);
    }



    Да, я как-то почти до такого докатился :)
    • 0
      Одной мало! Надо 3!

      def identity[A](x: A): A = x
      def implicitly[T](implicit e: T) = e
      @inline def locally[T](x: T): T = x

      Это не бесполезный код. Это функции импортируемые по умолчанию в любой исходник на scala.

      lampsvn.epfl.ch/trac/scala/browser/scala/tags/R_2_9_1_final/src//library/scala/Predef.scala
    • 0
      Похоже на большинство видимых мной «посетителей».
    • +1
      Не скомпилится ;)
      • +1
        Как говорил один мой преподаватель, когда ему указывали на ошибку на доске: «Не пропечаталось!».
  • +1
    А я не жалею о нашей трясине.
    Мы пишем крутую универсальную библиотеку (этим у нас занимаются двое), которой пользуется вся остальная команда уже в котором по счету проекте. Уже сколько лет. Иногда трясина — это хорошо. Сы придумали новые подходы. Мы облегчили себе жизнь. Мы сэкономили тысячи строк кода.
  • 0
    Меня частенько в неё затягивает.
    Вот пишу программу по наиболее правильной схеме библиотека -> интерфейс к ней.
    И постепенно библиотека превращается в фреймворк и библиотеку, построенную на этом фреймворке.
    В погоне за универсальностью переделывается архитектура.

    В результате срыв сроков, гейзенбаги и прочие неприятности.
  • +10
    Как-то на RSDN пробегала картинка в тему:
    image

    :)
  • 0
    в emacs есть команда для этого
    xkcd.com/378/
  • +3
    Круто.

    Теперь я знаю, как называется моя неизлечимая болезнь.
  • +5
    Начали за здравие, закончили за упокой.
    Тьюринговская трясина, идеально гибкая программа и добавление лишних функций – это точно ОДНА тема?

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