DRAKON.SU

Текущее время: Пятница, 29 Март, 2024 04:19

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




Начать новую тему Ответить на тему  [ Сообщений: 28 ]  На страницу 1, 2  След.
Автор Сообщение
СообщениеДобавлено: Пятница, 18 Март, 2011 12:28 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 145
Откуда: Москва
Предлагается концепция автора как создать
- графический пакет для Дракона
- язык в пару к Оберону


Два пернатых в одной берлоге не уживутся? 1
Оглавление 2
Предисловие 3
Введение 4
1. Что мы хотим от графических пакетов? 6
1.1. Интерфейсотехника Раскина 7
1.2. На Вашем экране. 9
1.3. Элементарные принципы и действия 12
1.4. Программный доступ к данным 14
2. Какой язык нам нужен? 15
3. Все вместе 18
3.1. Концепт Вашей системы 18
3.2 Структура данных схемы для Вашей системы. 22
3.3. Исполняющая программа для Вашей системы. 24
3.4. Запуск программы для Вашей системы. 26
4. С высоты птичьего полета 27
К сообществу 30
Заключение 31
Список литературы 32


Вложения:
Dva_Pernatyh.pdf [1.3 МБ]
Скачиваний: 610
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Март, 2011 12:53 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 143
Откуда: Россия, Орёл
Вы читали Пфистер К. Компонентное программное обеспечение?

Прочитав "1.2 На вашем экране", у меня сложилось ощущение, что нет, т.к.
Цитата:
Начнём с простых вещей:
...
рисунок
написанное здесь у меня сразу проассоциировалось с Блэкбокс.

Его я и советую как графическую оболочку. Или, на выбор, другой потомок системы Оберон или её саму.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Март, 2011 13:22 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 145
Откуда: Москва
Евгений!

Спасибо. Я прочитал. К сказанному не добавлю.

К сожалению, Ваш совет относительно графической оболочки непригоден. В предлагаемой назначение другое.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Март, 2011 20:31 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Интересный документ. Зацепил очень многие из собственных соображений.
Попробовал изложить "зацепленное", но времени причёсывать нет, поэтому изложение сильно черновое.

=======


1. О концепции единой графической среды.
Концепция представляется глубоко правильной (она, в общем, не нова, но её постановка ещё раз, с современных позиций и в контексте Дракона и Оберона, представляется очень полезной).
Один из самых удручающих моментов в современном программостроении - это разобщённость решений. Такая разобщённость, которая для понимающих людей (например, "оберонщиков") выглядит просто "сизифовым трудом". Например, у разработчиков на массовых технологиях нет даже привычной для программистов на Компонентном Паскале/Блэкбоксе унифицированной базы для составных текстовых документов, которая позволяла бы разработчикам приложений унифицированно предоставлять такой сервис и его расширения пользователям. Каждый вынужден решать эту задачу повторно, многократно, одинаково некачественно (потому что невозможно решать такую сложную задачу в индивидуальном порядке). Нечего и говорить про следующий уровень - графического редактирования, на нём всё ещё хуже.
Естественные потребности алгоритмизировать и интегрировать программные решения сегодня обеспечиваются зоопарком скриптовых языков, внешних форматов и протоколов и т.п. В общем, всё очень "запущено". Хотя те, кто работает в операционных средах вроде Блэкбокса, Смоллтока и т.п. знают, как это может быть решено.
Тот же Блэкбокс можно рассматривать применительно к обсуждаемым идеям как верный прототип, серьёзный шаг в нужном направлении. Правда, пока что покрывающий программирующую целевую аудиторию и обеспечивающий текстоцентричные задачи. Двигаться дальше можно, перепроектировав, развив систему на новом уровне.

