Защита от Злого гения Декарта

Которой не существует. Но все таки я его нашёл!

Понятие

Регулярно как минимум в инженерной среде при проектировании (а точнее, при валидации) чего-нибудь складывается следующая ситуация. Разработчики придумывают какое-нибудь решение, а критики вокруг начинают придумывать разные идеи по поводу того, «а что будет если …». Изначально предлагаются осмысленные варианты поведения (здравомыслящие и логические), далее идет рассмотрение крайних случаев, потом идут какие-либо безобидные ситуации (как некорректный ввод пользователя), но в дальнейшем начинается нечто более серьезное. Что будет если закончится место на диске? Как разруливать ситуацию, если мы имеем нагрузку X, а нам дадут 10*X? А если задача зависнет? Однако, на этом дело не заканчивается. Идут вопросы о том, что делать если сыпется диск? А что если CPU будет не успевать? А если откажет таймер и часы переведутся? А если выйдет из строя тактовый генератор процессора? … где-то в конце этого списка молния попадает в компьютер, но он все равно должен выжить и выполнить боевую задачу.

В литературе по отказоустойчивым системам (fault-tolerance systems) между строк и сквозь все пронзает мысль о том, что нельзя построить систему, которая была бы оказоустойчивая и безопасная ко всему. Только сейчас в статье Marco Schneider'a нашел понятие того, кто пытается любыми способами сломать систему и с фактом того, что всегда есть возможность ему это сделать. То есть, если мы рассматриваем действующую систему, то мы можем находясь извне всегда придумать такую ситуацию, чтобы эту систему сломать, т.е. сделать так, чтобы она перестала функционировать. В статье такая роль называется malicious adversary или evil demon, последнее из которых — Злой гений Декарта.

Опытные и неопытные разработчики

Уровень 1. Новички в инженерии совершенно лишены тормозов и не знают о том, что вообще этот Злой гений существует. В связи с этим то, что они хотят сделать, они реализуют быстро, как придется и так, чтобы работало (классический Cowboy). У них нет в сознании множества граблей, на которые можно наступить. Нужно отправить e-mail? Где процедура… какие параметры? … сейчас подставим и всё! Готово! (пора рапортавать менеджерам о своей высокоэффективности). Однако то, что SMTP-сервер может быть не доступен, не обрабатывается. Письмо может не влезть в ящик, e-mail совсем не e-mail, пароль захордкожен и в открытом виде, бесконечный запрос отправки вешает всю систему, а ошибки сервера забыты, и это далеко не полный список.

Уровень 2. Более опытные разработчики имеют карту местности с множеством граблей, и отлично понимают, что наступить на новые, или на старые, можно в любой момент. Злой гений Декарта присутствует, но он есть интуитивно: уровень проработанности определяется на глазок, по срокам и ресурсам, а те, кто будет аргументировать методом «а что, если молния в компьютер?», будет мягко говоря, проигнорирован. Но даже для весьма опытных специалистов вопросы Злого гения ставят в тупик. Я несколько раз наблюдал ситуацию, когда в кругу матёрых инженеров (один пример на IT-конференции, второй в обществе специалистов по отказоустойчивым системам, третий в общении программистов со стажем порядка 10 лет) имел место диалог вида:

— Вот вы столько всего рассказали, все так интересно, но все равно ваша система не сможет спасти от всего?

— Да, не сможет.(с виноватым видом без акцента на то, что так вообще-то не сможет любая система)

Такой вот универсальный троллинг 2-го уровня.

Уровень 3. Понимание того, что Злой гений Декарта есть, универсальной защиты от него нет, но с ним можно бороться. А тот, кто предлагает универсальные способы решения — алхимик современности.

А как бы вы решали проблему защиты от Злого гения Декарта?

Мне известны два широкополосных способа, позволяющие эффективно решать данную проблему.

Решение 1: На основе анализа предыдущего опыта

В качестве иллюстрации данного способа решения мне нравится пример Титаника (его же и не только использует Leveson в своих статьях и книгах).

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

Ключевым в данной истории является то, что для решения проблемы непотопляемости был проанализирован исторический опыт и имеющиеся технические возможности, в соответствии с которыми стало возможно ликвидировать на каком-то уровне все опасности, которые угрожали кораблям-предшественникам. Это так называемый Hazard Analysis, используемый сейчас во всех западных системах, критичных к безопасности. Но подобного рода анализ для всех разрабатываемых систем ещё не пришел (дорогое удовольствие).

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

Решение 2: Вероятностная защита

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

Классическими иллюстрациями для этого могут служить криптостойкость ключа при шифровании и контроль CRC в обычных системах (при передаче данных или например для проверки на сбои в памяти).

В настоящее время практически любой крипто-ключ (кроме одноразовых паролей) может быть взломан перебором, но проблема в том, что перебирать придется долго или затратно. Особенность также в том, что если не перебирать полностью, а только малую часть, то существует вероятность того, что мы сможем наткнуться на правильный ключ. Но защищающихся ключом успокаивает то, что данная вероятность очень мала.

Если используем простейший CRC, то он позволяет также сделать так, что проявление сбоя будет замечено с высокой вероятностью, и не замечено — с пренебрежимо малой. Мы не защищаемся от всех сбоев, но зато защита идет от абсолютного большинства из них. И, если например CRC32, то следует помнить, что в случае сбоя если один из TCP/IP пакетов или запакованных архивов будет распакован или разобран в битом виде, при этом с вероятностью 2^-32 мы этого не заметим и никто нам об этом не скажет.

Здесь Злой гений Декарта есть, и полностью победить его невозможно, но он для победы должен быть достаточно мощен, чтобы перебрать ключ или достаточно удачлив, чтобы пройти через CRC.

Завершение

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

Сами же описанные решения не универсальны. Вероятности работают только там, где работает математика (при наличии системы аксиом), а зачастую может быть и так, что опыта нет и анализ провести не на чем.

Фальсифицируемость спецификаций

— Какие могут быть формальности между друзьями! Вася, сделай мне программу сортировки.
— А что такое сортировка?
— Мне надо, чтобы я вводил любые числа, а программа выдавала упорядоченные числа.

(через неделю)

— Ты что, Вася! Я ввожу 5 4 7 6, а твоя программа выдает 1 2 8 9.
— Так бы и сказал, что она должна использовать введенные числа.

(через неделю)

— Ты что, Вася! Я ввожу 5 4 7 6, а она выдает 4 5 6.
— Так бы и сказал, что все числа должны присутствовать.

(через неделю)

— Ты что, Вася! Я ввожу 5 4 7 6, а она выдает 4 5 6 7 и 8 и 9.
— Я выдал все, а от себя добавил, по дружбе, чтобы ты от меня отстал, наконец.

(через неделю)

— Ты что, Вася! Я ввожу 5.4 и 7.6, а она даже два числа отказывается сортировать.
— А откуда я знал, что тебе не только целые надо сортировать? Может тебе завтра взбредет комплексные сортировать?! Последний раз!!!

(через неделю)

— Ты что, Вася! Программа больше девяти чисел не сортирует…

© Конспект лекций для Светы

---

Фальсифицируемость

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

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

Иллюстрация первая: классическая (в качестве введения)

Приходит заказчик и говорит: «Я хочу программу, и чтобы она работала». Переводя с пользовательского на народный это означает: «У меня есть проблема, и я хочу, чтобы её не было. Разберитесь пожалуйста, что это у меня за такая проблема, и решите её, и чтобы у меня её не было. А что за проблема я знать не знаю и знать не желаю.»

Иллюстрация вторая: недавняя

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

WTF?? С каких это пор можно сделать систему, которая решает любую проблему и приспосабливается к любой ситуации?? Для меня вышенаписанное это звучит как: «Мы вас просили спроектировать непотопляемый корабль. А то, что сделали вы, утонуло после первого попадания ядерной боеголовки».

Удобные спецификации

«Так, вам задание. Система должна работать быстро. Отвечать на запросы — как можно быстрее. И не занимать много памяти. И, ещё, это…, проект должен быть готов чем скорее, тем лучше. »

Сделать универсальную систему невозможно, нужно оптимизировать по каким-либо параметрам. Но кроме этого, здесь следующее: такая формулировка очень удобна. Если вдруг окажется, что система тормозит, то всегда можно сказать «Мы же просили сделать так, чтобы система работала быстро! Почему не сделали?». «Медленно отвечает? Мы говорили вам!» …

Но с другой стороны: «Система вообще-то работает быстро. Может не так быстро, как хотелось бы, но это быстро!»

В результате никто ни в чем не виноват и никому ничего не должен.

Исторический пример неточных требований

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

В спецификации было указано следующее:

“Shut off the pumps if the water level remains above 100 meters for more than 4 seconds.”

“Выключите насос в случае, если уровень воды остается выше 100 метров в течение более чем 4-х секунд.”

Как бы вы проверяли программно эту ситуацию? Т.е. какая математическая формула выдавала бы ответ о том, нужно выключать насос или нет.

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

1. Среднее арифметическое за последние 4 секунды больше 100 м.
2. Среднее между минимумом и максимум за последние 4 секунды больше 100 м.
3. Среднее квадратическое за последние 4 секунды больше 100 м.

В дальнейшем оказалось, что разработчики использовали 4-ю интерпретацию, отличную от 3-х предложенных: вычисление минимального уровня воды и сравнение его с 100 м. Кроме того, что это неоднозначно, это была самая опасная из 4-х формулировок, так как кратковременный высокий уровень воды может привести к серьезным проблемам на станции, а последняя из формулировок оставит этот факт незамеченным.

Таким образом, чтобы требования были проверяемы, нужна их точная математическая формулировка. Если требования сделаны на естественном языке, то это приводит к множеству различных противоречивых толкований, и в том числе к ошибкам и проблемам.

Необходимость фальсификации

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

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

Таки образом, для каждой из спецификаций должны быть описаны конкретные условия проверки (что проверяется, условия, обстоятельства и т.д.; полная постановка эксперимента (теста) ). Иначе они трактуются как попало и не работают.

Позитивные сдвиги

К таким сигналам отношу следующее. В последнее время несколько раз встречал из различных источников (внутренние правила компании по качеству; слова умных людей; методологии в IT), что: в разработке необходимо 100%-е покрытие тестами; если вы не можете проверить тестами, то и не реализуйте — практически наверняка есть проблема на предыдущих этапах.

Вывод

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

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

Истец, судья и адвокат дьявола

Критика и Адвокат дьявола

