... Об интерпретаторе и компиляторе ФБП



Posted by Рустем Мухаметшин on February 06, 1999 at 07:21:54:

    После некоторого перерыва хочу вновь вернуться к теме развития внутренненго языка.
    Сначала зайду с хвоста :). Ну чтож, недавнее развитие конструкций языка вызвало живой отклик у масс (по крайней мере активных) дилеров. Начиная с того что писать по старому уже не хочется и кончая тем что Ананатолий Анимица переработал полностью свою настройку. Говорю я это к тому чтобы поставить точку на сображениях следующего рода: "Нам и так хорошо, можно писать на том что есть, язык самодостаточен, улучшение конструкций языка ничего не даст в смысле возможностей языка". Конечно, это так. Но как мне кажеться дело не в абстрактной достаточности машины Тьюринга. Нам нужен в первую очередь ТЕХНОЛОГИЧНЫЙ инструмент. Вот что я вкладываю в это понятие применительно к внутреннему языку ФБП:

- Возможность быстро писать несложный код
- Читабельность кода
- Возможность гибко пользоваться библиотеками готовых решений

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

    Остановлюсь на третьем пункте. Сейчас есть возможность собирать подпрограммы форм в FIRST.RPT. Я думаю, все этим пользуются и нелишне отметить необходимость общего модуля для всей системы (и для ф/к).
    Теперь давайте рассмотрим проблемы переносимости кода. Пусть имеются паралельные две оригинальные (в смысле не типовые) настройки. В существующей технологии переносить код общего характера разработанный для одной системы в другую не так то просто.
1) Здесь, я хочу отметить, в первую очередь, двубуквенность переменных. Даже небольшое отличие в названии 2-х буквенных переменных в разных системах делает много мороки при переносе кода между ними. С другой стороны, даже в ситуации отсутствия локальных контекстов переменных скольнибудь разумное имя могло обезопасить перекрытие с другими переменными в обоих системах. Двубуквенность коегде заложена в ФБП на синтаксическом уровне. Кстати, давно хотел узнать: "Для чего имя переменной из ветви вопроса прописывается в операции журнала? Соответсвенно, в дереве нельзя сменить ее имя не трогая по существу ветвь дерева." Пусть там останется это ограничение если уж в этом главная проблема.
2) Ну и, я думаю, назревает необходимость операторов препроцессора  #include ".\subr\subr1.rpt", да и о других стоит подумать (#define, #ifdef, ...)

    Итого вернемся к началу, небольшое и дешёвое :)))* изменение может дать существенный толчок в развитии системы. (* Конечно все надо делать. Но в некоторых случаях день Вашей работы, Аркадий, стоит в конце концов многих человеко-дней работы дилеров)

... (продолжение, начало см. 521, 522, 523)



Пpишедшие ответы: