Конечно противоречит. Это разные подходы.
На уровне базиса языка Форт, в какой то степени близок к 2, а расширения только полностью "верифицированные" и не усложнённые в своих вариантах применения. Даже ограниченных.

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

А есть грани чёткого разделения между ними?
Оставайтесь Дейкстра-ординарным.

Т.е. отсутствие сказуемого в предложении есть признак правильности написанного? Извините.
Это не ко мне, это к терапевту Зингеру.

Рассмотрим простой пример (с запасного форума):

Здесь заведомо есть ошибка - неправильное расположение значений на стеке; но даже для того, чтобы ее найти, надо в лучшем случае рассматривать не только сами слова, но и их стековые комментарии, а в худшем - отслеживать "ход исполнения". Если адрес переменной рассчитывается более сложно или кусок кода между ней и расчетом значения нетривиален, то заметить ошибку гораздо сложнее.
Но, самое интересное здесь, что данный простой! фрагмент содержит в себе еще несколько потенциально опасных моментов:
1. Если значения CURRENT и CONTEXT не совпадают, то вполне вероятно, что вызывается не тот TEST3, который мы только что определили.
2. Поведение THROW может зависеть от охватывающего CATCH.
3. Выделение массива в 2000 байтов требует где-то в дальнейшем проверок, что при заполнении не будет выхода за его пределы. Здесь уместнее применение константы, т.к. нет никакой гарантии, что при правке программы размер массива не поплывет.
Список можно продолжить.

Gudleifr поднимает правильные вопросы. Программы не будут писаться сами, и не может быть волшебного средства, с появлением которого Форт вдруг "резко разовьется" сам по себе. Сейчас для решения мелких проблем существует интерактивный режим, в котором можно вылавливать ошибки, связанные с неправильным помещением на стек, неверным вычислением адреса. Control-flow стек сам следит за целостностью структур управления. Дальше уже идет алгоритмика и ошибки интерфейсов (в неправильном порядке вызваны слова, не проверен результат работы и т.п.).