MSGID: _d0p3bh$9om$1@asu2.mayor.vorkuta.ru_ 322bce2f

REPLY: 2:5003/17.1@FidoNet 4230014e

REPLYADDR Alex_Morozov@f34.n5003.z2.fidonet.org

REPLYTO 2:5003/34 Alex Morozov

CHRS: CP866 2

RFC: 0 0

GATEWAY: RFC1036/822 fidogate.mayor.vorkuta.ru [FIDOGATE 4.4.4-snp19+bp3]
From: "Alex Morozov"


SPLIT: 10 Mar 05 12:20:01 @5003/34     41    01/02 +++++++++++
Hello, Den!
You wrote to (Alex Morozov) on Thu, 10 Mar 2005 08:09:53 +0300:

DG> 09 мар 2005 20:41, Alex Morozov -> Pavel Filatov:

DG> Саша, что-то у тебя с кодировочкой косяк.

AM>> @GATEWAY: RFC1036/822 fidogate.mayor.vorkuta.ru [FIDOGATE
AM>> 4.4.4-snp19+bp3]
AM>>
AM>> ¦¬¦-¦-TЛTИ¦-¦¦TВ ¦¬TА¦-¦+TГ¦¦TВ¦¬¦-¦-¦-TБTВTМ, ¦¦¦-¦¦ TTВ¦-
AM>> ¦-¦-¦¦TЙ¦-¦¬¦-TБTМ. ¦а¦¦¦-¦¬TМ¦-¦-¦¦ ¦¬ ¦¬¦-¦-TЗ¦¬TВ¦¦¦¬TМ¦-¦-¦¦
AM>> ¦¬¦-¦-TЛTИ¦¦¦-¦¬¦¦ ¦¬TА¦-¦¬¦¬¦-¦-¦+¦¬TВ¦¦¦¬TМ¦-¦-TБTВ¦¬ ¦-TЛ

Ок. Ещё раз, для тех кому лень перекодировать ;-)

Собсно статья немного не о том, но она многое объясняет.

========================================
     Как Microsoft проиграла битву за API


Автор: Джоэл Сполски
Переводчик: Алексей Бушмин
10. 01. 2005


Перед вами модная теория:
своем набеге на десктопы, и web-приложения заменят настольные приложения
(desktop application), могучая империя падет>.

И хотя существует часть правды в том, что Linux представляет большую угрозу
для Microsoft, предсказания о падении компании из Рэдмонда, по меньшей мере,
преждевременны. У Microsoft невероятное количество денег в банке, и они до
сих пор  невероятно  прибыльны. Падение будет долгим. Они могут халтурить
десятилетие, прежде чем  попадут в зону относительной опасности, и кто
знает: в последнюю минуту они могут реинкарнироваться в компанию по
производству мороженого. Поэтому не торопитесь списывать их со счетов. В
начале 90-х все  думали, что  с IBM покончено:  мейнфреймы стали историей.
Тогда же Роберт Крингли предсказал, что эра мейнфреймов закончится 1 января
2000 года, когда все программы на COBOLе заклинит, а вместо исправлений
этих приложений, чьи исходники, как говорят,  давно потеряны, легче будет их
переписать  на клиент-серверной платформе.

Хорошо, допустим. Мейнфреймы до сих пор с нами, ничего не произошло 1 января
2000 года, а IBM перестроилась в большую, технологически всеядную,
консалтинговую  компанию, производящую даже дешовые  пластиковые телефоны.
Так что теория кончины Microsoft, выведенная из  экстраполяции по малому
количеству точек,  является чрезмерной гиперболизацией.

Впрочем, существует  мало понимаемый и в целом незамеченный феномен:
стратегический бриллиант короны Microsoft - Windows API - потерян.
Краеугольный камень монополии и невероятной  прибыли от продаж Windows и
Office, фактически  обеспечивающих львиную долю в доходах  Microsoft и
покрывающих огромное число неприбыльных и малоприбыльных линеек продуктов, -
Windows API  -больше не интересен разработчикам. Курица, которая несла
золотые яйца, еще не мертва, но уже смертельно больна, и это никто еще не
заметил.