2. О парном к Оберону языке
С одной стороны, вполне понятно, от каких соображений отталкивается автор. С другой стороны, первое желание такой язык иметь может оказаться... скоропалительным. Это не значит, конечно, что в итоге не будет смысла его иметь. Но, может быть, для другого профиля, других проблем, чем кажется изначально.
Здесь я выскажу несколько отдельных соображений, без какого-то обобщающего мнения.
Во-первых, эмпирический факт: в Оберон-системах Оберон успешно выполняет функции макроязыка/скрипта, как раз это мы считаем традиционным преимуществом. В частности, говорим о том, что то, что пытаются получить, скрещивая тот же С и Питон (динамичность-гибкость и компилируемость-быстродействие), уже имеется в виде одного языка. Т.е. задача традиционных макроязыков на Обероне успешно решается без отдельного языка. Но это не значит, что нет каких-то новых задач (исходящих из специфики той же единой пользовательской среды), которые пока ещё не решаются.
В принципе, в качестве языка верхнего уровня можно рассмотреть правила записи и комбинации команд и "органов управления" в пользовательской среде. Какие-то конвейеры передачи результатов между операциями и проч. В ББ это обеспечивается в том числе спец. графическими объектами в активном тексте. Т.е. часть таких задач решается на уровне объектов интерфейса, активного документа.
Во-вторых, существует специфика задач интеграции компонентов (обеспечения вот этого "конвейера" между компонентами), требующая особых структур данных, удобных для этого. Как раз тот момент, который Вы отмечаете, говоря о том, что язык этого верхнего уровня должен быть ориентирован на текст. Ещё в СССР у тех же новосибирцев были языки вот такого тексто-ориентированного, интегрирующего характера. Сегодня эта специфика присуща распространённым скриптовым языкам типа PHP, ECMAScript(JavaScript). (Я не упоминаю более серьёзные языки, ориентированные на разнообразные структуры данных, функциональные языки, в частности). В принципе, структуры данных для удобного решения задач интеграции устоялись, например, в том же JavaScript - какими бы проблемами он не обладал, но "склеивать" на нём можно быстро и легко. Моё мнение - что стоит попробовать это сложившееся из скриптовых языков понимание отобразить в библиотеки на Обероне, и, возможно, необходимость для решения этих проблем в отдельном языке вообще отпадёт.
Однако, если говорить об отдельном языке, то я бы посмотрел в качестве одного из примеров марковские языки, например, тот же Рефал. И тут мы подходим, как раз глядя на Рефал, к ещё одному моменту, который Вы тоже затронули, говоря о необходимости "удобно обрабатывать графические схемы как данные". Язык должен быть, оказывается, не на плоские строки ориентирован, а на обработку иерархических данных. Они характерны для некоторых прикладных задач, бизнес-задач. На мой взгляд, набор базовых средств обработки таких данных сегодня есть в XPath/XQuery, по крайней мере, таков мой опыт их использования.
И в-третьих, возможно, языком вот этого верхнего уровня (склеивающим, интегрирующим) мог бы стать Дракон с древовидными структрами данных, соответствующими XML-языкам, правда, упрощённым до уровня непрофессиональных программистов. Но с сохранением преобразований в XML, который реально сегодня стал форматом для интеграции программных систем.
Такие вот соображения.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Март, 2011 22:30 

Зарегистрирован: Пятница, 24 Апрель, 2009 16:28
Сообщения: 66
Откуда: Москва
Дмитрий Дагаев писал(а):
Два пернатых в одной берлоге не уживутся

На сегодняшний день в сообществе имеет место согласие по двум пунктам:
1. Оберон – это хорошо;
2. Дракон – это хорошо.
Хотелось бы обратить Ваше внимание на то, что по п. 2 такого согласия нет.
Первый не комментирую.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Март, 2011 23:15 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 77
Откуда: Астрахань
Я бы еще уточнил пункт 1: ББ+КП - это хорошо. КП (и Оберон) без ББ - обычные языки программирования.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 19 Март, 2011 11:55 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 145
Откуда: Москва
Я еще хотел уточнить, что мы в этом разделе обсуждаем, а что - нет.
Не обсуждаем
На чем основывать графический пакет? Ну и я могу делать разработку в средах
Qt, MS Visual Studio, vxWindows, tk, DvDraw? Кого это в этом форуме интересует?
Никого.
Графический пакет будет основан на Обероне+Блэкбокс
Мы находимся в каталоге Визуальный язык ДРАКОН.
ДРАКОН будет представлен как обязательный графический язык

