Comments 22
Переизобретаете OWL? Или RDFS? Или HATEOAS? Или ПРОЛОГ? Или фреймы Минского? Думаю, нужна какая-то модельная задача, приложение, пример применения вашего Языка, иначе не очень понятно, зачем это всё.
В указанных подходах понятие свойств пассивно и приобретает смысл только в силу реализации определенного механизма вывода. В предлагаемом подходе свойство активно. Свойство само хранит знания и выдает результат.
Основной плюс, на мой взгляд, в том что не надо заранее продумывать и фиксировать какую-то жесткую структуру объектов и их свойств с учетом всех возможных изменений в будущем. Свойства легко добавлять к уже реализованным объектам по мере необходимости. В обработке естественного языка это актуально.
Нет, во всех этих представлениях семантической сети как раз все свойства динамические и доопределяемые (в этом, собственно, и суть этих форматов/протоколов/языков, суть проблемы описания бесконечно расширяемой семантической сети).
Если вспомнить синтаксис естественного языка, то известно, такой языковый знак как слово имеет характеристики: состояние, свойство, действие. Похоже ваш "новый язык" включает эти характеристики неким кодовым/знаковым образом. Любой язык коммуникационная система с использованием знаков порядок которых устанавливается доступным образом. Так что ваш подход не уникален.
Если вспомнить синтаксис естественного языка, то известно, такой языковый знак как слово имеет характеристики: состояние, свойство, действие.
Есть даже язык программирования основанный на основе СЛОВА — Форт (Forth) а также группа языков конкатенативной парадигмы. ?
Был, к примеру, сделан и дипломный проект в рамках широко использования слов русского языка в окружении условного Форт — небольшой браузер HTML файлов. (почти выглядивщий как программа-«роман» в словах)
P.S. Попытка автора статьи ввести синтаксические/семантические конструкции структурного плана сразу уменьшают мощность потенциального использования такого языка в сравнении, к примеру, в сравнении с DSL направленостью.
Сама идея классификации различных сущностей с помощью привычных для человеческого мышления понятий очень хороша и напрашивается сама собой. И это очень хорошо отображается на обычные части речи (существительное, прилагательное и глагол, т.е. объект, свойство и действие), но дьявол как обычно в деталях.
Ведь семантический анализ текста со свободной лексикой легко не сделать. Да и чем сложнее синтаксис будет становиться, тем труднее будет его использовать. А если взять строгие правила оформления кода программ, то получится еще один из десятков тысяч языков программирования.
У меня подход к данной теме немного другой. Разработать язык программирования с такой семантикой, в которую бы вписывались любые термины и комбинации символов, т.е. язык программирования без привязки к ключевым словам только на основе грамматики и тем самым сосредоточится не на теории, а уже на реализации.
В области ИИ я ничего не понимаю, и наверное вы придумали что-то полезное, но замечу:
Два, одинаково называемых поля в
разных объектах это два совершенно разных системных объекта
может быть один экземпляр свойства между многими объектами
... и не имеющих ничего общего с точки зрения системы
у них один тип или класс или интерфейс или структура или экземпляр
Человек воспринимает свойство самостоятельной сущностью и говоря, например, о цвете машины и о цвете волос, мы понимаем, что речь идет об одном свойстве – цвете
да, это тип
Следовательно, для реализации алгоритмов, моделирующих мыслительные процессы человека, свойство и объект должны быть представлены в виде самостоятельных и равноправных структур
они так и представлены, как объект и как тип свойства
Так как описание объекта максимально абстрактно («Нечто»), а новые свойства легко определяются и добавляются, то функциональность может быть расширена без необходимости внесения изменений в уже реализованные действия
Это объект JS или словарь. А потом понадобится ответить на вопрос "как работать с этим объектом, когда я забыл где и что добавлял, и есть ли оно в данный момент", и вы изобретёте контракт и класс. JS -> TS. А функциональность при наследовании и так расширяется без изменений, или меняется где это нужно через override. Или допустим на строго типизированном языке можно сделать класс, у которого все свойства и методы будут в словаре, и вызывать методы Get Set Call, что и происходит в JS. Только это будет в одном случае, а всё остальное строго. И будет это дженерик, у которого для свойств указывается один и тот же тип, или any/object для любого типа. И через этот тип свойства в разных объектах связаны по смыслу. А когда нужно связать их ещё и по поведению в рантайме, то они просто станут ссылками на объект свойства где-нибудь в куче.
В условиях острого недостатка новых идей
Сильно сказано. Может они просто не проходят отбор.
В частности, на многие десятилетия считающееся само собой разумеющимся представление о том, что объект первичен, а свойство привязано к объекту.
Потому что по определению, объект - это данные и методы их обработки. Если данные сами по себе - то никакого объекта нет. Там где данные не привязаны к объекту, есть например функциональное или процедурное программирование. И у вас о свойствах представление как о примитивах типа целого числа, но они могут быть объектами, их смысловая связь прямо прописана в виде класса.
"может быть один экземпляр свойства между многими объектами"
- Возможно, я не совсем понял, что вы имеете в виду, но один экземпляр вполне может быть как значение свойства, да. Но смысл свойства определяется не значением, а тем откуда оно получается. Например "высота = 2" и "ширина = 2" - ссылаются на один и тот же объект (2), но имеют разный смысл, так как ссылки идут из разных областей памяти. И тип объекта (в данном случае - целое число) не определяет смысл свойства. Можно сделать класс или структуру, назвать ее Color, но смысл у нее появится только в зависимости от того как мы ее будем использовать, то есть откуда будем на нее ссылаться.
" Потому что по определению, объект - это данные и методы их обработки."
- это в объектно-ориентированном программировании. Именно это положение и предлагается пересмотреть в предлагаемом свойство-ориентированном подходе.
смысл у нее появится только в зависимости от того как мы ее будем использовать, то есть откуда будем на нее ссылаться
Не обязательно. У целого числа 2 может быть потомок Width. Тогда он будет отличаться от Height. В любых объектах, которые их используют. Это можно делать наследованием или каким-нибудь брендированием для передачи смысла "2 как ширина". А у Color может быть наследник SkyColor или color.type = sky. То есть цвет не имеет смысла, и используется там, где смысл не важен, а цвет неба используется там, где важно его отличать от цвета кожи.
Сделайте обобщённый класс Sense<T,S>, и сможете для полей писать смысл, и он будет единый для всего проекта. Например поле "ширина_кабины" : Sense<int,кабины> = 5.
В моем понимании «глубоко копнуть» это показать середину луковицы
где дальше только сенсорная информация.
Определенные комбинации сигналов с сенсоров приводят к рефлекторным реакциям или выбросу тех или иных веществ в мозг, которые и влияют на выполняемые действия.
Рефлексы это «короткие» пути обработки сигналов, не контролируемые (или слабо контролируемые) более высокими уровнями «луковицы».
Создание ИИ должно идти не путем создания «языка», язык это высокоуровневая составляющая.
Попробую привести аналогию:
Вы знаете как устроена и на каких принципах функционирует совеменная вычислительная техника (от транзистора, до ОС и в самом конце пользовательское ПО).
Для ИИ практически ничего кроме нейрона (транзистора) достоверно ничего неизвестно, да и нейрон исследован относительно слабо. Если перенести современные знания о ИИ на современную вычислтетельную технику. Вы программы (аппаратуру тоже ) для компьютера писали бы не на языках программирования, а с использованием «глубокого обучения» случайных последовательностей ассемблерных комманд. При этом не понимая что такое ассемблер, который тоже был получен методом «глубокого обучения» «транзисторных сетей».
Думаю теперь Вы понимаете насколько «смешными» являются современные знания о ИИ.
Если у Вас есть желание серьезно заняться ИИ, пишите.
Насчет "смешного" текущего уровня ИИ согласен. Плохо, что от частого неоправданного использования, дискредитируется сам термин искусственный интеллект. Очень актуальна задача перехода от "глубокого обучения" к более высокоуровневым алгоритмам. А для этого надо понять с какими понятиями работает мозг. Если проводить аналогию с электронными компонентами, то необходимо перейти от рассмотрения отдельных транзисторов к рассмотрению функциональных блоков, дискретных элементов, микросхем.
Собственно в статье я и сделал такую попытку - описанный в разделе 2.1 базовый системный элемент мог бы, на мой взгляд, служить таким базовым блоком. Но наверняка кто-то может и другие гипотезы предложить.
В свое время японцы попытались реализовать что очень похожее, по ряду причин проект провалился.
Если интересно, почитайте:
ru.wikipedia.org/wiki/Компьютеры_пятого_поколения
Есть проблема — абсолютное большинство людей обладают крошечным кругозором (программисты особенно) и ничего кроме распиаренных фон Неймана и нейронных сетей не видят. Народ банально не хочет думать и даже научное сообщество в прямую говорит, что если то о чем вы пишете уже не описано в 10+ работах передовых ученых, то это ерунда недостояная даже прочтения (про анализ написанного даже не говорю).
... Человек воспринимает свойство самостоятельной сущностью ...
Ну, если учесть объективный научный факт того, что материя (объективная реальность) проявляется только и исключительно через свои свойства, то такое отношение вполне логично и объективно. :)
... свойство и объект должны быть представлены в виде самостоятельных и равноправных структур ...
То, что мы воспринимаем, как "самостоятельную" сущность и объект, объективно является функцией, т.е. свойством, иной сущности и объекта.
Объективно, любой ЯП реализует свойство-ориентированный подход. Так, что автор несколько нелогичен, когда пытается выделить свойство, как некую "самостоятельную" сущность.
Нелогичность в философской основе предлагаемого проекта, закономерно приведет к его логическому тупику, при практической реализации и применении, или замкнет его на очень узком диапазоне решаемых задач.
То что сейчас называется ИИ, больше похоже на цифровую обработку сигнала. В сигнальном графе нет понятия принадлежности и иерархии. Семантика таких средств как TensorFlow не зависит от языка программирования, поскольку реализует базовые понятия кибернетики.
Я и забыл, что КДПВ может не отображаться в самой статье. Boomburum, так и задумано?
Идея для языка программирования искусственного интеллекта. Свойство-ориентированный подход