OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Понедельник, 22 Октябрь, 2018 22:42

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 29 ]  На страницу Пред.  1, 2
Автор Сообщение
 Заголовок сообщения: Re: Сложно ли написать свою СУБД?
СообщениеДобавлено: Вторник, 12 Июль, 2011 15:07 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
alexus писал(а):
... При разработке систем есть два вида абстракций, каждая из которых важна для успешной реализации. Первая абстракция - это абстракция данных. Это совсем не ассемблер... Описание данных удачно реализовано в DDL (data definition language) SQL, IDEF, ER-диаграммах и т.п. Это все представители декларативных (частью визуальных) "языков". Когда я знакомился с Драконом, то меня несколько озадачило небрежное отношение автора к декларативным языкам. На декларативные языки ложится значительная семантическая нагрузка при создании системы.
М.б. здесь надо говорить не о небрежности, а об авторской точке зрения, проистекающей из специфики разработок. Ведь ГРАФИТ-ФЛОКС, как можно понять, делался под программирование БЦВМ как раз на ассемблере (если не полностью заказной процессор - то, наверно, на МПК К588 с "прошитой" спецсистемой команд или с "заводской" семейства Э-60... на ЛА, помнится, были популярны). А там, в сущности, всё можно свести к распределению памяти данных, отвлекаясь от абстрактных типов... отсюда и деклар-язык ФЛОКС - табличный в основе.
Другое дело - что неоправданно было "генерализовать" такой взгляд в виде классификации "всего, что содержится в программе", как в /Паронджанов, 2001, п. Классификация знаний/. Получается такая неявная детерминация языка и всей методологии формализации свойствами исполнителя, работающего только с машинными величинами. Но это легко корректируется - с одной стороны, вводим в классификацию вариантность графит-ОС-узлами И/ИЛИ, ИЛИ (в частности, для форм представления), с другой - определяем целостный родо-видовой состав данных, представляющих отчуждаемое знание. И получается классификация, представленная в этом примере.

А схема, принятая для ГРАФИТ-ФЛОКС, оказывается частным случаем. Кстати, этот случай тоже можно "графитизировать" экономно - введя в систему ЯПЗ актив-язык описания механизма-решателя задачи, как АС в этом примере или в п. Разработка решения этого (тут уже с ОС-элементами для отражения конфигураций под варианты применения) и сопоставив каждому элементу "машинного" АС-блока параметры размещения в ОП (атрибуты, редактируемые сочинителем и применяемые при генерации исхтекста; также см. п. Некоторые итоги того же примера).
    Тем самым деклар-язык как бы не употребляется - на самом деле имеем смешанный актив-деклар-язык.
alexus писал(а):
...
Вторая абстракция - это абстракция действия. Полиморфизм - частный случай данной абстракции.
Не относится ли сюда также "шаблонирование" действия (а равно и решения, т.е. вопроса развилки) по принципу, описанному здесь - вхождения объектов становятся полями, "означиваемыми" по месту употребления шаблона?


