Для автомата нужен алгоритм перебора позиций и выбора наилучшего продолжения. Понятное дело, что нужно как-то описывать доску, положение фигур, текущее состояние. Можно описать "движок" через ООП (а можно и не). Но при чём здесь стратегии?
Мне бы хотелось, что бы решалась задача (например, создание системы). Лучше всего, если задача будет решаться оптимальным способом. Тут ещё вопрос, существует ли этот самый оптимальный способ. Может быть, его нет, и нас всегда поджидает мистическое множество Парето, где куда ни пойди, чего-нибудь обязательно ухудшишь. Нельзя улучшить всё одновременно. Найти бы удачное сочетание подходов.
Вы приводите пример и (опять же!) примешиваете вопросы реализации. Почему можно присвоить одну функцию другой? Потому что это суть переменные, содержащие указатели или ссылки. Можно представить себе язык программирования, в котором нельзя таким образом присваивать значения (друг другу), зато будут специальные объекты (левосторонние, l-value), которые способны принимать ссылки.
Я имел в виду, что в процедурном программировании Вы явно пишите функцию f1 для типа 1, а функцию f2 для типа 2. Но и здесь Вы можете попытаться добиться некоторой гибкости. Другое дело, а насколько эта гибкость нужна.
Можно представить себе процесс, в ходе которого постоянно вызываются конструктор и деструктор объекта. Система поддерживает идентичность объекта через шину данных: деструктор производит сохранение объекта в поток, а конструктор считывает его их потока. (Некоторая аналогия с LLM прослеживается...) Птица-фенкис.
Любой список и есть сущность. Представьте себе, например, правостороннее дерево: Вы берёте, каждый раз очередной элемент (левый лист), и всегда что-то ещё остаётся (правое поддерево):
(Олег (знает (Python)))
При этом, частичное поддерево выражает собою целое понятие:
(Олег (знает (*)))
Дерево показывает структуру объекта и, вместе с этим, его идентичность. Расставьте иначе скобки — и Вы получите совершенно другой объект.
В реальной жизни мы ожидаем, что содержимое полностью определяет идентичность. В программировании, это означает, что, как раз, нельзя создавать два одинаковых по своему содержанию объекта, имеющих один и тот же идентификатор. Более того, система идентификации должна напрямую зависеть от этого содержания, ибо самый развёрнутый (полный и точный) идентификатор объекта — это он сам. Другое дело, что в реальной ситуации всё приходится здорово упрощать. Например, идентификатором может стать обыкновенное число или какая-нибудь составная строка. В этом случае, (не)равенство объектов полностью эквивалентно (не)равенству идентификаторов.
В то же время, есть объекты не как некие сущности (имеющие) соответствие в реальном мире, а как вычислительные объекты (то есть — помеченные фрагменты памяти). Например, цело число, строка, список, кортеж или словарь. Здесь мы просто обязаны следить за уникальностью таких объектов, и мы будем помечать различные фрагменты памяти различными идентификаторами. Мы можем создать два объекта-числа, в которых хранится одно и то же значение.
Нам следует очень аккуратно рассуждать о различных объектах, понимая, что есть объекты-сущности и объекты-реализации. Здесь всегда возникает смешение. Тут и, вправду, много похожего. В том-то и трудность, что мы легко подменяем понятия. Так что, объекту как понятию легко потерять свою идентичность. :-)
Объект имеет идентичность значит, что может существовать два объекта одинаковых по содержимому, но разной идентичностью, то есть разных.
Честно говоря, на этом утверждении хотелось бы остановиться и поразмышлять. никуда не продвигаясь пока дальше.
Здесь утверждается, что у объекта имеется некоторое содержание/содержимое, но есть и некий идентификатор, который действует отдельно от содержания. Грубо говоря, у каждого объекта есть некоторые данные (поле data или contents) и метод id (возвращающий уникальный идентификатор объекта).
ООП это любые языки где есть мутируемые сущности для которых верно
Не сочтите за троллинг замечание. Просто, давайте будет говорить по-русски. Пусть у нас есть простой список в Python и нет ничего другого. Нам же никто не мешает данные хранить в простом списке, не так ли? Список изменяемый. Но имеется проблема с ссылками: когда мы пытаемся скопировать список, копируются ссылки. Допустим, у мы пользуемся только глубоким копированием. Как тогда интерпретировать Ваше соотношение:
not equal (a, b) => not (a == b)
?
Если два объекта могут иметь одинаковые свойства, но всё равно не равны (из-за уникальной идентичности), то это сущности (ООП), а не value object.
Вот видите, Вы сразу говорите о каких-то свойствах. Значит, список — это value object?
поведение упаковано вместе с данными
Насколько это принципиально? Будем, например, использовать для хранения данных обыкновенные списки и кортежи. (Есть ещё и словари, которые уже очень близки к объектам.) А для обработки написать ряд функций. Да, это всё будет раздельно. И что? Плохо? А если это хорошо решает задачу?
вызов идёт через позднее связывание (или хотя бы таблицу), т.е. метод выбирается по типу объекта
Да, конечно. Если мы используем процедурный подход, то мы всегда вызываем именно то, что нужно, и проблемы разрешения вызывамых методов не возникает.
Мой вопрос был немного в другом. Я привык к тому, что, например, язык программирования C++ — это язык, в котором были введены (при сохранении синтаксиса Си) специальные конструкции, обеспечивающие работу с классами. Именно поэтому, такие языки оказываются, лишь, объектно-ориентированными. А есть объектные языки, где объекты (классы) реализованы в собственном смысле этого слова. Я, лишь, наслышан о таких языках программирования. В руках не держал. Даже, жалко, что не держал. Но Вы же понимаете, всё время возникает вопрос: а почему мы пользуемся языками программирования, которые являются, лишь, ориентированными на объекты (классы), а не не работаем с самими объектами (классами)?
Чтобы понять различие, надо представить себе ситуацию, когда при исполнении встречаются объекты различных классов. В обычном ООП-языке мы можем предусмотреть специальный класс, который описывает это взаимодействие. Но при попытке учесть всю комбинаторику взаимодействий, нам придётся соорудить немерено таких классов. Целая таблица маршрутизации! Можно сделать. Но, если у нас есть чистые объекты,то при их встрече такой промежуточный класс будет создаваться автоматически.
Например, это может быть класс Список и класс Пользователь: результат их композиции будет класс СписокПользователей. В приложении каждый класс объектов может быть часть некоторого списка. У нас должна быть возможность составления таких списков и управления ими. Композиция классов даёт некоторые специфические вещи для списка объектов определённого класса.
За последние годы мы создали сотни схем для проектов, которые поддерживаем. Некоторые — довольно простые, другие же настолько сложные, что без трехкратного увеличения и легенды в них не разобраться. Схемы — важный элемент инфраструктурной документации. Они помогают наглядно показать, как работает проект: где находятся сервисы, как они взаимодействуют, как проходит трафик и какие есть внешние интеграции.
Было бы очень здорово. Наверное, уже имеется классификация схем и некоторое представление о том, что такое схема схем — схема, которая связывает воедино схемы различных уровней. Ведь, это первое, что приходит в голову, что есть разные уровни, и на каждом уровне своя схема.
Несмотря на то, что все схемы служат одной цели — отразить устройство системы, на практике они сильно различаются в зависимости от контекста.
Довольно общо и довольно туманно.
Почти в каждом проекте мы начинаем с общей схемы работы. На ней отображаются ключевые компоненты: серверы, кластеры, хранилища, managed services в облаках, точки входа трафика, внешние интеграции, а также маршруты и логика взаимодействия между всеми этими элементами.
Общая схема работы — это описание того, ради чего функционирует система, где выражена основная системная функция. Разве не так?
Чем больше схем мы составляли, тем яснее становилось: это не просто иллюстрации, а полноценный рабочий инструмент, к которому предъявляются определенные требования.
Разве для схем не существует ГОСТ?
Первая сложность, с которой сталкивается технический писатель при составлении схемы — это сбор и хранение информации о системе. Данных может быть очень много: компоненты, связи, внешние интеграции, детали окружения. Удержать всё в голове невозможно, а вносить на схему по частям — непросто, особенно когда важно учитывать связи элементов и их взаимное расположение.
Здесь ожидается описание того, как это всё (эффективно) хранится в базе данных, какие средства визуализации используются/разработаны, какие принципы управления схемами и элементами схем выработаны.
Чтобы не упустить важное, приходится где-то фиксировать информацию заранее. Часто мы используем для этого описание контура — формализованное текстовое и табличное представление частей системы и их конфигураций. В идеале оно охватывает всё, что нужно для составления схемы: от перечня сервисов до точек взаимодействия.
В идеале, схемы развиваются вместе с разработкой системы. Где-то схема идёт впереди разработки, указывая то. что нужно сделать. Где-то схема идёт позади разработки, фиксируя то, как это было реализовано.
В идеале хотелось бы, чтобы схема обновлялась автоматически — вместе с изменениями в инфраструктуре. Подобные решения существуют, например, в разработке: автогенерация документации по коду. Но они не покрывают нашу специфику, особенно в проектах где инфраструктура гибридная и нестандартная. Поэтому пока что нам приходится вносить изменения вручную.
Ага! Вот но что. Вот с этого места, пожалуйста, по подробнее.
Вы совершаете принципиальную ошибку. Если всеобщая автоматизация возможна, то она не потребует существенной поддержки. А Вы всё меряете привычными себе стереотипами.
В математике есть понятие ортогонализации. Любой процесс можно представить в виде произведения двух матриц: в одной матрице лежат данные, в другой матрице лежат методы обработки. Ортогонализация приводит к тому, что всё практически сводится к сумме произведений диагональных элементов.
Тут, скорее, проблема отсутствия старта и финиша: где — старт и где — финиш? А так... Один что-то предъявляет, другой должен без ошибок дойти до... финиша (каждой отдельной процедуры). Как-то так.
Научный сотрудник Центра изучения экзистенциального риска при Кембриджском университете Морис Чиодо в своем комментарии изданию заявил, что использование данных, произведенных до 2022 года, позволяет быть уверенным в минимальном наличии «загрязнения» от ИИ.
Проблема в том, что в интернете нет внутреннего (встроенного) механизма определения времени появления того или иного текста. Если бы научные сотрудники в своё время хорошенько потрудились бы над созданием интернета, то такой механизм был бы обязательно реализован. Была бы возможность откатиться по времени на любой момент (это был бы встроенный архив интернета), делать запросы данных с ограничением по времени.
А если Вы хотите, чтобы данные были чистыми, то Вы с самого начала заведёте для ИИ отдельный слой (для работы), к которому, при необходимости, можно было бы обращаться за справкой из реального мира.
Исследователи, в том числе и Чиодо, уже несколько лет бьют тревогу — даже если коллапса модели не произойдет, загрязнение интернета по‑прежнему является актуальной проблемой, и его очистка будет либо непомерно дорогой, либо попросту невозможной, считают они.
Плохие исследователи. Потому и нет ничего нормального, потому как нет нормальных исследователей. Нужна единая вычислительная инфраструктура, где каждой сущности реального мира соответствует свой узел + трансвлючение (семантическая база знаний).
Авторы статьи полагают, что генеративные модели уже создали большое количество контента — достаточное, чтобы другие ИИ обучались именно на их творениях. В результате это напоминает игру в «испорченный телефон», в которой все игроки стремительно «глупеют». В индустрии такой сценарий развития называют «коллапсом модели».
Это же рассуждение можно применить и к до-ИИ-шному периоду. Сначала в интеренете были одни только гики, которые учились сами. Потом туда ринулись толпы авторов, а потом новые поколения стали учиться уже на, что написано в интернете.
Идеальной задачей для OOD является веб-браузер. Он не имеет вообще никакой стратегии, а состоит из набора инструментов, вызываемых внешним по отношению к нему пользователем компьютера или разработчиком контента по своему желанию.
Почему? Вот это, уж, совершенно не понятно. Браузер осуществляет отображение данных в его низкоуровневом машинном представлении в его высокоуровневое пользовательское представление.
Для автомата нужен алгоритм перебора позиций и выбора наилучшего продолжения. Понятное дело, что нужно как-то описывать доску, положение фигур, текущее состояние. Можно описать "движок" через ООП (а можно и не). Но при чём здесь стратегии?
Мне бы хотелось, что бы решалась задача (например, создание системы). Лучше всего, если задача будет решаться оптимальным способом. Тут ещё вопрос, существует ли этот самый оптимальный способ. Может быть, его нет, и нас всегда поджидает мистическое множество Парето, где куда ни пойди, чего-нибудь обязательно ухудшишь. Нельзя улучшить всё одновременно. Найти бы удачное сочетание подходов.
Вы приводите пример и (опять же!) примешиваете вопросы реализации. Почему можно присвоить одну функцию другой? Потому что это суть переменные, содержащие указатели или ссылки. Можно представить себе язык программирования, в котором нельзя таким образом присваивать значения (друг другу), зато будут специальные объекты (левосторонние, l-value), которые способны принимать ссылки.
Я имел в виду, что в процедурном программировании Вы явно пишите функцию f1 для типа 1, а функцию f2 для типа 2. Но и здесь Вы можете попытаться добиться некоторой гибкости. Другое дело, а насколько эта гибкость нужна.
Никто не смеётся. Надо разобраться. Наконец-то.
Можно представить себе процесс, в ходе которого постоянно вызываются конструктор и деструктор объекта. Система поддерживает идентичность объекта через шину данных: деструктор производит сохранение объекта в поток, а конструктор считывает его их потока. (Некоторая аналогия с LLM прослеживается...) Птица-фенкис.
"Нет в мире совершенства." (с)
Любой список и есть сущность. Представьте себе, например, правостороннее дерево: Вы берёте, каждый раз очередной элемент (левый лист), и всегда что-то ещё остаётся (правое поддерево):
(Олег (знает (Python)))При этом, частичное поддерево выражает собою целое понятие:
(Олег (знает (*)))Дерево показывает структуру объекта и, вместе с этим, его идентичность. Расставьте иначе скобки — и Вы получите совершенно другой объект.
Что же Вы понимаете под полиморфизомом?
В реальной жизни мы ожидаем, что содержимое полностью определяет идентичность. В программировании, это означает, что, как раз, нельзя создавать два одинаковых по своему содержанию объекта, имеющих один и тот же идентификатор. Более того, система идентификации должна напрямую зависеть от этого содержания, ибо самый развёрнутый (полный и точный) идентификатор объекта — это он сам. Другое дело, что в реальной ситуации всё приходится здорово упрощать. Например, идентификатором может стать обыкновенное число или какая-нибудь составная строка. В этом случае, (не)равенство объектов полностью эквивалентно (не)равенству идентификаторов.
В то же время, есть объекты не как некие сущности (имеющие) соответствие в реальном мире, а как вычислительные объекты (то есть — помеченные фрагменты памяти). Например, цело число, строка, список, кортеж или словарь. Здесь мы просто обязаны следить за уникальностью таких объектов, и мы будем помечать различные фрагменты памяти различными идентификаторами. Мы можем создать два объекта-числа, в которых хранится одно и то же значение.
Нам следует очень аккуратно рассуждать о различных объектах, понимая, что есть объекты-сущности и объекты-реализации. Здесь всегда возникает смешение. Тут и, вправду, много похожего. В том-то и трудность, что мы легко подменяем понятия. Так что, объекту как понятию легко потерять свою идентичность. :-)
Честно говоря, на этом утверждении хотелось бы остановиться и поразмышлять. никуда не продвигаясь пока дальше.
Здесь утверждается, что у объекта имеется некоторое содержание/содержимое, но есть и некий идентификатор, который действует отдельно от содержания. Грубо говоря, у каждого объекта есть некоторые данные (поле data или contents) и метод id (возвращающий уникальный идентификатор объекта).
Не сочтите за
троллингзамечание. Просто, давайте будет говорить по-русски. Пусть у нас есть простой список в Python и нет ничего другого. Нам же никто не мешает данные хранить в простом списке, не так ли? Список изменяемый. Но имеется проблема с ссылками: когда мы пытаемся скопировать список, копируются ссылки. Допустим, у мы пользуемся только глубоким копированием. Как тогда интерпретировать Ваше соотношение:?
Вот видите, Вы сразу говорите о каких-то свойствах. Значит, список — это value object?
Насколько это принципиально? Будем, например, использовать для хранения данных обыкновенные списки и кортежи. (Есть ещё и словари, которые уже очень близки к объектам.) А для обработки написать ряд функций. Да, это всё будет раздельно. И что? Плохо? А если это хорошо решает задачу?
Да, конечно. Если мы используем процедурный подход, то мы всегда вызываем именно то, что нужно, и проблемы разрешения вызывамых методов не возникает.
Мой вопрос был немного в другом. Я привык к тому, что, например, язык программирования C++ — это язык, в котором были введены (при сохранении синтаксиса Си) специальные конструкции, обеспечивающие работу с классами. Именно поэтому, такие языки оказываются, лишь, объектно-ориентированными. А есть объектные языки, где объекты (классы) реализованы в собственном смысле этого слова. Я, лишь, наслышан о таких языках программирования. В руках не держал. Даже, жалко, что не держал. Но Вы же понимаете, всё время возникает вопрос: а почему мы пользуемся языками программирования, которые являются, лишь, ориентированными на объекты (классы), а не не работаем с самими объектами (классами)?
Чтобы понять различие, надо представить себе ситуацию, когда при исполнении встречаются объекты различных классов. В обычном ООП-языке мы можем предусмотреть специальный класс, который описывает это взаимодействие. Но при попытке учесть всю комбинаторику взаимодействий, нам придётся соорудить немерено таких классов. Целая таблица маршрутизации! Можно сделать. Но, если у нас есть чистые объекты,то при их встрече такой промежуточный класс будет создаваться автоматически.
Например, это может быть класс Список и класс Пользователь: результат их композиции будет класс СписокПользователей. В приложении каждый класс объектов может быть часть некоторого списка. У нас должна быть возможность составления таких списков и управления ими. Композиция классов даёт некоторые специфические вещи для списка объектов определённого класса.
Одни сплошные восклицательные знаки! И никаких вопросительных?
Эххх. Сделать бы самому складскую программу... :-(
За последние годы мы создали сотни схем для проектов, которые поддерживаем. Некоторые — довольно простые, другие же настолько сложные, что без трехкратного увеличения и легенды в них не разобраться. Схемы — важный элемент инфраструктурной документации. Они помогают наглядно показать, как работает проект: где находятся сервисы, как они взаимодействуют, как проходит трафик и какие есть внешние интеграции.
Было бы очень здорово. Наверное, уже имеется классификация схем и некоторое представление о том, что такое схема схем — схема, которая связывает воедино схемы различных уровней. Ведь, это первое, что приходит в голову, что есть разные уровни, и на каждом уровне своя схема.
Несмотря на то, что все схемы служат одной цели — отразить устройство системы, на практике они сильно различаются в зависимости от контекста.
Довольно общо и довольно туманно.
Почти в каждом проекте мы начинаем с общей схемы работы. На ней отображаются ключевые компоненты: серверы, кластеры, хранилища, managed services в облаках, точки входа трафика, внешние интеграции, а также маршруты и логика взаимодействия между всеми этими элементами.
Общая схема работы — это описание того, ради чего функционирует система, где выражена основная системная функция. Разве не так?
Чем больше схем мы составляли, тем яснее становилось: это не просто иллюстрации, а полноценный рабочий инструмент, к которому предъявляются определенные требования.
Разве для схем не существует ГОСТ?
Первая сложность, с которой сталкивается технический писатель при составлении схемы — это сбор и хранение информации о системе. Данных может быть очень много: компоненты, связи, внешние интеграции, детали окружения. Удержать всё в голове невозможно, а вносить на схему по частям — непросто, особенно когда важно учитывать связи элементов и их взаимное расположение.
Здесь ожидается описание того, как это всё (эффективно) хранится в базе данных, какие средства визуализации используются/разработаны, какие принципы управления схемами и элементами схем выработаны.
Чтобы не упустить важное, приходится где-то фиксировать информацию заранее. Часто мы используем для этого описание контура — формализованное текстовое и табличное представление частей системы и их конфигураций. В идеале оно охватывает всё, что нужно для составления схемы: от перечня сервисов до точек взаимодействия.
В идеале, схемы развиваются вместе с разработкой системы. Где-то схема идёт впереди разработки, указывая то. что нужно сделать. Где-то схема идёт позади разработки, фиксируя то, как это было реализовано.
В идеале хотелось бы, чтобы схема обновлялась автоматически — вместе с изменениями в инфраструктуре. Подобные решения существуют, например, в разработке: автогенерация документации по коду. Но они не покрывают нашу специфику, особенно в проектах где инфраструктура гибридная и нестандартная. Поэтому пока что нам приходится вносить изменения вручную.
Ага! Вот но что. Вот с этого места, пожалуйста, по подробнее.
А где они ООП-языки? SmallTalk? Simula? Oberon?
Вы совершаете принципиальную ошибку. Если всеобщая автоматизация возможна, то она не потребует существенной поддержки. А Вы всё меряете привычными себе стереотипами.
В математике есть понятие ортогонализации. Любой процесс можно представить в виде произведения двух матриц: в одной матрице лежат данные, в другой матрице лежат методы обработки. Ортогонализация приводит к тому, что всё практически сводится к сумме произведений диагональных элементов.
Тут, скорее, проблема отсутствия старта и финиша: где — старт и где — финиш? А так... Один что-то предъявляет, другой должен без ошибок дойти до... финиша (каждой отдельной процедуры). Как-то так.
Проблема в том, что в интернете нет внутреннего (встроенного) механизма определения времени появления того или иного текста. Если бы научные сотрудники в своё время хорошенько потрудились бы над созданием интернета, то такой механизм был бы обязательно реализован. Была бы возможность откатиться по времени на любой момент (это был бы встроенный архив интернета), делать запросы данных с ограничением по времени.
А если Вы хотите, чтобы данные были чистыми, то Вы с самого начала заведёте для ИИ отдельный слой (для работы), к которому, при необходимости, можно было бы обращаться за справкой из реального мира.
Плохие исследователи. Потому и нет ничего нормального, потому как нет нормальных исследователей. Нужна единая вычислительная инфраструктура, где каждой сущности реального мира соответствует свой узел + трансвлючение (семантическая база знаний).
Это же рассуждение можно применить и к до-ИИ-шному периоду. Сначала в интеренете были одни только гики, которые учились сами. Потом туда ринулись толпы авторов, а потом новые поколения стали учиться уже на, что написано в интернете.
Что, значит, стратегия? В каком смысле?
Почему? Вот это, уж, совершенно не понятно. Браузер осуществляет отображение данных в его низкоуровневом машинном представлении в его высокоуровневое пользовательское представление.