DRAKON.SU
https://forum.drakon.su/

Попытка обобщения результатов форума
https://forum.drakon.su/viewtopic.php?f=62&t=3025		 Страница 1 из 2
Автор:  Владимир Паронджанов [ Воскресенье, 28 Ноябрь, 2010 11:59 ]
Заголовок сообщения:  Попытка обобщения результатов форума
В этом сообщении (во второй "цитате")
информация постоянно обновляется.

Уважаемые коллеги!

Мне кажется, имеет смысл выделить наиболее важные результаты,
полученные на форуме "Визуальное программирование",
включая все его темы.
То есть сделать некое обобщение результатов.

На форуме свыше сотни тем. В них заключено богатое содержание.
Выделить наиболее важные результаты было бы очень полезно.
Но это очень сложная задача.

Признаюсь честно, что мне такая задача не по зубам
(просто потому, что у меня не хватает знаний).

Поэтому я обращаюсь за помощью к сообществу.

Непосредственным поводом для этого сообщения
стало сообщение Владислава Жаринова (Драконограф),
сделанное 12 октября 2010 года.

Уважаемый Владислав предложил следующее обобщение:
Цитата:
Итог этому этапу подвели доработанная по минимальным эргономическим требованиям Ты-среда, ДРОН и работы С. Тарасенко по "ресторации" Ты-среды и особенно - дракон-конверсии; в теоретическом плане - также работа Рэйлвей Каген по представлению шампур-схем S-выражениями (ПРОТОН). Показано, что можно создать дракон-среду как общедоступное и развиваемое приложение - это, считаю, уже много. Предварительно решена задача трансляции в исходный текст - но разными разработчиками со своими ограничениями. Кроме того, все основные результаты развития касались интерфейса - но не языков визуализации и не их машинного представления.

Со своей стороны Дмитрий_ВБ по ходу развития этой темы предложил идеи, которые позволят перейти к следующему этапу; речь идёт о текстовом представлении схем, которое я назвал ТФРД, позволяющем и хранить необходимые данные для отрисовки содержимого документа, и генерировать не шаблоны исходного текста для последующей доработки, а исходный прогтекст на конкретном ТЯП. Предлагается также "человекочитаемость" самого текстового представления (т.е. файла проектного документа).

viewtopic.php?p=52382#p52382

Опираясь на мнение Владислава, я позволил себе отредактировать
его текст и представить его в следующем виде

В этой "цитате"
информация постоянно обновляется.

Цитата:
НАИБОЛЕЕ ВАЖНЫЕ РЕЗУЛЬТАТЫ,
ПОЛУЧЕННЫЕ НА ФОРУМЕ "ВИЗУАЛЬНОЕ ПРОГРАММИРОВАНИЕ"

:idea: 1. Геннадий Тышов создал "среду Тышова" ( DRAKON - интегрированную среду языка Дракон).
viewtopic.php?p=22669#p22669

:idea: 2. Ярослав Романченко создал транслятор для языка Дракон-Оберон (ДРОН)
из среды Тышова в Active Oberon
(в настоящее время работа не развивается).
http://sage.com.ua/ru.shtml?e6l0
viewtopic.php?f=79&t=1080

:idea: 3. Станислав Тарасенко:
          -- разработал метод дракон-конверсии среды Тышова в любой язык
          программирования (в общем виде);
          -- применил этот метод для конверсии среды Тышова в язык Бейсик (Visual Basic),
          то есть создал транслятор Дракон-Бейсик (Бекон);
          -- предложил метод ресторации (с помощью программы Restorator) среды Тышова.
Метод дракон-конверсии: viewtopic.php?f=79&t=2768
viewtopic.php?f=79&t=2633
Метод ресторации: viewtopic.php?f=79&t=2604

:idea: 4. Рэйлвей Каген предложил:
        -- теоретический метод по представлению шампур-схем с помощью ПРОцедурно-ТОпологической Нотации (ПРОТОН);
        viewtopic.php?f=62&t=1716
        -- обработку приложений на основе ПРОТОНа;
        -- расширение языка ДРАКОН для параллельных процессов и обработки ситуаций.

:idea: 5. Петр Приклонский создал транслятор из среды Тышова в язык Си, который используется на практике. (Создаются рабочие файлы Си-программ, пригодные для компиляции без редактирования. Приложения созданы на C#. Для их работы необходимо наличие на ПК FrameWork 3.5).
viewtopic.php?f=79&t=2718

:idea: 6. Дмитрий_ВБ предложил идеи, которые позволят использовать текстовое представление схем, чтобы:
а) хранить данные для отрисовки содержимого документа,
б) генерировать не шаблоны исходного текста для последующей доработки, а исходный текст на конкретном текстовом языке программирования.

:idea: 7. Илья Ермаков и Никита Жигуненко разработали теорию двумерного структурного программирования, опираясь на аппарат теории графов.
viewtopic.php?f=62&t=2921

:idea: 8. Владислав Жаринов развивает целостное представление качественного порядка о методологии формализации знаний с позиций "предметника" и разрабатывает направление дальнейшего развития.
viewtopic.php?f=62&t=2046

:idea: 9. Сергей Бытко предложил использовать дракон-схемы для гуманитарных целей --
для преподавания уголовного права.
viewtopic.php?f=78&t=1715

:idea: 10. NotGonnaGetUs предложил представление шампур-схем лисповскими S-выражениями (sexp).
viewtopic.php?p=26619#p26619
См. также viewtopic.php?p=30956#p30956