Обсуждаем
С учетом сообщения И.Ермакова получается
1. Концепт графического пакета
2.1. Язык скрипта: tcl, perl, lisp, PHP, JavaScript
2.2. Язык представления данных Дракон-схемы: tcl, XML, Рефал
Я свой выбор предложил.
Не соглашайтесь! Высказывайтесь!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 19 Март, 2011 12:29 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Думаю, что брать ни один из готовых языков нельзя, нужно разобраться с проблемой и сделать свой. Зашивать какие-то исторические случайности-дефекты в новую разработку нельзя. Оберон и Дракон в этом плане свободны от таких проблем, потому что очень компактны и "чисты". А названные скриптовые языки - нет.
Одно только наличие какого-нибудь break для циклов - уже недопустимый дефект языка для выбора с современной точки зрения.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 21 Март, 2011 09:57 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 145
Откуда: Москва
Уважаемый Илья!

Один комментарий по поводу сказанного Вами
Цитата:
На мой взгляд, набор базовых средств обработки таких данных сегодня есть в XPath/XQuery, по крайней мере, таков мой опыт их использования.

Схема Рис.1 имеет бинарный формат файла и два текстовых. Один - то, что я предлагал (1200 строк, 109Кбайт). Второй - xml (7500 строк, 180КБайт).
Преимущества формата в виде языка: более компактный и понятный для человека, можно использовать как программу для интерпретатора.
Преимущества формата в виде xml: работа с данными большой степени вложенности, поиск в таких структурах XPath/XQuery.
В реальной работе осуществляем декомпозизию, т.е. вложенные объекты, блоки и проч. сохраняем отдельно.
Я склоняюсь к предложенному формату, т.к. пока мне удается обходиться без xml формата, но держу его про запас. Ваши опасения понимаю.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 22 Март, 2011 15:10 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Дмитрий, я тоже не фанат XML, я начинал его использовать не сильно охотно.
Просто у XML-технологий есть набор объективно ценных свойств, и я не вижу альтернатив по этим свойствам.
Я бы хотел спроектировать своё, как это представляю, но не до того пока :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 23 Март, 2011 08:13 

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


Последний раз редактировалось Владислав Жаринов Среда, 23 Март, 2011 08:43, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 23 Март, 2011 08:26 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Речь идёт о реинжиниринге тех, в общем, правильных идей, заложенных в XML-семейство, до компактного вида. Потому что то, что сейчас закреплено в стандарте, никогда никто не пытался упростить (хотя этим должны заниматься сами авторы), а разработка, не прошедшая фазу критического упрощения, может восприниматься только как прототип.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 23 Март, 2011 08:45 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Илья Ермаков писал(а):
Речь идёт о реинжиниринге тех, в общем, правильных идей, заложенных в XML-семейство, до компактного вида.
...
Вот к вопросу "инжиниринга" - т.е. определения состава сущностей документа и их представления человеку (отвлекаясь от того, как это будет записано текстом в файле документа):
1. Приемлемо ли такое определение документа, как в этом сообщении?

2. По поводу скрипт-языка - как Вы считаете, не построить ли его по принципу техноязыка - как язык лист-силуэтов (допуская исполнение команд редактора, скажем, как вставок)? Т.е. фактически "графит-Оберон-скрипт" :) ?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 23 Март, 2011 09:25 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Драконограф писал(а):
1. Приемлемо ли такое определение документа, как в этом сообщении?


