Здравствуйте, eao197, Вы писали:

E>Здравствуйте, Андрей Хропов, Вы писали:

АХ>> Весь этот Unix way сводится просто к сериализации/десериализации в/из потоков (они же файлы).
АХ>> Это конечно было замечательно в 70-е (и даже в 80-е) годы, но сейчас уже придумали кой-чего получше.

E>Что?
Ну нормальные компонентные модели вроде COM, CORBA, Java EE, .NET, которые поддерживают сообщения, обмен типизированными данными и т.п.

Зачем сериализовывать/десериализовывать в файл данные которые как параметр функции можно передать?

Я не спорю, Unix way через пайпы и фильтры — это неплохо. Но у него есть существенные ограничения, о которые здесь уже говорилось. Современные компонентные модели более универсальны.

Вот, скажем как вы подсистемы игры будете писать с помощью Unix way?

Здравствуйте, Cyberax, Вы писали:

>> C>Мальчик, файл и VFS в юниксах — это классический пример объектного
>> C>дизайна. VFS — так это вообще textbook example для полиморфизма.
>> Дедушка, эта ваша фраза — типичный пример так называемого
>> передёргивания, каковое является частным случаем так называемой демагогии.
C>А по сути ответить нет ничего?

Куда уж более по сути. Где вы тут объектщину углядели? По мне так чистейший KISS и unix way.

C>У меня сейчас в другой программе (построитель сценариев измерения)
C>используется самодельный VFS, например. На нем даже grep уже есть. То
C>есть я банально могу построить аналог юниксовой системы с помощью ООП, а
C>вот наоборот — не получится.

Так вот и не получится? За базар отвечать готовы?

C>Его не нужно на локальном компьютере. Блоб себе лежит где-то в базе, а
C>на мой компьютер приходят страницы по требованию.

А мне без разницы. Главное, что ресурс потреблятся зря.

C>А вот вам пришлось бы создавать временные файлы. Кстати, можно и
C>вычисляемый IStream сделать.

Не пришлось бы. С тем же успехом и я мог бы всунуть прослойку, которая реализовывалась бы как blob в базе.

Здравствуйте, McSeem2, Вы писали:

MS>Может я чего-то не понимаю, но меня от подобной халтуры тошнит. Как вся эта помойка может нравиться, я тем более не понимаю. Ребята! Брынза не бывает зеленого цвета — это вас кто-то обманул.

Надо признать, что реализация у МС хромает. Но давайте рассмотрим опять этот злосчастный .NET, у которой тоже реализация подхрамывает Для меня важна философия, архитектура, документация, перспективы итд, а баги это не самое главное.

Здравствуйте, Андрей Хропов, Вы писали:

АХ>Здравствуйте, Kolhoz, Вы писали:


K>> Опять 5*5... Эта компонентность не более мощная. Она более частная. Она реализуется тривиально поверх примитивов unix way, а вот unix way поверх объектной компонентной модели — нет. Не сравнивайте даже общее решение с частным!
АХ> Да все в точности наоборот!
АХ> Передайте от одного компонента другому имя файла и будет вам полнейший Unix way.

Какого файла? А если я туда netcat вставил? Или ssh?

АХ> Весь этот Unix way сводится просто к сериализации/десериализации в/из потоков (они же файлы).

Нет.

Дао Unix way:
— на каждую функциональную единицу — отдельный компонент
— к компоненту предъявляются требования:
* возможность как программного так и интерактивного задействования всех его функций.
* корректное сообщение о любых исключительных ситуациях
* наличие максимально простого для программной обработки протокола передачи как потребляемых, так и производимых компонентом данных.
— в системе из нескольких компонент между любыми двумя компонентами должна быть возможность встроить третий

Всё. Текстовые потоки, awk-и с netcat-ами — это частности и следствия означенного дао.

АХ> Это конечно было замечательно в 70-е (и даже в 80-е) годы, но сейчас уже придумали кой-чего получше.

Что же? Объектно-ориентированную религию не предлагать, тошно-с.

Здравствуйте, Андрей Хропов, Вы писали:

E>>Что?
АХ>Ну нормальные компонентные модели вроде COM, CORBA, Java EE, .NET, которые поддерживают сообщения, обмен типизированными данными и т.п.

COM уже масштабируется на сеть (про DCOM знаю, хорошо что это убожество умерло)?
CORBA — это просто один из малость извращенческих, но всего лишь RPC. Как и .net remoting. Это не компонентная модель и тем более не идеология. Внутри unix way применять можно, худо-бедно, а отдельно — лучше не стоит.

