Kolhoz wrote:
> C>А все равно. Нет нормального механизма передачи исключительных ситуаций.
> Как нет? Оно обычно в протокол зашито. Ни разу с этим трудностей не
> испытывал.
Проблема если нужно одновременно два разных потока данных как-то передавать.

> C>Недостаток. Кроме простого текста есть:
> C>1. XML
> Это — простой текст. Только очень дерьмовый простой текст. У меня всегда
> практически для обмена структурированной информацией S-выражения
> используются.
S-выражения — те же яйца, вид в профиль.

Как-то надо было сделать простую вещь — взять XML, пробежаться по всем
узлам с заданым путем, взять у них атрибут, сделать операцию с этим
атрибутом (это было имя файла, надо было regexp'ом его переименовать), а
потом записать его же в этот документ, но по другому пути.

После часа мучений с tee и прочими гадостями — просто взял
ActivePython+MSXML и за 10 минут написал все что нужно.

> C>2. JSON
> C>3. Да хотя бы ini-файлы
> C>4. Файлы с многострочными значениями
> И? Где тут проблемы, а?
Неудобно использовать стандартные утиллиты.

> C>Какие стандартные утилиты догадаются, что последовательность &#3241 (код
> C>вымышлен) — это буква "а"? Правильно, никакие.
> Unix-way не завязан на "стандартные" утилиты. Никак.
Без стандартных утиллит — получается простая идеология использования
соединенных фильтров.

>> > C>4. С бинарными данными еще хуже.
>> > Да? tar -xf — бла-бла-бла | bzip2
> C>А как там у нас grep будет работать, например?
> А зачем для бинарных данных grep?
А что, бинарные данные надо распечатывать и на стенки вместо обоев вешать?

> Ну так убогий rar — не unix way, он просто не вписывается. Любая
> компонентная система требует от компонентов следования определённой
> идеологии (и хорошо если идеологии, а не фиксированному API).
Нет. Это убогий unix way — так как RAR поддерживает создание архивов с
кодами коррекции ошибок (если повреждается часть файла — ее можно
восстановить). Но для этого ему нужен произвольный доступ к источнику и
результату.

> C>Ну и иногда еще ОЧЕНЬ мешает невозможность сделать свою реализацию
> C>файлов (я знаю, что можно использовать FUSE на Линуксе, но в общем
> C>случае в юниксах эта задача не решается).
> ЗАЧЕМ?!? Named pipes и unix domain sockets рулят со страшной
> силой.
Покажите мне fseek на named pipe или domain socket.

Можно использовать shmem с некоторыми ограничениями, но все равно не
хватает возможности полноценно реализовать свой файл.

> C>Мой любимый пример: как мне таблицу с графиками из Calc вставить в
> C>AbiWord, а потом ее там же редактировать с помощью inplace-редактора?
> Обе эти убогонькие программульки никакого отношения к unix way не имеют.
Ага, конечно. "Факты не совпадают с теорией — тем хуже для фактов".

> А вот R + MySQL + Python + latex + gnuplot + maxima идеально вяжутся в
> одну систему, и, как показывает практика, вендовозные ламеры, любители
> поредактировать табличку в текстовом процессоре, по эффективности работы
> просто рядом не валялись с теми кто пользуется подобной связкой.
Пробовал. ОЧЕНЬ неудобно писать спеки — если в Word/OpenOffice/... я
могу запустить редактор, нарисовать нужную диаграмму, cut&paste'ом
вставить в документ (не волнуюясь при этом об именах файлов), то с TeXом
один ужас получается.

Начиная с неправильных версий пакетов и стилей на разных компьютерах, и
заканчивая неполными документами.

> Пара дней — и идеального полиграфического качества статья готова, с
> идеальными графиками и достоверно проверенным качеством вывода и
> рассчётов.
Понимаете, мне НАФИГ НЕ НУЖНЫ документы полиграфического
качества, так работа идет с электронными копиями (а печатаются они для
отчетности).

> Вордописцы будут с тем же самым возиться не меньше месяца,
> как, опять же, демонстрирует та же самая практика.
Плохие вордописцы. Или они там формулы рисуют?

Хотя в TeXе очень неудобно писать химические формулы (точнее, их вообще
неудобно как-либо в текстовом виде записывать).

> C>Я не спорю, pipe'ы — это очень элегантное решение, позволяющее
> C>эффективно решать *большую часть* административных задач. Только
> C>вот пора бы уже что-то новое придумать.
> Те же самые пайпы ИДЕАЛЬНО решают задачу построения любого, сколь угодно
> сложного GUI.
ROTFL.

Как раз GUI — это идеальный пример для "компонентов" в понимании
COM/.NET/Delphi.

> И все эти "объектно-ориентированные" решения из просто
> рядом не валялись с простым и элегантным решением в стиле unix way.
Вы LOR читаете? Очень фанатичный стиль похож...