О вреде ООП надо говорить! Это - слишком важная тема, чтобы отмалчиваться.

Ну до конкретной альтернативы она как-то дошла же?)

Тогда ответ будет «потому что этот шаг допустим условиями».

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

Эвристика там одна: если после шага самая сложная из списка получившихся задач проще, значит всё верно. «Проще» трактуется как «меньше слов для формулировки» (м-да, опять получилась неисчислимая колмогоровская сложность, но здесь подразумевается не математическая формулировка, а описательная).

Бот не просто должен это запомнить, а превратить данные в знания.

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

Посмотри вычислительную сложность индуктивного логического программирования.

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

Очень быстро выяснится, что у Алисы вместо персональной теории разума просто таблица заглушек, а не «генератор переживаний».

У многих людей тоже «таблица заглушек». Это не мешает им слыть понимающими собеседниками.

Тогда ответ будет «потому что этот шаг допустим условиями».

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

Эвристика там одна

Ты уверен? :)

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

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

У многих людей тоже «таблица заглушек».

Вот только у человека не только таблица заглушек. В отличие от :)

Снова добавляем бектрекинг. Мы должны при возврате выбрать другое правило, иначе будет быстрое зацикливание.

Так возврата нет. Предположим нужно решить задачу «прочитать массив чисел, отсортировать и вывести результат».

1. пробуем превратить в последовательность. Получается. Итог: задачи «прочитать массив», «сортировать массив», «вывести массив». Записываем новые задачи.

2. Решаем «прочитать массив»

2.1. пробуем превратить в последовательность. Получается. Итог: задачи «прочитать число - размер массива», «создать массив заданного размера», «прочитать элементы массива заданного размера». Записываем задачи. Первые две базовые.

2.2. Решаем «прочитать элементы массива заданного размера». Пробуем превратить в последовательность: число шагов зависит от параметра. Пробуем превратить в цикл. Итог задача «для каждого номера элемента прочитать элемент с этим номером в массиве». Подзадача «прочитать элемент» базовая. Задача «прочитать массив» разбита на базовые, значит её алгоритм построен.

3. Решаем «сортировать массив»

…

Бэктрекинг потенциально может быть при неверном разбитии на подзадачи, но это скорее исключение и бектрекинг будет к сводиться к дополнительной проверке помимо допустимости шага: «есть ли записанный такой шаг среди ошибочных».

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

Не согласен. Во-первых именно сырые (синтаксически разобранные) данные и должны храниться, если они получены от пользователя. Типа «Ваня сообщил, что помидоры красные», «В книге … написано, что помидоры красные». Можно сжимать по одинаковым утверждениям (будет утверждение + группа источников). Если какое-то утверждение из большого числа источников и не существует ему противоречащего, можно сообщать его без указания источника.

А обобщать бессмысленно, почти на любое утверждение найдётся «опровержение». Мир не математичен. Выбери правильное: «Земля круглая», «Земля шарообразная», «Земля имеет свою уникальную форму не совпадающую с геометрическими фигурами».

Вот только у человека не только таблица заглушек. В отличие от :)

Спорно. Может эта таблица просто очень большая.

Бэктрекинг потенциально может быть при неверном разбитии на подзадачи,

Мы говорим о дизайн-тайме, когда алгоритм возникает в голове. И там бэктрекинг понадобится всегда, когда тебе нужно как-то обойти пространство дизайна. Например, для поиска оптимального алгоритма или алгоритма с максимизацией каких-то параметров (в дедлайн уложиться, хотя бы :))

Кроме того, в процессе вместе с поиском алгоритма методом комбинации правил его построения, одновременно происходит его «частичное выполнение», там же в голове (неявно, на уровне интуиции), иногда используя для этого тестовые запуски программы, когда головы уже не хватает. И это тоже потенциальная точка для бэктрекинга.

Так что переборов и поисков там хватает в любом случае. Просто сознательная картина процесса их не содержит.

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