А теперь, позвольте мне извиниться за насыщенность и помпезность предыдущих
абзацев. Похоже я начинаю выглядеть как писатель передовиц, который
продолжает и продолжает кричать о стратегическом активе Microsoft:  Windows
API. Доказательство моих слов займет несколько страниц. Пожалуйста, не
делайте никаких умозаключений, пока я не объясню, о чем я говорю. Это будет
длинная статья. Мне понадобиться объяснить, что такое Windows API,
продемонстрировать, почему это наиболее  важный стратегический актив
Microsoft . Я должен объяснить, как он был потерян, какие будут
последствия. Hо так как я говорю о долгосрочных тенденциях, я вынужден буду
гиперболизировать и обобщать.



Разработчики, разработчики, разработчики, разработчики



Помните определение операционной системы? Это нечто, управляющее ресурсами
компьютера так, что программы  могут запускаться и работать. Людям в
действительности наплевать на операционную систему, им не наплевать на те
приложения, которые операционная система позволяет запускать. Текстовые
редакторы. Интернет-пейджеры. Электронная почта. Счета к уплате. Веб-сайты с
картинками Paris Hilton. Сама по себе операционная система не так полезна.
Люди покупают операционные системы  из-за полезных приложений, работающих на
этой операционной системе. Следовательно, самая полезная операционная
система та, на которой запускается наибольшее количество полезных
приложений.

Логическое заключение состоит в том, что если вы пытаетесь продавать
операционную систему, то вам необходимо сделать так, чтобы  разработчики
программного обеспечения  захотели писать  программы для вашей операционной
системы. Поэтому Стив Баллмер прыгал по сцене и кричал: <Разработчики,
разработчики, разработчики, разработчики>. Это так важно для Microsoft, что
единственная причина, из-за которой средства разработки программного
обеспечения не раздаются  бесплатно, заключается в том, что они не хотят
случайно перерезать кислород разработчикам конкурирующих инструментов
разработки (хорошо, тем, которые остались), так как разнообразие
инструментов разработки, доступных для их платформы, делает ее куда более
привлекательной для разработчиков. Hо на самом деле они хотят раздавать.
Благодаря их программе Empower ISV вы можете получить пять наборов MSDN
Universal (иначе известных  как <практически все продукты Microsoft,
исключая Flight Simulator>) всего за 375$. Компиляторы командной строки  для
языков .NET включены с бесплатными библиотеками .NET : тоже бесплатно.
Компилятор С++ теперь бесплатен. Что угодно  для поощрения разработчиков
работать под .NET и ликвидации таких компаний как Borland.



Почему Apple и Sun не могут продавать компьютеры



Да, это немного глупо: конечно Apple и Sun могут продавать компьютеры, но не
на двух наиболее прибыльных рынках, а именно на рынках корпоративных и
домашних пользователей. Aplle до сих пор  где-то там внизу, с очень
маленьким процентом рынка (Пожалуйста, поймите, что я говорю о больших
числах, и следовательно, когда я говорю <никто>, я на самом деле имею в виду
<меньше чем 10 000 000 людей> и так далее и так далее).

Почему? Потому что на компьютерах Apple и Sun не работают программы для
Windows, или, если работают, то в режиме дорогой и не безупречной эмуляции.
Помните, что люди покупают компьютеры для программ на которых они работают,
а для Windows настолько больше программного обеспечения, чем для Mac, что
очень трудно быть пользователем Mac. Вот почему Windows API такой ценный
актив Microsoft.



Врезка: Что такое ?