Последний раз редактировалось Владислав Жаринов Пятница, 22 Июль, 2011 12:00, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Сложно ли написать свою СУБД?
СообщениеДобавлено: Вторник, 12 Июль, 2011 16:55 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Драконограф писал(а):
alexus писал(а):
... При разработке систем есть два вида абстракций, каждая из которых важна для успешной реализации. Первая абстракция - это абстракция данных. Это совсем не ассемблер... Описание данных удачно реализовано в DDL (data definition language) SQL, IDEF, ER-диаграммах и т.п. Это все представители декларативных (частью визуальных) "языков". Когда я знакомился с Драконом, то меня несколько озадачило небрежное отношение автора к декларативным языкам. На декларативные языки ложится значительная семантическая нагрузка при создании системы.
М.б. здесь надо говорить не о небрежности, а об авторской точке зрения, проистекающей из специфики разработок.
Пусть будет "авторская точка зрения"... Хотя понятнее (от смены названия) такой... хм?.. взгляд не становится (речь идёт о моем восприятии, которое может не совпадать с другими). Если вдумчиво посмотреть на работу инженера-конструктора, схемотехника, технолога и пр. и пр., то схемы, с которыми они работают и есть частные случаи декларативных и визуальных описаний (ДиВО :) ), хотя есть, конечно, и текстовые декларации (спецификации/регламенты/правила).
Говоря более обобщенно, при проектировании систем декларативные языки удобны и, следовательно, необходимы. Если, к примеру, убрать декларативные языки из проектирования баз данных (ER-диаграммы, SQL и т.п.), то мне легче застрелиться... ибо начнутся "хождения по мукам"...
Драконограф писал(а):
Ведь ГРАФИТ-ФЛОКС, как можно понять, делался под программирование БЦВМ как раз на ассемблере (если не полностью заказной процессор - то, наверно, на МПК К588 с "прошитой" спецсистемой команд или с "заводской" семейства Э-60... на ЛА, помнится, были популярны). А там, в сущности, всё можно свести к распределению памяти данных, отвлекаясь от абстрактных типов...
Ну... не скажите... (про ассемблер отдельный разговор...).
Драконограф писал(а):
Другое дело - что неоправданно было "генерализовать" такой взгляд в виде классификации "всего, что содержится в программе", как в /Паронджанов, 2001, п. Классификация знаний/. Получается такая неявная детерминация языка и всей методологии формализации свойствами исполнителя, работающего только с машинными величинами. Но это легко корректируется...
Ох... не легко... и, как правило, с неизбежной потерей простоты и наглядности (собственно, ради чего и создавалось).
Драконограф писал(а):
alexus писал(а):
... Вторая абстракция - это абстракция действия. Полиморфизм - частный случай данной абстракции.
Не относится ли сюда также "шаблонирование" действия (а равно и решения, т.е. вопроса развилки) по принципу, описанному здесь - вхождения объектов становятся полями, "означиваемыми" по месту употребления шаблона?
Мне не удалось обнаружить связи между текстом по ссылке и полиморфизмом, использованием шаблонов... Наверное, я что-то упускаю.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Сложно ли написать свою СУБД?
СообщениеДобавлено: Вторник, 12 Июль, 2011 18:50 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
alexus писал(а):
... Пусть будет "авторская точка зрения"... Хотя понятнее (от смены названия) такой... хм?.. взгляд не становится (речь идёт о моем восприятии, которое может не совпадать с другими).
...
Говоря более обобщенно, при проектировании систем декларативные языки удобны и, следовательно, необходимы. Если, к примеру, убрать декларативные языки из проектирования баз данных (ER-диаграммы, SQL и т.п.), то мне легче застрелиться... ибо начнутся "хождения по мукам"...
Разумеется - просто это языки "внешней" схемы задачи, её спецификации. Потом это надо перевести на прогязык в конкретной архитектуре приложений.
alexus писал(а):
Драконограф писал(а):
Ведь ГРАФИТ-ФЛОКС, как можно понять, делался под программирование БЦВМ как раз на ассемблере (если не полностью заказной процессор - то, наверно, на МПК К588 с "прошитой" спецсистемой команд или с "заводской" семейства Э-60... на ЛА, помнится, были популярны). А там, в сущности, всё можно свести к распределению памяти данных, отвлекаясь от абстрактных типов...
Ну... не скажите... (про ассемблер отдельный разговор...).
Так я как раз про него :)
alexus писал(а):
Драконограф писал(а):
Другое дело - что неоправданно было "генерализовать" такой взгляд в виде классификации "всего, что содержится в программе", как в /Паронджанов, 2001, п. Классификация знаний/. Получается такая неявная детерминация языка и всей методологии формализации свойствами исполнителя, работающего только с машинными величинами. Но это легко корректируется...
Ох... не легко... и, как правило, с неизбежной потерей простоты и наглядности (собственно, ради чего и создавалось).
Ну так ведь с целью преодоления "небрежности"... :wink:
alexus писал(а):
Драконограф писал(а):
alexus писал(а):
... Вторая абстракция - это абстракция действия. Полиморфизм - частный случай данной абстракции.
Не относится ли сюда также "шаблонирование" действия (а равно и решения, т.е. вопроса развилки) по принципу, описанному здесь - вхождения объектов становятся полями, "означиваемыми" по месту употребления шаблона?
Мне не удалось обнаружить связи между текстом по ссылке и полиморфизмом, использованием шаблонов... Наверное, я что-то упускаю.
Не, я не отождествлял шаблон с полиморфизмом, а хотел сказать, что это тоже можно считать частным случаем абстракции действия :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Сложно ли написать свою СУБД?
СообщениеДобавлено: Вторник, 12 Июль, 2011 20:16 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Драконограф писал(а):
alexus писал(а):
... Пусть будет "авторская точка зрения"... Хотя понятнее (от смены названия) такой... хм?.. взгляд не становится (речь идёт о моем восприятии, которое может не совпадать с другими).
...
Говоря более обобщенно, при проектировании систем декларативные языки удобны и, следовательно, необходимы. Если, к примеру, убрать декларативные языки из проектирования баз данных (ER-диаграммы, SQL и т.п.), то мне легче застрелиться... ибо начнутся "хождения по мукам"...
Разумеется - просто это языки "внешней" схемы задачи, её спецификации. Потом это надо перевести на прогязык в конкретной архитектуре приложений.
Зачем?.. Декларативные языки, о которых шла речь, являются конечными (для разработчиков) целевыми языками. Для примера cad приводит к получению чертежей, выполнению необходимых расчетов, получения технологических регламентов и т.д. Точно также, pcad позволяет получить необходимые для производства параметры печатных плат, программы сверления для станков с ЧПУ, фотошаблоны и пр. ER-диаграммы (IDEF) преобразуются в SQL, а SQL в структуры баз данных. Никакой конвертации в "прогязык" разработчики (конструктора, схемотехники, базовики) не выполняют.
Драконограф писал(а):
alexus писал(а):
Ну... не скажите... (про ассемблер отдельный разговор...).
Так я как раз про него :)
Макроассемблеры - двуязычные средства, которые позволяют формировать очень высокие и эффективные абстрактные уровни. Сводить их к распределению памяти значит использовать заложенный потенциал на 0,001%... Нерационально.
Драконограф писал(а):
Не, я не отождествлял шаблон с полиморфизмом, а хотел сказать, что это тоже можно считать частным случаем абстракции действия :)
Да, наверное. Я часто использую понятие "схема". Например, схема взаимодействия элементом системы при определенном возмущении. Схема объединяет понятие шаблона, обработчика события, включая понятие метода обработки, конструктивного элемента и др. Тоже частный случай абстракции действия.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Сложно ли написать свою СУБД?
СообщениеДобавлено: Четверг, 14 Июль, 2011 14:11 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
alexus писал(а):
Зачем?.. Декларативные языки, о которых шла речь, являются конечными (для разработчиков) целевыми языками. Для примера cad приводит к получению чертежей, выполнению необходимых расчетов, получения технологических регламентов и т.д. Точно также, pcad позволяет получить необходимые для производства параметры печатных плат, программы сверления для станков с ЧПУ, фотошаблоны и пр. ER-диаграммы (IDEF) преобразуются в SQL, а SQL в структуры баз данных. Никакой конвертации в "прогязык" разработчики (конструктора, схемотехники, базовики) не выполняют.
Для информатической стадии моделирования/формализации эти разработчики суть "предметники". Для всего, к чему они приводят, д.б. сгенерированы машинные программы/инструкции для людей. То, что это заранее заложено в САПР - сути не меняет - просто так было возможно сделать при текущем уровне понимания "предметки" + развития ИТ. Три схемы так же рулят - только перевод "внешняя-внутренняя" спрятан внутри САПР-приложений (хотя человеку всё равно в ряде случаев предварительно надо задать параметры генерации... в ряде случаев надо иногда пополнять базу правил перевода и их объектов).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Сложно ли написать свою СУБД?
СообщениеДобавлено: Четверг, 14 Июль, 2011 20:25 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Драконограф писал(а):
alexus писал(а):
Зачем?.. Декларативные языки, о которых шла речь, являются конечными (для разработчиков) целевыми языками...
Для информатической стадии моделирования/формализации эти разработчики суть "предметники".
Не более, чем программисты по отношению к Oberon или ДРАКОНу... В чем же разница?..


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Сложно ли написать свою СУБД?
СообщениеДобавлено: Пятница, 15 Июль, 2011 06:51 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
alexus писал(а):
Драконограф писал(а):
alexus писал(а):
Зачем?.. Декларативные языки, о которых шла речь, являются конечными (для разработчиков) целевыми языками...
Для информатической стадии моделирования/формализации эти разработчики суть "предметники".
Не более, чем программисты по отношению к Oberon или ДРАКОНу... В чем же разница?..
Как раз в том, что "предметник" в триаде моделирования/формализации может не заниматься информоделированием решения (в пределе по Фридланду - построением командной модели), доводя его только до качественной/математической стадии. И соответственно ограничиться "внешней схемой" решения.
Ессно, это имеет место и для ИТ - я вот, например, по отношению к РДП занимаю позицию "предметника" и потому остаюсь почти целиком на качественной стадии - отсюда и характер формулировки, скажем, языковых требований.
Дело аналитика - математически рассмотреть и уточнить эти требования, сформировать (максимально пользуясь уже имеющимися определениями) архитектуру приложений, их воплощающих (если, следуя, скажем, Бассу/Клементсу/Кацману, понимать архитектуру как максимально возможную абстракцию как от особенностей исполнителя, так и от требований конкретной задачи) - а описание архитектуры станет завершающим компонентом "внешней" схемы.
Дело программиста (ИТ-разработчика) - закодировать эту архитектуру на конкретном прогязыке в конкретной среде, используя конкретные библиотеки (сторонние и/или свои). Спецификация прогтекста и инструкции операторам приложения (с комментариями по реализации архитектуры) - это "нейтральная" схема решения. Результат трансляции (код+ресурсы) - "внутренняя" схема.
Вот в этом и разница между предметным и ИТ-разработчиками - они действуют на разных стадиях процесса. Конечно, введённая здесь изолированность ролей в триаде условна - также и применяемая конкретной триадой архитектура (свод архитектур) может видоизменяться с опытом решения задач.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Проект СУБД от alexus
СообщениеДобавлено: Пятница, 15 Июль, 2011 10:32 

