Обратная сторона Unix way

Статика — это вообще говно для быдла. И пайпы и юникс-вей тут не при чем. Менять любой кирпичик в рантайме — это ООП в стиле смоллтока. Единственный Ъ-подход в проектировании систем.

Динамика — это вообще говно для малограмотного быдла

/fixed

Для прототипирования самое то.

Для прототипирования самое то.

== «Для программ на выброс, которые не обязаны работать, динамика вполне подходит».

Для программ на выброс, которые не обязаны работать

Индустриальный стандарт, другими словами.

ты опять выходишь на связь? язабан

И всё-таки если пайпы не вносят ощутимых задержек почему бы и не использовать данный подход? 3 компонента, которые можно будет использовать по отдельности с другими программами прямо из голой консоли и вместе они образуют нужный мне функционал. При необходимости прошаренный человек сможет заменить какой-нибудь кирпичик или добавить в эту цепочку свой. Вариантов использования данной модульности много, но так ли быстры пайпы?

пайпы вообще не единственный путь IPC.

А еще можно сделать так, чтоб не было завязки на «скорость пайпов».

Вот давай, например, расскажи что у тебя там за 3 части программы и что ты там хочешь между ними гонять и почему скорость коммуникации может быть критичной?

И всё-таки если пайпы не вносят ощутимых задержек почему бы и не использовать данный подход?

Какой «этот»? Если что, ты отвечаешь на пост об ублюдочности динамической типизации.

так ли быстры пайпы?

Быстры для какой задачи, по сравнению с чем? Ты формулируешь вопросы настолько абстрактно, что для ответа на них придется читать небольшую лекцию.