Уважаемые коллеги!

Я полностью отдаю себе отчет, что я не имею права выступать
с такими обобщениями, так как мои знания, увы, недостаточны.

Поэтому предложенная мною редакция является неполной.
Хуже того, она содержит ошибки, промахи, неточности и другие погрешности.
Например, вклад Ильи Ермакова отражен далеко не полностью; точнее,
почти совсем не отражен.

Поэтому я обращаюсь к Вам с почтительной просьбой.
Изложите свое мнение по затронутому вопросу и исправьте допущенные
мною ошибки и недочеты.

Мне кажется, данная тема настолько важна. что здесь следует полностью
устранить все изъяны и некорректные формулировки.
Автор:  Владислав Жаринов [ Воскресенье, 28 Ноябрь, 2010 19:00 ]
Заголовок сообщения:  Re: Попытка обобщения результатов форума
Владимир Паронджанов писал(а):
Уважаемые коллеги!

Опираясь на мнение Владислава, я позволил себе отредактировать
его текст и представить его в следующем виде

Цитата:
НАИБОЛЕЕ ВАЖНЫЕ РЕЗУЛЬТАТЫ,
ПОЛУЧЕННЫЕ НА ФОРУМЕ "ВИЗУАЛЬНОЕ ПРОГРАММИРОВАНИЕ"

:idea: Владислав Жаринов развивает обобщение полученных результатов и разрабатывает направление дальнейшего развития.

...обращаюсь к Вам с почтительной просьбой.
Изложите свое мнение по затронутому вопросу и исправьте допущенные
мною ошибки и недочеты.

Мне кажется, данная тема настолько важна. что здесь следует полностью
устранить все изъяны и некорректные формулировки.

Относительно себя уточню, что я, конечно, не обобщаю полученные другими результаты в полном смысле этого утверждения (достаточно представить, какие знания и умения нужны, чтобы обобщить и развить хотя бы совместно ПРОТОН и представление Ермакова-Жигуненко :)). Просто, следуя "новому системному подходу", вырабатываю целостное представление качественного порядка о методологии формализации знаний с позиций "предметника", который потенциально готов взаимодействовать с "информатизатором" своих задач на общей платформе языка-технологий-реализации, сокращающей усилия ума сторон (после надлежащего освоения, конечно). Насчёт направления - это верно, даю свои предложения.
Автор:  Владимир Паронджанов [ Воскресенье, 28 Ноябрь, 2010 19:15 ]
Заголовок сообщения:  Re: Попытка обобщения результатов форума
Уважаемый Владислав!

Я правильно поправил? Если нет, дайте Вашу формулировку.
Автор:  Рэйлвэй Каген [ Воскресенье, 28 Ноябрь, 2010 21:24 ]
Заголовок сообщения:  Re: Попытка обобщения результатов форума
Представление шампур-схем S-выражениями предложил NotGonnaGetUs.
В том, что касается поддерживаемых мной направлений - это ПРОТОН и обработка приложений на её основе, а также расширения ДРАКОНа для параллельных процессов и обработки ситуаций.
Автор:  Владимир Паронджанов [ Среда, 01 Декабрь, 2010 14:27 ]
Заголовок сообщения:  Re: Попытка обобщения результатов форума
Цитата:
Станислав Тарасенко предложил метод ресторации среды Тышова и дракон-конверсии среды Тышова.


Помогите, пожалуйста, указать точную ссылку (ссылки) на указанные предложения Станилава Тарасенко.
И еще вопрос. Ресторация -- ведь это жаргон? Какой строгий термин должен стоять вместо ресторации? Или я не прав?
Автор:  Александр Ильин [ Среда, 01 Декабрь, 2010 14:36 ]
Заголовок сообщения:  Re: Попытка обобщения результатов форума
Владимир Паронджанов писал(а):
Ресторация -- ведь это жаргон? Какой строгий термин должен стоять вместо ресторации?
Правка программы путём редактирования встроенных ресурсов (текстовых описаний окон, меню, картинок и т.п.), без изменения исполняемого кода.
Ресторация - это даже не жаргон, а просто глагол от названия программы Restorator. Название происходит от английского restoration: ремонт, реконструкция, реставрация.
http://lingvo.yandex.ru/restoration/с%20английского/
Автор:  Владимир Паронджанов [ Среда, 01 Декабрь, 2010 16:50 ]
Заголовок сообщения:  Re: Попытка обобщения результатов форума
Уважаемый Александр Сергеевич!

Спасибо.
С учетом Вашей подсказки я поправил текст так:
Цитата:
Станислав Тарасенко предложил метод ресторации (с помощью программы Restorator) среды Тышова и дракон-конверсии среды Тышова.

Если есть замечания, я готов внести исправления.
Автор:  Владимир Паронджанов [ Пятница, 03 Декабрь, 2010 12:21 ]
Заголовок сообщения:  Re: Попытка обобщения результатов форума
Уважаемые коллеги!

Помогите указать точные ссылки для этих утверждений:
Цитата:
6. Дмитрий_ВБ предложил идеи, которые позволят использовать текстовое представление схем, чтобы:
а) хранить данные для отрисовки содержимого документа,
б) генерировать не шаблоны исходного текста для последующей доработки, а исходный текст на конкретном текстовом языке программирования.
Автор:  С. Тарасенко [ Суббота, 04 Декабрь, 2010 15:50 ]
Заголовок сообщения:  Re: Попытка обобщения результатов форума
Очень хорошо, что создана эта тема. В каждом деле бывает такой перелом, когда люди зарываются в бездне информации и необходимо выделить главное. Вот это и свершилось!

