Каким должен быть язык программирования? Анализ и критика Описание языка Компилятор
Отечественные разработки Cтатьи на компьютерные темы Компьютерный юмор Новости и прочее

Тексто-графическое представление программы

Идеи обогатить сухой аскетизм текстов программ давно витает в воздухе. Несколько картинок для иллюстрации.

Кирилл Осенков, osenkov.com/diplom/screenshots/cs/LightHorizontalGradient.png
Сергей Прохоренко, forum.oberoncore.ru/viewtopic.php?f=62&t=952&st=0&sk=t&sd=a


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

Графическое оформление блоков программы символами псевдографики

            Знакомство текстами программ для транслятора PL/1-КТ (его автор — Д.Ю. Караваев) привело к знакомству с одной оригинальной идеей. Дмитрий Юрьевич в своём трансляторе приравнял символы псевдографики к пробельным символам типа собственно пробела, табуляции и т.п. В связи с этим символы псевдографики могут находиться в любом месте программы, так же, как и пробелы. И тогда их можно использовать вот так:



Графическое оформление блоков программы символами псевдографики
Графическое оформление блоков программы символами псевдографики




            Идея хороша и оригинальна. Удобна в реализации тем, что такие графические средства доступны в самых минималистичных текстовых редакторах. Было бы интересно увидеть, что идея воплощена до конца, что псевдографика соответствует блокам в программе. В работающем варианте она факультативна: её можно рисовать, можно и не рисовать, а можно рисовать неправильно: для транслятора символы псевдографики равносильны пробелам и ничего не значат. А ведь возможны такие варианты:
  • Псевдографика «дорисовывается» (вставляется в нужное место текста программы) текстовым редактором или специальной утилитой. Это делается на основе анализа текста: встречающиеся ключевые слова управляют началом или концом блоков программы. Для PL/1 это осложняется тем, что в этом языке нет выделенных ключевых слов.
  • Псевдографика может стать таким же важным управляющим элементов прораммы, как и пробелы в языке Python. Именно на эти символы можно возложить обязанность в обозначение начала и конца блоков. По идее, эти символы могут быть взаимозаменяемы с ключевыми словами.
            

Что ещё почитать на эту тему

Опубликовано: 2012.09.25, последняя правка: 2022.01.21    13:22

ОценитеОценки посетителей
   ████████████████ 4 (36.3%)
   ████████ 2 (18.1%)
   ████████████ 3 (27.2%)
   ████████ 2 (18.1%)

Отзывы

     2014/01/17 05:17, Pensulo          # 

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

Что в принципе доказывает возможность реализации графической альтернативы текстовым языкам программирования. Необходимость также доказана практикой внедрения и ростом популярности таких систем разработки. Что нас ждёт впереди? Никто не знает точно, а гадать можно сколько угодно и при этом от ошибки нет страховки ни у кого.

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

     2016/01/07 01:25, Noname          # 

Как вариант дизайна Thyrd? http://thyrd.org/

     2016/02/19 08:57, Igor          # 

Это ещё из 80х Р-технология http://glushkov.org/?page_id=112

     2016/02/19 11:53, Автор сайта          # 

Пройдёмся по написанному по приведённой ссылке:

Каждый из ВСЕХ существующих языков программирования можно условно разбить на ДВЕ части. Одна задает (описывает) данные и простейшие выражения (типа оператора присваивания) их обработки. Это не проблемная часть языков, потому что она закрепляет и формализует школьные знания человека и базируется на многовековых принципах математики. Вторая определяет машинные команды, операторы типа if, for, goto и т.д. для задания её работы по обработке данных.

Мягко говоря, слишком упрощённый взгляд. А если описывает не простейшие выражения, а весьма не тривиальные? И почему эта часть языков не проблемная, если проблемы таки имеются?

Для человека эти [машинные] команды слишком сложны (новы), примитивны (маломощны) и запутывают весь процесс программирования, являются причиной всех его ПРОБЛЕМ и сложностей.

Ну не являются машинные команды источником всех проблем.

