Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

Одно из суждений о грядущем PHP

Anna | 29.05.2014 | нет комментариев

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

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

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

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

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

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

Правда, как выясняется, ничего и представлять не нужно. С Python случилось именно это. 1-й релиз 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, думаю, мы обязаны о-дюже отлично понимать, что мы делаем, делая тот либо другой выбор.

Источник: programmingmaster.ru

Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB