Comments 51
Нам трудно мыслить вне рамок мифологического сознания и потому кажется естественным, что объект класса «машины» обладает методом «ехать».
В изначальном объектно-ориентированном подходе у машины нет метода «ехать».
Любой объект может принять любое сообщение, и результат не гарантирован.
Машина, скорее всего, поедет, а лошадь скорее всего, нет — ей нужно сообщение «скакать галопом».
Но когда ОО-языки стали превращаться из динамических в статические, процесс отправки сообщение объекту стал называться вызовом метода, а имя сообщения методом.
Получилась подмена:
изначально имя сообщения (метода) задавалось вызывающей стороной,
а потом внезапно оказалось, возможные для вызова методы стали задаваться на стороне объекта-приемника.
Отсюда и получилось, что «машина имеет метод 'ехать'».
Недавно на хабре была серия статей про Алана Кея и Smalltalk — можно обратиться к ним и почитать дополнительные материалы по Smalltalk.
И, наверное, не случайно динамические языки до сих пор популярны и активно развиваются (Ruby и многие другие).
Спасибо за комментарий! Просто часто можно слышать про методы объектов класса в ООП и это вводит в заблуждение
Есть еще один момент: изначально в идее Алана Кея было определено, что объекты могут «развиваться» в течение времени жизни.
Это значит, что список сообщений, который может обработать объект, может меняться со временем.
Если говорить в современных терминах («метод объекта»), то что происходит, когда мы пытаемся вызвать метод, который не имеет смысла для текущего состояния объекта (текущего сочетания значений полей)?
В статических языках такой метод должен сгенерировать исключение вида InvalidOperationException:
Очевидно, что если возможно такое состояние объекта, при котором тот или иной метод является недопустимой операцией, то это архитектурная ошибка при разработке иерархии типов в соответствующем приложении.
Но гораздо хуже, если разработчик класса в таком случае, вместо генерации исключения, сразу вернет управление из метода (метод «ничего не делает», но клиентский код будет «думать», что метод отработал), и еще хуже, если в методе будет выполнена основная ветка кода на неконсистентных данных.
А что происходит в динамических языках?
Плюсы динамического подхода:
Это значит, что список сообщений, который может обработать объект, может меняться со временем.
Если говорить в современных терминах («метод объекта»), то что происходит, когда мы пытаемся вызвать метод, который не имеет смысла для текущего состояния объекта (текущего сочетания значений полей)?
В статических языках такой метод должен сгенерировать исключение вида InvalidOperationException:
The exception that is thrown when a method call is invalid for the object's current state.
Очевидно, что если возможно такое состояние объекта, при котором тот или иной метод является недопустимой операцией, то это архитектурная ошибка при разработке иерархии типов в соответствующем приложении.
Но гораздо хуже, если разработчик класса в таком случае, вместо генерации исключения, сразу вернет управление из метода (метод «ничего не делает», но клиентский код будет «думать», что метод отработал), и еще хуже, если в методе будет выполнена основная ветка кода на неконсистентных данных.
А что происходит в динамических языках?
- Когда какой-то метод теряет смысл для текущего состояния объекта, он удаляется из объекта (не из класса, а только из данного объекта).
- При попытке вызова метода автоматически генерируется исключение вида «нет такого метода».
Плюсы динамического подхода:
- Программисту не нужно в методе проверять, имеет ли метод смысл для текущего состояния объекта (устраняется «человеческий фактор»).
- Отсутствие метода и исключение вида «нет такого метода» семантически гораздо ближе к «не могу/не обработаю это сообщение», чем наличие метода и генерация внутри метода InvalidOperationException.
Машина, скорее всего, поедет, а лошадь скорее всего, нет — ей нужно сообщение «скакать галопом».
Помимо инкапсуляции (сведения функций и состояний в отдельный структурно-семантический «объём») в ООП ещё наличествуют абстракция, полиморфизм и наследование. Код, посылающий сообщения, скорее всего будет оперировать не конкретными объектами, а их обобщениями. То есть в его представлении будут не машины или лошади, а, например, транспортные средства. И сообщения, соответственно, будут — «переместиться» вместо «ехать» или «скакать». А как именно перемещаться (или не перемещаться) уже решат сами объекты, исходя из своего классового существа и актуального состояния. В этом главная практическая польза ООПа, иначе и огород было бы незачем городить.
Есть мнение, что наследование лишь одно из возможных (и не самое удачное) средств реализации полиморфизма и повторного использования кода.
Конечно, машина и лошадь вполне могут обработать сообщение «переместиться», если в заданной предметной области способ перемещения не важен, а вот здание класса «недвижимость» — нет.
Конечно, машина и лошадь вполне могут обработать сообщение «переместиться», если в заданной предметной области способ перемещения не важен, а вот здание класса «недвижимость» — нет.
Есть мнение, что наследование лишь одно из возможных (и не самое удачное) средств реализации…
Кто ж спорит. Однако, я думаю, что наследование — это в некотором роде золотая середина. С одной стороны, управляющий код может знать все объекты «в лицо» и манипулировать ими очень тонко в зависимости от индивидуальных особенностей (что требует весьма больших информационных затрат). С другой стороны, программа-оператор может вообще ничего не знать об объектах, с которыми работает (кроме того, что они объекты), и надеяться, что они «поймут» и обработают транслируемые команды-сообщения (здесь проблемы с обеспечением нужного результата — вроде как «моё дело прокукарекать, а там хоть не рассветай»). А вот если известен базовый класс управляемых объектов, мы получаем достаточную гарантию реализации абстрактных методов, т.е. заблаговременно знаем, какие сообщения будут обработаны подопечными объектами наверняка (что позволяет поднять уровень общей организации, особо не повышая сложность управляющего кода).
изначально имя сообщения (метода) задавалось вызывающей стороной,
А обработка сообщения осуществляется Господом Богом — или, всё-таки — кодом объекта?
Недавно на хабре была серия статей про Алана Кея и Smalltalk — можно обратиться к ним и почитать дополнительные материалы по Smalltalk.
«Изначальный» (первоначальный) язык ООП — это Симула, которая несколько раньше Алана Кея.
Хотя последний и придумал название «ООП».
В мифологическом сознании первобытного человека за каждым действием стоит сознательное существо
Нет. "Для мифологического сознания все, что существует — одушевлено." (википедия)
Например, машина едет по дороге только в рамках мифологического сознания, потому что на самом деле машина не обладает волей и не может куда-то ехать.
Вообще-то, нет. Чтобы ехать, не нужна воля.
Наш язык настроен на отражение мифологического сознания
С чего бы вдруг?
Собственно, из двух показанных выше неверных посылок вы и строите неверный вывод: "В ООП мифологическое сознание проникло в виде методов, которые должны выполняться определенными объектами определенных классов."
Нам трудно мыслить вне рамок мифологического сознания и потому кажется естественным, что объект класса «машины» обладает методом «ехать».
Человеку, который знаком с оригинальной концепцией Кея, и знает, что "метод "ехать" объекта "машина"" — это, на самом деле, сообщение "езжай" объекту "машина", это совершенно не кажется противоестественным и/или мифологичным. Есть актор, способный на конкретное действие, есть команда, его активирующая. Все логично.
Ключевой признак мифологического/магического/первобытного сознание — отсутствие цепочки выведения фактов (или категорий по Гегелю). Представление языковой пары «машина едет» как примера магического сознания и есть пример магического сознания, ибо это поверхностное представление. Что есть «машина»? Если у машины за рулём человек, она перестала быть машиной? Когда «машина едет», она с человеком за рулём один объект или нет?
Магическое сознание отличается тем, что «машина», и «дорога», и характеристика «едет» — монолитные сооружения в мыслях, неделимые, невыводимые, независимые. Язык здесь глубоко не при чём, без общественных установок/стереотипов язык нас ничему не учит, ни к чему не принуждает, он пуст, глух и бессмысленен.
Чтобы от магического состояния уйти, нужно приучить разум делать декомпозицию объектов и понятий автоматически. Даже если человек делает всего два шага разборки на составляющие, он уже не подвержен классическим ошибкам.
Монолитность мыслительных конструкций — признак, определяющий мифологическое сознание, из которого легко следуют и одушевление всего и вся, и святая вера в ритуал. Этот признак — часть мышления, не следующая из языковых навыков. Язык — продукт, а не основа. Например, категория «вещь в себе» очень хорошо ложится на традиционные выражения «ты не в себе!», «приди в себя!». То есть, язык подталкивает нас к кантовской философии, что ли?
P.S. Если интересно, как в действительности определить магическое сознание, рекомендую «Науку Логики» Гегеля,
Магическое сознание отличается тем, что «машина», и «дорога», и характеристика «едет» — монолитные сооружения в мыслях, неделимые, невыводимые, независимые. Язык здесь глубоко не при чём, без общественных установок/стереотипов язык нас ничему не учит, ни к чему не принуждает, он пуст, глух и бессмысленен.
Чтобы от магического состояния уйти, нужно приучить разум делать декомпозицию объектов и понятий автоматически. Даже если человек делает всего два шага разборки на составляющие, он уже не подвержен классическим ошибкам.
Монолитность мыслительных конструкций — признак, определяющий мифологическое сознание, из которого легко следуют и одушевление всего и вся, и святая вера в ритуал. Этот признак — часть мышления, не следующая из языковых навыков. Язык — продукт, а не основа. Например, категория «вещь в себе» очень хорошо ложится на традиционные выражения «ты не в себе!», «приди в себя!». То есть, язык подталкивает нас к кантовской философии, что ли?
P.S. Если интересно, как в действительности определить магическое сознание, рекомендую «Науку Логики» Гегеля,
Мне кажется, имеет смысл разделять мифологическое сознание и магическое мышление (во всяком случае попытки переосмыслить миф более-менее современном контексте осуществлялись и после Гегеля — скажем, Лосев или Барт). Миф (мифологиеское сознание) — это что-то вроде «зонда» восприятия, или такой специфический стиль осмысления. Не уверен, что его можно полностью вытравить из психики без высокого риска печальных последствий для последней. Например, свет лампочки накаливания для меня более уютен, тёпл, чем «казённый» свет классической люминесцентной лампы. Я могу до посинения декомпозировать этот факт, вспоминая электические схемы, закон Джоуля-Ленца, спектры электромагнитного излучения и т.п., раскапывая и рационализируя личный опыт (когда и с чего оно мне «прописалось») — квалитивное восприятие на уровне осчусчений останется таким же (а если и поменятеся, то целиком и сразу). Это мифологическое сознание. А вот если бы я искренне верил, что лампочкам самим по себе присуще эмоционально-температурное свойство (и лампочки таким образом мне что-то важное сообщают :)) — это было бы магическое мышление. Кстати, если при чтении этого текста у Вас (надеюсь) возникает какой-то относительно одушевлённый образ собеседника, это срабатывает мифологическое сознание (натурализатор концептов по Барту).
Спасибо за интересный комментарий! Моя статья — попытка за волосы поднять самого себя над мифологическим мышлением. Делается это исключительно в рамках задачи — построения расширяемой модели данных. Мне приходится отделять факты от их интерпретации. Причем на каком-то уровне ты начинаешь понимать, что само существование стула уже есть интерпретация. А, посмотрев далее, понимаешь, что и сам я — тоже плод интерпретации. Хорошо, что для целей моделирования мне это знание не нужно, иначе все начнется с того, что было слово и слово было… (непроизносимо)
Я хочу подчеркнуть, что процесс — это функция без актора, и, также как функция, — не имеет начала и конца в рамках существующего контекста.Можно ссылку на первоисточник такого определения процесса?
Такое чувство, что в учреждении галоперидол закончился…
Вот очень жаль что я пропустил обсуждение и статью про (любимого очень мною) Витгенштейна, так что тут оторвусь выскажусь.
Мир конечно это совокупность фактов, а не вещей. Факты связывают объекты (вещи). Здесь можно соглашаться. А дальше начинается разница, программирование и ООП в частности в свою очередь не настолько примитивны, насколько кажется. Если углубляться в Витгенштейна, то язык (программирования, моделирования и чего угодно) состоит в некотором отношении с миром и предложения на нём отражают факты, да. И Договор.закрыть() — это тоже факт, хотя он может и не совпадать с миропредставлением отдельно взятого бухгалтера. Просто это не тот договор, который у бухгалтера. Испытывать зуд при этом не стоит.
Если я правильно понял, вы считаете что процессное описание ближе к реальному описанию мира потому что нет «управляющего» объекта? В любом случае, в ООП его тоже нет. В нём нет объекта «мир» (хотя можно и завести), и в нем можно завести объект «процесс». Почему кто-то (автор программы в конечном итоге) просит что-то сделать объект, а не объект «делает сам»? Потому что программирование — это НЕ моделирование!!! Попробуйте создать модель, которая изменит состояние моделируемого объекта. Сможете? Нет.
Вся хрень в том, что Витгенштейна никто не дочитывает до конца. Есть у Дмитрия Гайдука такой рассказ (аудио), «про слова». Заканчивается тем, что (эвфемизмы) «слово само по себе фигня, важно как оно сказано, где и в какой момент. И конец». У Витгенштейна же одна из мыслей что перестановки слов ничего не меняют в мире, потому что это модель. Как только слово начинает что-то менять, оно становится объектом, как и всё в ООП. И конец.
Мир конечно это совокупность фактов, а не вещей. Факты связывают объекты (вещи). Здесь можно соглашаться. А дальше начинается разница, программирование и ООП в частности в свою очередь не настолько примитивны, насколько кажется. Если углубляться в Витгенштейна, то язык (программирования, моделирования и чего угодно) состоит в некотором отношении с миром и предложения на нём отражают факты, да. И Договор.закрыть() — это тоже факт, хотя он может и не совпадать с миропредставлением отдельно взятого бухгалтера. Просто это не тот договор, который у бухгалтера. Испытывать зуд при этом не стоит.
Если я правильно понял, вы считаете что процессное описание ближе к реальному описанию мира потому что нет «управляющего» объекта? В любом случае, в ООП его тоже нет. В нём нет объекта «мир» (хотя можно и завести), и в нем можно завести объект «процесс». Почему кто-то (автор программы в конечном итоге) просит что-то сделать объект, а не объект «делает сам»? Потому что программирование — это НЕ моделирование!!! Попробуйте создать модель, которая изменит состояние моделируемого объекта. Сможете? Нет.
Вся хрень в том, что Витгенштейна никто не дочитывает до конца. Есть у Дмитрия Гайдука такой рассказ (аудио), «про слова». Заканчивается тем, что (эвфемизмы) «слово само по себе фигня, важно как оно сказано, где и в какой момент. И конец». У Витгенштейна же одна из мыслей что перестановки слов ничего не меняют в мире, потому что это модель. Как только слово начинает что-то менять, оно становится объектом, как и всё в ООП. И конец.
Потому что программирование — это НЕ моделирование!!!
Мой пост об этом же. И тезис был для тех, кто считает, что при помощи нотаций UML он моделирует реальный мир, а не программный код. Я считаю, что ООП — это про программу, а не про реальный мир. И, если так, то я спокоен, но очень часто (слишком часто) я слышу, что давайте построим диаграмму классов для описания реального мира (с наследованием и прочей требухней, которой в реальном мире нет и быть не может). И вот тогда я с удивлением обнаруживаю, что по-прежнему жив миф об ООП как о способе моделирования мира.
Ну тогда я вас немного не в том ключе понял. Возможно вы были излишне кратки :) В любом случае читаю ваши публикации с интересом.
Просто мы знаем, кто такие системные аналитики — те, кто могут построить модели в нотациях UML, но вот кто такие бизнес-аналитики, которые должны строить модели предметных областей, нам неизвестно, потому что для них не придумали языка и методики описания предметных областей.Вот и приходится брать, что дают, чтобы из говна и палок слепить модель. Лично меня это не устраивает и я пытаюсь придумать что-то удобное для бизнес-анализа
Чем не устраивает BPMN? Лучше пока ничего нет, и в общем далеко не самое плохое из возможного.
Собственно сложность бизнес-аналитики не в столько в отсутствии инструментария на мой взгляд, а в огромном разнообразии (нет, не видов бизнеса, а) инструментария управления бизнесом. Все их вариации и комбинации приводят к тому, что каждая организация — этакий франкештейн, у которого некоторые конечности созрели больше, чем другие, и это ломает любые нотации.
Елиферов и Репин в своей книге про процессное моделирование писали, что можно (и может быть даже нужно) придумывать свои нотации под случай, главное чтобы они были доступными. Сами понимаете, чем универсальнее способ описания, тем сложнее в нём будет описана каждая деталь. И наоборот — чем детальнее способ описания, тем менее он универсален (и второй проект его окончательно доломает).
Я в своей практике бизнес-анализа «на общественных началах» понял, что лучше таких вещей как runthemodel.com я вряд ли что найду, поэтому и вам рекомендую жить в системной парадигме (которая как никак сейчас основная). Крутить концепции 100-летней давности любопытно, но у них был другой бэкграунд, и они были заточены под решение других противоречий.
Собственно сложность бизнес-аналитики не в столько в отсутствии инструментария на мой взгляд, а в огромном разнообразии (нет, не видов бизнеса, а) инструментария управления бизнесом. Все их вариации и комбинации приводят к тому, что каждая организация — этакий франкештейн, у которого некоторые конечности созрели больше, чем другие, и это ломает любые нотации.
Елиферов и Репин в своей книге про процессное моделирование писали, что можно (и может быть даже нужно) придумывать свои нотации под случай, главное чтобы они были доступными. Сами понимаете, чем универсальнее способ описания, тем сложнее в нём будет описана каждая деталь. И наоборот — чем детальнее способ описания, тем менее он универсален (и второй проект его окончательно доломает).
Я в своей практике бизнес-анализа «на общественных началах» понял, что лучше таких вещей как runthemodel.com я вряд ли что найду, поэтому и вам рекомендую жить в системной парадигме (которая как никак сейчас основная). Крутить концепции 100-летней давности любопытно, но у них был другой бэкграунд, и они были заточены под решение других противоречий.
Некропост, но все же не удержусь.
Посмотрите в сторону ArchiMate. Летом вышла версия 3.0. Похоже, что создателям стандарта таки удалось ухватить необходимую и достаточную метамодель, которая позволяет описывать именно предметные области (деятельность), а не отдельные процессы или создавать отдельные модели. Выделение пассивных структур, активных структур и поведения и перпендикулярных им слоев (бизнес, софт, хард) позволяет весьма полно описать многие и многие аспекты как предметной области так и конкретного предприятия. А встроенная в стандарт концепция точек зрения (viewpoint) позволяет создать множество описаний одного и того же понятия.
Сам познакомился с этим стандартом примерно два года назад и с тех пор все больше и больше убеждаюсь в его выразительности и мощности.
Чем не устраивает BPMN? Лучше пока ничего нет, и в общем далеко не самое плохое из возможного.
Посмотрите в сторону ArchiMate. Летом вышла версия 3.0. Похоже, что создателям стандарта таки удалось ухватить необходимую и достаточную метамодель, которая позволяет описывать именно предметные области (деятельность), а не отдельные процессы или создавать отдельные модели. Выделение пассивных структур, активных структур и поведения и перпендикулярных им слоев (бизнес, софт, хард) позволяет весьма полно описать многие и многие аспекты как предметной области так и конкретного предприятия. А встроенная в стандарт концепция точек зрения (viewpoint) позволяет создать множество описаний одного и того же понятия.
Сам познакомился с этим стандартом примерно два года назад и с тех пор все больше и больше убеждаюсь в его выразительности и мощности.
Спасибо! До сих пор я лишь выступал в роли того, кто находит ошибки в нотациях, а не в роли того, кто наслаждается моделированием.
Попробуйте смоделировать в ArchiMate что-то настоящее и сложное, а не пример из учебника. Только тогда раскрывается вся мощь языка.
Когда получается в одну модель (но естественно на несколько диаграмм) уложить несколько уровней абстракции функций и объектов предметной области, и помимо этого еще и показать какими средствами автоматизируется та или иная функция (и какими программными объектами выражается тот или иной бизнес-объект). А если еще есть инструментальная поддержка навигации по этой модели (как например это умеет Sparx Enterprise Architect). Вот тогда понимаешь что значит комплексное моделирование с учетом разных точек зрения.
Когда получается в одну модель (но естественно на несколько диаграмм) уложить несколько уровней абстракции функций и объектов предметной области, и помимо этого еще и показать какими средствами автоматизируется та или иная функция (и какими программными объектами выражается тот или иной бизнес-объект). А если еще есть инструментальная поддержка навигации по этой модели (как например это умеет Sparx Enterprise Architect). Вот тогда понимаешь что значит комплексное моделирование с учетом разных точек зрения.
Ага, нашел вашу статью про то, чем не устраивает BPMN (и до кучи диаграммы Гантта). Конкретно в том случае (когда индивидуальные проекты недалеки от типовых), всё решается понятием шаблона. Шаблонизация встречается много где, и по сути является в моделировании… моделью моделируемого.
Поэтому «до некоторой степени универсальный» «описатель» должен в себе содержать возможности по шаблонизации. Это немного отличная от ООП концепция, и по сути называется в экономике и менеджменте параметризацией.
Поэтому «до некоторой степени универсальный» «описатель» должен в себе содержать возможности по шаблонизации. Это немного отличная от ООП концепция, и по сути называется в экономике и менеджменте параметризацией.
Да, шаблон — есть модель модели. Но в ИТ, а также у консультантов на эту тему полная каша. Они на одну доску ставят модели и модели моделей, смешивая уровни абстракции.
Кроме того, я прошу правильно меня понять — я не занимаюсь вопросами управления или инструментами управления бизнесом. Я строю модели описания активности, которые потом могут быть применены в качестве инструмента управления бизнесом, но сами по себе таковыми не являются. Проблема консультантов в том, что они сразу переходят к интерпретации данных, пропустив шаг сбора данных. Это приводит к избирательному видению и ограниченности мышления
Кроме того, я прошу правильно меня понять — я не занимаюсь вопросами управления или инструментами управления бизнесом. Я строю модели описания активности, которые потом могут быть применены в качестве инструмента управления бизнесом, но сами по себе таковыми не являются. Проблема консультантов в том, что они сразу переходят к интерпретации данных, пропустив шаг сбора данных. Это приводит к избирательному видению и ограниченности мышления
При определённом уровне развития и семантика может казаться магией. Машина (как автомобиль) это семантическая конструкция обобщающая определённый тип средств передвижения. Возможно в детском возрасте она может иногда восприниматься в мифологическом аспекте, и её можно “по-человечески” попросить ехать быстрее, но обычно в утилитарном использовании взрослый человек воспринимает слово “машина” как удобный ярлык, не требующий сложного разъяснения при использовании и обходящийся без мифологических коннотаций и одушевлений.
Вы обнаружили корреляцию и сделали из неё далеко идущие выводы, всё потому что мифология “паразитирует” на семантике, а нас с детства учат что мифологический подход самый низкозатратный при объяснении не вполне ясных явлений.
Ну, а ООП это лишь семантическая методика, не мифологический подход, попытка смешать одно с другим приводит к концепции магии, а здесь и до Гарри Поттера недалеко, и это не комплимент.
Вы обнаружили корреляцию и сделали из неё далеко идущие выводы, всё потому что мифология “паразитирует” на семантике, а нас с детства учат что мифологический подход самый низкозатратный при объяснении не вполне ясных явлений.
Ну, а ООП это лишь семантическая методика, не мифологический подход, попытка смешать одно с другим приводит к концепции магии, а здесь и до Гарри Поттера недалеко, и это не комплимент.
«Машина едет» означает (может означать) что машина движется «сама», без наличия внешних побуждающих сил.
Сиречь источник её движения находится внутри неё самой — а не снаружи, как в случае телеги, кареты или лошади.
Точно так же часы с кукушкой отсчитывают время и кукуют необходимое количество раз — в силу «внутренних причин», своего устройства, а не желания кого-то снаружи.
То же самое относится и к компьютеру, который исполняет программу в силу своих «внутренних» причин — а не чего-то внешнего.
Разумеется, можно трактовать эту ситуацию и мифологически — что «машина — вещь одушевлённая», но это другое.
Сиречь источник её движения находится внутри неё самой — а не снаружи, как в случае телеги, кареты или лошади.
Точно так же часы с кукушкой отсчитывают время и кукуют необходимое количество раз — в силу «внутренних причин», своего устройства, а не желания кого-то снаружи.
То же самое относится и к компьютеру, который исполняет программу в силу своих «внутренних» причин — а не чего-то внешнего.
Разумеется, можно трактовать эту ситуацию и мифологически — что «машина — вещь одушевлённая», но это другое.
Источником движения машины может быть что угодно, — мы не знаем что именно, но лишь догадываемся. Мы можем сказать, что участвует в движении машины: дорога, водитель, машина, воздух, другие машины, другие водители и проч., но сказать в чем причина ее передвижения — не можем, потому что это лишь наша гипотеза в текущий момент времени при текущем уровне знаний и представлений. Для бизнеса не нужна модель причин, но нужна модель фактов, фактов без интерпретации их. А лишь потом тот, кто хочет, может интерпретировать эти факты так, как захочет
Для бизнеса не нужна модель причин, но нужна модель фактов, фактов без интерпретации их. А лишь потом тот, кто хочет, может интерпретировать эти факты так, как захочет
Бхы, какой субъективный идеализм…
А что такое «факты» в Вашем мистическом мироощущении?
Их приносит в клювике Господь Бог?
«Факты» без отслеживания причинно-следственных связей, без возможности «поиграть» с ними, попытаться их опровергнуть — не отличимы от «не-фактов» ни для кого, акромя Господа Бога.
А семантика естественных языков — размазана.
Т.е. глагол «едет» может означать, что объект «движется по твёрдой поверхности», да ещё, скорее всего — «на колёсах», в противоположность «плывёт», летит" или «идёт».
А может означать именно «движение в силу внутренних причин» — в противопоставлении с «катится».
Т.е. подразумевается, что парус, к примеру — был выставлен специально и каким-то образом управляется.
Факты собирает следователь, оценку им дает судья. Моя задача — построить модель для следователя. Давать оценку будут разные стейкхолдеры и получать разные результаты, но это уже второй шаг. Я же вижу, что первый шаг в моделировании просто пропускается и сразу переходят ко второму — даче оценок. Но тогда нельзя на основе такой модели построить представления разных точек зрения, и ценность модели резко падает. Как минимум, она становится нерасширяемой.
Если следователь не будет задумываться о том, как и на основании чего судья даёт оценку собранным следователем фактам (на самом деле работа следователя отнюдь не сводится к сбору улик) — то судья будет постоянно давать негативную оценку собранным следователем «фактам», а последнее — будет поводом для постановки вопроса о профнепригодности данного «следователя».
Играть эту игру в стеке разработки можно дольше — но, в конце-концов — работа продукта, созданного на основании Ваших предсказаний окажется некорректной — и те, кто им пользовался — окажутся у разбитого корыта.
Сиречь заботиться о корректности и единстве модели, на основании которой Вы взаимодействуете с дальнейшими этапами разработки — в том числе и Ваша задача, и Ваш интерес.
P.S. А называть первичные данные — «фактами» — это очень сильно льстить им.
Играть эту игру в стеке разработки можно дольше — но, в конце-концов — работа продукта, созданного на основании Ваших предсказаний окажется некорректной — и те, кто им пользовался — окажутся у разбитого корыта.
Сиречь заботиться о корректности и единстве модели, на основании которой Вы взаимодействуете с дальнейшими этапами разработки — в том числе и Ваша задача, и Ваш интерес.
P.S. А называть первичные данные — «фактами» — это очень сильно льстить им.
Возможно Вы правы, но это значит, что я плохо донес мысль. Как только мы говорим «машина едет», мы даем такую интерпретацию событиям, которую потом будет сложно переделать в «водитель катится в машине». Поэтому кто катится и почему — вопрос второй, но и в первом и во втором случае участники у нас одни и те же. Фиксация этих участников и есть факты, а приписывание им ролей — это интерпретация.
Здесь какой-то уже совсем глубокий уход от обычной семантики русского языка.
Сказать «водитель катится в машине» — как-то совсем нельзя.
«Водитель катается на машине» — т.е. передвигается бесцельно, с целью получить удовольствие от самого процесса «катания».
«Водитель катается в машине» — боюсь, что он потерял сознание, и его тело безвольно катается по полу кабины.
В общем, Ваша градация, мягко говоря — нечёткая и неоднозначная.
А описание без выявления причинно-следственных связей — неполное по-определению.
Сказать «водитель катится в машине» — как-то совсем нельзя.
«Водитель катается на машине» — т.е. передвигается бесцельно, с целью получить удовольствие от самого процесса «катания».
«Водитель катается в машине» — боюсь, что он потерял сознание, и его тело безвольно катается по полу кабины.
В общем, Ваша градация, мягко говоря — нечёткая и неоднозначная.
А описание без выявления причинно-следственных связей — неполное по-определению.
Выявление участников — первый шаг, второй — интерпретация их участия с разных точек зрения, сравнение разных точек зрения, проведение анализа с учетом интересов разных стейкхолдеров. Строить модель только с точки зрения одного стейкхолдера — обречь себя на нерасширяемость модели и на невозможность ее анализа.
Гхм.
Давайте начнём с базы.
Мир есть совокупность объектов, которые вступают в отношения.
(Ну и ещё объекты имеют свойства; иногда свойства непросто отличить от отношений.)
Факты — это некоторые высказывания относительно объектов внешнего мира, их свойств и отношений — которые являются истинными.
Например, «машина едет [по дороге]» — это высказывание — и, возможно — факт.
Хотя немножЭчко и интерпретация — ибо можно «снизить» уровень высказывания — «положение машины [относительно дороги] изменяется».
При этом первичными данными будет набор отметок о положении объекта «машина» относительно объекта «дороги», к примеру.
Стейкхолдеры — это не столько «объекты:, сколько категории, т.е. множества объектов, обладающих неким общим свойством, интересующим нас в текущей ситуации.
Стейкхолдеры — это часть объектов всего окружающего мира, плюс у нас всегда существует „окружающая среда“ (та же дорога, к примеру) — и возможны „случайные участники“ — например, на дорогу перед машиной выбегает пешеход или корова.
Ну и плюс — у „окружающей среды“ могут быть „состояния“ — т.е. свойства.
Дождь, туман или гололёд на дороге.
Т.е., в общем-то это тоже может быть рассмотрено как объекты — но проще и удобнее рассматривать их в качестве „свойств среды“.
Вопрос, включать ли „случайных участников“ или „окружающую среду“ в число стейкхолдеров — или отнесения тех или иных явлений в какую-либо из категорий есть вопрос философский, т.е. сильно зависит от конкретных условий задачи.
Ну и плюс — весь процесс классифицирования есть процесс итеративный, в котором стадии „выявления участников“ и определения их взаимоотношений — взаимосвязаны, и полноценно существовать друг без друга не могут.
Как-то так, мне кажется.
Давайте начнём с базы.
Мир есть совокупность объектов, которые вступают в отношения.
(Ну и ещё объекты имеют свойства; иногда свойства непросто отличить от отношений.)
Факты — это некоторые высказывания относительно объектов внешнего мира, их свойств и отношений — которые являются истинными.
Например, «машина едет [по дороге]» — это высказывание — и, возможно — факт.
Хотя немножЭчко и интерпретация — ибо можно «снизить» уровень высказывания — «положение машины [относительно дороги] изменяется».
При этом первичными данными будет набор отметок о положении объекта «машина» относительно объекта «дороги», к примеру.
Стейкхолдеры — это не столько «объекты:, сколько категории, т.е. множества объектов, обладающих неким общим свойством, интересующим нас в текущей ситуации.
Стейкхолдеры — это часть объектов всего окружающего мира, плюс у нас всегда существует „окружающая среда“ (та же дорога, к примеру) — и возможны „случайные участники“ — например, на дорогу перед машиной выбегает пешеход или корова.
Ну и плюс — у „окружающей среды“ могут быть „состояния“ — т.е. свойства.
Дождь, туман или гололёд на дороге.
Т.е., в общем-то это тоже может быть рассмотрено как объекты — но проще и удобнее рассматривать их в качестве „свойств среды“.
Вопрос, включать ли „случайных участников“ или „окружающую среду“ в число стейкхолдеров — или отнесения тех или иных явлений в какую-либо из категорий есть вопрос философский, т.е. сильно зависит от конкретных условий задачи.
Ну и плюс — весь процесс классифицирования есть процесс итеративный, в котором стадии „выявления участников“ и определения их взаимоотношений — взаимосвязаны, и полноценно существовать друг без друга не могут.
Как-то так, мне кажется.
С точки зрения формальной логики в конструкции «водитель катится в машине» больше «магии», чем в конструкции «машина едет».
По сути это комбинация установленной связи водитель-машина (водитель в машине) и состояния машины (едет).
В данном процессе осуществляется обмен управляющими воздействиями. Водитель воздействует на управляющие органы машины, сообщая ей свои требования, а машина перемещает водителя в соответствии с измененным после получения управляющего «сообщения» от водителя внутренним состоянием.
По сути это комбинация установленной связи водитель-машина (водитель в машине) и состояния машины (едет).
В данном процессе осуществляется обмен управляющими воздействиями. Водитель воздействует на управляющие органы машины, сообщая ей свои требования, а машина перемещает водителя в соответствии с измененным после получения управляющего «сообщения» от водителя внутренним состоянием.
Точно так же часы с кукушкой отсчитывают время и кукуют необходимое количество раз — в силу «внутренних причин», своего устройства, а не желания кого-то снаружи.
Но как же, взводил их вполне конкретный человек, который хотел, чтобы с определенной периодичностью кукушка куковала.
Аналогично и с машиной, которая едет. У нее может быть не только мотор и топливо, но и блок автоматической подачи, этот блок может даже сам принимать решение, очень запутанное, основанное на обучении. В один прекрасный день вы выходите, а она угадывает, что нужно подъехать именно сейчас. Но все же, когда-то ее запустили и это все тот же механизм, который взвели на заводе чьей-то конкретной рукой. Возможно даже механической, но и она в свою очередь тоже была кем-то создана.
Означает ли это, что «одушевленность» определяется простой невозможностью отследить первопричину движения?
Но как же, взводил их вполне конкретный человек
Их может взводить не только человек, и не обязательно конкретный человек — результат их работы от этого ничуть не изменится.
Я называю такие вещи «автономными системами» — т.е. алгоритм их функционирования определяется их внутренним устройством, из внешней среды приходят только некие достаточно простые вещи.
Но все же, когда-то ее запустили и это все тот же механизм, который взвели на заводе чьей-то конкретной рукой. Возможно даже механической, но и она в свою очередь тоже была кем-то создана.
Это не имеет значения.
Означает ли это, что «одушевленность» определяется простой невозможностью отследить первопричину движения?
Понятие «одушевлённости» вообще никак не возможно определить — бо мы не знаем на сегодня, что такое «душа». Для меня и собака и кошка — имеют душу, а для кого-то не всякий человек — одушевлён.
Но если в корректном описании объекта понятия «душа» можно избежать — то его следует избегать.
Любая машина работает в соответствии с физическими законами, и эти законы могут быть познаны и использованы при её изготовлении.
С практической точки зрения оказывается не важно, кто и что делает в активности. Главное — кто и что участвует в активности. И тогда модель становится симметричной — есть участники активности и состояния объектов, более ничего, но ничего более нам и не надо. Интересно, что попытки найти акторов, результаты и проч — лишние. Для анализа активности это несущественно. Но мы все равно продолжаем цепляться за мифологические представления об акторах, совершающих деяния
Какие-то странные посылки и выводы.
1. Машина едет — это ни магическое, ни мифологическое сознание. Это не более чем утверждение, заостряющее внимание на соединенин предмета и действия.
Если машина едет, то это не обязательно ее воля или даже функция (это вполне может быть просто побочный эффектом).
И также это не означает, что высказывающийся не имеет понятия о причинах и процессе «ехать» и о внутреннем устройстве, позволяющем машине выполнять это действие.
2. Следует разделять ООП и инструменты для его реализации.
Суть ООП — описание взаимодействия между объектами путем передачи ими друг другу уведомлений.
Классы в «ООП языках» являются всего лишь инструментом, позволяющим описать поведение объекта, выделив его в программе синтаксисом языка. А вызов метода всего лишь реализует частный случай обмена уведомлениями, когда вызывающая сторона уведомляет о необходимости выполнить действие, а вызываемый объект рапортует о результате (причем второе не обязательно).
Исключения же не являются частью объектной модели.Они нужны только для того, чтобы обработать ситуацию, когда реальное взаимодействие объектов вошло в противоречие с созданным программистом описанием в виде программы.
Конечно, классы с методами не покрывают всего многообразия возможных сценариев взаимодействия объектов. Но никто не мешает реализовать недостающие инструменты для реализации всего остального самому или воспользоваться готовыми решениями.
1. Машина едет — это ни магическое, ни мифологическое сознание. Это не более чем утверждение, заостряющее внимание на соединенин предмета и действия.
Если машина едет, то это не обязательно ее воля или даже функция (это вполне может быть просто побочный эффектом).
И также это не означает, что высказывающийся не имеет понятия о причинах и процессе «ехать» и о внутреннем устройстве, позволяющем машине выполнять это действие.
2. Следует разделять ООП и инструменты для его реализации.
Суть ООП — описание взаимодействия между объектами путем передачи ими друг другу уведомлений.
Классы в «ООП языках» являются всего лишь инструментом, позволяющим описать поведение объекта, выделив его в программе синтаксисом языка. А вызов метода всего лишь реализует частный случай обмена уведомлениями, когда вызывающая сторона уведомляет о необходимости выполнить действие, а вызываемый объект рапортует о результате (причем второе не обязательно).
Исключения же не являются частью объектной модели.Они нужны только для того, чтобы обработать ситуацию, когда реальное взаимодействие объектов вошло в противоречие с созданным программистом описанием в виде программы.
Конечно, классы с методами не покрывают всего многообразия возможных сценариев взаимодействия объектов. Но никто не мешает реализовать недостающие инструменты для реализации всего остального самому или воспользоваться готовыми решениями.
Мы находимся в мире, который описывается четырехмерным пространством-временем. Для моделирования этого мира нам не надо прибегать к термину «соединение объекта и действия», который был бы уместен в эпоху Аристотеля, но совсем не уместен в 21 веке. Дело в том, что в четырехмерном мире нет объектов без действий и действий без объектов. Объекты и действия — одно и то же. На этом стоит стандарт ИСО 15926 и это позволяет моделировать мир при помощи теории множеств. Иначе — добро пожаловать в Древнюю Грецию!
Суть ООП в описании кода, но не предметного мира. Я дал коммент насчет ООП только для того, чтобы подчеркнуть, насколько ООП далек от моделирования реального мира.
Суть ООП в описании кода, но не предметного мира. Я дал коммент насчет ООП только для того, чтобы подчеркнуть, насколько ООП далек от моделирования реального мира.
Во-первых, мы соединяем не объект и действие, а предмет и действие.
А это объекты разных категорий.
Во-вторых, тот факт, что объект не существует без действия не делает некоторое конкретное действие объекта необходимым в нашей модели (например, нам может быть совершенно безразлично, что машина не только едет, но и издает звуки).
Далее, соединение предмета и действия является не более чем элементом процесса построения модели, когда ма соединяем нужные действия с нужными предметами, игнорируя те, которыми можно пренебречь.
Ну и утверждение, что объекты и действия суть одно и то же, как мне представляется, некорректно. Пусть объект не существует без действия, но он может быть чем-то бОльшим, чем одно лишь действие.
Что же до соотношения ООП, моделирования и описания кода, то, может быть, я отстал от жизни и не заметил упрощения понятия «программирование», но я как-то привык считать создание модели предметной области неотъемлемой частью процесса пиограммирования, а потому привык распространять понятие ООП и на этот этап.
А это объекты разных категорий.
Во-вторых, тот факт, что объект не существует без действия не делает некоторое конкретное действие объекта необходимым в нашей модели (например, нам может быть совершенно безразлично, что машина не только едет, но и издает звуки).
Далее, соединение предмета и действия является не более чем элементом процесса построения модели, когда ма соединяем нужные действия с нужными предметами, игнорируя те, которыми можно пренебречь.
Ну и утверждение, что объекты и действия суть одно и то же, как мне представляется, некорректно. Пусть объект не существует без действия, но он может быть чем-то бОльшим, чем одно лишь действие.
Что же до соотношения ООП, моделирования и описания кода, то, может быть, я отстал от жизни и не заметил упрощения понятия «программирование», но я как-то привык считать создание модели предметной области неотъемлемой частью процесса пиограммирования, а потому привык распространять понятие ООП и на этот этап.
Со стороны складывается впечатление, что вы пытаетесь забивать гвозди экскаватором. Языки развившиеся естественным путем несут в себе семантическую неоднозначность, исходя из самой концепции их построения — слова в них, это всегда кодировка определенных образов, которая дает возможность толковать практически любую информацию с разными контекстами. Чтобы это преодолеть, необходимо выработать иную концепцию языка\схем представления данных\etc.., в которой будут кодироваться только четкие и однозначные понятия. Однако, не все в нашем мире можно описать «абсолютно точно» и «с вероятностью 13,333(3)%».
И мифологическое сознание тут совершенно не причем.
И мифологическое сознание тут совершенно не причем.
статья краткая — это плюс.
минус — так и не понял какую проблему поднял автор в статье и как предложил ее решить.
минус — так и не понял какую проблему поднял автор в статье и как предложил ее решить.
Спасибо за ответ. Хочу поделиться мыслью об:
Предлагаю понятие «сознание» убрать из рассмотрения вообще, достаточно «мышление». Меньше путаницы будет.
«Одушевленное/неодушевленное» тоже не использовать, это рудиментарные понятия только усугубляющие путаницу.
вместо «мифологическое мышление» использовать понятие «обьектно-субъекнтый подход»:
есть обьект/субьект который получив на вход А (аргументы и имя метода в ООП, заклинание в магии, удар в физике, добавление воды в химии..) выдает Б ( выполнение другого метода в ООП, действие силы в магии, движение в физике, растворение в химии… ).
вся суть подхода в том, что можно прогнозировать ожидаемый исход от действия, зная набор формул (правил, теорию) какие А вызывают какие Б.
Это дает возможность построить модель предметной области и более-менее еффективно в ней моделировать ее и свое поведение.
этот подход самый древний, разработан еще первобытными, которые рисовали оленей на стенах пещер и первые слова языков. но работает и по сегодня как самый массово доступный и применяемый.
Другой подход — системный. появился недавно и еще в разработке. громоздкий в оперировании, теоретически еще не проработанный, возможно в человеческой логике (логике человеческих языков) и вовсе окажется неподъемным. Но уже неплохо показывает себя в компьютерных системах (модели не нейросетях).
Других подходов насколько помню не известно.
Итого, остается по знаменитому принципу «разделяй и властвуй», нарезать из реальности небольшие слабо связанные между собой сектора, для которых строить языковые модели с более-менее однозначными иерархически сгруппированными наборами понятий и в них работать в объектно-субъектном подходе.
и помнить, что многие понятия из разных моделей при похожем написании несут достаточно различающуюся смысловую нагрузку…
Нам трудно мыслить вне рамок мифологического сознания… Но по сути своей — этот способ мышления — попытка одушевить неодушевленное.
Предлагаю понятие «сознание» убрать из рассмотрения вообще, достаточно «мышление». Меньше путаницы будет.
«Одушевленное/неодушевленное» тоже не использовать, это рудиментарные понятия только усугубляющие путаницу.
вместо «мифологическое мышление» использовать понятие «обьектно-субъекнтый подход»:
есть обьект/субьект который получив на вход А (аргументы и имя метода в ООП, заклинание в магии, удар в физике, добавление воды в химии..) выдает Б ( выполнение другого метода в ООП, действие силы в магии, движение в физике, растворение в химии… ).
вся суть подхода в том, что можно прогнозировать ожидаемый исход от действия, зная набор формул (правил, теорию) какие А вызывают какие Б.
Это дает возможность построить модель предметной области и более-менее еффективно в ней моделировать ее и свое поведение.
этот подход самый древний, разработан еще первобытными, которые рисовали оленей на стенах пещер и первые слова языков. но работает и по сегодня как самый массово доступный и применяемый.
Другой подход — системный. появился недавно и еще в разработке. громоздкий в оперировании, теоретически еще не проработанный, возможно в человеческой логике (логике человеческих языков) и вовсе окажется неподъемным. Но уже неплохо показывает себя в компьютерных системах (модели не нейросетях).
Других подходов насколько помню не известно.
Итого, остается по знаменитому принципу «разделяй и властвуй», нарезать из реальности небольшие слабо связанные между собой сектора, для которых строить языковые модели с более-менее однозначными иерархически сгруппированными наборами понятий и в них работать в объектно-субъектном подходе.
и помнить, что многие понятия из разных моделей при похожем написании несут достаточно различающуюся смысловую нагрузку…
пример понятий из разных моделей знаний, выраженных одним и тем же термином:
скорость (движения) в физике — целое семейство понятий (средняя с., моментальная с.) связывает расстояние со временем при движении тела.
скорость (реакции) в химии — связывает время реакции с составом хим. реактивов и условиями реакции (температура, давление..) (расстояние выпало)
скорость схождения числового ряда — связывает кол-во елементов ряда с точностью схождения (и время и пространство выпали).
если свести их в «единое» понятие — получится что-то настолько абстрактное (зависимость одной величины какого-то явления от нескольких других величин), что оно захватит и множество других понятий и будет практически неприменимо для прикладного мышления внутри моделей… сольется с понятием зависимость или функция…
Да, все что написал и пишу -это ИМХО, не претендующее на исключительную истину общего употребления,
это только полуфабрикаты моего мышления в поисках теории знания, информации… (вдруг кто иначе воспримет, минусовать начнет из-за несогласия)
скорость (движения) в физике — целое семейство понятий (средняя с., моментальная с.) связывает расстояние со временем при движении тела.
скорость (реакции) в химии — связывает время реакции с составом хим. реактивов и условиями реакции (температура, давление..) (расстояние выпало)
скорость схождения числового ряда — связывает кол-во елементов ряда с точностью схождения (и время и пространство выпали).
если свести их в «единое» понятие — получится что-то настолько абстрактное (зависимость одной величины какого-то явления от нескольких других величин), что оно захватит и множество других понятий и будет практически неприменимо для прикладного мышления внутри моделей… сольется с понятием зависимость или функция…
Да, все что написал и пишу -это ИМХО, не претендующее на исключительную истину общего употребления,
это только полуфабрикаты моего мышления в поисках теории знания, информации… (вдруг кто иначе воспримет, минусовать начнет из-за несогласия)
Благодарю за полезную статью!
Немного выйду за пределы программирования.
При анализе в любом проекте столкнулся именно с проблемой мифологичного сознания.
Ученые, разработчики, аналитики, причем неплохого уровня уверены, что в материальном мире есть объекты, частицы, «черные дыры» и т. п. И это серьезная проблема!
Они уверены, что модели в мифологическом сознании есть в реальности!
Достучаться до них очень сложно!
Очень помогает стандарт ISO 81346, но только для технических специалистов.
У ученых, физиков, химиков такая каша в голове, что просто дым и чад.
Я сам столкнулся с проблемой вменяемой информации на темы объектно-ориентированного мышления.
Если есть какие-то ресурсы — просьба поделиться.
Немного выйду за пределы программирования.
При анализе в любом проекте столкнулся именно с проблемой мифологичного сознания.
Ученые, разработчики, аналитики, причем неплохого уровня уверены, что в материальном мире есть объекты, частицы, «черные дыры» и т. п. И это серьезная проблема!
Они уверены, что модели в мифологическом сознании есть в реальности!
Достучаться до них очень сложно!
Очень помогает стандарт ISO 81346, но только для технических специалистов.
У ученых, физиков, химиков такая каша в голове, что просто дым и чад.
Я сам столкнулся с проблемой вменяемой информации на темы объектно-ориентированного мышления.
Если есть какие-то ресурсы — просьба поделиться.
«Машина едет по дороге» — эта конструкция не описывает действие машины на дорогу, соответственно, она не имеет никакого отношения к определению функции машины.
Если мы хотим определить функцию машины, то должны определить: 1) объект, на который направлено действие машины; 2) определить само действие. Используя эту схему, мы получим: машина перемещает пассажира (или груз).
Если вы посмотрите на исследования естественного языка, то легко найдете, что в основе всех языков лежит следующая ядерная конструкция: субъект, акция, объект. Другими словами, язык, как средство отображения нашего понимания мира, устроен так, что мы описываем мир через действие субъекта на объект. Соответственно, это не проявление мифологического сознания, а проявление просто сознания. Ну, либо мы любое сознание должны будем считать мифологическим, что не так.
Если мы хотим определить функцию машины, то должны определить: 1) объект, на который направлено действие машины; 2) определить само действие. Используя эту схему, мы получим: машина перемещает пассажира (или груз).
Если вы посмотрите на исследования естественного языка, то легко найдете, что в основе всех языков лежит следующая ядерная конструкция: субъект, акция, объект. Другими словами, язык, как средство отображения нашего понимания мира, устроен так, что мы описываем мир через действие субъекта на объект. Соответственно, это не проявление мифологического сознания, а проявление просто сознания. Ну, либо мы любое сознание должны будем считать мифологическим, что не так.
Sign up to leave a comment.
Моделирование активности и мифологическое сознание