>[оверквотинг удален]
> неудобен для этой задачи, но и C как-то не очень круто
> подходит.
> Текстовые данные и видео -- это очень разные данные, и работать с
> ними базируясь на одних и тех же принципах не выйдет. Можно
> взять архитектуру ffmpeg, и сделать поверх неё движок для обработки текста,
> она легко вместит в себя это, но это будет оверинжинирнг, архитектура
> ffmpeg слишком сложна для coreutils. Архитектура же coreutils/sh (aka unix-философия)
> не подходит для видео, потому что они слишком проста и тупа
> для этого. Текст видео разные, настолько разные что программы, работающие с
> ними пишут совершенно по-разному.

Utf8 ты совершенно зря здесь упомянул. У utf8 в худшем случае линейный доступ к ячейке, поэтому хардкорный баш уже будет спотыкаться.

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

Доминирование работы с текстом (в частности приведённый выше pgrep) здесь является следствием, а не причиной, и не философским положением.

Зачем тратиться на миллион одинаковых UI, когда можно просто взять поток байт на вход из stdin. Это будет вполне юниксвейно.

Один уровень эмпатии по отношению к человеку меньше, один уровень эмпатии по отношению к компьютеру больше.

Программа мало отличима от функции, мультитрединг реализован на уровне процессов (нет разницы между процессами и потоками.