Что такое Тьюринговская трясина?
Это состояние, в котором программа становится столь могущественной, столь обобщенной, что усилия по решению с её помощью какой-либо конкретной задачи равны или превосходят затраты на написание с нуля программы, которая решает только данную задачу.
...
Здравствуйте, Lloyd, Вы писали:
L>Привет,
L>Интересная заметка на Хабре: L>
L>Что такое Тьюринговская трясина?
L>Это состояние, в котором программа становится столь могущественной, столь обобщенной, что усилия по решению с её помощью какой-либо конкретной задачи равны или превосходят затраты на написание с нуля программы, которая решает только данную задачу.
L>...
тот чувак, хотя и цепляет правильные вещи, но в конкретных суждениях неправ почти на 100%
начнем с того, что именно ругаемый им mplayer является примером хорошей архитектуры, а хвалимые им браузеры с их плагинами (полагаю, речь про фокс?) — говнокомбайны
все ключи командной строки mplayer-а относятся именно к процессу получения-воспроизведения видео; там решены почти все задачи, случающиеся на практике — в частности есть ключ, который позволяет открыть пайп и показывать поверх фильма *анимированное* лого, читаемое из пайпа
с другой стороны, рассмотрим задачу "выбрать правильное имя и папку для сохраняемого файла исходя из той страницы, на которой находилась ссылка, по которой кликнули для скачивания файла"
предположу, что для решения этой простой задачи потребуется изучение объема, примерно равного *всем* ключам мплеера (да еще и заталкивание собственного state-a в код) и вся эта плагинная архитектура тут не поможет
>Каждый мессенджер считаем своим долгом поддерживать все возможные протоколы связи, вплоть до электронной почты, социальных сетей, СМС, бумажных писем и отправки сообщений внеземным цивилизациям. Все операционки лезут на все типы устройств
L>Что такое Тьюринговская трясина? L>Это состояние, в котором программа становится столь могущественной, столь обобщенной, что усилия по решению с её помощью какой-либо конкретной задачи равны или превосходят затраты на написание с нуля программы, которая решает только данную задачу.
плохой дизайн и/или плохой язык программирования
к слову сказать, современные языки программирования не дают возможность создать хороший дизайн для любой задачи (программы), поэтому имеется шанс попасть в вышеупомянутую трясину
VE>Ну вот матан могущественен и обобщёнен. Мешает это ему решать конкретные задачи? VE>Или речь исключительно о программах?
хабр>Я частенько страдаю от желания пойти поплавать в этой трясине. Начинается всё с необходимости решить какую-то конкретную проблему. Я смотрю на существующие инструменты и вижу в каждом из них своих недостатки. И вот, забыв о первоначальной задаче, я уже набрасываю архитектуру универсального инструмента, который будет решать общий класс подобных задач, будет невероятно гибким, универсальными и…
и после "и…" выясняется, что
1. существующие языки программирования не подходят или подходят плохо
2. а разрабатывать новый язык (или расширения) надо отдельно от решения прикладной задачи
вывод из этого тот, что всем серьезным программистам надо документировать подобные ситуации, и публиковать их, акцентируя свои желания в области ЯП
Здравствуйте, m e, Вы писали:
ME>вывод из этого тот, что всем серьезным программистам надо документировать подобные ситуации, и публиковать их, акцентируя свои желания в области ЯП
Ну надо создавать место, где каждый мог бы бросить камень в текущий ЯП и выразить желание
Здравствуйте, Lloyd, Вы писали:
L>Интересная заметка на Хабре: L>
L>Что такое Тьюринговская трясина?
L>Это состояние, в котором программа становится столь могущественной, столь обобщенной, что усилия по решению с её помощью какой-либо конкретной задачи равны или превосходят затраты на написание с нуля программы, которая решает только данную задачу.
L>...
Чтото мне кажется что тему придется переносить в форум Немерле.
VE>Ну надо создавать место, где каждый мог бы бросить камень в текущий ЯП и выразить желание
кроме места необходимы еще и:
1. способ — у меня есть мысль сделать что-то не такое скучное как вики, но и не такое хаотичное, как форум (чем-то похожее на упрощенный google wave)
2. культура общения — люди не должны воспринимать кидания камнями в языки как личное оскорбление, и в то же время должны защищать языки в том случае, если считают камень брошенным несправедливо
Здравствуйте, m e, Вы писали:
ME>плохой дизайн и/или плохой язык программирования
Язык программирования тут только косвенно влияет.
Ну, то есть если мы рассматриваем только прикладные программы, то неважно, на каком языке они написаны.
Переводчик, имхо, не очень понял, о чём пишет автор.
Вот, скажем, примеры из жизни. Допустим, у нас есть электрическая почта. И мы, допустим, хотим автоматизировать некоторые рутинные действия.
Например, я хочу сделать так, чтобы когда я в отъезде, почтовый сервер автоматически всем отвечал, что меня нету, так что на скорый ответ рассчитывать не надо.
И я хочу, чтобы мои сослуживцы получали чуть больше информации, чем все остальные — скажем, я могу в ответе написать, что я поехал к такому-то перспективному клиенту.
Поскольку сам я этих писем не вижу, то легко забыть отключить эту штуку, когда я вернулся — поэтому я хочу заранее настраивать дату отключения.
Что делает матаноориентированный разработчик? Он видит систему "событие — ответ", которая покрывает широчайший класс сценариев.
Можно, к примеру, написать универсальный автоответчик, работающий по конфигурируемым пользователем правилам. Небольшое усилие — и язык описания правил становится тьюринг-полным, позволяя пользователю создавать настройки произвольной сложности.
Обратная сторона такого "решения" — то, что объём действий по конфигурированию этого "универсального всемогутора" становится сопоставим с объёмом программы специализированного почтового фильтра, написанной на традиционном ЯП.
Пользователеориентированный разработчик видит тут узкое семейство сценариев, и реализует только их, минимизируя потребные для этого усилия. См. например Microsoft Exchange / Outlook.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, m e, Вы писали:
S>Обратная сторона такого "решения" — то, что объём действий по конфигурированию этого "универсального всемогутора" становится сопоставим с объёмом программы специализированного почтового фильтра, написанной на традиционном ЯП.
То, что настраивать становится сложно, говорит наоборот не о матане, а о кривизне решения. Нередко эволюция пользователеориентированного решения, кстати.
В качестве иллюстрации
Пользователеоринетированный:
fact 0 = 1
fact n = n * fact (n - 1)
Матанориентированный
product = foldr1 (*)
enumFromTo f t = ...
factorial n = product [1..n]
Вот вроде бы система сложнее, умеет больше, но факториал посчитать всё так же просто.
И как раз пример матана нам показывает, как важно выделить независимые базисные вещи, а не подпирать один костыль другим, получая в итоге сотню взаимосвязанных классов.
Здравствуйте, VoidEx, Вы писали: VE>То, что настраивать становится сложно, говорит наоборот не о матане, а о кривизне решения.
Нередко эволюция пользователеориентированного решения, кстати.
В целом — да. Матаноориентированность просто позволяет встрять в трясину значительно быстрее. Пользователеориентированные решения растут медленно, т.к. мы добавляем по настройке на каждый сценарий, который у нас попросили.
Матаноориентированность — это попытка предотвратить затраты усилий на медленное сползание в трясину сползанием быстрым. То есть "пользователеориентированный" идиот каждый релиз добавляет поддержку очередной штуки типа "from начинается на...", "from заканчивается на...", "from в домене ...", "from в домене, начинающемся на ...", и так далее. Только потом он добавляет штуки типа "любое из двух вот этих условий" и "оба этих условия одновременно", достигая близости к ЧРФ (эквивалентных МТ).
Матаноориентированый идиот сразу делает "from матчит регексп ...", моментально достигая трясины Тьюринга и перекладывая геморрой по программированию на пользователя.
Понятно, что оба варианта чудовищно неудобны для выражения концепции типа "письмо от сотрудника моей же компании". Поэтому оба идиота — идиоты.
VE>Вот вроде бы система сложнее, умеет больше, но факториал посчитать всё так же просто.
Непонятно, почему первый — пользователеориентированный, и почему второй — матаноориентированный.
Оба варианта — матаноориентированные. В обоих пользователь вынужден сам описывать factorial. Если факториал доступен "из коробки", то это — пользователеориентированный вариант, и не шибко важно, как именно устроен факториал внутри.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Пользователеориентированный разработчик
Прочитав эти слова, вспомнил знакомого абсолютного пользователеориентированного разработчика. Он писал программы с UI, который выглядел как форма с кнопками вида:
[Функция для Иван Иваныча] [Опция для Семен Семеныча] и т.д. Жаль, скриншот не сохранил.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Sinclair, Вы писали:
S>Непонятно, почему первый — пользователеориентированный, и почему второй — матаноориентированный.
Потому что в первом реализован узкий сценарий — fact, а во втором широчайший класс сценарий, где fact — лишь частный случай.
И как видно, внутренне сложное устройство не мешает дать пользователю помимо широких возможностей ещё и простые кнопки для частых случаев.
S>Оба варианта — матаноориентированные. В обоих пользователь вынужден сам описывать factorial. Если факториал доступен "из коробки", то это — пользователеориентированный вариант, и не шибко важно, как именно устроен факториал внутри.
fact — это предоставляемая функция. Только в одном случае реализовали именно fact, во втором — сложную систему, а fact выразили в терминах этой системы.
> объём действий по конфигурированию этого "универсального всемогутора" становится сопоставим с объёмом программы специализированного почтового фильтра
Вернёмся к исходной фразе
Это состояние, в котором программа становится столь могущественной, столь обобщенной, что усилия по решению с её помощью какой-либо конкретной задачи равны или превосходят затраты на написание с нуля программы, которая решает только данную задачу.
Могущественная и обобщённая программа по сути определяет некий язык (DSL, язык конфигурирования системы, если угодно). То, что такой язык оказывается сложнее, чем другие, заслуга языкописателя, а не свойство любого DSL. Есть куча примеров, когда конфигурировать оказывается на порядки проще.
Вот есть у меня выбор, или решать задачу сразу на Си, или написать компилятор <подставьте свой любимый высокоуровневый язык> (тьюринг-полный язык, между прочим), и решать потом на нём.
В совокупности, конечно, второй вариант сложнее, но речь идёт о "решении с её помощью", т.е. сложность создания самой системы не включается в сравнение.
И таки что, правда на <подставьте свой любимый высокоуровневый язык> писать сложнее, чем на Си?
VE>fact — это предоставляемая функция. Только в одном случае реализовали именно fact, во втором — сложную систему, а fact выразили в терминах этой системы.
Тогда оба решения одинаковы. Отойдём от языков программирования в сторону "обычных" программ. Скажем, если в Excel есть функция Factorial(), то пользователю не очень важно, насколько красиво/сложно/ещё-как-то она устроена внутри.
VE>Могущественная и обобщённая программа по сути определяет некий язык (DSL, язык конфигурирования системы, если угодно). То, что такой язык оказывается сложнее, чем другие, заслуга языкописателя, а не свойство любого DSL. Есть куча примеров, когда конфигурировать оказывается на порядки проще.
Два соображения:
1. Философский вопрос: есть ли негативная корреляция между "тьюринг-полнотой" и "упрощением решения"? Если есть, то все упрощения достигаются ценой намеренного уменьшения выразительной мощности.
2. Автор статьи не исходит из предположения о том, что корреляция объективно существует. Он просто пишет о риске заменить решение пользовательской задачи решением "архитектурной" задачи, и при этом потерять решение пользовательской задачи. То есть в ваших терминах — иметь функцию foldR, забыв сделать собственно функцию fact.
VE>И таки что, правда на <подставьте свой любимый высокоуровневый язык> писать сложнее, чем на Си?
Ну, строго говоря, в оригинале было не "сложнее", а "не проще". И во многих случаях таки окажется не проще.
Вот, скажем, написать FFT на javascript сильно проще, чем на C?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Два соображения: S>1. Философский вопрос: есть ли негативная корреляция между "тьюринг-полнотой" и "упрощением решения"? Если есть, то все упрощения достигаются ценой намеренного уменьшения выразительной мощности.
Думаю, корреляция если и есть, то позитивная. На выразительном языке решение проще. Если есть какой-то простой DSL, то относительно своей области он наиболее выразителен (так как работает в терминах этой области).
S>2. Автор статьи не исходит из предположения о том, что корреляция объективно существует. Он просто пишет о риске заменить решение пользовательской задачи решением "архитектурной" задачи, и при этом потерять решение пользовательской задачи. То есть в ваших терминах — иметь функцию foldR, забыв сделать собственно функцию fact.
Ну, автор мог бы тогда написать и более общо: решение одной задачи вместо другой. И исходная задача оказывается не решена. Весьма распространённое явление. Удивительное дело.
VE>>И таки что, правда на <подставьте свой любимый высокоуровневый язык> писать сложнее, чем на Си? S>Ну, строго говоря, в оригинале было не "сложнее", а "не проще". И во многих случаях таки окажется не проще.
Я ссылался на перевод, где написано "равны или превосходят".
S>Вот, скажем, написать FFT на javascript сильно проще, чем на C?
Я смотрю на существующие инструменты и вижу в каждом из них своих недостатки. И вот, забыв о первоначальной задаче, я уже набрасываю архитектуру универсального инструмента, который будет решать общий класс подобных задач, будет невероятно гибким, универсальными и…
FFT не входит в общий класс каких-то задач, для решения которых предназначен javascript.
Обратные примеры (когда задача подходит под язык), я думаю, вы сможете придумать сами и согласитесь, что на C их написать куда сложнее.
Здравствуйте, VoidEx, Вы писали:
VE>Думаю, корреляция если и есть, то позитивная. На выразительном языке решение проще. Если есть какой-то простой DSL, то относительно своей области он наиболее выразителен (так как работает в терминах этой области).
Речь идёт про "тьюринг-полноту", т.е. выразительность за пределами своей области.
VE>Ну, автор мог бы тогда написать и более общо: решение одной задачи вместо другой. И исходная задача оказывается не решена. Весьма распространённое явление. Удивительное дело.
VE>Я ссылался на перевод, где написано "равны или превосходят".
Именно. Обратите внимание на выделенное. S>>Вот, скажем, написать FFT на javascript сильно проще, чем на C?
VE>FFT не входит в общий класс каких-то задач, для решения которых предназначен javascript.
Значит, это VE>Обратные примеры (когда задача подходит под язык), я думаю, вы сможете придумать сами и согласитесь, что на C их написать куда сложнее.
Всё зависит. Вот, скажем, есть задача мигрировать данные из одной реляционной базы в другую. И под эти задачи пишется тул, который конфигурируется на некоем DSL, который, конечно же, построен на XML, и делается развесистый UI-редактор с сотней диалогов.
Тул — абсолютно всемогущий, т.к. включает в себя тьюринг-полный язык описания трансформаций одного в другое, плюс отдельный событийно-ориентированный движок для обработки случаев типа "в целевой таблице нашлась конфликтующая запись", "в целевой таблице не нашлось записей для обновления".
В итоге, есть значительный риск нарваться на ситуацию, в которой объём XML, потребный для переливания таблицы X из базы A в базу B, превышает объём C-кода, который делает то же самое. Кроме того, в С-коде я могу делать внешние вызовы произвольных библиотек, а в туле я вынужден писать всё сам, т.к. у него нет возможностей расширения.
И если мне нужно при переливании сконвертировать, скажем, GUID из бинарного представления в текстовое, решение на C запросто может оказаться даже проще.
Ну и понятно, что проще всего вообще выполнить всё это одним SQL-запросом, если архитектура используемой СУБД позволяет обратиться к исходной таблице.
Потому, что SQL разрабатывался не из соображений математической полноты, а из соображений применимости к практическим, конкретным задачам.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
VE>>Я ссылался на перевод, где написано "равны или превосходят". S>Именно. Обратите внимание на выделенное.
Пардон, я почему-то прочёл "проще".
S>Всё зависит. Вот, скажем, есть задача мигрировать данные из одной реляционной базы в другую. И под эти задачи пишется тул, который конфигурируется на некоем DSL, который, конечно же, построен на XML, и делается развесистый UI-редактор с сотней диалогов. S>Тул — абсолютно всемогущий, т.к. включает в себя тьюринг-полный язык описания трансформаций одного в другое, плюс отдельный событийно-ориентированный движок для обработки случаев типа "в целевой таблице нашлась конфликтующая запись", "в целевой таблице не нашлось записей для обновления". S>В итоге, есть значительный риск нарваться на ситуацию, в которой объём XML, потребный для переливания таблицы X из базы A в базу B, превышает объём C-кода, который делает то же самое. Кроме того, в С-коде я могу делать внешние вызовы произвольных библиотек, а в туле я вынужден писать всё сам, т.к. у него нет возможностей расширения. S>И если мне нужно при переливании сконвертировать, скажем, GUID из бинарного представления в текстовое, решение на C запросто может оказаться даже проще.
Ну, я вроде не подвергал сомнению возможность написать ужасающе кривой тул. Чего стоит "DSL, который, конечно же, построен на XML".
S>Ну и понятно, что проще всего вообще выполнить всё это одним SQL-запросом, если архитектура используемой СУБД позволяет обратиться к исходной таблице. S>Потому, что SQL разрабатывался не из соображений математической полноты, а из соображений применимости к практическим, конкретным задачам.
Как раз SQL — это матан. Потому и применим практически.
А вот пример выше — это как раз наугад собранный паровоз из костылей без модели.
