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

Joel on Software - Как Microsoft проиграла битву за API

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

Автор: Джоэл Сполски

Переводчик: Алексей Бушмин

10. 01. 2005

Перед вами модная теория: «Microsoft-у конец. Как только Linux продвинется в своем набеге на десктопы, и 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 . Я должен объяснить, как он был потерян, какие будут последствия. Но так как я говорю о долгосрочных тенденциях, я вынужден буду гиперболизировать и обобщать.

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

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

Логическое заключение состоит в том, что если вы пытаетесь продавать операционную систему, то вам необходимо сделать так, чтобы разработчики программного обеспечения захотели писать программы для вашей операционной системы. Поэтому Стив Баллмер прыгал по сцене и кричал: «Разработчики, разработчики, разработчики, разработчики». Это так важно для Microsoft, что единственная причина, из-за которой средства разработки программного обеспечения не раздаются бесплатно, заключается в том, что они не хотят случайно перерезать кислород разработчикам конкурирующих инструментов разработки (хорошо, тем, которые остались), так как разнообразие инструментов разработки, доступных для их платформы, делает ее куда более привлекательной для разработчиков. Но на самом деле они хотят раздавать. Благодаря их программе 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»?

Если вы пишите программу, скажем текстовый редактор, и вы хотите высветить меню или записать файл, вы должны попросить операционную систему сделать это за вас, используя очень специфический набор вызовов функций, который различается на каждой операционной системе. Эти вызовы функций называются 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 огромна, и она должна гарантировать – это и является ее главной задачей и ответственностью, – что каждый сможет безопасно обновить свою операционную системую. Не имеет значения, какое приложение инсталлированно, оно обязано работать, даже если ведет себя плохо, или использует недокументированные функции, или полагается на ошибочное поведение функции, которое было ошибочным в Windows n, но уже исправлено в Windows n+1. На самом деле, если вы загляните в секцию AppCompatibility вашего реестра, вы увидите целый список приложений, для которых Windows эмулирует старые ошибки и необычное поведение, поэтому они могут работать. Реймонд Чен пишет «Меня черезвычайно бесит, когда люди обвиняют Microsoft в преднамеренной невозможности запуска приложений после обновления ОС. Если приложение не запускается под Windows 95, я воспринимаю это за персональный провал. Я трачу много бессонных ночей, фиксируя ошибки программ сторонних производителей, чтобы они продолжали работать под Windows 95.»

Много разработчиков с этим не согласно. Если приложение ведет себя неправильно, или полагается на недокументированное поведение, то оно должно перестать работать после обновления ОС. В Apple разработчики ОС всегда придерживались этой точки зрения. Поэтому так мало старых работающих программ под Macintosh. Например, много разработчиков пытались ускорить свои приложения, копируя указатели из таблицы векторов прерываний и вызывая их непосредственно, вместо использования соответствующей функции процессора. Несмотря на то, что где-то внутри «Inside Macintosh» – официальной библии 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-приложений. Настоящий долгосрочный ущерб не был виден.

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

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

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

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

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

В начале девяностых многие из нас полагали, что главная битва произойдет между процедурным и объектно-ориентированным стилем программирования, и воспринимали объектно-ориентированное программирование как средство резкого повышения продуктивности программистов. Я тоже так думал. Некоторые до сих пор так думают. Получается, мы ошибались. Объектно-ориентированное программирование прикольная штука, но не повышает продуктивность, как это обещалось. Реальное и значительное повышение производительности мы получили от программирования на языках, автоматически управляющих памятью вместо вас. Это может быть подсчет ссылок или «сборка мусора», это может быть 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. На С++ всегда требовалось в три-четыре раза больше работы. Почему? Управление памятью. Самый легкий путь понять почему – взглянуть на документацию к любой функции Windows API, возвращающую строку. Посмотрите внимательно как много дискуссий о том, кто должен выделить память под эту строку, и как вам договариваться о размере выделяемой памяти. Обычно, вы вызываете функцию дважды, в первый раз вы сообщаете, что выделили ноль байт, и она возвращает вам ошибку «недостаточно выделенной памяти», а также говорит, сколько памяти вам необходимо выделить. Это в том случае, если вам повезло, и не надо не вызывать функцию, возвращающую список строк или даже структуру переменной длины. В любом случае, простая операция открытия файла, записи строки и его закрытия займет страницу кода, если используется чистый Windows API. На Visual Basic подобная операция займет три строки.

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

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

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

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

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

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

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

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

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

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

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

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

Ни у одного программиста со сдельной оплатой не найдется времени на изучение всех этих год, а то и два на переход на Фмфдщт стая новых инструментов разработки из Рэдмонта, только потому, что в 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, как нам следует разрабатывать программы.

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

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

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

Но платой за это станет гладкость пользовательского интерфейса. Вот несколько примеров того, что вы не можете действительно хорошо делать в веб-приложении:

