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

Иван Никитин и партнерыНовостиРазноеJoel on Software – Как Microsoft проиграла битву за API

Данный пост отражает сугубо личную точку зрения автора (то есть, мою точку зрения). Я ни в коем случае не преследую цель затеять здесь священную войну или флейм. Этот пост является продолжением обсуждения дискуссии в Клубе Выпускников. Материалы и само обсуждение здесь не публикуется, и если у вас нет доступа к этому форуму – могу лишь порекомендовать пройти курсы Веба в ЦКО Специалист, и получить вожделенный доступ к этой конференции.

Джоель Спольски написал очень вдумчивую и очень подробную статью
How Microsoft Lost the API War (Как Microsoft проиграла битву за API)

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

Конечно же, скажут мне, легко критиковать чужие мысли, чужие заметки, и я соглашусь, добавив, что критиковать легко, а огульно критиковать (в стиле “Microsoft must die!”) еще легче! Не будем уподобляться воинствующим тинейджерам, с их возрастным максимализмом, и постараемся разобраться в вопросе… Итак, let’s go!

> Наибольшее преимущество .NET заключается в автоматическом управлении памятью.

Да что вы уперлись в это управление памятью? Да, это кошмар, но это кошмар конкретного подхода – языка С! Когда вы сами беретесь распределять память, сами дергаете WinAPI, то это хорошо проходит на сравнительно небольшом коде, но время идет, и количество вашего кода так же увеличивается, и старые подходы, типа прямая работа с WinAPI становятся неэффективными. WinAPI также изменяется – он (API – это “он”, интерфейс) не может не изменяться! Операционка меняется, железо меняется, и если вы хотите всем этим пользоваться, WinAPI также будет изменяться. Этого не может не быть. Но говорить только о проблеме распределения и освобождения ресурсов – это просто не видеть проблем своего приложения. Да, .Net делает это вместо вас, и делает хорошо, но помимо автоматического управления памятью .Net дает еще и огромное количество возможностей: и JIT компиляцию под текущую платформу, и богатейшую библиотеку классов (вместо запутанного WinAPI!!!), решение проблем совместимости, и практически отсутствие DLL hell и … см. ниже

> Потом .NET 1.1 не имел идеальной обратной совместимости с 1.0

Вполне согласен! Но они умеют работать бок-о-бок (side-by-side). И если вам эта совместимость край как нужна (если вам просто лень просто перекомпилировать проект под другой .Net Framework) поставьте на машину заказчика оба .Net Framework’а! У меня, например, их три – в качестве тестов (1.0, 1.1, 2.0) ! Вот собираюсь и теперь и четвертый поставить (3.0). Самое интересное, за все время, что я использую и пишу .Net приложения, у меня ни разу не возникала проблема несовместимости отдельных компонентов! Вот вам и DLL hell. DLL hell превратился в Assembly Paradise!

> Лагерь журнала MSDN всегда пытается убедить вас применять новые и сложные внешние технологии, такие как COM+, MSMQ, MSDE, Microsoft Office, Internet Explorer и его компоненты, MSXML, DirectX (пожалуйста, самую последнюю версию), Windows Media Player и Sharepoint… Sharepoint! У кого он есть?

Э-э-э, ребята! Не надо путать божий дар с яичницей! Вы только что тут активно говорили о распределении памяти и прямом программировании WinAPI, и здесь же смешиваете технологии совершенно иного порядка. SharePoint? Ну, во-первых, есть он у многих. А во вторых… А вот представьте себе, необходимо сделать корпоративный портал, с хранением документов, на 10000 пользователей, на 10 удаленных офисов, с корпоративным поиском на 1000000 документов в индексе, с интеграцией с офисными приложениями и, скажем, ERM SAP. Вот это и задача SharePoint. Если такую задачу начать писать “в лоб”, то возможно, вы и справитесь… к 2030 году.

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

О да! Не надо смешивать все в одной куче: Веб (Поручик, молчать!!! Никаких два-нулей!!! Нецензурными словами не выражаться!), rich-clients, smart-clients и другое. Это совершенно разные задачи, совершенно разные направления, и совершенно разные реализации.

> Причина, по которой платят 130 000 $ программисту со знанием СОМ, заключается в том, что никто за последние восемь лет не утруждал себя изучением СОМ, так что вам необходимо найти действительно опытного и зрелого человека, обычно уже в менеджменте, и убедить его работать программистом, связаться (боже, помоги мне!) с маршаллингом, моникерами, распределенными потоками, агрегатами и миллионом других вещей, которые понимал только Дон Бокс, и даже Дон Бокс больше не может на это смотреть.

