Одно из мнений о будущем PHP

Original author: Anthony Ferrara
  • Translation


В последнее время в сообществе разработчиков наблюдается весьма оживленное обсуждение всего того, что касается PHP и его будущего. Что радует — большинство подобных разговоров проходят в позитивном ключе. Популярны дискуссии на тему PHP 6 и того, каким он мог бы выглядеть. Народ задает очень много вопросов об HHVM и её роли в будущем языка и сообщества. Так что позвольте и мне поделиться с вами некоторыми своими мыслями по этому поводу.


Об обратной совместимости

Я считаю, что каждый следующий релиз обязан поддерживать обратную совместимость с предыдущим: 6, 7, 99, «слон-энтузиаст» — называйте как угодно. А теперь я скажу «в основном», поскольку некоторые несовместимости всё же будут иметь место. Но эти несовместимости должны быть обоснованны и контролируемы. Также они должны быть направлены только на пересмотр поведения пограничных случаев и всего такого. Хотя это не означает того, что там не может быть серьезной внутренней реорганизации и стремления к чистоте и простоте вещей. Это означает, что несовместимости не должны чинить препятствий разработчикам.

Такой подход очень легко проверить:

Код, который вы пишете, должен выполняться без проблем и на PHP 5.х, и на PHP 6.х (и любых двух последовательных мажорных релизах).


Почему это важно? Взгляните на переход от PHP 4 к PHP 5. Программистам было достаточно легко писать код, который работал на обеих версиях, хотя на окончательный переход к PHP 5 потребовалось около 10 лет. А представьте, если бы делать это было затруднительно?

Хотя, как выясняется, ничего и представлять не надо. С Python произошло именно это. Первый релиз Python 3 вышел около 5 лет назад. И сегодня, в 2014 году, он все еще задействован не на полную катушку. Не потому, что он плохой, а потому что очень нелегко использовать единый код, который бы работал без проблем на обеих версиях. То есть вы используете либо Python 2, либо тот его функционал, который будет работать в Python 3 (в итоге теряя преимущества обоих). И если нужные вам библиотеки или платформы не имеют версии под Python 3, вам остается либо портировать их самому, либо ну… вам просто не повезло. По факту именно так и происходит.

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

О переписывании движка

Многие люди говорят: надо переписать движок PHP. Несмотря на то, что я определенно вижу в этом плюсы (да, движок весьма замысловат), вынужден задать вопрос: действительно ли это так необходимо? Где фундаментальная собака зарыта? Несомненно, движок PHP имеет архитектурные просчеты, однако по большому счету работает хорошо.

Так что я бы предпочел увидеть переход движка на компонентную основу, разделение его на подсистемы. Сегодня это уже частично сделано. Но я хотел бы увидеть изменения, которые сделали бы движок действительно компонентным. Почему это важно? Потому, что при таком подходе отдельные улучшения смогут внести весомый вклад в развитие движка.

Например, на данный момент самой запутанной частью PHP являются парсер и компилятор. Они настолько тесно связаны и запутаны, что это приводит к массе проблем в разработке. С другой стороны, если бы они были отдельными компонентами движка, тогда что парсер, что компилятор было бы гораздо легче заменить. А их общей частью могло бы быть некое Абстрактное Дерево Синтаксиса (Abstract Syntax Tree). Почему AST? Поскольку это некое общее представление, которое могли бы использовать оба компонента. Да, над этим пришлось бы очень много и хорошо поработать, однако преимущества не заставили бы себя ждать: от последовательного и более предсказуемого синтаксиса до добавления возможности определять собственный синтаксис средствами самого PHP (представьте себе возможность определять DSL в PHP, которые на самом деле являются частью языка).

Так что переписывать заново не нужно. Рефакторить и подчищать.

О переходе стандартной библиотеки к объектно-ориентированному подходу

Некоторые люди предлагают переход стандартной библиотеки PHP к объектно-оритентированному подходу: даже скалярные типы имели бы поведение объектов. То есть вы могли бы написать примерно следующее:

$string = "Foo";
var_dump($string->length); // 3
var_dump($string->toLower()); // string(3) "foo"
// etc


Не думаю, что этому необходимо произойти, хотя, признаюсь, звучит это круто.

Причина проста: скаляры — не объекты. Но, что самое главное, они вообще не относятся к какому бы то ни было типу. PHP полагается на такую систему типов, которая считает, что строки — это целые числа. Гибкость системы заключается также и в том, что любой скалярный тип можно с легкостью привести к другому скалярному типу. Конечно, это не всегда хорошо, ибо из-за этого происходит очень большое количество ошибок.