Теперь позволю себе некоторую вольность:

Цитата:
. Предварительно решена задача трансляции в исходный текст - но разными разработчиками со своими ограничениями.


Не хочу показаться наглецом, но выскажусь просто для очистки своего тщестлавия. Можете всерьёз не приниамть.

Моя трансляция по своей ИДЕЕ ограничений не имеет. Можно запросто составлять шаблоны перевода для любого текстового языка.

Другое дело, что программа не опробирована на большом количестве схем, и могут быть сбои. Но исходный код открыт, к тому же язык Visual Basic (профессионалы все его знают), и по-моему этот код достоин изучения (там много неожиданных находок). К тому же, если будут сообщения об ошибках, я всегда готов поправить - мне-то легче.

Я бы и так доработал, но сейчас я вовсю занимаюсь музыкой и не программирую. А главное, зачем, если мой проект как-то повис в воздухе. Видимо, надо часто выступать и всё время впустую обновлять версии, чтобы было внимание, - но у меня нет на это времени. Пусть прилижет кто-то другой. Всё равно мне было бы приятно увидеть в соавторстве свою фамилию. А то жалко, если пропадёт столько труда.

Поэтому ещё раз благодарю Драконографа и Владимира Данииловича за то, что здесь выложены и мои ссылки. Это всегда приятно, потому что я не профессионал и к такому не привык.
Автор:  Владимир Паронджанов [ Суббота, 04 Декабрь, 2010 16:07 ]
Заголовок сообщения:  Re: Попытка обобщения результатов форума
С. Тарасенко писал(а):
....................................................................................
Моя трансляция по своей ИДЕЕ ограничений не имеет. Можно запросто составлять шаблоны перевода для любого текстового языка.
...............................................................
Я бы и так доработал, но сейчас я вовсю занимаюсь музыкой и не программирую. А главное, зачем, если мой проект как-то повис в воздухе. Видимо, надо часто выступать и всё время впустую обновлять версии, чтобы было внимание, - но у меня нет на это времени. Пусть прилижет кто-то другой. Всё равно мне было бы приятно увидеть в соавторстве свою фамилию. А то жалко, если пропадёт столько труда.

Стас!

Я не понял, почему ПОВИС В ВОЗДУХЕ? И почему ВПУСТУЮ?
Если можно, поясни пожалуйста.
Автор:  С. Тарасенко [ Суббота, 04 Декабрь, 2010 16:44 ]
Заголовок сообщения:  Re: Попытка обобщения результатов форума
Повис в воздухе - потому что у программы перевода нет пользователей, а значит нет вопросов, предложений, поправок.

Впустую - потому что не будет пользователей. Обновлять не для кого, значит - впустую.

Но это не плохо. Если бы были пользователи, вопросы и предложения, я постоянно обновлял бы версию и меньше бы занимался музыкой. Другое дело - меня удивляет, почему на таком огромном форуме никто не схватился за мою идею перевода схем на любой язык, а не какой-то выбранный. Вот я и попытался предположить, что из-за того, что я мало выступаю на форуме. Или я не прав?

Хотя что-то мы отклонились от темы...

______________
(Добавлено)

Вот написал я это, а потом посмотрел, что у переводчика было 20 000 скачиваний. Ничего себе! Придётся доработать! Что-то молчат все...

Скоро выложу версию для нового редактора.
Автор:  Владислав Жаринов [ Среда, 08 Декабрь, 2010 08:47 ]
Заголовок сообщения:  Re: Попытка обобщения результатов форума
С. Тарасенко писал(а):
Другое дело - меня удивляет, почему на таком огромном форуме никто не схватился за мою идею перевода схем на любой язык, а не какой-то выбранный. Вот я и попытался предположить, что из-за того, что я мало выступаю на форуме. Или я не прав?
Возможно, потому, что Вы решаете задачу, не конечную в "технологической цепочке" обеспечения визуализации. Ей предшествуют по крайней мере следующие:
    * определить подходящее решение визуализации как целостный комплекс графит-языков (фрагментарно уже много чего сделано);
    * определить язык текстовой записи указанного комплекса.
Первым начал заниматься Ярослав; определяя форму записи ДРАКОН-АО для ДРОНа, он высказал идеи для деклар-графит-языка, но остановился на развитии одной из идей Владимира Даниеловича (помещать деклар-текст в комментарии к дракон-схеме); см. прежде всего в этом сообщении. Теперь этим занимаюсь я :) но уже для всех составляющих смысла, заложенных в программный текст. Результаты можно найти на страницах этого раздела, а их приложение в этом примере; естественно, они привязаны к конкретному языку, но м.б. перенесены на другие (правда, если язык на другой концепции программирования, чем Оберон - возможно, потребуется пересмотреть и что-то в подходах к "графитизации" - прежде всего для процессных конструктивов).

