Принимая PHP всерьёз

    image
    Ракета Союз, доставленная на поезде на пусковую площадку. Фото из общественного достояния 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 потоке. На первый взгляд, это кажется глупым ограничением. Но так как наше приложение выполняется в контексте веб-сервера, мы имеет натуральный источник параллелизма: веб запросы. Просто отправляя асинхронные запросы самим себе, мы легко получаем параллелизм с изолированными состояниями и вызовами по копированию-восстановлению. На практике, это безопаснее и устойчивее к ошибкам, чем подход с блокировками и разделяемым состоянием, который используется в других языках общего назначения.

    В заключении, тот факт, что PHP программы оперируют на уровне запросов, означает, что рабочий процесс программиста является быстрым и эффективным, и остаётся быстрым после изменения приложения. Множество языков продуктивной разработки претендуют на это, но если они не очищают своё состояние при каждом запросе, и основной поток событий разделяет программный уровень состояния между запросами, они почти всегда требуют некоторое время на запуск. Для типичного сервера приложений на Python'е, типичный цикл отладки будет выглядеть примерно как «подумать, отредактировать, перезапустить сервер, отправить несколько тестовых запросов». Даже если «перезапустить сервер» занимает всего несколько секунд из общего количества часов, это забирает большой срез из 15-30 секунд наших человеческих мозгов на необходимость удержания в голове самой ненужной части текущего состояния.

    Я утверждаю, что разработка на PHP в стиле «подумать, отредактировать и перезагрузить страницу» делает разработчиков более продуктивными. В долгих и сложных циклах разработки проектов это даёт ещё больший прирост.

    Доводы против PHP


    Если всё это является правдой, почему же его так ненавидят? Когда вы уберёте все красочные гиперболы в сторону, что основные жалобы о PHP кластере сведутся к следующим проблемам:

    1. Сюрпризы при преобразованиях. Почти все языки в наши дни позволяют сравнить, например, integer и float с оператором >=; Чёрт, даже C позволяет. Совершенно понятно, что здесь имеется ввиду. Менее очевидно сравнение строки и числа с помощью ==, и разные языки делали разный выбор. Выбор PHP в данной ситуации наиболее порочен, что приводит к сюрпризам и неприятным ошибкам. К примеру, 123 == '123foo' оценивается как истина (что он там делает?), но 0123 == '0123foo' является ложью (хмм).

    2. Несогласованность вокруг ссылок и семантических значений. PHP 3 имел чёткую семантику передачи аргументов, возвращения всего по значению, создавая логическую копию данных в запросе. Программист может выбрать ссылочную семантику вместе со знаком & [2]. Это возникло вместе с введением объектно-ориентированных средств программирования в PHP 4 и 5. Большинство PHP ОО-аннотаций были позаимствованы из Java, и Java имеет семантику, в которой объект передаётся по ссылке, в то время как примитивные типы передаются по значению. В итоге, текущее состояние семантики PHP заключается в том, что объекты передаются по ссылке (выбираем Java, вместо, скажем, C++), примитивные типы передаются по значению (здесь Java, C++, и PHP согласен), но старая ссылочная семантика и знак & остались, время от времени взаимодействуя с новым миром неоднозначными способами.

    3. Философия вычислений, игнорирующих отказы. PHP пытается очень, очень трудно сохранять запрос запущенным, даже если он уже наделал чего-то совсем странного. Так, к примеру, деление на ноль не бросает исключения, не возвращает INF, и не завершает фатально запрос. По умолчанию, он просто предупреждает и присвоит значение как false. Так как false молча рассматривается как 0 в числовых контекстах, множество приложений разворачиваются и запускаются с недиагностированными делениями на ноль. Конкретно эта проблема была разрешена в PHP 7, но импульс в дизайне к обработке неоднозначностей, даже когда они могут иметь смысл, пропитывает в том числе и библиотеки.

    4. Противоречия в стандартной библиотеке. Когда 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:

    1. Сюрпризы при преобразованиях становятся ошибками в Hack файлах. Весь класс данных проблем уходит прочь.
    2. Семантика ссылок и значений в Hack очищена простым запретом использования ссылок старого стиля, так что они больше не нужны в новой кодовой базе. Это делает поведение семантики аналогичной стилю объектов-по-ссылке-и-всего-остального-по-значению, также как в Java или C#
    3. PHP-шные вычисления, игнорирующие отказы являются больше свойством среды выполнения, и их сложнее обрабатывать анализатором семантики вроде Hack, чтобы внедрить его прямо в эти системы. Тем не менее, на практике, большинство форм вычислений, игнорирующих отказы, требуют тех самых сюрпризов при преобразованиях. К примеру, проблемы, которые возникают из-за получения false после деления на ноль, в итоге не возникнут на пересечении границы проверки типа [4], которая провалится из-за попытки преобразовать булево в число. Эти границы встречаются чаще в кодовой базе Hack. Вместе с простой возможностью описывать данные типы, Hack на практике уменьшает «тормозной путь» для множества некорректных запусков.
    4. В завершении, противоречия в стандартной библиотеке остаются. Большинство в 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
      –33
      Golang хотя-бы звучит.
        –24
        Лично я, выбирая между PHP и чем-то другим, выбрал бы что-то другое, просто потому, что PHP нигде не работает одинаково (только если у вас не дефолтный php.ini, но такого практически не бывает) — и именно этот факт является самым большим источником ошибок и прочих проблем.

        Но PHP все же лучше других скриптовых языков подходит для разработки больших долго-живущих проектов, благодаря своей выразительности и достаточно простой структуре кода (хотя, Python для этого подходит гораздо больше).
          +7
          PHP нигде не работает одинаково

          Не могли бы вы раскрыть этот момент подробнее?

            0

            Поведение очень многих стандартных функций зависит от глобальных настроек в php.ini. И даже используемый синтаксис зависит от них. Нет возможности поменять эти настройки для своего кода, не ломая весь остальной код в проекте.

              +5

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


              В общем, всё нормально на самом деле в этом плане в пхп. Это вообще не проблема, то что описывается проблемой — высосано из пальца и раздуто до слона.

                +2
                В дополнения к комментарию выше хочу сказать что многие настройки давно можно менять в самом php файле для 1 файла во время исполнения скрипта (ini_set), что мешает это сделать в проекте, если в этом есть крайняя необходимость?
                  –4

                  Насколько я знаю, ini_set не меняет их для одного файла, а меняет глобально.

                    –1
                    Выдержка из документации:
                    «Устанавливает значение заданной настройки конфигурации. Настройка будет хранить установленное значение пока выполняется скрипт. После завершения работы скрипта значение настройки вернется к исходному.»

                    http://php.net/manual/ru/function.ini-set.php
                      0
                      Вот только скрипт # текущему файлу.
                      –2

                      Было бы интересно услышать возражения. izac даже привёл пример из документации, подтверждающий мои слова:


                      Настройка будет хранить установленное значение пока выполняется скрипт.

                      Или большинство не знает, что значит слово «глобально»?

                    0
                    Зависит, но этот хлам начали вычищать и сводить несколько идентичных по сути настроек к одной.
                  –4
                  Вы не управляете своим собственным php.ini?
                  Такое бывает только на shared-хостинге, что при цене современных VPS/VDS — просто смешное ограничение (а очень хороший качественный shared даже дороже VPS/VDS — просто потому что там одна и та же базовая технология, но для shared админы хостера трудятся чуть больше).
                  Для более сложных систем есть Docker с его изоляцией и возможностью иметь свой индивидуальный файл php.ini для каждого куска вашей системы.
                    +5
                    воу-воу! Испокон веков аргументом пыхарей было, что он везде есть, даже на самый отстойных хостингах, на что им обычно возражали, что VPS/VDS давно уже не стоит бешеных бабок.
                    А теперь внезапно VPS/VDS — аргумент в пользу пыха?
                      0

                      Ну, не в защиту предыдущего оратора будет сказано, но, тем не менее, возможность редактировать php.ini на некоторых shared-хостингах все-таки имеется. Например, у Ру-Центра.

                        +2
                        А, то есть Slack выбрали PHP по вашему мнению именно из-за возможности установить на shared-хостинге? Пользую пыху > 5 лет, ни разу не пользовался shared-хостингом. Я пыхарь, как вы выражаетесь и моим аргументом НИКОГДА небыло «возможность запуска на shared». VPS\VDS — не аргумент в пользу пыха. Не аргумент в пользу чего бы то ни было вообще. А php.ini несложно расценивать, как environment variables которые есть почти в любом веб-проекте на любой технологии.
                        +7
                        Вы не управляете своим собственным php.ini?

                        Очень странный вопрос. Нет, когда я пишу бибилотеку, я не управляю php.ini окружения, где будет выполняться код. Я не знаю, какое будет значение у arg_separator.output, short_open_tag, allow_url_fopen и еще тысячи настроек, которые влияют на выполнение кода.


                        Но конечно, если весь код проекта пишет строго один человек под одно окружение, это не проблема. Но статья вроде о PHP всерьёз.

                          +1
                          Вы либо описываете этот нюанс в документации к своему ПО в разделе «Требования».
                          Либо пишете так, чтобы работа вашего кода не зависела от этих настроек.

                          Во всем мире с этим как-то борятся, а в PHP — это принципиально невозможно, что ли?

                          Или вы думаете, что в мире вне PHP не существует настроек системы, не зависящих от разработчика ПО?
                            0
                            Вы либо описываете этот нюанс в документации к своему ПО

                            Ну вот автор одной бибилотеки написал одни значения, а автор другой — другие. А свой код я писал в расчете на третьи. И что делать?


                            Во всем мире с этим как-то борятся

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

                              –4
                              Вы мало знаете о мире.

                              Или просто настроены пессимистично — у всех все хорошо, а у одного меня все плохо.

                              Это не так.
                                +5
                                В соседнем посте рассказывают, что C тоже может зависеть от окружения. Что делать-то теперь, как с этим жить?

                                Вы на практике встречали хоть раз нестандартное значение arg_separator.output?
                                И мне вот сходу сложно представить, каким образом кусок лапши, зависящий от short_open_tag получил звание «библиотеки». Мы ведь сейчас не в 1998 году находимся, и даже не в 2006.
                                  0
                                  В соседнем посте рассказывают, что C тоже может зависеть от окружения. Что делать-то теперь, как с этим жить?

                                  И это на самом деле большая проблема. Я смотрю в сторону Раста и надеюсь. Правда, к сожалению, те задачи которые я решаю с помощью C, пока что не решаются с помощью Раста.

                                  0
                                  Ну вот автор одной бибилотеки написал одни значения, а автор другой — другие. А свой код я писал в расчете на третьи. И что делать?
                                  Дело в том, что «разные настройки» это скорее не разные возможности, а экивоки в пользу кода со странностями.
                                  Для яркого примера можно взять те же регистр-глобалс, которые можно было в настройках включать, а можно было выключать.
                                  Если код написан правильно и современен — разные настройки проблему не создают. Если же код написан неправильно или несовременен — это проблема кода. Используйте современные либы, пишите современный код не используя спорных решений и все будет ок:)
                                    0
                                    Это общая проблема веб-разработки, никак не относящаяся к PHP. И даже к веб-разработке. x64 x86 — слышали?
                                  +9
                                  Хотеть менять arg_separator.output — это в наше время, как минимум, странное желание. Если какой-то уником на своем хосте играет с этим параметром — он сам себе злобный Буратино.

                                  На short_open_tag уже много лет никто внимания не обращает, стандартом де-факто давно стало использование полной формы записи, а для вывода начиная с версии 5.4 всегда доступно <?=.

                                  allow_url_fopen — это, вообще-то, директива безопасности, и это вполне нормально, когда параметры безопасности задает владелец хоста, а не писатель библиотеки.

                                  В общем, сдается мне, насчет «тысячи настроек, которые влияют на выполнение кода» вы слегка перегнули, и при внимательном рассмотрении этих настроек, которые стоит учитывать в коде, останется вряд ли больше десятка, да и те, как правило, связаны с безопасностью, что вполне разумно.
                                    –1
                                    Ссылки на библиотеки, пожалуйста.
                                  –3
                                  Юзайте Vagrant и будет у вас один енвайронмент и будет РНР работать всюду одинаково
                                    –10

                                    Как только мы уходим от shared hosting, необходимость в PHP отпадает в принципе.


                                    Сразу появляется простор для RoR, Django, Go etc.

                                      +4
                                      До первой необходимости начать расширяться — да, всё очень даже не плохо. А потом начинается как в том комиксе про белок-истеричек:
                                      «А-а-а-а-а-а! У нас пол проекта зависит от сохранения состояния!»
                                      «А-а-а-а-а-а! У нас слишком много данных бегает между приложением и memcache/redis/whatever для сохранения стейта, у нас гигабитный линк ложится!»
                                      И так далее.

                                      Слишком многие расслабляются и имеют потом огромные проблемы с разработкой и поддержкой. Кто-то справляется, кто-то нет. Тех, кто знают на что идут и планируют правильно на самом деле довольно мало — в основном те, кто уже опытные и скорее всего они провели значительное время в выбранной технологии, а не 2-3 года. Настоящие профи в любом языке и технологии это те, кто активно и серьёзно работали хотя-бы 5-7 лет.
                                      Да и со временем значительное кол-во человек всё равно возвращаются к PHP, потому что работы на RoR, Python и Go не настолько много — на всех не хватает.

                                      У меня есть щас клиент, которому девелоперы сделали магазин на Django & QShop — сейчас всё переносим на платформу на Symfony, потому что за относительно простые вещи начали выкатывать такие ценники, что ппц — клиентам оказалось дешевле заплатить нам за полный перенос магазина на новую платформу и заниматься её развитием, чем пытаться заниматься модификацией Django Qshop для добавления весьма тривиальных вещей.
                                        +3
                                        Ну с учетом того, что PHP7(Symfony 2\Laravel\Zend2 и т.д) производительнее вашего RoR и Django, а цена среднего PHP-девелопера ниже специалиста того же уровня на RoR, Django, я уж не говорю о Go, то выбор НЕ в пользу PHP в данной ситуации кажется как раз намного более странным.
                                    –4
                                    «Я утверждаю, что разработка на PHP в стиле «подумать, отредактировать и перезагрузить страницу» делает разработчиков более продуктивными. В долгих и сложных циклах разработки проектов это даёт ещё больший прирост.»

                                    Вот тут вы очень сильно ошибаетесь, ибо перезагрузить страницу, где куча состояния и взаимодействия, чтобы добраться до какой-то минифичи — это неземная боль.
                                      0
                                      Это же перевод…
                                        +2
                                        Ну автор оригинальной статьи, заблуждается (или нарочно вводит в заблуждение).
                                          –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.

                                            0
                                            Да нет, тут не к качеству перевода претензия, а я со смыслом несогласен, о чём и написал. А на то что это перевод я сначала не обратил внимания почему-то.
                                            +3

                                            А что это меняет? Типа: чувак же на английском написал, он не может ошибаться?

                                            +3
                                            Это не так, на самом деле во многих других языках очень популярны инструменты имитирующие такую логику, тот же JRebel и Java, а в Spring Framework (Java) вообще практически из коробки идут инструменты позволяющие на лету при изменении исходников либо рестартить сервер, либо релоадить загруженные классы.

                                            P.S. А если взять популярную нынче тему с микросервисами, то микросервис обычно простое веб-приложение, которое не хранит кучу состояний, да и вообще, состояние это противоестественно для REST!
                                              +1
                                              В PHP нет необходимости ничего рестартить или релоадить, т.к. каждый запрос на сервер практически с нуля поднимает PHP процесс, который завершается после отправки ответа клиенту…
                                              –7
                                              не используйте MVC паттерн и никакой боли не будет. Я например использую свой собственный (а что было делать) компонентный фреймворк, где состояние страницы сохраняется между вызовами (ну типа как в ASP WebForms только механизм другой) и никакой нечеловеческой боли не испытываю.
                                                +3
                                                MVC тут непричём
                                              +7
                                              но 0123 == '0123foo' является ложью (хмм).


                                              0 указывает на восьмиричную систему счисления. Так что здесь как раз все ок.
                                                0
                                                Вопрос, видимо, в том, почему '0123' приводится из строки согласно десятичной системе счисления, а не восьмеричной.
                                                  +2
                                                  В php 7.1 выражения будут давать предупреждения о глупости авторов таких сравнений: http://php.net/manual/en/migration71.other-changes.php
                                                  +3
                                                  Спасибо за хороший перевод интересной статьи.
                                                  по сабжу, да, парни сделали с php казалось бы невозможное, они такие модники)
                                                  или же у них не было иного выбора для накопившегося легаси;)
                                                    +4
                                                    PHP отличный язык программирования, который идеально подходит для большинства сайтов.
                                                    Те кто утверждает обратное, просто застряли в 2000м или в своих причудах «нормальных языков».
                                                      +7
                                                      Те, кто утверждают обратное, нашли себе отличные языки еще тогда в 2000м :)
                                                      +8
                                                      php — замечательный язык, который позволяет быстро и малыми силами добиваться поставленных целей в одной достаточно четко очерченной области. Со своими минусами — куда без них. Но минусы в большинстве своем простые, явные и их довольно легко обойти, не впадая в борьбу с языком (как это бывает во многих популярных языках, ага). Так что совершенно непонятны нападки на него со всех сторон в течение последних лет. Складывается впечатление, что вместо того, чтобы выбрать правильный инструмент и делать дело, людям интереснее изливать свои печали в бложиках :(
                                                        –3
                                                        Мне кажется, что большенство недовольных как раз новички. Они хотят учить новые технологии, ведь кому понравиться догонять. Конкурировать со старыми разработчиками с 10 лет опыта на PHP не получиться, а вот выучив NodeJs можно сразу получать норм зарплату при опыте 1-2 года и считатся спецом. Поэтому и испытывают негатив к пхп, не совсем понимая причин. Как доказательство, скажем постоянно слышу что Python более объектно ориентрованый, но на самом деле поддержка ООП в PHP Существенно шире. Просто новички видимо думают что ООП, это когда вызываешь метод через точку. А в PHP действительно скаляры не объекты и множество функций со старых времен.
                                                          +5
                                                          Бредятина.

                                                          Уровень вашей зарплаты зависит не от инструмента, а от квалификации.
                                                          И от понимания куда с вашей квалификацией вы можете податься.

                                                          С PHP ситуация следующая:
                                                          Есть много работы, но и есть много дешевой рабочей силы.

                                                          Это позволяет легко начать работать.

                                                          С Node ситуация такая:

                                                          Работы намного меньше, её еще надо поискать, но и рабочей силы меньше.

                                                          Поэтом средняя планка зарплаты — выше. Но найти работу сложнее.

                                                          Если вы стали профи PHP, то не совершайте ошибку — не конкурируйте с индусами за плошку риса. Не толкайтесь с ними локтями на дешевом рынке.

                                                          Идите в сложные системы — и заработок вас приятно поразит.

                                                            +1
                                                            Могу поддержать — нужно не сидеть на WordPress и прочих, а вливаться в настоящее программирование, большие проекты и.т.д. — там сейчас PHP себя прекрасно чувствует и серьёзной высоко оплачиваемой работы вполне хватает.
                                                            Но и знать нужно гораздо больше, чем хватает для работы с WP даже в запущенных случаях.
                                                            Для примера: мне пришлось вычищать 5.0 проект от всех ошибок, варнингов, фаталов и несовместимостей перенося всё на 5.6. Для этого нужно иметь опыт, мозги и знать что менялось от версии к версии, как, почему, и понимать как переписать то, что не поддаётся простому исправлению.
                                                          +3
                                                          людям интереснее изливать свои печали в бложиках

                                                          … написанных на PHP, кстати

                                                          +14
                                                          Приятно что еще остались люди неподдавшиеся яваскриптовому безумию.
                                                            –5

                                                            А я прочел и подумал, как хорошо, что это пэхэпэшное безумие позади.

                                                              –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'щика и наоборот. Эй эффективные менеджеры, где вы?
                                                                0
                                                                На какой «одной технологии»? Фронтенд давно уже не мыслим без JS
                                                                Или вы нам из прошлого века пишете?
                                                                  +1

                                                                  Говорить "одна технология" в адресс node.js нельзя. Все почему-то забывают, что до ноды уже существовал серверный JS, но он не был так популярен. Вся хитрость в libuv, который позволяет творить настоящую магию, и JS тут лишь синтаксический сахар.

                                                                0
                                                                Добродетели PHP:
                                                                Первая, состояние.

                                                                На деле это и плюс и минус. Плюс конечно же в простоте, а минус в оверхеде на постоянное выполнение одних и тех же действий.
                                                                Всё хочу написать неумирающее приложение на php с использованием какого-нибудь Amp, да всё руки не доходят.
                                                                  +2
                                                                  Очень рекомендую это сделать. Возможно в вашем проекте очень много оверхеда идет на иммутабельные объекты(чтение конфигов, ядро фреймворка и т.д.) или если просто пугает асинхронщина — начните с php-pm.
                                                                  Мы получили огромный прирост производительности сохранив stateless модель для обработки запросов.
                                                                    0
                                                                    Не, я думаю о чисто своём маленьком проекте. Мою главную работу на данную модель мне одному не переписать за всю жизнь.
                                                                      +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.

                                                                        +4
                                                                        Да собственно вот они все: asynchronous-php
                                                                        В amphp больше всего верю, потому что там ребята из php-internals и самое главное — с ними отлично получается лично контактировать хоть на гитхабе, хоть в твиттере.
                                                                    +7
                                                                    Бесконечные споры же. Ну вот знаю я языков 7, наверно. Многие присутствующие наверно и больше ещё. Ну нет большой разницы на чём писать (кроме сильно несовместимых с языком вещей, но и то люди умудряются делать). Где-то большое прямо в языке есть, где-то библиотеку какую подключить. Где-то сахарку побольше, где-то поменьше. А тут прям выбор тысячелетия… Пустое это всё.
                                                                      0
                                                                      Добродетели PHP
                                                                      Первая, состояние.

                                                                      Мне кажется это не отличительная особенность ПХП. В других языках есть способы получения такого же эффекта (константы, и т.п)
                                                                      И то что ПХП стартует новый процесс на каждый запрос — называть «чистым состоянием» (или как там?) не очень верно.
                                                                        0
                                                                        я уже гдето писал откуда берется негатив. Так как работающих проектов на PHP очень много, то прийдя на работу и не зная PHP часто приходится его изучать. Обратная ситуация встречается реже.
                                                                          +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 наверно всегда будут относиться с некоторым пренебрежением и презрением из-за староверов и недоучек, которые после установки вордпресса мнят себя обалденными специалистами, хотя сам язык и экосистема содержат все, чтобы писать понятный, быстрый и поддерживаемый код и эффективно решать задачи.
                                                                            0

                                                                            Очень хорошее разделение, реально всё так и есть на деле.

                                                                              0
                                                                              Такое разделение есть во многих активно развивающихся языках. А тесты, CI и прочие современные практики вообще от языка не зависят.
                                                                              0
                                                                              извините, веткой промахнулся
                                                                              –4
                                                                              Ещё 3 года назад в твиттере я очень удачно ответил на твит Anthony Ferrara мыслью, которую поддержало довольно большое кол-во народу

                                                                              С тех пор я только укрепился в своём мнении — очень больщое кол-во разработчиков PHP знают плохо — отбери у них фреймворк или дай им легаси проект в котором нужно разбираться почти с голым PHP — они как новорождённые слепые котята становятся, приходится тыкать моськой в мануал, где прямым текстом написаны очевидные вещи. Т.е. люди мануал если и читали, то вскользь.
                                                                                –1
                                                                                +1.
                                                                                Фреймворки/CMS за программистов жуют толченную картошку :)
                                                                                0
                                                                                Десять раз перечитал вот это:
                                                                                Асинхронный curl'инг на локалхост (или даже другой веб-сервер) предоставляет неразделяемый (shared-nothing), копирование-в/копирование-из подход использования параллелизма.

                                                                                Интересный способ согласования предложения.
                                                                                  –1

                                                                                  Буду рад, если вы предложите более правильный перевод данной фразы, так как я действительно не очень понимаю, как правильно ее перевести.

                                                                                    +1
                                                                                    Просто отправляя асинхронные запросы сами себе мы легко получаем параллелизм с изолированными состояниями и вызовами по копированию-восстановлению.

                                                                                    — Кстати у переводов должна быть соответствующая плашка.
                                                                                      0

                                                                                      Даа, как хорошо вы перевели. Намного более понятно получилось. А что за плашка должна быть соответствующая? Пояснение, что эта статья — перевод? У меня есть только возможность указать, что эта статья является туториалом. Как у других — не знаю)

                                                                                        0
                                                                                        Плашка как например тут: https://habrahabr.ru/post/315048/
                                                                                        Как ставить не знаю.
                                                                                  –15
                                                                                  ПХП — говно язык, что уж тут поделаешь…
                                                                                    0
                                                                                    Последние года 3 пишу на PHP. Постоянно просматриваю блоги/твиты J.Pauli, nikic и других «папок». В последнее время просматриваю доклады Шипилева и других с jug/jpoint. Всегда жду новенького в хабе php…
                                                                                    Но вот эта «статья» не понятно, какую должна мысль донести. Холивара ради? И так хватает постоянных метаний фекалий из одного стана в другой. Неужели до сих пор люди не понимают, что к любому инструменту нужны «руки». А то потом разгребаешь божественный код адептов ror/django…

                                                                                    Поддался общей истерии и написал комментарий…
                                                                                      0

                                                                                      Ну, отчасти да, ради того чтобы еще раз объяснить народу, что пхп решает задачи. До сих пор у массы программистов куча предубеждений и вирусов насчет него, и эта статья как антивирус для них.


                                                                                      Вторая причина — рассказ о Hack, статической типизации в мире пхп.

                                                                                        0
                                                                                        Статья для тех, кто думает, а не просто метает фекалии )) Вторые изменятся, когда станет вопрос о новой работе…
                                                                                        0
                                                                                        Господа, с php всё понятно — hi is alive.
                                                                                        В статье явно уклон идет больше на Hacklang, и на самом деле, после беглого знакомства — действительно не плох.

                                                                                        Собственно, может кто уже юзает реально в prodaction эту штуку, расскажет где можно захостить и какие подводные камни есть? Насколько я понял с оф.сайта под windows реализации нет?
                                                                                          +1
                                                                                          А какой смысл, когда есть PHP7?
                                                                                            0
                                                                                            У Hack есть опциональная статическая типизация, а у PHP7 только type hinting.
                                                                                              +1
                                                                                              Есть declare(strict_types=1); для включения строгой проверки типов.
                                                                                              Да, включать эту проверку в рамках текущего _файла_ тот ещё костыль, не совсем полноценный, но хоть что-то.

                                                                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                        Самое читаемое