Ракета Союз, доставленная на поезде на пусковую площадку. Фото из общественного достояния NASA.
Это перевод статьи Taking PHP Seriously, автор которой является одним из инженеров известного приложения Slack. Он рассказывает о недостатках и преимуществах PHP, а также о языке Hack и виртуальной машине HHVM, на которую почти завершил переход Slack.
Slack использует PHP для большей части своей серверной логики, что является не самым популярным выбором в наши дни. Почему же мы решили написать новый проект именно на этом языке? Следует ли вам поступать также?
Большинство программистов, которые немного игрались с PHP, знают две вещи про него: это плохой язык, который они никогда не станут использовать при наличии выбора, и что некоторые из чрезвычайно успешных проектов в истории мира используют его. Это не совсем противоречие, но этот факт должен заставить вас задуматься. То есть, Facebook, Wikipedia, Wordpress, Etsy, Baidu, Box и в последнее время Slack — все они успешно решают проблемы, не смотря на то, что используют PHP? Были ли бы они более успешными, если бы они использовали у себя Ruby? Erlang? Haskell?
Вполне возможно, что нет. Язык PHP имеет множество недостатков, которые, несомненно, замедлили его развитие, но среда PHP имеет такие достоинства, которые более чем компенсируют данные недостатки. И он также имеет способы разрешения его собственных языковых проблем, которые вполне впечатляют. По итоговым результатам, PHP предоставляет наилучший фундамент для создания, изменения и эксплуатации успешного веб-проекта по сравнению с конкурирующими средами. Сегодня я хотел бы начать новый проект на PHP, с парой оговорок, но не видя причин извиняться за это.
Исторический экскурс
PHP родился в уникальной для современных языков среде веб-сервера. Его сильные стороны связаны с контекстом запроса на сервере.
PHP изначально назывался "Персональная Домашняя Страница". Он был опубликован в 1995г. Расмусом Лердорфом, с нацеливанием на поддержку маленьких, простых динамических веб-приложений, вроде гостевых книг и счётчиков посетителей, популярных на заре Интернета.
С момента релиза PHP, он был использован в намного более сложных проектах, чем изначально ожидали его авторы. Он претерпел несколько мажорных изменений, каждое из которых принесло новые механизмы для обуздания этих сложных приложений. Сегодня, в 2016, он является богатым фичами членом семьи Смешанной Парадигмы Продуктивных Языков (MPDPL) [1], которая включает JavaScript, Python, Ruby и Lua. Если вы пробовали PHP в ранние 2000-ные, современная кодовая база PHP может удивить вас трейтами, замыканиями и генераторами.
Добродетели PHP
PHP имеет несколько очень глубоких и, однозначно, верных особенностей.
Первая, состояние. Каждый веб-запрос начинается с совершенно чистого листа. Его пространство имён и глобальные переменные не инициализированы, за исключением некоторых стандартных глобальных переменных, функций и классов, которые предоставляют примитивную функциональность и жизнеобеспечение. Начиная каждый запрос с известного состояния, мы получаем своего рода изоляцию от возможных ошибок; если запрос t сталкивается с неполадкой ПО и завершается с ошибкой, данный баг не оказывает никакого влияния на выполнение последующего запроса t+1. В действительности, конечно же, помимо программной кучи, состояние приложения находится и в других местах, и вполне возможно полностью испортить базу данных, memcache или файловую систему. Но PHP разделяет эту слабость со всеми мыслимыми средами, которые позволяют сохранять состояние. В то же время, разделение программных куч между запросами снижает цену большинства программных ошибок.
Вторая, параллелизм. Индивидуальный запрос работает в одном PHP потоке. На первый взгляд, это кажется глупым ограничением. Но так как наше приложение выполняется в контексте веб-сервера, мы имеет натуральный источник параллелизма: веб запросы. Асинхронный curl'инг на локалхост (или даже другой веб-сервер) предоставляет неразделяемый (shared-nothing), копирование-в/копирование-из подход использования параллелизма. На практике, это безопаснее и устойчивее к ошибкам, чем подход с блокировками и разделяемым состоянием, который используется в других языках общего назначения.
В заключении, тот факт, что PHP программы оперируют на уровне запросов, означает, что рабочий процесс программиста является быстрым и эффективным, и остаётся быстрым после изменения приложения. Множество языков продуктивной разработки претендуют на это, но если они не очищают своё состояние при каждом запросе, и основной поток событий разделяет программный уровень состояния между запросами, они почти всегда требуют некоторое время на запуск. Для типичного сервера приложений на Python'е, типичный цикл отладки будет выглядеть примерно как «подумать, отредактировать, перезапустить сервер, отправить несколько тестовых запросов». Даже если «перезапустить сервер» занимает всего несколько секунд из общего количества часов, это забирает большой срез из 15-30 секунд наших человеческих мозгов на необходимость удержания в голове самой ненужной части текущего состояния.
Я утверждаю, что разработка на PHP в стиле «подумать, отредактировать и перезагрузить страницу» делает разработчиков более продуктивными. В долгих и сложных циклах разработки проектов это даёт ещё больший прирост.
Доводы против PHP
Если всё это является правдой, почему же его так ненавидят? Когда вы уберёте все красочные гиперболы в сторону, что основные жалобы о PHP кластере сведутся к следующим проблемам:
- Сюрпризы при преобразованиях. Почти все языки в наши дни позволяют сравнить, например, integer и float с оператором >=; Чёрт, даже C позволяет. Совершенно понятно, что здесь имеется ввиду. Менее очевидно сравнение строки и числа с помощью ==, и разные языки делали разный выбор. Выбор PHP в данной ситуации наиболее порочен, что приводит к сюрпризам и неприятным ошибкам. К примеру, 123 == '123foo' оценивается как истина (что он там делает?), но 0123 == '0123foo' является ложью (хмм).
- Несогласованность вокруг ссылок и семантических значений. PHP 3 имел чёткую семантику передачи аргументов, возвращения всего по значению, создавая логическую копию данных в запросе. Программист может выбрать ссылочную семантику вместе со знаком & [2]. Это возникло вместе с введением объектно-ориентированных средств программирования в PHP 4 и 5. Большинство PHP ОО-аннотаций были позаимствованы из Java, и Java имеет семантику, в которой объект передаётся по ссылке, в то время как примитивные типы передаются по значению. В итоге, текущее состояние семантики PHP заключается в том, что объекты передаются по ссылке (выбираем Java, вместо, скажем, C++), примитивные типы передаются по значению (здесь Java, C++, и PHP согласен), но старая ссылочная семантика и знак & остались, время от времени взаимодействуя с новым миром неоднозначными способами.
- Философия вычислений, игнорирующих отказы. PHP пытается очень, очень трудно сохранять запрос запущенным, даже если он уже наделал чего-то совсем странного. Так, к примеру, деление на ноль не бросает исключения, не возвращает INF, и не завершает фатально запрос. По умолчанию, он просто предупреждает и присвоит значение как false. Так как false молча рассматривается как 0 в числовых контекстах, множество приложений разворачиваются и запускаются с недиагностированными делениями на ноль. Конкретно эта проблема была разрешена в PHP 7, но импульс в дизайне к обработке неоднозначностей, даже когда они могут иметь смысл, пропитывает в том числе и библиотеки.
- Противоречия в стандартной библиотеке. Когда PHP был молодым, его аудитория была наиболее знакома с C, и множество API использовали дизайн стандартной библиотеки языка C: шести-символьные имена в нижнем регистре, ответы об успешном/неуспешном выполнении и возвращающие реальное значение в вызываемый параметр «out», и так далее. По мере развития PHP, C-шный стиль разделения на пространства имён через префиксы с _ стал более распространённым: mysql_..., json_..., и так далее. А совсем недавно, camelCase стиль именования методов из Java на классах CamelCase стал самым распространённым способом введения новых функциональных возможностей. Так, что в итоге, иногда мы видим примеры кода с перемешанными выражениями вроде DirectoryIterator($path) вместе с if (!($f = fopen($p, ‘w+’))… в сбивающей с толку логике.
Чтобы не показаться нерефлективным апологетом PHP: всё это серьёзные проблемы, которые позволяют более вероятно создавать дефекты. Они являются явными ошибками (unforced errors). Здесь нет присущего компромисса между Хорошими Частями PHP и данными проблемами. Должна быть реализована возможность создать PHP, который разрешит данные недостатки, сохранив при этом все хорошие стороны.
HHVM и Hack
Этот преемник системы PHP зовётся Hack [3]
Hack — это такой язык программирования, который люди называют «постепенная система типов» для PHP. «Система типов» значит, что он позволяет программисту составлять автоматически проверяемые инварианты о данных, которые протекают через код: данная функция берёт строку или число и возвращает лист Fribbles, как например в Java или C++ или Haskell, или в любом другом статически типизированном языке, который вы выберете. «Постепенная» означает, что некоторые части вашей кодовой базы могут быть статически типизированными, в то время как другие её части могут всё ещё находится в беспорядочном, динамическом PHP. Возможность совмещать эти подходы позволяет постепенно мигрировать большие кодовые базы.
Вместо того чтобы разлить здесь тонны чернил в описании системы типов Hack и того, как она работает, просто поиграйтесь с ним. Я буду здесь, когда вы вернётесь.
Это аккуратная система, и она весьма амбициозна в том что она позволяет вам выразить. И наличие возможности постепенной миграции проекта на Hack, в случаях когда он разрастается сильнее, чем вы ожидали изначально, является уникальным преимуществом экосистемы PHP. Проверки типов Hack сохраняют рабочий процесс в стиле «думать, отредактировать, перезагрузить страницу», потому что они запускаются в фоне, постепенно обновляя модель кодовой базы, когда он видит модификации в файловой системе. Проект Hack предоставляет интеграции со всеми популярными редакторами и IDE, так что вы сможете увидеть обратную связь об ошибках типов уже тогда, когда завершите печатать код, также как в веб-демонстрации.
Давайте рассмотрим совокупность реальных рисков, которые создаёт PHP, в свете Hack:
- Сюрпризы при преобразованиях становятся ошибками в Hack файлах. Весь класс данных проблем уходит прочь.
- Семантика ссылок и значений в Hack очищена простым запретом использования ссылок старого стиля, так что они больше не нужны в новой кодовой базе. Это делает поведение семантики аналогичной стилю объектов-по-ссылке-и-всего-остального-по-значению, также как в Java или C#
- PHP-шные вычисления, игнорирующие отказы являются больше свойством среды выполнения, и их сложнее обрабатывать анализатором семантики вроде Hack, чтобы внедрить его прямо в эти системы. Тем не менее, на практике, большинство форм вычислений, игнорирующих отказы, требуют тех самых сюрпризов при преобразованиях. К примеру, проблемы, которые возникают из-за получения false после деления на ноль, в итоге не возникнут на пересечении границы проверки типа [4], которая провалится из-за попытки преобразовать булево в число. Эти границы встречаются чаще в кодовой базе Hack. Вместе с простой возможностью описывать данные типы, Hack на практике уменьшает «тормозной путь» для множества некорректных запусков.
- В завершении, противоречия в стандартной библиотеке остаются. Большинство в Hack надеются на то, что смогут сделать эту проблему менее болезненной через оборачивание её в более безопасные абстракции.
Hack предоставляет возможность, которой не имеют другие популярные члены семьи MPDPL: возможность ввести систему типов уже после основной разработки, и только частично, в тех частях системы, где значение перевешивает цену.
HHVM
Hack изначально был разработан как часть виртуальной машины HipHop, или HHVM, виртуальной среды с открытым исходным кодом для PHP. HHVM предоставляет другую важную опцию для успешного проекта: возможность запустить ваш сайт быстрее и более экономно. Facebook докладывает о приросте производительности в 11.6 раз на процессорной эффективности над интерпретатором PHP, а Wikipedia сообщает об ускорении в 6 раз.
Slack недавно перевёл свои веб-окружения на HHVM и получил значительные снижения задержек на всех точках выхода, но нам не хватает измерений в стиле apples-to-apples на процессорные нагрузки на момент написания этого текста. Мы также находимся в процессе перемещения нашей кодовой базы на Hack и будем сообщать о своём опыте здесь.
Смотря вперёд
Мы начали с очевидного парадокса о том, что PHP является очень плохим языком, который используется во многих успешных проектах. Мы считаем, что его репутация как бедного языка, в изоляции, довольно заслуженна. Успех проектов, использующих его, имеет много общего с основными свойствами среды PHP, и возможностью ускоренной разработки, которая также предоставляет PHP. И преимущества от этого окружения (сниженное количество багов через изоляцию ошибок; безопасная параллельность; высокая пропускная способность программистов) являются более ценными, чем проблемы, которые возникают из-за недостатков языка.
Кроме того, в отличии от других членов семьи MPDPL, он предоставляет чёткий путь для миграции на более производительную, безопасную и обслуживаемую среду в виде Hack и HHVM. Slack находится на последних стадиях к переходу на HHVM, и на ранних этапах перехода на Hack, и мы оптимистично настроены, так как они позволяют нам производить более качественное программное обеспечение в более быстрые сроки.
Примечания (они тоже из блога разработчика):
[1] Это я придумал термин MPDPL. В то время как существует мало генетических связей между ними, данные языки сильно повлияли друг на друга. Глядя на прошлый синтаксис, можно увидеть, что они имеют намного больше общего, чем отличий. Во вселенной языков программирования ассамблеи MIPS, Haskell, C++, Forth и Erlang, трудно отрицать, что MPDPL образуют плотный кластер в пространстве языковых дизайнов. [назад к тексту]
[2] К сожалению, & обозначается в получаемом, а не в вызывающем значении. Так что когда программист объявляет о своём желании получить параметры по ссылке, это не отображается никаким образом. Это делает сложный для понимания код и анализ того, что может измениться, и значительно затрудняет эффективную работу с PHP. Смотрите Рисунок 2 в dl.acm.org/citation.cfm?id=2660199. [назад к тексту]
[3] Да, Hack является практически негуглёжным названием для языка программирования. Иногда используется Hacklang, когда возможна неоднозначность. Если уж Google сами могут назвать свой популярный язык ещё более негуглёжным Go, то почему бы и нет? [назад к тексту]
[4] Эти проверки типов в программе на Hack также применяются во время выполнения по умолчанию, так как они работают на основе PHP-шной системы подсказок типов. Это увеличивает безопасность смешанных кодовых баз, где Hack и классический PHP смешиваются друг с другом. [назад к тексту]
Комментарии (82)
renskiy
12.11.2016 09:25-24Лично я, выбирая между PHP и чем-то другим, выбрал бы что-то другое, просто потому, что PHP нигде не работает одинаково (только если у вас не дефолтный php.ini, но такого практически не бывает) — и именно этот факт является самым большим источником ошибок и прочих проблем.
Но PHP все же лучше других скриптовых языков подходит для разработки больших долго-живущих проектов, благодаря своей выразительности и достаточно простой структуре кода (хотя, Python для этого подходит гораздо больше).
franzose
12.11.2016 11:49+7PHP нигде не работает одинаково
Не могли бы вы раскрыть этот момент подробнее?
homm
12.11.2016 15:25Поведение очень многих стандартных функций зависит от глобальных настроек в php.ini. И даже используемый синтаксис зависит от них. Нет возможности поменять эти настройки для своего кода, не ломая весь остальной код в проекте.
saggid
12.11.2016 15:38+5В целом, это не является проблемой на самом деле. Это больше надувание слона из мухи. Уже давно в пхп используется менеджер пакетов, который совмещает в одном проекте сотни библиотек, и всё ведь работает. Да и вообще, сколько лет я уже использую пыху — честно, еще ни разу не возникло подобной проблемы. Такое ощущение, что вы просто взяли подобные доводы из какой-то старой статьи про недостатки пхп, сами при этом не особо зная о реальном положении дел.
В общем, всё нормально на самом деле в этом плане в пхп. Это вообще не проблема, то что описывается проблемой — высосано из пальца и раздуто до слона.
izac
12.11.2016 17:26+2В дополнения к комментарию выше хочу сказать что многие настройки давно можно менять в самом php файле для 1 файла во время исполнения скрипта (ini_set), что мешает это сделать в проекте, если в этом есть крайняя необходимость?
homm
12.11.2016 17:49-4Насколько я знаю, ini_set не меняет их для одного файла, а меняет глобально.
izac
12.11.2016 20:31-1Выдержка из документации:
«Устанавливает значение заданной настройки конфигурации. Настройка будет хранить установленное значение пока выполняется скрипт. После завершения работы скрипта значение настройки вернется к исходному.»
http://php.net/manual/ru/function.ini-set.php
batyrmastyr
13.11.2016 15:05Зависит, но этот хлам начали вычищать и сводить несколько идентичных по сути настроек к одной.
polifill
12.11.2016 13:09-4Вы не управляете своим собственным php.ini?
Такое бывает только на shared-хостинге, что при цене современных VPS/VDS — просто смешное ограничение (а очень хороший качественный shared даже дороже VPS/VDS — просто потому что там одна и та же базовая технология, но для shared админы хостера трудятся чуть больше).
Для более сложных систем есть Docker с его изоляцией и возможностью иметь свой индивидуальный файл php.ini для каждого куска вашей системы.guai
12.11.2016 14:36+5воу-воу! Испокон веков аргументом пыхарей было, что он везде есть, даже на самый отстойных хостингах, на что им обычно возражали, что VPS/VDS давно уже не стоит бешеных бабок.
А теперь внезапно VPS/VDS — аргумент в пользу пыха?franzose
13.11.2016 04:59Ну, не в защиту предыдущего оратора будет сказано, но, тем не менее, возможность редактировать php.ini на некоторых shared-хостингах все-таки имеется. Например, у Ру-Центра.
hlogeon
14.11.2016 19:09+2А, то есть Slack выбрали PHP по вашему мнению именно из-за возможности установить на shared-хостинге? Пользую пыху > 5 лет, ни разу не пользовался shared-хостингом. Я пыхарь, как вы выражаетесь и моим аргументом НИКОГДА небыло «возможность запуска на shared». VPS\VDS — не аргумент в пользу пыха. Не аргумент в пользу чего бы то ни было вообще. А php.ini несложно расценивать, как environment variables которые есть почти в любом веб-проекте на любой технологии.
homm
12.11.2016 14:40+7Вы не управляете своим собственным php.ini?
Очень странный вопрос. Нет, когда я пишу бибилотеку, я не управляю php.ini окружения, где будет выполняться код. Я не знаю, какое будет значение у
arg_separator.output,short_open_tag,allow_url_fopenи еще тысячи настроек, которые влияют на выполнение кода.
Но конечно, если весь код проекта пишет строго один человек под одно окружение, это не проблема. Но статья вроде о PHP всерьёз.
polifill
12.11.2016 15:12+1Вы либо описываете этот нюанс в документации к своему ПО в разделе «Требования».
Либо пишете так, чтобы работа вашего кода не зависела от этих настроек.
Во всем мире с этим как-то борятся, а в PHP — это принципиально невозможно, что ли?
Или вы думаете, что в мире вне PHP не существует настроек системы, не зависящих от разработчика ПО?homm
12.11.2016 15:21Вы либо описываете этот нюанс в документации к своему ПО
Ну вот автор одной бибилотеки написал одни значения, а автор другой — другие. А свой код я писал в расчете на третьи. И что делать?
Во всем мире с этим как-то борятся
Во всем мире, если есть какие-то настройки, они существуют на уровне модуля. Их можно поменять под себя, не ломая весь остальной код, запускаемый в этом же компиляторе или интерпретаторе.
polifill
12.11.2016 15:41-4Вы мало знаете о мире.
Или просто настроены пессимистично — у всех все хорошо, а у одного меня все плохо.
Это не так.
Stalker_RED
12.11.2016 15:48+5В соседнем посте рассказывают, что C тоже может зависеть от окружения. Что делать-то теперь, как с этим жить?
Вы на практике встречали хоть раз нестандартное значениеarg_separator.output?
И мне вот сходу сложно представить, каким образом кусок лапши, зависящий отshort_open_tagполучил звание «библиотеки». Мы ведь сейчас не в 1998 году находимся, и даже не в 2006.homm
14.11.2016 14:55В соседнем посте рассказывают, что C тоже может зависеть от окружения. Что делать-то теперь, как с этим жить?
И это на самом деле большая проблема. Я смотрю в сторону Раста и надеюсь. Правда, к сожалению, те задачи которые я решаю с помощью C, пока что не решаются с помощью Раста.
edogs
12.11.2016 17:47Ну вот автор одной бибилотеки написал одни значения, а автор другой — другие. А свой код я писал в расчете на третьи. И что делать?
Дело в том, что «разные настройки» это скорее не разные возможности, а экивоки в пользу кода со странностями.
Для яркого примера можно взять те же регистр-глобалс, которые можно было в настройках включать, а можно было выключать.
Если код написан правильно и современен — разные настройки проблему не создают. Если же код написан неправильно или несовременен — это проблема кода. Используйте современные либы, пишите современный код не используя спорных решений и все будет ок:)
hlogeon
14.11.2016 19:11Это общая проблема веб-разработки, никак не относящаяся к PHP. И даже к веб-разработке. x64 x86 — слышали?
vshemarov
12.11.2016 16:01+9Хотеть менять arg_separator.output — это в наше время, как минимум, странное желание. Если какой-то уником на своем хосте играет с этим параметром — он сам себе злобный Буратино.
На short_open_tag уже много лет никто внимания не обращает, стандартом де-факто давно стало использование полной формы записи, а для вывода начиная с версии 5.4 всегда доступно <?=.
allow_url_fopen — это, вообще-то, директива безопасности, и это вполне нормально, когда параметры безопасности задает владелец хоста, а не писатель библиотеки.
В общем, сдается мне, насчет «тысячи настроек, которые влияют на выполнение кода» вы слегка перегнули, и при внимательном рассмотрении этих настроек, которые стоит учитывать в коде, останется вряд ли больше десятка, да и те, как правило, связаны с безопасностью, что вполне разумно.
yAnTar_yAnTar
12.11.2016 13:20-3Юзайте Vagrant и будет у вас один енвайронмент и будет РНР работать всюду одинаково
akzhan
12.11.2016 23:37-10Как только мы уходим от shared hosting, необходимость в PHP отпадает в принципе.
Сразу появляется простор для RoR, Django, Go etc.
Psih
13.11.2016 00:38+4До первой необходимости начать расширяться — да, всё очень даже не плохо. А потом начинается как в том комиксе про белок-истеричек:
«А-а-а-а-а-а! У нас пол проекта зависит от сохранения состояния!»
«А-а-а-а-а-а! У нас слишком много данных бегает между приложением и memcache/redis/whatever для сохранения стейта, у нас гигабитный линк ложится!»
И так далее.
Слишком многие расслабляются и имеют потом огромные проблемы с разработкой и поддержкой. Кто-то справляется, кто-то нет. Тех, кто знают на что идут и планируют правильно на самом деле довольно мало — в основном те, кто уже опытные и скорее всего они провели значительное время в выбранной технологии, а не 2-3 года. Настоящие профи в любом языке и технологии это те, кто активно и серьёзно работали хотя-бы 5-7 лет.
Да и со временем значительное кол-во человек всё равно возвращаются к PHP, потому что работы на RoR, Python и Go не настолько много — на всех не хватает.
У меня есть щас клиент, которому девелоперы сделали магазин на Django & QShop — сейчас всё переносим на платформу на Symfony, потому что за относительно простые вещи начали выкатывать такие ценники, что ппц — клиентам оказалось дешевле заплатить нам за полный перенос магазина на новую платформу и заниматься её развитием, чем пытаться заниматься модификацией Django Qshop для добавления весьма тривиальных вещей.
hlogeon
14.11.2016 19:14+3Ну с учетом того, что PHP7(Symfony 2\Laravel\Zend2 и т.д) производительнее вашего RoR и Django, а цена среднего PHP-девелопера ниже специалиста того же уровня на RoR, Django, я уж не говорю о Go, то выбор НЕ в пользу PHP в данной ситуации кажется как раз намного более странным.
youlose
12.11.2016 11:19-4«Я утверждаю, что разработка на PHP в стиле «подумать, отредактировать и перезагрузить страницу» делает разработчиков более продуктивными. В долгих и сложных циклах разработки проектов это даёт ещё больший прирост.»
Вот тут вы очень сильно ошибаетесь, ибо перезагрузить страницу, где куча состояния и взаимодействия, чтобы добраться до какой-то минифичи — это неземная боль.
greabock
12.11.2016 11:26Это же перевод…
youlose
12.11.2016 11:36+2Ну автор оригинальной статьи, заблуждается (или нарочно вводит в заблуждение).
saggid
12.11.2016 13:27-1Я что-то неправильно перевел?) Предложи свою версию перевода этого предложения, Грибок: I claim that PHP’s simpler “think; edit; reload the page” cycle makes developers more productive. Over the course of a long and complex software project’s life cycle, these productivity gains compound.
youlose
12.11.2016 14:17Да нет, тут не к качеству перевода претензия, а я со смыслом несогласен, о чём и написал. А на то что это перевод я сначала не обратил внимания почему-то.
homm
12.11.2016 14:42+3А что это меняет? Типа: чувак же на английском написал, он не может ошибаться?
dim_s
12.11.2016 12:15+3Это не так, на самом деле во многих других языках очень популярны инструменты имитирующие такую логику, тот же JRebel и Java, а в Spring Framework (Java) вообще практически из коробки идут инструменты позволяющие на лету при изменении исходников либо рестартить сервер, либо релоадить загруженные классы.
P.S. А если взять популярную нынче тему с микросервисами, то микросервис обычно простое веб-приложение, которое не хранит кучу состояний, да и вообще, состояние это противоестественно для REST!
boldyrev_gene
12.11.2016 13:25+1В PHP нет необходимости ничего рестартить или релоадить, т.к. каждый запрос на сервер практически с нуля поднимает PHP процесс, который завершается после отправки ответа клиенту…
caballero
12.11.2016 14:43-7не используйте MVC паттерн и никакой боли не будет. Я например использую свой собственный (а что было делать) компонентный фреймворк, где состояние страницы сохраняется между вызовами (ну типа как в ASP WebForms только механизм другой) и никакой нечеловеческой боли не испытываю.
shushu
12.11.2016 12:33+7но 0123 == '0123foo' является ложью (хмм).
0 указывает на восьмиричную систему счисления. Так что здесь как раз все ок.BasilioCat
13.11.2016 11:17Вопрос, видимо, в том, почему '0123' приводится из строки согласно десятичной системе счисления, а не восьмеричной.
batyrmastyr
13.11.2016 15:13+2В php 7.1 выражения будут давать предупреждения о глупости авторов таких сравнений: http://php.net/manual/en/migration71.other-changes.php
beTrue
12.11.2016 13:18+3Спасибо за хороший перевод интересной статьи.
по сабжу, да, парни сделали с php казалось бы невозможное, они такие модники)
или же у них не было иного выбора для накопившегося легаси;)
ideological
12.11.2016 13:29+4PHP отличный язык программирования, который идеально подходит для большинства сайтов.
Те кто утверждает обратное, просто застряли в 2000м или в своих причудах «нормальных языков».
heilage
12.11.2016 13:42+8php — замечательный язык, который позволяет быстро и малыми силами добиваться поставленных целей в одной достаточно четко очерченной области. Со своими минусами — куда без них. Но минусы в большинстве своем простые, явные и их довольно легко обойти, не впадая в борьбу с языком (как это бывает во многих популярных языках, ага). Так что совершенно непонятны нападки на него со всех сторон в течение последних лет. Складывается впечатление, что вместо того, чтобы выбрать правильный инструмент и делать дело, людям интереснее изливать свои печали в бложиках :(
olegl84
12.11.2016 13:58-3Мне кажется, что большенство недовольных как раз новички. Они хотят учить новые технологии, ведь кому понравиться догонять. Конкурировать со старыми разработчиками с 10 лет опыта на PHP не получиться, а вот выучив NodeJs можно сразу получать норм зарплату при опыте 1-2 года и считатся спецом. Поэтому и испытывают негатив к пхп, не совсем понимая причин. Как доказательство, скажем постоянно слышу что Python более объектно ориентрованый, но на самом деле поддержка ООП в PHP Существенно шире. Просто новички видимо думают что ООП, это когда вызываешь метод через точку. А в PHP действительно скаляры не объекты и множество функций со старых времен.
polifill
12.11.2016 15:07+5Бредятина.
Уровень вашей зарплаты зависит не от инструмента, а от квалификации.
И от понимания куда с вашей квалификацией вы можете податься.
С PHP ситуация следующая:
Есть много работы, но и есть много дешевой рабочей силы.
Это позволяет легко начать работать.
С Node ситуация такая:
Работы намного меньше, её еще надо поискать, но и рабочей силы меньше.
Поэтом средняя планка зарплаты — выше. Но найти работу сложнее.
Если вы стали профи PHP, то не совершайте ошибку — не конкурируйте с индусами за плошку риса. Не толкайтесь с ними локтями на дешевом рынке.
Идите в сложные системы — и заработок вас приятно поразит.
Psih
13.11.2016 00:46+1Могу поддержать — нужно не сидеть на WordPress и прочих, а вливаться в настоящее программирование, большие проекты и.т.д. — там сейчас PHP себя прекрасно чувствует и серьёзной высоко оплачиваемой работы вполне хватает.
Но и знать нужно гораздо больше, чем хватает для работы с WP даже в запущенных случаях.
Для примера: мне пришлось вычищать 5.0 проект от всех ошибок, варнингов, фаталов и несовместимостей перенося всё на 5.6. Для этого нужно иметь опыт, мозги и знать что менялось от версии к версии, как, почему, и понимать как переписать то, что не поддаётся простому исправлению.
caballero
12.11.2016 14:39+14Приятно что еще остались люди неподдавшиеся яваскриптовому безумию.
p4s8x
12.11.2016 22:01-5Тссс!!! Тихо-Тихо!!!
В PHP 10 лет, годами наблюдал следующий процесс появления нового «php-программиста»:
1) студент, окончил абстрактный не технический вуз — в поисках работы.
2) 0 опыта работы, но в институте преподавали html — устроился работать контенщиком
3) пол года опыта работы: смог вставить countdown скрипт на сайт, заменил логотип в страничке. Все, через месяц уволился и устроился работать верстальщиком
4) прошел год — смог установить по инструкции плагин на <популярная cms на php>, требующий двух правок в php-файлах — все — бежит работать php-программистом.
И вот 2 года назад случилось чудо, очередной такой студент на моих глазах стал не php-программистом, а… внезапно открыл в себе талант backend-разрабочика другой технологии…
P.s. Быть может скоро и 1С-Битрикс перепишут… это же идеально, разрабатывать frontend и backend на одной технологии… можно нанимать меньше разработчиков, ведь явно любому frontend разработчику можно дать задачу backend'щика и наоборот. Эй эффективные менеджеры, где вы?polifill
12.11.2016 22:06На какой «одной технологии»? Фронтенд давно уже не мыслим без JS
Или вы нам из прошлого века пишете?
rumkin
13.11.2016 12:30+1Говорить "одна технология" в адресс node.js нельзя. Все почему-то забывают, что до ноды уже существовал серверный JS, но он не был так популярен. Вся хитрость в libuv, который позволяет творить настоящую магию, и JS тут лишь синтаксический сахар.
sumanai
12.11.2016 14:49Добродетели PHP:
Первая, состояние.
На деле это и плюс и минус. Плюс конечно же в простоте, а минус в оверхеде на постоянное выполнение одних и тех же действий.
Всё хочу написать неумирающее приложение на php с использованием какого-нибудь Amp, да всё руки не доходят.p4s8x
12.11.2016 21:04+2Очень рекомендую это сделать. Возможно в вашем проекте очень много оверхеда идет на иммутабельные объекты(чтение конфигов, ядро фреймворка и т.д.) или если просто пугает асинхронщина — начните с php-pm.
Мы получили огромный прирост производительности сохранив stateless модель для обработки запросов.sumanai
12.11.2016 21:13Не, я думаю о чисто своём маленьком проекте. Мою главную работу на данную модель мне одному не переписать за всю жизнь.
saggid
12.11.2016 21:28+2На тему ускорения есть ещё такая штучка как Kraken PHP Framework:
Kraken is able to emit millions of events and thousands of messages and connections per second using single container. It is scalable for multiple processes and threads, faster than traditional PHP approach and able to handle same or higher amount of connections that Node.js.
p4s8x
12.11.2016 22:13+4Да собственно вот они все: asynchronous-php
В amphp больше всего верю, потому что там ребята из php-internals и самое главное — с ними отлично получается лично контактировать хоть на гитхабе, хоть в твиттере.
crea7or
12.11.2016 19:45+7Бесконечные споры же. Ну вот знаю я языков 7, наверно. Многие присутствующие наверно и больше ещё. Ну нет большой разницы на чём писать (кроме сильно несовместимых с языком вещей, но и то люди умудряются делать). Где-то большое прямо в языке есть, где-то библиотеку какую подключить. Где-то сахарку побольше, где-то поменьше. А тут прям выбор тысячелетия… Пустое это всё.
YemSalat
12.11.2016 20:24Добродетели PHP
Первая, состояние.
Мне кажется это не отличительная особенность ПХП. В других языках есть способы получения такого же эффекта (константы, и т.п)
И то что ПХП стартует новый процесс на каждый запрос — называть «чистым состоянием» (или как там?) не очень верно.
alexhott
12.11.2016 21:25я уже гдето писал откуда берется негатив. Так как работающих проектов на PHP очень много, то прийдя на работу и не зная PHP часто приходится его изучать. Обратная ситуация встречается реже.
MetaDone
12.11.2016 22:48+6Большинство программистов, которые немного игрались с PHP, знают две вещи про него: это плохой язык, который они никогда не станут использовать при наличии выбора
В любом языке можно найти что-то кажущееся странным, например как тут
сам php вполне себе норм, но вот часть тех, кто на нем пишут — это ппц Х_х. Вроде бы на дворе 2016 год, а на работе в проектах от другой команды до сих пор видны ошибки вида «cannot modify header information — headers already sent» или же ошибки выполнения sql-запросов (вообще только за то, что это видит пользователь на странице, нужно отрывать руки с корнями)
Потому мне кажется, что всех кто связан с php можно разделить на 2 лагеря:
староверы — это те, кто работает с 1-2 cms, могут написать под них модуль, при работе с другими системами не могут переключиться на другой подход потому что привыкли, в основном делают сайты-визитки и шаблонные простые интернет-магазины клиентам. Про автоматизированное тестирование не слышали или же считают что проверить вручную будет быстрее. Таких лучше не подпускать к даже немного сложным проектам. Пишут в стиле php4 до сих пор, развитием языка и новыми фишками не интересуются. Код пишется в каком-нибудь notepad++. Деплой — закинуть файлы через фтп и залить дампы новых таблиц через phpmyadmin.
приверженцы современного подхода — эти люди чтят psr, работают с современными фреймворками, знают как работает веб-сервер и могут спокойно сами его настроить оптимально в зависимости от проекта. Вполне себе пишут еще на нескольких языках или хотя бы имеют представление о других подходах. Пишут тесты и знают какие они бывают. Стараются использовать последние фишки языка. Для работы используют IDE (phpstorm, netbeans и т.п.). Деплой чаще всего автоматизирован.
Разделение весьма условное, да и промежуточные варианты тоже существуют, но вот сам язык позволяет использовать оба таких подхода — и старый, потому что куча кода написанная ранее должна продолжать работать, и новый, т.к. язык развивается и новые проекты лучше начинать используя последние возможности. Получается, что к php наверно всегда будут относиться с некоторым пренебрежением и презрением из-за староверов и недоучек, которые после установки вордпресса мнят себя обалденными специалистами, хотя сам язык и экосистема содержат все, чтобы писать понятный, быстрый и поддерживаемый код и эффективно решать задачи.VolCh
13.11.2016 17:06Такое разделение есть во многих активно развивающихся языках. А тесты, CI и прочие современные практики вообще от языка не зависят.
Psih
13.11.2016 00:58-4Ещё 3 года назад в твиттере я очень удачно ответил на твит Anthony Ferrara мыслью, которую поддержало довольно большое кол-во народу
iAchilles
13.11.2016 15:06Десять раз перечитал вот это:
Асинхронный curl'инг на локалхост (или даже другой веб-сервер) предоставляет неразделяемый (shared-nothing), копирование-в/копирование-из подход использования параллелизма.
Интересный способ согласования предложения.saggid
13.11.2016 15:07-1Буду рад, если вы предложите более правильный перевод данной фразы, так как я действительно не очень понимаю, как правильно ее перевести.
zhigalin
14.11.2016 20:35+1Просто отправляя асинхронные запросы сами себе мы легко получаем параллелизм с изолированными состояниями и вызовами по копированию-восстановлению.
— Кстати у переводов должна быть соответствующая плашка.saggid
14.11.2016 21:24Даа, как хорошо вы перевели. Намного более понятно получилось. А что за плашка должна быть соответствующая? Пояснение, что эта статья — перевод? У меня есть только возможность указать, что эта статья является туториалом. Как у других — не знаю)
zhigalin
14.11.2016 21:44Плашка как например тут: https://habrahabr.ru/post/315048/
Как ставить не знаю.
Zebratuk
14.11.2016 16:41Последние года 3 пишу на PHP. Постоянно просматриваю блоги/твиты J.Pauli, nikic и других «папок». В последнее время просматриваю доклады Шипилева и других с jug/jpoint. Всегда жду новенького в хабе php…
Но вот эта «статья» не понятно, какую должна мысль донести. Холивара ради? И так хватает постоянных метаний фекалий из одного стана в другой. Неужели до сих пор люди не понимают, что к любому инструменту нужны «руки». А то потом разгребаешь божественный код адептов ror/django…
Поддался общей истерии и написал комментарий…saggid
14.11.2016 17:11Ну, отчасти да, ради того чтобы еще раз объяснить народу, что пхп решает задачи. До сих пор у массы программистов куча предубеждений и вирусов насчет него, и эта статья как антивирус для них.
Вторая причина — рассказ о Hack, статической типизации в мире пхп.
stokker
14.11.2016 17:26Статья для тех, кто думает, а не просто метает фекалии )) Вторые изменятся, когда станет вопрос о новой работе…
FreeMind2000
15.11.2016 02:12Господа, с php всё понятно — hi is alive.
В статье явно уклон идет больше на Hacklang, и на самом деле, после беглого знакомства — действительно не плох.
Собственно, может кто уже юзает реально в prodaction эту штуку, расскажет где можно захостить и какие подводные камни есть? Насколько я понял с оф.сайта под windows реализации нет?hlogeon
18.11.2016 11:58+1А какой смысл, когда есть PHP7?
sumanai
18.11.2016 13:19У Hack есть опциональная статическая типизация, а у PHP7 только type hinting.
batyrmastyr
20.11.2016 21:38+1Есть declare(strict_types=1); для включения строгой проверки типов.
Да, включать эту проверку в рамках текущего _файла_ тот ещё костыль, не совсем полноценный, но хоть что-то.
VGrabko
Golang хотя-бы звучит.