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

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

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

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

        Логика рассуждений понятна. Текст — это видимая сущность, из которой порождается суть программы, её семантика, невидимая часть. Можно напрямую создавать семантику программы, минуя «архаичный» текст. Исчезает надобность в каком-либо синтаксисе.

        Идея достаточно интересна. Похожие идеи были высказаны Евгению Зуеву:

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

на что он ответил статьёй "Древовидный" C++. Вот сжатый ответ Евгения:

        Речь ... пойдет ... о том, как ... представить программу на ЯП в виде дерева (а на самом деле, конечно, графа) и какие преимущества можно из такого представления получить.

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

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

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

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



        Чем отличаются формат html от форматов pdf и doc? Да тем, что html-документ можно набрать в любом текстовом редакторе. А ведь можно было, уйдя от простого текста, разработать такой формат, который бы обеспечил бы и меньший объём документа, и скорость загрузки, и моментальность отображения. Но выбор сделан в пользу того, что мы сейчас имеем, и это не случайно.

        Так что прав Евгений Зуев: текст ещё долго будет служить программистам верой и правдой.

Последняя правка: 2014-12-23    16:40

ОценитеОценки посетителей
   ███████████████████ 4 (44.4%)
   ██████████ 2 (22.2%)
   ██████████ 2 (22.2%)
   █████ 1 (11.1%)

Отзывы

     2014/01/22 05:47, Сергей

Возможно, есть ещё одна вещь: кому-то может быть удобнее мышление образами, кому-то — словами. Вот и разделятся разработчики на сторонников изобразительного (или чертёжного) программирования и сторонников обычного, письменного программирования.

     2014/04/21 06:43, utkin

Скорее не устарел, однако хранение программ в других форматах заслуживает внимания. Действительно большинство языков программирования можно рассматривать в виде графов либо в виде деревьев (что является частным случаем графа). Деревья отлично структурируют программу и вполне соответствуют современным представлениям в программировании — блоки кода, классы, объекты и пр. Кроме того, уже частично готова инфраструктура, например XML позволяет хранить структурированные тексты программ без особых усилий.
С программной точки зрения механизм также не вызывает затруднений — можно ввести в модель понятие блока, имеющего сходство с понятием узла в дереве. В зависимости от типа блок можно представлять как часть кода между программными скобками {} или begin-end, цикл, условие (там могут быть 2 блока), функция и пр. Оператор goto  в таком случае становится чисто физически затруднительным.

     2014/04/24 21:01, Автор сайта

Было бы интересно в результате компиляции получить и увидеть граф программы. На мой взгляд, текстовая форма хранения программы по-прежнему должна являться основной. Если же вводить/редактировать граф программы, то всё равно должна быть возможность преобразования в текстовый вид. Да и редактирование графа потребует соответствующих инструментов. Вещь, конечно, интересная, но не повлечёт ли это дополнительные сложности? Какие у Вас соображения?

     2014/06/17 04:22, utkin

Какие у Вас соображения?

Фактически вторая Валентина собиралась (и следующая версия также планируется собираться в дерево). То есть при старте в один проход идет разбор структур в дерево. Это ни где не отображалось — тогда не было таких идей, просто так было удобно рассматривать процессы. Вычислительный процесс представлялся таким образом:
Программа состоит из блоков (ООП не было, много сложностей и я ставил перед собой другие задачи). Каждый блок это узел дерева. Корневой узел — самый глобальный блок создается интерпретатором автоматически. То есть пустая программа это просто корень дерева. Узлы имеют ссылки на другие узлы (блоки программы) и на список строк (преобразованный текст программы). Блок это универсальная форма, которая может иметь несколько представлений:
1. Программные скобки — begin-end или {-}
2. Условия
3. Циклы
4. Методы (функции — много параметров / один результат).
Все это описывалось одной структурой (просто заполнялись нужные для конкретного блока поля).
Из блоков я не успел реализовать следующие возможности — загрузка методов из внешних модулей и подключение сторонних библиотек (DLL — тогда интерпретатор был жестко ориентирован на Windows)
Таким образом, данные блоки могли бы быть:
а) Представлены графически (при этом текстовое представление программы хранилось отдельно) и соответственно сохранены/распечатаны как картинка.
б) Сохранено во внешних источниках (XML, JSON и т.д.)
в) Прочитаны из внешних источников.
На текущий момент это было не реализовано (но реализация была возможна).
Сама идея блоков была рождена с той целью, чтобы можно было в будущем свободно копировать некоторые узлы из блока в блок (сходная идея — снипеты в Visual Studio).
Насчет преобразований, то собрать текст из блока намного проще (потому что блок порожден автоматически, обработан и имеет мало ситуаций для обработки, чем текст введенный человеком), чем представить обычную программу в виде дерева.

     2014/06/17 16:49, Автор сайта