Условия и выполняемые при этом Действия могут быть записаны на любом языке — русском, английском, китайском, математическом, программистском и т.д. в одну или несколько строк. Ввод Р-схем на порядок быстрее, трансляция проще и эффективнее. Р-схема на рис.2, например, по сравнению с записью её в С++ в 13 раз компактнее, не содержит 256(47%) символов из программы в С++, для её ввода требуется только 17 (по числу горизонтальных дуг) нажатий клавиш.

Чтобы записать действия на перечисленных языках, потребуется значительное количество символов, вовсе не 17. При этом простота описания алгоритма не приводит к простоте описания данных. Т.е. недостатки Р-схем во многом повторяют недостатки блок-схем вообще и «Дракона» в частности. Эти инструменты применимы в императивной парадигме, но как насчёт функциональной?

     2018/10/04 18:55, Utkin          # 

Посмотрел Scratch. Отвечу так, личные впечатления — это все неэффективно. Такие блоки абсолютно не годятся для больших программ. Если их делать универсальные, то их смысл теряется, если уникальными (а в том же Scratch их очень много, при том, что это детский язык программирования), то все это превращается в кашу. Золотой середины там наверно нет. В общем цветовой винегрет эффективен для очень небольших участков кода. Это может быть интересно, например, для программирования микроконтроллеров. И такой проект (на базе того же Scratch — S4A, прототипирование Ардуино плат, обучение детей программированию микроконтроллеров) есть. Российская разработка — микроконтроллерный набор TETRA от Амперки, S4A также как и Scratch руссифицирует команды. Полноценный код он не дает, а управляет платой с компьютера (обычно через USB). В общем для демонстрации и быстрого прототипирования это удачное решение (а у TETRA там ещё и модули специально подключаются, то есть согласование датчиков и исполнительных устройств с микроконтроллером не требуется). Но для серьезного промышленного программирования все это неэффективно. Кроме того, блоки как в блок-схеме эффективны для традиционного структурного программирования. Но как быть с ООП? Аналогично со всеми этими замыканиями, анонимными и дружественными функциями? Yield? Обобщенное программирование? Это будет смотреться очень вырвиглазно.

     2018/10/05 17:11, Автор сайта          # 

Думаю, что золотую средину каждый должен искать себе сам, меняя настройки среды разработки. Создавая свои настройки или выбирая из нескольких рекомендованных. Возможные вариации — от полного отказа от синтаксической раскраски до «вырвиглазной» раскраски всего и вся (например, выделение очерёдности выполнения в соответствии с приоритетами, типа x = a + b * c).

К примеру, большую часть времени не обращаю внимание на парность скобок. Но иногда хочется себя проверить, вот тогда можно включить на пару секунд более контрастное выделение.

     2018/10/06 09:34, utkin          # 

Ну все-таки раскраска синтаксиса это одно. А раскраска блоков это другое. Опять же вопрос про людей с ограниченными возможностями. Если люди страдают дальтонизмом (не различают некоторые цвета) это также может создавать проблемы.

     2018/10/06 12:19, Автор сайта          # 

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

     2023/10/13 10:56, Shurik7777          # 

В Lazarus есть возможность отображать вложенные блоки в виде вертикальных линий. Сервис — Параметры — Редактор — Подсветка и соответствия — галочка на "Отображать контур блока (глобально)". Настройка цветов рядом в разделе Цвета в списке Цвета контуров блоков (по умолчанию слишком цветасто).

     2023/11/03 15:31, void          # 

Мягко говоря, слишком упрощённый взгляд. А если описывает не простейшие выражения, а весьма не тривиальные? И почему эта часть языков не проблемная, если проблемы таки имеются?

Наиболее разумным здесь, на мой взгляд видится некоторое средство тексто-графического грамотного литературного (мета)программирования — на основе first class object и реализованное поверх Scheme, соответственно. Как первое приближение к примеру, есть статья Jon L. Bentley, "Little Languages for Pictures in Awk", где описывается DSL dformat — препроцессор для pic (наподобие pic, grap, graf, chem и т.п.).

И нечто в духе "функциональной геометрии". Вот она в репозитории с примерами: 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, средство литературного грамотного программирования TexiWebJr https://github.com/arnoldrobbins/texiwebjr (на awk: texinfo -> ... -> pdf), индексатор https://github.com/arnoldrobbins/prepinfo, пример arnoldrobbins/texindex: Replacement version of texindex, written in awk, using TexiWebJr https://github.com/arnoldrobbins/texindex написанный в Literate Programming стиле.

