Kolhoz wrote:
> C>Проблема если нужно одновременно два разных потока данных как-то
> передавать.
> ???
> Ни разу не проблема.
Как через один пайп передать два потока одновременно? Только named pipe'ами.

> C>S-выражения — те же яйца, вид в профиль.
> Не те же. Обработка проще и дешевле. И вместе с ними можно передавать код,
> не только данные.
Как мне из JavaScript прочитать S-expr? Упс... А как там с разными
кодировками?

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

> C>После часа мучений с tee и прочими гадостями — просто взял
> C>ActivePython+MSXML и за 10 минут написал все что нужно.
> И чем же это не unix way?
COM ведь используется.

Создается компонент (написанный на С++) и прозрачно используется из
совершенно другого языка (о котором создатель компонента мог и не
догадываться).

Это я к тому, что Unix-pipes — это далеко не идеал.

> Этих стандартных утилит — вагон. На все случаи жизни хватит. Для меня
> самые "стандартные" — perl и python.
И что? Тот же Word замечательно рулится через OLE2 из
Python/Perl/VisualBasic/Brainfuck (да!)/C#/Nemerle/....

> C>Без стандартных утиллит — получается простая идеология использования
> C>соединенных фильтров.
> Это и есть unix way. Много маленьких уединённых программок с CLI,
> способных общаться через пайпы И СОКЕТЫ.
Вот только этот мирок разбивается, когда встречается с суровыми
реальностями настоящих требований пользователей.

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

В частности, для данного примера хватило бы возможности реализовывать
свои потоки произвольного доступа. В OLE это УЖЕ есть — смотри IStream.

>> > ЗАЧЕМ?!? Named pipes и unix domain sockets рулят со страшной
>> > силой.
> C>Покажите мне fseek на named pipe или domain socket.
> Зачем?
А вы думаете, что мир заканчивается однонаправленными потоками?

> C>Можно использовать shmem с некоторыми ограничениями, но все равно не
> C>хватает возможности полноценно реализовать свой файл.
> Зачем? Тем более shmem не масштабируется, так что фтопку.
Именно в этом и проблема с ним.

> Какие факты? Есть две ущербные программульки, про unix way ничего не
> знающие — так какое они имеют отношение тогда к обсуждаемой теме?
Есть 99% рынка домашних компьютеров, занятых этими ущербными программами.

А многочисленные попытки приспособить The Unix Way к десктопу — провалились.

> C>Пробовал.
> Плохо пробовали. Неумело.
Я не ежик, чтобы колоться, но продолжать жрать кактус. Причем без
какой-то перспективы на улучшение.

> C> ОЧЕНЬ неудобно писать спеки — если в Word/OpenOffice/... я
> C>могу запустить редактор, нарисовать нужную диаграмму, cut&paste'ом
> C>вставить в документ (не волнуюясь при этом об именах файлов), то с TeXом
> C>один ужас получается.
> Какие такие спеки?!? Для тех. документации есть docbook. А тех, кто
> пишет её в офисах — надо гнать в три шеи, им в IT не место.
Еще раз медленно, для тех кто долго понимает:

Технические спецификации — это НЕ документация к коду, это НЕ
документация к существующим системам, их НЕ нужно иметь в 10 форматах,
они ДОЛЖНЫ удобно редактироваться.

> C>Начиная с неправильных версий пакетов и стилей на разных компьютерах, и
> C>заканчивая неполными документами.
> Ну ну. Не умеете вы этих кошек готовить.
Ага. А может это просто кто-то много о себе думает?

> C>Понимаете, мне *НАФИГ НЕ НУЖНЫ* документы полиграфического
> C>качества, так работа идет с электронными копиями (а печатаются они для
> C>отчетности).
> Тогда какие на хрен вордоофисы? Это задача для docbook.
Docbook не подходит по многим причинам:
1. Редактировать руками его неудобно.
2. Нет нормальных редакторов.
3. Куча ненужных возможностей.
4. Нет НУЖНЫХ возможностей.

> C>Плохие вордописцы. Или они там формулы рисуют?
> Естественно рисуют.
Тогда действительно нафиг такое.

> C>Хотя в TeXе очень неудобно писать химические формулы (точнее, их вообще
> C>неудобно как-либо в текстовом виде записывать).
> Удобно, очень удобно. Удобней чем любой визуальный редактор.
> Даже диаграммы Фейнмана — и то удобно, куда уж там всякой попсовой химии.
Ты просто не видел формул. Их и в 2D (на листе бумаги) неудобно иногда
рисовать, а уж в 1D — вообще невозможно.

Диаграммы Фейнмана — это десткий лепет по сложности рисования.

> C>ROTFL.
> Это вы от незнания.
Задумайтесь, всякое общее утверждение — неверно.

> C>Как раз GUI — это идеальный пример для "компонентов" в понимании
> C>COM/.NET/Delphi.
> Отвратительный пример.
А что делать? Мир — жестокая штука.

> Идеальный GUI — это, например, Tcl/Tk, с частичной генерацией кода на
> стороне логики. Другой вариант — сервер, отображающий визуальные
> компоненты, которые описываются в виде XML или S-выражений.
А кто описания строит? Если автомат — то в морг.

Ну а задавать расположение визульных компонентов вручную с помощью
layout'ов (которые можно описывать как угодно) — додумались уже давным
давно.

> Всякой дебильной объектщине в GUI и близко места нет. То, что
> извращенцы-объектщики так нагло и упорно в GUI лезут — ни разу им не
> оправдание.
Ну так функциональщики показали бы класс.

> Нет тут фанатизма. Есть знания и опыт, которых нет у вас.
Вы случайно не Луговской? Что-то стиль похож.

Кстати, и откуда вы это знаете о моем опыте? Читали резюме? Видели мои
проекты? А?