Однако подобные ситуации могли бы быть разрешены более конкретным поведением. Например, вы могли бы бросить отлавливаемое предупреждение или исключение при попытке «грязного» приведения типов, так что если кто-нибудь попытался бы привести «123abc» к целому числу, то получил бы сообщение о частичной потере данных.

Еще более важным является то, что при наличии такой системы типов вы не можете знать на 100%, какой тип имеет та или иная переменная в данный момент времени. Вы можете предполагать различные варианты, однако что там на самом деле — не известно. Ситуация не шибко изменится даже после приведения типов или если язык будет поддерживать подсказки скалярных типов, поскольку эти типы всё равно позже можно изменить.

Таким образом, всё это означает, что при объектно-ориентированном подходе все скалярные операции должны были быть привязаны ко всем скалярным типам. Что привело бы к объектной модели, в которой скаляры имели бы не только математические методы, но и методы работы со строками. Что за бред…

Становление HHVM

Сегодня, на момент написания этой статьи, я не рекомендую использовать HHVM в продакшне. На то есть несколько причин. Все они известны и не являются фундаментальными. Время покажет, удастся ли их решить, но я на это очень надеюсь.

  1. HHVM контролируется одной компанией. Не поймите меня неправильно, проблема не в том, что Facebook тратит уйму денег на разработку. Но в том, что проект контролируется компанией, чей бизнес не зависит от того, используете вы HHVM или нет. Одно дело, если бы они осуществляли платную поддержку и сделали HHVM полноценным продуктом. Другое — что сейчас это ни проект с открытым исходным кодом, ни коммерческий проект — нечто среднее. И я был бы весьма напряжен, переводя продакшн на HHVM в такой ситуации.
  2. HHVM не имеет публичной спецификации, то есть в целом вы будете программировать так же, как под движок Zend. Однако это метод проб и ошибок, поскольку все будет нормально до тех пор, пока вы не попытаетесь поддерживать несколько реализаций. Как разработчик библиотеки я уже прочувствовал это на своей шкуре. С другой стороны, если бы HHVM и PHP пришли в итоге к некоей общей спецификации, многие вещи стали бы гораздо проще...
  3. HHVM — проект с закрытыми исходниками, хотя и принимает код от сторонних разработчиков (уже хорошо). Однако поток пулл-реквестов и патчей не производит проект с открытым исходным кодом. Ну и где ясность процесса? Где ясность перспектив? Где открытость участия? Где лидерство?


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

Могут ли PHP и HHVM сосуществовать?

Естественно. Несмотря на то, что некоторые тесты выглядят убедительными, JIT-компиляторы — не магия. Они идут на компромиссы с этим нашим реальным миром: многие тесты выявляют это. Ну, а на самом деле, если вы внимательно посмотрите на подавляющее большинство тестов, вы заметите, что они не исполняют «реальный» код. Стоп-стоп, то есть вы таки сравниваете производительность HelloWorld или генератора чисел Фибоначчи?! Ну, удачи вам, только теперь успокойтесь, пожалуйста, и выкиньте все эти бесполезные результаты.

Позвольте повториться, что тесты, не задействующие реальные системы, бесполезны: это чепуха и даже хуже — они просто опасны.

На практике существуют задачи, с которыми HHVM справится гораздо быстрее PHP. Но в то же время есть задачи, где PHP покажет свою скорость. Единственный способ проверить — протестировать свое приложение.

Но HHVM исполняет мой код как нативный! Как PHP может быть быстрее?
Помните, я сказал, что JIT — не магия? Так вот, это на самом деле так. Вы не можете скомпилировать PHP напрямую, поскольку это интерпретируемый язык программирования. Что означает, что вы не можете знать, какой код стоит в очереди на компиляцию ровно до того момента, как вы не выполните этот код. Так что JIT именно это и делает. Он анализирует исполняемый код и, получив достаточные сведения о нем, генерирует нативный код. Данный процесс не избавлен от издержек, из-за этого HHVM медленна в консоли.

Важнее то, что JIT не генерирует универсальный код. Он генерирует код, в соответствии с условиями, которые существовали на момент создания этого кода. Так что, если ваша функция складывает два целых числа, то такой код мог бы скомпилироваться в простую инструкцию add. Однако компилятор также добавит инструкции проверки параметров на целочисленный тип. И если затем вы передадите в свою функцию не число (что нормально с позиции PHP), одна из проверок даст ложный результат.

Когда проверка дает ложный результат, происходит нечто вроде «аварийного переключения». Проще говоря, движок «отменит» все, что скомпилировал для данного метода и переключится в режим интерпретатора. Проведение такой операции гораздо дороже нежели постоянная работа в режиме интерпретатора.

И это лишь одна причина, по которой JIT-компиляторы — не магия.

Я не хочу, чтобы вы сейчас подумали, будто бы я против JIT-компиляторов. Напротив, для большинства задач они покажут существенный прирост производительности. Но всё же они не идеальны.

