Здравствуйте, Cyberax, Вы писали:
C>Сравни сложность разработки — распределенные приложения заметно сложнее C>отлаживать и писать.
Сравнил. Обрати внимание на название инструмента в моей подписи
Там самое сложное -- это привыкнуть к асинхронности на первом этапе. Затем, при использовании нескольких дополнительных библиотечек, что монолитное, что распределенное приложение -- уже нет разницы. Так что инструменты здесь играют очень и очень важную роль.
>> Я говорил об RPC именно как о Remote Procedure Call, а call -- это >> синхронный вызов. И вся цель RPC в том, чтобы скрыть от программиста >> факт распределенности. C>Такой RPC мне самому не нравится — слишком много проблем вызывает.
Так собственно это и есть RPC...
C>А вот что-нибудь типа JMS в Java — вполне себе ничего.
А вот это уже еще один вид IPC
>> Вот тестовые протоколы, которые должным образом структурируют информацию >> (как, например, заголовки HTTP, XML, YAML) как раз позволяют >> использовать подобный прием. C>Просто сам по себе HTTP запрос представляет вызов одного метода примерно C>такого типа: C>
Здравствуйте, Kisloid, Вы писали:
K>Мне Мигель говорил что C# 2.0 поддерживается на 90%, причем 10% это баги Это было давно, примерно полгода назад.
В лучшем случае к выходу C# 3.0 компилер стабилизируют в объёме C# 2.0, а окружающие библиотеки так и будут ущербными,
что сводит на нет все радости существования компилятора и Mono вообще.
Просто это изначально проигрышная позиция догонять, да ещё таких мастеров несовместимости и забивания на стандарты как MS.
Здравствуйте, iZEN, Вы писали:
ZEN>Да у них на сайте чёрным по белому написано. Не могут решить, какую версию библиотеки GTK использовать и ZEN>использовать ли её вообще для реализации WinForms. Месяц назад смотрел специально.
Ссылку пдай. А то я что-то не вижу.
VD>>С компонентным подходм в Моно проблем нет. Тот же компилятор Немерле использует компонентный подход для динамической подгрузки макросов. ZEN>Про языки будем отдельно говорить, так и Delphi/Kylix можно подцепить.
Такое ощущение что мы говорим через испорченный телефон. Причем тут Кликс? Немереле использует штатные компонентые средства Моно и дотнета.
Что непонятного в моих словах?
ZEN>В теме рассматривается проблема: а так ли хорошо реализован КОП в Linux или не очень хорошо.
В теме задается вопрос "если ли КОП в Линукс". А этот вопрос ты сам только что придумал.
Собственно мой ответ в том, что переносимые среды воде Явы и дотнета обеспечивают компонентность на любой ОС где их установали.
Если тебе хочется пофанатсвовать и помериться пенисами в области Ява вс. дотнет, то открывай новую тему. И лучше сразу во Флэйме.
ZEN>Пока все склоняются в сторону того, что КОП в Linux реализован иначе, не как в Windows, но в любом случае использование подхода КОП как в Windows тоже не возбраняется. ZEN>В Windows, например, очень трудно использовать подход UNIX просто из-за того, что пользователи (программисты и просто пользователи) зашорены идеологией виндовс и не способны мыслить иначе, чем кнопочками, диалогами и командой "Выполнить".
Ты точно понимашь под термином КОП то что все остальные?
Что за компоентный подход ты усмотрел в самих Виндовс и загадочном Юникс (видимо Линукс).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Другое дело, я действительно люблю когда все работает out of the box. АХ>Нажал кнопку "Установить" — все установилось , "выполнить" — выпонилось АХ>и не люблю по запутанным мануалам изучать значения флагов в командной строке. АХ>Пусть простые задачи будут простыми.
Причем тут КОП? КОП — Компонетно Ориентированное Программирование. То есть взгляд на программу как на собираемую из отдельных компонентов.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
>> C>Нет, правило хорошее. Если что-то можно не распределять — то лучше не >> C>распределять. >> Как раз у меня есть противоположный собственный опыт. То, что казалось >> бы, может работать монолитом, выигрывает по некоторым параметрам >> (надежность, масштабируемость) будучи распределенным. C>Сравни сложность разработки — распределенные приложения заметно сложнее C>отлаживать и писать.
А как же Эрланг?
От чего, от чего, от чего тах хорошо?
Потому что кто-то любит программиста
<< RSDN@Home 1.2.0 alpha rev. 647>>
Здравствуйте, Kisloid, Вы писали:
K>Вот тогда следующий вопрос, возьмем к примеру Мозилловские проекты, зачем им надо было создавать свою реализацию КОМа если есть unix way (хотя наверное вопрос к ним ) ?
Замечательный вопрос. Четко демонстрирующий то, что под компонентным подходом в Уних-вэях понимают совсем другое.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, iZEN, Вы писали:
ZEN>И что? Сейчас три вышеперечисленные мною компании в открытую спонсируют ECMA, не говоря уже о мелких конторках. Но почему-то IBM и Sun не спешат присоединяться.
Ты хоть понимашь что такое ECMA и чем эта организация отличается от ANSI, к примеру?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, EvilChild, Вы писали:
АХ>>Еще посмотрим, когда Mono доделают как он на Unix системах развернется . EC>Не доделают его — это нереально.
А ты сам то Моно пробовал?
EC>Он обречён на отставание. EC>Посмотри с какой скоростью плодятся всякие C# 3.0, LINQ, ADO.NET 3, WCF, WPF и прочие buzzwords.
Нда, знания на уровре фантастики. C# 3.0, LINQ, ADO.NET вообще от платформы не зависят.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, EvilChild, Вы писали:
EC>В лучшем случае к выходу C# 3.0 компилер стабилизируют в объёме C# 2.0, а окружающие библиотеки так и будут ущербными, EC>что сводит на нет все радости существования компилятора и Mono вообще.
А ты вкурсе, что сборки от C# 3.0 без перекомпиляции можно запускать под .NET 2.0 и Моно?
Что до библиотек, то их уже точно больше чем можно найти в поставке какого-нибудь С++-компилятора.
EC>Просто это изначально проигрышная позиция догонять, да ещё таких мастеров несовместимости и забивания на стандарты как MS.
Любой С++-компилятор догоняет стандарт С++. Пока только один догнал текущий стандарт.
Внимание, вопрос! С++ обречен?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Андрей Хропов, Вы писали:
АХ>>Другое дело, я действительно люблю когда все работает out of the box. АХ>>Нажал кнопку "Установить" — все установилось , "выполнить" — выпонилось АХ>>и не люблю по запутанным мануалам изучать значения флагов в командной строке. АХ>>Пусть простые задачи будут простыми.
VD>Причем тут КОП? КОП — Компонетно Ориентированное Программирование. То есть взгляд на программу как на собираемую из отдельных компонентов.
Это была моя реакция на
пользователи (программисты и просто пользователи) зашорены идеологией виндовс и не способны мыслить иначе, чем кнопочками, диалогами и командой "Выполнить".
Здравствуйте, Kolhoz, Вы писали:
АХ>>то что вы пишете в Unix как АХ>>"ls | more" АХ>>можно записать как (условно) АХ>>"File result = more.Process( ls.Process(input) )". АХ>>more и ls некие компоненты.
АХ>>Чуть больше слов, но суть та же.
K> Не та же. Я не могу между more и ls вставить в этой модели ничего (sort, например).
Почему?
"File result = more.Process( sort.Process( ls.Process(input) ) )"
Как я уже говорил, на мой взгляд вся эта работа через каналы — частный случай КОП.
K>>> Дао Unix way: K>>>- на каждую функциональную единицу — отдельный компонент АХ>>Правильно — в любой компонентной системе так.
K> Не в любой. В объектных моделях для этого функциональная единица должна совпадать с объектом. А это не всегда возможно. Скорее, это почти никогда не возможно — объектная иерархия редко совпадает с семантической.
Почему это она не должна совпадать с семантической?
K>>>- к компоненту предъявляются требования: K>>> * возможность как программного так и интерактивного задействования всех его функций. АХ>>Правильно. Так как вы там интерактивность в Unix way обеспечиваете?
K> Не понял вопроса. Легко и непринуждённо обеспечиваем.
Ну и как вы будете игру (не многопользовательскую, а самую обычную) писать через Unix way?
K>>> * корректное сообщение о любых исключительных ситуациях АХ>>Сообщение мало. Надо еще данные не убить по возможности. АХ>>Без поддержки исключений обработка ошибок — это геморрой жуткий. АХ>>Я уж не говорю про RAII. А это предполагает ОО.
K> ОО тут совершенно не при делах...
Аргументируй.
АХ>>Эээ. Вот тут мне видится фундаментальный изъян. АХ>>Дело в том что для того чтобы вставить на вход одного компонента выхлоп из другого нужно чтобы у них были совместимы интерфейсы, т.е. передаваемая информация была в одном формате, АХ>>в unix way используется наименьший общий знаменатель — простой текст.
K> Не обязательно. Не нужна совместимость, на самом деле.
Как это так? Подаем ASCII а программа хочет Unicode и привет!
АХ>>Вот LaTeX — это Unix way? АХ>>в цепочке "latex -> dvips -> ps2pdf" ты можешь вставить (точнее, смысл есть?) между dvips и ps2pdf grep?
K> Могу, и как правило вставляю (psnup, ps2ps, мелкие самописные пошкрип-фильтры). Смысла много — postscript обрабатывать весело, легко и просто, буклетик там из него сшить, водяные знаки наложить, или ещё что, а вот pdf потом править обломно будет. Так уж лучше я поправлю ps на этом этапе.
Правильно, но это уже не ЛЮБЫЕ, а специализированные компоненты, предназначенные для обработки ps.
K>>> Всё. Текстовые потоки, awk-и с netcat-ами — это частности и следствия означенного дао. АХ>>Имеют свои плюсы, но не универсальны.
K> Естественно. А Unix way не требует использования обязательно текстовых потоков.
А как же тогда вы между ЛЮБЫМИ двумя компонентами третий вставите?
AX>> Теперь уже дальше идем в сторону скрещения ОО с функциональщиной . Даже в скриптовых языках, без которых Unix way никуда .
K> Простите, какие языки? Какая функциональщина? Мне глубоко наплевать на ОО и функциональщину в языках. Наплевать и растереть.
А позволь поинтересоваться на каких языках ты пишешь?
K> В данном случае источник мирового зла — это OOD, то есть, ОО на уровне проектирования, на компонентном уровне.
Ужас какой-то. И чем тебя OOD угнетает? Это американский заговор, да?
K> Тут пока никаких языков нет и не предвидится.
Где тут?
Здравствуйте, VladD2, Вы писали:
VD>А ты вкурсе, что сборки от C# 3.0 без перекомпиляции можно запускать под .NET 2.0 и Моно?
А как насчёт коммерческих GUI библиотек, которые кишат p/invoke & interop? А как быть с пространствами
имён типа System.Diagnostics, System.Threading, System.EnterpriseServices, System.Drawing,
реестр и прочая виндовая байда, которая на юнихи никак не ложиться? GDI, COM, COM+, DTS туда же.
Реализовать это всё равно, что написать половину винды.
VD>Что до библиотек, то их уже точно больше чем можно найти в поставке какого-нибудь С++-компилятора.
Причём здесь С++? Что он тебе плохого сделал, что ты его упоминаешь к месту и не к месту? Речь идёт
о КОП в linux, C++ к нему (КОП) никаким боком (причём именно ты об этом чаще всех говоришь).
VD>Любой С++-компилятор догоняет стандарт С++. Пока только один догнал текущий стандарт.
VD>Внимание, вопрос! С++ обречен?
С++ вообще не имеет никакого отношения к разговору — ты что-то попутал.
Здравствуйте, VladD2, Вы писали:
VD>А ты сам то Моно пробовал?
Я с UNIX знаком достаточно хорошо, чтобы понимать НАСКОЛЬКО он отличается от винды
и поэтому представляю себе сложность портирования BCL на UNIX.
А на винде его использовать вообще смысла нет.
Только не рассказывай мне, что BCL и C# это разные вещи — это я и так понимаю.
Но без BCL, C# большинству его пользователей вообще не упал, в C# нет ничего такого,
что давало бы ему хоть какие-то преимущества например перед Java — вся соль в библиотеках
и интеграции с операционкой, а коли их не будет, то он пойдёт фтопку.
VD>Нда, знания на уровре фантастики. C# 3.0, LINQ, ADO.NET вообще от платформы не зависят.
Ты у меня ещё экзамен прими, эксперт по оценке чужих знаний.
Формально да — не зависят, но без LINQ и в особенности ADO.NET привлекательность .NET как платформы существенно снижается.
Здравствуйте, Cyberax, Вы писали:
>> Как раз у меня есть противоположный собственный опыт. То, что казалось >> бы, может работать монолитом, выигрывает по некоторым параметрам >> (надежность, масштабируемость) будучи распределенным. C>Сравни сложность разработки — распределенные приложения заметно сложнее C>отлаживать и писать.
Узость мышления. Переключитесь на другую парадигму — и наоборот, распределённые системы, построенные на обмене сообщениями будут для вас гораздо проще императивных однопоточных последовательных систем. Вы же пытаетесь в рамках привычных вам сущностей выписать чуждые структуры — и поражаетесь их якобы "сложности". Ну так машина Тьюринга на XSLT тоже аццки сложная получается. Или Форт на Intercal-е.
Здравствуйте, Андрей Хропов, Вы писали:
K>> Не та же. Я не могу между more и ls вставить в этой модели ничего (sort, например). АХ>Почему? АХ>"File result = more.Process( sort.Process( ls.Process(input) ) )" АХ>Как я уже говорил, на мой взгляд вся эта работа через каналы — частный случай КОП.
Нельзя менять код ни одного из компонентов.
K>> Не понял вопроса. Легко и непринуждённо обеспечиваем. АХ>Ну и как вы будете игру (не многопользовательскую, а самую обычную) писать через Unix way?
Опять не понял вопроса? Что мешает? Логика и AI — одним процессом (причём AI — на скриптовом языке), графический движок — другим, всё это вместе завёрнуто в скриптовую обёртку третьим процессом, чтение и разгрёб конфигурации — четвёртым.
K>>>> * корректное сообщение о любых исключительных ситуациях АХ>>>Сообщение мало. Надо еще данные не убить по возможности. АХ>>>Без поддержки исключений обработка ошибок — это геморрой жуткий. АХ>>>Я уж не говорю про RAII. А это предполагает ОО.
K>> ОО тут совершенно не при делах... АХ>Аргументируй.
Не мне это надо делать. Это вам бы показать, как объектная модель позволяет достичь при исключительной ситуации большего чем корректное сообщение. Я таких фичей у ОО не наблюдаю.
Кстати, на заметку: исключение — это очень не-ОО сущность. И в компонентных ОО-моделях аналога исключений как бы даже и нет. Обидно, да?
K>> Не обязательно. Не нужна совместимость, на самом деле. АХ>Как это так? Подаем ASCII а программа хочет Unicode и привет!
А между ними встраивается iconv, и здрасте.
K>> Могу, и как правило вставляю (psnup, ps2ps, мелкие самописные пошкрип-фильтры). Смысла много — postscript обрабатывать весело, легко и просто, буклетик там из него сшить, водяные знаки наложить, или ещё что, а вот pdf потом править обломно будет. Так уж лучше я поправлю ps на этом этапе. АХ>Правильно, но это уже не ЛЮБЫЕ, а специализированные компоненты, предназначенные для обработки ps.
И что? А надо вставлять wc, строки в ps считать? Зачем? Хотя, grep+wc у меня пару раз было в пайплайне за генерёжкой ps сразу — когда надо было статистику количества страниц вести. Только это всё к теме не относится. То, что я описал (psnup и компания) — это чистейший unix way.
K>> Естественно. А Unix way не требует использования обязательно текстовых потоков. АХ>А как же тогда вы между ЛЮБЫМИ двумя компонентами третий вставите?
Опять не понял, где вы затруднения углядели. Что я, не могу враппер подсунуть, который по popen() дёрнется вместо другой программки? Не могу на сокет повесить свою прослойку? Да у меня частенько ssh-форвардинг в качетсве быстрых временных затычек в сложных распределённых системах влезает, а в коде этих систем никому и знать не надо, что соединения перехватываются и данные дополнительно обрабатываются. Бинарные данные, кстати.
AX>>> Теперь уже дальше идем в сторону скрещения ОО с функциональщиной . Даже в скриптовых языках, без которых Unix way никуда .
K>> Простите, какие языки? Какая функциональщина? Мне глубоко наплевать на ОО и функциональщину в языках. Наплевать и растереть. АХ>А позволь поинтересоваться на каких языках ты пишешь?
А какое это имеет значение? См. моё дао — из него ясно следует, что язык роли не играет. Дао работает с любыми языками. Но мы то сейчас не про языки говорим, а про уровень компонентов.
K>> В данном случае источник мирового зла — это OOD, то есть, ОО на уровне проектирования, на компонентном уровне. АХ>Ужас какой-то. И чем тебя OOD угнетает? Это американский заговор, да?
Вы потеряли нить разговора. Начисто. Постарайтесь подумать ещё раз — на каком уровне абстракции мы выстраиваем компонентную модель? Какие методы формализации предметной области мы должны применять, и какие ограничения на эти методы накладывает семантика компонентной модели? Думайте не менее получаса прежде чем ответить — а то опять скажете что-то не в тему и невпопад, опять смешно будет.
K>> Тут пока никаких языков нет и не предвидится. АХ>Где тут?
Здравствуйте, Anton Batenev, Вы писали:
K>> Лучший unix way GUI всех времён и народов (и, кстати, работавший даже под DOS) — Wolfram Mathematica, точнее ейный компонент mathview.
AB>Т.е. это твоя разработка?
Нет конечно же. Мои разработки, увы, такого запредельного качества, неизбежно вызывающего восторг и поклонение, вызвать не могут. Так что я предпочитаю указывать на всем известный шедевр как аргумент в споре о применимости той или иной модели.
AB>1. Я хочу понять, чем эти два подхода так сильно отличаются (понять визуально [если не сложно, то скриншотики с подробными комментариями], поюзать, если возможно [URL для скачивания]).
Для mathview очень легко понять визуально разницу. Там DPS торчит из всех щелей.
AB>2. Хочу оценить сложность создания подобного одним человеком, который говорит, что этот гуй хорош.
Там много очень маленьких и простых гуёвых примочек, сделанных поверх фреймворка mathview. Оцените, как легко и просто делаются такие сложные и красивые вещи.
AB>3. Все обдумать, взвесить, и, при удобном случае, попытаться попользовать.
Для попробовать — проще всего взять Tcl/Tk, и что либо простенькое нарисовать.
Здравствуйте, Cyberax, Вы писали:
C>Иностранные поисковики на слова "agent protocol" выдают всякую фигню, а C>родной ya.ru на "агентный/агентский протокол" выдает, в основном, C>рефераты про искусственный интеллект.
C>Так что прошу примеры агентских протоколов и программ, их использующих.
И, да, это часто относят к искусственному интеллекту — но совершенно напрасно. Область применения агентной модели гораздо ширшее и глубжее.
Особенность протоколов большинства агентных систем в том, что для обмена сообщениями используется сложный, часто тьюринг-полный язык. То есть, агенты как бы программируют друг друга. Это очень сильно упрощает жизнь при разработке сильно распределённых гетерогенных систем.
C>Вообще-то у Явистов есть JMS (Java Message Service) и его адаптация для C>high-performance computing.
C>MPI, кстати, тоже есть. Поищите по словам JavaMPI и mpiJava.
Есть то он есть. Только вот его как бы и нет — производительность оставляет желать всего хорошего, заходите почаще, а лучше мы к вам. Как я матерился, когда в последний момент пришлось всё на C++ переписывать, осознав, что Java не тянет.
Здравствуйте, DJ KARIES, Вы писали:
K>> И кого волнуют простые юзеры винды? Мы про них тут вообще не говорим. DK>Их >90 процентов от пользователей персональных компьютеров на планете. DK>Ваша фраза напоминает "а кому нужно это быдло, тут об интеллигенции базар"
Нет, это ваша фраза напоминает "а фигли вы тут калачами торгуете, когда в соседнем ряду та-аких хряков завезли!". Понимаете? Мы обсуждаем архитектуру компонентных систем. И совместимость разных идеологий с физическими возможностями разных ОС. Сколько там юзеров у какой ОС в контексте данного разговора никого совершенно не колышет. Так что просто признайте, что встряли в тему, в которой вы просто ни ухом, ни рылом, попытались поумничать, и сели в лужу. Полезно, знаете ли. Остужает.
Здравствуйте, Kisloid, Вы писали:
DK>>Их >90 процентов от пользователей персональных компьютеров на планете. DK>>Ваша фраза напоминает "а кому нужно это быдло, тут об интеллигенции базар"
K>Правильно, над еще добавить, что как программисты мы пишем именно для них. Интересно а для кого пишет товарищ колхозник ?
Ещё одна легкоузнаваемая по полёту птица, не врубившаяся в тему. Право слово, смешно-с.
Особенно в свете того, что обсуждалось, как легко и непринуждённо unix way применяется в Win32.
) ?
.
