Previous Entry Share Next Entry
Inside geek syndrome, часть 1: Способ мышления
sun
dnovikoff
Как я уже писал давеча в FB, мне на днях подтвердили то, что я за собой давно подозревал - синдром Аспергера. Несмотря на страшное название и ряд вытекащих из этого вопросов, штука это очень прикольная и настолько интересная, что я решил написать серию постов про это дело. Дальше я пройдусь по симптомам, а пока начну с основного - устройства мозгов, так как именно из него вытекает всё остальное.

DISCLAIMER

Этот текст носит аналитический характер, и его первейшей задачей является качественный анализ собственных тараканов. Я не ставил и не ставлю себе целью привлечение внимания к этому вопросу или, упаси мрзд, подчёркивание собственной исключительности или необычности, как это любит делать, скажем, ЛГБТ-тусовка. Если моя исключительность в чём-то и заключается, так это в том, что я умею лучше всех писать код или создавать акустику. Но если первому подтверждения есть, то над вторым я только работаю. Всё описанное ниже - лишь технические подробности устройства жизни, не более того. Пост вообще не об этом. Его публикация преследует своей целью ознакомить людей с тем, что “бывает и так”, а также упросить жизнь людям, которые могли сталкиваться с подобными особенностями, но не понимали, почему, как и откуда растут ноги.


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

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

- очень прокачанный pattern matching и способность выдавать нетривильные решения.
- акцентирование внимания на деталях, реакция на которые может доходить до полнейшей идиосинкразии (и, как следствие, лютый перфекционизм или тотальное неприятие балеток, лол).
- внезапная потеря фокуса внимания в разговоре (когда человек перестаёт вас слушать и как бы погружается в свои мысли).
- использование формальных языковых конструкций.
- проблемы с социальной адаптацией, эмпатией или как минимум замедление этих процессов и алекситимия.
- много чего ещё (см. выдержки из книг Эттвуда тут: http://www.aspergers.ru/taxonomy/term/31)

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


Представьте, что у вас в голове находится два сервера. Первый, на котором работает fact database, подключён к внешнему миру. Второй выполняет роль solver’а и соединён только с первым сервером, причём пропускная способность линка между серверами у вас ограничена. Это выглядит странно, но устроено именно так - если в обычной компьютерной системе у вас за общение с внешним миром отвечает некий сервер приложений, который использует базу данных только как хранилище, то тут всё ровно наоборот - общение с внешним миром у вас происходит через базу данных, а сервер приложений изолирован совсем.

Оба эти сервера включены постоянно, имеют uptime длинной во всю вашу жизнь и управляют тем, как и что вы делаете. При этом вы можете смотреть на них со стороны, анализировать их устройство, но возможности модифицировать прошивку у вас нет. По сути, влиять вы можете только на подсистемы общения с внешним же миром, типа, ну, принтера. То есть, если вам надо сообщить внешнему миру “kille’m all” вместо “hello, world”, то вы не можете просто изменить аргумент функции, которая отправляет это сообщение на принтер. Вместо этого вам надо лезть в прошивку самого принтера и добавлять кейс на предмет того, что если сервер вам прислал “hello, world”, то на самом деле надо напечатать “kill’em all”. Адаптация системы к реальности в результате превращается в очень весёлый процесс.

Но это, на самом деле, всё фигня.

Не фигня - это устройство сервера приложений, сиречь solver’а. Представьте себе highly-parallel систему с тысячами ядер, каждое из которых при этом очень, очень медленное и довольно примитивное по своему устройству. Причём, систему, управляемую событиями и только событиями. Наверное, наиболее близкой аналогией будет огромный конечный автомат, каждый узел графа выполняется на отдельном маленьком, тупеньком и медленном процессоре.

При этом все эти ядра постоянно чем-то загружены. То есть CPU usage у вас равен 100% всё время по определению. Даже когда вы едите, срёте, едете на велосипеде или играете с кошкой. Весь вопрос лишь в том, чем именно заняты эти процессоры, но НЕ заняты они быть в принципе не могут. Ежели вам нравится играть с кошкой и это доставляет вам удовольствие, то эти ядра будут анализировать поведение кошки, но ежели нет, то сервер приложений моментально найдёт чем заняться ещё, пусть даже это будет анализ правильности геометрической формы куска говна на вашем ботинке или вдумчивая рефлексия на тему “почему я мудак”.

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

Как всё это выглядит в реальности?

Ну вот подходит к вам девушка и говорит “привет”. Первое, что при этом происходит - это запись факта в базу данных. На это требуется время (помните, что каждый узел системы по-отдельности - медленный?). После этого тормозной линк передаёт solver’у событие: в базе данных появился новый факт, “девушка сказала слово привет”.

Solver, который всё это время был чем-то занят, в случае высокого приоритета поступившего события, начинает переключение контекста и выгрузку кэшей обратно в БД. Исходя как из скорости линка, так и из количества обрабатывающих модулей, процесс это небыстрый и дорогой по ресурсозатратам. Поэтому события низкого приоритета система просто игнорирует. Именно отсюда берётся вот это:

- Дима, ты чай просил. Тебе заварить?
- …
- Дима, чай! Чайник уже закипел, тебе заварить или ты сам сделаешь?
- …
- Дииииииима, мать твою!!!
- А, чо, где?! Что было-то?

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

- Что за девушка?
- Красивая?
- Я её знаю?
- etc.

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

Но, по мере поступления данных начинают нагружаться другие освободившиеся процессоры и после прохождения некоего порога процесс приобретает лавинообразный характер, нагружая уже всю систему целиком. При этом анализ идёт параллельно для разных частей дерева решений, такой out of order execution. То есть я _одновременно_ думаю о том, что будет, если девушка красивая, и если девушка некрасивая, и одновременно с этим же думаю о том, что если девушка красивая и умная, или красивая и глупая. Или красивая, умная, но плохо одетая, красивая, глупая, плохо одетая, красивая умная хорошо одетая, красивая глупая хорошо одетая и так далее. Заканчивая каким-нибудь стопиццотысячным вариантом с девушкой, которая красивая, умная, хорошо одетая, но обколотая, без работы, любит отличающуюся от моих вкусов музыку, не умеет водить автомобиль, имеет сомнительные моральные принципы и так далее. ПАРАЛЛЕЛЬНО. Я ещё не успел девушке не то, что в ответ сказать даже привет, а даже посмотреть на неё, а у меня в голове уже одновременно вертится ВЕСЬ этот граф. И пока он там не отработает и в систему не поступят все необходимые для анализа факты, хрен я чего скажу.

Помните выше про то, что я не могу играть в шахматы? Вот оно ровно из-за этого.

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

Отсюда собственно и происходят проблемы, например, с социальной адаптацией. Потому что к тому моменту, как вы сообразите девушке ответить “о, привет, как тебя зовут?”, она уже уйдёт, бросив вам вслед “ну что за тормозной дебил?!”. А ежели приоритет необходимости ответа в заданное время будет высок, то этот ответ конечно произойдёт вовремя, но будет таков, что хорошо, если вам не стукнут по морде за, эм, излишнюю прямоту. Хорошей аналогией тут будет сравнение biased и unbiased движков 3D-рендеринга. Первые показывают вам картинку очень быстро, но выглядит она нереалистично и строится на базе фактически набора хаков и упрощений. Вторые дают картинку, неотличимую от фотографии, но при этом картинку эту формируют в статистических понятиях (физическое моделирование потока фотонов) и вы охереете ждать, пока она отрисуется до приемлемо низкого уровня шума.

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

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

Причина этого проста. Во-первых, система имеет кэши. Во-вторых, паттерны и промежуточные результаты обработки тоже сохраняются в БД. Но как только система сталкивается с незнакомой ситуацией, начинается ад. Вот вы будете смеяться, но я когда давеча решил с утра побегать, я завис минут на десять. Просто вышел на улицу и стоял на месте перед подъездом, анализируя вопрос о том, как же именно мне следует даже не бежать (в плане там темпа или о чём тут можно ещё подумать), а как мне следует _начать_ бежать. Я совершенно серьёзно.

Отдельный интересный вопрос во всей этой истории - это обучаемость системы. Как я уже говорил, всё общение с внешним миром происходит через сервер БД. То есть ежели вы сказали девушке “ты дура” и получили в ответ по морде, то устойчивая связь между этими двумя фактами у вас сформируется только после полной обработки события получения по морде, то есть отработки всех описанных выше процессов. С утра получили по морде - к вечеру переварится. Если просто по морде получили. А если тому предшествовал длинный диалог - то через неделю.

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

Ещё веселее выглядит изнутри потеря фокуса внимания. Вот сидите вы с кем-то и общаетесь, скажем, за литературные качества романов некоего известного писателя. Вообще не важно о чём. Вам говорят: "а вот там он конечно странно развил ситуацию со знакомством героя с девушкой" (продолжим ту же аналогию). Как я уже говорил, у вас в голове постоянно что-то крутится на всех процессорах, и это что-то управляется событиями. И вот вы это слушаете, и на слове "знакомство" у вас срабатывает триггер, а в голове моментально проносится логическая, сугубо формальная цепочка "знакомство - при знакомстве говорят слово привет - слово привет я последний раз видел на рекламе окон - окна были со стеклопакетами - стеклопакеты делаются на П-образном профиле - П-образный профиль может являться частью каркаса - каркас может увеличивать жёсткость корпуса - у нас есть проблемы с жёсткостью корпуса акустики - почему бы не сделать в акустике каркас из П-образного профиля? Хм, акуууустика!". ТЫДЫЩ! Всё, пол-секунды, а вы уже "не здесь" для собеседника.

Такие вот дела:)

  • 1
Да нивапрос вообще :)

А по теме круто загибаешь. Порадовал. Думал я просто долбаеб, а у меня оказывается тоже это синдром))

Я таки ещё постов про него понапишу. Просто сел разбираться в тараканах и внезапно накатал страниц 50 текста, лол. Понял, что надо это выложить, но в один пост ни хрена не влезет :)

  • 1
?

Log in