Второй задачей занимаются Рэйлвей Каген и Дмитрий_ВБ. Каждый из них использует свою версию языка импер-шампур-схем; представление других компонентов частного знания о задаче не обсуждается и собственно зависит уже не от природы знания, а от свойств выбранного графит-языка (в графовой части - от учёта всех возможных топологий; в текстовой - от выбора способа записи текста как составной части описания вершины/дуги графа; понятно, то и другое не определить без решения первой задачи).
Относительно пересадки лиан замечу, что согласен со сторонниками доказательного программирования, о чём говорил в этой теме; в развитие этого дан этот пример.
В целом по языковому базису и его реализации высказывался в этом сообщении и в этом сообщении. Основное ограничение в его частной компоненте - надо расширить на системы процессов РВ содержательно и корректно - но здесь пока ещё согласованный подход к визуализации не определился (см., напр.: viewtopic.php?p=44099#p44099).

Ограничение Вашего решения по дракон-конверсии (не подхода) в том, что привязано к конкретному редактору, для которого первая задача не решена, т.к. отсутствуют по крайней мере следующие принципиальные вещи:В силу этого исходное решение хорошо подходит для команд разработчиков, которые тоже люди и приветствуют снижение нагрузки на свой профессиональный интеллект даже за счёт такой визуализации (а оставшуюся и привнесённую решением "избыточную сложность" могут преодолеть "профессиональными приёмами" мышления и действия - не всегда гарантоспособными, конечно - об этом см. И. Ермакова и Info21). Для общения с "предметниками" и вообще непрофессионалами в ИТ (что необходимо при расширении сферы применения) эта сложность уже в принципе работает против качества формализации знаний.

Относительно решения - важно не чтобы "схватились", а чтобы использовали для главной цели, поставленной создателем техноязыка - улучшения работы ума как следствия и удобной записи знаний, и удобного средства ведения этой записи. Будут хорошо решены предыдущие задачи - возникнет потребность и в хорошем решении третьей... и тут вместе с другими подходами будет востребован и Ваш... Возможно, и он потребует развития - я сказать не могу, ибо не разбирался. Это больше к специалистам по программированию, своей же задачей считаю дать определение того, что нужно запрограммировать :) Несистемно уже подходили к визуализации - пора работать системно, от начала "техцепочки". Далее реализацию согласованного базиса на уровне алгоритмов и структур данных для конкретной платформы пусть формулируют программисты... только если они работают открыто - представляя свои решения когнитивно-эргономичными спецификациями для аудитории. И здесь снова относительно языка реализации - всё-ж таки должен он совпадать с визуализируемым прогязыком... а не быть из "экстремистски-объектных", на которых, как я смотрю, хорошо окна сообщений об ошибках генерировать да другие "особенности реализации" ;) к исправлению которых во многом и сводится развитие приложения, отвлекая от главного...
    И ещё важно - чтобы, с одной стороны, конверсия шла точно в прогтекст - ну, этого Вы в конкретном случае добились, как я понимаю, и имеете представление, как сделать для другого ТЯП. А с другой - обязательно, чтобы прогтекст из внешнего источника (напр. файла, выгруженного из ТЯП-прогсистемы или из инжсистемы типа Spin) точно реконвертировался в открытый (выбранный оператором) РДП-проект (обновляя содержание по совпадению имён сущностей и дополняя в остальной части).
    На эту тему информация к размышлению:
    night-stels в http://www.progz.ru/post172273-15/ писал(а):
    Для прошивок телефона, которыми я занимаюсь исходников от 20К до 40К файлов (в зависимости от модели). В каждом от 100 до 25К строк. В среднем 5К строк. Всю эту кучу я легко читаю с помощью Source Insight 3.5. Софтина очень полезная на мой взгляд. Примерно пол часа она разгребает всю эту кучу файлов, устанавливает связи между файлами, функциями и прочим. А потом остается только спокойненько читать код. При этом для каждой функции, переменной при наведении выдается описание, все места где она вызывается или используется. Ну и куча других полезных фич имеется. Вообщем мне нравится.
    Вот так должен действовать и РДП-редактор со входным текстом на поддерживаемом ТЯП. Только представление кода будет графитным - что может несколько изменить подход к навигации по сущностям.


Насчёт того, что надо чаще выступать - с позиций теории передачи информации Вы, конечно, правы :) напомню старое правило "спецпропаганды", сформулированное давними специалистами в этом деле - англичанами: "повторяй то, что хочешь донести, везде и всегда - что-нибудь <в памяти читателей> да останется" (в оригинале речь идёт о лжи, с воспринимаемостью истин м.б. несколько сложнее ;))... классический пример из истории - "Кроме того, я требую, чтобы Карфаген был разрушен." :D

С. Тарасенко писал(а):
Вот написал я это, а потом посмотрел, что у переводчика было 20 000 скачиваний.
Число скачиваний, возможно, объясняется недоступностью вложения и/или обрывами... я тут тоже посмотрел, как быстро растёт число обращений к одному своему вложению (из О.Е. Акимова по математике)... потом как-то попробовал открыть... ба! не открывается... пришлось повторно вкладывать :) Проверьте на всякий случай...

Наверное, и на просьбу Владимира Даниеловича об уточнении ссылок со своей стороны заодно ответил :)
Автор:  Владимир Паронджанов [ Среда, 08 Декабрь, 2010 11:28 ]
Заголовок сообщения:  Re: Попытка обобщения результатов форума
Драконограф пишет:
Цитата:
Наверное, и на просьбу Владимира Даниеловича об уточнении ссылок со своей стороны заодно ответил

Уважаемый Владислав!