Причина, по которой разработчику со знанием COM+ платят $130000 в год заключается в том, что это разработка несколько иного уровня, нежели разработка Веб-приложений (нет! Не так! Некоторые Веб-приложения тоже могут требовать инфраструктуры COM+). Когда у вас встанет задача построения распределенной системы, в которой текут распределенные транзакции, включающие в себя, скажем SQL сервер в Москве и факсимильный аппарат в Питере, то, боюсь, без COM+ обойтись будет сложно. И кстати, .Net ни в коем разе не отменяет COM+. Пример, курс Microsoft: Building COM+ Applications Using Microsoft .NET Enterprise Services

Итак, в качестве вывода можно привести такую фразу: .Net – это очередной шаг в развитии технологий разработки приложений, мощный и могучий способ решить поставленные задачи. Он может не нравится, его можно не замечать, или вовсе отрицать, но он никуда не денется, он будет и дальше развиваться. А Microsoft “битву за API” не проигрывала, да и битвы-то никакой и не было. Просто все переходит на новый качественный уровень, непохожий на старые, привычные методы программирования, но это уже совсем другая история…

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

Один комментарий

  1. >я далеко не полностью разделяю его
    Кого “его”? Авторский опыт вы не разделяете? Похоже, так и есть, поскольку вы вообще не поняли, о чем говорил Joel и на что обращал внимание.

    >WinAPI также изменяется — он (API — это «он», интерфейс) не может не изменяться! Операционка меняется, железо меняется, и если вы хотите всем этим пользоваться, WinAPI также будет изменяться.

    Конечно, операционка меняется – потому что ее меняют. Если бы ее не меняли, она бы и не менялась. И Joel очень подробно объяснил, кому выгодно ее менять – владельцам микрософт, которые хотят таких же резких изменений, какие были, когда Windows сменила DOS. Чтобы сразу срубить много бабла с тех, кто обновит свою операционную систему до новой версии. Проблема только в том, что, если Windows действительно качественно превосходила Dos, то вот новые изменения большинству людей не нужны. Они искусственно навязываются микрософтом. И в долгосрочном плане такая политика убыточна. И опять же Joel объяснил почему.

    Потому что если программист отладил куски кода, он предполагает, что они и дальше будут работать – их не нужно заново отлаживать. Заставляя заново отлаживать старый код, микрософт попросту не уважают труд программистов, которые пишут под windows. И в скором времени по мнению Джоела им это должно аукнуться: разработчики уйдут в веб. Но только благодаря программам для windows (написанным этими самыми разработчиками) эта ОС так популярна, поскольку сама по себе она никому не нужна.

    Да, и, кстати говоря, старые подходы, типа прямой работы с WinAPI, может, и становятся неэффективными, но это все же не повод менять Api. Их можно дописывать, но Joel прямым текстом говорит: “команда разработки ОС вошла во вкус и решила вместо добавления новых функций в Windows API заменить его полностью”.

    Представьте, что вы написали свои собственные функции, которые используют внутри себя функции Api. Эти функции используются в других функциях, и т.д. В конце концов, у вас появляются все более и более крупные куски кода, из которых вы потом, как из кирпичей, строите здание своей программы. А потом приходит микрософт с новой версией windows и вышибает из-под вашего здания фундамент – функции api. И кому, интересно, это понравится?

    >Э-э-э, ребята! Не надо путать божий дар с яичницей! Вы только что тут активно говорили о распределении памяти и прямом программировании WinAPI, и здесь же смешиваете технологии совершенно иного порядка. SharePoint? Ну, во первых, есть он у многих. А во вторых… А вот представьте себе, необходимо сделать корпоративный портал, с хранением документов, на 10000 пользователей, на 10 удаленных офисов, с корпоративным поиском на 1000000 документов в индексе, с интеграцией с офисными приложениями и, скажем, ERM SAP. Вот это и задача SharePoint. Если такую задачу начать писать «в лоб», то возможно, вы и справитесь… к 2030 году.

    Да, ну вот опять. Справитесь с этой задачей к 2030му году – почему же тогда микрософт справилась к 2006-му году? Может, потому что там работают сотни людей? А как насчет конкурирующих фирм, в которых тоже сотни людей, и которые пытаются из WinAPI слепить ТО ЖЕ САМОЕ? Очевидно, что микрософт таким образом пытается устранить своих конкурентов.

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

    >Причина, по которой разработчику со знанием COM+ платят $130000 в год заключается в том, что это разработка несколько иного уровня, нежели разработка Веб-приложений

    Так рассуждают марксисты, которые считают, что труд создает стоимость (соответственно, чем больше труда, тем больше стоимость). В рыночной же экономике труд еще должен быть оценен. Он вообще может оказаться бесполезен. Кстати, у Джоела и по экономике есть статья (правда, всего одна, вроде бы).

Добавить комментарий