Хорошо. А какие решения? Что сразу попробуем, на какой простой демонстрационной задаче, или, может быть, на практическом примере с известным решением.

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

P.S. Тут, к примеру, даже на ассемблере кто то делает эмулятор компьютера "Специалист" на Raspberry PI Zero c нуля публикуя дневник разработки на форуме zx-pk.ru

"Каких-то" - это уже слово-паразит, от которого нужно избавляться. Это очередной виток уворачивания от практической деятельности.

Ну и что, теперь сидеть и ждать, пока эти самые "те" откликнутся?

Делает и делает, если нравится человеку, то в чем проблема?

Это нравится, должно ещё совпасть с желанием, умением и возможностью это или что то другое сделать.

Серия уроков.
Автор: Arsen Gonian
Начало решения примеров задач на SP-Forh

P.S. Начальная страница

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

Разве в представленных решениях математических задач на Форт, при использовании и чисто стека без аппарата локальных переменных языка наличествующего в Форт они "значительно" менее понимаемы в его использовании и не лаконичны в своём практицизме чем решения на Python/C/C++?

P.S. Интересно, что вообще в этой тематике (Форт), что кто то создаёт свои сайты при отсутсттвии какой то значимой современной публикумой литературы по Форт и связанными вопросами по его использованию.
Ассемблер в этом плане оказывается даже более презентабельнее чем Форт.

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

А что с ними дальше делать? Программирование не сводится к вычислению формул, написанных на листочке. Обучение языку с помощью вычисления формул полезно прежде всего тем, что результат вычислений может быть проверен независимо. Если программа выдает тот же результат, значит пример получился и язык программирования освоен на уровне записи базовых выражений. Лаконичность и практицизм тут не к месту. Дальше-то пойдут высокоуровневые архитектурные подходы, и оставаться на уровне структурного программирования на стеке уже просто бесполезно.

Нет "cеребрянной пули" и вся эта "высокоуровневость архитектурных подходов" на поверку оказывается конфетной обёрткой
над действительно рабочим и "низкоуровневым" кодом в рамках используемого языка решающего алгоритм требуемой задачи.

P.S. Подтверждение этому - выживемость Си языка, как кому бы ни хотелось увидеть его "смерть"

В том-то и дело, что ее нет. Но вывод отсюда видится другой - как раз высокоуровневые подходы и подлежат изучению. Ну вот добавим мы в Форт : SQR DUP * ; (потому что кто-то обнаружит, что в Форте нет квадрата числа "из коробки" - это выраженьице он вычитал на форумах и начал им щеголять). Но таких слов можно добавить сотни. Дело-то в другом. Если такой Форт будет запускаться в консоли, а для GUI требовать подключения dll вручную (с таким же ручным кодированием GetMessage/TranslateMessage/DispatchMessage), то это и есть вопрос архитектуры. Если же такой Форт вообще не может получать доступ к системным функциям, кроме тех, которые уже скомпилированы в его словах, им вообще невозможно пользоваться за пределами учебных примеров. А, к примеру, многопоточность? Можно придумать для нее слова, но что за ними будет стоять? Эмуляция потоков на уровне адресного интерпретатора? Совсем не то, ожидается-то асинхронная работа нескольких слов, и заодно уж повышение производительности за счет аппаратной многопоточности.


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

Современные варианты Си (скорее уж C++) довольно далеко ушли от Си уровня Borland в практике применения. Что с Visual Studio, что с Qt невозможно работать на той старой базе.

Очень эзотеричская реализация eForth в рамках вычислителя c одной командой (Subleq)
на С, Perl, Python
Subleq eForth

URISC


P.S. В запуске на Perl между вводом Слов и их рeзультатом выполнения у меня на буке проходит от 2-ух секунд.
Cи скомпилированная система выполнения команды -Subleq из поданного ей файла с кодом на вход не тормозит..
Интересен, вероятно, может быть и запуск Siubleq eForth на FPGA или в реализации на ТТЛ логике.

Денис Юричев (известен тем, что делает книгу о Reverse Engineering для начинающих)

Три видео с его канала:
Рассказ о SAT/SMT летом 2021,
часть I
часть 2
часть 3

JIT? в форте Черезова?
А нафига он форте, где нативная компиляция + оптимизатор?
Не, сделать конечно можно, но смысл...

А в чём проблема взять одну из графических обёрток (например, GTK или IUP) и вызывать их функции? Так-то и других языках делают.
Если сильно надо, то можно написать либу поверх них (обёртка поверх обёрток, да).



О помню для ускорения действия программы (дофига запросов к mysql на сервере) я разбил 4 типа запроса по 1 на каждый поток. Производительность сего решения, правда, не высчитывал. Все равно там всё в сеть упиралось.
Тогда ещё на СПФ писал. Потоки были реализованы честно.

В Форте, в принципе, и так JIT, если разобраться. Он не нативной компиляцией интересен, все равно же не дотянет до пиковой производительности. А вот необходимость сначала компилировать, а потом еще и оптимизатор пускать будет уже просто лишним шагом.

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