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

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

Понятие

Регулярно как минимум в инженерной среде при проектировании (а точнее, при валидации) чего-нибудь складывается следующая ситуация. Разработчики придумывают какое-нибудь решение, а критики вокруг начинают придумывать разные идеи по поводу того, «а что будет если …». Изначально предлагаются осмысленные варианты поведения (здравомыслящие и логические), далее идет рассмотрение крайних случаев, потом идут какие-либо безобидные ситуации (как некорректный ввод пользователя), но в дальнейшем начинается нечто более серьезное. Что будет если закончится место на диске? Как разруливать ситуацию, если мы имеем нагрузку 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.

Завершение

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

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

О проблемах программного обеспечения в 1983-м году

Цитата из статьи 1983-го года:

If you look at when the Bank of America central computer crashes and start doing statistics, you find that occasionally somebody has spilled coffee in the mainframe, or something like that happened that you can understand. But, in about 95% of those crashes, they don't really know what caused it. The system goes down, somebody says "Oh, here it goes again," and they push the reboot button. It takes them a couple of minutes to bring the stuff in from disk, the system starts again, and everying is fine. So, depending on the particular prejudices of whoever is recording those things, it was either a transient hardware failure, or whatever they like to call it. But basically, they just don't really know what happened.

Если вы взглянете на статистику аварий центрального Банка Америки, то вы обнаружите, что кто-то внезапно пролил чашку кофе на центральный процессор, или что-нибудь подобное, что может произойти и при этом можно понять что именно. Где-то в 95% случаев этих аварий никто не знает что на самом деле произошло. Система падает, и кто-то говорит: «Ё-мое.. опять..», и нажимает кнопку рестарта. Это требует нескольких минут, так как требуется загрузка с диска, после чего система стартует снова, и опять все хорошо. Однако, в зависимости от пожеланий-заморочек сопровождающих, они записывают это как временный аппаратный сбой или что-то в этом духе. Но на самом деле они даже не представляют, что это было.

Такое ощущение, что за 30 лет ничего не изменилось.

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

Разное

Статья сама по себе интересная, просто отмечу тезисно несколько вещей.

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

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

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

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

— Ты что, Вася! Я ввожу 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). По моему мнению, такое мышление погубно, и уже давно я научился и привык быстро переключатся между ролями Истца и Адвоката дьявола. Что интересно, исторически была уже масса случаев, когда народ откровенно не понимал мою позицию, пытаясь присвоить её к одной или противоположной точке зрения, и все непонимание получалось потому, что фактически моей личной позиции по вопросу попросту не было.

Аналогии

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

Идея, её реализация и распространение

Меня поpажают люди наyки. Они за всю жизнь пpидyмывают 1 идею, а потом боятся ее сказать хоть ближайшим дpyзьям, боясь что ее yкpадyт. Идyт годы, и идея так и yстаpевает, не бyдyчи опyбликованной. Люди искyсства и бизнеса подают новые идеи сотнями, и совеpшенно спокойно относятся к томy, что какие-то из них бyдyт pеализованы на стоpоне.

Полугуманитарный преподаватель

Цитата из Капеллана Дьявола (с.269):

Однажды мы с Биллом разговаривали о термитах на отделении зоологии в перерыве на кофе. Нас особенно занимало, что за эволюционное давление привело термитов к их необычайной социальности, и Гамильтон стал хвалить «теорию Стивена Бартца». «Но, Билл, — возразил я, — это же не теория Бартца. Это твоя теория. Ты опубликовал её на семь лет раньше». Он помрачнел и стал это отрицать. Тогда я сбегал в библиотеку, нашел нужный том журнала «Ежегодный обзор экологии и систематики» и сунул ему под нос запрятанный в его собственной статье параграф. Он прочитал, а затем неподражаемым голосом ослика Иа-Иа признал, что, судя по всему, это и вправду его теория, «но Бартц изложил её лучше» (это правда, и я рассказываю эту историю вовсе не затем, чтобы принизить вклад Стивена Бартца. Билл Гамильтон знал, причем лучше многих, что набросать идею на обороте конверта, — это не то же самое, что разработать на её основе исчерпывающую модель). Напоследок замечу, что среди тех, кого Бартц поблагодарил в своей статье «за полезные советы и критику», был не кто иной, как У.Д.Гамильтон!

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