Зарегистрирован: Пятница, 16 Октябрь, 2009 20:04
Сообщения: 68
Тему заболтал Драконограф. Многословие и языкоковерканье апологетов языка ДРАКОН напрягает и отвращает от ДРАКОНа. Это не продвижение продукта, а антиреклама, особенно в темах, не относящихся к ДРАКОНу.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Проект СУБД от alexus
СообщениеДобавлено: Пятница, 22 Июль, 2011 11:56 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Доровских Александр писал(а):
Тему заболтал Драконограф. Многословие и языкоковерканье апологетов языка ДРАКОН напрягает и отвращает от ДРАКОНа. Это не продвижение продукта, а антиреклама, особенно в темах, не относящихся к ДРАКОНу.
Интересно, что про ДРАКОН я не сказал ни слова :wink: и не могу сказать, что alexus не к месту вспомнил про него :) Видимо, "победные реляции" ((с) И.Е. Ермаков) реальных "апологетов" или "адептов" о том, что техноязык можно использовать буквально любым образом (да ещё и не отступая от "классического" определения), действительно уже достали так, что иной раз чисто автоматически увязываются у тех или иных собеседников с иными подходами и/или предметами обсуждения... В результате, как мы видим, по существу предмета, обсуждаемого мной с alexus, не было сказано ничего...

