В 2000 году я был большим фанатом PHP. Я начал пользоваться им сразу после официального выхода версии 4.0 в апреле. В то время кроме него было всего 4 альтернативы для создания веб-сайтов.
1) C – слишком сложный для часто меняющегося проекта. Компиляция занимала много времени, было мало свободных инструментов, а платные не влезали в мой бюджет. Слишком многословный. Управление зависимостями было сложным делом.
2) Java – лучше, чем С, но всё ещё многословный и долго компилирующийся. Управление зависимостями было сложным делом.
3) Perl – почти так же хорош, как PHP, только без системы управления пакетами. На CPAN был набор модулей на все случаи жизни, но их надо было скачивать и устанавливать. Управление зависимостями было сложным делом.
4) ASP – почти так же хорош, как PHP, только это был инструмент от Microsoft, и его использование засосало бы меня в их дорогой мир.
Для трёх позиций я написал: " Управление зависимостями было сложным делом". Для меня это был ключевой момент PHP. Его философия была «всё в одном». Таких, как сейчас, систем управления пакетами тогда не было. Сейчас есть удобные штуки типа Bundler для Ruby и Leiningen для Clojure. Но не в 2000-м. Даже системы управления пакетами в Linux стали лучше с 2000 года. А система «всё в одном» решала проблемы управления пакетами в PHP. Но теперь это преимущество не имеет значения.
У PHP есть и другие сильные стороны. Он оптимизирован для веба, но это сегодня не уникально. Для тех, кто боялся С, он предложил обёртки для функций С. Но в других языках сегодня всё ещё проще:
За последние несколько лет я работал в разных корпорациях (Wine Spectator, Timeout) над их системами. В основном это был PHP и фрейморк Symfony. Я уже критиковал их ранее. Мне кажется, что люди, использующие в корпоративных задачах PHP в наше время, забыли, почему PHP нравился им раньше. Можно рассказать, какие преимущества были у него в 2000 году, но сегодня? Он медленный, неуклюжий, системы стали слишком сложными, некомпилируемая сущность языка встаёт на пути попыток сделать на нём большие проекты. Если вы делаете CMS в проекте, которому нужны 100 серверов, вам придётся деплоить CMS целиком на каждый из 100 серверов.
Какие инновации в мире PHP существуют сегодня?
Люди добавляют pthreads, когда в языке нет инструментов для работы с параллелизмом. Для контраста взгляните на Clojure.
Сложная система кэширования кода у Symfony.
В комментарии добавляют аннотации – инструкции, контролирующие выполнение программы. Мне кажется, что это плохая идея. Если вам необходимо моделировать взаимодействующие проблемы (cross-cutting concerns), вам нужно выбрать язык, который делает это элегантно, а не полагаться на сырое решение вроде аннотаций.
Список изменений и исправлений, которые необходимо сделать из-за длинной истории противоречивой разработки.
Разбухшее управление памятью.
Ритуальное программирование – куча ненужных инструкций, без преимуществ вроде проверки на этапе компиляции. В 2000 одним из аргументов в пользу PHP было то, что в нём не было лишнего кода, типичного для Java. Хотим ли мы, чтобы PHP полностью превратился в Java?
Любовь к сложности ради сложности.
Никаких настроек для управления и конфигурирования. Это похоже на отсутствие систем управления пакетами, от которого PHP страдал – в отличие от Ruby, Python или Clojure. Но в PHP не ведётся никакой работы по исправлению ситуации – это перекладывается на плечи инструментов сисадмина вроде Chef и Supervisor.
Обилие обезьяньих патчей (подмены методов и значений атрибутов классов программы во время ее выполнения). traits похожи на обезьяньи патчи в Ruby, но с traits ещё сложнее работать, а также отслеживать и отлаживать их.
Амбиции, обгоняющие сам язык. Как сказал Фабьен Потансье, у PHP есть несколько замечательных свойств. Что странно. Это как если бы мы вставили мощный движок от Ferrari в ржавый Fiat.
Бесконечное множество функций, введённых для удобства.
И не могу не вспомнить знаменитое эссе: "PHP: фрактал плохого дизайна".
Когда у PHP встречаются крутые штуки (Streams и Iterators), они получаются как бы прибитыми к языку, а не интегрированными в него. Они не ощущаются частью философии языка. Вместо этого Рамус Лердорф говорит вещи навроде:
Для сравнения, Юкихиро Мацумото описывает Ruby так:
Недостаток глубокого видения у лидеров команды разработчиков PHP ведёт к уродливым проявлениям, в частности, к отсутствию наставлений для начинающих программистов о том, как писать на PHP хороший код.
В 2004 году внезапно появился Ruby On Rails, и пообещал спасти всех от сложности Java и беспорядка PHP. В то время это было большое улучшение. В нём была структурированность и элегантность, недоступная PHP. Но сегодня даже Rails устарел. Сегодня Ruby и PHP одинаково плохо работают с паралеллизмом. Они разрабатывались тогда, когда у компьютерных процессоров было одно ядро, которое со временем становилось всё быстрее. Но будущее подчиняется закону Амдала, и в этом направлении им нечего предложить. jRuby – будущее Ruby, один из тех языков, которые сегодня стоит рассматривать. Но нет языка, про который можно было бы сказать «это будущее PHP».
Хотелось бы мне, чтобы люди могли ответить мне на вопрос «почему бы я сегодня выбрал для себя PHP?». В 2000 году аргументы за него были убедительными, но сегодня таких причин нет. Мир изменился, и сейчас есть десятки лучших возможностей.
1) C – слишком сложный для часто меняющегося проекта. Компиляция занимала много времени, было мало свободных инструментов, а платные не влезали в мой бюджет. Слишком многословный. Управление зависимостями было сложным делом.
2) Java – лучше, чем С, но всё ещё многословный и долго компилирующийся. Управление зависимостями было сложным делом.
3) Perl – почти так же хорош, как PHP, только без системы управления пакетами. На CPAN был набор модулей на все случаи жизни, но их надо было скачивать и устанавливать. Управление зависимостями было сложным делом.
4) ASP – почти так же хорош, как PHP, только это был инструмент от Microsoft, и его использование засосало бы меня в их дорогой мир.
Для трёх позиций я написал: " Управление зависимостями было сложным делом". Для меня это был ключевой момент PHP. Его философия была «всё в одном». Таких, как сейчас, систем управления пакетами тогда не было. Сейчас есть удобные штуки типа Bundler для Ruby и Leiningen для Clojure. Но не в 2000-м. Даже системы управления пакетами в Linux стали лучше с 2000 года. А система «всё в одном» решала проблемы управления пакетами в PHP. Но теперь это преимущество не имеет значения.
У PHP есть и другие сильные стороны. Он оптимизирован для веба, но это сегодня не уникально. Для тех, кто боялся С, он предложил обёртки для функций С. Но в других языках сегодня всё ещё проще:
проблемы языка Julia в настоящее время – относительная нехватка библиотек. Но в языке достаточно просто взаимодействовать с существующими библиотеками из С. В отличие от других языков, вы можете вызывать код С, не написав ни строчки на С, и поэтому я думаю, что библиотеки для Julia быстро подтянутся. По моему опыту у меня получилось использовать 5 000 строк С-кода через 150 строк кода на Julia.
За последние несколько лет я работал в разных корпорациях (Wine Spectator, Timeout) над их системами. В основном это был PHP и фрейморк Symfony. Я уже критиковал их ранее. Мне кажется, что люди, использующие в корпоративных задачах PHP в наше время, забыли, почему PHP нравился им раньше. Можно рассказать, какие преимущества были у него в 2000 году, но сегодня? Он медленный, неуклюжий, системы стали слишком сложными, некомпилируемая сущность языка встаёт на пути попыток сделать на нём большие проекты. Если вы делаете CMS в проекте, которому нужны 100 серверов, вам придётся деплоить CMS целиком на каждый из 100 серверов.
Какие инновации в мире PHP существуют сегодня?
Люди добавляют pthreads, когда в языке нет инструментов для работы с параллелизмом. Для контраста взгляните на Clojure.
Сложная система кэширования кода у Symfony.
В комментарии добавляют аннотации – инструкции, контролирующие выполнение программы. Мне кажется, что это плохая идея. Если вам необходимо моделировать взаимодействующие проблемы (cross-cutting concerns), вам нужно выбрать язык, который делает это элегантно, а не полагаться на сырое решение вроде аннотаций.
Список изменений и исправлений, которые необходимо сделать из-за длинной истории противоречивой разработки.
Разбухшее управление памятью.
Ритуальное программирование – куча ненужных инструкций, без преимуществ вроде проверки на этапе компиляции. В 2000 одним из аргументов в пользу PHP было то, что в нём не было лишнего кода, типичного для Java. Хотим ли мы, чтобы PHP полностью превратился в Java?
Любовь к сложности ради сложности.
Никаких настроек для управления и конфигурирования. Это похоже на отсутствие систем управления пакетами, от которого PHP страдал – в отличие от Ruby, Python или Clojure. Но в PHP не ведётся никакой работы по исправлению ситуации – это перекладывается на плечи инструментов сисадмина вроде Chef и Supervisor.
Обилие обезьяньих патчей (подмены методов и значений атрибутов классов программы во время ее выполнения). traits похожи на обезьяньи патчи в Ruby, но с traits ещё сложнее работать, а также отслеживать и отлаживать их.
Амбиции, обгоняющие сам язык. Как сказал Фабьен Потансье, у PHP есть несколько замечательных свойств. Что странно. Это как если бы мы вставили мощный движок от Ferrari в ржавый Fiat.
Бесконечное множество функций, введённых для удобства.
И не могу не вспомнить знаменитое эссе: "PHP: фрактал плохого дизайна".
Когда у PHP встречаются крутые штуки (Streams и Iterators), они получаются как бы прибитыми к языку, а не интегрированными в него. Они не ощущаются частью философии языка. Вместо этого Рамус Лердорф говорит вещи навроде:
У нас есть защищённые свойства, абстрактные методы, вся эта фигня, про которую ваш учитель информатики вам рассказывал. Мне на всё это дерьмо плевать.
Для сравнения, Юкихиро Мацумото описывает Ruby так:
Для меня часть смысла жизни состоит в радости. Программисты радуются, когда они могут сконцентрироваться на творческом аспекте программирования. Ruby разработан так, чтобы делать программистов счастливыми. Если вы делаете работу быстро и весело, это же хорошо, не так ли? Ваша жизнь становится лучше. Я хочу решать повседневные задачи при помощи компьютера, поэтому я пишу программы. Используя Ruby, я хочу концентрироваться на том, что я делаю, а не на волшебных правилах языка вроде необходимости начинать программу со слов «public void что-то что-то что-то» для того, чтобы потом сказать «print hello world».
Недостаток глубокого видения у лидеров команды разработчиков PHP ведёт к уродливым проявлениям, в частности, к отсутствию наставлений для начинающих программистов о том, как писать на PHP хороший код.
В 2004 году внезапно появился Ruby On Rails, и пообещал спасти всех от сложности Java и беспорядка PHP. В то время это было большое улучшение. В нём была структурированность и элегантность, недоступная PHP. Но сегодня даже Rails устарел. Сегодня Ruby и PHP одинаково плохо работают с паралеллизмом. Они разрабатывались тогда, когда у компьютерных процессоров было одно ядро, которое со временем становилось всё быстрее. Но будущее подчиняется закону Амдала, и в этом направлении им нечего предложить. jRuby – будущее Ruby, один из тех языков, которые сегодня стоит рассматривать. Но нет языка, про который можно было бы сказать «это будущее PHP».
Хотелось бы мне, чтобы люди могли ответить мне на вопрос «почему бы я сегодня выбрал для себя PHP?». В 2000 году аргументы за него были убедительными, но сегодня таких причин нет. Мир изменился, и сейчас есть десятки лучших возможностей.