Нормальную типизацию пока никуда не завезли :(

Какой «этот»? Если что, ты отвечаешь на пост об ублюдочности динамической типизации.

Вот я и хочу узнать причину не использовать модульность. Все хаяют кеды за их громозкость и неповоротливость, а были бы они модульными, то любой ненужный компонент просто бы отключили, а нет - весь функционал одной любой взятой программы монолитен: взять те же activites kwin'а, пользуются этой функцией 2,5 человека, а всё равно находится с стандартном функционале. В итоге и получается кедерастам - кеды, гномосекам - гном, а столько бы независимого можно было бы сделать..

Быстры для какой задачи, по сравнению с чем? Ты формулируешь вопросы настолько абстрактно, что для ответа на них придется читать небольшую лекцию.

Мне конечно не в реальном времени задачи выполнять, но видимых задержек и лишней заметной нагрузки не хотелось бы. Сравниваю я монолитное приложение с использованием stdin и stdout, разбив программу на подпрограммы. Мне нравится идея bash'a: создаем конвеер из маленьких подпрограмм, к этой кучи маленьких инструментов мы может добавить и свои кирпичики. Bash в памяти занимает 3.6МБ, а если свою обертку-конвеер над этими подпрограммами сделать, то может быть и еще меньше будет занимать. Мне близка следующая идея: любой компонент можно заменить или использовать отдельно от моего приложения. Что думаешь?

Все хаяют кеды за их громозкость и неповоротливость, а были бы они модульными

Внезапно! кеды модульны. По остальному вопросу обратись к мейнтейнру своего дистриба.

Неужели в этих ваших юниксвеях за 40 лет ничего лучше нетипизированных синхронных текстовых уникастных потоков для реализации модульности не придумали?

Вот я и хочу узнать причину не использовать модульность.

Как уже сказано выше, кеды модульны. Если ты считаешь иначе - это значит, что твое определение «модульности» обладает фатальными недостатками.

весь функционал одной любой взятой программы монолитен: взять те же activites kwin'а, пользуются этой функцией 2,5 человека, а всё равно находится с стандартном функционале

Модуль - это фрагмент кода с опубликованным стабильным интерфейсом. Качество модульности определяется двумя параметрами - собственно разделением функциональности по модулям и протоколам, по которым модули общаются. Ни первое, ни второе не бесплатно - чем больше модулей ты сделаешь, тем больше протоколов тебе придется определять и тем сложнее будет взаимодействие между модулями; стабильность же межмодульного означает дополнительные расходы на его поддержание. И это всё... ради того, чтобы можно было выбросить activities? разрабы KDE решили, что оно того не стоит.

Приведенное выше объяснение, конечно, сильно упрощено. Например, вообще не упомянуто отображение протокола общения на транспорт - Си/Си++ вызовы vs текстовая сериализация vs CORBA vs whatever.

В итоге и получается кедерастам - кеды, гномосекам - гном, а столько бы независимого можно было бы сделать..

Ну да, дело за малым - определить согласованные протоколы.

Мне нравится идея bash'a: создаем конвеер из маленьких подпрограмм

То, что ты считаешь это «идеей bash», многое объясняет. И, в любом случае, «идея bash» опирается на то, что протокол межмодульного общения зафиксирован - это поток текста.

Что думаешь?

Думаю, что хороший вуз и специальность в области SE ответят на многие твои вопросы.

Мне близка следующая идея: любой компонент можно заменить или использовать отдельно от моего приложения.

Это не приложение, а пакет программ. Ну так делай, в чем проблема, мало что-ли успешных примеров?

Что думаешь?

Ну еще немного и ты DBus придумаешь.

капча «opium» как бы намекает

Таблетки прими, ничтожество.

Преждевременная оптимизация - корень всех зол.

Возьми и померяй. Очевидно медленнее в сравнении с общей памятью. Также очевидно, что достаточно быстро, чтобы этой скорости хватало с запасом для нормально спроектированной системы в большинстве случаев.

Делаем простенький тест

$ time head -c $((20*1024*1024*1024)) /dev/zero > /dev/null
real    0m2.432s
user    0m0.541s
sys     0m1.882s

$ time head -c $((20*1024*1024*1024)) /dev/zero | cat > /dev/null
real    0m7.656s
user    0m0.841s
sys     0m12.661s

Получаем производительность пайпы на уровне 2GB/sec для 1 CPU или 4GB/sec для 2 CPU (на моем железе) + добавте сюда накладные расходы на сереализацию/де-сереализацию если она нужна и сделайте вывод будут ли такие расходы критичны для вашего случая.

А ты с помощью такого пайпа (именно пайпа тк вопрос про это)

prog1|prog2

Как лучше покрошить задачу на модули, сильно зависит от самой задачи. Определитесь с требованиями, и решение само напросится.

А можете подобную аналитику с dbus провести? Каков он при передаче 200КБ раз в несколько секунд? И так ли сильно с kdbus улучшится производительность? Какие мысли о этой технологии? Для чего ее рациональнее всего использовать?

200КБ раз в несколько секунд?

ваще ниачем.

К сожалению я не имею достаточного опыта в рботе с dbus но чисто теоретически накладные расходы при работе с ней должны быть как минимум в 2 раза больше чем с PIPE (данные нужно вначале передать на dbus сервер, затем сервер их перешлет конечному получателю. Получается 2 пересылки C1 - S - C2 вместо C1 - C2). Использовать ее стоит наверное в области для которой ее создовали - унификация RPC для GUI приложений. Например если вы хотите работать с треем DE. Для консольных же преложений я бы не стал ее использовать хотябы потому что DBUS сервер может просто напросто отсутствовать в системе (например его нету на многих серверах).

пайпы в баше, что ли? ну, попробуй питон

но так ли быстры пайпы?

оу, пайпы так же быстры как и дев/нулл и даже быстрее.

Пиши что за программа и какие отдельные её компоненты можно использовать. А мы подумаем, нужны ли они и как лучше реализовать твою модульность. Или пиши более подробно о данных на вход и выход из каждого модуля.

Рассмотрим на практическом примере:
1. запись аудио файла
2. преобразование речи в текст
3. преобразование текста в математическое выражение
4. гуй обертка
Каждый компонент может быть полезен сам по себе, но вместе они составляют завершенный проект. Каждый этап можно заменить или вообще убрать, самым сложным этапом является четвертый - как реализовать взаимодействие? Нужна модульность, но вызывать из обертки = потеря модульности. Значит обертка должна быть независимой, но при запуске из bash как можно контролировать весь паровоз по нажатию гуевской кнопки «остановить запись»? Один вопрос порождает другой. Можно дать возможность компонентам с 1 по 3 вызываться через пайпы, но для гуй обертки будет использоваться dbus связь. Тогда мы получаем возможность вызывать кирпичики по требованию, но как тогда реализовать конвеерность: тут же записывается, тут же распознается, тут же появляется результат в гуй обертке? Еще можно в гуй обертку добавить конструктор паровоза: в настройках создаем последовательность пайпа. Да, последний вариант кажется более правильным..

Есть программа, функции которой можно сделать независимыми и разбить на части, как завещал юникс вей. С одной стороны возможность сменить любой кирпичик является интересной и практичной идеей, но насколько сильно пайпы будут тормозить всю конструкцию, нежели реализованной нормально статически?

Уныло. Вот же методичка.

-_-
Я говорю про неименованые пайпв.

Если такая сложная программа и такое глубокое непонимание того как это сделать - не берись, не справишься.

Если такая сложная программа и такое глубокое непонимание того как это сделать - не берись, не справишься.

Это просто пример желаемого стиля разработки. Нужно понять, как наладить связь между этими компонентами-кирпичиками и конечной оберткой, сейчас придерживаюсь мысли создания паровоза из настроек графического интерфейса. Тогда будет возможность полностью контролировать последовательность пайпа и его запуск/остановку. Хотелось бы критики данного способа и услышать другие варианты возможной реализации..

У меня такое ощущение, что он сейчас про конвеер говорит, а не про типизацию.

почему пайпы?
бери unix socket

что вы таки имеете в виду?

Нормальная — это опциональная и зависимая, с выводом, конечно :)

опциональная

вероятность прихода милого пушного зверька к проектам, над которыми по очереди работало больше 2 человек, возрастает до 99%

зависимая

пришедший песец приобретает ещё и необъятные размеры

Вот поэтому я и хочу сказать, что лютый фап на статику — бессмысленная затея

Вот поэтому я и хочу сказать, что лютый фап на статику — бессмысленная затея

Хм. Похоже, ты не понял - он назвал бессмысленной твою dream typing (которая опциональная, с выводом, и не существует).

Нет это ты не понял, я хотел сказать, что раз моей dream typing не существует, то все остальное — сорта говна.

я хотел сказать, что раз моей dream typing не существует, то все остальное — сорта говна.

Я понял это. А тебе сказали, что dream typing - говно еще худшее.

А это уже 5.3 :)