Могу примеры привести. В английском перед объектом предлог The, перед классом a. В фразе каждый мужчина должен построить дом... Дом это класс.. А вот я живу в доме за углом, слово дом это объект. Сколько не говори «мед» во рту слаще не станет.. Здесь мед просто лексема.

сори. Не могу скинуть. Вся моя библиотека пропала после оккупации. Но, на память не жалуюсь. В семью индоевропейских языков входит большинство языков см. Здесьhttps://www.google.com/search?q=%D1%8F%D0%B7%D1%8B%D0%BA%D0%B8+%D0%B8%D0%BD%D0%B4%D0%BE%D0%B5%D0%B2%D1%80%D0%BE%D0%BF%D0%B5%D0%B9%D1%81%D0%BA%D0%BE%D0%B9+%D1%81%D0%B5%D0%BC%D1%8C%D0%B8&sca_esv=2e0bf73006d1ba9f&sxsrf=AE3TifMmtnoeNGToSr2xBXIP-y2D3qQ-rA%3A1760004104773&source=hp&ei=CIjnaM7sLLXAwPAPwP7r2AI&iflsig=AOw8s4IAAAAAaOeWGKh-UHzeFFAfFy2Wh-1Z754nSkgx&oq=%D1%8F%D0%B7%D1%8B%D0%BA%D0%B8+%D0%B8%D0%BD%D0%B4%D0%BE&gs_lp=Egdnd3Mtd2l6IhPRj9C30YvQutC4INC40L3QtNC-KgIIATIFEAAYgAQyBRAAGIAEMgUQABiABDIGEAAYFhgeMgYQABgWGB4yBhAAGBYYHjIGEAAYFhgeMgYQABgWGB4yBhAAGBYYHjIGEAAYFhgeSPa3AVCYC1jFZHAEeACQAQCYAY8BoAGMC6oBAzQuObgBAcgBAPgBAZgCEaACtgyoAgrCAg0QIxiABBgnGIoFGOoCwgIHECMYJxjqAsICDRAuGIAEGCcYigUY6gLCAgUQLhiABMICChAAGIAEGEYY-QHCAgwQABiABBgKGEYY-QHCAgcQABiABBgKwgIHEC4YgAQYCsICCBAAGIAEGKIEwgISEAAYgAQYsQMYgwEYDRhGGPkBwgIKEAAYgAQYsQMYDcICBxAAGIAEGA3CAgcQLhiABBgNwgIIEAAYgAQYywGYAwfxBaI4Wkeqm0eGkgcENC4xM6AH6H2yBwQwLjEzuAeODMIHBzAuMS44LjjIB4cB&sclient=gws-wiz. К не объектным языкам относятся языки индейцев.
Этой темой занимался когда начинал работать над созданием своего языка. Много литературы тогда прочитал. Это было лет 20 назад. Просто поверь. Или по гугли.

Стосовно ООП — тут справді холіварна тема. Особисто я орієнтуюсь на поширене трактування ООП у сучасних мовах, де головний акцент — на наслідуванні як інструменті повторного використання коду.

Это все следствие более глубоких причин. Дело в том, что все естественные языки (индоевропейской группы) объектные. И наше мышление отсюда тоже объектное. Все остальное детские болезни ООП.

Справжнє розширення можливостей дає лише оракул, який може відповідати на нерозв’язувані запити.

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

базові властивості машини Тюрінга відомі понад сімдесят років.

Кстати, именно то, что я прочитал в определении машины Тьюринга в википедии и послужило поводом для моего возмущения. А именно Маши́на Тью́ринга — абстрактный исполнитель (абстрактная вычислительная машина) — математическая модель вычислений, предложенная Аланом Тьюрингом в 1936 году для формализации понятия алгоритма. Это не так. Машина Тьюринга это исполнитель вычислительных алгоритмов.

Якщо ти вважаєш, що недетермінована машина Тюрінга «не існує», то маєш спростувати не чиюсь точку зору, а цілу галузь формальної математики. Хто, ймовірніше, помиляється, ти чи всі вони?