1. Создавать программы с быстрой графикой.

2. Строить систему проверки орфографии в режиме реального времени с красными волнистыми подчеркиваниями.

3. Предупреждать пользователей, что они потеряют свои данные, если нажмут кнопку закрытия браузера.

4. Обновлять на основе изменений пользователя небольшую часть экрана без обращения к сервера.

5. Создавать быстрый клавиатурный интерфейс (без необходимости использовать мышь).

6. Позволять людям продолжать работу, когда они не подсоединены к Интернет.

Не все из вышеперечисленного представляет собой большую проблему. Вскоре часть проблем будет разрешена остроумными программистами на Javascript. Два новых почтовых веб-приложения Gmail и Oddpost показывают хорошую работу по преодолению или полному разрешению некоторых вышеназванных пунктов. А пользователей, похоже, не заботят небольшие затруднения и «тормознутость» веб-интерфейса. Почти все мои знакомые, по тем или иным причинам, совершенно счастливы от веб-интерфейса электронной почты, несмотря на все мои убеждения в том, что «богатый клиент», э-э, богаче.

Итак, веб-интерфейс пользователя решает 80% всех проблем, и даже без нового браузера мы, вероятно, достигнем процентов 95. Это терпимый уровень для большинства людей, и, несомненно, для разработчиков, которые голосуют за веб-разработку практически при каждом значимом проекте.

Это значит, что, внезапно, API от Microsoft уже не так важен. Веб-приложениям не нужен Windows.

Это не значит, что в Microsoft ничего не заметили. Конечно, заметили, а когда последствия стали ясны, ударили по тормозам. Такие новые многообещающие технологии, как HTAs и DHTML были остановлены в своем развитии. Команда разработки Internet Explorer похоже исчезла; результатов их деятельности не видно уже несколько лет. Ни в коем случае в Microsoft не позволят DHTML стать чуточку лучше: это слишком опасно для их ключевого бизнеса – «богатых клиентов». Сегодня Microsoft делает ставку на «богатого клиента». Вы увидите это в каждом слайде презентации Longhorn.

Проблема в следующем: слишком поздно.

Мне немного жаль

Мне действительно немного жаль. По мне, Веб – это классно, но веб-ориентированные приложения с их гадким, непоследовательным интерфейсом с большим временем реакции – большой шаг назад в отношении удобства и практичности (usability) интерфейсов. Я люблю «богатых клиентов» и сойду с ума, если придется работать на веб-версиях ежедневно мною используемых программ: Visual Studio, CityDesk, Outlook, Corel PhotoPaint, QuickBooks. Но это то, чем собираются нас снабдить разработчики. Больше никто (в смысле «меньше чем 10 000 000 человек») не хочет работать с Windows API. Венчурный капитал не будет инвестировать в разработку Windows-приложений, так как боится конкуренции с Microsoft. И, пожалуй, большинство пользователей не волнует паршивый веб-интерфейс также, как волнует меня.

А вот решающий довод: я заметил (и друг из агентства по найму подтвердил), что программист на Windows API здесь в Нью-Йорке, знающий С++ и СОМ, зарабатывает около 130 000$ в год, тогда как типичный веб-программист, использующий язык с автоматическим управлением памятью (Java, PHP, Perl, даже ASP.NET) зарабатывает около 80 000$ в год. Это огромная разница, и когда я поговорил с друзьями из Microsoft, они признали, что их фирма потеряла целое поколение разработчиков. Причина, по которой платят 130 000 $ программисту со знанием СОМ, заключается в том, что никто за последние восемь лет не утруждал себя изучением СОМ, так что вам необходимо найти действительно опытного и зрелого человека, обычно уже в менеджменте, и убедить его работать программистом, связаться (боже, помоги мне!) с маршаллингом, моникерами, распределенными потоками, агрегатами и миллионом других вещей, которые понимал только Дон Бокс, и даже Дон Бокс больше не может на это смотреть.

Как бы мне не было противно, большое количество программистов давно ушли в веб и отказываются возвращаться. Большинство разработчиков под .NET – ASP.NET разработчики, программирующие для Microsoft веб-сервера. ASP.NET великолепен; я занимаюсь веб-разработкой десять лет, и это действительно на целое поколение опережает все остальное. Но это серверная технология, так что клиенты могут использовать любую платформу. И это прекрасно работает под Linux при помощи Mono.

Ни одно из этих предсказаний не предвещает ничего хорошего Microsoft и доходам, получаемых благодаря власти API. Новый API это HTML, и победителями на рынке разработки приложений станут люди, которые смогут заставить HTML петь.

В английском оригинале статья называется

How Microsoft Lost the API War

Джоель Спольски - основатель Fog Creek Software, небольшой компании по
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky

Содержание раздела