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

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

P.S. И что тогда в осадке?

Пойти, это вряд ли, но призадуматься смогут:) Но голову
пеплом посыпать не будут. Форт подобен Лиспу и сравнивать
его тоже можно с точки зрения популярности



Уровень комфорта у Форт выше. т.к. работать с ним проще.
Остальное дело наживное, при наличии насущной потребности.



Возможность выбора из двух или больше "зол" .

Форт только может попробовать ускорить целевой код других
языков, но это тоже под вопросом. т.к. нет доступного 100% решения или около того, эффективной компиляции промежуточного Форт кода сделанного, например, тем же LCC Си компилятором.

Все реально. Систем разработок в исходниках - навалом.
Можно их представить в ассемблерном виде с скармить форт-ассемблеру.
Можно форт встроить в систему разработки.


Тело форт-системы (включая все программы, которые в нее загружены)
в качестве библиотеки подпрограмм. Т.е. принцип такой: все на что способна система, все относительно легко предоставляется для построения прикладной программы. Еще отдельный вызов каждой процедуры с заданными параметрами
из командной строки.



Трансляторы могут быть представлены в виде библиотек для Форта
и поставляться вместе с программами, которые они должны воспринять
(или предоставляется ссылка на транслятор для Форта).
Еще вариант: единый формат представления исходных текстов - польская запись.
При этом, все трансляторы должны быть еще и конвертерами в польскую запись.

Готово!

Пока просматривал уже нафлуженное, задался двумя вопросами.
1) Поймал себя на неточности. Написал, что большие Perl/Python программы написаны практически на C++. Но, ведь, все большие программы на C++, которые я видел, написаны практически на C! А все C++ фичи либо носят чисто декоративный характер, либо нужны для интерфейса с визуальными "объектами". (В этом смысле Python, как и Java, более ОО, чем C++). Что же такого заложено в C, что делает его, по сути, единственным языком написания сложных программ? Ведь даже коллеги на полном серьезе обсуждают внедрение C-элементов в Forth.
2) Почему мое утверждение об ориентированности Forth на решение сложных, а не простых, задач вызвало такое возмущение коллег?
Начну со второго вопроса. Ответ прост. Программисты не любят больших задач! Причины понятны, Дейкстра их сформулировал еще 40 лет назад. Быть гениальным творцом чего-то внешне очень заумного, но внутренне очень простого, гораздо почетнее, чем числиться автором чего-то, что еще пяток лет придется доводить до ума. Конечно, есть много начинающих, которые мечтают чем-то большом и светлом (обычно, новой игре), но большинство из них с этой мечтой и остаются. Успешные программисты - жертвы цехового метода обучения, начинавшие с того, что писали свои утилитки и подпрограммки, глядя, как это делает гуру. (Например, по Python я, вообще, не видел серьезных книг). А супер-успешные программисты вообще как начинали с чего-то очень простого и прикладного (например, с FoxBase, позднее - с FoxPro), так с ним и остаются на всю жизнь, обрастая учениками, и втюхивая где-попало свои студенческие наработки на страх окружающим.
С популярностью языка C ситуация схожая. Вернемся к C++, точнее к книге Страуструпа. Тот, обдумывая применение C++ для сложных проектов, как заядлый фортер рассуждал о написании над C++ (на C++) языков, описывающих проблемную область задачи. Но он лукавил. На C++ (а, тем более, на C) невозможно написание чего бы то ни было, отличающегося от них. Синтаксис и логика языка вынужденно остаются теми же. Т.о. наш вывод о нелюбви к сложным задачам усиливается. Программисты еще и не любит создавать (и использовать) новые языки. Даже попадая в новую языковую среду они продолжают пытаться использовать старые парадигмы. Посмотрите, например, как питонисты извращаются, чтобы остаться в рамках, усвоенных при C-программировании. Исключения лишь подтверждают правило, и в каждом "новом" языке от awk до PHP мы видим стремление сохранить С-синтаксис.
Возвращаясь ко второй части флуда, напомню, что программисту свойственно рассуждать о задаче с точки зрения пользователя, а не машины, и поэтому он обычно способен создать язык для рисования окошек, но не покрытия плоскости некоторыми видами мозаик (хотя, это - одно и то же). Поэтому новые языки переполнены атавизмами. Чемпион - Perl, как сборище устаревших решений (хотя и языки ООП не сильно отстают, со своими фантиками, завернутыми в другие фантики, обрезаемыми при компиляции). К таким атавизмам в Forth можно отнести попытки вставить в него элементы C, классы, иероглифы, "стандартные" структуры данных...
Итак, Forth предназначен для работы со сложными задачами путем создания новых языков, но...
1) ... программисты не любят сложных задач;
2) ... программисты боятся новых языков;
3) ... программисты стремятся рассуждать о способе решения (разбиения) задач в терминах пользователя, а не Forth.

Не надо обобщать.
Мне нравятся сложные задачи. Я люблю их решать.
Я постоянно создаю новые языки. Каждый раз при создании новой программы из старых исходников я беру лишь виндовые апи-интерфейсы, старый код стараюсь использовать по минимуму. Так интереснее: можно увидеть разницу в своем подходе к программированию сегодня и например пять лет назад, увидеть положительные и отрицательные стороны, оценить удачные и не очень решения.
Мой способ мышления - Форт. Так задачи решаются эффективнее. А пользователю нужен лишь интерфейс к программе. Он может быть любым.
Может просто этим программистам не хватает квалификации?

Можно сказать больше. Используя логику банальных выводов:)
и Forth используется банальнейшим образом т.к. можно обдумывать задачу в процессе "немедленного" написания кода.
Хорошее решение может быть получено повторным рассмотрением
созданного кода.

Скорее, наоборот. Посмотрите внимательно на свои "сложные" задачи. Так ли уж они сложны? Если они допускают "решение", значит нет. Сложные программистские задачи - это задачи, объединяющие много разноплановых решений. (Кстати, сложной считается задача, которую в одиночку практически не потянуть).Это верно для простых задач. Перефразируя Кнута (под Forth) можно сказать:
1) проход сверху-вниз - разбить на слова;
2) проход снизу-вверх - добавить DUP-ов и SWAP-ов.

Ой-ли? Стек не используется? Созданный лексикон слов
используется отлично от способа, чем в Форте?
Про Форт в новом языке далее забываем?
Нет, тогда, что есть новый язык? Расширение новыми
структурами и парадигмами Форт языка (надстройки ООП,
мат выражения, структуры, регулярные выражения,форматный вывод, работа со строками? и т.д. что
пропущено? элементами из других языков по своему и это уже не Форт?)

P.S. Возможно всё не так как представлено:)

Сложные задачи, обычно, решаются специалистами
в данной преметной области, а программисты лишь
"озвучивают" найденные решения:)

P.S. Программа сложна или нет, если в ней "куча" по
делу и без дела навешенных, вроде простых, фич, требующих n-го и часто немалого времени для реализации?

Вспомнил, что коллега уже выкладывал образцы:Надеюсь, он не обидится.

Пардон, но это бред. Мы все это время говорили о задачах, сложных именно для программирования, а не для объяснения программисту.

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

P.S. Сложно - это долго и муторно и решение выглядит коряво?