Посмотрите на другие сообщества и вы увидите реализации виртуальных машин наряду с JIT-компиляторами. CPython и PyPy — хорошие тому примеры. Стоит также заметить, что Python имеет спецификацию языка, так что вы можете легко сменить одну реализацию на другую.

Но HACK крут!
Hack — новый язык программирования, разработанный Facebook и включенный в HHVM. Грубо говоря, это статически типизированная версия PHP с некоторыми дополнительными фишками…

И Hack офигенен! Я очень хочу, чтобы обозначенные мной проблемы HHVM каким-то образом решились, и я бы мог внести свой вклад!

Ведь это интересная идея. Сейчас существует несколько метаязыков, построенных на базе PHP. Лидеры — Hack и Zephir. Но есть проблема. Оба предназначены для конкретной среды исполнения: Hack работает на HHVM, а Zephir — на PHP. Как это разрешить?

Честно говоря, я бы просто выкинул Zephir и построил компилятор из Hack в PECL. Поскольку Hack — статически типизированный язык, должна быть возможность кросс-компиляции между Hack и PECL. А учитывая то, что Hack уже поддерживает привязки C++ (для подключения системных библиотек), теоретически компилятор должен обрабатывать и это. В таком случае уже бы не было смысла писать расширение PECL. Вы бы писали свое расширение на Hack (который располагает статическими анализаторами кода, дебаггерами), и генерировали бы стопроцентно совместимое расширение PECL. Эта вещь, конечно, весьма нетривиальна в реализации, но было бы здорово такое попробовать! Вот, кстати, и еще один аргумент в пользу спецификации языка.

О спецификации языка

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

