Здравствуйте, Cyberax, Вы писали:
C>Проблема если нужно одновременно два разных потока данных как-то передавать.
???
Ни разу не проблема.
>> Это — простой текст. Только очень дерьмовый простой текст. У меня всегда >> практически для обмена структурированной информацией S-выражения >> используются. C>S-выражения — те же яйца, вид в профиль.
Не те же. Обработка проще и дешевле. И вместе с ними можно передавать код,
не только данные.
C>Как-то надо было сделать простую вещь — взять XML, пробежаться по всем C>узлам с заданым путем, взять у них атрибут, сделать операцию с этим C>атрибутом (это было имя файла, надо было regexp'ом его переименовать), а C>потом записать его же в этот документ, но по другому пути.
И? Где трудности? Вставить в пайплайн xslt кто запретил?
C>После часа мучений с tee и прочими гадостями — просто взял C>ActivePython+MSXML и за 10 минут написал все что нужно.
И чем же это не unix way?
>> C>2. JSON >> C>3. Да хотя бы ini-файлы >> C>4. Файлы с многострочными значениями >> И? Где тут проблемы, а? C>Неудобно использовать стандартные утиллиты.
Этих стандартных утилит — вагон. На все случаи жизни хватит. Для меня самые "стандартные" — perl и python.
C>Без стандартных утиллит — получается простая идеология использования C>соединенных фильтров.
Это и есть unix way. Много маленьких уединённых программок с CLI, способных общаться через пайпы И СОКЕТЫ.
>>> > C>4. С бинарными данными еще хуже. >>> > Да? tar -xf — бла-бла-бла | bzip2 >> C>А как там у нас grep будет работать, например? >> А зачем для бинарных данных grep? C>А что, бинарные данные надо распечатывать и на стенки вместо обоев вешать?
Ответ не в тему. Зачем для бинарных данных grep? Есть много других полезных утилит.
C>Нет. Это убогий unix way — так как RAR поддерживает создание архивов с C>кодами коррекции ошибок (если повреждается часть файла — ее можно C>восстановить). Но для этого ему нужен произвольный доступ к источнику и C>результату.
Нужен произвольный доступ — значит, не нужен поток и масштабируемость. Выбирай.
>> ЗАЧЕМ?!? Named pipes и unix domain sockets рулят со страшной >> силой. C>Покажите мне fseek на named pipe или domain socket.
Зачем?
C>Можно использовать shmem с некоторыми ограничениями, но все равно не C>хватает возможности полноценно реализовать свой файл.
Зачем? Тем более shmem не масштабируется, так что фтопку.
>> C>Мой любимый пример: как мне таблицу с графиками из Calc вставить в >> C>AbiWord, а потом ее там же редактировать с помощью inplace-редактора? >> Обе эти убогонькие программульки никакого отношения к unix way не имеют. C>Ага, конечно. "Факты не совпадают с теорией — тем хуже для фактов".
Какие факты? Есть две ущербные программульки, про unix way ничего не знающие — так какое они имеют отношение тогда к обсуждаемой теме?
>> А вот R + MySQL + Python + latex + gnuplot + maxima идеально вяжутся в >> одну систему, и, как показывает практика, вендовозные ламеры, любители >> поредактировать табличку в текстовом процессоре, по эффективности работы >> просто рядом не валялись с теми кто пользуется подобной связкой. C>Пробовал.
Плохо пробовали. Неумело.
C> ОЧЕНЬ неудобно писать спеки — если в Word/OpenOffice/... я C>могу запустить редактор, нарисовать нужную диаграмму, cut&paste'ом C>вставить в документ (не волнуюясь при этом об именах файлов), то с TeXом C>один ужас получается.
Какие такие спеки?!? Для тех. документации есть docbook. А тех, кто пишет её в офисах — надо гнать в три шеи, им в IT не место.
C>Начиная с неправильных версий пакетов и стилей на разных компьютерах, и C>заканчивая неполными документами.
Ну ну. Не умеете вы этих кошек готовить.
>> Пара дней — и идеального полиграфического качества статья готова, с >> идеальными графиками и достоверно проверенным качеством вывода и >> рассчётов. C>Понимаете, мне НАФИГ НЕ НУЖНЫ документы полиграфического C>качества, так работа идет с электронными копиями (а печатаются они для C>отчетности).
Тогда какие на хрен вордоофисы? Это задача для docbook.
>> Вордописцы будут с тем же самым возиться не меньше месяца, >> как, опять же, демонстрирует та же самая практика. C>Плохие вордописцы. Или они там формулы рисуют?
Естественно рисуют.
C>Хотя в TeXе очень неудобно писать химические формулы (точнее, их вообще C>неудобно как-либо в текстовом виде записывать).
Удобно, очень удобно. Удобней чем любой визуальный редактор.
Даже диаграммы Фейнмана — и то удобно, куда уж там всякой попсовой химии.
>> Те же самые пайпы ИДЕАЛЬНО решают задачу построения любого, сколь угодно >> сложного GUI. C>ROTFL.
Это вы от незнания.
C>Как раз GUI — это идеальный пример для "компонентов" в понимании C>COM/.NET/Delphi.
Отвратительный пример.
Идеальный GUI — это, например, Tcl/Tk, с частичной генерацией кода на стороне логики. Другой вариант — сервер, отображающий визуальные компоненты, которые описываются в виде XML или S-выражений.
Всякой дебильной объектщине в GUI и близко места нет. То, что извращенцы-объектщики так нагло и упорно в GUI лезут — ни разу им не оправдание.
>> И все эти "объектно-ориентированные" решения из просто >> рядом не валялись с простым и элегантным решением в стиле unix way. C>Вы LOR читаете? Очень фанатичный стиль похож...
Я ROTFL читаю и смеюсь.
Нет тут фанатизма. Есть знания и опыт, которых нет у вас.
