Здравствуйте, EvilChild, Вы писали:
EC>Здравствуйте, VladD2, Вы писали:
VD>>А ты вкурсе, что сборки от C# 3.0 без перекомпиляции можно запускать под .NET 2.0 и Моно? EC>А как насчёт коммерческих GUI библиотек, которые кишат p/invoke & interop?
Как насчет того чтобы не переводить разговор на другие темы?
VD>>Что до библиотек, то их уже точно больше чем можно найти в поставке какого-нибудь С++-компилятора. EC>Причём здесь С++?
При том, что их отсутсвие не сильно мешает разработывать ПО.
EC> Что он тебе плохого сделал, что ты его упоминаешь к месту и не к месту? Речь идёт EC>о КОП в linux, C++ к нему (КОП) никаким боком (причём именно ты об этом чаще всех говоришь).
Ну, раз о КОП, то с каой целью тут преплитаются какие-то внешние библиотеки? Что подержка КОП трубет внешних бибилотек?
VD>>Внимание, вопрос! С++ обречен? EC>С++ вообще не имеет никакого отношения к разговору — ты что-то попутал.
Ну, вот и твой разговор о библиотеках не имеет никакого отношения к делу.
Не фига притягивать что попало в качестве аргументации против очевидных вещей.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, EvilChild, Вы писали:
EC>Здравствуйте, VladD2, Вы писали:
VD>>А ты сам то Моно пробовал? EC>Я с UNIX знаком достаточно хорошо, чтобы ...поэтому ...представляю себе...UNIX.
Ясно. Значит не пробовал. Так и запишем. Кстати, что за манера вместо "нет" выдавать тирады пустых слов?
EC>Только не рассказывай мне, что BCL и C# это разные вещи — это я и так понимаю.
BCL практически полностью реализован в Моно. Как в прочем и в Роторе.
EC>Ты у меня ещё экзамен прими, эксперт по оценке чужих знаний.
Думаю, ты и сам понимаешь уровень своих знаний в этом вопросе.
EC>Формально да — не зависят, но без LINQ и в особенности ADO.NET привлекательность .NET как платформы существенно снижается.
Здравствуйте, VladD2, Вы писали:
VD>Как насчет того чтобы не переводить разговор на другие темы?
Я это к тому, что .NET как компонентная среда под Linux обладает более ограниченной сферой применения по сравнению с её реализацией под вынь. В посте, на который я отвечал речь шла о том, в каком объёме она реализована под линь. Так, что всё по теме.
EC>>Причём здесь С++?
VD>При том, что их отсутсвие не сильно мешает разработывать ПО.
Но и не помогает. И к КОП под линух отношения не имеет.
VD>Ну, раз о КОП, то с каой целью тут преплитаются какие-то внешние библиотеки? Что подержка КОП трубет внешних бибилотек?
КОП способствует разработке с их использованием
VD>Ну, вот и твой разговор о библиотеках не имеет никакого отношения к делу.
VD>Не фига притягивать что попало в качестве аргументации против очевидных вещей.
Ещё раз — я говорил об объёме раелизации конкретной среды под конкретную платформу, а до того есть ли КОП под линух мне вообще дела нет.
Здравствуйте, VladD2, Вы писали:
VD>Ясно. Значит не пробовал. Так и запишем. Кстати, что за манера вместо "нет" выдавать тирады пустых слов?
Мне достаточно того, что написано на их сайте.
VD>BCL практически полностью реализован в Моно. Как в прочем и в Роторе.
Т.е. я могу создавать Serviced Components и хостить их под моно в линухе? И они смогут участвовать в распределённых транзакциях?
Ты сам в это веришь? Может даже проверял?
VD>А LINQ — это всего лишь обертка над ним и фрэймворком. К тому же еще не существующая официально.
Для тех, кто не читает между строк — основная мысль моего поста такая: большинству пользователей среды не нужен её кастрированный вариант.
Здравствуйте, Kolhoz, Вы писали:
K>>> Лучший unix way GUI всех времён и народов (и, кстати, работавший даже под DOS) — Wolfram Mathematica, точнее ейный компонент mathview. AB>>Т.е. это твоя разработка? K> Нет конечно же.
К сожалению, по ссылке огромный объем информации, из которого понять что-либо очень сложно за короткое время. По этому я и просил что-нибудь свое, что по проще и наглядно.
K> Мои разработки, увы, такого запредельного качества, неизбежно вызывающего восторг и поклонение, вызвать не могут. Так что я предпочитаю указывать на всем известный шедевр как аргумент в споре о применимости той или иной модели.
А я ни с чем и не спорю
AB>>1. Я хочу понять, чем эти два подхода так сильно отличаются (понять визуально [если не сложно, то скриншотики с подробными комментариями], поюзать, если возможно [URL для скачивания]). K> Для mathview очень легко понять визуально разницу. Там DPS торчит из всех щелей.
Что такое DPS?
AB>>3. Все обдумать, взвесить, и, при удобном случае, попытаться попользовать. K> Для попробовать — проще всего взять Tcl/Tk, и что либо простенькое нарисовать.
Я имел ввиду вообще попытаться применить концепцию безотносительно среды.
Kolhoz wrote: > C>Сравни сложность разработки — распределенные приложения заметно сложнее > C>отлаживать и писать. > Узость мышления. Переключитесь на другую парадигму — и наоборот, > распределённые системы, построенные на обмене сообщениями будут для вас > гораздо проще императивных однопоточных последовательных систем.
Я уже давно понял, что делать распределенные или многопоточные системы
на чем-то кроме отсылки сообщений — это обычно гиблое дело.
В случае с многопоточностью — постоянные проблемы с нужными
блокировками, а с распределенными системами — проблемы с реакциями на
сбои. Хотя, конечно, бывают случаи когда обычный RPC намного удобнее.
Но даже просто системы с отсылкой сообщений все равно сложнее
отлаживать, хотя бы из-за необходимости следить за несколькими
приложениями одновременно.
Kolhoz wrote: > C>Так что прошу примеры агентских протоколов и программ, их использующих. > http://en.wikipedia.org/wiki/Agent_based > И, да, это часто относят к искусственному интеллекту — но совершенно > напрасно. Область применения агентной модели гораздо ширшее и глубжее.
В общем понятно, система представляется набором агентов, обменивающихся
сообщениями.
> Особенность протоколов большинства агентных систем в том, что для обмена > сообщениями используется сложный, часто тьюринг-полный язык. То есть, > агенты как бы программируют друг друга. Это очень сильно упрощает жизнь > при разработке сильно распределённых гетерогенных систем.
В МОРГ!!!!
Я работал с такой системой, которая интегрировала две
enterprise-системы. Для общения использовался SOAP, а для управления
control-flow — BPEL4j. Типа grid computing и все такое...
Вот только когда в реальности в одном проекте начинают работать разные
люди — обнаруживается, что это все не очень-то удобно. И часто проще
использовать обычные синхронные сетевые вызовы (что в итоге и произошло
— осталось несколько веб-сервисов, склеивающих две системы, все
остальное было написано в обычно стиле).
> C>Вообще-то у Явистов есть JMS (Java Message Service) и его адаптация для > C>high-performance computing. > C>MPI, кстати, тоже есть. Поищите по словам JavaMPI и mpiJava. > Есть то он есть. Только вот его как бы и нет — производительность > оставляет желать всего хорошего, заходите почаще, а лучше мы к вам.
Ну как бы Java не создавалась для high-perf computing. Поэтому сейчас
Sun и делает Fortress.
Здравствуйте, Cyberax, Вы писали:
>> C>Так что прошу примеры агентских протоколов и программ, их использующих. >> http://en.wikipedia.org/wiki/Agent_based >> И, да, это часто относят к искусственному интеллекту — но совершенно >> напрасно. Область применения агентной модели гораздо ширшее и глубжее. C>В общем понятно, система представляется набором агентов, обменивающихся C>сообщениями.
Здравствуйте, EvilChild, Вы писали:
VD>>Как насчет того чтобы не переводить разговор на другие темы? EC>Я это к тому, что .NET как компонентная среда под Linux обладает более ограниченной сферой применения по сравнению с её реализацией под вынь. В посте, на который я отвечал речь шла о том, в каком объёме она реализована под линь. Так, что всё по теме.
Понятно. Значит не переводить не можешь. Будем считать это признанием отсуствия аргументации по теме. Следовательно вопрос можно считать исчерпаным.
VD>>При том, что их отсутсвие не сильно мешает разработывать ПО. EC>Но и не помогает. И к КОП под линух отношения не имеет.
Естественно. Но главное здесь, то что вопрос наличия или отсуствия библиотек никак не связан с поддержкой компонентного подхода.
Софт для Линукса пишут и на С и на С++ вообще не поддерживающих этот подход. Причем при разработке на этих языках зачастую основная масса библиотек пишется разработчиками этого проекта. Так что если они воспользуются, например, Моно, то не окажутся в худших условиях, так как получа большие по объему бибиблиотеки (и что характерно библиотеки будут лучше стандартизованы и поще в использовании).
EC>Ещё раз — я говорил об объёме раелизации конкретной среды под конкретную платформу, а до того есть ли КОП под линух мне вообще дела нет.
А ты не говори, ты попробу. Понимашь, в чем дело ты говоришь о том, что явно не видел в глаза. А между тем Моно уже нехило продвинулся вперед. В нем конечно меньше классов чем в дотнете, но вполне достаточно для реализации обчень широкого класса ПО.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, EvilChild, Вы писали:
VD>>Ясно. Значит не пробовал. Так и запишем. Кстати, что за манера вместо "нет" выдавать тирады пустых слов? EC>Мне достаточно того, что написано на их сайте.
Цитаты, плиз, а мы оценим адекватны ли твои выводы.
VD>>BCL практически полностью реализован в Моно. Как в прочем и в Роторе. EC>Т.е. я могу создавать Serviced Components и хостить их под моно в линухе?
Serviced Components никогда не входило в состав BCL. Более того Serviced Components — это обертка над COM+, который реализован только под Windows 2000+.
EC> И они смогут участвовать в распределённых транзакциях?
Насколько я понимаю для этого можно использовать библиотеки вроде Кибернэйта.
EC>Для тех, кто не читает между строк — основная мысль моего поста такая: большинству пользователей среды не нужен её кастрированный вариант.
Большинству людей не нужен сам Линукс. Что с того?
В общем, еще раз не притягивай за уши вещи к делу не относящиеся. Ява и Моно прекрасно решают проблему компонентрой разработки. А уж применимость их для решения конкретных задач — это отдельный вопрос.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
, так примеров *реальных* агентных > систем (с интеллектуальными агентами внутрях) там приведено не было. Да > и вообще в этой теме, имхо, мало кто рубит.
У меня уже давно выработалась реакция на болтологический бред
маркетологов. Маркетологические статьи обычно наполнены общими фразами,
обещаниями завоевания мира и т.п.
Статьи про агентные системы по моей маркетологической шкале берут 10 из
10. В Рунете я нашел только нелепые примеры про шахматные программы, где
каждая фигура представлена агентом, отсылающим сообщения другим фигурам
и прочей фигней про искусственный интеллект. В Google'е нашел только
полузаброшенные проекты систем управлениями grid-вычислениями и прочим.
Реальных success stories с агентами что-то не очень видно.
_rasta wrote: > ну... собственно консолью и обеспечиваем, нет? > find /usr/src/linux -name "*.c" -exec grep -H "fuck" {} \; | wc -l > чем не интерактивность? > с другой стороны. что для этого предлагает КОМ? таки да, компонентность > есть, но... а где интерактивность?
Смотри Monad Shell
Здравствуйте, Cyberax, Вы писали:
C>У меня уже давно выработалась реакция на болтологический бред C>маркетологов. Маркетологические статьи обычно наполнены общими фразами, C>обещаниями завоевания мира и т.п.
+1
C>Статьи про агентные системы по моей маркетологической шкале берут 10 из C>10. В Рунете я нашел только нелепые примеры про шахматные программы, где C>каждая фигура представлена агентом, отсылающим сообщения другим фигурам C>и прочей фигней про искусственный интеллект. В Google'е нашел только C>полузаброшенные проекты систем управлениями grid-вычислениями и прочим.
C>Реальных success stories с агентами что-то не очень видно.
Реальные success stories есть, только для агентных систем, которые построены не на интеллектуальных агентах, а на совсем других
. В частности, у нас в компании работает несколько систем, написанных на агентах. Только маркетологического шума мы пока поэтому поводу не упели поднять , так, легкий шумок
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Прежде чем читать этот ответ, предлагаю тебе освежить в памяти текст сообщения, на которое я отвечал, а то ты опять начнёшь отвечать на, то о чём речь и близко не шла.
VD>Цитаты, плиз, а мы оценим адекватны ли твои выводы.
Кто такие "мы"? Или ты о себе во множественном числе? EnterpriseServices:
At this point Mono does not support the EnterpriseServices namespace. System.Windows.Forms:
The current implementation is still somewhat incomplete, with several large controls (Edit, ListBox/ComboBox, TreeView), etc, still being developed. It is too early to file bugs if you cannot compile or run a certain application because of controls missing. Unsupported technologies
Some technologies are very hard to implement or are being phased out by components in the Longhorn time frame. In some cases, we feel that they are not crucial to the future of the open source desktop.
System.EnterpriseServices and System.Management come to mind, and we are unlikely to put any resources into the task. We would gladly host the code if someone cares to implement it, but they would likely remain unsupported features of Mono.
А по поводу пробовал/не пробовал — я заводил rotor под FreeBSD как только он был анонсирован, поэтому представление имею.
А вот ты пробовал mono под Linux? или ты настолько наивен, чтобы верить всему, что пишут на сайтах разработчики?
VD>Serviced Components никогда не входило в состав BCL. Более того Serviced Components — это обертка над COM+, который реализован только под Windows 2000+.
Serviced Components входят в .NET Framework, а уж что это и с каких версий винды поддерживается совершенно не важно, непонимаю к чему ты приводишь эту соверщенно несущественную в данном контексте информацию.
EC>> И они смогут участвовать в распределённых транзакциях? VD>Насколько я понимаю для этого можно использовать библиотеки вроде Кибернэйта.
Ты неправильно понимаешь — я про транзакции, что поверх DTC работают. В MS реализации .NET Framework это есть, а в моно болт.
Я говорю именно об этом — 2 реализации совершенно неравномощны в плане функциональности, а все разговоры о стандартах это для пионеров.
EC>>Для тех, кто не читает между строк — основная мысль моего поста такая: большинству пользователей среды не нужен её кастрированный вариант. VD>Большинству людей не нужен сам Линукс. Что с того?
Ты опять не посуществу: как это относится к той теме, о которой я говорил?
VD>В общем, еще раз не притягивай за уши вещи к делу не относящиеся. Ява и Моно прекрасно решают проблему компонентрой разработки. А уж применимость их для решения конкретных задач — это отдельный вопрос.
Ещё раз, для тех у кого в танке сильно накурено, я овечал на конкретную фразу из сообщения Еще посмотрим, когда Mono доделают как он на Unix системах развернется.
Я выразил сомнение в том факте, что моно когда-либо развернётся на юнихах, так же как под виндой, про компонентный подход в линукс вообще ни слова.
Но тут пришёл ты, со своей туманной философией, странно ещё, что про Nemerle ничего не сказал.
Т.е. я, например, не верю, что можно завести RSDN@home под моно на линухе и дело даже не в отсутствии Jet.
Думаю с этим ты спорить не будешь?
В общем все твои посты, не относящиеся к теме того поста, на который я отвечал я буду просто скипать.
eao197 wrote: > C>Реальных success stories с агентами что-то не очень видно. > Реальные success stories есть, только для агентных систем, которые > построены не на интеллектуальных агентах, а на совсем других > <http://rsdn.ru/forum/?mid=1570455>
. В частности, у нас в компании > работает несколько систем, написанных на агентах. Только > маркетологического шума мы пока поэтому поводу не упели поднять , так, > легкий шумок
У вас скорее немного другое — система создания message-driven приложений.
В принципе, в мире оно Java уже существует в виде JMS и EJB MDB. JMS
предоставляет очереди сообщений и/или систему subscriber/publisher, а
EJB-контейнер — распределенность, многопоточность и управление контекстом.
Хотя JMS делает ставку скорее на надежность, а не на скорость и обычно
предназначена для распределенного использования.
PS: интересно, а можно ли прикрутить SObjectiser к ActiveMQ? У ActiveMQ
есть C-шный интерфейс и общий результат может получится интересным.
Mamut wrote: > C>Сравни сложность разработки — распределенные приложения заметно сложнее > C>отлаживать и писать. > А как же Эрланг?
Самый правильный вариант Но все равно сложно.
Здравствуйте, Kolhoz, Вы писали:
K> Ещё одна легкоузнаваемая по полёту птица, не врубившаяся в тему. Право слово, смешно-с.
Товарищ Колхозник, я понимаю что я еще молод и мало у меня опыта, и по сравнению с Вами, с гуру, мне не тягаться, а мне и не надо тягаться, всего то я хотел узнать про КОП в линукс мире, я начал изучать линукс, и даже что то под него писать, понимаете я щас под виндами работаю над очень большим проектом, и не могу себе представить проект такого уровня без КОП, мне стало жутко интересно, как же в линуксе писать такие проекты, я стал искать, нашел нечто похожее в XPCOM. Просто у меня возникает некое такое чувство, что под линуксом не так уж и хорошо с КОП, ибо мало больших проектов, и то все в основном с таким ужасным количеством багов. Но не в этом суть, просто меня тошнит от манеры вашего ведения беседы (которое и беседой не назвать). Примерно то же самое видел в linuxforum.ru. Отныне буду просто игнорировать ваши сообщения.
Я очень уважаю Линуса, очень толковый человек, говорит очень правильные на мой взгляд вещи, но почему у Линукс сообщества такие люди как kolhoznik очень часто встречаются, ведь хоть какой бы ни была ОС, без нормального сообщества оно просто пустое место. Ладно, продолжу свое приключение в удивительный мир линуксов, стараясь не обращать внимания на таких людей как колхозник.
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Kisloid wrote:
> Вот мне очень интересно. Есть ли под линуксами компонентно > ориентированное программирование ? Исходя из личного опыта, не могу себе > представить крупный проект без компонентно ориентированного подхода. Под > windows например COM, .NET. Знаю под линуксом есть мозилловская > разработка XPCOM. Доводилось с ней работать, но все же она не дотягивает > до COM по качеству, скорости. Может я чего то упустил ?
Мои пять копеек. Имхо идеология Линукс в принципе не озабачивается этим, как операционная система оно не хочет
"ограничивать" пользователей одной технологией, как это делает майкрософт.
Т.е. сама идеология — конструктор "собери-сам", майкрософт же пытается всё запихать в операционку.
Если тебе понадобится выбрать КОП платформу — пожалуйста, java, mono, corba, XPCOM, SOAP, всё что угодно. Линукс —
прежде всего операционная система, притом действительно многоплатформенная.
В общем, Линукс ОС и КОП — вещи перпендикулярые, что хочешь, то прилаживаешь, а КОП в Виндоуз ОС — фактически
неотъемлимая часть.
Спор о том, что более правильное — спор ни о чём, это два решения одной задачи, и оба верные.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Cyberax, Вы писали:
>> Узость мышления. Переключитесь на другую парадигму — и наоборот, >> распределённые системы, построенные на обмене сообщениями будут для вас >> гораздо проще императивных однопоточных последовательных систем. C>Я уже давно понял, что делать распределенные или многопоточные системы C>на чем-то кроме отсылки сообщений — это обычно гиблое дело.
+1
Только понимать тут нечего — это тривиально доказуется формально.
C>В случае с многопоточностью — постоянные проблемы с нужными C>блокировками, а с распределенными системами — проблемы с реакциями на C>сбои. Хотя, конечно, бывают случаи когда обычный RPC намного удобнее.
RPC — это транспортный уровень.
C>Но даже просто системы с отсылкой сообщений все равно сложнее C>отлаживать, хотя бы из-за необходимости следить за несколькими C>приложениями одновременно.
Не сложнее. Для них гораздо лучше развиты формальные методы анализа. А симптоматическая отладка — это вообще зло, её надо искоренять.
Извините за личный вопрос, но не могли бы вы чуть приоткрыть маску? По вашим постам складывается впечатление, что вы являетесь аспирантом в каком-то продвинутом профильном ВУЗе (об этом говорит, например, опыт общения с LaTeX (в том числе и по набору формул), упоминание использования пакета Matematica, теперь вот упоминания про формальные доказательства и теоритические обоснования).
Я спрашиваю потому, что у меня есть некоторый негативный опыт общения с полностью анонимными участниками форума (у которых за ником вообще невозможно различить реального человека). Неприятной особенностью таких персонажей является склонность к весьма серьезным заявлениям и черезмерная категоричность в суждениях. Что в конце-концов резко снижает ценность их сообщений (даже при наличии в них актуальной информации).
Конечно я не в праве просить от вас подобных сведений, но все же если бы вы чуть рассказали о себе (например, образование, наличие/отсутсвие ученых степеней, предметные области, в которых вам доводилось работать), то это позволило бы лично мне определить уровень доверия к вашим высказываниям. Не обижайтесь, пожалуйста, ничего личного.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