АХ>Зачем сериализовывать/десериализовывать в файл данные которые как параметр функции можно передать?

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

АХ>Я не спорю, Unix way через пайпы и фильтры — это неплохо. Но у него есть существенные ограничения, о которые здесь уже говорилось. Современные компонентные модели более универсальны.

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

АХ>Вот, скажем как вы подсистемы игры будете писать с помощью Unix way?

Да запросто. См. моё дао.

Здравствуйте, Cyberax, Вы писали:

>> Нет. Это означает — сначала сделай хороший двигатель, а потом думай,
>> какой кожей обивать кресла и какого цвета будет стрелка на спидометре.
C>Ага, сначала сделать крутой двигатель, а потом обнаружить, что ему нужен
C>бензин Аи-99.

Опять за неимением аргументов начинаем передёргивать?

Моя аналогия предельно ясна — нельзя плясать от GUI, от морды. Бензин — технологическое требование.

>> Вот вот. Это и есть — ущербный и ограниченный подход, который не
>> позволяет делать даже самые простейшие вещи (см. пример задачи несколько
>> ранее).
C>Пайпы могут наливать мне кофе? Отсойная вещь! Они даже не могут код на
C>С++ компилировать!

Как не могут? Очень даже могут. Была в одной конторке кофеварка с управлением по USB, народ там юниксовых утилит к ней понаписал. Весело было...

C>OLE — это способ связывания разных компонентов и их визуального
C>отображения. Что делают эти компоненты внутри — OLE не волнует.
C>Называется это умным словом — "инкапсюляция".

Это называется так, что в этой роли OLE — ну ни разу не компонентная модель, а просто идиотский (за неимением нормальных) способ встроить окно одного приложения в другое. В рамках unix way это делается чище и гибче.

Здравствуйте, Cyberax, Вы писали:

>> Очень смешно. Все 5000x5000 надо одновременно отобразить? :-O
C>На принтере — вполне себе нормально.

Вы бы хоть иногда поток сознания через фильтр какой пропускали, а?
Ну при чём тут принтер?!?

C>Для отображения на экране модель упрощается, но вынести его на сервер
C>нельзя. Так как при приближении модели упрощенные детали должны проявляться.

И почему вынести нельзя? Очень даже можно. И протокол с обратной связью сделать. У меня во всех системах визуализации оно так и устроено.

>> C>На выходе примерно 500Мб информации (данные о треугольниках и индексы в
>> C>них).
>> Значит это ещё не выход.
C>То есть?

То есть, нужен ещё один уровень обработки.

>> Я же сказал — Внутри. Одного. Контекста. Какие пайпы, блин! Это ОДИН
>> ПРОЦЕСС. С общей памятью. Физически. А логически — две отдельные
>> программы, обменивающиеся сообщениями.
C>А нафига???

Нам же нужна компонентная модель, не так ли? С минимальным оверхедом, когда дело доходит до всякоразного HPC, но со всеми плюшками от компонентности для разработчиков — и code reuse, и чёткое разграничение функциональных элементов, и масштабируемость, понадобится — легко можно разорвать компоненты и разбросать по кластеру — в коде самих компонентов менять ничего не придётся.

C>Кстати, трехмерный отображатель, обработчик данных и измеритель у меня —
C>разные подсистемы (сделанные на COM). Причем конфигурация всего может
C>управляться из любого COM-клиента, а в само приложение встроен VBA (как
C>в Word/Excel).

Ну и как, слабО теперь эти отдельные компоненты растащить на разные узлы кластера? Или вставить дополнительную обработку между ними, не трогая совсем никак их код?

Здравствуйте, Cyberax, Вы писали:

>> В .NET из компонентностей есть только довольно примитивные формы RPC и
>> сериализации и интерфейс ко всё тому же OLE. Ничего чистого и тем более
>> наглядного не прослеживается — нет даже общей идеологии.
C>Назовите НЕпримитивные формы RPC.

Любой АГЕНТНЫЙ протокол. Жабисты ими иногда развлекаются, но довольно неумело.
У пользователей Схемы или Тикла получается лучше.

C>Ну и OLE к .NET не имеет никакого отношения. Может не стоит показывать
C>своего незнания в обоих предметах?

Я же сказал — в .NET есть интерфейс к OLE. Скажешь, нет? :-O

>> Вы поработайте для сравнения в команде, где весь документооборот на вордах,
>> и в команде, где с одной стороны docbook, а с другой —
>> bugzilla+cvszilla. Поймёте, почему вторая команда будет свысока смотреть
>> на первую.
C>Пробовал. После $#TY$OIU# с docbook в итоге перешли на Word.