Если нетрудно, дайте эти ссылки в отдельном сообщении, а то я боюсь ошибиться.
Желательно в такой форме, чтобы я вставил их методом копирования без редактирования.
Автор:  Владислав Жаринов [ Среда, 08 Декабрь, 2010 13:56 ]
Заголовок сообщения:  Re: Попытка обобщения результатов форума
Владимир Паронджанов писал(а):
Драконограф пишет:
Цитата:
Наверное, и на просьбу Владимира Даниеловича об уточнении ссылок со своей стороны заодно ответил

Уважаемый Владислав!

Если нетрудно, дайте эти ссылки в отдельном сообщении, а то я боюсь ошибиться.
Желательно в такой форме, чтобы я вставил их методом копирования без редактирования.

Примерно в порядке появления в сообщении:
Предложение Я. Романченко (итоговое) по совмещению импер- и деклар-описаний программы (ДРАКОН-АО): viewtopic.php?p=17243#p17243.
Предложение по графит-методу комплексной визуализации: http://drakonografika.narod.ru/L2/metas ... .html#n53c (классификация визуализируемых знаний); http://drakonografika.narod.ru/L2/index ... pril2.html (определение языков); http://drakonografika.narod.ru/L3/compl ... w.html#Pr1 (пример использования).

Новые результаты по ПРОТОНу (Рэйлвей Каген): viewtopic.php?p=53757#p53757.
Новые результаты по ВЯЗБС (Дмитрий_ВБ): viewtopic.php?p=50762#p50762.

Оценки целей и методов визуализации: viewtopic.php?p=52445#p52445, viewtopic.php?p=52404#p52404, viewtopic.php?f=78&t=2919&start=0 и http://drakonografika.narod.ru/L3/part_ ... html#n3114 (как доказательно визуализировать алгоритмы); viewtopic.php?p=50779#p50779 (текстовая запись графит-моделей); viewtopic.php?p=53470#p53470 (объём и характер знаний по формализации).
И. Ермаков: viewtopic.php?p=48527#p48527; viewtopic.php?p=48436#p48436; viewtopic.php?p=50025#p50025.
Info21: viewtopic.php?p=47420#p47420; viewtopic.php?p=52672#p52672.
С. Оборотов: viewtopic.php?p=47670#p47670.
Рэйлвей Каген: viewtopic.php?p=54810#p54810; viewtopic.php?p=53274#p53274.
Дмитрий_ВБ: viewtopic.php?p=50799#p50799; viewtopic.php?p=51261#p51261.
vladfind: viewtopic.php?p=45784#p45784.

Оценки свойств языков и их реализации: viewtopic.php?p=51007#p51007 и viewtopic.php?p=52382#p52382; viewtopic.php?p=43298#p43298.
И. Ермаков: viewtopic.php?p=52460#p52460.
Рэйлвей Каген: viewtopic.php?p=52860#p52860; viewtopic.php?p=52411#p52411.
Г. Тышов: viewtopic.php?p=52854#p52854; viewtopic.php?p=47052#p47052; viewtopic.php?p=46015#p46015.
Э. Ильченко: viewtopic.php?p=40900#p40900; viewtopic.php?p=40351#p40351.
Р. Самойлов: viewtopic.php?p=51962#p51962.
П. Приклонский: viewtopic.php?p=49270#p49270; viewtopic.php?p=55399#p55399.
VOT7: viewtopic.php?p=55829#p55829; viewtopic.php?p=55834#p55834.

Предложения по визуальной SADT-подобной декомпозиции графит-моделей: http://drakonografika.narod.ru/L3/requi ... #Pril2n132 (предварительное обоснование); http://drakonografika.narod.ru/L3/compl ... html#n3221 (пример использования).
Автор:  Владислав Жаринов [ Четверг, 09 Декабрь, 2010 05:44 ]
Заголовок сообщения:  Re: Попытка обобщения результатов форума
Как-то ограничился только своими оценками, а есть и другие авторы. Дополнил в исходном сообщении. Быть может, упомянутые авторы найдут и иные свои сообщения, на их взгляд более подходящие (а неупомянутые - добавят), если будет интерес...
Также дополнил полнотекстовое сообщение кое-чем.
Автор:  Ярослав Романченко [ Четверг, 09 Декабрь, 2010 13:21 ]
Заголовок сообщения:  Re: Попытка обобщения результатов форума
Драконограф писал(а):
Предложение Я. Романченко (итоговое) по совмещению импер- и деклар-описаний программы (ДРАКОН-АО): viewtopic.php?p=17243#p17243
Говоря о табличном представлении декларативной части я подразумевал не только сами таблицы но и соответствующие пользовательские интерфейсы для ввода этих табличных данных. Пользовательский интерфейс можно реализовать по принципу мастеров в Visual Studio.
Автор:  Владислав Жаринов [ Вторник, 14 Декабрь, 2010 08:46 ]
Заголовок сообщения:  Re: Попытка обобщения результатов форума
Владимир Паронджанов в viewtopic.php?p=55498#p55498 писал(а):
Петр Приклонский писал(а):
[Продукт] не сильно кого то заинтересовал... что то ни кто не интересуется
Причина проста. На этом сайте (OberonCore.ru) собрались
сторонники Оберона. Для них Си как бы не существует.
Вполне естественно, что оберонщики не заинтересовались
работой по Си.
...
Ваши сообщения стоит повесить на тех сайтах, где люди проявляют интерес
к языку си.