Два разных отношения

Представьте, что вы разрабатываете что-то новое, например новая идея/изобретение, или новый продукт как разработка, или пропагандируете новый принцип. И тут выясняется, что кто-то только что сделал то же самое, но от своего имени. Возможно даже лучше. Какие чувства вы испытываете? Радуетесь ли вы или наоборот, чувствуете, что у вас что-то отобрали?

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

1. Когда хочется никому не отдать и прибить гвоздями свое авторство не только, но и над всем, что из этой идеи следует; а также получить за придуманное плюшки. Надо заставить всех подписать копирайты на себя, доказать свое первенство и прописать его во все педии.
2. Попытаться распространить идею безвозмездно и как можно шире, особо не задумываясь о личном. Если кто-то работает в том же направлении, то поспособствовать изменению мира. Хотят пользоваться? Пусть пользуются, не жалко.

По моему мнению, для данных двух отношений характерно следующее.

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

Чем человек становится старше, тем он больше переходит от первого ко второму (эвристическое наблюдение).

Патенты и авторское право — средства для первых, научные публикации и книги — средства для вторых. Первые нагло тырят идеи у вторых, а свои не отдают.

Проработанная модель лучше идеи

Время от времени от имени психологии первых (назовем их эгоистами) слышу такую по смыслу фразу: «Я накидал им идею, и они сделали» с таким подтекстом, что как будто «без моей идеи они вообще никто». Есть ещё другой вариант: «штуку X я придумал и написал ещё в детстве, на коленке, за полчаса; а они её год делали и то еле работает» с подтекстом «это такая мелочь, которую нечего придумывать, я гений и это маленькая частичка моих идей; а эти писатели и внедрятели занимались этим столько времени».

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

С точки зрения маркетинга и пищевой пирамиды кратко иллюстрирует это следующее выражение: «Тот кто придумывает, получает 1, кто реализовывает 10, кто продает — 100.»

С точки зрения «изменить мир», может быть не так сложно найти идею. Но намного сложнее её реализовать на практике. И ещё на порядок сложнее довести её до потребителя, чтобы ей пользовались многие.

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

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

Что интересно, У.Д. Гамильтон (тот, о ком была первая цитата) свою теорию соотношения полов у медоносных пчел точно так же опубликовал не в специальной заметке в журнале «Nature», как сделал бы любой ученый с нормальной степенью амбициозности, а спрятал в рецензии на чужую книгу. Кстати, у этой рецензии был безошибочно узнаваемый гамильтоновский заголовок: «Азартные игроки со времен зарождения жизни: усоногие, тли, вязы».

Капеллан дьявола

Речь идет об одноименной книге, которую прочитал некоторое время назад.

Книга представляет собой сборником статей Докинза, которые никаким образом не попадали в другие издания. В связи с этим в каждой из них тематика разная и рассматривается под своеобразным фокусом.

Чтобы не писать обо всем или не о чем, здесь три темы, которые показались мне интересными.

Рецепт и чертеж

Имеется два различных типа для создания или развития — рецепт и чертеж.

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

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

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

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

Пару своих примеров для иллюстрации.

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

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

Адвокат беспристрастной истины

В этой теме мне прежде всего понравилась формулировка роли. Смысл самой идеи можно было увидеть в разных вариантах и у Платона, и у Гегеля.

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

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

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

Разрывы в мышлении

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

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

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

Основываясь на этом примере, мы можем получить следующую иллюстрацию. Если взять современного человека, и сравнить его с кроманьонецем 40 тыс. лет назад, то отличия между ними незначительны (мы можем друг с другом легко спариваться). Если пойти дальше, то можно получить так, что предок человека, живший 200 тыс. лет назад (назовем его X), ещё не ушел от нас настолько далеко, чтобы потерять возможность к спариванию. Однако может получиться так, что мы уже не можем спариваться с предком человека, жившего 400 тыс. лет назад (назовем его Y) из-за того, что различия слишком велики. Особенность всего этого в том, что генетическое расстояние между X и Y меньше, чем между нами и Y, поэтому X и Y могут спариваться. Таким образом, мы и X один вид, X и Y один вид, но мы и Y уже не один вид, и это отличие подобно различиям между клушами и чайками, только с той разницей, что межвидовые формы чаек и клуш ещё не вымерли.

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