Если вы пишите программу, скажем текстовый редактор, и вы хотите высветить
меню  или записать файл, вы должны попросить операционную систему сделать
это за вас, используя очень специфический набор вызовов функций, который
различается на каждой операционной системе. Эти вызовы функций называются
API: это интерфейс, который операционная система,  например  Windows,
представляет разработчикам приложений, строящим текстовые процессоры,
электронные таблицы и всякую всячину.  Это набор тысяч и тысяч функций и
подпрограмм, которые программисты могут использовать, чтобы заставить
операционную систему делать такие интересные вещи как высвечивание меню,
чтение и запись файла, или более эзотерические вещи, например,  выяснить,
как произнести конкретную дату по сербски, или черезвычайно сложное
задание - вывести веб-страницу в окно. Если Ваши программы используют вызовы
API для Windows, то они не будут работать в Linux,  у него  другие вызовы
API.  Иногда они делают примерно одинаковые вещи. По этой причине  программы
для Windows не запускаются под Linux. Если Вы хотите заставить
Windows-программу работать под Linux,  то вы должны заново реализовать весь
Windows API, который состоит из тысяч сложных функций:  это все равно, что
написать Windows заново, что заняло у Microsoft тысячи человеколет. И если
вы сделаете одну маленькую ошибку или  упустите одну функцию, в которой
нуждается приложение, то эта программа вылетит по ошибке.



(Я знаю, знаю, на этом  месте  2,3% мира -  пользователи Macintosh -
разогревают свои почтовые программы, чтобы послать мне  уничтожающее письмо
о том, как они любят свои Mac'и. Еще раз: я говорю о больших цифрах и
обобщаю, так что не тратьте свое время. Я знаю, как Вы любите свои Mac'и. Я
знаю, что там есть все, что Вам нужно. Я люблю Вас, но Вы всего лишь 2,3%
мира, и статья не про Вас).



Две силы в Microsoft



В Microsoft есть два противостоящих лагеря, я их буду называть лагерь
Реймонда Чена и лагерь журнала  MSDN.

Реймонд Чен -  разработчик в команде Windows с 1992 года. Его веблог The Old
New Thing набит детальными техническими историями  о порядке вещей в
Windows, даже глупые вещи имеют  под собой веские основания.

Больше всего на веблоге Реймонда впечатляет история о невероятных усилиях,
приложенных командой разработки Windows для поддержания обратной
совместимости.



<Взгляните с  точки зрения покупателя. Вы купили программы X, Y и Z. Затем
вы обновились до Windows XP. Теперь ваш компьютер внезапно зависает, и
программа Z вообще не работает. Вы скажите своим друзьям:
до Windows XP. Она внезапно зависает и не совместима с программой Z>. Будете
ли вы дебажить вашу систему, чтобы определить, что программа X причина
зависаний, а программа Z не работает, потому что использует
недокументированные сообщения Windows? Конечно нет.  Вы вернете коробку с
Windows XP и получите обратно деньги. (Вы купили программы X, Y и Z
несколько месяцев назад. 30-дневный срок возврата уже для них не действует.
Единственное, что вы можете вернуть, это Windows XP.)>



Я впервые услышал об этом от одного из разработчиков популярной игры
SimCity, который поведал мне о критической ошибке в их программе:  она
использовала память сразу после ее освобождения. Главное табу, нарушение
которого прощалось в DOS, но карается  в Windows, где освобожденную  память
тут же стащит другое работающее приложение. Тестеры в команде разработки
Windows протестировали множество популярных приложений, чтобы убедиться, что
все работает без сбоев, но SymCity  зависала. Они сообщили это разработчикам
Windows, которые  дизассемблировали SymCity, шаг за шагом в дебаггере найдя
ошибку, и добавили  специальный код, проверяющий наличие SymCity в памяти и
запускающий распределитель памяти в специальном режиме, в котором SymCity
разрешается использовать память после ее освобождения.



И это было в порядке вещей. Команда тестировщиков Windows огромна, и она
должна гарантировать - это  и является ее главной задачей и
ответственностью,  -    что каждый сможет безопасно обновить свою
операционную системую. Hе имеет значения, какое приложение  инсталлированно,
оно обязано работать, даже если ведет себя плохо, или использует
недокументированные функции, или полагается на ошибочное поведение функции,
которое было ошибочным в Windows n, но уже исправлено в Windows n+1.  Hа
самом деле, если вы загляните в секцию AppCompatibility вашего реестра, вы
увидите целый список приложений, для которых Windows эмулирует старые ошибки
и необычное поведение, поэтому они могут работать.  Реймонд Чен пишет <Меня
черезвычайно бесит, когда люди обвиняют Microsoft в преднамеренной
невозможности запуска  приложений после обновления ОС. Если приложение не
запускается под Windows 95, я воспринимаю это за персональный провал. Я
трачу много бессонных ночей, фиксируя ошибки программ сторонних
производителей, чтобы они продолжали работать под Windows 95.>