Вы не математик. А мне плевать кто прав. Даже тысячи мух не убедят меня в том, что говно это вкусно. Читай то, что я написал. Я не политик и не собираюсь никого убеждать. Умный поймет и задумается. Хочешь понять иди на канал, или в личку. Меня найти легко.
P.S. За 20 лет на этом сайте и 70 в моей жизни еще никто не обвинял меня то я глупость написал или сказал. Но бывало делал))

Маячня. Будь-яку недетерміновану машину Тюрінга можна змоделювати детермінованою, яка просто перебере всі варіанти.

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

Паралельність не збільшує обчислювальну потужність, лише впливає на швидкість.

. Хотя при желании можно придраться. Но, в теме речь идет о новых способах мышления и парадигмах. Что я и предложил. Можем пообщаться подробнее если Вас интересует моя машина. Думаю здесь не очень удачное место для этого. Спасибо!

вона на Тьюрінг компліт машині, отже, таки еквівалетнна, ні?

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

За все языки уже не надо. Недавно написал транслятор реализующий исполнитель не эквивалентный Тьюрингу

Я так не говорил. Это вы так поняли. Повторюсь. Физический мир не детерминирован. Вот так получилось. Алгоритмы, машина Тьюринга-детерминированы по определению.

Але цей патерн можна реалізувати не використовуючи ООП взагалі. Ось в чому сіль, ООП втрачає всі свої переваги, якщо йти в сторону подій та обміну сигналами.

Я ж говорю нет противоречия.

Поточний процес виглядає як A —> B —> C. Але через деякий час він змінюється під впливом обставин на C —> A —> B’ —> D. У вас не просто змінюється порядок, а ще й нові кроки додаються. Передбачити такі зміни майже неможливо на початку розробки, бо ані розробник, ані замовник не розуміють, що їх чекає через рік використання системи

Это интересная, но отдельная и очень важная тема. Но опять же. Это не проблема ООП. Я уже где-то здесь писал. Интуитивно большинство программистов подразумевают последовательное выполнение операторов. А теперь представь что машина работает строго по принципу адресация-событие-подписка. Тогда нет проблем добавить в любое место любое изменение последовательности выполнения. Необходимо только не начудить с ближайшими событиями. Что б сохранить новый требуемый порядок выполнения. Можно добавить в любое место что угодно, и построить новую цепочку. Этот принцип создает уникальные возможности в автоматизации и умных домах. Пользователь сам по своему желанию строит необходимые цепочки вообще не касаясь уже созданных объектов и их взаимодействие. Он просто делает подписки на необходимые события для выполнения актуальной проблемы.

Вот не хорошо когда такие архитекторы принимают решения.

Події реального світу важко описувати в ООП, тому що він вимагає чіткої структури даних.

Здесь нет противоречия. Хотя и с ООП нет противоречия. четкость структуры данных способствует четкости мышления. В системах реального времени на первом месте проблема порядка выполнения.

Зазвичай ти дивишся на структуру даних, конкретні запити та як просто та ефективно їх реалізувати.

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

якщо алгорими та імперативна парадигми детерміновані то чому не можна створити «універсальну парадигму»?

Потому что «физику» не обманешь

«універсальна парадигма» все одне фізику не обдуриш, треба працювати мізками very hard якщо хочеш гарний результат і ніякими «універсальними парадигмами» це не замінити

Все правильно. Есть всего одна проблема. Физический мир не детерминирован, алгоритмы и вся императивная парадигма детерминированы. Поэтому на лицо противоречие для построения универсальной модели.

У вас в архітектурі відсутній процесор в класичному розумінні, але для таких задач люди давно придумали пліси

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

Это другое мышление. Ощутить можно разобрав примеры. Коих тоже не мало на канале. Плис это действительно заготовка, на которой можно сделать все. том числе и мою машину.

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

Якщо ви пишете на низькому рівні, то без сумнівів залежить. Проте інструменти, як обгортки дозволяють речі, залежні від архітектури заліза приховати.

Это если архитектура классическая(Тьюринга). Или детерминированная. Я дал описание новой архитектуры. Не детерминированной. Ее полноценно нельзя реализовать на машине фон неймана. Что б разобраться надо по ссылке мой канал посетить. Это реально другая машина и другой способ мышления. Вы ж понимаете что в императивной парадигме реализовать многопроцессорную работу не получится. А у меня это норма.