Хреновенько пробовали, значит. Я пока не встречал ни одной не-ламерской конторы, где использовали бы Word, и множество крутых, пользующихся docbook или доморощенными аналогами.

C>И уж системы багтрекинга и SCM к формату документов не имеют никакого
C>отношения.

Имеет, имеет. Они должны идеально интегрироваться в документооборот. Или вы всё ручками делаете? Представляю, какой кошмар и бардак у вас творится. Одна только попытка засунуть вордовый документ в cvs, думаю, будет тем ещё цирком. А уж обеспечить гарантированную целостность проектной документации, системы автоматического тестирования, системы багтрекинга и документации к коду, пользуясь вордом — это задача века, за её решение надо конный памятник в масштабе 1:50 ставить. Из чистого золота. Прижизненный.

>> Ламер — не тот, кто пользуется виндовсом (я вот почти только под виндовс
>> и писал всегда), а тот, кто не желает думать своей головой и ведётся на
>> дешевый appeal to authority.
C>Ага. Всякой чепухе про Unix way, например.

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

C>Ну-ну. От вас технических возражений по сути и не было.

Как не было? Было. И все были успешно проигнорированы.

Например, очень смешно замяли тему про ООП в GUI.

Здравствуйте, DJ KARIES, Вы писали:

DK>Ну, что ж вы так агрессивно настроены?
DK>Я про гегемонию МС говорил, за которой обывателю не видны ни линУксы, ни цыгВины, ни прочие проблески разума среди пошлой коммерции.

Любой независимый объективный семантический анализ вашего текста покажет совершенно обратное — вы говорили, что технологии unix way физически не интегрируются в Windows. Что не есть истина.

DK>У простого юзера винды НЕТ X-Window, в отличие от WinAPI, что бы там офигевшие и зазнавшиеся линуксоиды не говорили

И кого волнуют простые юзеры винды? Мы про них тут вообще не говорим.

Здравствуйте, Kolhoz, Вы писали:

K> Успокойтесь. Всё работает очень быстро. Посмотрите, например, на X11, где вся графика гоняется через unix domain socket, если локально, и через, например, tcp, если удалённо. И ничего, работает.

То-то я смотрю XPutImage так тормозит. А без него качественно отобразить векторную графику — ну никак не получается (только не надо говорить, что это X-сервер умеет делать — не умеет он ничего). Вот и получается, что без костылей типа MIT-SMH — никуда.

Здравствуйте, Kisloid, Вы писали:

K>Надо признать, что реализация у МС хромает. Но давайте рассмотрим опять этот злосчастный .NET, у которой тоже реализация подхрамывает Для меня важна философия, архитектура, документация, перспективы итд, а баги это не самое главное.

Я уже приводил свое видение рекламного слогана для дот-нет:



Аналогично для MS Office:


Теоретически, безусловно все может быть, даже то, чего быть не может. На практике — число глюков в пересчете на условную единицу функциональности неуклонно растет.

Здравствуйте, EvilChild, Вы писали:

EC>Не доделают его — это нереально.
EC>Он обречён на отставание.
EC>Посмотри с какой скоростью плодятся всякие C# 3.0, LINQ, ADO.NET 3, WCF, WPF и прочие buzzwords.

Мне Мигель говорил что C# 2.0 поддерживается на 90%, причем 10% это баги Это было давно, примерно полгода назад.

Здравствуйте, McSeem2, Вы писали:

MS>Теоретически, безусловно все может быть, даже то, чего быть не может. На практике — число глюков в пересчете на условную единицу функциональности неуклонно растет.

Ну не скажи, вспомни хотя бы Win95 и сравни с XP, как небо и земля. Win 95 а может даже и Win 3.x дало верное направление развития, дало начало.

Здравствуйте, iZEN, Вы писали:

VD>>Под Линукс прекрасно работают Ява и Моно. Этого более чем достаточно. Потом практически любой скриптовый язык решает задачи в том числе аналогичные КОП.
ZEN>По последним новостям проекта Mono до сих пор не решены проблемы работы "компонентов" WinForms.

Источкник новостей, плиз. Или так уж честно и говори "по слухам".

С компонентным подходм в Моно проблем нет. Тот же компилятор Немерле использует компонентный подход для динамической подгрузки макросов.

Здравствуйте, Kolhoz, Вы писали:

K>Здравствуйте, Андрей Хропов, Вы писали:

