Каким должен быть язык программирования? Анализ и критика Описание языка Компилятор
Отечественные разработки 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. Именно на эти символы можно возложить обязанность в обозначение начала и конца блоков. По идее, эти символы могут быть взаимозаменяемы с ключевыми словами.
            

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

Последняя правка: 2018-10-18    08:50

ОценитеОценки посетителей
   ██████████████████████████████████████████ 2 (100%)
   ▌ 0
   ▌ 0
   ▌ 0

Отзывы

     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, Автор сайта

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

Написать отзыв

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

Авторизация

Регистрация

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

Карта сайта


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Комментарии

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

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

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

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

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

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

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

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

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

Циклы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Компилятор

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

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

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

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

Последние комментарии

2018/12/16 17:17 ••• Геннадий Тышов
✎ Программирование без программистов — это медицина без врачей

2018/12/07 08:57 ••• Автор сайта
✎ Почему обречён язык Форт

2018/12/07 08:36 ••• Автор сайта
✎ Нужны ли беззнаковые целые?

2018/12/03 13:51 ••• kt
✎ Экстракоды при синтезе программ

2018/11/30 17:56 ••• Freeman
✎ Изменение приоритетов операций

2018/11/30 17:20 ••• Автор сайта
✎ Почему языки с синтаксисом Си популярнее языков с синтаксисом Паскаля?

2018/11/26 14:23 ••• Автор сайта
✎ Так ли нужны операции «&&», «||» и «^^»?

2018/11/18 15:21 ••• Freeman
✎ Устарел ли текст как форма представления программы

2018/11/17 03:28 ••• Comdiv
✎ Изменение длины объекта в стеке во время исполнения

2018/11/16 12:53 ••• Автор сайта
✎ Помеченные комментарии

2018/11/11 14:01 ••• Александр Коновалов aka Маздайщик
✎ Нерабочий код

2018/11/11 13:39 ••• Александр Коновалов aka Маздайщик
✎ О русском языке в программировании