[mdk-re] Re: [mdk-re] Re: [mdk-re] По поводу электронной почты.
Maksim Otstavnov
=?iso-8859-1?q?maksim_=CE=C1_otstavnov=2Ecom?=
Ср Дек 13 09:04:01 MSK 2000
Hello Mikhail,
Monday, December 11, 2000, 3:39:31 AM, you wrote:
>> MZ> Готов поспорить (но лучше не здесь). COM/DCOM достаточно удачен
>> MZ> (за вычетом кроссплатформенности), и его в свое время "словили"
>> MZ> разработчики Mozilla.
>>
>> Мне это не кажется образцом "правильного" подхода, прежде всего, из-за
>> проблемы "больших словарей" ("разработчики приложений" учат словари
>> классов вместо того, чтобы программировать).
MZ> Смею думать, это общая проблема всех компонентных архитектур. Да и такая
MZ> ли уж проблема? В эпоху становления модульных программ тоже, наверное,
MZ> раздавались сердитые возгласы по поводу того, что программисты роются в
MZ> куче библиотек вместо того, чтобы реализовать алгоритмы :)
Я бы сказал так: есть библиотеки и библиотеки. Если библиотека
прикладной ориентации, она может быть сколь угодно большой: ее словарь
мне не нужно держать "в активе". Например, если я пишу статистический
софт, предполагается, что я знаю язык статистики и всегда могу найти
то, что уже сделано другими.
Если же говорить, допустим, о системных вызовах, то даже две с
половиной сотни оных в Linux повергают меня в ужас, такой я мракобес
;) не говоря уже о на порядок большем их числе в другой известной
системе ;) Я думаю, подобно тому, как в нормально спроектированном
государстве должно быть конституционное ограничение на объем
законодательства (в килознаках или килограммах), нормальное сообщество
как-то должно себя ограничивать в таких вещах.
На мой взгляд, это _проблема_, и прежде всего проблема культуры
программирования.
Если посмотреть на сертифицированные учебные пособия для сдачи
экзаменов по этой другой ОС в плане стиля изложения и дидактики, то
это больше всего напоминает биологию, причем додарвиновскую (и
отсутствие исторического контекста в них весьма характерно и, конечно,
оправдано, поскольку кому ж приятно осознавать себя частью тупиковой
ветви развития), линнеевскую.
Но Линней полагал, что изучает и классифицирует разнообразие видов,
созданных Творцом, а в этих учебниках тем же тоном описываются вещи,
созданные весьма посредственными архитекторами. С самым пластичным и
благодарным материалом - кодом - который, на самом деле, требует от
мастера такта и вкуса, и _все_, учат обращаться как с хрупким
субстратом, имеющим предзаданные формы.
Это серьезная проблема IMHO.
>> С Mozilla отдельный
>> разговор, но (pipes+sockets+интерпретация (или компиляция на лету)
>> "удаленного" кода+защищенный (меж)сетевой обмен) кажется мне гораздо
>> более аккуратным решением большинства из тех задач, которые ставили
>> разработчики DCOM (оставляя в стороне вопросы производительности, с
>> которой все равно получилось как всегда).
>>
>> Интересно, что все эти механизмы _уже существовали_ до того, как такие
>> задачи были поставлены ;)))
MZ> Если Вы о CORBA (в числе прочего), то многие до сих пор воротят от нее
MZ> нос. Вполне возможно и желательно, чтобы CORBA преобладала как средство
MZ> связывания компонентных, гетерогенных, удаленных и т.п. программ, но...
MZ> с первого раза освоить спецификацию я не смог.
Да, я такой мракобес, что и спецификации Корбы мне кажутся раздутыми.
Но их авторов _можно понять_, учитывая универсальность, на которую
претендует Корба (см. advocacy Мигеля в сторону [D]COM:
http://lwn.net/2000/0720/,
http://www.helixcode.com/~miguel/bongo-bong.html и тонкое напоминание
о KISS-принципе в этой связи Эрика: http://lwn.net/2000/features/ESR/
("Miguel is trying something very gutsy. He's trying to move a
substantial portion of the Unix world from using the traditional sort
of interface that depends on text streams and piping and sockets to
using a different kind of interface like CORBA and interprocess
message passing. The jury is still out whether this is a good
idea.")).
Я бы тоже, скорее, расслоил это на замысел и реализацию, т.е. и CORBA
может работать поверх традиционных механизмов или другими, пока
неизвестными науке способами, и DCOM мог бы работать поверх них...
если бы они были в его среде ;)
С точки зрения стиля разработки, на сегодня "think CORBA" скорее
противостоит традиционному способу думанья об этом, и я полностью
согласен с Эриком, что the jury is still out to consider it.
Но, вообще, если я скажу, что, допустим, скриптование в Web - тоже
пример _компонентной архитектуры_, кто первый бросит в меня камень?
MZ> Или вспомнить хрестоматийную "о семи уровнях" модель OSI и TCP/IP.
А вот это скорее пример "мирного сосуществования", поскольку более
тонкую дифференциацию семислойки иногда полезно применить как
инструмент описания того, что реально делалось в ориентации на
пятислойку. И даже получить некоторый результат (например, развитие
SSL -> SSL/TLS).
--
-- Maksim
Подробная информация о списке рассылки community