gudleifr писал(а):
Сейчас, под старость, мне кажется, что эта граница в C-подобных языках - два уровня (по молодости, кажется, была выше)...
Т.е., допустим, я пишу программу строковой обработки и свободно использую string.h (все эти strcpy и strcmp). Я вполне свободно формулирую задачу в терминах этих операций, понимаю, что они делают и какие ловушки есть в их использовании...
Но, опять допустим, я наращиваю третий уровень. Использую написанную программу как библиотеку более высокого уровня. И тут, не знаю как у вас, а у меня уже возникают проблемы: я уже перестаю быть уверен, что набор из моих операций, использующих строковые операции, эффективно/правильно делает то, что мне надо. Может проще было прямо вызвать эти самые строковые операции?
Требуется какое-то явное средство доказательства того, что все, что мне нужно правильно "инкапсулировано" на всю глубину вложения. (См., например, Дейкстра "Заметки по структурному программированию").
Вопрос вызова функций - это вопрос тактический. Рано или поздно это отлаживается. Вплоть до определенного размера программы (скажем, 10 тыс. строк) можно не предпринимать специальных усилий по проработке архитектуры.
За этим уровнем (примерно до 50 тыс. строк) проект обычно оказывается настолько сложным, что неминуемо требует сторонних модулей, библиотек, интеграции с другим ПО. Здесь могут потребоваться соглашения о межмодульных интерфейсах, управление пространством имен и какие-то механизмы управления ресурсами. Например, все любят имена переменных X и Y. В Форте легко можно иметь их в нескольких последовательно подключаемых модулях, причем внутри модулей все скомпилируется правильно, а в режиме интерпретации будет видно совсем не то, что ожидается. В данном случае проблема все еще решается вынесением части функционала в отдельный словарь (скрываем из области видимости) и да, заведением вспомогательных интерпретаторов, возможно, совместно с DSL.
Больше 50 тыс. строк мне трудно оценивать трудоемкость и проблемы. Отмечают трудности с интеграцией, масштабированием (обработка массива в 4 кб явно отличается от обработки массива в 4 Тб), эффективность кодирования отступает на второй план по сравнению с эффективностью связей между участниками проекта. Видимо, на этом уровне Форт, концентрирующий усилия на DSL и гибком управлении параметрами кода, уже не имеет такой привлекательности, как любой инструмент, обеспечивающий сборку мусора, управление версиями и интеграционное тестирование.
gudleifr писал(а):
Хищник писал(а):
Если теперь надо архивировать файл, и на входе параметр - имя архивируемого файла, то интерактивности в целом и нет.
Как бы, это только кажется.
Например, помню когда писал для себя последнюю gif-библиотеку, интерактивность потребовалась дважды:
Я не имел в виду, что для архиватора не надо управлять никакими параметрами. Я хотел привести в качестве примера некую задачу, которая достаточно сложна, но при этом стандартна. Поэтому нам интересно просто вызвать ее. В данном случае мы выбираем библиотеку ради функциональности, а остальное (размер, быстродействие), является
приемлемым.
В сложных проектах драйвер вполне может выступить в качестве именно такого кирпичика, изменение которого приведет к малозначимым улучшениям (несущественно с точки зрения задачи, или же узким место является аппаратная часть), однако попытка переписать код связана с риском получить лишь частично работоспособное решение. Однако это не касается ключевых фрагментов кода, относящихся к тому, что, собственно, и является целью проекта.