Часто поднимаемой проблемой Форта выступает его поддержка чего-либо - обычно GUI, но встречаются упоминания web, сетей, БД, и т.п. В основном в связи с этим ставится задача доработки Форта до такого состояния, чтобы эти возможности появились как результат реализации соответствующих библиотек для какой-то Форт-системы. В своем крайнем варианте такой подход выливается в проект Форт-ОС, под которой понимается программный комплекс, целиком написанный на Форте, использующий для внутреннего взаимодействия присущие Форту механизмы, и том числе позволяющий пользователю в эти механизмы вмешиваться. На протяжении уже очень долгого времени (со времен FIDO, не говоря уже о времени существования форума) такой подход систематически показывал свою несостоятельность. В отсутствие:
- явной цели в виде конкретных проектных требований;
- четкого плана реализации и программной архитектуры;
- необходимых ресурсов, включая отлаженное тестирование;
подобные попытки выливались в фрагментарные разработки, которые были по силам индивидуальному разработчику или небольшой группе. На то время, пока у них был интерес и силы.

Что мешало реализации с точки зрения ресурсов? Ориентация на лобовую попытку "сделать как везде, но на Форте". Исходя из этого посыла, в Форте начинали воспроизводиться базовые функции, которые могли быть реализованы на уровне "нарисовать кнопку", или в виде оберток над функциями интерфейса Windows. При этом уровень управления приложением обычно не бывал достигнут - в качестве примера такого уровня можно привести Delphi-подобные продукты, которые самостоятельно организовывали обработку сообщений и управление набором виджетов. В итоге можно было видеть Форт-приложения, внутри которых было необходимо использовать цикл GetMessage() TranslateMessage() DispatchMessage(), самостоятельно выполняя привязку виджетов к кодам событий, а коды событий - к обработчикам. Собственно, вполне рутинный характер такого распределения кода по исходным текстам способствовал его автоматизации в Delphi, где программисту было достаточно написать обработчик событий вида "нажата кнопка".

Если пойти с другой стороны, на современном уровне уже можно увидеть "шаблон проектирования Интерпретатор". Под этим шаблоном понимается встраивание интерпретатора в большую программную систему для управления ее работой. Формально его описание можно найти, как и полагается, в самой известной справочной системе (другое дело, что там оно недостаточно обстоятельно разъяснено):

https://ru.wikipedia.org/wiki/%D0%98%D0%BD%D1%82%D0%B5%D1%80%D0%BF%D1%80%D0%B5%D1%82%D0%B0%D1%82%D0%BE%D1%80_(%D1%88%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F)

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

Отсюда такой вариант - в качестве интерпретатора берется Форт, который сразу добавляет возможности JIT-компиляции. Его назначением является не замена программы на нижнем уровне, а работа "сверху". Например, вместо рисования кнопки Форт взаимодействует с такими методами, как изменение размера и положения, надписи, цвета и т.д. Т.е., если у кнопки есть функция вида MyButton->setRect(x, y, w, h) , то вместо задания координат в compile-time можно организовать взятие их со стека. Тогда слово Форта будет выглядеть так:



В данном случае неразборчивость Форта относительно символов внутри имени позволяет использовать вот такую мимикрию под ООП.

Продолжая эту линию, можно и при работе с СУБД, WiFi, USB и прочими популярными технологиями брать за основу готовые программные продукты, в которых основные функции уже реализованы, и определять слова Форта, которые могли бы задавать регулярно изменяемые (а не все) параметры их работы. У такого подхода появляется практическая польза - длительные циклы компиляции для коррекции малозначимых деталей часто можно заменить подбором параметров из командной строки.

Т. е. берём условный GTK подключаем к среде и рулим из форта? Правильно понял?

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

Я тут наткнулся на VfxForth. У него есть слова и для работы со сторонними библиотеками и для плавающей точки. Подойдет?

Старая вещь, представляющая собой пример "телеги с реактивным двигателем". Та самая ситуация, которую я уже описывал - вместо пересмотра архитектуры взаимодействия форт-машины с приложением пишется еще одно окно, которое умеет только интерпретировать команды Форта. Соответственно, все, что сможет делать такое приложение, определится набором определенных на Форте слов, что дает непомерный объем требуемого для разработки кода. Пришли в тупик. Там, где в Python, C++ и прочих языках top-10 работают крупные компании и сообщества разработчиков-пользователей, в мире Форта пытаются казаться серьезными и повторяют то же поведение в совершенно неподходящих условиях.

