Каким должен быть язык программирования? Анализ и критика Описание языка Компилятор
Отечественные разработки 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 файлов что-то показать пытается — как-то извлекает текст и показывает на нём отличия. Но как патч это уже использовать нельзя.

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

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

Авторизация

Регистрация

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

Карта сайта


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Комментарии

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

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

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

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

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

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

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

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

Циклы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Компилятор

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

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

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

Прочее

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

2018/10/11 22:29, Автор сайта
Формула расчета точности для умножения

2018/10/08 14:00, Неслучайный читатель
Сколько проходов должно быть у транслятора?

2018/10/06 12:19, Автор сайта
Тексто-графическое представление программы

2018/10/04 17:39, Автор сайта
Об исключенных командах или за что «списали» инструкцию INTO?

2018/09/29 16:52, Автор сайта
Как отличить унарный минус от бинарного

2018/09/22 20:13, Д.Ю.Караваев
Идеальный транслятор

2018/09/22 12:32, Автор сайта
Типы в инженерных задачах

2018/09/22 12:20, Д.Ю.Караваев
О русском языке в программировании