Тексто-графическое представление программы
Идеи обогатить сухой аскетизм текстов программ давно витает в воздухе.
Несколько картинок для иллюстрации.
Подобные идеи наверняка приходили в разные головы в разное время, и автор этих строк в этом плане не одинок. Однако хочется взять на себя смелость проработать их глубже. Графическое оформление блоков программы символами псевдографикиЗнакомство текстами программ для транслятора PL/1-КТ (его автор — Д.Ю. Караваев) привело к знакомству с одной оригинальной идеей. Дмитрий Юрьевич в своём трансляторе приравнял символы псевдографики к пробельным символам типа собственно пробела, табуляции и т.п. В связи с этим символы псевдографики могут находиться в любом месте программы, так же, как и пробелы. И тогда их можно использовать вот так:
Идея хороша и оригинальна. Удобна в реализации тем, что такие графические средства доступны в самых минималистичных текстовых редакторах. Было бы интересно увидеть, что идея воплощена до конца, что псевдографика соответствует блокам в программе. В работающем варианте она факультативна: её можно рисовать, можно и не рисовать, а можно рисовать неправильно: для транслятора символы псевдографики равносильны пробелам и ничего не значат. А ведь возможны такие варианты:
Что ещё почитать на эту тему
Опубликовано: 2012.09.25, последняя правка: 2022.01.21 13:22
Отзывы
Что в принципе доказывает возможность реализации графической альтернативы текстовым языкам программирования. Необходимость также доказана практикой внедрения и ростом популярности таких систем разработки. Что нас ждёт впереди? Никто не знает точно, а гадать можно сколько угодно и при этом от ошибки нет страховки ни у кого. Почему-то хочется верить в то что эволюция средств разработки и программирования пойдёт по пути упрощения процесса, снижения требований к уровню знаний в области, предоставления доступа к этой теме как можно большему числу обычных людей. Ведь когда-то же компьютеры были уделом маргинального меньшинства?!
Каждый из ВСЕХ существующих языков программирования можно условно разбить на ДВЕ части. Одна задает (описывает) данные и простейшие выражения (типа оператора присваивания) их обработки. Это не проблемная часть языков, потому что она закрепляет и формализует школьные знания человека и базируется на многовековых принципах математики. Вторая определяет машинные команды, операторы типа if, for, goto и т.д. для задания её работы по обработке данных. Мягко говоря, слишком упрощённый взгляд. А если описывает не простейшие выражения, а весьма не тривиальные? И почему эта часть языков не проблемная, если проблемы таки имеются?Для человека эти [машинные] команды слишком сложны (новы), примитивны (маломощны) и запутывают весь процесс программирования, являются причиной всех его ПРОБЛЕМ и сложностей. Ну не являются машинные команды источником всех проблем.Условия и выполняемые при этом Действия могут быть записаны на любом языке — русском, английском, китайском, математическом, программистском и т.д. в одну или несколько строк. Ввод Р-схем на порядок быстрее, трансляция проще и эффективнее. Р-схема на рис.2, например, по сравнению с записью её в С++ в 13 раз компактнее, не содержит 256(47%) символов из программы в С++, для её ввода требуется только 17 (по числу горизонтальных дуг) нажатий клавиш. Чтобы записать действия на перечисленных языках, потребуется значительное количество символов, вовсе не 17. При этом простота описания алгоритма не приводит к простоте описания данных. Т.е. недостатки Р-схем во многом повторяют недостатки блок-схем вообще и «Дракона» в частности. Эти инструменты применимы в императивной парадигме, но как насчёт функциональной?
К примеру, большую часть времени не обращаю внимание на парность скобок. Но иногда хочется себя проверить, вот тогда можно включить на пару секунд более контрастное выделение.
Мягко говоря, слишком упрощённый взгляд. А если описывает не простейшие выражения, а весьма не тривиальные? И почему эта часть языков не проблемная, если проблемы таки имеются? Наиболее разумным здесь, на мой взгляд видится некоторое средство тексто-графического грамотногоИ нечто в духе "функциональной геометрии". Вот она в репозитории с примерами: https://github.com/arnoldrobbins/dformat также интересны проекты: компилятор awk в Си https://github.com/arnoldrobbins/awkcc, статья arnoldrobbins/awk-sys-prog: "Awk As A Major Systems Programming Language" Revisited, https://github.com/arnoldrobbins/awk-sys-prog, средство Судя по мануалам для Troff — это тьюринг-полный язык разметки/текстовый процессор наподобие TeX. Например, про groff и набор макросов mom есть довольно наглядные обучалки. Сборка итогового PostScript или PDF выглядит как: dformat paper.in.troff | pic |troff -ms > paper.out.ps;здесь -ms или -mom — используемый набор макросов. А вся строка с конвейером на основе pipe — наглядная демонстрация принципа "Unix way": Делайте маленькие компактные программы, делающие одну вещь хорошо — связанные в общую сеть вычислений то есть: troff препроцессор/компилятор документации, из исходного базового языка разметки .troff через драйвер в нужный выходной формат, например, postscript или PDF или HTML или PCL или whatever. Аналогичный tex по низкоуровневости. Поэтому далее используют некоторый набор макросов поверх troff — например, ms или mom или ещё какой — получая примерный аналог LaTeX/ConTeX поверх базового TeX.В плане более качественного алгоритма из TeX, оптимизирующего пустые места между словами на основе "боксов и клея", мне больше нравится не стандартный Groff GNU troff или классический, а вот этот: Heirloom troff из Heirloom Project https://en.m.wikipedia.org/wiki/Heirloom_Project https://heirloom.sourceforge.net/ или отсюда: http://n-t-roff.github.io/heirloom/doctools.html https://github.com/n-t-roff/heirloom-doctools. Здесь например, элементарно используются и внедряются True Type шрифты, поддерживается UTF8, и генерируется сразу итоговый PDF. И базовый TeX, и базовый troff — алгоритмические текстовые процессоры/компиляторы в документацию. Посредством расширений или дополнительных наборов макросов или препроцессоров можно несколько повысить декларативность — но в довольно ограниченных пределах, и код всё равно остаётся довольно низкоуровневым, императивным. Например, dformat — небольшой DSL, препроцессор, который потом обрабатывается другим постпроцессором pic, который потом обрабатывается troff при компиляции в драйвер (с императивными инструкциями отрисовки) в итоговый PostScript, PDF или что там ещё. Язык pic уже чуть более декларативен (например, точки привязки вроде BoxB.e, BoxB.sw, BoxB.se) — но всё ещё требует например размеров и координат. Более интересен в этом смысле такой инструмент, как Lout: https://github.com/william8000/lout/commits/master и "литературное" средство Slit2 поверх него https://github.com/leonardoce/Slit2 Версия Lout-3.42.2 и последняя текущая мастер ветка отлично собирается например под windows компилятором gcc. Lout, Bassier Lout поддерживает только однобайтные кодировки и реализует компилятор в PostScript. Про настройку русского языка в Type1 PostScript KOI-8 (или CP1251) шрифтах см. https://wiki.archlinux.org/title/Lout https://github.com/i-kuzmin/lout-dejavu i-kuzmin/lout-dejavu: DejaVu fonts and Cyrillic koi8-r mapping for Lout, также см. https://web.archive.org/web/20051225233347/http://t37.nevod.perm.su, https://web.archive.org/web/20010910224155/http://linux.perm.ru/doc/documents/lout/install.html и https://web.archive.org/web/20051028020303/http://linux.ru.net/index.php?module=library&action=show&docid=116&part=996 либо например GitHub — smartmic/addfonts: Batch conversion of TTF/OTF fonts to Postscript Type1 files for easy usage with the Lout typesetting system https://github.com/smartmic/addfonts про диаграммы(блоксхемы) в списке рассылки https://lists.gnu.org/archive/html/lout-users/2011-03/msg00013.html. Lout уже более интересен чем базовый+макросы TeX или troff, потому что он более функциональный: бОльшая его часть фактически написана не на Си, а на PoscScript, который в свою очередь, по сути своей "функциональный Форт". Объекты состоят из символов, параграфов, страниц, картинок, и т.п. По сути здесь происходит компиляция в "функциональный PostScript" из некоторых first class (ну или не совсем) objects представлений объектов. Lout "из коробки" содержит бОльшую часть функциональности, которая обычно в TeX реализуется отдельными расширениями вроде asymptote, metapost, Pstricks и т.п. Для того чтобы написать какие-то документы достаточно просмотреть встроенную документацию и примеры. Как один из примеров, вот этот репозиторий: https://github.com/aeronau/ediciolout "Composicio de textos mitjancant Lout Arnau Prat Gasull lout-users Agost de 2016" смотрим (или собираем и смотрим) в репозитории 0.pdf и исходный его 0 и includes. Например: 30d @Rotate { Hola, mon }показывает "объект" строку "Привет, мир" повернутую на 30 градусов. Можно (см. стр. 20) определять макросы, или функции на PostScript:import @BasicSetupПоказывает в рамочке Arnau PRAT GASULL или import @BasicSetupопределяет макрос @cref который раскрывается в цепочку объектов. Ещё на Lua+С есть такой текстовый процессор как SILE: https://sile-typesetter.org/ Довольно таки очевидным становятся три вещи: 1. Можно написать аналогичный dformat для pic DSL: "Languages for pictures in AWK" — только проще, потому что PostScript у нас и так уже "функциональный форт", почти напрямую поддерживающий эти самые first class functional objects 2. Можно то же самое генерировать из 3. Можно, например, переписать Slit2 в Slit3 с паскаля на Аду, ещё далее повысив декларативность Literate Programming базовых блоков: сделать вместо <<function foobar>>метакод с параметрами-метапеременными именованных блоков кода: <<function foobar>>($config=Linux|Windows,$foo=bar,"txt",...)где во время компиляции документации посредством tangle эти метапеременные должны расширяться в нужные значения (аналогично @d макросам классического WEB Д.Кнута либо аналогично вычислению именованных блоков кода с параметрами в Emacs org-mode babel tangle). Можно пойти ещё дальше, в сторону first class objects, objects as environments, functional objects. Например, основанные на Scheme инструменты То есть, теперь нечто подобное Lout только на схеме вместо Си и Постскрипта — для генерации и в рантайме, и в компайлтайме, в единой first class environments среде. Про текстово-графическое представление программ. Ну вот, например, DRAKON Editor Степана Митькина на ActiveTCL. Вполне себе успешно справляется с кодогенерацией алгоритма из нарисованных блок-схем в исходники, написанные НА ЛЮБОМ языке (ибо настраиваемо, и десяток языков уже настроено "из коробки"). Здесь, если посмотреть на структуру файла с моделью, диаграммой, ДРАКОН граф-схемой, на файл формата .drn. То мы тут, внезапно, обнаружим внутри SQLite базу данных. То же самое можно было бы вполне реализовать на некотором гомоиконном языке — S-выражения лиспа, функции/макросы функционального постскрипта, РЕБОЛ-выражения в Реболе или RED. Кстати, неплохо было бы нечто подобное DRAKON Editor-у реализовать на RED. Интерпретируемый язык вроде Ребола, реализованный поверх низкоуровневого RED/System (аналогичного Си). Минималистичный тулчейн размером менее мегабайта. Примеры про лайвкодинг и эксель в 15 строчек на реактивном программировании в блоге. Так что подобную Kernel схему было бы разумно реализовать, прежде всего, на самом таком RED или даже RED/System. Что я хочу всем этим сказать? Вполне себе возможно написать нечто подобное используя одно средство литературного программирования и текстовый процессор вроде Lout, Pollen, ну или на худой конец SILE/Heirloom troff/TeX — в духе двух эквивалентных, гомоиконных представлений: 1. first class functional objects языков разметки/вёрстки, напрямую отображённых из графического представления алгоритма 2. то же самое в код — некоторый гомоиконный DSL для их представления 3. и посредством Ещё как пример достаточно высокоуровневого текстово-графического представления мультимодели. Можно посмотреть на язык Modelica и среды DrModelica, OpenModelica. Где по сути получается символьное вычисление композиции знаний, представленных объектно-ориентированным представлением уравнений. Метод connect соединяет объекты в подсборку, подсборки в сборку. Есть два эквивалентых пресдставления: и текстовое, и графическое.
Здесь нас интересуют, для наглядности стр. 88 Рис.6 Алгоритм поездки на автобусе (а,силуэт) стр. 89 Рис.6 (окончание)Алгоритм поездки на автобусе (б, примитив) стр. 92 Рис.7 Текстовый язык, соответствующий визуальному языку на рис. 6а (описаны только две ветки из четырёх) в Рис. 7 приведено следующее: АЛГОРИТМ Поездка на автобусеТакже в тему наглядных эквивалентных текстово-графических представлений: смотри стр. 177 глава 12 ДРАКОН-Си стр. 188 рис. 96 Программа игры "Угадайка" на языке ДРАКОН-2 cтр. 189 рис.97 Абстрактная ДРАКОН-схема стр. 190 рис.98 Программа "Угадайка" на языке ДРАКОН-Бейсик Попробую изобразить нечто в духе Рис.7, только на языке функционального программирования с first class-objects, например CURL. Программы на CURL — это "document literal", которые исполняет запускалка апплетов. Если современные веб-браузеры сами по себе довольно таки сложные — из-за accidental complexity, громоздкой трудоёмкости реализации трёх-четырёх разнородных технологий: 1) HTML, 2)CSS, 3)JS+DOM, 4)браузер как запускалка этого всего в виде Global Interpreter Lock, Язык CURL предлагал всё это "унифицировать" в виде функциональных объектов. Документ в облегчённой разметке — это "document literal" который апплет верстает в виде geometry layout manager, как набора вложенных контейнеров: HBox, который компонует горизонтально вправо, VBox который компонует вертикально вниз и прочих (наподобие P, DIV, SPAN). Можно указывать "макросы" в {CURLY BRACES} — отсюда и название языка. Это настоящие лисповые макросы, то есть, функции, обрабатывающие функции. В том числе, можно делать динамические переменные которые затем показывать привязкой в этим виджетам/гаджетам в разметке наподобие HTML. Только гибче — по сути в CURL, примерно как в Dylan или goo и используются functional objects = first class objects где object=class, object(в стиле CLOS), function, functor, макросы, окружения (bindings), модули, элементарные значения и т.п. Ранние публикации по CURL примерно 1998 года содержат исходники, компилирующиеся под Unix. Там взяли "браузер" на основе tcl/tk и добавили эдакий лисп. Который компилируется через Си в обычный native code. Актуальные версии платные, коммерческие, с ограничением по времени. CURL RTE кажется, бесплатное. Реализованы плагином к MS Internet Explorer или отдельным приложением. Среда разработки напоминает Jupiter Notebook в том смысле, что все примеры интерактивны и можно их тут же прямо в хелпе и исполнить. Попробую изобразить нечто в духе Рис.7, только на языке функционального программирования с first class-objects, например CURL. Это пока что псевдокод, запускать не пробовал :) Здесь понадобятся структурные контейнеры: {АЛГОРИТМ Поездка на автобусеПсевдокод приблизительный, как некоторая схема которую надо далее ковырять, чтобы запустилось. Необходимые пояснения:1) Документ-литерал показывает апплет, поэтому ему нужна структура в виде вложенных HBOX и VBOX. 2) Выражения в {фигурных скобках} — это вызов лисповых функций. Которые FEXPR, то есть, макросы. 3) В выражении {Foo bar ... } bar — это параметр Foo.4) в многострочных выражениях {Foo barbaz — это литерал-строка, которую документ-литерал компонует в соответствии с контейнером Foo, xyzzy — это строка-литерал, которую документ-литерах компонует в соответствии со всей структурой вложенных контейнеров Foo quux5) что-то надо придумать насчёт форм If-then, If-then-else — например, ЕСЛИИНАЧЕ для второй формы 6) по сути, здесь мы получаем две/три вещи сразу: а) структура вложенных контейнеров, определяющих выравнивание вложенных в него элементов HBOX, VBOX б) определение структуры DSL, задающей текстовое представление алгоритма в) набор поддерживающих макросов, FEXPS, функциональных объектов. Из (а) можно сгенерировать рисовалку графического представления алгоритма. В каком-то смысле, (а) и (б) эквиваленты — контейнеры HBOX, VBOX можно траспилировать в замыкание (наподобие CPS-преобразования), соответствующее единичному (естественному, натуральному) отображению. То есть, возможно, что из (а) можно сгенерировать и функциональную структуру императивной программы (б) — но это не точно.
Как улучшить работу ума Вы не поверите, но это давно уже обсуждалось. Главный недостаток всех схем заключается в том, что они делают акцент на описании алгоритма, хотя для программиста куда важнее описать данные. В приведённой статье даже статистика есть на эту тему.Здесь понадобятся структурные контейнеры: {АЛГОРИТМ Поездка на автобусеИменно такой синтаксис я и держу в голове. Только вместо фигурных скобок выбрал обычные. Если в блок-схемах рисуются графические элементы, которые потом заполняются текстом, то моё видение подразумевает, что сначала пишется текст, а уж потом на его основе автоматически генерируются графические элементы. За счёт настроек редактора степень графических украшательств регулируется от полного отсутствия до сверхподробностей.
Написать автору можно на электронную почту |
2014/01/17 05:17, Pensulo