Еще раз посмотрим на Форт со стороны подхода к программированию. Я не пишу такие неоднозначно понимаемые термины, как "метод", "методология" (и уж тем более "парадигма" или "философия"). Это создает атмосферу чего-то возвышенного, а нужно как раз окунуться в практику.

Итак, сравним два стиля кода.

Теперь второй стиль:


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

Получился Форт. Написанный на <любимом языке>, но тем не менее внутри отражающий общие подходы к реализации Форт-машины.

Что это дает? Теперь можно попробовать не рассматривать Форт как язык программирования в общепринятом смысле и, соответственно, искать у него библиотеки, IDE, пресловутую "поддержку из коробки" и прочее. Ясно же, что этого нет, а усилия по реализации в итоге приведут только к тому, что будет "как у всех". Вместо этого стоит попробовать поставить Форт в один ряд с такими понятиями, как алгоритм суммирования элементов массива, сортировки пузырьком, или программу рисования графиков. Тогда вопрос будет не "программируем ли мы на Форте?", а "используются ли фортоподобные алгоритмы при построении программного приложения?".

Может не в тему топика
такой комментарий
одного разработчика встраивающего Форт в свои корпоративные проекты.

P.S. Автоперевод вопроса https://coderoad.ru/11745658/Как-бы-можно-было-закодировать-приложение-в-Forth-или-Factor

Что тогда относить к фортоподобным алгоритмам? Конкатенативную компиляцию и поиск по словарю или последовательность простых функций (процедур?), работающих с глобальными данными? И насколько данный подход применим за пределами собственно Форта (с постфиксной записью и стеками)? Понятно, что искусственно можно реализовать приведённый пример, но применяется ли такое на практике?

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

"Неожиданно", топик обсуждения Форт на zx-pk.ru (05.07.2022)
FORTH vs компилятор бейсика vs C++/Pascal/остальное

P.S. Из развиваемых проектов Форт для Z80 M4 FORTH: A Forth compiler for the Z80 CPU and ZX Spectrum
и много Z80 Форт и для ZX programandala-net

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

Думаю, очень многие ломали головы что же такое Forth, какое положение он занимает в привязанности к машинному коду и т.д.
В целом, на Forth можно смотреть с разных точек зрения, поэтому можно предположить, что это скорее набор принципов.
Не ясно можно ли назвать это парадигмой, ведь в Forth-системах применяется стеково-ориентированное программирование или, например, контекстно-ориентированное программирование [1].
Да что вообще можно сказать про Forth? Есть ли у него синтаксис? Ответ: нету Весь код, кроме метаданных, состоит из названий определений.
Помимо этого, Forth явных типов данных не имеет. Т.е. смысл определений и их названия определяют как и что на этом языке можно писать.
Можно сказать, что Forth это подход по созданию метаязыка. А стек оказался лишь более удобным способом работы с данными в таких языках.
А какой это будет язык, на чём написан и какие решения будут использованы для разработки – решать разработчикам.
В итоге, получается, что многие Forth-системы, это лишь диалекты базового языка, что предлагают нам стандарты.

[1] Контекстно-ориентированное программирование

Заметка о языке :Firth сделанного в рамках Lua.
:Firth pre-alpha 1– a Forth-like language for DSL creation.

P.S. Тут, ещё подумалось, что можно использовать отдельно библиотеку LibJit
для повышения производительности Форт программ при стековом байт коде VM (может и для МК может сработать при наличии ресурсов в необходимой мере)
Библиотека нормально собралась и отработала тесты под Linux 32 (правда не последняя её версия)
В примере библиотеки "скриптовый" Паскаль Dpas с выполнением кода во время загрузки его с исходника.
На Github есть некоторое количество отдельных языков в привязкe к этой библиотеке.

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

https://ru.bmstu.wiki/LibJIT
...