> Это про обсуждаемую. задачу. Если про нее - она решена не юниксвейно, но вполне вменяемо. И сорц у нее достаточно прост чтобы любой предендующий на power user - вдуплил.
> Где логика на C писана. А пайпы - реализация, а не идея.
В юниксвейной логике - мелкие и быстрые проги на сях соединяются высокоуровневой скриптовой логикой, где то что она медленная - вообще не роялит, посколько это лишь коммутация и прочее, по сути. В случае склеивания библиотечных функций медленным скриптоязыком - проблема состоит в том что есть шанс нарваться на то что существенные потоки данных пролетают через скриптовое тормозилово.
> Эх, умели бы IT'шники как пользователи телевизоров/автомобилей/квартир/быт. химии/и
> т. д. править во всём этом мелкие косяки.
Как ни странно, именно это иногда и приходится делать. Знаете, забить мелкий гвоздь в стену или подклеить отлипшие обои вполне можно и не вызывая себе сервисмэнов, которых ждать, пардон, дольше, да еще и не бесплатно. А то что иногда оказывается что в бетонную стену гвоздь молотком - не того, и нужен простенький перфоратор, ну так простые перфораторы стали считаться бытовыми приборами в результате, стерев границу между бытовой дрелью и огроменным строительным перфоратором. А допустим Коливас - вообще анестезиолог. Это не мешает ему копаться в ядре и писать свой майнер биткоинов, колупая еще и ядро вычислений на opencl (который как бы "не совсем си").
> Одновременно обладая глубокими познаниями во всём том, что используют.
Для исправления программы такого плана и починки пары багов - совершенно не надо быть K&R-ом в одном лице :)
> Вот только в реальности они обладают глубокими познаниями только в IT. Но выпендрёжу...
Ну вон анестезиолог в ядре копается. Может, дело в том что если что-то интересно или нужно, в этом вполне можно разобраться, а не дефолтить к логике имбецила "я не разберусь, пусть это другие делают"? :)