Давным давно, лет 15 назад, когда вокруг было много идей, я понял, что все разные, и для практического результата пришел к заключению, что та идея более ценна, которая лучше выдерживает критику. Утверждение очень простое и может не совсем очевидное, но внедрение такого критического мировоззрения привело к тому, что любая идея, пытающаяся достучаться до моего сознания (как извне так и снаружи), подвергалась жесткой бомбардировке, и, соответственно, выживали немногие.

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

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

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

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

Переключение между ролями

Последующим открытием через несколько лет стало то, что очень сложно переключаться между ролями. Как мне кажется, это связано с нашей эмоциональной биохимией. Мы плохо критикуем идею, если только что были Истцом. Аналогично у нас не получается хорошо защищаться, если мы только что были Адвокатом Дьявола. Это утверждение также истинно для третьей роли, которая будет рассмотрена ниже.

По моему опыту, хорошо время на переключение делать где-то минимум в 5-6 минут. За это время — очистить эмоциональный фон и оперативную память. Слишком частые переключения череповаты.

Третья роль

В последнее время окончательно вырисовалась третья роль, в корне отличающаяся от двух, описанных выше.

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

Таким образом, решение о факте и необходимости применения лежит вне компетенции Истца и Адвоката дьявола, и эту роль по аналогии с судопроизводством, я называю Судьей. Кроме всего этого, так как Судья нейтрален, то он может устанавливать правила.

Суммируя. Истец выдвигает идею и её защищает. Адвокат дьявола критикует. Судья устанавливает правила (обязательно до), и принимает решение (обязательно после).

Роли в дискуссиях

Часто в разных дискуссиях люди присваивают другим определенные роли (например человек A за идею X, B против X). По моему мнению, такое мышление погубно, и уже давно я научился и привык быстро переключатся между ролями Истца и Адвоката дьявола. Что интересно, исторически была уже масса случаев, когда народ откровенно не понимал мою позицию, пытаясь присвоить её к одной или противоположной точке зрения, и все непонимание получалось потому, что фактически моей личной позиции по вопросу попросту не было.

Аналогии

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

Способы предоставления информации

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

Для достижения своих целей в изложении и решения описанных проблем можно использовать разные способы подачи информации.

Мне известны три различных способа, каждый из которых имеет свои особенности и подходит для отдельных целей. Здесь их изложение.

Сократовский метод

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

Данный метод является классической схемой для предоставления человечеству полезных вещей (например описание решения проблемы X или научная статья), а также выполнения различных интеллектуальных работ/трудов.

Если провести описываемый вопрос через классический сократовский диалог, проведя одну итерацию, то это можно представить как:

Проблема → Способ её решения → Решение порождает новые проблемы.

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

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

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

Таким образом, применение метода — последовательное выполнение ряда шагов (некоторые из которых могут отсутствовать):

1. Проблема.
   1. Актуальность проблемы (зачем её надо решать?)
   2. Описание проблемы (в чем суть).
   3. Примеры.
2. Решение проблемы — что предлагается/суть сообщения.
   1. Описание способа решения (она же теория).
   2. Примеры (они же практика).
   3. Особенности.
3. Выводы.
   1. Значимые результаты.
   2. Какие были/остались проблемы.
   3. Что будет в будущем.

Но не только научные статьи пишутся в таком стиле. Теперь третье приближение к сократовскому методу — цитата о применении метода из книги И.Адизеса «Идеальный руководитель»:

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

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

Inverted Pyramid

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

Данный способ появился во время Гражданской Войны (Civil War, полагаю что в США). Все репортеры хотели передать с линии фронта домой свои истории с помощью телеграфа, но особенность в том, что они могли бы погибнуть в любой момент, или телекоммуникационные линии могли бы быть оборваны. Поэтому никто никогда не знал, сколько времени отведено на передачу, и необходимо было передавать самую важную информацию в начале, а менее важное — в последующем.

Журналисты часто используют такой прием в случае, когда нужно быстро что-то написать. Собирается группа абзацев (каждый из них самостоятельная мысль), потом сортируется по важности по убыванию. Таким образом такая постановка задачи позволяет быстро собрать статью, захватить внимание читателя и передать таким образом максимум информации.

Таким образом, основная цель способа — захватить внимание читающего.

Burying the Lead

Lead — основной смысл сообщения. Burying — «закапывание». Т.е., целью является «закопать смысл сообщения». В данном контексте это может означать два основных замысла. Первый — смысл раскрывается в самом конце, второй — смысл закопан внутри и читателю предстоит его найти.

Основным ореолом обитания данного метода являются детективы, истории, анекдоты, пьесы и тому подобное. Читатель чаще всего заинтересован в поиске смысла и к этому подготовлен. Цель — неожиданная развязка или заставить о чем-то задуматься.

Комбинированные схемы

Совсем необязательно при написании использовать только одну из трех схем — их можно вполне успешно комбинировать.

Хорошим вариантом является написание некоторого заголовка или аннотации (lead), в котором содержится основной смысл статьи (core idea), раскрывающая суть, либо захватывающая внимание. А после lead'a можно использовать одну из других схем (сократовский метод для научных и технических статей, или burying the lead для публицистики).

Для иллюстрации этой схемы цитата Don Wycliff'a, победителя конкурса Editorial Writing (1996):

“I’ve always been a believer that if I've got two hours in which to do something, the best investment I can make is to spend the first hour and 45 minutes of it getting a good lead, because after that everything will come easily.”

