PHP4 или ASP.NET - что лучше?

Немного о себе. Я сделал пару небольших проектов на PHP4 (к сожалению, до сегодняшнего дня ни один из них не дожил). Зато могу похвастаться завершенными сайтами, сделанными по технологии ASP.NET: Melodyland, который был переписан мною с ASP на ASP.NET, и своим "домашним" сайтом, который был создан как тестовая площадка для программирования на ASP.NET. Все работает на связке Celeron 500 + 128 Мбайт RAM + Windows 2000 + IIS 5 + SQL Server 2000, и вопреки расхожему мнению о тормознутости Windows, и ASP, и ASP.NET прекрасно функционируют при загрузке 30–50 сессий. Что в это время происходит с оконным интерфейсом - другой вопрос, но сами сервисы летают.

ASP.NET - это не продолжение ASP. Это концептуально новая технология Microsoft, созданная в рамках идеологии .NET. Ключевыми сторонами .NET являются масштабируемость, кроссплатформность, межъязыковое взаимодействие и шаткое понятие "безопасное программирование" (safe-programming).

PHP - наоборот, открытая и бесплатная технология. Разумеется, расшифровывать сегодня PHP как Personal Home Page было бы неправильно, но отголоски прошлого дают о себе знать и по сей день. PHP - скриптовый язык, созданный исключительно для динамического вывода HTML. Это не значит, что на нем нельзя создать крупный проект. Это значит, что создать крупный проект на PHP дорого и трудно.

Для программирования на PHP не нужна дорогая среда программирования. Чтобы научиться писать более или менее работоспособные скрипты, достаточно одного-единственного учебника. С ASP.NET такой фокус не пройдет. Без Visual Studio, MSDN и иногда - доступа в Интернет там делать нечего. Большую часть времени начинающий разработчик тратит на штудирование MSDN. А к тому времени, когда он выучит навороченную модель классов и все необходимые ему функции, Microsoft наверняка придумает что-то новое. Помнится, кто-то говорил, что чем больше вариантов предложено, тем больше времени уходит на выбор лучшего. ASP.NET - яркое тому подтверждение.

Зато если выучить... Счетчик посещений? - пожалуйста, десять строчек. Добавить сюда такую же таблицу? - два-три щелчка мышкой, пятнадцать строчек текста. Другой вывод информации? - нет проблем: делаем дочерний класс, перекрываем функцию, отводим на отладку четверть часа, привязываем к выводу второй таблицы - готово! Вообще, работа в ASP.NET с применением Visual Studio сильно напоминает работу в Delphi, с той лишь разницей, что все происходит гораздо быстрее, проще и логичнее. Основные же языки, на которых пишутся ASP.NET-приложения, - Visual Basic.NET и C#, - являются наследниками соответственно Visual Basic и Java/C++. И если переход с Visual Basic на Visual Basic.NET требует некоторого пересмотра философии программирования (так как от старого Бейсика осталась лишь часть синтаксиса и название), то переход с С++, и особенно с Java на C#, органичен настолько, что не должен занимать больше двух-трех недель.

Теоретически под ASP.NET можно писать программы на любом языке, для которого имеется соответствующий компилятор. Однако на практике для создания ASP.NET-приложений используются главным образом Visual Basic.NET и C# (где-то позади плетутся managed C++ и J#). Некоторые программные среды - например, Delphi 8 - обеспечивают номинальную поддержку ASP.NET, но толку от нее, прямо скажем, немного.

"Родная" среда ASP.NET - IIS, работающий под управлением Windows. Да, IIS известен как не самый стабильный веб-сервер, а Windows - как не самая стабильная операционная система. Но вот небольшая история из жизни.

На одной моей работе стоял сервер под управлением Windows 2000 и IIS, на котором сисадмин держал в тот момент больше двух сотен сайтов. Большая их часть состояла из динамически сгенерированных ASP-страниц (ASP.NET тогда только появился, и единственный, кто рисковал с ним работать, - правда, на отдельной машине, - был ваш покорный слуга). Так вот, сервер за два года перезагружался всего пару раз, если не считать обязательных перезагрузок после установки критических обновлений. На другой работе, которой я занимался параллельно, стоял сервер с FreeBSD 4.x, исполнявший роль прокси/файрволла для локальной сети. Он падал раз, а то и два раза в месяц. Я сам некоторое время был сисадмином и не понаслышке знаю, как надо постараться, чтобы достичь таких впечатляющих результатов в стабильности работы и Windows, и FreeBSD. С тех пор я уверен, что 90–95% стабильности работы сервера обеспечивается вовсе не выбором "правильной" системы, а выбором "правильного" сисадмина.

Я не пытаюсь убедить кого-то в том, что Windows работает более стабильно и предсказуемо, чем Unix/Linux. Мало того, я сам так не думаю. Но ASP.NET - это не только Windows. Существует, например, проект Mono, позволяющий запускать любые .NET-приложения под Linux (и, соответственно, под FreeBSD в режиме бинарной совместимости), существует mod (по-нашему - плагин) Apache для обработки ASP.NET-приложений. Но все-таки ASP.NET и *nix - пока что больше гетерогенная среда, со всеми вытекающими.

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

По идеологии Microsoft, программист - маленький винтик хорошо отлаженного механизма. Одиночки-камикадзе вроде меня, свято верящие в светлое будущее этой корпорации, не считались и не считаются. Исключаем нас - и остаются большие, быстро и постоянно расширяющиеся интернет-проекты, где один программист отвечает за один модуль. А каким, собственно говоря, еще проектам требуется кроссплатформность и мультиязычность по умолчанию? Только таким, где могут нанять такого профи, что язык, на котором он пишет, отличается от основного проектного. Только таким, которым впоследствии может потребоваться безболезненное портирование на Pocket PC, MAC, могут потребоваться интернет-сервисы и т. д. Вот в таких проектах ASP.NET разворачивается на славу. Проблемы с производительностью, нехватка ресурсов? Чепуха! Купим еще компьютеров, купим еще программистов, купим звезды с неба, лишь бы темпы разработки не падали.

РНР-программистам в подобных проектах делать нечего. Почему? Да потому, что им потребуется куча координаторов, которым деньги платить надо. Координаторов, большую часть работы которых берет на себя сама среда .NET. И, кстати, с кластерными Unix-системами обращаться тоже непросто. Как ни крути, Unix - это прекрасная stand-alone-система, но именно поэтому сделать кластер на ней гораздо сложнее, и соответственно, денег уйдет больше. Я не говорю о суперкомпьютерах, я говорю о парке в 20–50 машин. За то время, что уйдет на автоматизацию и подключение дополнительной Unix-машины к Unix-кластеру, программисты на Windows уже давно будут писать следующий модуль. Не говоря уж о том, что кластерная СУБД MySQL как кластер существует только в альфа-версии. Автоматизация же взаимодействия между машинами на Windows Server 2003 и SQL Server - одна из сильнейших сторон этих систем (Редакция умывает руки. Все рассуждения о сложности создания кластеров на Unix целиком на совести автора. Лично мне кажется, умеючи - это не так уж долго, что на Windows, что на Unix, но экспертом в данном вопросе я не являюсь и судить не берусь. - Прим. ред).

Технология РНР в корне отличается от ASP.NET. Больше всего она похожа на классические ASP-приложения, только скриптовый язык в ней один. Язык РНР напоминает сборную солянку из C и Perl с небольшим добавлением специй в виде Basic и даже Pascal. Все это натянуто на каркас из примитивной модели классов, которая представляет собой привычные структуры C с кое-как приделанным сбоку наследованием. Правда, недавно появилась пятая версия PHP, предоставляющая неплохие возможности для объектно-ориентированного программирования, однако большого распространения она пока не получила.

PHP4 слишком доверяет программисту. В нем нет типов, объявлять переменные необязательно, существуют опасные конструкции. Синтаксис PHP заточен под быстрое и простое решение типовых проблем. При этом вся ответственность за опасные трюки лежит на программисте. Что, в частности, приводит к такому распространенному явлению, как обнаружение серьезных ошибок в коде через месяц-другой после сдачи проекта.

Область применения PHP - небольшие проекты, которые делает или тесно сработавшаяся группа, или вообще один человек. Благодаря бесплатности PHP (а также бесплатности MySQL и самой платформы), этот язык становится идеальным выбором для небольших авторских сайтов или сайтов для малого и среднего бизнеса. Кроме того, PHP работает быстрее.

Теоретически ASP.NET должна работать быстрее (все-таки здесь мы имеем дело с единожды скомпилированными бинарными кодами, тогда как PHP-скрипты каждый раз обрабатываются заново). Однако PHP летает как на IIS, так и на Apache и при большой (правда, искусственно вызванной) нагрузке всегда выдает результаты лучше, чем ASP.NET. И уж тем более лучше, чем классический ASP. Обескураженный, я пошел на сайт Microsoft, чтобы найти хотя бы одну статью, в которой бы сравнивалось быстродействие PHP и ASP.NET. Безуспешно. Зато на других ресурсах нашлось довольно много статей, авторы которых пришли к тому же выводу, что и я. "Родная" связка PHP + MySQL + Apache работает быстрее ASP.NET + IIS + Microsoft SQL Server 2000.

Значит ли это, что ASP.NET хуже? Отнюдь. На том же сайте Microsoft есть масса данных, из которых следует, что решения на базе Linux/Unix в целом обходятся среднему и большому бизнесу намного дороже, чем аналогичные решения на основе Windows (Было бы странно найти на сайте Microsoft иную информацию. Но доля правды в этом есть - бесплатность технологий вовсе не означает бесплатности их использования). Такие, казалось бы, парадоксы на самом деле вполне логичны. Скорость работы обеспечивается тем, что все РНР-приложения работают в едином адресном пространстве, тогда как ASP.NET за счет навороченной модели классов многократно проверяет и перепроверяет данные, удерживая каждое приложение в отдельном адресном пространстве. Первый подход более быстр, но менее надежен, второй - более надежен, но за это приходится платить. Чудес не бывает. Быстродействие же связки РНР + MySQL обеспечивается тем, что разрабатывающие эти две технологии группы очень тесно сотрудничают. То же самое и со связкой ASP.NET + MS SQL.

Однако скорость работы РНР с другими СУБД (через ODBC) разочаровала. С большинством известных СУБД, включая MS SQL Server, SAP и MaxDB (тот же SAP, начиная с версии 7.5), он у меня работал медленнее ASP.NET. Насколько я понял, из-за того, что ASP.NET старается делать из БД как можно меньше выборок, помещая все актуальные таблицы и даже связи между ними в кэш (технология ADO.NET в случае с MS SQL), в то время как РНР склонен генерировать множество запросов к СУБД.

Парадокс с ценами, когда оплатить несколько лицензий Microsoft дешевле, чем взять бесплатные Unix/Linux, PHP и MySQL, тоже вполне логичен. Следует учитывать, что, во-первых, эти продукты бесплатны, пока вы не собираетесь делать на них коммерческие проекты (Linux и PHP, конечно, бесплатны без всяких условий. Коммерческая лицензия в полном смысле этого слова есть только у MySQL. Некоторые затраты на PHP, пожалуй, грозят только программистам, делающим скрипты на продажу. Дабы не открывать код скриптов, им приходится использовать продукты компании Zend, а они, увы, платные. - Прим. ред), а во-вторых, что разработка и поддержка проектов под эти платформы в целом обходится дороже. Кроме того, Linux в ряде случаев работает медленнее Windows. Возможно, я ошибаюсь, но ни для какой СУБД я и близко не видел такого количества критических исправлений и сообщений, как для MySQL. А все это есть риск (Редакция умывает руки. Все рассуждения о сложности создания кластеров на Unix целиком на совести автора. Лично мне кажется, умеючи - это не так уж долго, что на Windows, что на Unix, но экспертом в данном вопросе я не являюсь и судить не берусь. - Прим. ред.).

Теперь PHP. Если кратко охарактеризовать ощущения от работы с ним - это постоянная отладка, дебаг. И дело даже не в том, что полноценного дебаггера пока нет (по крайней мере, лучший, что я нашел, Zend Studio, не идет ни в какое сравнение с дебаггером Visual Studio), а в том, что само устройство языка способствует серьезным логическим ошибкам.

Вот пример, который недавно прислала мне однокурсница, попросив помочь:

<p>
<?
$bukvi = ”abcdefg”;
$stroka = ”abcdefg”;
echo $stroka[0]; echo ”<br>”;
echo $bukvi[0]; echo ”<br>”;

if ($srtoka[0] == $bukvi[0])
echo ”строки совпадают”;
else
echo ”строки не совпадают”;
?>
</p>

Сценарий работает, но работает неправильно.

Даже примитивная опечатка (выделена красным) приводит к логической ошибке, которой в C# не было бы в принципе. Вообще, в РНР объявление переменных отсутствует как класс, что, с моей точки зрения, большой минус. А любой сведущий в программировании человек понимает, к чему приводит отсутствие типов в крупном проекте.

Конечно, программисты на РНР могут сказать, что я ничего не понимаю: ведь достаточно залезть в php.ini и настроить вывод предупреждений. Но и здесь не все так просто. Моему знакомому PHP-программисту недавно позвонил работодатель, у которого завис сайт. В результате выяснилось, что хостер обновил PHP с версии 4.3.6 до 4.3.8, в которой предупреждения об использовании необъявленных переменных оказались по умолчанию включены. В итоге сайт стал представлять собой сборник всевозможных предупреждений от движка PHP, поскольку приятель, привыкнув к равнодушию PHP, никогда не затруднял себя объявлением переменных.

Как правило, обновление версии РНР на сервере - головная боль и для заказчиков, и для программистов. Порой найти ошибку очень трудно, особенно если она появляется лишь при определенных обстоятельствах, так что ее можно вообще не выявить до сдачи проекта. В этом и сила, и слабость РНР. Пока в С# вы будете заниматься планированием, писать разные классы, интерфейсы для коллекций и прочая и прочая, чтобы потом одним махом за десять минут сделать страницу, - в РНР вы ту же страницу успеете написать несколько раз. Только вот каждая следующая страница на ASP.NET делается лишь за десять минут, а в РНР снова и снова придется затрачивать то же самое время. Нужно визуально в выводе что-то на странице изменить - в ASP.NET понадобится пять минут, а в РНР - придется искать и править вывод HTML. PHP-программист предпочтет скорее переписать все заново, а в ASP.NET программист будет вынужден использовать готовые наработки. Иначе его просто не возьмут на работу. На таком коллективизме, когда индивидуальность программиста нивелирована до предела, и построена вся философия .NET, и эта философия, повторюсь, прекрасно действует в большом коллективе. А индивидуальность и простота РНР-программирования - в маленьком.

Этот факт хорошо отражает ситуация на рынке труда: соотношение РНР- и ASP.NET-программеров сейчас составляет 3:2, что говорит как о доступности бесплатных продуктов, так и о большом количестве небольших, но амбициозных проектов, для которых PHP подходит идеально. Иная ситуация, например, в Израиле (там соотношение примерно 1:10), Америке и Европе.

Заработок ASP.NET-программиста тоже выше, и если хороший PHP-программист получает у нас в лучшем случае 800, ну максимум 1000 долларов (информация с www.job.ru), то зарплата ASP.NET-программиста, как правило, начинается с 800 долларов. Оно и понятно - ответственности больше, работы больше, геморроя больше, свободы меньше.

Итак, маленькие и средние проекты - удел маленьких групп программистов и PHP; средние и большие - удел больших групп, использующих продукты Microsoft (Это какая-то ложная дихотомия. Можно подумать, что в мире есть только PHP и ASP.NET. Масса крупных проектов сделана на Perl, который лишен перечисленных недостатков PHP и прекрасно работает. - Прим. ред), а также очень немногочисленных хорошо организованных групп программистов на РНР; гигантские проекты делят между собой продукты HP, IBM, Sun, Oracle, и расценки там в несколько раз выше. Но это уже совершенно другая история.

Что выбрать начинающему программисту? Затрудняюсь ответить однозначно. РНР, конечно, проще… но я все-таки советовал бы изучать ASP.NET, у него абсолютно точно есть будущее в средних и крупных компаниях, чего не скажешь о РНР. Отмечу также, что ситуация на рынке труда всего лишь год-полтора назад была примерно 1:9 в пользу РНР, и радикальное изменение этого соотношения не может не насторожить.

Если же повезет и если ты действительно хороший программист - можно попасть в "совершенно другую историю", где и зарплата совершенно другая. Этому может способствовать участие в различных конкурсах, проводимых компаниями (попасть туда иным путем, без серьезных наработок на стороне, очень трудно).