вторник, 6 ноября 2007 г.

"Древовидный" C++

Сергей Прохоренко в комментарии написал:

Вот несколько моих постов в форумах, которые могут быть полезны для Вашей разработки «древовидного» Си++...

Сергей, спасибо за ссылки и развернутые комментарии, а также за идею заголовка для этого поста :-). Практически со всеми соображениями, высказанными Вами, можно согласиться. Хочу только немного прояснить свое, так сказать, профессиональное «позиционирование» (выделения в Ваших цитатах – мои):

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

Хочу подчеркнуть, что структура программы (компилируемые модули, области видимости имен, объекты) и структура модели (подсистемы, элементы) вообще говоря не обязаны совпадать. При разработке сверху вниз следует начинать со структуры модели, на которую затем накладывать структуру программы.

Иными словами, Вы – совершенно справедливо - выделяете два фундаментальных компонента: модель предметной области и (программную) модель, ее реализующую. Ваши примеры касаются обоих компонентов; однако мои интересы все-таки ближе к программным моделям (каждый должен заниматься своим делом :-)); формализация и структурирование предметной области – все-таки весьма специфическая и далекая от меня задача, я пытаюсь что-то делать, скорее, в сфере анализа языков программирования как таковых.

Именно этому – своему проекту, которым я занимаюсь несколько последних месяцев – я хотел бы посвятить ближайшую серию постов (почти уже готовых). Речь там пойдет только и исключительно о том, как половчее представить программу на ЯП в виде дерева (а на самом деле, конечно, графа) и какие преимущества можно из такого представления получить.

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

И последнее замечание.
В некоторых текстах (не у Вас конкретно) чувствуется некая склонность к преувеличению важности для конечных пользователей "древовидного представления" программ. Я уже писал, что скептически отношусь к попыткам полной смены программной парадигмы: мол, синтаксис – гадость и излишество, давайте его выкинем и перейдем на древовидное представление программ (а заодно и обобщим все на свете: чего там, ведь условный оператор и в Си, и в Модуле, и где-там-еще представляется одинаковым деревом... :-)).

Менталитет разработчиков – вещь все-таки довольно деликатная и требует по крайней мере уважительного отношения. Чтобы совершить подобное насилие над привычками программистов, нужно предложить нечто, что было хотя бы таким же простым, удобным и универсальным, как синтаксически организованный программный текст. Чтобы манипулировать деревом, нужна как минимум адекватная поддержка – соответствующие программные инструменты – не говоря уже о том, чтобы такие инструменты сравнились по простоте и удобству с типичными текстовыми редакторами. Конечно, могут возразить, что в принципе манипулировать деревом ненамного сложнее, чем текстом на формальном языке – однако фундаментальное преимущество текста заключается в том, что с ним можно успешно и эффективно работать великим множеством способов - вплоть до листа бумаги.

Поэтому, если говорить о конечных пользователях – программистах, я бы все-таки рассматривал древовидное представление программы как дополнительное средство – для визуализации и навигации, например,- наряду с обычными (продвинутыми) текстовыми редакторами. С другой стороны, любой сколько-нибудь серьезный инструмент для работы с программными текстами (компилятор, например) практически всегда будет основываться на древовидном представлении. Существенно то, что дерево служит сугубо внутренним целям этого инструмента.

(Между прочим, редактор Visual Studio включает элементы «древовидного» подхода – фрагменты текста программы, соответствующие отдельным синтаксическим конструкциям, можно избирательно сворачивать и разворачивать. К сожалению, набор языковых конструкций, управляемых редактором, ограничивается пространствами имен, классами, функциями и комментариями и не распространяется на «внутренности» функций. Скорее всего, нечто подобное и в Эклипсе есть; может, даже и получше, чем в VS?)

6 комментариев:

Qbit комментирует...

К сожалению, набор языковых конструкций, управляемых редактором, ограничивается...

В VS есть #pragma region ... #pragma endregion.

Анонимный комментирует...

Что вы думаете о Flora/C+?

http://www.citforum.ru/programming/application/flora.shtml

http://www.softcraft.ru/design/cold/cold.shtml

или больше ссылок в Гугле

gouriev комментирует...

насчет манипулирования "древовидным" или любым другим графическим
представлением:

это уже было в "языках 4 поколения",
которые, однако, не распространились
широко, как мне кажется.

"древовидным" также может быть (или так рассматриваться) сам текст.
насколько я понимаю, в этом и заключалась парадигма "структурного программирования"). 1970?

этот мир стар как... мир :)

Анонимный комментирует...

> насчет манипулирования "древовидным" или любым другим графическим
представлением:

интересным является естественное эволюционное развитие такой системы, в духе классов и образа Смоллток-системы

> "древовидным" также может быть (или так рассматриваться) сам текст.

на уровне аспектов, компонентов, интерфейсов текст становится не двухмерным а трехмерным деревом :-)

Анонимный комментирует...

Евгению Зуеву еще одна интересная ссылка: http://www.osenkov.com/diplom/screenshots/cs/LightHorizontalGradient.png

Мне кажется, что система программирования "древовидного" языка программирования (не только "древовидного" C++) должен иметь:
1. Гипертекстовое представление - с ним непосредственно работает программист. В гипертекстовом представлении отображается и древовидная структура исходного текста модуля программы, и ссылки на связанные модули проекта, и ссылки на использованные функции, и сворачиваемые конструкции языка программирования.
2. xml-представление - в нём хранится исходный текст модуля программы, отображаемый в гипертекстовом представлении. Программист как правило НЕ РАБОТАЕТ непосредственно с xml-представлением.
3. Инструментальные панели и прочие элементы графического интерфейса, с которыми непосредственно работает программист.

Сергей Прохоренко
sergeyprokhorenko AT yahoo.com.au

Анонимный комментирует...

Мое улучшение схемы отступов, предложенной Осенковым:
http://forum.oberoncore.ru/viewtopic.php?f=62&t=952&st=0&sk=t&sd=a

Сергей Прохоренко
sergeyprokhorenko AT yahoo.com.au