AM>> В современном компьютерном мире существуют два подхода к вопросу: AM>> 1. Программа должна уметь делать все необходимое для выдачи AM>> требуемого результата. Под каждую задачу разрабатывается своя AM>> программа, пользователю остаётся только ее запустить и ввести в AM>> нее исходные данные. SM> Например, годед. ;) AM>> 2. (стиль *никс) программа должна выполнять какую то небольшую AM>> часть задачи (желательно не конкретной задачи, а некий AM>> универсальный фрагмент). В системе должна иметься туева хуча AM>> таких маленьких программок, которые пользователь скриптом AM>> связывает в решатель нужной ему задачи. SM> Например, Фидошный узел? ;)
У меня на узле стояли только Радиус и Партосс - и этого было достаточно
AM>> PS: И тут я с ужасом представил Автокад в стиле юникс - одна AM>> программа вычисляет координаты, другая рисует линии, третья - AM>> окружности, четвертая заполняет область штриховкой, пятая AM>> расставляет блоки, шестая вставляет тексты, седьмая вставляет AM>> растры, восьмая из всего этого генерирует pdf... A инженер бешено AM>> стучит по клаве, связывая это все в скрипт, который сделает AM>> нужный ему чертеж ;) SM> А на самом деле это много програм связанных между собой оболчкой.
Если считать отдельными программами dll - то да. Но это меня, как пользователя, не напрягает - главное, что мне самому не надо быть оболочкой - можно думать о чертеже, а не о том, какую программу для выполнени очередной операции запустить и какие данные ей передать.
-- Best regards! Posted using Hotdoged on Android --- Hotdoged/2.13.5/Android * Origin: Yet another Android node on Redmi Note 10 (2:469/335)
