Тут язык очень сильно держит. Например, те же "наследования" идут как раз от ООП модели и определяются хитростями движка (т.е. неявно в ваших терминах это "код"). См, например, наследование буквально в первом пункте http://www.ksl.stanford.edu/software/jtp/doc/owl-reasoning.html -- это ведь именно в обсуждении reasoning, т.е. "execution-по-логически" (для функциональных это же "наследование" будет обсуждаться как evaluation, т.е. "execution-по-функциональному"). Кстати, "компиляция" (а хоть и модели данных в физическую схему, или трансформация модели данных из одного представления в другое -- или даже кода на языке программирования в исполнимое представление. Но можно скомпилировать и код без единой команды, только определения структур данных) это, как меня учили, просто "исполнение/вычисление в особом смысле". Никакой "имплементации", исключительно абстрактные синтаксисы.
У меня мысля такая, что наследование нужно для моделирования данных/мира - посему и делались различные попытки сделать ООСУБД, ОРМ и онтологии. Но наследование как оно реализовано в ООП - а оно там реализовано по разному, к моделированию данных имеет опосредованное значение: в одном языке мы можем выразить так, а в другом языке те же данные так не можем, но можем по другому. Т.е. семантика наследования всегда разная.
Вобщем и получается что моделирование данных к ООП не сводимо на практике, т.е. нет такого, по крайней мере, общепринятого языка программирования, в которым бы выражалось наследование и он был бы пригоден именно для моделирования данных, независимо от реализации. Хотя мне думается что онтологии - хоть OWL хоть 15926 этого достигают.
Даже OWL и 15926 -- это традиционная линия рассуждений про наследование. Но ведь есть ещё прототипная парадигма (линия family resemblance Витгенштейна, затем популяризированная Лакоффом, и в сильно искажённом виде попавшая и в computer science в разных изводах прототипного ООП и фреймовых систем в AI). Она мало разработана, хотя justy_tylor ну вот прямо сейчас пытается скрестить её с современными теориями типов и сделать именно что язык данных -- http://justy-tylor.livejournal.com/195108.html (и там ещё в комментах он мне про это подробнее говорит).
Ещё одно соображение: на форуме онтологов нет согласия в том, может ли быть процедура (на процедурном языке) онтологией, или не может. Часть профессоров пытается провести рассуждение про "только данные", но другая часть эффективно сопротивляется, показывая, что любая (даже процедурная, не говоря уж о функциональной или логической) программа вполне онтологична по природе своей.
Ну да, это очень тонкий момент. Я бы сказал что пока промышленно умеют работать только с данными. Но нет оснований полагать что нельзя включить сюда и вычислимые вещи, уж декларативка-то просится.
Тут примерно та же ситуация как с языком ограничений, UML более-менее юзается, а вот с OCL уже беда.
Я бы сказал, что простенькие функции имеет смысл включать уже сейчас, типа сложить умножить аггрегация и пр. Скажем описываемое map/reduce/filter и стандартными операциями
С UML хитрая вещь произошла: из него было выделено ядро (мета-язык) MOF, а сам UML расписан в терминах этого мета-языка. На базе MOF породили чёртову тучу языков, и вот для этой чёртовой тучи языков использование OCL уже много более популярно. Но, конечно, это "более популярно" относится примерно к такому же количеству людей, как количество пишущих на Хаскеле :-)
В ISO 15926 столкнулись буквально в эти дни с той же проблемой: или мы определяем, что такое наследование (и тогда должны выбрать логический язык для этого -- хоть OCL, хоть Common Logic, хоть какой-нибудь из зоопарка semantic web), или мы не определяем, что такое наследование и воздерживаемся от введения аксиом и вычислений/выводов.
Моя же позиция в том, что "язык программирования общего назначения с развитыми библиотеками -- это неплохой язык ограничений". Тут меня вполне уже убедили, и даже показали пример, как это делается в Питоне :-D
Я кстати вспомнил про такую вещь как Datalog - очень интересно в плане именно моделирования данных, ибо там есть хоть и ограниченная но функциональность. А в ограниченности ее плюс, ибо она допускает более-менее эффективную реализацию. Еще интереснее Datalog with disjunctive rules ибо тут уже можно привычное для ООП наследование делать
Данные это не "яблоко на столе и общий класс Яблоко", а описания яблока и класса. Именно на этом онтологии рушатся, ибо вместо вечных истин в реальности оказываются product types, sum types и полиморфизм, с которым онтологи работать не умеют вообще.
Мне нравятся функциональный подход весьма, но к примеру наследование в нем выражать геморройно. Возможно на программерском уровне это особо и не надо, но на уровне описания предметной области это важно
( ... )
Наследование есть везде где есть иерархии Прототипы-то тоже наследуют просто динамически, а в ОО обычно статическое наследование Поскольку данные/онтология независимы от имплементации, то статическое наследование удобнее
Comments 15
Reply
Но наследование как оно реализовано в ООП - а оно там реализовано по разному, к моделированию данных имеет опосредованное значение: в одном языке мы можем выразить так, а в другом языке те же данные так не можем, но можем по другому. Т.е. семантика наследования всегда разная.
Вобщем и получается что моделирование данных к ООП не сводимо на практике, т.е. нет такого, по крайней мере, общепринятого языка программирования, в которым бы выражалось наследование и он был бы пригоден именно для моделирования данных, независимо от реализации.
Хотя мне думается что онтологии - хоть OWL хоть 15926 этого достигают.
Reply
Reply
Reply
Ну да, это очень тонкий момент.
Я бы сказал что пока промышленно умеют работать только с данными.
Но нет оснований полагать что нельзя включить сюда и вычислимые вещи, уж декларативка-то просится.
Тут примерно та же ситуация как с языком ограничений, UML более-менее юзается, а вот с OCL уже беда.
Я бы сказал, что простенькие функции имеет смысл включать уже сейчас, типа сложить умножить аггрегация и пр. Скажем описываемое map/reduce/filter и стандартными операциями
Reply
В ISO 15926 столкнулись буквально в эти дни с той же проблемой: или мы определяем, что такое наследование (и тогда должны выбрать логический язык для этого -- хоть OCL, хоть Common Logic, хоть какой-нибудь из зоопарка semantic web), или мы не определяем, что такое наследование и воздерживаемся от введения аксиом и вычислений/выводов.
Моя же позиция в том, что "язык программирования общего назначения с развитыми библиотеками -- это неплохой язык ограничений". Тут меня вполне уже убедили, и даже показали пример, как это делается в Питоне :-D
Reply
Еще интереснее Datalog with disjunctive rules ибо тут уже можно привычное для ООП наследование делать
Reply
Reply
Reply
Наследование по данным есть в САПРах и подобном софте. Клоны, галереи, префабы, ... Там получается ближе к прототипной модели, чем к классовой.
Reply
Прототипы-то тоже наследуют просто динамически, а в ОО обычно статическое наследование
Поскольку данные/онтология независимы от имплементации, то статическое наследование удобнее
Reply
Leave a comment