Судя по мануалам для Troff — это тьюринг-полный язык разметки/текстовый процессор наподобие TeX. Например, про groff и набор макросов mom есть довольно наглядные обучалки. Сборка итогового PostScript или PDF выглядит как:
dformat paper.in.troff | pic |troff -ms > paper.out.ps;
ps2pdf paper.out.ps paper.out.pdf
здесь -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
def @arnauSC
{ @ShadowBox { Arnau @S { Prat Gasull } } }
Показывает в рамочке Arnau PRAT GASULL или
import @BasicSetup
def @cref right x
{ @I x }
определяет макрос @cref который раскрывается в цепочку объектов. Ещё на Lua+С есть такой текстовый процессор как SILE: https://sile-typesetter.org/

Довольно таки очевидным становятся три вещи:

1. Можно написать аналогичный dformat для pic DSL: "Languages for pictures in AWK" — только проще, потому что PostScript у нас и так уже "функциональный форт", почти напрямую поддерживающий эти самые first class functional objects

2. Можно то же самое генерировать из литературного грамотного препроцессора отдельным инструментом — вроде того самого slit2 на паскале.

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 инструменты литературного грамотного программирования: GNU skribillo на Guile, Pollen на Racket Scheme как DSL, ну или встроенный Scribe в Racket Scheme. Эта схема всё ещё не first class object, поэтому можно посмотреть оригинальные статьи John Schutt про Kernel, vau-expressions и реализацию на MIT scheme и портировать оттуда. Как конечный результат, должно получиться нечто, напоминающее "document literal" в языке Curl (тот, который язык стартапа, где был Т. Бернерс-Ли, а не утилита для скачки файлов). Этот самый "document literal" по сути и должен являться чем-то типа functional first class objects, bindings/environments/classes&objects as first class objects lambda/vau expressions.

То есть, теперь нечто подобное 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. и посредством литературного грамотного программирования — в единой, предпочтительно first class objects as environments среде.

Ещё как пример достаточно высокоуровневого текстово-графического представления мультимодели. Можно посмотреть на язык Modelica и среды DrModelica, OpenModelica. Где по сути получается символьное вычисление композиции знаний, представленных объектно-ориентированным представлением уравнений. Метод connect соединяет объекты в подсборку, подсборки в сборку. Есть два эквивалентых пресдставления: и текстовое, и графическое.

     2023/11/06 12:50, void          # 

Ещё вот подумалось, про наглядное представление программ. На сайте drakon.su в разделе https://drakon.su/knigi_vladimira_parondzhanova._skachat есть книги В. Д. Паронджанова, например, В.Д. Паронджанов "Как улучшить работу ума": https://drakon.su/_media/biblioteka_1/ parondzhanov_v.d. _kak_uluchshit_rabotu_uma_.pdf

Здесь нас интересуют, для наглядности
стр. 88 Рис.6 Алгоритм поездки на автобусе (а,силуэт)
стр. 89 Рис.6 (окончание)Алгоритм поездки на автобусе (б, примитив)
стр. 92 Рис.7 Текстовый язык, соответствующий визуальному языку на
рис. 6а (описаны только две ветки из четырёх)

в Рис. 7 приведено следующее:
АЛГОРИТМ Поездка на автобусе
ВЕТКА Поиск автобуса
ВЫПОЛНИТЬ Найди остановку автобуса и займи очередь
АДРЕС Ожидание посадки
КОНЕЦ ВЕТКИ
ВЕТКА Ожидание посадки
ЕСЛИ Автобус подошёл ?= ДА
ЦИКЛ ЖДАТЬ
КОММЕНТАРИЙ Происходит посадка пассажиров
ЕСЛИ Твоя очередь подошла ?= НЕТ
КОММЕНТАРИЙ Жди, пока подойдёт очередь
КОНЕЦ ЦИКЛА
ЕСЛИ В автобус можно войти ?= ДА
АДРЕС Посадка в автобус
М1: ИНАЧЕ КОММЕНТАРИЙ Жди прихода следующего автобуса
АДРЕС Ожидание посадки
КОНЕЦ ЕСЛИ
ИНАЧЕ ПЕРЕХОД НА М1
КОНЕЦ ЕСЛИ
ВЕТКА Посадка в автобус
ВЫПОЛНИТЬ Войди в автобус