АХ>>Здравствуйте, Kolhoz, Вы писали:


K>>> Опять 5*5... Эта компонентность не более мощная. Она более частная. Она реализуется тривиально поверх примитивов unix way, а вот unix way поверх объектной компонентной модели — нет. Не сравнивайте даже общее решение с частным!
АХ>> Да все в точности наоборот!
АХ>> Передайте от одного компонента другому имя файла и будет вам полнейший Unix way.

K> Какого файла? А если я туда netcat вставил? Или ssh?
И? В чем проблема?
Передайте имя файла netcatу, а он дальше передаст.

то что вы пишете в Unix как
"ls | more"
можно записать как (условно)
"File result = more.Process( ls.Process(input) )".
more и ls некие компоненты.

Чуть больше слов, но суть та же.

АХ>> Весь этот Unix way сводится просто к сериализации/десериализации в/из потоков (они же файлы).

K> Нет.

K> Дао Unix way:
K>- на каждую функциональную единицу — отдельный компонент
Правильно — в любой компонентной системе так.

K>- к компоненту предъявляются требования:
K> * возможность как программного так и интерактивного задействования всех его функций.
Правильно. Так как вы там интерактивность в Unix way обеспечиваете?

K> * корректное сообщение о любых исключительных ситуациях
Сообщение мало. Надо еще данные не убить по возможности.
Без поддержки исключений обработка ошибок — это геморрой жуткий.
Я уж не говорю про RAII. А это предполагает ОО.

K> * наличие максимально простого для программной обработки протокола передачи как потребляемых, так и производимых компонентом данных.
K>- в системе из нескольких компонент между любыми двумя компонентами должна быть возможность встроить третий
Эээ. Вот тут мне видится фундаментальный изъян.
Дело в том что для того чтобы вставить на вход одного компонента выхлоп из другого нужно чтобы у них были совместимы интерфейсы, т.е. передаваемая информация была в одном формате,
в unix way используется наименьший общий знаменатель — простой текст.
Часто программы работают все же не с простым текстом, а со структурированными данными
(простейшие утилиты вроде grep не берем в расчет), поэтому имеем оверхед на сериализацию/десериализацию.
А любой компонент в середину все равно нельзя, поскольку обработка разной информации требует разных компонентов (пример с закодированными символами в HTML уже приводился, так же можно сказать что с ASCII и Unicode надо работать по-разному и т.п.).

Вот LaTeX — это Unix way?
в цепочке "latex -> dvips -> ps2pdf" ты можешь вставить (точнее, смысл есть?) между dvips и ps2pdf grep?

K> Всё. Текстовые потоки, awk-и с netcat-ами — это частности и следствия означенного дао.
Имеют свои плюсы, но не универсальны.

АХ>> Это конечно было замечательно в 70-е (и даже в 80-е) годы, но сейчас уже придумали кой-чего получше.

K> Что же? Объектно-ориентированную религию не предлагать, тошно-с.
Глупости говорите. ОО давно уже само-собой. Теперь уже дальше идем в сторону скрещения ОО с функциональщиной . Даже в скриптовых языках, без которых Unix way никуда .

Здравствуйте, Андрей Хропов, Вы писали:

K>>- к компоненту предъявляются требования:
K>> * возможность как программного так и интерактивного задействования всех его функций.
АХ>Правильно. Так как вы там интерактивность в Unix way обеспечиваете?

ну... собственно консолью и обеспечиваем, нет?
find /usr/src/linux -name "*.c" -exec grep -H "fuck" {} \; | wc -l
чем не интерактивность?

с другой стороны. что для этого предлагает КОМ? таки да, компонентность есть, но... а где интерактивность?

K>> * корректное сообщение о любых исключительных ситуациях
АХ>Сообщение мало. Надо еще данные не убить по возможности.
АХ>Без поддержки исключений обработка ошибок — это геморрой жуткий.

вот этого я не понял. если софтина приняла на вход что-то и умерла, то она об этом корректно сообщила. что не так?

АХ> А любой компонент в середину все равно нельзя, поскольку обработка разной информации требует разных компонентов (пример с закодированными символами в HTML уже приводился, так же можно сказать что с ASCII и Unicode надо работать по-разному и т.п.).

логично предположить что эти символы надо раскодировать. в частности (для аски и юникода) iconv. нормально? вставляется как раз между

АХ>Вот LaTeX — это Unix way?
АХ>в цепочке "latex -> dvips -> ps2pdf" ты можешь вставить (точнее, смысл есть?) между dvips и ps2pdf grep?