Подытоживая

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

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 83

    +3
    Важнее то, что JIT не генерирует универсальный код. Он генерирует код, в соответствии с условиями, которые существовали на момент создания этого кода. Так что, если ваша функция складывает два целых числа, то такой код мог бы скомпилироваться в простую инструкцию add. Однако компилятор также добавит инструкции проверки параметров на целочисленный тип. И если затем вы передадите в свою функцию не число (что нормально с позиции PHP), одна из проверок даст ложный результат.

    Когда проверка дает ложный результат, происходит нечто вроде «аварийного переключения». Проще говоря, движок «отменит» все, что скомпилировал для данного метода и переключится в режим интерпретатора. Проведение такой операции гораздо дороже нежели постоянная работа в режиме интерпретатора.


    По-моему эта часть неверно переведена, по мне так это ерунда какая-то. Если он имеет ввиду, что в php значения хранятся как универсальный тип и простая инструкция ADD для сложений чисел одного типа не подходит, то тогда это понятно. Однако, всегда есть возможность совершенствовать анализатор для определения типа переменной во время компиляции, например такое повсеместно используется в V8 для javascript и очень успешно. Например счетчик в цикле for часто имеет тип int и это самый простой пример.
      0
      в оригинальном тексте именно это и говорится. Качество перевода действительно хромает.
        +3
        Если он имеет ввиду, что в php значения хранятся как универсальный тип

        В разделе «On Objectifying The Standard Library» Энтони так и говорит об этом: «The reason is simple, scalars are not objects, but more importantly they are not any type. PHP relies on a type-system that truly believes that strings are integers.».

        Возможно я что-то упускаю…
          +1
          Если брать конкретно приведенный фрагмент, то там говорится лишь о тех инструкциях, которые будут выполняться на уровне процессора. То есть при реализации функции, складывающей числа, наиболее вероятная ситуация когда мы будем складывать собственно числа, по этому JIT будет генерировать инструкцию add и перед ней ставить проверки на тип аргументов. Если там все же не int, то нужно будет скорректировать статистику и сгенерированный код, и выполнять что-то другое. То есть генерируемый JIT компилятором код адаптируется под те условия, которые есть здесь и сейчас на основе и с учетом вероятности какого-либо события (скажем если в функцию передается string 1 раз из 1000, а все остальное время приходит int, то jit подстраивается и возвращает код оптимизированный именно под int. И наоборот). При текущей реализации у вас есть один код на все кейсы, который по природе своей медленный.

          Что до типов и как они хранятся в php — почитайте PHP Internals, так хорошо описан принцип работы zval контейнеров.
        0
        Да, над этим пришлось бы очень много и хорошо поработать, однако преимущества не заставили бы себя ждать: от последовательного и более предсказуемого синтаксиса до добавления возможности определять собственный синтаксис средствами самого PHP (представьте себе возможность определять DSL в PHP, которые на самом деле являются частью языка).


        А DSL в PHP и так можно определять средствами самого языка, без каких-либо сторонних библиотек: habrahabr.ru/post/186656/ Но проконсультировавшись со специалистами — пришёл к выводу, что это только зла добавит в язык, так что затею бросил =)
          0
          Идея неплохая, и метаязыки должны появиться, создатели Zephir ранее заявляли о такой возможности. Есть ещё такая вот реализация. Но использование метаязыка должно давать какие-то плюшки, а пока всё что я вижу — это потеря поддержки IDE.
          0
          HHVM — проект с закрытыми исходниками

          Разве это так? github.com/facebook/hhvm/
          HHVM is an open-source virtual machine...


          PHP relies on a type-system that truly believes that strings are integers

          Не подскажете, что имеется ввиду? То, что строка — это указатель на нее? Или что-то другое?
          0
          В последнее время в сообществе разработчиков наблюдается весьма оживленное обсуждение всего того, что касается PHP и его будущего. Что радует — большинство подобных разговоров проходят в позитивном ключе.

          В позитивном ключе? Автор с Луны? Даже не так… автор с Плутона?

          PHP — это ж красная тряпка. Стоит только упомянуть — сразу понабегут рассказывать про фракталы. По моим ощущениям, из всех мейнстримовых языков больше всего ненавидят PHP, потом идут JS и C++… ну Perl ещё. С остальными языками как-то поспокойнее.
            +8
            «Есть всего два типа языков программирования: те, на которые люди всё время ругаются, и те, которые никто не использует.»
            Bjarne Stroustrup.


            По личным субъективным наблюдениям последнее время действительно стало спокойнее.
            P.S. PHP не является моим основным и тем более любимымы языком, но я рад что он движется вроде бы в правильную сторону.
            • UFO just landed and posted this here
                +1
                reactphp + iibevent, и пишите себе в node-style на php. Насколько я помню для php есть экстеншен для асинхронной работы с IO, драйвер для postgresql поддерживает асинхронные запросы… Собственно зачем еще что-то?
                • UFO just landed and posted this here
                    +3
                    Что значит «не рассчитанные»? Ну так используйте те что рассчитаны. На самом деле что синхронная модель в php, что псевдо-асинхронная в node.js, разница не так уж важна. В node.js довольно легко написать так, что асинхронный он, или нет, но тоже может залочиться весь процесс на какое-то время. + как уже упоминалось ниже — callback-hell (да, промисы минимально это дело разруливают но все же).

                    Словом, я считаю что в своей нише php нормально себе живет и будет жить. А вот попытки переместить php куда-либо дальше web я считаю странными.
                    • UFO just landed and posted this here
                        +2
                        Странно вы как-то плавали, т.к. у меня бот висит с 20-го марта этого года — проверяет новые задачи в редмайне и иссью на гитхабе и отправляет в скайп, если появились новые. И до сих пор висит, никому не мешает. Как кушал 5 метров оперативы, так и кушает.

                        Может на более тяжёлых задачах и проявится что-то, но пока не проявляется почему-то =) Исходники открыты и висят на гитхабе, если интересно — пишите в личку, скину ссылку, сами проверите.
                          –1
                          у меня бот висит с 20-го марта этого года

                          Сейчас «21 апреля 2014 в 12:58» этого года. У вас бот висит минус один месяц?
                            +2
                            почему минус?
                              0
                              Тупонул. Март с маем перепутал.
                            0
                            это который Skype-API?
                            0
                            github.com/SerafimArts/Skype-API/blob/master/run.bat

                            Кроном запускается? Или постоянно висит в памяти?
                              0
                              так демон же, однократно запускается… цикл для перезапуска в случае exception'ов
                              Интереснее вопрос: что в логах? Если он раз в час крашится, то это не показатель отсутствия утечек…
                                0
                                А что, js не течет? в JS сделать что-то что безбожно течет чуть попроще, так что все упирается в ровность рук. Да и сборщик мусора в php не такой уж и плохой.
                                  0
                                  js не течет? кто такое сказал? одна из главных проблем — сложность детектирования этих утечек, как раз из-за асинхронности и отсутствия стека(события попадают в event loop с чистым стеком)
                                  php в последнее время в этом плане вообще торт :)
                                  • UFO just landed and posted this here
                                      +2
                                      забыть var — это не интересно, когда в твоем распоряжении замыкания…
                                        0
                                        Есть supervisord, и не надо извращений с кроном.

                                        Если не секрет, не припомните какие именно модули у вас ликали?
                                        • UFO just landed and posted this here
                                            0
                                            supervisord как средство избавления от кастылей с pid-ами и кроном.

                                            лики в DPO быстро патчатся, в последний раз у меня проблемы с ним были только на 5.3 версиях.
                                    0
                                    Ну пока не было крашей. Раньше были, когда гитхаб или редмайн не отвечал, но это поправил, заодно добавил такой вот фикс с готу в батнике, на всякий случай.
                                    0
                                    Через регистрацию как сервиса. Он же под винду (через COM объект скайпа работает).
                                  +1
                                  Даже на php 4 писались демоны, а на пятом так вообще благодать стала, спокойно работаю месяцами. На ононимках можно даже горячую подгрузку сделать, чтобы не перегружать при новых билдах. Даже mysqli есть, который с базой может асинхронно работать. Есть сборщих мусора и не нужно следить за ссылками как в 4-й версии, а стандартные либы либо не текут, либо быстро патчатся.

                                  А вот мантра не такая бредовая, когда на асинхронных языках начинаешь сражаться с асинхронность, пытаться дебажить, помнить о локах, писать потокобезопасные реализации, убирать мусор и т.д. лучше напищу php код, который будет в 10 раз медленее работать, либо поставлю костыли с pcntl, чем ещё раз на дебаг нодовской библиотеки потрачу времени больше, чем на сам проект.

                                    +2
                                    Никаких кросспоточных проблем в стандартной поставке node не возникает, в том то и фишка, что она однопоточна…
                                    Есть возможность юзать пулл потоков(node-cluster) при необходимости, но это отдельная тема
                                      0
                                      Что вы имеете ввиду под " убирать мусор"?
                                        0
                                        Отвечу сразу и на пост выше.
                                        Я упоминал не только о ноде, у всех хватает своих тонких моментов. Даже разрабатывая на php в режиме демона нужно о них помнить.
                                        PHP отрабатывает и умирает, подчищая за собой все открытые ресурсы, созданные объекты, глобальные переменные, статик кеши, сбрасывается состояние контейнера, одиночек, подхватывает новый код. Это позволяет не задумываться о таких вещах и избавляет от массы проблем, но бьёт по производительности.
                                          +1
                                          Что угодно можно настроить на работу в режиме FastCGI.
                                0
                                а можно пример веб-сервера для отдачи статики на этом?
                                (нет, не надо кричать сразу про nginx. некоторые вещи на nginx вы просто не сделаете).
                                  +1
                                  А не могли бы Вы уточнить, о каких вещах в отдаче статики Вы говорите? Для расширения кругозора, так сказать…
                                    –2
                                    например, у вас на диске 30Тб видео, порезанное кусками по 1 минуте. Вам надо отдать 2 часа видео(т.е. склеить 120 сегментов и отдать в рамках 1 http-запроса).
                                      +1
                                      за что Вы порезали видео? Склейте обратно и юзайте streaming
                                        –1
                                        Открою вам секрет: mp4 — это не единственный контейнер для видео.
                                        Ок, вы упомянули модуль streaming, в котором смещение задается в секундах от начала файла, что годится для весьма ограниченного числа применений.

                                        Например, мы делаем облачный сервис видеонаблюдения и клиенту выделяется некое количество Гб/минут записи. Писать видео цельным куском тут не получится(не говоря уже о всяких заморочках с moov atom'ами), да и смещение относительно начала файла теряет смысл.

                                        Так что давайте вернемся к отдаче статики.
                                        На самом деле интересен пример не только на reactphp + libevent, но и на node.js
                                          +1
                                          принципиальной разницы между reactphp + libevent и nodejs нет.
                                          если Вы динамически клеите куски видеофайлов — почему Вы называете это статикой?
                                          по моему мнению, статика это то, что можно отдать напрямую из файловой системы, без модификаций…

                                          в node.js отдача статики реализуется pipelining'ом чтения файловой системы, получается почти как nginx, в reactphp думаю так же.
                                            0
                                            >если Вы динамически клеите куски видеофайлов — почему Вы называете это статикой?

                                            а в чём проблема? можно mmap'нуть пару файлов и использовать writev() для записи в сокет.
                                            будет тот же самый эффект.

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

                                            так оно и отдаётся без модификаций.

                                            >в node.js отдача статики реализуется pipelining'ом чтения файловой системы

                                            а можно всё-таки пример? желательно с sendfile().
                                              0
                                              Вот сервер для отдачи одного файла…

                                              Пример
                                              require('http').createServer(function(request, response) {
                                                  var filename = require('path').join(__dirname, 'video.mp4');
                                                  var stat = require('fs').statSync(filename);
                                                  response.writeHead(200, {
                                                      'Content-Type': 'video/mp4',
                                                      'Content-Length': stat.size
                                                  });
                                                  require('fs').createReadStream(filename).pipe(response);
                                              }).listen(80);
                                              



                                              Писал на память, могут быть ошибки
                                                0
                                                один — это как раз очевидно и неинтересно. интересно 2 и более :)
                                                  0
                                                  в одном запросе?
                                                    0
                                                    да, в одном запросе. чего тут сложного?
                                                      0
                                                      Сложного ничего, просто думаю имеет ли смысл тратить на это время…

                                                      Пример
                                                      require('http').createServer(function(request, response) {
                                                          var files = ['1.mp4', '2.mp4'];
                                                      
                                                          function nextfile() {
                                                              if (!files.length) return response.end();
                                                              require('fs').createReadStream(__dirname+'/files/' + files.shift())
                                                                           .pipe(response, {end: false})
                                                                           .on("end", nextfile);
                                                          }
                                                      
                                                          response.writeHead(200, {
                                                              'Content-Type': 'video/mp4'
                                                          });
                                                          nextfile();
                                                      }).listen(80);
                                                      



                                                      Не стал считать Content-Size...
                                +7
                                Стать асинхронным, как node? Нет, спасибо, не надо нам callback-hell, это путь в никуда. Асинхронным как Akka — да, норм.
                                  0
                                  прямо так и в никуда…
                                  Кто не хочет, не устраивает себе callback-hell, есть модули типа async, все очень симпатично получается.
                                    +2
                                    Я занимался немного разработкой на node.js и async модуль хорош, но это все равно не позволяет писать код в классическом стиле, лучше смотреть в сторону yield и подобных вещей. Еще я встречал фаната erlang, который рассказывал про ассинхронность у языка в крови и вообще что нет callback-hella и есть более продвинутая система распараллеливания на несколько ядер.

                                    Свою нишу node.js получил на мой взгляд не из-за асинхронности, а из-за популярного языка и легкого старта, легко получить первый работающий результат, низкий порог вхождения.
                                      +1
                                      Может вы и правы, но именно асинхронность стала причиной использования node лично мной на некоторых проектах,
                                      Легкий старт? легче чем в PHP? Не согласен.
                                      Само наличие парадигменного сдвига делает свое дело. Я почти неделю привыкал к тому, что не могу получить результат запроса к базе, как результат вызова функции, но когда освоился, почему-то в сторону yield смотреть не хочется.
                                      Пропало желание подгонять js к некому классическому стилю, я полюбил его таким, какой он есть.
                                      promises — хорошая методология, но иногда и она оказывается излишней.

                                      В основном, кстати я пишу на PHP, так как его средств с лихвой хватает на 90% моих задач.
                                      Превращать PHP в nodejs, разумеется, не нужно, к тому же уже есть reactPHP.
                                        0
                                        Любопытно, а когда по вашему промисы излишни? И еще — насколько большие проекты вы делаете с применением node.js. Какую часть проекта занимает именно нода? Крутятся ли они в продакшене?
                                          0
                                          В маленьком API на 10 методов — это ненужная абстракция.
                                          Проектов с node у меня было немного, и все API в чистом виде(для мобильных приложений), без генерации HTML, angular и даже express. Использую restify, хотя можно было бы и без него обойтись.
                                          В продакшне крутятся, но крутятся не у нас, в штатах…
                                          Из них 2 довольно крупные, по реализации около 800rps с одного инстанса, на одном сейчас 3 таких ноды, на втором 2.
                                          Какую часть? Ну собственно rest api, т.е чуть менее, чем полностью(если учитывать хранимые процедуры Lua для Redis).
                                            0
                                            В маленьком API на 10 методов — это ненужная абстракция.

                                            А какое отношение промисы имеют к абстракциям? Это механизм flow-control, не более. И что вы имеете в виду под «API на 10 методов». Если вы про сам restfull-сервис, то какая разница сколько методов? Если вы про какой-то внутренний сервис, тем более. Сервис может использоваться в каком-то контексте где промисы смогу спасти от callback-hell.
                                              0
                                              Ну это не совсем control-flow же, async — control flow в чистом виде, а промисы это все же абстракция над control flow.
                                              Наверное, я так рассуждаю, потому что не использовал чужих реализаций, делал свой велосипед, и вот в небольшом сервисе (Сервис коротких ссылок, например, 2 метода, не считая авторизации) я этот велосипед не использую.
                                  0
                                  Платформа, которая «умеет всё» обречена стать монстром. Уж лучше поднапрячься, изучить дополнительные действительно пригодные для задачи инструменты и внедрить, как дополнение к тому, что уже есть.
                                0
                                Впоне возможно, что более позитивные отзывы связаны не только с обновлениями самого языка, но и с появлением/развитием хороших инструментов, фреймворков, написанных на нем.
                                +2
                                Если PHP будет строго следить за обратной совместимостью, то это сильно замедлит внедрение новых возможностей, зато возможно повысит авторитет языка в enterprise-секторе. Подобное мы наблюдаем с таким серьезным промышленным языком, как Java.
                                  +1
                                  PHP, Enterprise… чёрт, а ведь это на яву!
                                    –1
                                    Опечатка по Фрейду
                                  +2
                                  Что-то второй раз замечаю за Anthony Ferrera нехорошую черту — кидать камень в разработчиков Phalcon/Zephir.

                                  Честно говоря, я бы просто выкинул Zephir


                                  Ранее он похожее про Phalcon завялял. Заметьте — сказано абсолютно без аргументации. Почему выкинул? И самое главное ради чего? Чтобы где-то некогда в каком-то светлом будущем построить компилятор из Hack в PECL, хотя Zephir уже умеет компилироваться в PECL расширения! При этом странно хвалить HACK, который работает только на ранее раскритикованной HHVM.
                                    0
                                    … о которой он почему-то говорит, что она закрытая.

                                    На самом деле, я тоже не разделяю подобную точку зрения. Я пока в данных технологиях не разбираюсь (наверное, поэтому и взялся за перевод), но думаю, что разные подходы важны и полезны. Пройдет некоторое время, а там уж и определятся лидеры и аутсайдеры по различным параметрам, в том числе и по сообществу.
                                      0
                                      Это конечно очень некрасиво заявлять, что вот чужой труд, на который было потрачено уйма времени и сил, надо просто так выкинуть из-за того что кому-то вдруг понравился hacklang больше чем zephir.
                                      0
                                      Что угодно придумают, лишь бы не изучать Ruby
                                        +1
                                        Я имею в виду, что PHP был хорош именно своей простотой и доступностью для начинающего. Приближая свой синтаксис к языкам другого предназначения, PHP наступает на те же грабли и может растерять все свои прежние преимущества. When you're hammer, everything looks like a nail.
                                          –1
                                          Для того, что бы не изучать руби — придумали более быстрые языки программирования =)
                                            0
                                            Ассемблер был до руби, но как-то народ не стремится на нем писать под WEB. Суть новых языков программирования — балансирование на грани между удобством разработки и производительностью. Ну и если вы будете применять язык, который больше склоняется в сторону производительности при реализации задачи, которая требует скорейшего решения, то думаю вам стоит пересмотреть взгляды на выбор инструментов разработки.
                                              +1
                                              Я, как человек не понаслышке работавший с руби — ответственно заявляю, что у руби «балансировка» немного накренилась в сторону просто безумнейших тормозов. Не просто же так гитхаб через раз отвечает заглушкой юникорна или твитч постоянно лагает ;) Не просто же так популярные ресурсы убегают с этого языка на более лёгкие.

                                              Хотя в оправдание могу сказать, что во второй версии скорость немного подняли, хотя работа с json как и была раз в 8-10 медленнее пыха, так и осталась… Ну и добавить лишь то, что это было таким же холиварным ответом к холиварному комментарию =)
                                                0
                                                Причем тут холивары? Я вообще про это:
                                                $string = "Foo";
                                                var_dump($string->length); // 3
                                                var_dump($string->toLower()); // string(3) "foo"
                                                // etc
                                                


                                                Зачем ограничиваться строками? И вот, приходим к понятию: «все есть объект». А если все есть объект, то рано или поздно тормоза обеспечены.

                                                Я свободно пишу как на php, так и на ruby и еще на парочке языков и не буду разводить холивар. Мой месседж не в этом. А в том, что у меня есть набор инструментов (языков, технологий) и я в зависимости от потребностей могу выбирать что лучше под данную конкретную задачу. Если php будет продолжать гнаться за более мощными языками, при этом волоча за собой шлейф обратной совместимости, то может растерять свои декларированные преимущества. Обострится принцип «When you're hammer, everything looks like a nail.», т.е. языки, где все давно есть, в которые надо просто проинвестировать время и изучить, не будут выбираться в пользу php. А php будет балансировать между фичастостью, обратной совместимостью и скоростью. Как результат, боюсь, за всеми тремя кроликами разработчики не угонятся, но все равно удачи им.
                                                  0
                                                  «Всё есть объект» в виде кода — не значит, что «всё есть объект» в виде внутреннего представления. Вполне достаточно использовать те же самые операции при обращениям к методам скаляра (с помощью функций) или проверять на скаляр и заменять на аналогичную функцию:

                                                  — $string->length на strlen($string);
                                                  — $string->toLower() на strtolower($string);
                                                  — $string->toLower()->toUpper(); на strtoupper(strtolower($string));

                                                  То что внутри рубей это реализовано по другому до такой степени, что пришлось изобретать два разных типа строк (константная — :string и объект — «string») — это проблемы реализации рубей. Если в пыхе требуется поддержка скаляров, как объектов, то помимо возможностей препроцессора внутри самого языка (через кастомные фильтры) есть ещё целое расширение — уже давно nikic это реализовал: github.com/nikic/scalar_objects но почему-то никто особо (особо — это значит как другими пекловскими расширениями, вроде runkit, apc, mcrypt, libevent, intl) этим не пользуется =) Даже hhvm пользуется большей популярностью, имхо.

                                                  При этом, сознавая всю красоту ОО подхода к скалярам я придерживаюсь мнения автора поста — это плохо, если разделять методы или свойства к каждому скаляру по отдельности — получим тысячи ошибок вызова методов, просто потому что в переменной в этот момент времени был другой тип переменной. А если делать общие методы для всех типов, то получим ещё большую мешанину, сейчас хотя бы префиксы есть, не везде, но зачастую. Что должно делать "->replace()"? Это аналог array_replace или str_replace? Или может preg_replace? Или суперпопулярная функция substr_replace?
                                                    0
                                                    Вы изобрели макросы?
                                                    Символ — не строка.
                                                    Такие расширения на публичный хостинг никто ставить не будет.
                                                      0
                                                      1) Я только изобрёл препроцессор и апи для него, который ставится в виде пакета из композера, а остальная часть за самим языком.

                                                      2) Символ из набора символов — не строка, да, логично =) В пыхе, например нет ни символов, ни строк, если уж на то пошло. В пыхе есть только последовательный набор байт, но все называют их строками.

                                                      3) Но PDO почему-то ставили, его даже после этого в язык встроили. Mcrypt ставили, ейписи, либэвент, интл, крул, сокеты и многое другое. В чём отличие этого расширения от перечисленных выше?
                                                        0
                                                        Эти расширения полезны. То есть без вашего прожить можно, а без интл, курла или мкрипта уже тяжко будет.
                                                    0
                                                    Т.е. если подытожить, то максимум что стоит сделать — это:

                                                    — Вынести функции в подпространства, по ходу написав соглашение именования аргументов:
                                                    str\replace("string", "s", "a"); // atring
                                                    // или, на крайний случай
                                                    str::replace("string", "s", "a"); // atring
                                                    

                                                    — Добавить множественный импорт из пространств имён:
                                                    use str/*;
                                                    use array/*;
                                                    use str/substr/*;
                                                    

                                                    — Добавить возможность разрешения конфликтов имён классов внутри конечного кода:
                                                    use Std\Some\Any;
                                                    use Any\Some\Ololo\Any;
                                                    
                                                    new Any; // первый use
                                                    new Ololo\Any; // второй use
                                                    


                                                    Остальные модные тенденции превращать всё в объект — фтопку. Опять же, имхо.
                                                      0
                                                      В мощных языках для этого используются классы-обертки. Загоняете в такой new MegaString($string) и работаете с методами, расширяете, кстати monkey-patch в php уже можно сделать? Ок, появились traits.

                                                      а как вам такое?
                                                      use str\replace as str_replace;
                                                      use array\replace as array_replace;
                                                      


                                                      и приходим к бесполезности даже начинать пользоваться вашим предложением.

                                                      Вернусь к началу. В Java есть базовые типы и классы-обертки. В Scala пошли еще дальше — язык напоминает Ruby синтаксическим сахаром, но базовые типы остались. В Ruby, как и в Smalltalk все есть объект и все интуитивно, но медленно. В php очень простой и неполный ООП и куча функций. Никаких макросов ни в коем случае. Один из проверенных той же джавой подходов — классы-обертки.

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

                                                        И часто такой код вы наблюдаете? И почему бесполезности, если несогласованность — это единственный «камень преткновения» на данный момент в пыхе.

                                                        На счёт неполного\простого ООП — что имеется ввиду, то что классы — это не объекты или числа? А зачем? Всего должно быть в меру. Возможностей хватает, и если сравнивать с тем же руби — покажите мне позднее статическое связывание на нём, например.

                                                        И с чего Вы решили, что Никита или Дмитрий не прочитают этот тред? =)
                                                          0
                                                          Да да в PHP очень «неполноценный ООП», что мне интересно там неполноценного-то?
                                                      0
                                                      Про «безумные тормоза» это преувеличение. В тех проектах, что участвую и поддерживаю (нагрузки выше среднестатистического сайта) ни разу даже близко не упирались в скорость руби / рельсов.
                                                        0
                                                        Хорошо, перефразирую. Скорость руби + рельс. В случае каких-нибудь нитро или синатры — результат будет конечно намного отличаться.
                                                          –1
                                                          Дело в том, что руби как язык может быть медленнее, но модель его работы другая. Если пхп при каждом запросе заново грузит все классы (хоть и лениво), заново все инициализирует, а в конце умирает, то в руби да и в других языках, 1 запрос = 1 вызову метода, поэтому отдача контента упирается уже в базу или что-то еще, например в медленный шаблонизатор.

                                              Only users with full accounts can post comments. Log in, please.