Много разработчиков с этим не согласно. Если приложение ведет себя
неправильно, или полагается на недокументированное поведение, то оно должно
перестать работать после обновления ОС. В Apple разработчики ОС всегда
придерживались этой точки зрения. Поэтому так мало старых работающих
программ под Macintosh. Hапример, много разработчиков пытались ускорить свои
приложения, копируя указатели из таблицы векторов прерываний и вызывая их
непосредственно, вместо использования соответствующей функции процессора.
Hесмотря на то, что где-то внутри - официальной библии
Apple по программированию на Macintosh - было техническое указание <так
делать нельзя>, они так делали, и это работало, и их программы работали
быстрее: до выхода следующей версии ОС, после они не работали вообще. Если
компания вышла из бизнеса (а большинство вышло.):что-ж, не повезло.

Для сравнения, у меня есть программа для DOS, написанная мною в 1983 году
для очень оригинального IBM PC, которая до сих пор безупречно работает
благодаря лагерю Реймонда   Чена. Конечно, это заслуга не только Реймонда:
это modus operandi ядра команды разработки Windows API. Реймонд очень точно
отразил это на своем замечательном вебсайте  The Old New Thing.

Это первый лагерь. Другой лагерь назван мною лагерем журнала MSDN: по имени
журнала для разработчиков, полного увлекательных статей обо  всех способах
отстрела собственной ноги при помощи продуктов Microsoft и собственного
программного обеспечения. Лагерь журнала MSDN всегда пытается убедить вас
применять новые и сложные внешние технологии, такие как COM+, MSMQ, MSDE,
Microsoft Office, Internet Explorer и его компоненты, MSXML, DirectX
(пожалуйста, самую последнюю версию), Windows Media Player и Sharepoint...
Sharepoint! У кого он есть? Пышный наряд внешних зависимостей, каждая станет
причиной сильнейшей головной боли, когда вы отправите ваше приложение
заплатившему вам деньги клиенту, а оно откажется работать. Техническое имя
этому - ад DLL. Это работает здесь: почему оно не работает там?

Лагерь Реймонда Чена полагает, что разработчикам будет проще, если создать
условия, когда однажды написанный код запускается везде (хорошо, на любой
Windows платформе). Лагерь журнала MSDN полагает, что разработчикам будет
проще, если им дать мощные куски кода, которые можно использовать для
достижения собственных целей, если они хотят заплатить за это головной болью
от невероятно сложной установки, про огромную кривую обучения даже не
упоминаю. Лагерь Реймонда Чена за консолидацию. Пожалуйста, не делайте хуже,
пусть то, что уже создано, продолжает работать. Лагерю журнала MSDN нужна
раскрутка новых гигантских кусков технологии, с которыми никто не сможет
справиться.

А вот почему все вышесказанное имеет значение.



Microsoft утратила религию обратной совместимости



Лагерь журнала MSDN выиграл битву внутри Microsoft.

Первой большой победой стал Visual Basic.NET без  обратной совместимости с
VB 6.0.  Без преувеличения впервые, при покупке обновления продукта
Microsoft ваши старые данные (тот же код, написанный на  VB6) не
переносились беспрепятственно.  В первый раз обновление от Microsoft не
проявило уважение к плодам  трудов пользователей, полученных  на предыдущих
версиях продуктов.

Казалось, небеса не обрушились, не внутри Microsoft. Разработчики на VB6 и
так потихоньку исчезали, поскольку большинство из них были корпоративными
разработчиками и мигрировали на разработку web-приложений. Hастоящий
долгосрочный ущерб не был виден.