Напомню - в своём посте обсуждал с alexus отнюдь не ДРАКОН и даже не визуализацию, а суть процесса формализации знаний и отношение к нему участников, выступающих в разных ролях. Разумеется, всё сказанное никак не зависит от того, употребляется ли в этом процессе техноязык (и вообще какая-то визуализация) - точно так же оно приложимо к чисто текстовой записи результатов формализации.
О том же и на страницах, упомянутых в тексте поста. Если Е.С. Вентцель (И.Грекова) или А.Я. Фридланд, результаты которых использованы, относятся к апологетам ДРАКОНа (хотя и никак с ним не связаны) - тут уж я ничего поделать не могу... :D

Хотя я не "продвигаю ДРАКОН" - и потому не нуждаюсь в каких-то "спецпропагандистских" приёмах изложения своей точки зрения - но в замечании Александра вижу рациональное зерно и для себя. Уже появлялась мысль, что обсуждение формализации знаний в целом, шампур-метода (как формальной основы одного из путей визуальной формализации) и техноязыка (как средства формализации импер-знаний, построенного на базе шампур-метода) объединять, да ещё и под названием, относящимся только к техноязыку, не очень логично. Как-нибудь подумаю над этим...


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 29 ]  На страницу Пред.  1, 2

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2018, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB