>[оверквотинг удален]
>> То есть, справедливости ради я отмечу, что на горизонте не просматривается
>> альтернатив, которые можно было бы считать прорывными, которые выводили бы осестроение
>> на новый уровень. Но это не делает гору костылей блестящим и
>> отлаженным механизмом.
>> unix философия начинается и заканчивается на работе с текствыми файлами. Есть coreutils,
>> которые -- эссенция unix-философии и финальная точка в ней. Всё остальное
>> в лучшем случае живёт самостоятельной жизнью, забив на unix-философию огромный болт
>> давным-давно, в худшем пытается натянуть unix-философию на решение задач, для которых
>> она не подходит.
> Ну и как это противоречит моему комментарию?

Я процитировал выше фразу, с которой я не согласен, и там же написал почему не согласен. А процитированный тобой кусок не несёт в себе цели противоречия чему-либо, он там только для того, чтобы убедиться, что мы понимаем фразу "unix-философия" одинаково.

> И, кстати, вообще говоря, а что ещё может быть в программах, кроме
> текста, покуда мы всё кодируем последовательностями байт? У вас в ДНК,
> простите биты и байты.

Последовательность байт и текст -- это разные вещи. Текст -- это частный случай последовательности байт. Причём, отметь, мы можем придумать много разных способов кодирования текста байтами. Вспомнить хотя бы ascii, koi8-r, cp866, utf8, utf16 и много других. Когда ты работаешь с текстом, ты работаешь с текстом, а не с байтами. Программирование на C в этом смысле вводит в заблуждение, но C -- это не тот язык, из которого следует черпать эпистемологическую мудрость.

> Условная "двухмерная логика" типа графов или анализа картинок, уже в миллион раз
> сложнее, и де факто всё равно упаковывается в последовательности, за исключением
> human computing.
> Трёхмерная логика существует только в сознании специалистов по алгебраической геометрии,
> а порядки выше вообще маловероятны по curse of dimensionality.

Логика тут не при чём. Если тебя тянет в теорию, то забей на логику: логика -- это лишь способ реализации вычислителя. А теория вычислителя -- это либо машина Тьюринга, либо квантовый компьютер. Ну, точнее это квантовый компьютер, и как частный его случай -- машина Тьюринга.

Но мы говорим не о вычислителях и не о логике. Это важно. Важно, потому что если забывать о чём мы говорим, то все языки эквивалентны ассемблеру, и поэтому их дополнительная сложность не нужна. Люди постоянно совершают ошибки мышления такого типа, и единственный способ их избегать, это чётко в рассуждениях следить за тем, чтобы не выходить за пределы чётко очерченной предметной области, а переходя границы чётко это отмечать и отдавать себе отчёт зачем это делается. Если цель гиперобобщение, с тем чтобы сказать что все языки равны, или что картинка эквивалентна тексту, то в голове должна включаться сирена предупреждающая о том, что мышление вошло в пике.

Смотри, в чём фишка работать с данными из текстовых файлов? Файлы разбиваются на строки, строки разбиваются на токены. Есть общепринятый способ разбиения файла на строки символов '\n', существует несколько распространённых способов разбиения на токены, скажем, в csv для этого используется запятая, плюс немного довольно очевидной магии с кавычками и экранирования. Ты можешь работать с текстовыми данными, решая задачи сформулированные в терминах предметной области твоей задачи (отсортировать строки csv таблички лексикографически по идентификатору записи), но излагая алгоритм решения в терминах текста и токенов. И это довольно просто выходит. Во многих случаях. В смысле, ps aux | grep firefox | xargs kill -9, выглядит просто и работает эффективно. Сочиняя такое, я мыслю в терминах процессов, имён процессов, сигналов отправляемых процессам, а излагаю это в терминах запуска утилит, перенаправления ввода вывода и фильтрации. Простым мыслям соответствует простой код. Офигенно. Именно так и должно быть.

Но попробуй теперь рассуждая в терминах векторов движения и блоков пикселей, написать код разобирающий h265 упакованный в mkv и выясняющий, двигался ли определённый объект в кадре между 1:23 и 1:45 -- это человек или статуя? Причём излагая этот код в терминах байтов. Слабо? Тебе придётся создать два-три уровня абстракции между байтами и векторами движения, прежде чем тебе удастся навести мосты над семантической пропастью между тем и этим. Твой код в объёме достигнет десятков или даже сотен тысяч строк. Особенно если писать ты будешь на bash, как того требует ортодоксальная unix-философия. Тут уже простым мыслям соответствует сложный код, и никакая unix-философия не сможет эту сложность спрятать, у неё недостаточно методов для этого. Тебе придётся уровни абстракции оформлять в виде подгружаемых библиотек, а если при этом mkv и h265 -- это лишь частные случаи контейнеров и кодеков, с которыми твоя программа должна работать, и даже формат пикселя может отличаться от случая к случаю, то вероятно в твою голову начнут закрадываться еретические мысли о том, что не только bash неудобен для этой задачи, но и C как-то не очень круто подходит.

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