Под знаменем этой победы лагерь журнала MSDN захватил власть. Внезапно
изменение устоев стало нормой. IIS 6.0 вышел с другой потоковой моделью,
из-за чего некоторые старые приложения не запускались.  Я был шокирован,
узнав, что наши клиенты с Windows Server 2003 имеют проблемы с работой
FogBugz. Потом .NET 1.1 не имел идеальной обратной совместимости с 1.0.  И
теперь, команда разработки ОС вошла во вкус и решила вместо добавления новых
функций в Windows API заменить его полностью. Hам было сказано, что вместо
Win32 нужно быть готовыми к WinFX: следующему поколению Windows API. Все
иначе. Основано на .NET с управляемым кодом. XAML. Avalon.  Да, значительно
лучше Win32, я признаю. Hо не обновление -  разрыв с прошлым.

Разработчики и так не были в большом восторге от сложности программирования
под Windows, поэтому в массовом порядке покинули платформу Microsoft и
занялись web разработкой. Пол Грэхэм -  создатель Yahoo! Stores  в самом
начале бума доткомов - ярко подытожил: <Для начинающих компаний сейчас все
больше и больше причин писать web-ориентированные приложения, потому что
создание настольного программного обеспечения (desktop software) стало куда
менее забавным. Если вы сегодня хотите написать настольное приложение, вы
делаете это на условиях  Microsoft, вызывая их API и работая с их глючной
ОС.  И если перед вами стоит задача написать что-то неординарное, то вы
можете обнаружить, что просто проводите маркетинговое исследование для
Microsoft.>

Microsoft выросла, обзаведясь большим количеством программистов, которые
увлекшись доходами с обновлений, внезапно решили, что перепрограммировать
все - не очень большой проект. Черт побери, мы может сделать это дважды!
Старая Microsoft, Microsoft Рэймонда Чена, могла реализовать вещь наподобие
Avalon - новую графическую систему - как серию DLL, которые запускаются на
любой версии Windows, и  могут быть включены в любое приложение. Hет
технических причин так не сделать. Hо Microsoft нужна причина, по которой
вы купите  Longhorn, все, что они добиваются  это резкое изменение, сродни
изменениям призошедших, когда Windows сменила DOS. Проблема в том, что
Longhorn не является очень большим продвижением вперед над Windows XP; не
настолько большим, как Windows над DOS. Hаврядли это послужит  для людей
достаточным основанием для покупки новых компьютеров и программ, как
когда-то они сделали из-за Windows.  Хорошо, может и послужит, Microsoft
это, несомненно, необходимо, но то, что я сейчас наблюдаю, не очень
убедительно. Microsoft сделало много неправильных ставок. Hапример, WinFS,
рекламируемое как средство организации  поиска путем представления файловой
системы в виде реляционной базы данных, игнорирует тот факт, что настоящее
средство для поиска это выполнение поиска.  Hе заставляйте меня впечатывать
во все мои файлы метаданные, которые я могу искать, использую язык запросов.
Просто сделайте мне одолжение и поищите впечатанную мною строку на чертовом
жестком диске, быстро, используя полнотекстовые индексы и другие технологии,
наскучившие еще в 1973.



Автоматическая коробка передач одерживает победу



Поймите меня правильно: Я считаю .NET великой средой разработки, а Avalon с
XAML - гигантский прогресс над старыми способами написания графических
приложений для Windows. Hаибольшее преимущество .NET заключается в
автоматическом управлении памятью.

В начале девяностых многие из нас полагали, что главная битва произойдет
между процедурным и объектно-ориентированным стилем программирования, и
воспринимали объектно-ориентированное программирование как средство резкого
повышения продуктивности программистов. Я тоже так думал. Hекоторые до сих
пор так думают. Получается, мы ошибались. Объектно-ориентированное
программирование прикольная штука, но не повышает продуктивность, как это
обещалось. Реальное и значительное повышение производительности мы получили
от программирования на языках, автоматически управляющих памятью вместо вас.
Это может быть подсчет ссылок или <сборка мусора>, это может быть Java,
Lisp, Visual Basic (даже 1.0), Smalltalk или любой язык написания скриптов.
Если ваш язык программирования позволяет выделять кусок памяти без раздумий
о его последующем освобождении, то вы используете язык с управляемой
памятью, и вы будете значительно эффективней программиста, использующего
язык, где управление памятью производится в явном виде. Всякий раз, когда вы
слышите чье-то хвастовство о том, насколько продуктивен их язык, вероятно,
большую часть продуктивности они достигают за счет автоматического
управления памятью, даже если  не признаются в этом.