Вот ещё и результаты Петра упустил... добавлено в обобщающие сообщения.
Предложение правильное, а вот исходную посылку я бы уточнил. По моему впечатлению, конкретный язык лишь внешнее (производное) основание для объединения на данной конференции. Глубинное - определённый взгляд на программирование как деятельность. Которому удовлетворяет не каждый язык. Это легко понять, перечитав хотя бы доклад И. Ермакова. Там ведь линия рассуждений такая: "Чтобы делать гарантоспособные (использую Ваш термин, полностью здесь приложимый) инфопрогизделия, нужно следовать таким-то и таким-то правилам при формализации задачи. Эти правила предъявляют такие-то требования к языку программной формализации. Этим требованиям удовлетворяет конкретный язык - Оберон.". А отнюдь не навыворот - "я люблю Оберон, поэтому он обладает в моих глазах некими достоинствами, ради которых я от него не откажусь, даже если выяснится, что его недостатки перевешивают." ;) Как следствие - если бы язык назывался иначе, имел бы не точно такое же определение - он бы был принят участниками данной конференции - и называлась бы она "<какое-нибудь-другое>core.ru"... ;) И если бы было много языков, удовлетворяющих критериям минимальной сложности и точности определения и использования - уж наверное бы все они были здесь приняты так или иначе (или я неправ?). Хотя есть сомнения, что можно определить много строго информатически формальных языков, минимальных и в то же время принципиально отличных друг от друга (не беря во внимание непринципиальные отличия вроде иного написания ключевых слов и/или разного распределения объема синтаксиса по отдельным правилам).
В основу же многих прогязыков положен принцип "программирование как художественное творчество". Хотя бы и в ущерб гарантоспособности решения (как следствие и ущерба гарантоспособности совокупного работника). Первым следствием этого служит неформальный синтаксис этих языков - что идёт вразрез с Вашей же (совершенно правильной) концепцией "гибридизации" как соединения текстового синтаксиса с визуальным. Вот Вирт пишет в "Потерянной дороге", что только для четвёртой версии С++ был определён текстовый синтаксис - а с чем тогда скрещивать? Свердлов при разборе языков и концепций (выдержка вложена в это сообщение) указывает, что у Явы синтаксис неформальный, у Си-диез тоже неоднозначный - что, гибридизация в этом случае даст формальный язык? Не даст...
Хороший пример этому - "педагогический эксперимент", результаты которого приведены в п. Непрофессиональная визуализация в конце этого примера. Сочинители использовали фактически определение техноязыка без текстового синтаксиса - и должны были восполнять его "формализацией по примерам" из Вашей книги. Примеры удачные в содержательном плане, отлично оформлены - но они не следуют общему правилу синтаксиса (и не должны - у Вас в данном случае другие цели). Как следствие - перевод с псевдокода не получился точным. Кстати, камнем преткновения стала не только текстовая часть - но и то, о чём говорил Илья ("алгоритмы - это ещё не всё") - не было понимания, как структурировать задачу. А оно формализуется за пределами чисто алгоритмического языка.
Между прочим, и к циклам ДЛЯ всё сводить нельзя - от них вообще лучше бы уходить (тот же пример показывает такую возможность).
Поэтому нужно рассматривать визуальный язык как "графитный".
И прогязык ведь не сводится только к структуре маршрутов - но и здесь, кстати, пока целостного выражения не достигнуто - нет визуализации прерываний и исключений (лично я придумал кое-что - но нужно окончательное профессионально проверенное решение).

