gudleifr писал(а):
Т.е. слово "архитектура" заменили на "планирование"? И не возразишь... Капитан Очевидность, однако. А если теперь спросить: что есть планирование в FORTH? И каким оно должно быть? И не стоит ли планировать не только FORTH-программу, но и саму FORTH-систему?
Естественно, стоит. Характеристики форт-системы должны отвечать требованиям тех программ, которые потом на ней будут писаться, а не быть коллекцией популярных программных технологий или результатом следования пути наименьшего сопротивления.
gudleifr писал(а):
Еще один Капитан Очевидность. А я что говорил? Для простых программ - тестов дофига (хотя это ни от чего не спасает), а для сложных - тесты, это чисто "наработка на отказ".
Тесты и не обязаны от чего-то спасать. Просто без тестов точно будет плохо. Кроме собственно кодировщиков, уже окончательно устоялось понятие Quality Assurance, и это другой специалист, а не просто деятельность, которую программист может позволить себе эпизодически и от широты души.
gudleifr писал(а):
Наоборот, имеем чисто экстенсивное развитие. Более умное железо позволяет писать более глупые программы.
Вобщем-то WiFi от модема отличается настолько сильно, что говорить о следовании требованиям программистов там просто нереально. Модем не масштабируется на скорости, которые достигаются в WiFi - медный телефонный провод не обеспечит десятки мегабит в секунду. Виды модуляции, frequency hopping, управление пакетами - все это в современных коммуникационных протоколах отнюдь не представляет собой экстенсивное развитие модема. Во многих технологиях ситуация обстоит точно так же, просто для того, чтобы удержать уровень сложности для разработчиков, образуется новая прослойка. Не так уж случайна высокая популярность преобразователей USB-serial. Да, там скорость ограничена 962 кбит/с, хотя USB как интерфейс может обеспечить и больше. Вот только сложность полнофункционального драйвера USB, который работает с этими пакетами, а не с сервисом, предоставляемым готовым драйвером USB-UART, существенно выше. Точно так же, если влезть с программой глубоко внутрь современной читалки, там "внезапно" обнаружится масса устройств, которые постоянно чего-то требуют
У контроллера USB нет регистра, из которого можно вот просто так прочитать содержимое файла на внешней флешке. Зато у этого контроллера по стандарту есть действия типа "послать сигнал awake, потому что внешнее устройство проявило активность". Поэтому при попытке заняться низкоуровневой программной поддержкой современного железа очень быстро вспомнится поговорка "не до жиру, быть бы живу".
gudleifr писал(а):
Я же говорю, привыкшему к глюкам компьютерщику это кажется нормальным. Ну, подумаешь, запомнить в какой момент жать... А для нормального человека - дикость. (Я тоже покупаю своим родственникам PocketBook-и).
Я понимаю причины, по которым появляется такая продукция, но это не означает, что я согласен с тем, что так и надо продолжать.
gudleifr писал(а):
Вспомните какой-нибудь свой сложный программный продукт. Где-то в середине наступает момент[ы], когда надо выбрасывать прототипы. И вот тут возникает вопрос: выбрасывать только лексиконы, или заодно и сам FORTH.
Это естественный процесс. Существует "жизненный цикл быстрого прототипирования", существует итеративный подход. Первая версия в рамках этих подходов специально и создается для выяснения наиболее принципиальных моментов, с пониманием того, что потом ее надо выбрасывать. Вот и надо заранее определить, выбрасывать ли и Форт тоже. Если задачей является пересмотр Форта, то он сам по себе продукт, подлежащий разработке. В рамках данного подхода его надо выбросить и переписать заново с учетом выявленных проблем. Но совершенно не стоит бросать все в одну кучу. В Форте ли проблема? Можно отложить ее решение, пойдя на "штрафной круг" переписывания инструментария... и надеясь, что проблема сама как-то рассосется, или же новая версия решит ее волшебным способом.
gudleifr писал(а):
Например, когда я начал писать Win-FOBOS, я взял Win32Forth и начал честно на нем экспериментировать с WIN-API. Когда понял идею, выкинул все написанное и написал g2.asm, в который вошло только то, что было нужно для работы (например, там были слова для вызова WIN-API и реализации конечных автоматов, но не было слова для умножения). Дописав почти до конца, понял, что можно сделать лучше. Переделал лексиконы - g8.txt. К этому времени созрела идея вторичной машины и собираюсь опять переделать g8.asm... Конечно, мой проект очень прост, но по количеству мусора, ушедшему из лексиконов первой версии просто в силу "оптимизации ядра", я оцениваю уровень сложности, которого смогу достичь в итоге, достаточно оптимистически...
В таких случаях удобно писать сценарии использования (включая фрагменты программ, которые желательно потом запускать), по сценариям выписать спецификацию. Там уже и решить, нужно ли обязательно делать умножение и все прочее (а то потом от сложных вещей захочется отказаться с формулировкой "да ну, и так сойдет", а через пару месяцев выяснится, что пользоваться полученной программой и незачем). К спецификации, опять же, тесты. По всему проекту контрольные точки ("надо добиться того, чтобы Форт умел выводить на экран числа от 0 до 10 в цикле"). Метрические характеристики (графика со скоростью 0,1 FPS - полный провал, продолжать бессмысленно).