Вы очень конкретно мыслите. Это хорошо в ряде ситуаций. Но это не позволяет вам мыслить о том, как вы мыслите. И мыслить о мышлении -- это не рефлексия имеющая исключительно теоретическое значение. Мышление -- это поиск, надо, выйдя из исходной точке, пройти многими путями в разные стороны, выискивая тот путь, который ведёт к цели. Эффективная организация этого поиска -- это самостоятельная задача, но чтобы решать эту задачу и пытаться соптимизировать решение, придётся думать о том, как идёт процесс мышления.
То, что вы описываете как мышление, для меня неотличимо от метода проб и ошибок, пусть и помещённого на вершину иерархии.
Я придерживаюсь подхода Аристотеля про то, что в основе мышления лежит логика, схема.
И меня ничуть не расстраивает, что я не способен мыслить о мышлении. Но если вы способны - предъявите схему.
И вы говорите об оптимизации, но почему-то не предъявляете оптимизируемые параметры. Не надо так, это превращает содержательные разговоры в "за всё хорошее против всего плохого". Keep focus.
Редукция, в общем смысле -- это перевод неких утверждений из одних терминов в другие, из терминов более высокоуровневого описания, в термины низкоуровневого описания. Но в процессе поиска решений задач мы постоянно переводим утверждения не только "вниз", но и "наверх". Даже если речь идёт об инженерной задаче. Если я пытаюсь создать механические часы, то я начинаю редуцировать своё высокоуровневое представление о часах в низкоуровневое. Переводить с языка "циферблат, по которому движутся часовая и минутная стрелки, которые вращаются механизмом, который работает беря энергию от пружины, и дозируя расход этой энергии маятником", на язык конкретных шестерёнок, с конкретным количеством зубьев, формой зубьев, конкретным образом соединённых между собой, конкретным образом расположенными в пространстве относительно друг-друга. Это два разных языка описания задачи, и они оба являются инкапсуляцией. Высокоуровневый язык прячет от нас множество свойств системы, типа положения шестерёнок в пространстве. Низкоуровневый язык позволяет с этими свойствами работать, но при этом теряет какие-то высокоуровневые свойства и не позволяет о них говорить. Они оба нужны нам для того, чтобы разделять и властвовать. Чтобы не держать в голове одновременно всё, размышляя об устройстве часов.
Работая с этими языками мы постоянно переключаемся с одного на другой, потому что языки несовершенным образом приспособлены под устройство задачи, мы постоянно сталкиваемся с какими-то частными рассуждениями/подзадачами, в которых язык, который привёл нас к этой подзадаче, оказывается неприменим для решения этой задачи. Нам приходится переходить от одного языка к другому.
И вот тут вылезают редукция и "эмердженция". Мы на частных задачах редуцируем высокоуровневое описание ситуации в низкоуровневое, чтобы найти там какую-то конфигурацию шестерёнок, которая даст нам то, что нам нужно на высоком уровне. И получив это низкоуровневое описание, мы поднимаемся обратно наверх.
То есть, на самом деле, всё ещё сложнее: в таких ситуациях мышление идёт сразу на обоих уровнях, голова параллельно выстраивает рассуждения в двух разных моделях. Но в примере с часами всегда получается так хорошо, в силу простоты задачи.
Мне всё ещё не ясно, откуда вы берёте иерархию - "высокоуровневое описание" и "низкоуровневое описание".
Скажем, я привёл 9 описаний, мне по работе нужно уметь хотя бы знать ключевые слова из каждой предметной области.
Как их соотнести по уровням:
- геохимия нефти и газа (из чего состоят углеводороды и в каких условиях пребывают)
- геология нефти и газа (какой рельеф вокруг углеводородов, пористость и проницаемость среды)
- инженерия нефтедобычи (каким способом извлекаем)
- физическая модель многофазного потока в пористой среде (выбор какие физ.эффекты важны)
- матфизика и запись диффуров с гранусловиями
- вычислительная математика (каким способом/алгоритмом ведём рассчёт)
- программирование (как закодить алгоритм в конкретном языке программирования)
- машинное обучение (часть параметров в алгоритме обучается автоматически, проверяем точность обучения)
- анализ и визуализация данных (как отображаем насчитанный результат)
В системной инженерии отношение часть-целое является базовым.
Через него задаются уровни "подсистема" - "целевая система" - "использующая система". Но эти уровни вполне физичны, потому что системы нарезаются на 4D индивиды с явными пространственно-временными границами.
Ручка является частью кружки, потому что занимает часть того пространства-времени, которое занимает кружка.
При этом мне совершенно непонятно, как могут быть высокоуровневыми или низкоуровневыми термины.
То же самое можно продемонстрировать на примере задачи разработки программы. Пишется библиотека, которая инкапсулирует какое-то взаимодействие с системой, выставляя наружу какой-то API, который мы спроектировали таким образом, чтобы потом нам было бы удобно мысля в абстракциях этого API решать более сложную, более высокоуровневую задачу. При этом, поскольку в общей ситуации невозможно создать хороший API не создавая при этом ту часть программы, которая будет пользоваться этим API (или хотя бы не представляя как будет эта высокоуровневая часть работать), то при проектировании мы постоянно мечемся с языка низкоуровневых операций, которые должны быть спрятаны под API, к высокоуровневому представлению задачи, выраженному на языке абстракций предлагаемых этим API. Эта вся проблема, между прочим, в программировании имеет форму специальной олимпиады: top-down vs bottom-up approaches, написание программы сверху-вниз или снизу-вверх. Начать ли писать программу с написаня простых, низкоуровневых функций, постепенно переходя ко всё более и более высокоуровневым, или писать её сверху-вниз, начав с написания самых высокоуровневых, используя в них ещё вызовы ещё ненаписанных функций, затем писать эти ненаписанные функции, полагаясь на другие ненаписанные, и со временем добраться таким образом до простых низкоуровневых функций, написать их, и получить рабочий код.
Просто всё чуть сложнее, чем просто сверху-вниз или снизу-вверх. Разрабатывая систему мы постоянно выполняем переходы туда и обратно.
Если я вызываю большой сторонний модуль/библиотеку в одну строчку, это "простая низкоуровневая функция" или нет?
Я понимаю, когда говорят о функциональной декомпозиции в принципиальной схеме - там уровни между функциями прослеживаются (и как правило сторонняя библиотека реализует высокоуровневую функцию).
Я понимаю, когда говорят о модульной декомпозиции - из каких блоков код будет компилироваться.
Я понимаю, когда говорят за архитектурный дизайн и функционально-модульный синтез - и рассматривают разные способы совмещения функциональной и модульной декомпозиций.
И понимание этого процесса может позволить оптимизировать процесс поиска решения общей задачи. Я опять же могу нарисовать аналогию. Если мне надо найти выход из лабиринта, то я могу использовать алгоритм, который будет принимать решения основываясь на локальных свойствах лабиринта, на тех свойствах которые я непосредственно наблюдаю находясь в какой-то точке лабиринта. Либо я могу в процессе поиска строить карту той части лабиринта, которую я обошёл, и через это рефлексировать свою деятельность, и находить менее очевидные ходы, которые позволят мне уменьшить время потраченное на обход лабиринта. Больше думать, меньше ходить.
Вы предлагаете увеличить временные затраты на обдумывание. А принесёт ли такой ход пользу? Если да, то какую?
Может, наоборот, имеет смысл меньше думать и больше ходить?
Выныривая из аналогии... Чтобы понимать как происходит процесс мышления, надо иметь какие-то слова, для описания основных операций, как идёт мышление. И я уверен, что редукционный переход и обратный ему "эмерджентный" переход -- это пара операций, для которых обязательно надо иметь в голове слова. Это пара операций, которые всегда надо видеть, и не только потому, что они могут подсказать новый и неочевидных кульбит мысли, но ещё и потому, что отслеживая их можно избавлять мышление от ряда ошибок, которые очень свойственны человеческому мышлению. Например, непродуктивная редукция. Скажем, вопрос "как работает память человека"? Биолог с удовольствием ответит на этот вопрос, начав произносить слова "нейроны, синапсы, образование новых синапсов, увеличение/уменьшение числа синаптических рецепторов,..." Это редукция. Но непродуктивная, потому что она не позволяет ответить на множество вопросов, которые у нас возникают в связи с памятью: почему человек помнит что-то, может узнать это, но не может вспомнить? Помнит ли человек вообще всё, но не всегда может вспомнить, или он помнит не всё? Как меняется содержимое памяти со временем? Меняется ли оно непрерывно, или только когда мы воспроизводим это содержимое? Все эти вопросы существуют на "высоком" уровне абстракции, но исчезают на низком. Это не значит, что надо отказываться от редукционного перехода -- нет, это значит, что для решения этих вопросов нужно уметь выполнять обратный переход. Но мышление человека очень склонно совершать ошибку: услышав объяснение биолога, оно помечает проблему памяти как решённую, а потом, сталкиваясь с вопросами на которые нет ответов, мышление впадает в когнитивный диссонанс (оно же "знает" что проблема решена, так?) и начинает сглаживать противоречие отрицая существование этих безответных вопросов. Говоря, например, "перечисленные проблемы байесианства -- это вовсе не проблемы". Сам по себе когнитивный диссонанс не плох и не хорош, так же как и сглаживание противоречий, но в данном случае это приводит человека к тому, что имея пробелы в своём понимании общей ситуации он не видит этих пробелов, не осознаёт их, избегает осознавать их. Имея белые пятна на карте, человек не видит их примерно так же, как он не видит гориллу, когда считает количество передач мяча (https://www.youtube.com/watch?v=IGQmdoK_ZfY).
Проблемой в википедии называется вопрос, требующий изучения и разрешения.
Психолог может изучать вопрос как задать ёмкость памяти и как её исследовать. Но где тут уровень?
Такое чувство, что вы предлагаете считать, что нижайший уровень - это квантовая теория поля, а высочайший - это астрономия.
И редуцировать для вас - это значит взять что-то сложное и разложить его на мельчайшие элементы (что обычно непродуктивно). Редуцировать явление можно в разные предметные области, будут возникать разные описания, имеющие разную значимость с т.з. конкретного исследователя. А ваша "анти-редукция" - это не мысленная операция, она подразумевает сборку машины по чертежу - и ещё непонятно, заработает ли та. Поэтому мне вообще непонятно, зачем об этом говорить, потому что получается очень непродуктивно.
И это сказывается также и при решении инженерных задач. В рамках того примера с программированием, это приводит к тому, что проектируя программу и её внутренние API, программист выпускает из рассмотрения какие-то проблемы. Эти проблемы вылезут потом, в процессе реализации проекта, и вот там они могут причинить существенную боль, потому что общая спроектированная структура программы не рассчитана на эти проблемы. И тогда приходится нарушать какие-то инварианты, нарушать инкапсуляцию, городить огород сложных телодвижений, разобраться в которых потом будет невозможно.
Если же всегда чётко выделять редукционные переходы, всегда давать себе отчёт, какие именно свойства системы мы потеряли в результате этого перехода, отслеживать всегда то, в рамках какой модели -- высокоуровневой или низкоуровневой -- мы мыслим, то можно сделать такого рода ошибки менее вероятными. Избежать их совсем не удастся, но можно, по-крайней мере, помечать белые пятна на карте как белые и всегда видеть их, всегда осознавать ущербность карты. Причём не в виде абстрактного утверждения "любая карта не соответствует реальности", а в виде конкретного списка конкретных неточностей карты.
Объяснение биолога -- это объяснение памяти на уровне физиологии. Но объяснение памяти на уровне физиологии не может заменить собой объяснения памяти в терминах психики. Если получив какое-то объяснение я отдаю себе отчёт на каком уровне абстракции находится это объяснение, то я вижу какие уровни абстракции при этом остались без объяснения. Мышление обычного человека успокаивается, когда получает хотя бы одно объяснение. Тренированное же мышление не должно успокаиваться до тех пор, пока оно не получит объяснений на всех уровнях абстракции, которые используются при решении задачи. Если вы порефлексируете своё мышление, вы увидите как те примеры, когда ваше мышление успокаивалось получив одно объяснение, так и примеры тому, когда одного объяснения почему-то оказывалось недостаточно, и мысль продолжала искать второе, на другом уровне абстракции. Но принятие этого решения, этот выбор "искать ещё, или успокоится" происходил неосознанно -- не обязательно неверен, но он исходил из каких-то неосознаваемых эвристик. В ваших силах заменить эти эвристики сознательным процессом, осознающим свои сильные и слабые стороны.
Вы убедите меня, если покажите сообщество людей, которое практикует предложенный вами подход "поиска объяснений на всех уровнях абстракции" и получает хорошие результаты.
Пока что я вижу главный аргумент "знать больше лучше, чем знать меньше" - "лучше быть богатым и здоровым, чем бедным и больным" - "а вы заварки больше кладите".
Помогает ли такой подход концентрировать вероятность для нахождения проблемных мест? Я не вижу как.
Позволяет ли он рассуждать в схемах, которые экономят ресурс внимания и могут явно проверяться/отлаживаться? Я не вижу как.
Предлагаете ли вы методы, которыми будут составляться "конкретные списки конкретных неточностей карты"? Я не вижу таких.
Наконец, позволяет ли вам ваш метод сформулировать конкретную задачу с со списком возможных ответов, которую методы байесовской статистики не решают / дают неверные ответы? Не похоже, скорее ваш подход уводит вас в другие предметные области и вы не возвращаетесь из них назад к исходной задаче. Что грустно. Не надо так.
Добавлено 06 Апрель 2017, 12:36:Если получив какое-то объяснение я отдаю себе отчёт на каком уровне абстракции находится это объяснение, то я вижу какие уровни абстракции при этом остались без объяснения. Мышление обычного человека успокаивается, когда получает хотя бы одно объяснение. Тренированное же мышление не должно успокаиваться до тех пор, пока оно не получит объяснений на всех уровнях абстракции, которые используются при решении задачи. Если вы порефлексируете своё мышление, вы увидите как те примеры, когда ваше мышление успокаивалось получив одно объяснение, так и примеры тому, когда одного объяснения почему-то оказывалось недостаточно, и мысль продолжала искать второе, на другом уровне абстракции. Но принятие этого решения, этот выбор "искать ещё, или успокоится" происходил неосознанно -- не обязательно неверен, но он исходил из каких-то неосознаваемых эвристик. В ваших силах заменить эти эвристики сознательным процессом, осознающим свои сильные и слабые стороны.
Ключевое моё возражение - что таким образом вы получите эрудированное гуманитарное мышление, которое разбирается в тонких оттенках объяснений. А зачем это нужно?
Я вот совсем недавно окончил курс
системного мышления, опирающийся на системную инженерию и инженерный менеджмент. Вся системность упирается в постановку вопросов, внятный ответ на которые, будучи общим знанием команды, продвигает проект к успешному завершению.
Например, вопрос "где наша целевая система, что именно мы производим?" Мы выпускаем металлические чушки и целевая система - это партия товара или мы оказываем сервис по доставке чушек и целевая система поставка заказа с чушками? Ответ на этот вопрос сильно влияет на выбор ключевых показателей и предполагает разную специализацию компании на рынке. Выбор альтернативного ответа приводит к альтернативным действиям.
У вас же я перехода к действиям я вообще не заметил. Посидим, покумекаем, составим суперточную карту. А делать когда? Почему более длительная деятельность с менее точной картой не приведёт к большему успеху?
Основной урок из системного мышления, что я извлёк - он ровно про это - основная польза приходит от забарывания ошибок по ключевым направлениям. Важно уметь концентрироваться на этих ключевых направлениях, как минимум уметь их проговаривать, и важно, чтобы работа с ними влияла на итоговый результат (что тоже нужно уметь проговаривать и обосновывать). Всё остальное - рецепты как применить системный подход в деле.