Вот и об упомянутых форумах программистов... Почитал я дискуссию на Сахаре до конца - и там всплыл интересный момент. Один из участников утверждает (дословно), что "зачастую легче самому написать и отладить код, решающий конкретную задачу, чем разбираться в чьём-то, уже решающем её (или содержащем элементы, которые можно было бы позаимствовать)" - имя в виду, что и визуальный разбор этого кода особо не поможет. И это совершенно справедливо - для "художественного программирования". Тогда как тот же Илья утверждает, что не д.б. разницы в качестве и понятности между "когда-то кем-то написанным и написанным сегодня у нас" - а это уже при "убедительном программировании". И здесь-то визуализация кода поможет - потому что она визуализирует логически обоснованные свойства решения для человека, которму просто более удобно воспринимать их в "графитной" форме, а не в чисто текстовой.
Как следствие, обратите внимание - на той же Компьютерре техноязык не приемлют прежде всего сторонники "художественного творчества на формальные темы" - независимо от излюбленного ими языка (однако по генезису они, как правило, "объектно-экстремистские", говоря словами Свердлова).
В общем, ситуация-то чисто "трёхмушкетёрская" - помните, когда Д'Артаньяну кардинал предлагает сотрудничество, а тот отвечает "Я очень вас уважаю, но как-то так получилось, что все мои друзья принадлежат к сторонникам короля, а все недруги - к сторонникам вашего преосвященства. Поэтому, если бы я сменил сейчас сторону - я был бы дурно принят здесь и на меня плохо посмотрели бы там." К данному случаю это относится так - Вы продекларировали единство формальности и эргономичности как основу методологии ДРАКОН, однако это вступает в противоречие с неформальностью многих текстовых методологий. Конечно, гибридизировать техноязык можно и с таким ТАЯ/ТЯП - но как результат получится не техноязык "ДРАКОН-Х", а язык "Х-драконоподобный" (наверное, понятно, что элементы переставлены не случайно) ;) Он не обеспечит того самого повышения гарантоспособности, которое декларирует МФЗ-ДРАКОН. И в этом надо отдавать себе отчёт... Сторонники "преосвященности художественного программирования", видимо, отдают, хотя бы и неявно - и "дурно принимают" техноязык как средство упорядочения программирования... вплоть до откровенного хамства. А как средство неупорядоченного зачем он им - ведь "литературно" можно
и на ЮМЛе "шарашить"...
Что предполагает эта самая гарантоспособность? Однозначность толкования полученного описания как человеком, так и машиной. Иначе самая удобная для восприятия форма не поможет - потому что за ней будут скрываться неоднозначности содержания. Простоту определения языка - чтобы было удобно понимать именно сложные описания. Лаконизм конструкций, составляющих описание - но не в ущерб однозначности, конечно. Профессионалы, возможно, сформулируют полнее и точнее. А конечная цель - обеспечение предсказуемости поведения изделия, содержащего инфопрограммную компоненту. Без "нечеловеческих" усилий создателей изделия - что Вы определили как "интеллектуальный терроризм".
Так что и причина незаинтересованности здесь в drt-Си-конверторе может оказаться не так проста, как Вы предположили... и распространение его может не дать ожидаемого эффекта. Что не умаляет результатов Петра - как поддержка программирования неполностью гарантоспособного они могут оказаться весьма кстати. У него есть своя ниша - о которой писал тот же Громов (правда, с распространением "встроенки" для применений, влияющих на безопасность человека и природы, в процентном объёме эта ниша должна сокращаться - иначе будет, как в примерах, приводимых Карповым - т.е. фактически очень многим инновационным решениям доверять будет невозможно). Но ограничения, несовпадения с парадигмой "интеллектуального антитеррора" каждого текстового языка, используемого для "гибридизации", надо осознавать - следуя мудрости Д'Артаньяна... У чистого Си их скорее всего меньше, чем у "плюсов" и "диезов" - но это можно выявить только в обсуждении свойств языка (а отнюдь не практики его использования - поэтому распространение конкретной среды само по себе к этому отношения не имеет).
Автор:  Владислав Жаринов [ Воскресенье, 26 Декабрь, 2010 05:45 ]
Заголовок сообщения:  Re: Попытка обобщения результатов форума
Ярослав Романченко писал(а):
Говоря о табличном представлении декларативной части я подразумевал не только сами таблицы но и соответствующие пользовательские интерфейсы для ввода этих табличных данных. Пользовательский интерфейс можно реализовать по принципу мастеров в Visual Studio.
Да, я тоже подразумеваю, что вершина типа имеет таблицу атрибутов - предварительное определение состава и структуры таблиц здесь.
А что должны делать мастера?
Автор:  Владислав Жаринов [ Суббота, 27 Август, 2011 14:05 ]
Заголовок сообщения:  О поддержке формализации знаний как целостного процесса
Перемещено отсюда.
Геннадий Тышов в viewtopic.php?f=79&t=3091&start=20#p56042 писал(а):
Отсюда в и.с. меньшее внимание на программирование, на типизацию данных, верификацию - это все вещи тесно связанные с выбранной средой программирования и организацией программирования.