Они должны храниться, но не только они. Например, по сырым данным ты технически не сделаешь полнотекстовый поиск. По ним нужно построить обратный индекс или преобразовать их в self-index (есть и такие). Точно так же, для логического вывода тебе сначала нужно построить онтологию по связанным фактам. Ты это все можешь делать «на лету» и даже инкрементно через мемоизацию, но делать это придется. А вопрос хранения при этом сырых данных — это вопрос вычислительных бюджетов. Память не бесконечная. Частично решают персистентные структуры данных, которые могут компактно хранить версии. И в Мемории они именно для этого — максимально сохранять полную историю.

Спорно. Может эта таблица просто очень большая.

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

Т.е. ты можешь думать об этом, как о динамическом программировании в частности, и о методе размена времени на память — вообще. Мемория, кстати, именно под операционную поддержку этого метода и делается. Отсюда и название. Memoria — это 4-е начало риторики: правильное структурирование информации для лучшего запоминания.

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

Например, для поиска оптимального алгоритма или алгоритма с максимизацией каких-то параметров (в дедлайн уложиться, хотя бы :))

Оптимальный алгоритм математики ищут. Годами. Поэтому либо гуглёж, либо реально перебор по жадной эвристике (если изменение дало уменьшение времени выполнения, то его не пересматриваем).

Точно так же, для логического вывода тебе сначала нужно построить онтологию по связанным фактам.

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

Окей. Мы, я вижу, уже оба устали. Тема эта будет продолжаться в разных контекстах)

Я тут пока саммаризирую то, о чем речь шла.

Мы можем проникать интроспекцией довольно глубоко, но для этого нужно затратить работу. Которая, в общем случае, имеет экспоненциальную трудоемкость. Т.е. интроспекция реально трудна, и тут не стоит удивляться, что у нас её, в целом, нет. Настолько, что даже нет понятия о том, что она может быть, и для чего она может использоваться в работе. Я тут буду, как обычно, бездоказательно, утверждать, что чем лучше у человека развит интроспективный внутриличностный интеллект, тем лучше человек способен поднимать и социализировать промежуточный когнитивный материал. Т.е., при наличии необходимых условий, тем более сложные задачи он может решать в контексте коллективного разума. Теории на эту тему есть, но они разрозненны. Учебника, к сожалению, нет. Поэтом, всё — сами. Зато, — дух первооткрывательства, очарование таинственности, прикосновение к сакральным истинам, ну и вот это вот всё. Потом, когда процессную интроспекцию научатся развивать с детского сада, этого уже больше не будет. Как нет больше в программировании той «магии», которая нас зажигала в 90-х.

Для её развития важны два фактора — «правильное» окружение и навыки владения продвинутыми структурами данных. Последнее — не совсем то, что мы привыкли понимать под структурами данных. Там правят балл кодировки, распределения вероятностей и теория информации. А то, что мы привыкли называть структурами данных — это лишь операционная надстройка. Сжатые структуры данных, в целом, лежат в том же классе описательной сложности, что и нейросети на основе вероятностных методов. К сожалению, наши люди эту матчасть забывают сразу, как только заканчивается соответствующий курс в их альма-матерах. А программируем за зарплату мы только то, что приносит доход уважаемым людям. В бСССР тервер к этим вещам не относится. Сейчас, правда, снова пошла мода на «матан», поскольку «матан» в виде ML начал приносить доход уважаемым людям. Когда я в конце 90-х начинал заниматься ИИ, это было уделом фриков-изгоев.

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

Что качается продвинутых структур данных, то для их внедрения в практику будет удобная площадка на основе Мемории.

Что касается этого топика, то проблемы у ООП, действительно есть. Точнее, не у самого ООП, а у тех ООЯП, которые мы сейчас имеем. И связано это с их встроенной реализацией объектов, как структур данных. Принципы инкапсуляции (скрытия состояния) не подходят для задач баз данных, где может понадобиться прямой доступ к отдельным элементам внутреннего состояния объектов. Ходить к этому состоянию исключительно через интерфейсы самого объекта можно, но вот хранить такое состояние так, чтобы такие походы максимально утилизировали железо — уже сложно. Объектам ООЯП обычно соответствуют таблицы-построчники, так как оба хранят данные строки/объекта локально. Тогда как для аналитических приложений нужны таблицы-поколоночники. И вот их на ООЯП реализовать уже будет сильно сложнее. Как вам пара десятков указателей this у объекта? :)

