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» не проигрывала, да и битвы-то никакой и не было. Просто все переходит на новый качественный уровень, непохожий на старые, привычные методы программирования, но это уже совсем другая история…

 

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

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

Ваш e-mail не будет опубликован. Обязательные поля помечены *