Я всегда считал, что если у вас есть два часа на то, чтобы что-то сделать [написать], то лучшее, что я могу сделать, это потратить первый час и 45 минут на создание хорошего лида (lead), потому что после этого все остальное идет легко.

Алхимики современности или неразрешимые проблемы

Раньше алхимики искали философский камень и способ превратить что-нибудь простое и подручное в золото. Т.е., каким-то простым действием (например хитрым ударом молотка и словами «крэкс-пэкс-фэкс») сделать из куска глины кусок золота. Закончилось все это тем, что простого способа не нашли (в настоящее время на это нужно потратить огромное количество энергии для ядерных реакций), но попутно было изобретено много чего.

Но алхимики никуда не исчезли. Они до сих пор среди нас, только декорации изменяются.

Здесь хочу выделить отдельный класс т.н. неразрешимых проблем и описать пару их свойств.

Современные примеры

Поиск серебряной пули

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

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

Поиск элексира вечной молодости

Это алхимики как древности, так и современности. В древности правители щедро финансировали поиск вечной молодости, стараясь как выведать что-нибудь за тридевять земель или шпионажем, так и спонсируя отдельных естествопытателей.

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

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

Знание языка

Имеется ввиду человеческого языка общения.

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

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

General Problem Solver

Это мое прогностическое мнение. Не существует универсального AI, решающего любую проблему. Есть много разных AI с разной эффективностью, и естественный интеллект не исключение.

Было и будет много разных интеллектов. Много предлагателей универсальных интеллектов. Много попыток его построить с провалом, но с косвенными плюшками.

Свойства

Все свойства расписаны выше, но здесь их явная систематизация.

Кроме того, мое контекстное определение. Неразрешимая проблема — такая проблема, которая решается частично, но не может быть решена полностью, либо полное её решение слишком затратно; мы можем решить её частично, и улучшить результат, но полного решения нет.

Полезность и бесполезность попыток

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

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

Множество предложений простого способа

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

Нет простого способа

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

Оптимизм

Есть вещи, которые не таковы, какими мы хотели бы их видеть. Очень хочется иметь философский камень, универсальный молоток, элексир молодости и пр.. Но реальность не такова.

Заключение

Когда каркас данного сообщения был готов, то перечитал Брукса (его Мифический человеко-месяц, где есть No Silver Bullet с историей 10 и 20 лет спустя). И с восхитительным удивлением нашел там следующую цитату:

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

Turski W. M. And no philosophers’ stone, either // Kugler H. J. (Ed.). Information Processing 86. Amsterdam : Elsevier Science, North Holland, 1986. P. 1077-1080.

Развитие технических систем — Взрыв и стандартизация (с примером IBM)

Лампочки накаливания появились не сразу, а долгое время изобретались разные варианты решения. В свое время Эдисон перебрал две тысячи лампочек, прежде чем выбрал ту самую, которая победила газовое освещение.

При выходе в новую область наблюдается взрыв разнообразия различных форм. Так было с самолетами в 20-30-х гг., так было в войне Unix'ов, так было с кодировками до ASCII и до UTF-8.

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

После взрыва запускается процесс естественного отбора, когда разнообразие начинает уменьшаться, а видообразование приостанавливается. Отдельные наиболее приспособленные особи выживают и захватывают большие области, другим видам питаться нечем и они отмирают. Так, на сушу в свое время вышли 5-ти, 6-ти и 8-ми пальцевые существа, но выжили только потомки первых, потому мы такие и других больше не наблюдаем.

В технических системах происходит аналогичный процесс, когда остаются в основном 4-хколесные машины шириной в две крупы лошади, мейнстримовые языки программирования, типовые решения для аппаратных устройств (генераторы, трансформаторы), коробочные продукты (one-the-shelf), … Большие выжившие монстры решают большие классы задач, а в маленьких закоулках ютятся отдельные подвиды, зачастую мало кому известные и потенциально отмирающие.

Технические пути отбора

В технических системах с точки зрения отбора можно выделать два механизма.

Первый — насильственный захват и выбивание конкурентов. Например как это делает Windows — разработчики Windows сами себе стандарт, не обращая внимания на других, и способ захвата — выживают те решения, которые выигрывают на рынке, даже если эти решения не являются сильными. Это и сама ОС, и Ctrl-C Ctrl-V (задолго до них был Ctrl+Insert и Shift+Insert), и Win-1251 и др.. С точки зрения разработки — это решения для себя, для полного контроля и для вписывания в внутрикорпоративные стандарты.

Второй — через комитет (comittee). Когда собирается группа экспертов и после обсуждения принимает какое-либо чаще всего консенсусное решение. Решения более сильные, более глобальные, но делаются немногим дольше и не всегда выживают.

Технетика

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

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

Стандартизация вычислений с плавающей точкой

Сейчас ещё один такой случай, который увиделся при чтении Fatal Defect (chapter Wrong Number), где подробно разобрана история становления стандарта по вычислительным арифметическим операциям на компьютерах/калькуляторах с плавающей точкой. Особенность в том, что в 60-х не было единого подхода и решения того, как хранить вещественные числа в компьютере, а также как проводить вычислительные операции. Каждая организация делала свое решение, а зачастую внутри организации разные аппаратные разработки имели разные реализации.

Особенностей разностей несколько. Для примера, первая в том, что для повышения точности можно хранить разное количество дополнительных разрядов (кроме отображаемых на дисплее калькулятора можно хранить 0, 1, 3, … разрядов за краем табло, чтобы потом результат вычисления был более точным; например если не хранить, то 1/3*3 получится 0.99999). Второй является то, что можно использовать разные способы округления, которые также могут отражаться на конечном результате. Третьей являются разные алгоритмы выполнения данных операций, каждый из которых может отличаться точностью, быстродействием и неравномерным распределением ошибок. Четвертой — возможно разные преобразования между отображением и вычислением (например сначала берется то что на дисплее в 10-й системе счисления, переводится в 2 с/c, считается, далее обратно в 10 с/c). Пятой — стоимость системы.

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

Компьютер в любом случае не может обеспечить 100%-й точности для всех математических вычислений (так как числа в памяти есть конечное число единиц и нулей), и, казалось бы, с этим мало чего можно сделать. Однако в 70-х запустился процесс продвижения идеи, согласно которой необходимо было привести зоопарк к общему знаменателю, чтобы мы не всегда получали точный результат, но на разных компьютерах этот неточный результат был бы одинаковым.

В конце 70-х IBM инициировала внутри себя процесс создания подобного стандарта, так как зоопарк был внутри данной организации и руководство уговорили это сделать. После запуска процесса был собран IEEE-комитет из ~70 представителей различных компаний и институтов (не только из IBM). После многочисленных штурмов и споров (потому что каждый эксперт считает свои заблуждения самыми правильными) был выпущен черновой вариант с сомнениями о том, что этому кто-то будет следовать. Однако IBM в 1980-м выпускает первые чипы 8087, которые соответствовали описанным требованиям, и после этого запустился лавинообразный процесс, который охватил всех мировых производителей, хотя официальный чистовой вариант был принят в 1984-м.

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

Поступательное развитие

В последнее время вокруг меня что-то много звезд выстроилось по этому понятию…

Примеры

Нельзя сразу собрать проект, который реализует полет на Луну. Или создаст термоядерную бомбу. Или реализует национальную ПРО.

Сразу слетать на Луну — это будет глупая и бессмысленная смерть. Сначала надо собрать ракету и запустить. Понять, что чтобы слетать, надо работать над надежными двигателями, иначе летать она будет низко. Придумать гироскоп, иначе летать будет не туда. Собрать конструкцию заданного масштаба (ракеты малой дальности и межконтинентальные — это две болшие разницы). Запустить железяку и проверить, чтобы она не столкнулась с небесным сводом. Запустить жывотное, потому что его не жалко. Запустить человека в корпусе. Запустить и отработать технологии выхода в открытый космос. Слетать на Луну и померять радиацию. Попробовать прилуниться, а то иначе можно утонуть. И только потом появляются какие-то шансы на слетать и вернуться обратно.

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

Для ПРО сначала необходимо создать что-то, что сможет зарегистрировать массы самолетов. Потому что-то, что сможет засечь одиночный самолет. Потом что-то, что сможет засечь и определить высоту полета. Потом что-то, что сможет засечь, определить x,y,z,t и сбить. И только потом можно думать о чем-то, что сможет отразить атаку в глобальном масштабе.

Два простых правила

Давно в данной теме знаю и использую два простых правила:

Законченные и дискретные решения

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

Сложные системы строятся из простых

После Буча сейчас много где цитируют J.Gall'a ^*: «Любая работающая сложная система является результатом развития работавшей более простой системы... Сложная система, спроектированная "с нуля", никогда не заработает. Следует начинать с работающей простой системы».

Процесс роста

Совсем недавно встретил через Стратоплан картинку роста в любой области (источник — недра психологии потока):

От себя отношу картинку не только как к личностному росту, но и к росту проектов или групп людей (что почти одно и то же по закону Конвея).

На графике по вертикали сложность постановки задачи, они же требования к её исполнению (масштабность проекта, процент отказов, производительность системы, … — все это может быть большим уровнем по требованиям). По горизонтали наши умения (+ знания и навыки). Т.е. способность что-либо делать.

В самом начале мало чего умеем. И лучше, если не предъявляем к себе каких-либо сверх-требований. Тогда это нижний левый угол.

Делая что-то, мы учимся это делать лучше. Если делать это долго, то мы научимся это самое делать, но нам становится скучно. A1→A2. Если мы предъявляем к себе более высокие требования, то появляется чувство тревоги — получится ли? сложно! много всего.. и все такое. A1→A3.

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

Оптимальное развитие — как по красной линии, можно немного иногда заходить в сторону тревоги. Если делаем переход вида A1→A4, то растем и можем осуществить большее.

Следствия:

• Сначала мы все ничего не умеем. Если мы предъявляем к себе большие требования, то станет страшно, ничего не будет получаться и все будет заброшено. Поэтому начинать надо с простых вещей.
• Если долго делать одни и те же простые вещи, то станет скучно и уныло. Что делать? Повышать требования.
• Что делать чтобы быстро расти вверх? Идти согласно коридору потока. Если проект большой и масштабный, то идти придется долго, зачастую окольными путями.

Под другим ракурсом

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

Слишком сложная цель

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

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

Работа в стол: переход на самообразование в случае плохого образования; постепенная выработка мастерства; методический и системный сбор информации.

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

Отсутствие цели

Проект выполнен, а дальнейших целей нет.

Активный поиск качественно более широкой и дальней цели и отсутствие ожидания. Без этого — останов процесса роста и потеря поступательного развития.

Отсутвие возможности работы над следующим этапом (не важно по каким причинам) — способствует потере команды и задела.

Цель забирают

По разным причинам — недопущение до информации, высмеивание, потеря контроля, куча соавторов.

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

---

^{* — данная мысль только в программной инженерии лет на 20 старше; у Брукса в статье о серебрьяной пуле есть ссылка на научную публикацию 1971 года и цитата коллеги 1958-го года.}

Made to Stick — Создание Ключевой Идеи — Концепт «Намерение командира (Commander’s Intent)»

Планирую опубликовать три сообщения о понятии Core Idea (Главная, Центральная, Ключевая Идея), взятого с подачи книги Made to Stick. Тема относится к постановке задач, достижении цели и общему менеджменту (в плане управления).

За последние несколько месяцев я успел опробовать и успешно применить это в ряде областей, как организации разработки ПО, постановке преподавательского курса, дизайнинге, самоорганизации (контроль дел, life-менеджмент), планирование путешествий, …, и считаю это очень полезной штукой.

Организация в армии

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

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

Ни один план не выдерживает встречи с противником

В оригинале: «No plan survives contact with the enemy».

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

Есть хорошая аналогия в шахматах: вы знаете все про игру (что может сделать оппонент, что можете сделать вы), но вы можете просчитать только несколько ходов и не можете спланировать все, записав кучу условий типа «если X, то Y». Многое зависит от ходов противника, а иногда происходят совсем неожиданные ходы, поэтому планы необходимо постоянно пересматривать и больше полагаться на интуицию.

Имеются другие интерпретации данного свойства: «No sales plan survives contact with the customer» (ни один план не выживает при встрече с покупателем), «No lesson plan survives contact with the teenagers» (ни один план урока не выживает при встрече с тинейджерами). От себя добавлю: «No project manager plan survives contact with the development».

Концепт Commander’s Intent (Намерение командира)

Данный концепт Commander’s Intent (CI) предлагается как результат длительного наблюдения, обобщения опыта и разработки планирования для армии США, который начал фиксироваться и формализоваться в 1980-х. О нем можно познакомится подробно, но дальше будет смысловая суть.

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

CI никогда не содержит специфичные мелкие детали. Его задача — определить намерение, или другими словами, цель. Основной смысл такого принципа: вы можете потерять способность выполнить конкретный оригинальный план, но вы никогда не потеряете способности выполнить намерение/цель. Другими словами, потеря нескольких бойцов в батальоне и потеря высоты не может помешать потерять намерение защиты прохода третьей бригады.

При таком планировании люди знают цель, хорошо понимают те возможности, которые у них есть и не требуют контроля или разрешения сверху. Их задача — выполнить конечные условия приказа, но при этом есть свобода импровизации. Кроме того, приказ трансформируется в различные варианты поведения в зависимости от рода войск или специфичности обстановки. Если приказ имеет вид «Мы собираемся провести пешее подразделение в такую-то точку вперед», то для разных групп это может означать разное: механики знают, что они должны обеспечить безотказное функционирование техники, так как остановка одной единицы транспорта остановит все; инженеры должны создать дымовую завесу от противника; артиллерия подавить огневые точки и т.д.. Людям предоставляются цели и конкретные условия их выполнения и они, в свою очередь, начинают генерировать собственные решения, которые зависят от их способностей, особенностей и общей обстановки.

Как обеспечить подобное поведение?

Как сделать так, что создаваемые идеи (приказы, цели) могли быть правильно поняты, не были искажены из-за изменяющихся обстоятельств в хаотичном окружении? Один из способов — идея должна быть простой. Но не в том смысле простой, что упрощена так, чтобы её понял любой дурак. Это должна быть Core Idea — центральная, ключевая, самая главная Идея.