<... и так далее ...>
Также в тему наглядных эквивалентных текстово-графических представлений: смотри
стр. 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. Это пока что псевдокод, запускать не пробовал :) Здесь понадобятся структурные контейнеры:
{АЛГОРИТМ Поездка на автобусе
{HBOX
{ВЕТКА
Поиск автобуса
{VBOX
{ВЫПОЛНИТЬ Найди остановку автобуса и займи очередь}
{АДРЕС Ожидание посадки}
}
}
{ВЕТКА
Ожидание посадки
{VBOX
{ЕСЛИИНАЧЕ Автобус подошёл ?= ДА
{ЦИКЛ ЖДАТЬ
{КОММЕНТАРИЙ
Происходит посадка пассажиров
}

{ЕСЛИ Твоя очередь подошла ?= НЕТ
{КОММЕНТАРИЙ
Жди, пока подойдёт очередь
}
}
}
{ЕСЛИИНАЧЕ В автобус можно войти ?= ДА
{АДРЕС Посадка в автобус}

}{МЕТКА М1

{КОММЕНТАРИЙ
Жди прихода следующего автобуса
}
{АДРЕС Ожидание посадки
}
}{
{ПЕРЕХОД НА М1}
}
}
{ВЕТКА Посадка в автобус
{VBOX
{ВЫПОЛНИТЬ Войди в автобус}
}
}
<... и так далее ...>
Псевдокод приблизительный, как некоторая схема которую надо далее ковырять, чтобы запустилось. Необходимые пояснения:

1) Документ-литерал показывает апплет, поэтому ему нужна структура в виде вложенных HBOX и VBOX.
2) Выражения в {фигурных скобках} — это вызов лисповых функций. Которые FEXPR, то есть, макросы.
3) В выражении {Foo bar ... } bar — это параметр Foo.
4) в многострочных выражениях
    {Foo bar
baz
{quux
xyzzy
}
}
baz — это литерал-строка, которую документ-литерал компонует в соответствии с контейнером Foo, xyzzy — это строка-литерал, которую документ-литерах компонует в соответствии со всей структурой вложенных контейнеров Foo quux
5) что-то надо придумать насчёт форм If-then, If-then-else — например, ЕСЛИИНАЧЕ для второй формы
6) по сути, здесь мы получаем две/три вещи сразу:

а) структура вложенных контейнеров, определяющих выравнивание вложенных в него элементов HBOX, VBOX
б) определение структуры DSL, задающей текстовое представление алгоритма
в) набор поддерживающих макросов, FEXPS, функциональных объектов.

Из (а) можно сгенерировать рисовалку графического представления алгоритма. В каком-то смысле, (а) и (б) эквиваленты — контейнеры HBOX, VBOX можно траспилировать в замыкание (наподобие CPS-преобразования), соответствующее единичному (естественному, натуральному) отображению. То есть, возможно, что из (а) можно сгенерировать и функциональную структуру императивной программы (б) — но это не точно.

     2023/11/06 17:45, Автор сайта          # 

Как улучшить работу ума

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

Здесь понадобятся структурные контейнеры:

