gudleifr писал(а):
Мур, в случае с Forth, не сторонний наблюдатель, а "производитель микроволновки, настоятельно не рекомендующий сушить в ней домашних животных".
Мур создал прецедент разработки форт-системы, на основании которого можно разрабатывать программы подобного класса. В этом смысле его вклад неоспорим - просто по факту того, что другие люди пишут другие форт-системы. Но вот как архитектор ПО, способный в широком диапазоне условий посоветовать стиль разработки, типы инструментов, подходы к тестированию и отладке, Мур как-то не особо известен. Это не недостаток Мура (так ему можно вменить в вину и то, что он пирожками не торгует), а пометка, что, выбирая Форт в качестве языка, мы выбираем именно Форт, и не получаем автоматически все бонусы, которые когда-либо были у каждого из фортеров. Мур пишет код "по месту"? Замечательно. Мы тоже можем. Главное, помнить, что в определенных случаях можно сорваться в штопор и начать ставить заплатки, а глубокий пересмотр архитектуры и делать лень, и времени уже нет.
gudleifr писал(а):
В данном случае термин "позже" не подходит. Задача уже имеет статус обязательной к решению. Тем более, что по мнению начальства она, обычно, должна быть решена за неделю до того, как проект был начат.
Тактические задачи решает и сам программист. Тем более что в ТЗ не написано, что вот на этот алгоритм желательно иметь пакет тестов, а к пакету - генератор тестовых последовательностей. Это все проблемы коллектива, а система должна просто работать. И тут уже выбор программиста, проверит ли он свой модуль в комфортных условиях, или будет это делать при испытаниях, пытаясь доказать, что это не случай, который он забыл предусмотреть, а проблема оборудования или другого программного модуля.
В случае с Фортом, пишущимся при наличии опыта программирования на другом языке, ситуация склоняется к п.2. Обычно человек, поработав хотя бы несколько лет, уже накопил достаточный опыт наблюдения вещей, "вероятность которых пренебрежимо мала". С другой стороны, широко распространенные алгоритмы скорее всего будут им рано или поздно реализованы. Поэтому имеет смысл сосредоточиться на разработке прототипа "Perl-Forth", который при первых итерациях уже позволил бы оценить, во что это вообще выльется. Например, что у такой системы будет со стеком? А стек на разных платформах? Может быть, там придется писать просто разные реализации, и ничего общего у них быть не может. Тогда нужен и комплект тестов, который немедленно и не нужен, а потом на какой-нибудь платформе вылезет неприятный эффект с underflow, разваливающим всю систему целиком. Как-то не хочется от безобидного лишнего DROP получать не сообщение об ошибке, а намертво повисший ARM (я не знаю, как такое возможно,
но хочу быть уверенным, что этого не будет). Опять же, что с парсером на Perl, позволит ли он написать более качественный (быстрый? модифицируемый? сопровождаемый? компактный?) код? Если все это отложить "по месту", есть высокий риск погрязнуть в решении текущих вопросов, не выяснив ключевые, которые потом рванут.