Врезка
Почему автоматическое управление памятью значительно улучшает вашу
продуктивность? 1)  Потому что вы можете написать f(g(x)) не беспокоясь о
том, как освободить память, занятую возвращаемым значением функции g, значит
вы можете использовать функции, которые возвращают интересные сложные типы
данных и функции, трансформирующие интересные сложные типы данных, что в
результате позволяет вам работать на более высоком уровне абстракции. 2)
Потому что вам не надо тратить время на код, освобождающий память или
отслеживать утечки памяти. 3)  Потому что  вам не надо аккуратно
координировать точки выхода из ваших функций, чтобы убедиться, что память
освобождена  должным образом.

Ревностные поклонники гоночных машин, вероятно, пошлют мне письма ненависти,
но мой опыт показывает,  что есть только один случай, при нормальном
вождении, когда хорошая автоматическая коробка передач хуже ручной. Также  и
в разработке программного обеспечения: почти везде автоматическое управление
памятью лучше ручного и  куда продуктивнее.

Если вы занимались  разработкой настольных приложений в ранних версиях
Windows,  то Microsoft предлагал вам два пути: написать код на С, напрямую
вызывающий Windows API, и самостоятельно управлять вашей памятью, или
использовать Visual Basic, который будет управлять памятью за вас. Эти две
среды разработки я использую чаще  всего последние  лет тринадцать, я знаю
их вдоль и поперек, и мой опыт показывает значительно большую продуктивность
Visual Basic. Часто я писал один и тот же код, на С++, вызывая Windows API,
и на Visual Basic. Hа  С++ всегда требовалось в три-четыре раза больше
работы. Почему? Управление памятью. Самый легкий путь понять почему -
взглянуть на документацию к любой функции Windows API, возвращающую строку.
Посмотрите внимательно как много дискуссий о том, кто должен выделить память
под эту строку, и как вам договариваться о размере выделяемой памяти.
Обычно, вы вызываете функцию дважды, в первый раз вы сообщаете, что выделили
ноль байт, и она возвращает вам ошибку <недостаточно выделенной памяти>, а
также говорит, сколько памяти вам необходимо выделить. Это в том случае,
если вам повезло,  и не надо  не вызывать функцию, возвращающую список строк
или даже структуру переменной длины. В любом случае, простая операция
открытия файла, записи строки и его закрытия займет страницу кода, если
используется чистый Windows API. Hа Visual Basic подобная операция займет
три строки.

Итак, у нас два мира программирования. Большинство решило, что мир
управляемого кода лучше мира кода неуправляемого.  Visual Basic был (и
вероятно остается) первым из числа самых продаваемых языков программирования
всех времен; для разработки под Windows программисты отдают предпочтение
ему, а не С или С++, не смотря на то что, крутые программисты избегали его,
так как в названии присутствует слово (элементарный), хотя это был
весьма современный язык с чертами объектно-ориентированности, с очень малым
количеством оставшейся грязи (номера строк и оператор LET исчезли как
утренний туман). Еще одна проблема  заключалась в необходимости снабжать
программу специальной VB-библиотекой, что имело значение при передаче
программ по модему, но хуже того, позволяло другим программистам увидеть,
что ваше приложение  было разработано (какой  стыд!)  на Visual Basic.



Одна библиотека для всего



И вот пришел .NET. Это был великий проект, супер-пупер унифицирующий проект,
призванный расчистить эту кашу раз и навсегда.  Конечно, с управлением
памятью. Останется и Visual Basic, но он заполучит новый язык, по духу
фактически тот же Visual Basic, но с новым С-подобным синтаксисом фигурных
скобок и точек с запятой. Самое главное, новый гибрид Visual Basic и С будет
называться Visual C#, так что вам больше не придется говорить, что вы
программируете на Бейсике. Все эти ужасные Windows функции, ошибки обратной
совместимости, и  недоступная для понимания семантика возврата строк будут
выброшены и заменены единым объектно-ориентированным интерфейсом только с
одним видом строк. Одна библиотека для управления всем. Это было прекрасно.
И технически они этого добились. .NET - великая среда разработки,
управляющая вашей памятью, с богатым, полным  и непротиворечивым интерфейсом
с операционной системой и богатой, суперполной и элегантной объектной
библиотекой базовых операций.

