Хищник писал(а):
Остается предположить, где проходит эта граница, и какие классы программ окажутся ниже. Вполне вероятно, что их будет более чем достаточно.
Сейчас, под старость, мне кажется, что эта граница в C-подобных языках - два уровня (по молодости, кажется, была выше)...
Т.е., допустим, я пишу программу строковой обработки и свободно использую string.h (все эти strcpy и strcmp). Я вполне свободно формулирую задачу в терминах этих операций, понимаю, что они делают и какие ловушки есть в их использовании...
Но, опять допустим, я наращиваю третий уровень. Использую написанную программу как библиотеку более высокого уровня. И тут, не знаю как у вас, а у меня уже возникают проблемы: я уже перестаю быть уверен, что набор из моих операций, использующих строковые операции, эффективно/правильно делает то, что мне надо. Может проще было прямо вызвать эти самые строковые операции?
Требуется какое-то явное средство доказательства того, что все, что мне нужно правильно "инкапсулировано" на всю глубину вложения. (См., например, Дейкстра "Заметки по структурному программированию").
С другой стороны, "разговорный" стиль FORTH-программирования позволяет естественно чуть ли не отвлеченные темы обсуждать. Плавно повышая уровень и перескакивая на лирические отступления...
Да, и метод "проблемно-ориентированного языка" дает возможность строго обосновать требования к "инкапсуляции".
Конечно я видел (не на C++, там обычно ООП-методы используются только в косметических целях, а, особенно, на Python) многоуровневые иерархии "инкапсуляций", но результат был кошмарен: тонны "фантиков", завернутых в другие "фантики". А "конфет" - как текста в глубинах формата docх.
Хищник писал(а):
Если теперь надо архивировать файл, и на входе параметр - имя архивируемого файла, то интерактивности в целом и нет.
Как бы, это только кажется.
Например, помню когда писал для себя последнюю gif-библиотеку, интерактивность потребовалась дважды:
1. Пока я, в очередной раз, вспоминал форматы и алгоритм сжатия, средство выдачи диагностик и статистик, а так же возможность подгонять параметры "на лету" были очень даже потребны.
2. Т.к. речь шла не просто о вытаскивании/засовывании рисунков, а для конкретных целей, то в процессе уточнения/пересмотра этих целей требовалось выдергивать (и запихивать) из GIF-ов разные фрагменты, засовывать их в разные хранилища, вести учет распакованных/запакованных/модифицированных и т.д.
Так что вариант "купил библиотеку и пользуюсь" устраивает только до тех пор, пака вам безразлично, что она делает.
Например, мое знакомство со "стандартными парсерами XML" очень быстро привело к тому, что я отказался и от "стандартных парсеров" и от XML... Себе дороже.
В общем, как писал Мур: конечно бывают полезные библиотеки, но подавляющее большинство нужного тебе "Сделай Сам!".
mOleg писал(а):
Проголосовал за последнее
Спасибо. Зная Вас, это было очевидно. Терминологические сложности.