Да и ещё насчёт программирования и допрограммной формализации - концепция "трёх схем предметки", выдвинутая первоначально в датаматике (для проектирования СУБД; см. выдержку из стандарта IDEF1X в этом сообщении: viewtopic.php?p=45614#p45614), думаю, позволяет при её обобщении определить разницу. Как - показывал в этом сообщении: viewtopic.php?p=52940#p52940.
И под "внешней схемой" как раз и понимается совокупное описание задачи, полученное математизацией качественного - т.е. спецификация. Что это специф-описание должно включать - говорил в этом разделе: http://drakonografika.narod.ru/L3/main_ ... ml#Pril3n2 (там конкретную форму его представления называю "формуляром").

В отношении представления, получается, разница в том, что "внешнее" представляется в системе языков (при графовой или текстовой основе специф-документа; о необходимости обеих рассуждал здесь: viewtopic.php?p=53256#p53256), а "нейтральное" - на прогязыке/комплексе прогязыков (в концепцию нейтрального моделирования входят правила перевода на каждый и правила сочетания языков).

Относительно состава внешних языков рассуждал, в частности, Агафонов - см. другое вложение в этом сообщении: viewtopic.php?p=45614#p45614. Я для простоты ограничился (помимо ДРАКОНА-Родного, определяемого тут: http://drakonografika.narod.ru/L3/imper ... #Pril2n354) набором простейших схемных и табличных языков, приводимым здесь: http://drakonografika.narod.ru/files/inforjazyki.pdf.

Нужно иметь возможность сочетать текст, таблицы, встроенную (включая графит-схемы) и внешнюю графику в документе среды разработки и документирования процессов. Как - показывал на этом примере: http://drakonografika.narod.ru/L3/compl ... w.html#Pr1. Но ещё раз подчеркну - это одна из основных форм существования документа. Другой д.б. текстово-базированная - ибо прав Info21, периодически напоминая, что нельзя всё свести к картинкам. Конкретную реализацию при первичности графово-базированной вижу как символ-сборку в смысле, определённом здесь (в ОЯ-правиле СВ): http://drakonografika.narod.ru/L3/requi ... #Pril2n132. Т.е. сочинитель заботится о композиции текста, таблиц и графики в жёстких полях, а на более высоком уровне - о композиции уже этих полей в сборки так, чтобы они образовывали связный документ. Форма документа - примерно как в ББ (ссылки лист-силуэтов преобразуются в определённым образом оформленные гиперссылки в тексте; структуры управления лист-силуэта - в управляющие сущности "текста как интерфейса"). Графовая организация облегчает ему задачу именно такой структуризации; удобно и вести альтернативные представления "предметки" РДП-документом (они просто накапливаются как разные жёсткие поля, организованные по разным ЛС-строкам и целым лист-силуэтам). А выборка даёт привычный "книжный" текст - каждая свой.

Какова будет "нейтральная" концепция реализации работы с РДП-документом (РДП-редактора) - "модель-вьюшка-контроллер" кажется оптимальной, но думать надо... специалистам в "нейтрализации" (т.е. в программировании) в том числе. Но для этого нужны "неизбыточно сложные" язык и среда программирования...
Автор:  Владислав Жаринов [ Суббота, 27 Август, 2011 14:12 ]
Заголовок сообщения:  О технологии целостной гарантоспособной визуальной формализа
Перемещено отсюда.
Ещё раз уточним для начала. Гарантоспособность - значит, эргономичность не только в свойствах результата, но и в свойствах процесса его получения - то, что просто и предметно изложил VOT7 в этом сообщении. Это раз.
Два - не только эргономичность, но и "убедительность" решения - что сжато определил Илья здесь: viewtopic.php?p=53206#p53206. Чтобы можно было и построить решение расчётно-логически настолько, насколько возможно при текущем научном уровне, и применить все передовые методы и средства проверки. И показать, что сделано и как это получено, с необходимыми пояснениями (в учебных и научных целях).
А целостность служит всему этому основой - чтобы не разрывать ни описание (для связки диосцен в документах активно должны использоваться ссылки), ни процесс его получения неоправданными техпереходами (прежде всего кросс-операциями и сменами рабочей среды).

В отношении технологии формализации принцип применения изложенного в предыдущем сообщении кратко такой: предметник совместно с аналитиком сочиняют "внешнюю схему" по МФЗ-РОЗ (подробнее см. здесь), оформляя как реферат задачи, при этом ищут математическое решение элементов задачи, подлежащих машинной реализации, если надо - матанализируют задачу в целом (ну там, решаемость, оптимизация, требования к поведению для верификации - задачи и методы анализа зависят от "предметки "). Всё делается в РДП-редакторе.

Далее аналитик совместно с программистом переводят содержание реферата в "нейтральную схему" на прогязыке, оформляя как развитие реферата (называю его "паспорт") - и представляя в символической форме (для человека) графит-методом (как графит-руководство с пояснениями КогниСтиль в составе графит-инструкции пользователю решения и, если в реализации есть автоматизированная часть - графит-программы, а также требований для верификации по методу, допустим, проверки моделей, описанному здесь: download/file.php?id=1798).
    "Нейтральный" язык д.б. точной визуализацией пересечения/объединения прогязыков РВ, используемых как входные в средах инжпроработки и программирования - примером в импер-части служит ДО7Pr: http://drakonografika.narod.ru/L3/imper ... #Pril2n353 - ну и АТ-язык деклар-части должен поддерживать образование всех типов, как вариант - предварительное предложение здесь: http://drakonografika.narod.ru/L3/syste ... html#n2151.
Это всё тоже в РДП-редакторе - исходя из архитектурных правил перевода.
Графит-модель подвергается инженерной проработке - выгружается в среду типа Spin (в записи на её входном языке, получаемой автоматически из "нейтральной") и проверяется на соответствие требованиям и, если возможно, прогоняется на исполнение (в Spin возможно - там есть функция симуляции Promela-текстов). Контрпримеры и результаты прогона анализируются, ошибки графит-руководства устраняются, требования корректируются. Можно делать прямо в инжсреде на текстах, а затем загружать обратно в РДП-редактор (опять же автоматически!). Изменённый РДП-документ дополняется комментариями по обновлениям; аналитик по необходимости согласовывает их с предметником.
Все эти вещи определяются как графит-инж-МФЗ (взаимосвязанная с РОЗ или рассматриваемая как её часть).

Затем графит-программа выгружается (снова автоматически!) в исхтекст на прогязыке (напомним, что он есть подмножество "нейтрального" языка). Исхтекст загружается в прогсреду (допустим, ББ) и в ней компилируется; также формируются массивы встроенных в инфопрогизделие данных (конфиги, экраны, сообщения). Получается машкод, т.е. "внутренняя схема" приложения; при необходимости он правится вручную программистом. Для этого код можно выборочно визуализировать в РДП-редакторе, поддерживающем лиорасширение техноязыка; ЛД-схемы компилированного и правленого вариантов фрагмента кода сохраняются в проекте.
    С графит-инструкции по необходимости делается текстобазированное руководство оператора (как символ-сборка) или выдержка из РДП-документа в графовом виде. В принципе эти данные можно полностью или частично встраивать в инфопрог; когда он должен работать автономно от РДП-среды, в его код добавляется показчик РДП-документа.
В РДП-проекте также создаются другие докэлементы (оформляемые как жёсткие поля в структуре лист-силуэтов), с участием которых делаются и другие необходимые документы (руководство программиста, проспект решения и ещё чего нибудь).

А если РДП-редактор реализован как подсистема ББ (что и правильно) - то мы вообще нуждаемся кроме него только в инжсреде (если кто-то и её не запрограммирует в ББ :)). И РДП-документ, очевидно, существует как "модель-вьюшка-контроллер", для которого графит-представление есть одно из отображений...
Страница 1 из 2 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/