Если бы это было преимуществом, то неизбежно было бы масоовое использование форта.
м ы видим противоположное
На самом деле имеет место другая закономерность и другая последовательность причин

форт используется как-раз как способ сделать разработку более удобной субьективно

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

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

Да, получается, что это не преимущество. И, еще раз, да, дело не в языке, а в психологии.

Есть и на Форте: http://tracker.coreboot.org/trac/openfirmware/browser
еще http://tunes.org/wiki/forth_20oses.html
Не важно на чем написана ОС. Главное, чтобы эта была ФотрОС.

Не курить и бегать по утрам - это преимущество. Но курят достаточно много людей, а бегают по утрам отнюдь не все некурящие.

Хищнику, который индивидуалистом не является, легко рассуждать

У меня нет никакого доброго дяди, который спонсирует мое программирование на Форте. Поэтому сначала был именно индивидуализм, который через стадию "ух ты, а как это у тебя так получается?" перешел в "не знаем, мы работаем с форт-технологиями и нам нравится".

Я так понимаю - цель "заговорить" тему "сверху-вниз"
и всё получится:)

Поскольку это нетипично ...
то урок отсюда извлечь никак не получается. То есть - это особенность лично Хищника и никого более, так зачем на это ориентироваться?

Получение результата после целенаправленной работы - это типично. Особенно с учетом того, что несколько человек на протяжении последних ~10 лет так или иначе осваивали разработку форт-машин с моей подачи. Поэтому мне и забавны рассуждения о том, что Форт нельзя развить в одиночку. Базовые функции - 2-3 тыс. строк на Си, более или менее развитый транслятор - 5-6 тыс. Неподъемно? Даже с учетом того, что это не бросок в никуда с закрытыми глазами, а работа с вполне прогнозируемыми результатами?

Значит уже не "просто писать" или "индивидуализм", а "целенаправленно" ... это не просто разные вещи, а даже противоположные

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

Сначала еще раз соглашусь с коллегой вопрос в том, что сложность задачи очень часто проблема не задачи, но программиста. Например, мой "MD с человеческим лицом". Сначала реализовывал на Win32Forth. Долго реализовывал, с месяц или два (здесь и далее читай "с перерывом на работу), т.к. постоянно лазал в MSDN. Дошел почти до конца и встал перед вопросом: изучать целевой компилятор Win32Forth или написать новую версию FOBOS? Думал долго, но, наконец, вспомнил о своей идее-фикс организовать хранилище кода на своей страничке в Сети. На этот раз пошло быстрее - недели две, и опять - почти до конца. С тех пор прошло уже два года - переписал уже раза три, "философских" заметок наплодил... Но красиво не получается. Была бы конкретная задача, заткнул бы дыры и сдал, но хочется именно красиво. В смысле - интуитивно и конструктивно... Вот так и рождаются "сложные" задачи... Конец лирического отступления.
Итак, новый сложный проект "Академический Forth". И его разработка сверху-вниз. (Сложный только потому, что я подхожу к нему, как к сложному).
Шаг 0. Постановка задачи.
Прежде всего, попытаюсь сформулировать отличия Fort от других систем программирования. Это, отнюдь, не польская запись (если уж на то пошло, запись оператора присваивания через "равно" и вызова функции в виде "имя-список", как противоречащие нашей математической интуиции, дорогу себе пробивали достаточно долго). Это:
1) Совмещение в одном потоке исполнения-компиляции. Все языки (и даже интерпретаторы) стараются разнеси эти два состояния как можно дальше. Исключение составляет, разве что Python, в котором "компиляция" может возникать без ведома пользователя и порождать кучу побочных эффектов. Но, как и злоупотребления методами "компиляции" в конструкторах-деструкторах языков ООП, этим "можно начать пользоваться только за неделю до увольнения".
2) Неопределенность слов "здесь и сейчас". Возьмем, например, слово "запятая". Все очевидно, берем число и фигачим в словарь. Но это только кажется. Во первых, в случае, например, целевой компиляции так это слово определено по-другому даже в словаре CONTEXT . В словаре CURRENT это же слово определено (или будет определено) совершенно по-другому (в терминах целевой машины). Более того, описывая на языке Forth ситуацию, до того, как создан первый Forth мы, безусловно, столкнемся с ситуацией, когда "запятая" еще вообще не определена (описывается словами программиста и каким-нибудь ассемблерным макросом).
В уже готовом Forth слова, порожденные использованием хитростей (1) и (2) тоже бывают вполне полезны. Слово-замыкание DOER , например, семантика которого может быть определена только в момент исполнения. Или гипотетическое слово-макрос, которое имеет разные семантики не исполнения, но компиляции. Правда, многие фортеры таких слов не любят, но раз эти хитрости нам полезны в процессе написания своего Forth, то почему мы должны отказываться от них после его написания?
Выход мне видится в заведомо контекстной зависимости всех слов: в слое объяснения - текст, в слое ассемблера - код, в слое словаря - шитый код... (Идея коллеги mOleg о совершенной разнотипности словарей нам, похоже пригодится). Вот только "слой" в отличие от других языков будет определятся не синтаксическим контекстом, а явным переключателем (интерпретатора или самого слова).
...
Я не заврался? Можно ли это описать формально?

Я не думаю, что дело в том, что каждый из беседующих ... как бы помягче - уклоняется от продуктивной работы. Я хотел бы видеть у кого-то такую работоспособность, как у Михаила и такой объём форт-кода (непрокомментированного, кстати, что говорит о работоспособности и организованности)
gudleifr тоже представил проект, прежде чем приступить к обсуждению

Что такое сверху-вниз
Большинству известна цепочка:
точка - прямая - плоскость - пространство.
Предположим нам эта цепочка неизвестна, тогда
если мы начнем уточнять в таком порядке:
пространство
плоскость
прямая
точка,
то это и будет сверху-вниз. Это без полутонов, грубо.
На самом деле этот подход используется в форте гораздо чаще, чем в мэйнстрим-языках.
Тут не имеет значения, что мы определяем сначала элементарные понятия, например на ассемблере, потом более сложные на основе этих элементарных и т.д. Главное здесь это именно создание нового понятия,
которое возникает при прокрутке задачи в голове, и вобще говоря, не зависит от языка, на котором мы пишем программу. Потом, да, мы его привязываем к языку.
Форт, в этом смысле, это не язык. Да, он для своих нужд имеет кое-какой функционал, в виде набора элементарных процедур и набора элементарных структур данных.
Но, чтобы решать более-менее реальные(сложные) задачи, нужно написать язык для решения этих задач. Этот язык неправильно называть фортом. Он может быть чем угодно, но это не форт.
На только базовом минимуме форта(собственно это есть форт) особо ничего не напишешь.

А нельзя было об этом вспомнить на первой странице темы? Как бы проехали.