А можно резюме из этого сообщения? :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 23 Март, 2011 09:56 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Дмитрий Дагаев писал(а):
Предлагается концепция автора как создать
- графический пакет для Дракона
- язык в пару к Оберону
...
Некоторые мысли:

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

Разд. 3. Вывод к п. 3.1 очевиден и "предметных" возражений не вызывает. Оператору программы, ясное дело, нужен не её алгоритм - а алгоритм работы с ней. Это процесс, взаимодействующий ("параллельный") с процессом исполнения программы; взаимодействие идёт через пультовые команды. При представлении процесса оператора как графит-инструкции их форматы описываются взаимосвязанно с алгоритмом процесса (напр, как выборки из форм диалога с отражением, какие пля формы становятся аргументами пультовых команд оператора/сообщений машины).

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

По поводу "языка оболочки" высказался здесь - как и о проекте структуры данных, представляющей документ редактора. Там заложено и представление полного пути к частям документа - как к РДП-переменным с техноименем-индексом в "объектной системе координат", и применение из документа команд редактора к содержимому данного и/или иных документов (для визуальной автоматизации работы в редакторе).
То, что касается деталей реализации работы с документом в графит-редакторе (его "нейтральной схемы" как приложения, обрабатывающего структуры данных документа), конечно, во всей полноте обсуждать программистам.


Последний раз редактировалось Владислав Жаринов Среда, 23 Март, 2011 10:13, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 23 Март, 2011 10:11 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Илья Ермаков писал(а):
Драконограф писал(а):
1. Приемлемо ли такое определение документа, как в этом сообщении?
А можно резюме из этого сообщения? :)
Язык, кратко описанный в Разд.2 "Лексика ЛС-диалекта" этого демо-примера, д.б. языком представления документа графит-редактора. Он же (в режиме исполнения документа) определяет сценарий представления содержания документа, - а также и оперирования с содержанием, если в лист-силуэтах есть операторы-действия (как в этом примере). Естественно, действия могут распространяться и на другие документы (надо определить, как они находятся редактором).
Общий принцип построения документа изложен вкратце в п/р 1.4 демо-примера. Разумеется, это т. зр. "предметника" - программист может уточнить.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 23 Март, 2011 14:54 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 83
Мне понравилась фраза: Не должно быть отдельных приложений а должна быть
одна графическая программа.

Фирма Microsoft упорно работает в этом направлении
-----------------------------------------------------------------------
Теперь по делу.

Почему нет ПО ?

Крупные софтверные компании не заинтересовались описанием языка ДРАКОН, которое
опубликовал Владимир Даниелович, и не захотели реализовывать его в своих программных
продуктах.
Не нашлось также и крепкого сообщества разработчиков свободного ПО, которое захотело
бы решать эту задачу.

По базовому комплекту открытого ПО:

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

Так что вопрос сейчас состоит в том, найдутся ли желающие что-нибудь делать хотя бы
на таком уровне.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 24 Март, 2011 09:12 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 145
Откуда: Москва
Уважаемый Дмитрий_ВБ!

Полностью с Вами согласен. Несколько ремарок.
1. Я и хочу определить "найдутся ли желающие что-нибудь делать". Для того пишу.
2. Графические программы, которые есть, мы видим. И разработчики понимают, что отстают от "крупных софтверных компаний". Разработчиков устраивают свои продукты в таком виде?
3. Я сделал первый шаг: концепцию на графику и язык. Собираюсь сделать второй: концепцию построения реальных систем на всем этом.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 24 Март, 2011 09:16 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 145
Откуда: Москва
Уважаемый Драконограф!

Цитата:
По поводу "языка оболочки" высказался здесь - как и о проекте структуры данных, представляющей документ редактора

Поясните пожалуйста, какие структуры данных для Дракона Вы предлагаете. А то не пойму по ссылке.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Март, 2011 12:19 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 145
Откуда: Москва
Я опубликовал концепцию построения реальных систем на визуальных языках.
viewtopic.php?f=62&t=3355


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

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


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

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


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

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