Ну, и Ваша тоже.
Ответ на "эмоции вокруг" - в
этом посте. А здесь по существу - о применимости.
...
ИС Дракон реализуется язык Дракон описанный в книге "Как ..." с развитием в части перехода от бумажного документа к интерактивному на компьютере, в части расширения области применения от отраслевого к широкому применению в различных областях деятельности.
Кроме того, существуем личный опыт, наработанный многолетней разносторонней работой - всегда ответственной.
Да... только всё это делается почему-то "утилитарно"...
...
А была бы разработка открытая, начиная со спецификации реализуемых языков - могли бы подключиться не отдельные коллеги (вроде того, о ком идёт речь здесь):
Недавно товарищ (на форуме не был), прислал модуль, позволяющий избавиться от эффекта мерцания при перерисовке экрана, также собирается заняться выгрузкой в формате XML.
- а более широкий круг.
...
Само по себе описание, вообще говоря, м.б. сформировать легче, пользуясь результатами работы с продуктом - и для этого вроде бы предназначены темы, связанные с Ты-средой. Но их материал надо использовать, "втаскивая" в целостно организованную Справку. И даже это в принципе мог бы делать не сам разработчик (хотя бы предварительно) - но при определённом достигнутом уровне качества и самого изделия и конечной формы документации на него.
И об отношении создателя к процессу разработки. Вот это:
...
Так как прототипа среды языка Дракон общего применения нет, то развитие и.с. Drakon идет эволюционным путем. Нет и теории для реализации, поэтому проектирование производится с использованием эвристических алгоритмом - основанных на наблюдении, методе проб и ошибок. Не всегда достаточно знаний средств разработки на языке Delphi и операционной системы.
Развитие и выполнение доработок приводит и к появлению ложного пути развития, новых недоработок и ошибок.
...
Выкладывание программного кода не предполагается. Не будет траты Вашего и моего времени на вопросы связанные с пристрастиями к технике программирования.
Благодарю за внимание, понимание и сотрудничество.
- вместе с уже пройденным путём развития вызывает, по крайней мере, следующие вопросы:
1) У Вас, судя по послужному списку, д.б. хорошее образование в части математических основ информатики (в частности, визуализации графов; уточню, что говорю без иронии). Плюс практический опыт, о котором Вы говорите. Почему бы не выработать теорию упорядоченных "по-Паронджановски" граф-схем для редактора?.. Тогда вряд ли потребовался бы путь "информатического тыка"...
2) Если язык таков, что знаний по разработке на нём не всегда достаточно - нужно ли продолжать на нём работать?..
3) Если появился ложный путь развития - наверное, нужно от него отказаться? А не продолжать следовать?..
...Вы пишите:
Цитата:
радостно, что делается хоть что-то, и грустно, что не всё возможное...
Разработка ИС Дракон выполняется эволюционно и нельзя требовать "всё возможное" и сразу в одной программе. Тем более, "всё возможное" это так неопределенно, вы творчески подойдите к использований ИС Дракон не пользуясь стереотипами.
Если подходить творчески - то стоит напомнить известный советский фильм "Приходите завтра". Там один из главных героев - скульптор (А. Папанов) - также чувствует, что зашёл в творческий тупик. Во многом из-за того, что работает в основном "на коротких временах", "на потребу". Но не может ни на что решиться. И только случайная неосторожность главной героини (Е. Савинова) - она разбивает одну из "ширпотребовских" его статуй. И это подталкивает его - освободиться от "плодов лёгкого успеха" и начать всё заново.
Конкретно могу свой опыт напомнить - несмотря на те же предостережения Рэйлвей Каген, я тоже до поры не вникал глубоко в терминологию "шампур-метода" и теорию, которая должна за ней стоять. Как результат - то, что описано в
этом посте. Понадобилось выстраивать всё заново. Что и отражено для понятийного аппарата
в этом пункте.
И теперь представление о "предметке" графовой визуализации стало допускать сопряжения с другими результатами. Так, если посмотреть на
эту книгу, то в п. 4.3 (не вошёл в выдержку) есть "Начальные идеи поиска классов". И вот если посмотреть на сущности, которые выделяет Мейер - то можно увидеть некие соответствия с графит-понятиями (STATION - вершина, LINE - трасса, ROUTE - маршрут, LEG - марш). Возможно, это даёт идею для использования его результатов в редакторе. Но если это опять программировать на "языке с утечками"... и без теории... что получится?..
Так что задуматься над опытом героя Папанова есть смысл... И начинать нужно со спецификации - как это делает С. Прохоренко
здесь. А то Вы, Геннадий Николаевич, иронизируете над "теоретиками", "преподавателями, которые посылают читать" да "трудами" - а Валерий Лаптев превращает "качественные" определения Сергея в реальный проект... и недостающие теоретические положения вырабатывая, и в работе ОС разбираясь... И подключая студентов, которые в результате начинают писать
лучше и на не вполне "гарантоспосообных" прогязыках. Это ли не пример того, каким
должен быть эффект применения среды формализации в ИТ-образовании?..