В результате, в объектной парадигме сложно делать высокопроизводительные структуры данных. Это будет God Object, или сразу с query-интерфейсом (SQL, OQL, XPath и т.п.), или его внутреннее состояние экспортироваться в псевдо-объектном варианте через вьюшки-хэндлеры, типа std::string_view в С++. Последнее, само по себе, нормально. Но это отход от принципа инкапсуляции состояния.

Короче, объекты ООЯП слишком ригидны в том, каким образом они могут моделировать многообразие данных. И это одна из причин фэйла ООБД. И, соотвественно, все приложения, которые обрабатывают большие объемы структурированных данных, вынуждены переходить к data-oriented diesign, а ООП использовать на уровне вьюшек для данных.

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

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

Здесь такая же атомарная операция, как распознавание слова в наборе звуков или котика в наборе линий.

Как вам пара десятков указателей this у объекта?

Их просто именовать надо:

о.column1->data, о.column2->data, …, где column1 – указатель на элемент массива-колонки.

Но это отход от принципа инкапсуляции состояния.

В чём? Любая фигня с набором функций – это объект. СУБД с SQL с точки зрения ООП тоже один большой объект (внутренняя структура которого не видна). string_view тоже предлагает обращаться через интерфейс, а не в обход его.

И это одна из причин фэйла ООБД.

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

И не во все операции.

Совершенно верно. Расклад с процессной интроспекцией примерно такой. Она в общем случае невычислима, так как упирается или в проблему остановки (если мы идем через индукцию машин Тьюринга), или в теоремы Гёделя о неполноте, если мы идем через логику. Это, в целом, одно и то же. На практике, правда, упереться в них у нас не получится, так как гораздо раньше упремся в комбинаторную сложность индуктивного программирования. Всё, что нам тут доступно, это AnyTime алгоритмы типа MonteCarlo, которые нам дадут на столько точный результат, на сколько мы ему выделили вычислительного бюджета.

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

По сути, тут речь идет о новом классе (самоприменимых) структур данных высших порядков — структур данных над вычислительными феноменами, такими как реальная трудоемкость вычисления функции.

И вот если ты можешь увидеть такую самоприменимость внутри своего разума, то ты переходишь на второй уровень :)

По сути, тут речь идет о новом классе (самоприменимых) структур данных высших порядков — структур данных над вычислительными феноменами, такими как реальная трудоемкость вычисления функции.

Кстати, их варианты сейчас довольно таки широко применяются в программировании. И я оставляю это в качестве упражнения для интересующегося читателя, который все еще читает нашу с monk-ом дискуссию, — догадаться, где и как. С ними имеют дело почти все.

о.column1->data, о.column2->data, …, где column1 – указатель на элемент массива-колонки.

А теперь, пожалуйста, так, чтобы компилятор смог векторизовать цикл обхода коллекции таких объектов :)

Т.е., да, формально это всё можно сделать, а в С++ даже иметь для такого композитного указатели value-семантику. Только вот нужно еще, чтобы оптимизатор понимал, как это всё правильно оптимизировать.

В чём? Любая фигня с набором функций – это объект.

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

А так — да. Сама по себе вьюшка — это тот же объект, который просто не владеет своим состоянием. Ничего такого уж не-ООП-шного тут нет.

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

Я тя умоляю! Транзакции на «произвольные структуры данных» прекрасно «надеваются» через персистентные структуры данных. ООБД, в этом смысле, совсем не являются «произвольными», так как не вылезают за пределы графов, которые хорошо отображаются в реляционную модель. Нужно только traversal добавить в язык запросов — и всё. ООБД выродились в просто ORM.

Сама по себе вьюшка — это тот же объект, который просто не владеет своим состоянием. Ничего такого уж не-ООП-шного тут нет.

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

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

Создавать локальные иерархии наследования, подходящие для конкретного случая. Ах да, ваш язык это не поддерживает. Тогда остается только сраться %)

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

Не будут, наследоваться нужно от более абстрактных вещей, все фигуры одинаковы по уровня абстракции, все эти приколы с ромбами и квадратами не более чем тупой пример