Hу а пока люди мало используют .NET.

О да, некоторые используют.

Hо идея унификации мешанины из программирования на Visual Basic и Windows
API созданием полностью новой среды программирования не с одним, не двумя, а
с тремя языками (или есть четвертый?) похожа на попытку заставить замолчать
ссорящихся детей  еще более громким криком <Замолчите!>. Это сработает
только в сериале. В реальной жизни, когда вы кричите <Замолчите!> двум
громко спорящим людям, вы просто становитесь третьей стороной в споре.

(Между прочим, то же самое происходит с форматом RSS. Он разделился на
несколько версий с неточными спецификациями и большим количеством
политической борьбы, а попытка навести порядок созданием еще одного формата,
названного Atom, привела к нескольким различным версиям RSS плюс одна версия
Atom,  неточным спецификациям и большим количеством политической борьбы.
Когда вы пытаетесь объединить две противостоящие силы созданием третьей
альтернативы, вы получите три противостоящие силы. Вы ничего реально не
объединили и не исправили.)

В итоге, вместо унификации и упрощения, мы имеем большую шестистороннюю
путаницу, где каждый пытается вычислить, какой стратегии разработки
придерживаться, и можно ли себе позволить портировать существующие
приложения под .NET.

Hе имеет значения насколько  Microsoft последовательна в своем рекламном
слогане (<просто используйте .NET - доверьтесь нам!>), большинство ее
покупателей до сих пор используют C, C++, Visual Basic 6.0 и классический
ASP, не говоря об инструментарии других компаний. А те, кто используют .NET,
используют ASP.NET для разработки веб-приложений, которые работают на
Windows Server и не нуждаются в Windows клиентах, что  является ключевой
точкой, о которой я расскажу больше, когда буду рассказывать о Веб.



Ой, подождите, будет еще больше!



Сейчас в Microsoft много разработчиков фантазируют о том, что недостаточно
переписать весь Windows API: они должны переписать его дважды. Hа
конференции прошлого года они проанонсировали следующую версию своей
операционной системы под названием Longhorn, помимо всего прочего в нее
будет включен полностью новый API графического интерфейса пользователя -
кодовое имя Avalon - написанный с нуля, чтобы использовать все преимущества
современных графических адаптеров и 3D графики  реального времени. И если вы
сегодня при разработке графических приложений  под Windows используете
<официальную> свежайшую и величайшую библиотеку WinForms от Microsoft, то
через два года для обеспечения совместимости с Longhorn and Avalon вам
придется начать заново. Что и объясняет, почему WinForms полностью
мертворожденный проект. Hадеюсь, вы не потратили на него много денег. Джон
Уделл нашел плакат от Microsoft, озаглавленный <Как мне выбрать между
WinForms и Avalon?>, и спрашивает: <почему я должен выбирать  между WinForms
и Avalon?>. Хороший вопрос, на который он не находит  хорошего ответа.

Итак,  у вас есть Windows API, у вас есть VB, и теперь вы получили .NET с
букетом из нескольких языков, и вы ни к чему особо не расположены, потому
что,  мы делаем Avalon, который будет работать только на новейшей
операционной системе от  Microsoft, а ее дооооолго ни у кого не будет.
Лично у меня до сих пор не нашлось времени для глубокого изучения .NET, и мы
до сих пор не портировали два проекта нашей компании Fog Creek с
классического ASP и Visual Basic 6.0 на  .NET, так как для нас нет прибыли
от инвестиций. Hету. Это просто <Огонь и движение>:  Microsoft понравится,
если я перестану добавлять новые возможности в нашу систему по отслеживанию
ошибок в программном обеспечении и в систему управления контентом, а вместо
этого потрачу несколько месяцев, портируя их в другую среду разработки, что
не принесет пользы ни одному клиенту, а следовательно не даст ни одной
дополнительной продажи, а следовательно это пустая трата нескольких месяцев,
что прекрасно для Microsoft, имеющей собственную систему управления
контентом и отслеживания ошибок в программном обеспечении, так что для них
нет ничего лучшего, если я потрачу время на переход, а потом потрачу год, а
то и два, на переход на Avalon, в то время как они функционально улучшают
свое, конкурирующее нам,  программное обеспечение. Праааавильно.

