КОЛОНКА РЕДАКТОРА
Бурное развитие робототехники в этом веке делает весьма актуальной задачу самообучения роботов. Как и во многих компьютерных играх, в них широко используются экспертные системы (ЭС). Однако факты и правила в ЭС должен поставлять не инженер по знаниям - роботы должны научиться частично извлекать их из окружающей среды, и здесь все заранее не запрограммируешь. Посмотрим, как это может выглядеть в нынешних системах программирования.
Известно, что аббревиатура ООП расшифровывается как объектно-ориентированное программирование. (Правда, Г. Р. Громов, бывший издатель газеты "ComputerWorld-Москва", в которой я начинал свою редакторскую карьеру, запрещал использовать эту аббревиатуру, расшифровывая ее как "Организация освобождения Палестины". :)) Напомню, что ООП базируется на понятии объекта, принадлежащего тому или иному классу объектов, и на трех китах, определяющих свойства объекта: наследовании, инкапсуляции и полиморфизме. Каждый объект может иметь так называемые свойства и методы. Свойства - это элементы данных внутри объекта, методы - внутренние процедуры, исполняемые при обращении к объекту. Наследование позволяет нам создавать подклассы данного класса на основе уже существующего (базового, родительского) класса. Инкапсуляция - скрытие внутренней структуры данных и реализации методов объекта от остальной программы. Доступен только интерфейс объекта, через который посредством сообщений осуществляется все взаимодействие с ним. Полиморфизм - если сильно упростить, способность объекта выбирать правильный метод (внутреннюю процедуру объекта) в зависимости от типа данных, полученных в сообщении.
Языки высокого уровня (ЯВУ), поддерживающие ООП, называются объектно-ориентированнными. Это С++, Java, SmallTalk, Visual Prolog и множество других. Сейчас как-то немодно не поддерживать в ЯВУ объектно-ориентированность.
Программист описывает сначала некий абстрактный класс объектов, его свойства и программирует методы. Затем из абстрактного класса можно выделить подклассы объектов. У него есть возможность создать в программе объект заданного класса, присвоить ему какие-то свойства и т. д.
В то же время при реализации ряда задач возникает понимание, что указанных возможностей ООП уже не хватает. Во-первых, новые методы и свойства объекта не могут быть созданы динамически, а в программах искусственного интеллекта (ИИ) это, как мне представляется, часто необходимо. Добавить новые свойства в описание объекта не так трудно, используя, например, широко применяющийся в Лиспе и Прологе механизм списков. В ряде ЯВУ такая работа со свойствами уже существует. (Нельзя сказать, что ООП не развивается. Недавно в нем появилась парадигма аспектного программирования, см. http://aosd.net.) Динамическое создание методов для откомпилированной программы - задача не совсем простая, но, к счастью, сейчас есть такие инструменты, как JIT ("компиляция-на-лету"), динамическая компоновка и др.
Что это дает, станет понятно из второго пожелания к ООП - хотелось бы иметь возможность создавать объект не определенного заранее класса, т. е. если сейчас описания всех объектов заранее закладываются в программу, то в программах ИИ, выявив нечто, было бы неплохо назвать это объектом и, накапливая информацию о его свойствах и методах, позволить их создавать в программе динамически. Если у нас два или более полученных таким образом объектов, то можно пойти дальше и построить из них некоторую абстракцию, т. е. класс, содержащий шаблон для создания других объектов данного класса. Рассматривая несколько созданных таким образом классов, можно построить над ними надкласс, или суперкласс, и т. д. Таким образом, если нынешний ООП идет сверху вниз (ООП-), то, по крайней мере в задачах распознавания, ему недостает восходящего процесса (ООП+).
В реальных задачах ИИ все распознанные объекты никогда не совпадают, и нам необходима операция типа look like, которой также нет в нынешнем ООП, - определение степени похожести объектов как совпадения их свойств и методов. Вопрос этот весьма непрост и упирается в выбор критериев. Человек определяет похожесть прежде всего по форме и назначению, а затем по другим признакам.
Есть два соображения, почему было бы интересно расширить концепцию ООП. Во-первых, используемая парадигма в значительной степени определяет результат. Например, по мнению Н. П. Брусенцова, создателя троичного компьютера, одной из причин неуспеха японской программы построения машин пятого поколения (www.icot.or.jp/ARCHIVE/HomePage-E.html) было то, что в качестве базового языка для нее был выбран Пролог, базирующийся, если опустить все промежуточные слова о дизъюнктах Хорна, на двоичной логике. А провал Intel с намного опередившим свое время объектно-ориентированным процессором iAPX 432 кроме технологических трудностей, по утверждению Б. А. Бабаяна, обусловлен неправильной работой с объектами, приведшей к резкому снижению производительности.
С другой стороны, в ИИ эволюционный подход позволяет получить, на мой взгляд, более интересные результаты, чем известные в настоящее время. (Хотя выделение Пентагоном колоссальных сумм на робототехнику заставляет предположить, что американцы уже значительно продвинулись в этом направлении.) То, что единожды это сработало, можно с уверенностью утверждать, глядя на творение Господа - Человека.
Интересно, что вы думаете по поводу вышесказанного. Пишите мне по адресу: editorial@pcweek.ru.