функции — много параметров / один результат

А каков тип этого результата — элементарный или же это может быть, к примеру, структурой или массивом?
Как-нибудь надо будет поближе познакомиться в Вашими идеями :)

     2014/06/19 10:10, utkin

Язык безтиповый, результат строка. Однако строка может рассматриваться с разных позиций. Были группы встроенных функций, рассматривающих строку как массив, стек и т.д. (требовалось указание разделителя, например, если брать разделителем пробле, то можно работать со словами, если слеш, то можно обрабатывать путь в файловой системе и т.д.) Плюс длинная арифметика (разряды представлялись символьно). Также были операции сохранения/чтения строки в/из файл(а) (без промежуточных операций типа, открыть/закрыть). Ввод/вывод был базовый (по типу JavaScript), крутые навороты планировались через DLL и как веб-интерфейс (по типу настроек модемов/роутеров).

     2014/06/19 18:06, Автор сайта

Понятно. И эта возвращаемая строка находится, конечно, в «куче», в динамической памяти. И Вы, конечно, считаете, что современная техника пережуёт любую программную неэффективность. В том числе и избыточное использование динамической памяти. А у Вас не было интереса к тому, чтобы строки размещать в стеке? Да-да, в аппаратном стеке, с использованием регистров ESP и EBP? Ведь такая модель использования памяти значительно эффективнее и надёжнее.

операции сохранения/чтения строки в/из файл(а) без промежуточных операций типа, открыть/закрыть

Вот это интересно. Открывать/закрывать всё равно придётся, только у Вас это делается неявно, спрятано за кадром. Наверное, перед всякой операцией чтения/записи делается неявное открытие, а по окончании — неявное закрытие?

     2014/06/20 10:32, utkin

Меня интересовала прежде всего проверка моих предположений и сама возможность реализации идей. Вопрос эффективности можно оставить на потом. Я принципиально не против стека. Есть возможность, значит можно запихать в стек, хорошо. Но на тот момент это было не главное.

Вот это интересно. Открывать/закрывать всё равно придётся, только у Вас это делается неявно, спрятано за кадром. Наверное, перед всякой операцией чтения/записи делается неявное открытие, а по окончании — неявное закрытие?

Естественно. Но идея была абстрагироваться от таких нюансов. Зачем это нужно программисту? Да, при сохранении в двоичном виде, постоянном чтении/записи (как например в базах данных) такая ситуация оправдана. Но здесь были другие принципы. Один из которых — более человеческое взаимодействие с компьютером. Все-таки, нравится/не нравится, но в паскале и си человек должен знать и уметь некоторые вещи, которые на самом деле не нужны для решения практических задач. Например, чтение из файла. Открытие файла в таком случае «лишняя» операция. Она нужна чтобы соблюсти ритуал операционной системы. Но для решения задачи в данной операции нет необходимости. Аналогично и различные типы чисел. Да, word эффективнее, чем byte. А Integer предпочтительней использовать, чем Boolean. Но опять-таки для подавляющего большинства прикладных (именно прикладных) задач, не связанных с самим программированием, эти данные вполне можно укладывать в Integer и напрочь забыть про остальные упомянутые. Страдает эффективность, согласен. Но язык не заточен на создание системных приложений. А в подавляющем большинстве остальных случаев эффективности Integer более чем достаточно.

Ведь такая модель использования памяти значительно эффективнее и надёжнее.

В плане эффективности, наверно, да. В плане надежности не понял, в чем она заключается?

     2015/11/03 15:20, me.lunin(аt)gmail.com

Только традиции полувековой и более давности, восходящей к ленте Тьюринга, только слабость технической базы университетов и попытка найти универсальный подход к любой проблеме и консерватизм — только это проблема. И дайте ссылку на проект.

     2015/11/03 15:00, Автор сайта

Если Вас интересует проект Уткина, то смотрите «энтузиасты-разработчики компиляторов и их проекты», язык Валентина.

     2016/07/20 16:18, Abah

Можно ли отказаться от текста при программировании? Ха-ха 3 раза!!!

За полвека знакомства и практики программирования неоднократно размышлял на эту тему, пока не пришёл к окончательному выводу: текст — самое главное, что есть в программе. Когда исследуешь чужой код, прекрасно видишь "дерево", но без названий операций, за которыми подчас скрыты десятки и сотни команд, зачастую неясна суть действий. Неоднократно сталкивался с ситуацией, когда коллеги, пытаясь скрыть свои "ноу-хау" от своих конкурентов, просто называли (меняя слова в простом текстовом редакторе) функции абстрактными названиями типа f1, f2, f3..., а переменные брались как элементы массива.

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

