Есть и такая идея. И уже реализовываю. Не Тьюринга и не алгоритмы. Только здесь тоже интереса не вызывает. Хохотунчики одни

Что б придумать новое надо освоить фундаментальные знания, приобрести опыт. Тебе понравилась идея придуманная не тобой. Реально твое предложение это инженерное решение только одной даже не проблемы, а задачи. И ты даже знаешь у кого ты его содрал. . Весьма наивно считать что этого достаточно для построения чего-то серьезного. Но, кое где применить можно и нужно. Одобряю само стремление. Удачи!

Делать- в наше время это не производить. Это придумать и разработать.

В Северодонецке выпускали свои компьютеры и со своими процессорами. Между прочим весьма продвинутыми по своему времени. И ОС была своя..И многопроцессорные системы делали.. Серия ПС-2000 и т.д..

Если серьезный вопрос, то есть такое предложение...

Я этим и занимаюсь. Уже давно. И именно на практике.

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

На ассемблере можно сделать еще быстрее. На обычной архитектуре задачи будут выполняться медленней раза в 2-4.. Зато программировать будет в разы легче. И главный момент. Один раз написанное легко редактируется и применяется. Объединение практически безболезненное. Соединил свойства с методами и нет проблем с внутренностями. Вот это как раз технологическая бомба. Ну, а что эта фишка требует новой архитектуры, да еще многопроцессорной, это факт. Тогда будет еще быстрее работать. Есть еще плюшки. Что сам компьютер может конфигурироваться. Вычислительная часть становится второстепенной. Главное количество шин выборки из памяти. Потому как ветвление происходит очень бурно. Сама выборка команды и двух операндов может создать сразу 4 ветки. А может и больше потому как подписок может быть много.

Можно даже со времен Тьюринга. Так что пора бы усовершенствовать)

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

Нет смысла делать больше и делать переменным. Для определения 64 бит достаточно. А дальше работает иерархия. Мы определили концепт, а теперь им определяем новое понятие. Хотя пока даже не сталкивался с такой необходимостью. Обычно свойств меньше 16-ти. Больше всего у меня события было. Но и то, меньше 8. Методов тоже много не получается. Тем более есть еще статические. Кстати, свойства тоже бывают статические..Если будет нужно больше никто не мешает объединять в группы. Пока такой необходимости не возникало. Еще не сказал состав концепта. Это свойства, методы, события и вложения. Есть еще параметры, но они как бы виртуальное место занимают. При передаче через отдельный регистр, а в концепте адресуемся как к свойству.

4 бита, это базис. Объединение в группу это уже до 16 токенов, что несколько больше. Далее объединяем это понятием концепт (Concept) до 16-ти свойств (Property) и получается вполне достаточно. Минимализм это полезная штука.. А иерархия позволяет быстро развиться до сколь угодно большого уровня.

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

Та получилось даже проще чем синтаксис привычных языков потому как он вообще единый. Не надо плодить сущности без нужды. У меня базовых понятий вообще только 6. Это Токеn- Определяющий размер всего 4 бита, кстати),, Group- объединение концептов,Property-определяющее свойство, Dim — создающий что задано предыдущими понятиями и Concept-создающий из всего этого новое понятие. Ну, и, конечно, Adress. Из этого набора создается вообще все в системе.

Я упустил ваш комментарий. Вот в общем случае вы правы. Что на каждое устройство нужен свой драйвер. Это если делать так как делается. В моей системе нет вообще нужды в эксклюзивных драйверах. Механизм взаимодействия с устройствами, даже не известными происходит на уровне подписок событий к методам. И даже если это «черный ящик» подключение происходит по следующей схеме. Читаем класс «Черного ящика». Структура единая. На основе класса узнаем свойства, методы и события устройства. Делаем подписку на интересующих нас событиях на свои методы или события и наоборот. Свои события на методы подключенного устройства. И мне глубоко по барабану детали «черного ящика». Взаимодействие обеспечено.

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

Хорошо. Только сначала прелюдия. Для начала код имеет два варианта. Один типа ассемблера, второй уже высокого уровня. Для того что б было понятно сначала расскажу как происходит выполнение, а затем парочку примеров на этом ассемблере с подробным объяснением.
Итак, начинаю рассказывать. Я говорил что архитектура событийная. Событие (event) содержит из трех частей. 1-я часть это логическое выражение или высказывание (Condition), которое может и отсутствовать, тогда оно истинно. 2-я часть и 3-я часть это 2 списка подписок при истинности и при ложности после выполнения первой части.
Подписка (Subscription) из 2-х частей. 1-я это адрес запуска метода (типа процедура обработки события), но у нас можно запускать и другое событие (которое в свою очередь начнет выполнять свое Condition) и адрес данных. Например, мы можем по возникновению события изменить данные, передав параметр. Данные тоже могут выполняться. Там можно и методы запустить. Но эти детали уже потом. И 2-я часть подписки это параметр или параметры необходимые для запуская вызываемого концепта. Будь то метод, событие или данные. Вроде все, для начала.
Теперь расскажу как выполняется команда, Сначала, как положено идет выборка операндов. При выборке у данных, если на них есть подписка на какие-то события (А у данных есть события при чтении) своего класса, а могут быть и пользовательские) срабатывает подписка и там запускается цепочка определенная подпиской. Затем выполняется команда и идет проверка на наличие подписок на события возникающие при записи типа данных результата команды..Ну, и само собой при изменении данных там происходить проверка на наличие и отработки подписок на события при записи.
Теперь синтаксис команды сложения единицы. Он общий для всех концептов
Add Po (a, 1) Negative Po
Здесь команда сложения..Сначала имя класса (Add), затем имя этой команды (Po) Далее параметры команды (операнды а и единица) и далее идет подписка на событие Negativ. Подписка простая, без параметра. Проще говоря если результат команды, отрицательный, то выполняем ее еще раз. Вот такая петрушка получается..Это типа ассемблер такой.. Имя события из класса результата операции. Если кажется что это сложно, то отнюдь. Реально к обычной команде добавляется всего один бит, фиксирующий наличие подписки. Для начала думаю достаточно. Если будет интерес, покажу еще кое что..

А с какой целью интересуешься? Могу сказать что получается гораздо круче чем я представлял. Возможности такие что мозги плывут. Было б полезно пообщаться с кем-то. Новый взгляд и вообще новый опыт. Не привычно программировать. Обычно алгоритмы выполняются последовательно, а у меня как бы новое измерение появляется.. Команда выполняется в одном месте где она находится в памяти, а события происходят там, где находятся данные и про чтении и записи операндов могут происходить события и там могут запускать свои ... Даже не скажу что.. Это не только команды..У меня и данные тоже выполняются.. Вообщем круто.. Совсем другие методы программирования.. Циклы, сортировки совсем по другому выглядят.. Логическое программирование тоже интересно получается.. События могут формулироваться как высказывания и получается интерпретация высказываний как бы тоже выполняется.. Но, там еще конь не валялся.. Не хватает времени продумать..

Заканчиваю. Попалась тема не плохая. Смоделировал систему на десктопе.. С транслятором. Так что осталось работы где-то на штуку баксов. Перенести виртуальную архитектуру на контроллер. Ну, и расширять сферу применения. Т.е. добавлять новые устройства, производить и продавать.. Ну, тему удовлетворю готовой системой. Еще 2 месяца есть. Успею.

Я за каталоги говорил. Собирай в папки как угодно и называй их как угодно. Более того каталогов может быть несколько и один товар может находиться в нескольких папках.