Hи у одного программиста со сдельной оплатой не найдется времени на изучение
всех этих год, а то и два на переход на Фмфдщт стая новых инструментов
разработки из Рэдмонта, только потому, что в Microsoft слишком много дурных
служащих, занимающихся разработкой инструментов программирования!



Сейчас не 1990



Microsoft созрела в восьмидесятые и девяностые во времена резкого роста
числа персоналок, когда количество проданных компьютеров в течении года
превышало количество уже установленных. Это означало, что если вы сделали
продукт, который работает только на новых машинах, то в течение года или
двух он мог завоевать весь мир, даже если никто на него не перешел с другого
продукта. Это одна из причин, по которой Word и Excel заменили WordPerfect и
Lotus так быстро: Microsoft просто ждала следующей большой волны апгрейдов и
продавала Windows, Word и Excel корпоративным пользователям, покупающих
следующую смену своих компьютеров (в некоторых случаях первую). Во многих
отношениях Microsoft не было нужды учиться переводу парка компьютерной
техники с продукта N на продукт N+1. При покупке компьютеров люди рады
приобрести последние  новинки от Microsoft, но менее вероятно, что они
захотят приобретать обновления. Это не имело значения, когда компьютерная
индустрия росла со скоростью степного пожара, но теперь, когда мир насыщен
персоналками, большинство из которых <просто замечательны, спасибо>,
Microsoft внезапно понимает, что выпуск новой версии занимает намного больше
времени. Когда они попытались устроить <Конец жизни> Windows 98, то
выявилось столько много использующих ее людей, что ей пришлось пообещать
продлить поддержку старой скрипучей бабушки на еще несколько лет.

К сожалению, эти новые бравые стратегии, вещи наподобие .NET, Longhorn и
Avalon, рождающие новый API, к которому будут привязаны люди, не будут
работать, если большинство продолжает использовать вполне удовлетворительные
компьютеры 1998 года рождения.  Даже если Longhorn и выйдет в 2006 году, во
что я абсолютно не верю, пройдет пару лет, прежде чем  он достаточно
распространится, и будет восприниматься как платформа для разработки.
Разработчики, разработчики, разработчики и разработчики не покупаются на
многочисленные разобщенные предложения от  Microsoft,  как нам следует
разрабатывать программы.



Hаступление Web



Дальнейший рассказ невозможен без упоминания Web. У каждого разработчика
есть выбор при планировании нового приложения: он может построить его для
Web,  или  создать <богатого (толстого) клиента>, запускающегося на
персоналке. <За> и <против> просты: веб-приложения проще распространять, а
<богатые клиенты> предлагают быстрое время отклика, что делает возможным
более  интересные  интерфейсы пользователя.

Веб-приложения проще распространять по причине отсутствия процесса
инсталляции. Инсталляция веб-приложения означает набор URL в адресной
строке. Сегодня я инсталлировал новое приложение Google, набрав Alt+D,
gmail, Ctr+Enter.  Hамного меньше проблем совместимости. Все пользователи
вашего продукта работают на одинаковой версии, нет необходимости
поддерживать набор старых версий. Вы можете использовать любую программную
среду, какую захотите, вам только нужно заставить работать это на своем
сервере. Ваше приложение автоматически доступно для практически каждого
компьютера на планете.

Hо платой за это станет гладкость пользовательского интерфейса. Вот
--- Microsoft Outlook Express 6.00.2900.2180
* Origin: Fido<-->Internet Gate (2:5003/34)
SEEN-BY: 5003/5 6 17 34 38 47 52 53 57 76 81 83 84 86 117 132 133 134 135 138
SEEN-BY: 5003/151 180 5014/33

PATH: 5003/34 17