Вы будете смеяться, но есть такая система. Тоже работал в космических программах и знаком со стандартами на ПО, но они здорово устарели. И обычно требования сформулированы подразумевая двоичные файлы и ассемблер. Если интересно, можем пообщаться. Вся система строго формализована. И языки и протоколы. Верификация предусмотрена. Предназначение именно для автоматизации и управления устройствами. Годится как стандарт. Собственно, я так и делал.
Не думаю что существует общее решение. Каждая компания должна сама о себе заботиться. Собственно, вы эту мысль и высказали когда сказали что создатель документа лучше знает за уровень безопасности создаваемого. Общие методы и сервис понятно что должен быть. Но, не стану даже рекомендовать.
Извини, но мы разговариваем ни о чем. И ты критикуешь неизвестно что. Я говорю что можно. Ты говоришь что нельзя. Аргументом что все уже решено. Мне еще раз повторить что не решено? Еще раз повторить что это совсем другая архитектура?
А достаточно глубоко ее можно продумать только реализовав и описав хотя бы ее модель.
Как бы я математик. Именно формализовано все. Причем базовых понятий всего 3. Правда, это не противоречит что надо думать еще глубже.
А что, объект у вас не может быть значением?
Строго говоря не может. Но, в слова и в понятия каждый может вкладывать свой смысл. У меня все строго. И все типы и события все формализовано. Кстати, что такое события?
А вот нельзя. Макрооперации - можно. Но чтобы их распараллеливать, должен быть какой-то планировщик, должны быть какие-то атрибуты у операций и так далее, т.е. как минимум, они не могут быть атомарными, ниже них должно быть что-то ещё.
Ты за классическую архитектуру. А в моей можно. Поговорить что считать атомарными. А зачем?
Мы и сейчас точно так же можем делать, тоже на некотором уровне абстракций.
Несомненно. Я уже говорил что даже реализовал на STM32
Естественно, можно такой "событийный" уровень перенести и из прикладного софта на уровень взаимодействия "процессор-ОС", но мы-то все равно никуда не денемся от атомарных микроопераций.
Конечно. Отличие только в том, что атомарные мирооперации можно распараллелить по нескольким шинам доступа и процессорам. Анализ на истинность событий и переход по подпискам можно выполнять тоже параллельно. При такой логике работы прерывания вообще не нужны, если есть свободная шина доступа и процессор, если есть необходимость в выполнении команд.
И все равно останется нерешённым вопрос, с которого вся эта ветка началась: зачем это надо?
Это только та часть что касается работы с устройствами, и отличие в логике работы. Ибо с этого начался разговор. Т.е. для работы в области автоматизации это реальная бомба. Работы с приложениями, файлами и редактор я только коснулся. Пока не готов обсуждать за подробности, ибо надо усвоить, еще некоторые нюансы работы, потом структуры концепта (важно), затем языка и потом будут понятны плюшки для обычного применения. Я просто скопирую итоговое курсивом.
Управление системой универсально и предлагает:
a.) Визуализацию. Легко визуализируется в виде текста, элементов управления, таблиц или в любом другом виде удобном для пользователя. Фактически браузер. С любым наполнением и «оживлением» в виде создания собственных событий и реакций.
b.) Добавление новых подписок изменяя функционал.
c.) Добавление новых классов концептов и концептов.
d.) Обеспечивает универсальный протокола обмена так как представляет собой обмен концептами, классы которых описаны в приемнике и передатчике (если описание класса отсутствует, то его можно запросить у передатчика), потому универсален и прост так, как структура каждой транзакции сформулирована в описании класса передаваемого концепта. По этой причине система легко интегрируется и фактически является распределенной. Причем распределенными автоматически являются и сервера и устройства управления и браузеры построенные на предлагаемых принципах. Облачный сервис предлагается как часть общего принципа работы системы.
e.) Универсальна структура документов, потому нет необходимости в расширениях файла. Обмен и загрузка данных (и визуальное представление) универсальны. Как и и процесс их редактирования, представляющих данные в различных видах представления. Одним из которых является текстовый и одновременно транслятор. Табличная форма получается автоматически как Exel, графика и прочее просто виды представления. По этой причине среда является одновременно и транслятором и редактором и браузером и сервером.
Я понял твой вопрос. Я думаю как отвечать. Вот берем пример программы. Если выпадет снег, нужно его убрать. Программа? Ты гарантируешь что снег будет убран? (Т.е. в привычной терминологии выполнить программу) Вроде да.. А в жизни кто-то должен выглядывать в окно. Т.е. должно еще что-то произойти что б программа запустилась. И вот это что-то произошло. Что называть выполнением? Уборку снега или действия по обнаружению снега? В привычной архитектуре когда ты пишешь программу, интуитивно подразумевается что эта программа запустится и будет выполняться в том, порядке оператор за оператором в котором записана. А это не разумно хотя бы с точки зрения сохранения энергии. Вот в моей архитектуре не выполняются операторы как написано в тексте. Я даже программой это не могу назвать. Это скорее описание концептов (пусть объектов) и взаимодействия между ними. И процессор начинает работать с адресации (выглядывает в окно), анализирует события на которые есть подписка и потом осуществляет переход по истинности события, на которые (их может быть много) есть подписки. И все это параллельно! Фух, надо отдохнуть. По моему доступно описал работу процессора)) Вот получаем граф. Или нейронную сеть. Следующая порция позжее..
Ну, если говорить про существующие системы, то проще не в ядро изменения вносить, а написать универсальный драйвер, с которым будут работать все устройства, поддерживающие ваше соглашение.
Не получается так. Именно это я и хочу сказать. Императивная парадигма не позволяет.
Но на вопрос вы все еще не ответили: как именно вы хотите унифицировать бесконечное разнообразие устройств включая все, которые будут изобретены в будущем?
Ты очень правильно сформулировал проблему насчет будущих. Проблема почти Воланда. Не, только работать с будущими устройствами, но и так как захочется в будущем. А человек сейчас хочет так, а завтра по другому. К сожалению, не имею хрустального шара что б за пару фраз сказать и все станет понятно. И так кручусь как жук на сковородке подбирая слова, что б было близко к тому, чем занимаюсь. Надо полностью изучить основы. Документ я могу прислать, но лучше в общении. Это часа 3 минимум. Потом что б прошло пару дней что б улеглось и еще побеседовать. И только потом есть смысл показывать примеры. Я не выпендриваюсь. Просто по опыту. Не первый семинар уже провел.
И как я понимаю из ваших слов, вы знаете решение. Возможно, требующее специального «универсального драйвера» и соглашения на разработку устройств.
Да. Конечно, без соглашения никак. Скорее не "универсальный драйвер" а универсальный механизм взаимодействия. Кроме того событийная архитектура процессора. Ведь классическая архитектура это часть соглашения. Не объявленная, но подразумевающаяся.
Ты хочешь что б я рассказал за систему? Я с удовольствием. Сказал же что введение только попробовал опубликовать и не одобрил модератор. А что мало-мальски сложные устройства не работают, так и есть проблема. Могу только добавить что и простые устройства не работают. Простой выключатель попробуй добавить. Кстати, это главная фишка моей системы. В области автоматизации и ИИ это прорыв.
Вот именно, по этой причине все параметры настроек логично размещать в самом принтере. Это даже естественно. А система должна их вкусно визуализировать и подать на редактирование.
Спасибо за ответ. Я давно не понятный. И не знаю как объясниться. Пробую объяснить базовые понятия. Никому не интересно. Не хочу выглядеть идиотом. В двух словах это приблизительно так, как мы общаемся и понимаем друг друга и обходимся без софта. Вот где-то такая машина. И событийная и немного на Пролог похожа.
Вы будете смеяться, но есть такая система. Тоже работал в космических программах и знаком со стандартами на ПО, но они здорово устарели. И обычно требования сформулированы подразумевая двоичные файлы и ассемблер. Если интересно, можем пообщаться. Вся система строго формализована. И языки и протоколы. Верификация предусмотрена. Предназначение именно для автоматизации и управления устройствами. Годится как стандарт. Собственно, я так и делал.
Не думаю что существует общее решение. Каждая компания должна сама о себе заботиться. Собственно, вы эту мысль и высказали когда сказали что создатель документа лучше знает за уровень безопасности создаваемого. Общие методы и сервис понятно что должен быть. Но, не стану даже рекомендовать.
Извини, но мы разговариваем ни о чем. И ты критикуешь неизвестно что. Я говорю что можно. Ты говоришь что нельзя. Аргументом что все уже решено. Мне еще раз повторить что не решено? Еще раз повторить что это совсем другая архитектура?
Объект. https://habr.com/ru/post/275599/
А достаточно глубоко ее можно продумать только реализовав и описав хотя бы ее модель.
Как бы я математик. Именно формализовано все. Причем базовых понятий всего 3. Правда, это не противоречит что надо думать еще глубже.
А что, объект у вас не может быть значением?
Строго говоря не может. Но, в слова и в понятия каждый может вкладывать свой смысл. У меня все строго. И все типы и события все формализовано. Кстати, что такое события?
Но слышал достаточно чтобы понять что ничего нового вы пока не описываете
Думаю недостаточно даже с ООП. Вот буква это объект или значение? ) Уверен, что не сможешь сформулировать.)
А вот нельзя. Макрооперации - можно. Но чтобы их распараллеливать, должен быть какой-то планировщик, должны быть какие-то атрибуты у операций и так далее, т.е. как минимум, они не могут быть атомарными, ниже них должно быть что-то ещё.
Ты за классическую архитектуру. А в моей можно. Поговорить что считать атомарными. А зачем?
Похоже на описание функционального программирования «сверху вниз», где вместо описания последовательности действий используются условия.
Ты имеешь в виду декларативное программирование. Частично похоже. Только не на функциональное а на логическое. Типа Пролога. Этому есть объяснение.
Ориентация на событиях вместо опроса тоже широко распространена — прерывания, сигналы, сообщения.
Реактивное программирование называется. В этой теме. Только значительно продвинутое.
Революции в компьютерных техниках уже прошли, сейчас время эволюций.
А я думаю что назрело и перезрело. Дальнейшее развитие в распараллеливании. А предложений принципиальных нет.
При чем здесь парадигма? Данные это всего лишь данные, способ обработки вы вольны выбирать сами.
Оно то так, но трудно складывать кубик из шаров.
Мы и сейчас точно так же можем делать, тоже на некотором уровне абстракций.
Несомненно. Я уже говорил что даже реализовал на STM32
Естественно, можно такой "событийный" уровень перенести и из прикладного софта на уровень взаимодействия "процессор-ОС", но мы-то все равно никуда не денемся от атомарных микроопераций.
Конечно. Отличие только в том, что атомарные мирооперации можно распараллелить по нескольким шинам доступа и процессорам. Анализ на истинность событий и переход по подпискам можно выполнять тоже параллельно. При такой логике работы прерывания вообще не нужны, если есть свободная шина доступа и процессор, если есть необходимость в выполнении команд.
И все равно останется нерешённым вопрос, с которого вся эта ветка началась: зачем это надо?
Это только та часть что касается работы с устройствами, и отличие в логике работы. Ибо с этого начался разговор. Т.е. для работы в области автоматизации это реальная бомба. Работы с приложениями, файлами и редактор я только коснулся. Пока не готов обсуждать за подробности, ибо надо усвоить, еще некоторые нюансы работы, потом структуры концепта (важно), затем языка и потом будут понятны плюшки для обычного применения. Я просто скопирую итоговое курсивом.
Управление системой универсально и предлагает:
a.) Визуализацию. Легко визуализируется в виде текста, элементов управления, таблиц или в любом другом виде удобном для пользователя. Фактически браузер. С любым наполнением и «оживлением» в виде создания собственных событий и реакций.
b.) Добавление новых подписок изменяя функционал.
c.) Добавление новых классов концептов и концептов.
d.) Обеспечивает универсальный протокола обмена так как представляет собой обмен концептами, классы которых описаны в приемнике и передатчике (если описание класса отсутствует, то его можно запросить у передатчика), потому универсален и прост так, как структура каждой транзакции сформулирована в описании класса передаваемого концепта. По этой причине система легко интегрируется и фактически является распределенной. Причем распределенными автоматически являются и сервера и устройства управления и браузеры построенные на предлагаемых принципах. Облачный сервис предлагается как часть общего принципа работы системы.
e.) Универсальна структура документов, потому нет необходимости в расширениях файла. Обмен и загрузка данных (и визуальное представление) универсальны. Как и и процесс их редактирования, представляющих данные в различных видах представления. Одним из которых является текстовый и одновременно транслятор. Табличная форма получается автоматически как Exel, графика и прочее просто виды представления. По этой причине среда является одновременно и транслятором и редактором и браузером и сервером.
Как частный случай может быть и нейронка.
Я понял твой вопрос. Я думаю как отвечать. Вот берем пример программы. Если выпадет снег, нужно его убрать. Программа? Ты гарантируешь что снег будет убран? (Т.е. в привычной терминологии выполнить программу) Вроде да.. А в жизни кто-то должен выглядывать в окно. Т.е. должно еще что-то произойти что б программа запустилась. И вот это что-то произошло. Что называть выполнением? Уборку снега или действия по обнаружению снега? В привычной архитектуре когда ты пишешь программу, интуитивно подразумевается что эта программа запустится и будет выполняться в том, порядке оператор за оператором в котором записана. А это не разумно хотя бы с точки зрения сохранения энергии. Вот в моей архитектуре не выполняются операторы как написано в тексте. Я даже программой это не могу назвать. Это скорее описание концептов (пусть объектов) и взаимодействия между ними. И процессор начинает работать с адресации (выглядывает в окно), анализирует события на которые есть подписка и потом осуществляет переход по истинности события, на которые (их может быть много) есть подписки. И все это параллельно! Фух, надо отдохнуть. По моему доступно описал работу процессора)) Вот получаем граф. Или нейронную сеть. Следующая порция позжее..
Ну, если говорить про существующие системы, то проще не в ядро изменения вносить, а написать универсальный драйвер, с которым будут работать все устройства, поддерживающие ваше соглашение.
Не получается так. Именно это я и хочу сказать. Императивная парадигма не позволяет.
Но на вопрос вы все еще не ответили: как именно вы хотите унифицировать бесконечное разнообразие устройств включая все, которые будут изобретены в будущем?
Ты очень правильно сформулировал проблему насчет будущих. Проблема почти Воланда. Не, только работать с будущими устройствами, но и так как захочется в будущем. А человек сейчас хочет так, а завтра по другому. К сожалению, не имею хрустального шара что б за пару фраз сказать и все станет понятно. И так кручусь как жук на сковородке подбирая слова, что б было близко к тому, чем занимаюсь. Надо полностью изучить основы. Документ я могу прислать, но лучше в общении. Это часа 3 минимум. Потом что б прошло пару дней что б улеглось и еще побеседовать. И только потом есть смысл показывать примеры. Я не выпендриваюсь. Просто по опыту. Не первый семинар уже провел.
И как я понимаю из ваших слов, вы знаете решение. Возможно, требующее специального «универсального драйвера» и соглашения на разработку устройств.
Да. Конечно, без соглашения никак. Скорее не "универсальный драйвер" а универсальный механизм взаимодействия. Кроме того событийная архитектура процессора. Ведь классическая архитектура это часть соглашения. Не объявленная, но подразумевающаяся.
Если очень коротко, то я предлагаю даже исключить пункт "запустить нужную программу".
Ты хочешь что б я рассказал за систему? Я с удовольствием. Сказал же что введение только попробовал опубликовать и не одобрил модератор. А что мало-мальски сложные устройства не работают, так и есть проблема. Могу только добавить что и простые устройства не работают. Простой выключатель попробуй добавить. Кстати, это главная фишка моей системы. В области автоматизации и ИИ это прорыв.
Не все так печально)) Есть такая метода. И, уверен, ты их десяток и сам способен придумать. Я в систему построил именно с такой логикой.
Вот именно, по этой причине все параметры настроек логично размещать в самом принтере. Это даже естественно. А система должна их вкусно визуализировать и подать на редактирование.
Спасибо за ответ. Я давно не понятный. И не знаю как объясниться. Пробую объяснить базовые понятия. Никому не интересно. Не хочу выглядеть идиотом. В двух словах это приблизительно так, как мы общаемся и понимаем друг друга и обходимся без софта. Вот где-то такая машина. И событийная и немного на Пролог похожа.
И работает по другому и смысл другой. И вопрос не синтаксиса, а внешнего вида. Ладно. Спасибо за мнение.