Комментарии 20
PHP, конечно, не без недостатков, но язык развивается, и 7ая версия совсем не так плоха, насколько была 4ая (или даже 5.0)
Но огорчает другое. Как известно, PHP процесс оживает при каждом запросе и умирает, только затем, чтобы отрендерить страницу или обработать данные (AJAX/REST) — это должно делаться за миллисекунды. Так зачем за эти миллисекунды заставляют поднимать кучу библиотек фреймворков со всей магией (ORM, процессинг аннотаций и т.д.) — на каждый запрос! Если это уместно на «долгоживущих» платформах, то неуместно на платформе PHP (и даже язык тут не имеет значения, а именно платформа)
Но огорчает другое. Как известно, PHP процесс оживает при каждом запросе и умирает, только затем, чтобы отрендерить страницу или обработать данные (AJAX/REST) — это должно делаться за миллисекунды. Так зачем за эти миллисекунды заставляют поднимать кучу библиотек фреймворков со всей магией (ORM, процессинг аннотаций и т.д.) — на каждый запрос! Если это уместно на «долгоживущих» платформах, то неуместно на платформе PHP (и даже язык тут не имеет значения, а именно платформа)
Статья какая то троличя, большинство описанных проблем вовсе не явлляются проблемами, 7 PHP очень даже хорош. Поставило в тупик замечание проcall_user_func_array — что там такого странного я так и не понял, даже полез в документацию и ничего странного не обнаружил
Простите, с документацией я действительно погорячился — хак описан в комментарии к официальной документации (http://php.net/manual/ru/function.call-user-func-array.php#91503). Статью исправил и дополнил.
Дело в том, что начиная с версии 5.4 передача ссылок в функцию недопустима (http://php.net/manual/ru/language.references.pass.php). Это логично, но, например, конструкция
function (&$a, &$b) { return call_user_func_array('f', func_get_args()); }
перестала работать как ожидается.
Дело в том, что начиная с версии 5.4 передача ссылок в функцию недопустима (http://php.net/manual/ru/language.references.pass.php). Это логично, но, например, конструкция
function (&$a, &$b) { return call_user_func_array('f', func_get_args()); }
перестала работать как ожидается.
Понятно, но причину проблемы вижу в использовании антипатернов языка: передача параметров по ссылке зло в PHP по многим причинам и если есть желание или необходимость, то следует пользоваться объектами. Любой язык позволяет творить всякую хрень и не вина языка в этом
>> передача параметров по ссылке зло в PHP по многим причинам
Собственно моя претензия к языку в данном случае в том и заключается — почему это в нём вообще существует в таком странном виде.
Собственно моя претензия к языку в данном случае в том и заключается — почему это в нём вообще существует в таком странном виде.
Ну очевидно ведь — по историчиским причинам и обратной совместимости, ведь никто уже не помнит, что был PHP 3 b yb; и ниже
О какой обратной совместимости речь, если вызов
f(&$a)
приводит:
— к непримечательному вызову в 5.2
— к Deprecated в 5.3
— к Fatal error в 5.4
— к Parse error в 7
Но не для call_user_func_array. Вот эта конструкция (её вполне можно встретить — не столь буквально конечно, что, правда, ещё хуже):
function f1($a, &$b) {
$a++;
$b++;
return $a + $b;
}
function f2(&$a, &$b) {
return call_user_func_array('f1', array(&$a, &$b));
}
$a = 1;
$b = 2;
$c = f2($a, $b);
var_dump($a, $b, $c);
без всяких предупреждений выводит:
— 2, 3, 5 в 5.3
— 1, 3, 5 в 5.4
f(&$a)
приводит:
— к непримечательному вызову в 5.2
— к Deprecated в 5.3
— к Fatal error в 5.4
— к Parse error в 7
Но не для call_user_func_array. Вот эта конструкция (её вполне можно встретить — не столь буквально конечно, что, правда, ещё хуже):
function f1($a, &$b) {
$a++;
$b++;
return $a + $b;
}
function f2(&$a, &$b) {
return call_user_func_array('f1', array(&$a, &$b));
}
$a = 1;
$b = 2;
$c = f2($a, $b);
var_dump($a, $b, $c);
без всяких предупреждений выводит:
— 2, 3, 5 в 5.3
— 1, 3, 5 в 5.4
Я так понимаю, что на каждый пункт в статье, люди в комментариях должны приводить контр-аргументы?
Как работает http — делаем запрос -> получаем ответ
php заточен под web
как работает php — получили запрос -> отдали ответ -> умерли
стоит вспомнить про php-fpm, который не все время умирает
и такие вещи как https://github.com/reactphp, https://github.com/amphp — если нужно не умирать
php заточен под web
как работает php — получили запрос -> отдали ответ -> умерли
стоит вспомнить про php-fpm, который не все время умирает
и такие вещи как https://github.com/reactphp, https://github.com/amphp — если нужно не умирать
В случае FastCGI не умирает интерпретатор, а интерес (по крайней мере, в данной статье) представляет скрипт, который он обрабатывает.
Можно реализовать и сервер (sockets: http://php.net/manual/ru/book.sockets.php), и многопоточность (pcntl: http://php.net/manual/ru/book.pcntl.php; phthreads: http://php.net/manual/ru/book.pthreads.php; generators: http://php.net/manual/ru/language.generators.overview.php) без всяких дополнительных либ, используя просто имеющиеся стандартные расширения.
В общем, дело не в том, что чего-то нельзя в скрипте написать. Просто правильная задача для PHP мне видится как раз в связывании расширений между собой, а не в реализации всей функциональности в скриптах. Продолжительность работы, естественная для приложений, для скриптов PHP больше напоминает эксперименты — это как-будто неизлечимо больного при смерти всё время держат под капельницей или упорно пытаются научить художника-заику петь.
Если приложение работает как расширение, то ему всё равно, в каком из тысячи возможных режимов работает PHP и обрабатываемый им скрипт, как и скрипт не пытается бороться сам с собой, с интерпретатором и средой.
Можно реализовать и сервер (sockets: http://php.net/manual/ru/book.sockets.php), и многопоточность (pcntl: http://php.net/manual/ru/book.pcntl.php; phthreads: http://php.net/manual/ru/book.pthreads.php; generators: http://php.net/manual/ru/language.generators.overview.php) без всяких дополнительных либ, используя просто имеющиеся стандартные расширения.
В общем, дело не в том, что чего-то нельзя в скрипте написать. Просто правильная задача для PHP мне видится как раз в связывании расширений между собой, а не в реализации всей функциональности в скриптах. Продолжительность работы, естественная для приложений, для скриптов PHP больше напоминает эксперименты — это как-будто неизлечимо больного при смерти всё время держат под капельницей или упорно пытаются научить художника-заику петь.
Если приложение работает как расширение, то ему всё равно, в каком из тысячи возможных режимов работает PHP и обрабатываемый им скрипт, как и скрипт не пытается бороться сам с собой, с интерпретатором и средой.
В общем всё плохо
стоит ли вообще его использовать хотя бы для странички заказа пиццы.
И всё это для того, чтобы отдать HTML-страничку сомнительной художественной ценности.
Перебор желчи
есть у меня личный кабинет энергосбытовой компании на php+ms sql
при 70000 абонентов неплохо справляется со своей функцией
на лету формирует печатные формы счетов в PDF из реальной БД
и раз в месяц рассылает всем юрлицам (10000 договоро) весь пакет документов (счет, счет-фактиура, акт сверки, акт приема-передачи) менее чем за 8 часов. И это на сервере с 4-я ядрами и 16 гигами оперативки.
Так что хоронить рановато еще
при 70000 абонентов неплохо справляется со своей функцией
на лету формирует печатные формы счетов в PDF из реальной БД
и раз в месяц рассылает всем юрлицам (10000 договоро) весь пакет документов (счет, счет-фактиура, акт сверки, акт приема-передачи) менее чем за 8 часов. И это на сервере с 4-я ядрами и 16 гигами оперативки.
Так что хоронить рановато еще
Статья из разряда: «посоны, я отстрелил себе яйца из кольта 45 калибра. 45 — херня. Баллистическая ракета — лучше». Нытье про то, какой PHP плохой надоело уже. Да, это не самый подходящий инструмент для GUI и драйверов. С таким же успехом можно критиковать Си или Java: какие же они убогие, элементарное «Привет Мир!» в браузер вывести просто так не могут. А PHP может. МОЖЕТ:
Ни одной строчки кода.
Не устраивает поведение некоторых стандартных функций? Напиши свои, если ты такой крутой «Сишнег». Весь код ядра PHP открыт. Все спецификации открыты. Пиши расширение — и в путь.
«Глупо ругать молоток, если ударил им себе по пальцу» (с)
Привет Мир!Ни одной строчки кода.
Не устраивает поведение некоторых стандартных функций? Напиши свои, если ты такой крутой «Сишнег». Весь код ядра PHP открыт. Все спецификации открыты. Пиши расширение — и в путь.
«Глупо ругать молоток, если ударил им себе по пальцу» (с)
Наличие у файла расширения «php» ещё не делает его PHP-скриптом.
А в остальном — цитата из статьи:
«На мой взгляд, PHP позволяет сконцентрироваться на функциях собственно приложения, отделив его от гипертекстового интерфейса, который просто и удобно разрабатывать на PHP. <...> Каждый инструмент хорош на своём месте и плох на всех остальных.»
Смысл статьи не в критике PHP. Однако PHP развивается во многом благодаря критике — содержательной, разумеется, нытье ничего полезного не несёт, в этом вы совершенно правы.
А в остальном — цитата из статьи:
«На мой взгляд, PHP позволяет сконцентрироваться на функциях собственно приложения, отделив его от гипертекстового интерфейса, который просто и удобно разрабатывать на PHP. <...> Каждый инструмент хорош на своём месте и плох на всех остальных.»
Смысл статьи не в критике PHP. Однако PHP развивается во многом благодаря критике — содержательной, разумеется, нытье ничего полезного не несёт, в этом вы совершенно правы.
PHP — это гипертекстовый препроцессор.
И написан на чистом Си и фактически является обёрткой для Си. Синтаксис крайне удобен и прост. Совершенно оправдано упрощена работа с типами и с памятью.
Функционал, наверное, даже слишком богатый для задач, которые подразумевалось изначально на это языке решать.
А подразумевалось писать простейшие динамические страницы: блоги, гостевые, ленты, архивы статей.
И весь возможный и оправданный функционал таких сайтов на PHP можно также описать одной строчкой:
вывод/ввод из бд текста, пагинация, поиск, рубрикаторы. И еще несколько десятков мелочей.
Яркий пример, на мой взгляд, правильного использования PHP — это Википедия.
Но человеку же всегда мало: надо же к Жигулям турбину и складывающиеся крылья.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PHP: фрактал нецелевого использования