[mdk-re] Re: [mdk-re] Re: [mdk-re] По поводу электронной почты.

[Maksim Otstavnov <maksim@otstavnov.com>]

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