В книге много сказано о том, как найти эту Идею и что с ней делать в дальнейшем. В двух словах: это должно быть именно то, что критически важно, то, что является ядром (Core) наших намерений. Дальше необходим другой шаг: сделать так, чтобы она была упакована в удобную для восприятия форму и при этом как можно меньше поддавалась искажениям. Но как делается первое и второе — это уже отдельная большая тема (;

Консерваторы и либералы

В последние лет 10 появилось много исследований на тему разделения людей на консерваторов и либералов. Здесь некоторая сборка фактов и их компиляция.

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

Политическая окраска

Это разделение похоже на политические партии, но не является таковыми. Сходство заключается в том, что консерваторы более склонны сохранять существующий порядок, а либералы — увеличивать разнообразие, менее трепетно относится к устоям, обожать новинки и изменения, …

Различие в реакции на внешние стимулы

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

Решительность

Консерваторы более решительны (например политические лидеры), их мнение непоколебимо. Либералов же зачастую терзает между множеством вариантов (например научные работники), и у них в голове постоянно фигурирует множество вариантов, из которых проблема сделать выбор.

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

У консерваторов механизм принятия какого-то мнения работает практически автоматически. Т.е. когда какое-то чувство (мнение) преобладает, то весь мозг автоматически принимает его и заглушает другие чувства (мнения). Это позволяет работать в одном направлении, действовать решительно и убедительно.

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

Мышление

Либералы больше думают головой, консерваторы больше полагаются на чувства.

При этом логикой консерваторы обосновывают свою интуицию. Либералы с помощью логики делают выводы и руководствуются ими.

На этом же имеется корреляция в степени религиозности. Религиозное мышление более интуитивно, атеистическое — более логично. Здесь есть корреляция например с пунктом выше (Различие в реакции на внешние стимулы), откуда кто как и больше относится к гомосексуалистам, мини-юбкам, ГМО, клонированию и пр..

По мышлению другой пример: для консерваторов «не убий» — это словесное выражение интуитивного понятия, которое можно нарушить, воспринять по-своему, провести аллегорию и т.д. — если интуиция говорит о другом; для либералов «не убий» — это означает то, что написано, четко и логически — никогда, нигде, никого «не убий».

Внешние признаки

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

Преимущества и недостатки

Каждое из этих типов имеет свои плюсы и минусы. Например консерваторы могут быстро объединиться под одним флагом («Цой/Ленин жыф!», «Gott mit uns!», «Янки гоу хоум!», «Бей тех, кто не в тельняшках!», …) и толпой решить проблему. Либералы же мало того, что каждый из них имеет разное мнение, так и ещё в головах каждого из них находится куча мнений в противоречии. Поэтому консерваторы часто ошибаются, но давят толпой, а либералы быстро находят много разных решений, но из них не знают что выбрать (но чаще выбирают наиболее эффективные). Консерваторы выживают когда вокруг враги, болезни, отсутствие еды, потому что они банда!; либералы же начинают процветать когда есть еда, вода, мухи не кусают и сверху никто не капает.

Гуманитарные и технические науки

В каждой естественной науке заключено столько истины, сколько в ней математики.

(И. Кант)

Всё, что нельзя выразить в цифрах — это не наука, это — мнение.

(Роберт Хайнлайн)

Этот пост о разделении гуманитарных и технических наук. О том, что не все есть в науке — это математика. О том, как связаны гуманитарии и технари. О том, что для программирования нужны далеко не только технические навыки.

Необходимое условие точных наук

Оно же — необходимое условие для технических наук, для математики и для работы технического мышления.

Все технические науки (а некоторые говорят, что это якобы вся наука) опираются на теорию первого порядка. То есть, все, что работает с точными символами, формулами и значками, может быть описано логикой первого порядка. Здесь о теории первого порядка можно не задумываться, а основной смысл в том, что все технические науки имеют одно логическое (математическое) основание. Отличаются теории только набором аксиом. Ну и набором инструментов, чтобы часто встречаемые логические конструкции записывать покороче.

Ключевое здесь то, что любая техническая теория работает только тогда, когда имеется набор железобетонных утверждений. То есть, аксиом, которые выполняются всегда. Например, только если свет распространяется по прямой, то только тогда мы получим геометрию Евклида. Только если числа 1,2,3,4,… упорядочены друг за другом — получим арифметику. Аксиомой может быть постулат или закон (непреодолимость скорости света, закон Ома, …), т.е. что-то, обладающее свойством железобетонности.

Если таких аксиом нет, то нет никакой технической науки. Нет ни математики, ни матмоделей, ни формул, ни цифр, … Но, тем не менее, есть науки, которые не содержат в себе аксиом. Например лингвистика (смысл слова в которой у каждого человека может отличаться от другого и меняться с течением времени; все, что касается правил — работает с исключениями, поправками, натяжками и «авторским стилем»). Кроме того, есть науки, в которых часть изучаемой области аксиоматике не поддается. Например в биологии молекула ДНК это не постоянный носитель информации, а такой носитель, который может в любой момент изменится, быть исправленным другим носителем, стать активным устройством и др..

Постоянный процесс формализации в технических науках

Изначально если брать какую либо предметную область, на сейчас покрытую технической наукой, то в ней не было аксиом. Была предметная область, в которой было все непонятно. Звезды непонятно двигались по небу, тела непонятно как взаимодействовали в природе, свет и тепло непонятно как распространялись и пр.. С течением времени начали замечать, что есть что-то, что повторяется. Есть какие-то свойства, которые закономерны. То есть, в непонятной области выполнялась процедура классификации: выбирались некоторые классы явлений, для которых описывались закономерные свойства. Свет распространялся по прямой, тепло передавалось от горячего к холодному, тела чаще падали на землю, нежели оставались в воздухе и т.д..

Таким образом, в предметной области выделялись аксиомы, на основании которых можно было делать выводы о будущем. С течением времени количество аксиом росло, плюс для каждой из них появлялись граничные условия (когда они выполнялись). Непонятная область становилась все более понятной, и этот процесс (формализации) идет до сих пор. Задачей же технических наук является поиск наиболее эффективных в применении аксиом и установки их границ применения.

Таким образом, во-первых, в технических науках постоянно идет процесс формализации. Когда непонятное становится более понятным, количество моделей множится, а наши возможности их использовать увеличиваются. Сам период развития предметной области можно разделить на доаксиоматический и аксиоматический. Во-вторых, техническая наука работает только тогда, когда есть аксиомы. Поэтому техническое мышление начинает сильнее работать только по мере появления новых железобетонных знаний о мире. В-третьих, аксиомы могут быть сгруппированы и сформулированы различным образом. То есть, один и тот же процесс закономерностей можно описать различным набором аксиом (например выбрать 4 направления север-юг-запад-восток, или 4 аналогичных СВ-СЗ-ЮЗ-ЮВ).

Отсутствие аксиом

Что же делать, если аксиом нет? Неужели тут наук нет?

Этим делом как раз таки занимаются гуманитарные науки (в данном контексте).

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

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

Даже если выбрать какой-то более оптимальный вариант (возможно привлекая некие технические инструменты), то далеко не всякая система поддастся изменению. Например когда-то пытались все привести к десятичной системе (например время), но это сделать не удалось (так и пользуемся 24 часа, 60 минут и секунд). Мер счисления несмотря на СИ до сих пор много в мире. Таким образом, если уже что-то возникло, и люди к этому привыкли, то изменить это очень сложно. Фактически получается, что больше предыдущий опыт управляет нами, нежели мы оптимизируем его, используя стандарты.

Гуманитарные задачи

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

Если мы организуем работу нашего рабочего места — то это гуманитарная проблема. Тут нет по большому счету аксиом. Стул может сломаться. В любое время может появится новая вещь, которую нужно куда-то положить. Вещи нужно быстро находить при необходимости. Постоянно формировать новые привычки и забывать те, которые вышли из употребления.

Инженерная деятельность

Существует мнение, что для инженерной деятельности (и программирования в том числе) важны технические навыки и мышление. Есть другое мнение, которое говорит о том, что гуманитарная подготовка более важна. Как всегда — истина где-то рядом.

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

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

Но. Как только мы определяем утвержденные истины (данные там-то не пропадут; питание не пропадет в течение 10 минут после сигнала тревоги; если записано x=1, то после операции x будет равен 1; на диске есть свободное место в несколько килобайт всегда, …), и начинаем делать выводы от них, то мы решаем задачу технически (математически). У нас есть аксиомы, на основании которых можно делать выводы и писать надежные программы. Или создавать на их основе аппаратные или механические комплексы.

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

Long Tail

Часто получается, что по каким-то вещам мысли лежат под подушкой, пока не появится время и накопленный опыт. К такой очередной вещи относится Long Tail.

Об этом понятии хорошо сказано в статье «Тирания пространства».

Понятие

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

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

Распределение предложений в магазинах

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

Работает и обратный эффект — чем более большой магазин мы находим, тем имеем большую вероятность обнаружить в нём редкую вещь. Это происходит потому, что количество покупателей у большого магазина больше, поэтому товар не залеживается на прилавке и будет куплен с большей вероятностью.

Способность стричь длинный хвост

В коммерции получается, что покупатели, заинтересованные в товарах, находящихся дальше по графику длинного хвоста — все равно присутствуют. И этот спрос в ряде случаев намного больше, чем топовых вещей. Но малые магазины не в состоянии удовлетворить покупателей данной категории. Но их могут удовлетворить большие магазины. Поэтому в таком случае большие магазины в состоянии заработать $ на редких вещах, и, соответственно, это позволяет им «стричь» этот хвост.

Данная стрижка оказывается очень эффективна в интернет-коммерции. Но способность стричь данный хвост появляется не у каждого. Интернет примечателен тем, что не требует больших издержек на товары, поэтому он позволяет иметь намного больший ассортимент. К такому характерному примеру относится Amazon, когда предоставляемый спектр предложений весьма велик.

Высокоточное оружие и стрельба из пушки по воробьям

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

С другой стороны имеется более точное оружие. Характерным примером является Google. Его контекстная реклама, на которой базируется доход в более чем 90% компании, работает именно таким образом, чтобы предоставлять её тем пользователям, кто на неё ориентирован. Например если мы впишем в запрос «Авто Минск», то сразу получаем рекламу, ориентированную в конкретного пользователя. Такое действие намного эффективней стрельбы по воробьям. Оно работает именно тому, кто ищет подобное; лучше пробивает интуитивные спам-фильтры (люди далеко не всегда читают все что попало) и работает именно тогда, когда человеку это нужно.

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

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

Основной вопрос тут в том, что в разных ситуациях не все могут оседлать хвост. Но различные технологии и подходы позволяют сделать это, и, если это возможно сделать, лучше это сделать.

Попса и Long tail

В жизни встречалось много определений попсы. Кто-то говорил, что это то, что приносит $, а что «для души» — это уже не попса, и типа поэтому это круто. Есть мнение, что попса — это мнение и предпочтение толпы («а мы не серость, поэтому мы лучше»). И др.

По-моему, контекст головы длинного хвоста как раз является самым точным определением попсы.

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

Список книг

И последнее, что натолкнуло на вытягивание идеи из-под подушки.

Когда-то давно на одном из сайтов делался опрос, согласно которому нужно было написать тройку последних прочитанных книг. Но, прочитав последних несколько десятков ответов, я понял, что я вообще не вписываюсь в контингент. И, походу, редко в какой контингент списываюсь (; И сейчас эта история повторилась, когда в которой последние книги такие:

1. Ray Kurzweil, Terry Grossman, «Transcend» (участвовал в переводе, скоро выйдет на русском).
2. On Intelligence (Jeff Hawkins).
3. Айзек Азимов, «Мозг человека».
4. Нассим Талеб, «Одураченные случайностью».

А на очереди стоят ещё более далекие по хвосту:

1. Шеффер Жан-Мари «Конец человеческой исключительности».
2. Марков «Рождение сложности».
3. Винер «Кибернетика, или управление и связь в животном мире и в машине».
4. Эшби «Введение в кибернетику».
5. Бир «Мозг фирмы».
6. Ерик Дрекслер «Машины создания»

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

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

Разбор Leaky Abstraction

С подачи Алёны C++ разбор Leaky Abstraction.