мочь -- могу. смортя что ищем
почему нельзя?

Здравствуйте, Андрей Хропов, Вы писали:

АХ>>> Весь этот Unix way сводится просто к сериализации/десериализации в/из потоков (они же файлы).
АХ>>> Это конечно было замечательно в 70-е (и даже в 80-е) годы, но сейчас уже придумали кой-чего получше.

E>>Что?
АХ>Ну нормальные компонентные модели вроде COM, CORBA, Java EE, .NET, которые поддерживают сообщения, обмен типизированными данными и т.п.

А эти нормальные компонентные модели интероперабельны между собой? Например, каким образом COM-компонент будет общаться с JavaBean-ом?

АХ>Зачем сериализовывать/десериализовывать в файл данные которые как параметр функции можно передать?

Вообще-то параметры функции все равно будут сериализоваться/десериализоваться. Вопрос в том, насколько приложение владеет процессом сериализации. И не факт, что при работе с текстовым протоколом сериализацию/десериализацию придется делать ручками -- все это может выполняться автоматическими генераторами парсеров (например. парсинг HTTP в некоторых HTTP-серверах пишется не вручную).

АХ>Я не спорю, Unix way через пайпы и фильтры — это неплохо. Но у него есть существенные ограничения, о которые здесь уже говорилось.

Давайте еще раз повторим Unix way это не только пайпы и фильты. Пайпы и фильтры -- это всего лишь самый явный пример. Unix way -- это способ проектирования приложений из отдельных частей, каждая из которых выполняет конкретную задачу и общается с другими частями по наиболее простым протоколам.

Пайпы и фильтры всего лишь самые простые механизмы. В качестве более сложного примера можно взять, например, XML-RPC или даже SOAP.

Даже упомянутая вами CORBA может быть всего лишь транспортом для больших задач. Например, при создании системы управления телефонными переговорами с использованием спецификации Parlay можно применить Unix way для декомпозиции системы на части, взаимодействующие между собой по CORBA (просто потому, что этого требует Parlay). Но каждая из частей будет выполнять всего одну конкретную подзадачу и, скорее всего, будет отдельным процессом (может быть даже на отдельной машине). Хотя более в духе Unix way была бы организация взаимодействия отдельных процессов через XML-RPC или SOAP.

Имхо, у Unix way нет предела сверху. Эта идея может масштабироваться вместе со сложностью задачи.

АХ>Современные компонентные модели более универсальны.

Да ради бога.
Я не стараюсь доказать, что Unix way лучше указанных вами компонентных технологий. Это просто другой подход.

Только вот, если бы вы смогли показать преимущества тех же CORBA, J2EE и .NET по сравнению с Unix way в области расширяемости протоколов и в области интероперабильности, то я с удовольствием бы почитал такое сравнение.

АХ>Вот, скажем как вы подсистемы игры будете писать с помощью Unix way?

А какие игры? 3D shutter, RPG, Real-Time Strategy?
Если я не ошибаюсь, то в 3D shutter-ах, допускающих сетевую игру, как раз Unix way и использутся (т.е. есть сервер, который отслеживает всех игроков, а есть клиенты, которые отображают происходящее игрокам).

Здравствуйте, Kisloid, Вы писали:

K>Здравствуйте, McSeem2, Вы писали:

MS>>Теоретически, безусловно все может быть, даже то, чего быть не может. На практике — число глюков в пересчете на условную единицу функциональности неуклонно растет.

K>Ну не скажи, вспомни хотя бы Win95 и сравни с XP, как небо и земля. Win 95 а может даже и Win 3.x дало верное направление развития, дало начало.

Win2K гораздо устойчивее чем WinXP. Вообще помоему WinXP по устойчивости только чуть лучше чем Win98SE.

K> Моя аналогия предельно ясна — нельзя плясать от GUI, от морды.

Можно. Плясание именно от морды — это наипервейшее требование разработки Web-приложений. Потому что никого не волнует, как оно там, на сервере, творится. Главное — чтобы результаты были в доступном виде на экране. Но это — частный случай.

Здравствуйте, Cyberax, Вы писали:

>> Так я и рассказываю. Не слушают-с. Сколько я этих GUI понаделал,
>> преимущественно под Windows, и ну ни разу не приходилось применять их,
>> вендовый стиль мышления. К чему бы это?
C>Ну так покажите эти GUI. И их пользователей. Какие проблемы?

Я так понимаю, что образец GUI для подражания в количестве "много" нам не покажут?