{АЛГОРИТМ Поездка на автобусе
{HBOX
{ВЕТКА
Поиск автобуса
{VBOX
{ВЫПОЛНИТЬ Найди остановку автобуса и займи очередь}
{АДРЕС Ожидание посадки}
}
}
Именно такой синтаксис я и держу в голове. Только вместо фигурных скобок выбрал обычные. Если в блок-схемах рисуются графические элементы, которые потом заполняются текстом, то моё видение подразумевает, что сначала пишется текст, а уж потом на его основе автоматически генерируются графические элементы. За счёт настроек редактора степень графических украшательств регулируется от полного отсутствия до сверхподробностей.

Добавить свой отзыв

Написать автору можно на электронную почту
mail(аt)compiler.su

Авторизация

Регистрация

Выслать пароль

Карта сайта


Содержание

Каким должен быть язык программирования?

Анализ и критика

●  Устарел ли текст как форма представления программы

●  Русский язык и программирование

●  Многоязыковое программирование

Синтаксис языков программирования

Синтаксический сахар

●  Некоторые «вкусности» Алгол-68

●  «Двухмерный» синтаксис Python

●  Почему языки с синтаксисом Си популярнее языков с синтаксисом Паскаля?

●  Должна ли программа быть удобочитаемой?

●  Стиль языка программирования

●  Тексто-графическое представление программы

●●  Разделители

●●  Строки программы

●●  Слева направо или справа налево?

●  Комментарии

●●  Длинные комментарии

●●  Короткие комментарии

●●  Комментарии автоматической генерации документации

●●  Нерабочий код

●●  Помеченные комментарии

●  Нужны ли беззнаковые целые?

●  Шестнадцатиричные и двоичные константы

●  Условные операторы

●  Переключатель

●  Циклы

●●  Продолжение цикла и выход из него

●  Некошерный «goto»

●  Изменение приоритетов операций

●  Операции присвоения и проверки на равенство. Возможно ли одинаковое обозначение?

●  Так ли нужны операции «&&», «||» и «^^»?

●  Постфиксные инкремент и декремент

●  Почему в PHP для конкатенации строк используется «.»?

●  Указатели и ссылки в C++

●●  О неправомерном доступе к памяти через указатели

●  Обработка ошибок

●  Функциональное программирование

●●  Нечистые действия в чистых функциях

●●  О чистоте и нечистоте функций и языков

●●  Макросы — это чистые функции, исполняемые во время компиляции

●●  Хаскелл, детище британских учёных

●●  Измеряем замедление при вызове функций высших порядков

●●  C vs Haskell: сравнение скорости на простом примере

●●  Уникальность имён функций: за и против

●●  Каррирование: для чего и как

●●  О тестах, доказывающих отсутствие ошибок

●  Надёжные программы из ненадёжных компонентов

●●  О многократном резервировании функций

●  Использование памяти

●  Почему динамическое распределение памяти — это плохо

●  Как обеспечить возврат функциями объектов переменной длины?

●●  Типы переменного размера (dynamically sized types, DST) в языке Rust

●●  Массивы переменной длины в C/C++

●●  Размещение объектов в стеке, традиционный подход

●●  Размещение объектов переменной длины с использованием множества стеков

●●  Размещение объектов переменной длины с использованием двух стеков

●●  Реализация двухстековой модели размещения данных

●●  Двухстековая модель: тесты на скорость

●●  Изменение длины объекта в стеке во время исполнения

●●  Размещение объектов переменной длины с использованием одного стека

●  Можно ли забыть о «куче», если объекты переменной длины хранить в стеке

●  Безопасность и размещение объектов переменной длины в стеке

●  Массивы, структуры, типы, классы переменной длины

●  О хранении данных в стеке, вместо заключения

●  Реализация параметрического полиморфизма

Описание языка

Компилятор

Отечественные разработки

Cтатьи на компьютерные темы

Компьютерный юмор

Новости и прочее




Последние отзывы

2024/06/21 00:20 ••• Gudleifr
О превращении кибернетики в шаманство

2024/06/19 00:16 ••• Gudleifr
Программирование исчезнет. Будет дрессировка нейронных сетей

2024/06/12 11:27 ••• Автор сайта
Все языки эквивалентны. Но некоторые из них эквивалентнее других

2024/05/31 12:31 ••• Прохожий
Идеальный транслятор

2024/05/28 15:16 ••• Прохожий
Русской операционной системой должна стать ReactOS

2024/05/25 17:18 ••• Прохожий
Избранные компьютерные анекдоты

2024/05/11 16:33 ••• Автор сайта
Энтузиасты-разработчики компиляторов и их проекты

2024/04/28 15:58 ••• Автор сайта
Обработка ошибок

2024/04/23 00:00 ••• alextretyak
Признаки устаревшего языка

2024/04/21 00:00 ••• alextretyak
Постфиксные инкремент и декремент

2024/04/20 21:28 ••• Бурановский дедушка
Русский язык и программирование

2024/04/01 23:39 ••• Бурановский дедушка
Новости и прочее

2024/03/22 20:41 ••• void
Раскрутка компилятора