Ах да, ваш язык это не поддерживает. Тогда остается только сраться %)

Бугогагага!!

Не будут, наследоваться нужно от более абстрактных вещей

От каких?

се эти приколы с ромбами и квадратами не более чем тупой пример

Нормальный пример. Отлично показывает корявость парадигмы и/или недоязычков.

От каких?

геометрическая фигура

Нормальный пример. Отлично показывает корявость парадигмы и/или недоязычков.

Не, это индикатор говнокодеров.

Харам наступает тогда, когда основной объект и его вьюшки дизайнятся независимо. А если вместе, т.е., только они имеют доступ к его состоянию, то нарушения нет.

Отлично показывает корявость парадигмы и/или недоязычков.

Так ты уже набросил или еще нет?)

Не, это индикатор говнокодеров.

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

Так ты уже набросил или еще нет?)

Для этого надо бы отдельный тред, но можно и так начать.

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

А что не говно?

Моча, например. Так что там по фигурам?

Моча, например. Так что там по фигурам?

А что там по поводу кода который не говно?

но можно и так начать.

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

А пока ты не доопределишь задачу, я просто не знаю, как тебе эту иерархию строить. А «от балды» я не буду. Я так не делаю.

что там по фигурам?

Есть интерфейс IDrawable с методом draw, фигуры (и любые другие типы) его реализуют как им надо. Наследование? ненужно.

А что там по поводу кода который не говно?

Ну ты видел его? Покажи, как сделать вменяемую иерархию геометрических фигур.

Я же написал. Что тебе не понятно?

Наследование? ненужно

А как же основной принцип ООП? То говорят, что вот, ООП, везде ООП, без ООП никак, а оказывается, что основной принцип ООП == не нужно. Так мы уйдем в сторону «кастрированное ООП - это ООП или уже нет?»

Вот это:

геометрическая фигура

не ответ.

почему это не ответ?

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

Доопредели задачу в плане того, что конкретно ты ждешь от этой иерархии, и что ты будешь называть «вменяемой» иерархией. И я тебе покажу иерархию. Я тебе обещаю, что там будет больше 2-х уровней.

Могу сделать тред и кастануть числа третьего августа. Сейчас не могу устроить полноценный срач.

Конкретики нет.

Максимально конкретно все написал, наследоваться нужно от более абстрактных вещей, если там только интерфейс то и такое может быть, почему нет?

А как же основной принцип ООП

Предпочитайте композицию наследованию, этот принцип?

Да не вопрос. Только срача не будет. Я тебе покажу «на пальцах», как это делается, и ты немного расширишь свой кругозор. И всё)

такое может быть, почему нет?

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

Да не вопрос. Только срача не будет. Я тебе покажу «на пальцах», как это делается, и ты немного расширишь свой кругозор. И всё)

Звучит как вызов на дуэль!

Ахаха. Это ты на дуэль тут нас вызвал сначала)

На самом деле, не в моем случае. Если абстрагироваться о формы речи, то ты задал вопрос на который у меня есть ответ. Который я готов дать, если ты готов слушать. Вот и всё)

Потому что у тебя есть квадрат, а есть ромб (прямоугольный), который тот же самый квадрат, повёрнутый на 45 градусов. Методы определения площади и периметра придётся копипастить

Засовываешь квадрат в ромб и делегируешь методы. Просто и без копипасты. Только небольшой избыток кода по сравнению с наследованием может быть.

Засовываешь квадрат в ромб

Или ромб в квадрат?

Потому что у тебя есть квадрат, а есть ромб (прямоугольный), который тот же самый квадрат, повёрнутый на 45 градусов.

Ты серьезно?)

Зачем, можно в трейт вынести.

А можно при создании проверять углы и создавать более специализированный объект.

Ты серьезно?)

А что тебе не нравится в такой задаче?

Зачем ты выделил частные случаи?

А можно при создании проверять углы и создавать более специализированный объект.

Воо. Понеслась.

Зачем ты выделил частные случаи?

Наследники чего-то там абстрактного - это не множество частных случаев? А если можно сделать в общем случае, то зачем нужно ООПэ?