Как сказал мне старший коллега: "Программы пишут не только для работы. Их, в основном, пишут для чтения". Программа должна описывать общую идею, концепцию своей работы, постепенно переходя к описанию более мелких элементов и частностей. Броуди в книге "Способ мышления Форт" отмечал, что последовательности слов, использованных программистом, должны полноценно рассказывать о сути выполняемых действий. А "дерево" нужно только для того, чтобы никто ни в чём не разобрался.

     2018/05/25 01:12, Александр Коновалов aka Маздайщик

Хороший пример программирования без текста как линейной последовательности знаков — математические пакеты Mathcad и SMath Studio. В них при помощи графического интерфейса вводятся математические формулы и операторы языка программирования (if, for, while).

Кладём на страницу while — у конструкции два незаполненных слота: условие и тело. Заполняем и всё работает. К слову, писать программы в них можно не только тыкая мышкой, на большинство конструкций есть горячие клавиши.

Модель вычислений декларативная как в Excel. Меняем значение переменной в начале листа и вся страница пересчитывается.

Несколько характерных примеров (из онлайн-версии SMath Studio):

https://ru.smath.info/cloud/sheet/sSc6ByPoeY
https://ru.smath.info/cloud/sheet/v5uguRZyxP
https://ru.smath.info/cloud/sheet/LrzrXbGzGw
https://ru.smath.info/cloud/sheet/XZ4aMbFZ8x
https://ru.smath.info/cloud/sheet/3Zzs5Pkava
https://ru.smath.info/cloud/sheet/KDvKK3HPUk

В общем, такая технология уже давно существует.

     2018/05/25 23:26, Автор сайта

Существует, сомнений нет. Сомнения в том, что нужно ли отказываться от текста? Владислав Джавадов в своём «Канторе» предполагает, что должны существовать взаимно обратимые преобразования из текста во внутреннее представление и наоборот, т. н. «отекстовка». Так что варианты есть.

     2018/05/27 16:30, Александр Коновалов aka Маздайщик

Документы Mathcad’а сохраняются в XML, так что в некотором смысле это тоже текст:-). Но, понятно, речь не об этом.

В принципе, никто не мешает сделать для любого обычного текстового языка программирования среду разработки в духе Mathcad. Например, для Си горячей клавишей вводится оператор while вида
while (•) {

}
где знаками • я обозначил места для ввода текста (placeholder’ы). Среда не позволит, допустим, стереть букву i в слове while просто потому, что курсор в это место физически нельзя подставить (а можно только в placeholder). Но сохраняться файл будет в обычный текст на Си.

     2018/05/27 23:40, Автор сайта

Если основным способом хранения программы будет внутреннее представление в двоичном виде, то как это разместить на github? Это интересный вопрос.

     2018/05/27 23:41, Александр Коновалов aka Маздайщик

git clone https://github.com/%USERNAME%/%PROJECTNAME%
cd %PROJECTNAME%
git add file.jpg
git commit -m "Добавлена картинка"
git push

mspaint file.jpg

git add file.jpg
git commit -m "Обновлена картинка"
git push

Проблема хранения двоичных файлов — команда git diff (или её аналоги в GUI/web-мордах) не может, как правило, показать разницу. Хотя, например, git diff для PDF-ок с текстом или .doc/.docx файлов что-то показать пытается — как-то извлекает текст и показывает на нём отличия. Но как патч это уже использовать нельзя.

     2018/11/18 15:18, Freeman

Текст будет служить правдой до тех пор, пока не появится адекватная абстракция двоичных интерфейсов. Например, из предлагаемой теории объектно-ориентированной ОС следует:
  • Объектно-ориентированная ОС абстрагирует двоичные интерфейсы и контейнеры так же, как концепция UNIX абстрагирует текстовый ввод-вывод и консоль.
  • Нефрактальность исходных текстов естественным образом препятствует выращиванию фрактала, то есть реализации объектно-ориентированной ОС.
Поэтому язык Кантор, предназначающийся для разработки объектно-ориентированной ОС, реализуется на основе двоичного представления (БД, модели) кода, с идеей вторичности исходников.

Если основным способом хранения программы будет внутреннее представление в двоичном виде, то как это разместить на github? Это интересный вопрос.

Вопрос будет прорабатываться в теме пакетного менеджера Кантора (http://forum.cantorsys.com/viewtopic.php?id=27) и на одноименной лекции.

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

Написать автору можно на электронную почту 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 Маздайщик
✎ О русском языке в программировании