Вот мне очень интересно. Есть ли под линуксами компонентно ориентированное программирование ? Исходя из личного опыта, не могу себе представить крупный проект без компонентно ориентированного подхода. Под windows например COM, .NET. Знаю под линуксом есть мозилловская разработка XPCOM. Доводилось с ней работать, но все же она не дотягивает до COM по качеству, скорости. Может я чего то упустил ?
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, Kisloid, Вы писали:
K>Вот мне очень интересно. Есть ли под линуксами компонентно ориентированное программирование ? Исходя из личного опыта, не могу себе представить крупный проект без компонентно ориентированного подхода. Под windows например COM, .NET.
Ну так под Linux реализация .NET в виде Mono развивается постепенно.
Здравствуйте, Kisloid, Вы писали:
K>Исходя из личного опыта, не могу себе представить крупный проект без компонентно ориентированного подхода.
Так поднапрягите воображение. На COM и .NET мир клином не сошелся.
У программистов Windows есть понятная склонность считать технологии МС верхом человеческой мысли. А то, что эти технологии меняются как в калейдоскопе их не заботит. Unix консервативен, в его мире книги Стивенса, вышедшие в начале 90-х, до сих пор сохраняют свою полезность и эта консервативность не мешает делать крупные проекты.
Здравствуйте, Kisloid, Вы писали:
K>Вот мне очень интересно. Есть ли под линуксами компонентно ориентированное программирование ? Исходя из личного опыта, не могу себе представить крупный проект без компонентно ориентированного подхода. Под windows например COM, .NET. Знаю под линуксом есть мозилловская разработка XPCOM. Доводилось с ней работать, но все же она не дотягивает до COM по качеству, скорости. Может я чего то упустил ?
А кто сказал, что COM и .Net — компонентные технологии?
Они обе завязаны на реестр и Windows. Даже в Mono сталкиваются с неожиданными трудностями по реализации точка-нет, не говоря уже о реализации COM на не-MS-платформах. Эти т.н. "компонентные технологии" не являются таковыми, так как компонентные технологии должны быть не зависимы от низкоуровневой программной платформы, на которой они работают.
В Linux компонентно всё: от ядра до процессов пользовательского уровня. Например, оконная система X Window работает с ядром и пользовательскими процессами по чётко специфицированным протоколам, позволяющим запускать пользовательские процессы на одном компьютере, а следить за ним с красивым GUI на другом компьютере. Приложения ведут себя иначе — не как в Windows, где Explorer или глючное пользовательское приложение легко может свалить всю систему в BSOD.
P.S. В GNOME Desktop Environment штатно работает ORBit — CORBA сервер — аналог поддержки OLE/DCOM в Windows.
Здравствуйте, Quintanar, Вы писали:
Q>Так поднапрягите воображение. На COM и .NET мир клином не сошелся. Q>У программистов Windows есть понятная склонность считать технологии МС верхом человеческой мысли. А то, что эти технологии меняются как в калейдоскопе их не заботит. Unix консервативен, в его мире книги Стивенса, вышедшие в начале 90-х, до сих пор сохраняют свою полезность и эта консервативность не мешает делать крупные проекты.
Забавно, что есть много слов. Даже трое согласных с ними. И ни грамма по КОП.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Kisloid, Вы писали:
K>Вот мне очень интересно. Есть ли под линуксами компонентно ориентированное программирование ? Исходя из личного опыта, не могу себе представить крупный проект без компонентно ориентированного подхода. Под windows например COM, .NET. Знаю под линуксом есть мозилловская разработка XPCOM. Доводилось с ней работать, но все же она не дотягивает до COM по качеству, скорости. Может я чего то упустил ?
Под Линукс прекрасно работают Ява и Моно. Этого более чем достаточно. Потом практически любой скриптовый язык решает задачи в том числе аналогичные КОП.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Под Линукс прекрасно работают Ява и Моно. Этого более чем достаточно. Потом практически любой скриптовый язык решает задачи в том числе аналогичные КОП.
По последним новостям проекта Mono до сих пор не решены проблемы работы "компонентов" WinForms.
Здравствуйте, eao197, Вы писали:
E>Да, Unix way: [skipped]
Вот тогда следующий вопрос, возьмем к примеру Мозилловские проекты, зачем им надо было создавать свою реализацию КОМа если есть unix way (хотя наверное вопрос к ним ) ?
Какие примеры больших проектов написанных исключительно через unix way ? GAIM ?
После прочтения сложилось такое впечатление, что это ИМХО не очень удобно и влечет за собой кучу проблем.
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, Kisloid, Вы писали:
E>>Да, Unix way: [skipped]
K>Вот тогда следующий вопрос, возьмем к примеру Мозилловские проекты, зачем им надо было создавать свою реализацию КОМа если есть unix way (хотя наверное вопрос к ним ) ?
Может быть из-за того, что Mozilla (изначально Netscape) не является типично unix-овым проектом. Он пытается внести в Unix поведение Windows. Аналогичные попытки сделать какую-то компонентность для GUI есть в KDE. Называется KParts.
K>Какие примеры больших проектов написанных исключительно через unix way ? GAIM ?
С GIMP-ом и GAIM-ом не знаком, поскольку не пользовался. Но вот в качестве примера можно вспомнить Subversion, который способен использовать ssh для организации защищенного доступа к репозиториям. А так же svnadmin dump, который выплевывает содержимое репозитория в виде теста на стандартный вывод. Что позволяет интегрировать его с разными инструментами в виде архиваторов, фильтров и прочего. Либо почтовый клиент Mutt, который использует внешний текстовый редактор для редактирования почты. А так же разные преобразователи форматов, входящих в состав TeX-а.
Что касается удобства, то, имхо, нужно разделять Server-Side приложения и GUI приложения. В server-side приложениях Unix way весьма удобен. GUI, из-за того, что пользователи привыкли к Window-ому OLE, пытается придумывать какие-то комбайны.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Kisloid, Вы писали:
. K>Вот тогда следующий вопрос, возьмем к примеру Мозилловские проекты, зачем им надо было создавать свою реализацию КОМа если есть unix way (хотя наверное вопрос к ним ) ?
А unix way — это непортабельно. Не везде есть приличный fork(), не везде нормально работают пайпы, не везде есть shell с набором стандартных утилит для связки компонентов (sed-ы всяческие с awk-ами).
K>Какие примеры больших проектов написанных исключительно через unix way ? GAIM ?
Сам Unix. Это же конструктор такой — что хочешь, то из него и лепишь.
K>После прочтения сложилось такое впечатление, что это ИМХО не очень удобно и влечет за собой кучу проблем.
Это впечатление обманчиво. Пока что я не встречал более удобной компонентной модели чем Unix way.
Во первых — удобная отладка — протоколы обмена между компонентами как правило текстовые.
Во вторых — масштабируемость на халяву.
В третьих — лёгкость сопряжения с посторонними компонентами и сопровождения изменений в них — достаточно встроить маленькую программку-фильтр, приводящую протокол обмена к нужному тебе формату.
В пятых — нет привязки к какому либо конкретному языку и рантайму.
Короче, недостатков этой модели я не вижу. Преимуществ — вагон.
Здравствуйте, iZEN, Вы писали:
ZEN>А кто сказал, что COM и .Net — компонентные технологии? ZEN>Они обе завязаны на реестр и Windows. Даже в Mono сталкиваются с неожиданными трудностями по реализации точка-нет, не говоря уже о реализации COM на не-MS-платформах. Эти т.н. "компонентные технологии" не являются таковыми, так как компонентные технологии должны быть не зависимы от низкоуровневой программной платформы, на которой они работают.
ZEN>В Linux компонентно всё: от ядра до процессов пользовательского уровня. Например, оконная система X Window работает с ядром и пользовательскими процессами по чётко специфицированным протоколам, позволяющим запускать пользовательские процессы на одном компьютере, а следить за ним с красивым GUI на другом компьютере. Приложения ведут себя иначе — не как в Windows, где Explorer или глючное пользовательское приложение легко может свалить всю систему в BSOD.
ZEN>P.S. В GNOME Desktop Environment штатно работает ORBit — CORBA сервер — аналог поддержки OLE/DCOM в Windows.
Вопрос.
Если "В Linux компонентно всё" и "компонентные технологии должны быть не зависимы от низкоуровневой программной платформы, на которой они работают", то почему я не наблюдаю XWindows под ОС Windows или MSDOS?
Дядя Билл запретил?
Здравствуйте, DJ KARIES, Вы писали:
DK>Вопрос. DK>Если "В Linux компонентно всё" и "компонентные технологии должны быть не зависимы от низкоуровневой программной платформы, на которой они работают", то почему я не наблюдаю XWindows под ОС Windows или MSDOS? DK>Дядя Билл запретил?
Не XWindows, а XWindow. X-сервера под Windows есть, и не один. Например, WinaXe, XWinLogon, XWin32, eXceed.
Здравствуйте, DJ KARIES, Вы писали:
DK>Если "В Linux компонентно всё" и "компонентные технологии должны быть не зависимы от низкоуровневой программной платформы, на которой они работают", то почему я не наблюдаю XWindows под ОС Windows или MSDOS? DK>Дядя Билл запретил?
Здравствуйте, eao197, Вы писали:
E>Может просто плохо смотришь? http://www.interix.com/InteropToolworks.htm, http://x.cygwin.com/ E>
Дело в том, что распростанённость этого чуда весьма низка...
Отсюда мораль, выживает тот, кто выживает (кого-то). (тобишь мелкомягкие)
Здравствуйте, DJ KARIES, Вы писали:
DK>Дело в том, что распростанённость этого чуда весьма низка...
Ваша заява никак не вписывается в логику предыдущего вашего же утверждения.
Знаете, есть такой пренеприятнейший тип людей, кто не способен признавать свои ошибки и всячески старается их замазать и заболтать. Так, к сведению.
DK>Отсюда мораль, выживает тот, кто выживает (кого-то). (тобишь мелкомягкие)
А что, с X-Window что-то случилось? Вроде бы очень даже неплохо выживает. Что бы там всякие малограмотные не вещали.
) ?