Вот буквально вчера - исписали карандашом пару листов, формулы, примерные графики. 30 строк на Irbis - графики готовы, влияние параметров визуализировано, все понятно, можно работать. Это с учетом того, что на экране окно, в нем TChart, есть консоль и т.д. Альтернатива для spf или Vx - надо создавать компонент, модифицировать wm_paint, а внутри него пересчитывать точки графика в экранные координаты... это такой интересный пример "мощи Форта"? Суть и польза от конкретной работы не в том, что "на экране окно", а в содержимом этого окна. Ну и пусть Форт помогает формировать содержимое, а отрисовку окна, виджетов и обработку событий можно оставить базовой системе на основе C++ и компании.

Видать я совсем тупой, поскольку не понял - а что, в современной архитектуре нет понятия пользовательского экранного интерфейса? Или в современных программах исполняются слова, которые там не прописаны?


И опять я ничего не понял. На Vx нельзя написать слово, которое будет "модифицировать wm_paint, а внутри него пересчитывать точки графика в экранные координаты"? Что, из описанного Вами, в качестве примера, нельзя реализовать на Vx?


И опять я ничего не понял. Что С++ программа сама отрисовывает окна или таки передает параметры GUI? К слову, а Vx вроде как и многозадачность поддерживает. По крайней мере в документации слово Multitasker есть.

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


Ну так пускай они напишут внутри Vfx такой механизм, который будет позволять передавать координаты точки на графике. А если "тут тоже можно", то мы отправляемся в конец 90-х.

Вот подходящая ссылка
https://learn.microsoft.com/ru-ru/windows/win32/learnwin32/painting-the-window



Причем это только обработка сообщения об отрисовке окна. В данном случае важен порядок вызова функций. Показан пример на C++. Можно такое же сделать на fasm. Можно, приложив определенные усилия по созданию оберток над функциями и определению констант, сделать такое же на Форте. Ключевой оборот здесь "такое же". Дальше будет все ровным счетом одинаковое - при необходимости что-то изменить мы правим вот этот фрагмент (например, меняем цвет, добавляем линии и кривые, выводим текст), затем компилируем (!) и заново запускаем (!). На С++, fasm или Vfx. Вопрос - и в чем конкретный выигрыш от перехода на Форт? Порядок работы не изменился, по-прежнему надо разбираться в функциях и их параметрах, зато:
1) оно не такое быстрое
2) есть вопросы к полноте реализации.

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

В отличие от этого, можно посмотреть для примера хотя бы вот на это
FillRect(hdc, &ps.rcPaint, (HBRUSH) (COLOR_WINDOW+1));
hdc - это контекст окна, HBRUSH - идентификатор "кисть". Остаются rcpaint - это координаты прямоугольника для заливки (тут они в размер окна) и COLOR_WINDOW - это цвет. Легким движением руки можно переписать эту функцию так, чтобы она и координаты, и цвет забирала со стека. Тогда можно будет из консоли менять размер и цвет прямоугольника, не переписывая всю программу. Если распространить все это дальше, можно оформить основную программу на C++ или C# (MSVS, Qt, GTK, и что угодно еще) так, чтобы основной движок оставался "штатным", но параметры забирались со стека. Тогда мы избавляемся от постоянных перекомпиляций проекта, и заодно уменьшаем количество ошибок, вызванных тем, что при правке параметров случайно попортили логику программы.


А что она там передает? Вот пример - между BeginPaint и EndPaint необходимо вставить вызовы всего, что нужно нарисовать. Вообще всего. Да, оно, в каком-то смысле, "передает параметры GUI", но тут под GUI нужно понимать набор функций вида FillRect и подобных им, а там, к примеру, нет никакого холста (Canvas), который появился только в Delphi-подобных системах и вот он уже позволял "поставить красный пиксел в координатах 100, 100". Причем поставить и забыть, а при обработке wm_paint никакие ранее произведенные действия не учитываются - все состояние экрана необходимо нарисовать заново. Можно ли такое сделать в Vfx? Можно, конечно... как и сотне других систем подобного класса. И зачем они мне такие, если ничего нового относительно самого базового событийного движка Windows они не предоставляют? Вместо этого можно взять фреймворк, который реализует интерфейс уровнем выше и позволяет, например, показать на экране кнопку с надписью Caption в координатах x, y, w, h. Тогда над такой функцией уже полезно сделать форт-обертку, которая снимет все это со стека.

Если бы он ещё переменные-идентификаторы у себя хранил.

Эээ... а зачем? Имеются в виду вызовы в рантайме прямо по его идентификаторам?

Не так, глобально
Например, просто у произвольного label надпись поменять. Вот как сделать, если у себя в форте не сохранил идентификатор элемента?
Насколько помню, GTK не даёт такой роскоши, всё ж придётся городить минимальную обёртку.

В Irbis существенно проще - id элемента это просто его индекс. Т.е. есть MAXLABEL меток, и "123" 4 LABEL.TEXT установит текст 123 метке с номером 4. Если нужен идентификатор, его можно банально Фортом и сделать - 4 CONSTANT idMyLabel.