Сегодня мне в асю кинули вот такой вот материал для размышления. К сожалению в Yandex'е я так и не смог найти сайт с оригиналом текста, но все же вот этот текст неизвестного автора:

«Распространенность php вызвана легкостью установки его на сервере, малым количеством парадигм, заложенным в язык (императив + недо-ооп) -» легкость изучения а т.ж. тем, что это именно узко-нишевый язык, заточенный под веб, в отличие от java, ruby, python, perl - языков общего назначения, сравните распространенность php и perl/python на десктопе и все станет на свои места.. По большому счету это не язык, это всего лишь _препроцессор текста_, у него нет даже виртуальной машины, он не приспособлен для long-running-processes, на нем даже не напишешь stand-alone сервер, нет потоков, это паталогически _не правильный_ язык (если все же рассматривать его как язык), который подобает использовать ясно осознавая эту всю его неправильность - отсутствие модулей (пакетов, неймспейсов), отсутствие высокоуровневых типов данных, огромное количество глобальных не очень системно названных функций вида another_this_very_useful_function (ввиду отсутствия модулей), перемешивание логики работы и отображения, не способствующее MVC, отсутствие такого полезного высокоуровневого средства как исключения: Все попытки как то окультурить это дело (Smarty, всякие ORM-ы) производят впечатление мягко говоря использования средства не по назначению. php идеально подходит для не очень больших обособленных програмных комплексов типа форумов, гостевых, различных других веб-скриптов, кое-как для небольших CMS. Для других более сложных enterprise веб-приложений использование PHP возможно, но не обосновано в виду слабой масштабируемости (как там насчет кластеризации, load-balancing'а), не модульности, отсутствием высокоуровневых средств языка. В этом сигменте гораздо лучше подходят языки общего назначения, позволяющие писать приложения, выполняющиеся на специальном application server'е. А использование PHP CLI это вообще из ряда вон выходящее извращение:»

Итак, по пунктам:

1) По каким критериям автор оценивал что является языком программирования, а что нет. По легкости изучения? Так что же паскаль (delphi) тоже в трешь? Или узкая заточка под конкретные цели тоже теперь переводит язык программирования в разряд «всяких там процессоров». Может тогда Фортран тоже в трешь, на нем все рано только только считать - «недоязык»?

2) «сравните распространенность php и perl/python». И что? Что под наш всеобъемлющий Windows пишется много программ на perl? А ведь пока никто не отменял монополию Microsoft на рынке десктопов. Работе с Windows учат в школах, в СУЗах, и даже в высших учебных заведениях. Но это уже другая тема. А если речь шла о unix десктопах, то тем более пример «ни о чем». Полно системных утилит написанных на PHP. И работают они на равнее с perl утилитами.

3) «у него нет даже виртуальной машины» - у Си тоже нет виртуальной машины (поправьте меня Си кодеры, если я отстал от жизни). Так что даже Си в трешь?

4) « на нем даже не напишешь stand-alone сервер». Да ну! Согласен, что писать на php серверное ПО это чушь, но, тем не менее, вполне реальная чушь. А что на Perl писать stand-alone сервер менее бредовая идея?

5) Как это в PHP нет пакетов расширений. А как же PEAR? Автор явно даже не «пробовал PHP». Об этом говорит такая фраза как «отсутствие такого полезного высокоуровневого средства как исключения». В PHP есть исключения (по крайней в пятой версии точно есть).

6) «перемешивание логики работы и отображения». Вот это называется, неудачная попытка перевернуть все с ног на уши. Это с каких пор наличие опций считается недостатком. Все профессиональные php кодеры полностью разделяют логику и представление. А возможность вставлять в HTML куски кода только помогает в изучении языка. Но, об легкости изучения я уже писал.

7) «кое-как для небольших CMS». Автор явно не в теме того, что уже написано на PHP.

8) «как там насчет кластеризации, load-balancing'а». А как там на счет load-balancing'а на уровне сервера? Кластеризация? Ну да: разве нельзя сделать кластер из серверов с PHP? Не понимаю причем тут именно PHP: или тут пыталась пройти мысль об отсутствии в PHP средств для программирования параллельных вычислений. В чистом Си их тоже нет и что?

Вот такое вот пишут о PHP обиженные C# (про C# это только мое предположение, аргументы пока оставлю при себе) кодеры. 

Автор: Василий Котов
Сайт автора: http://kotov.phpwars.net/

Мои 5 копеек:

1) нет, по теоретическим основам и выразительности (сравни с Ruby и Python'oм). Полностью согласен с автором в плане PHP4, и не согласен для PHP5, последний уже более терпим и реально большие проекты на нём писать можно.

2) не ясно что хотел сказать оппонент, при чём тут win/*nix системы...? На PHP можно написать вебсервер (такой уже есть), можно очень многое написать из-за массы плагинов/биндингов на разное нативное API. Но! никто не задумывается особо использовать PHP в этом качестве, большей частью потому, что программисты на PHP обычно не занимаются не веб-ориентированным софтом. С тем же успехом можно и на чистом ассемблере что нибудь большое написать, но таких чудаков не найти, значит дело здесь в удобстве ;-)

3) VM есть у всех скриптовых языков. Автор вероятно имел в виду поддержку JIT'а + расширенные возможности рефлексии. PHP5 в этом плане далеко не так плох.

4) (веб, ftp, rsync, etc)сервер на Python'е далеко не чушь. Подобное на PHP более страшно, т.к. работа с памятью у PHP заточенна под очень быстрые, не multi-threaded приложения. Потому он и сорит памятью, но какое это имеет значение если на запрос выдаётся целый блок, отработать нужно в микросекунды и освободим память тоже целым блоком со всем мусором. Это идеальная для веб-приложений работа с памятью, но ставит крест на long-running софте.

5) PEAR весьма мерзкое поделие по мнению многих, призванное скорее латать бреши дизайна PHP4. Да, там много полезных либ, но это не сравниться по количеству и главное по качеству с модулями для Perl (поброди по cpan.org) или Python. 

6) 7) Согласен с оппонентом.

8) Согласен с оппонентом. load-balancing это задача сервера, а не скриптового движка. PHP очень хорошо масштабируем (википедия тому пример), потому что запросы обрабатываются движком индивидуально. Связующим звеном между двумя работающими скриптами может быть БД/реплика, общий (мем)кеш сервер, на худой конец файлы. Но между собой "общаться на прямую" они не могут, значит нет проблем с синхронизацией, значит не будет простоев от криворуких программистов и нет зависимостей - это позволяет выполнить два запроса на разных апп.серверах и расширять кластер до любых размеров.

Попытался быть объективен 

Оба поста на 5 баллов. Спасибо. Очень интересно было почитать.

Маленькие скрипты PHP5(zend engine2) обрабатывает быстрее чем perl. Но вот в больших скриптах, PHP, к сожалению, уступает perl'у в скорости.

Текст этот читал довольно давно, оригинал однозначно в ЖЖ, но найти не удалось. Возможно пост удалили, возможно моё умение обращаться с Google меня подвело. Жаль, там помимо этого поста и этого конкретного ответа ещё небольшая дискуссия была.

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