[PHP, Программирование, Интервью] Занятное мини-интервью с основными контрибьюторами PHP 8
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Несколько недель назад русскоязычное PHP-сообщество проводило стрим по случаю выхода мажорной версии языка. По ходу трансляции зрители могли задать вопрос Никите Попову и Дмитрию Стогову, — а в конце те подключились и ответили на часть из них (остальные ответы мы опубликуем письменно, просто не успели уложить почти 100 вопросов в 40 минут — следите за постами pronskiy).
Вы можете посмотреть видеоверсию интервью тут.
Часть ответов уже разлетелась по чатам в виде цитат («Я все языки не люблю, но меньше других — Rust», «Когда вcе заговорили о PHP++, я задумался о PHP+-»), а остальные яркие моменты мы решили сложить в этот пост.
Каждый подзаголовок — это кратко переформулированный вопрос. Местами ответы приведены в усеченном виде, но без потери смысла.
Про нативные enum’ы в PHP
Никита Попов: Надеюсь, они будут в PHP 8.1: по крайней мере, есть план, как это будет выглядеть, и люди, которые над этим работают. Изначально будут достаточно простые, стандартные enum, которые будут имплементированы как специальные объекты. Каждый член enum — это отдельный класс.
Дмитрий Стогов: Зачем для этого классы? Почему не взять enum как набор констант и объединить их в один тип?
Никита Попов: Классы — чтобы можно было их как-то типизировать. Если enum – это числа 1, 2 ,3, то нельзя отличить числа от членов enum. Думаю, возможность типизации это главное, если ее нет, то можно просто использовать класс с константами.
Мы хотели бы все-таки, чтобы тип проверялся. Например, есть какой-то enum параметр, ты туда посылаешь просто integer или string — и тогда получаешь ошибку.
А не сделать ли PHP компилируемым?
Дмитрий Стогов: Никто не мешает сделать компилируемым язык с динамической типизацией. Просто он будет работать точно так же, как интерпретатор: проверять, какой у нас тип, и иметь ветки кода для каждого возможного типа.
По сути, у нас есть режим function для JIT, который можно рассматривать как ahead of time компилятор. Если включите его, то все, что загружается, будет сразу компилироваться. Но большого смысла я не вижу: вам все равно потребуется вся виртуальная машина, все библиотеки. Хотя, можно как в GraalVM – cделать какой-то урезанный пак.
Но это большая работа, а увеличения производительности не будет. Tracing JIT показывает лучшие результаты, а он возможен только на этапе выполнения.
Если вы заинтересованы не в производительности, а хотите код скомпилировать и давать людям только бинарник, чтобы они код не видели, – это другая задача. Я не вижу смысла делать open source продукт для людей, которые будут зарабатывать деньги, скрывая свои сорцы.
Перспективы асинхронности в PHP
Дмитрий Стогов: Большого выигрыша от асинхронности для всех в PHP я не вижу: это сложность, это очень узкое применение для определенного круга задач.
Добавить async/await – нет никаких проблем, это синтаксический сахар. Добавить файберы и корутины? В принципе, думаю, не так уж сложно.
Вопрос — кто этим займется и доведет ли он это до ума.
Я готов помогать.
Никита Попов: Там как раз кто-то опять работает над этой темой. Но основная проблема в куче синхронного кода: это же причина того, почему в том же Китае так популярен Swoole, который заменяет PDO и так далее версией, которая работает асинхронно. Но я как-то не совсем знаю, хотим ли мы это иметь на уровне ядра. Потому что это точно сделает все более сложным.
Дмитрий Стогов: Вероятно, нам потребуется редизайнить stream layer. Если с ним разобраться, то все остальное будет проще. Анатоль Бельский пытался за это браться, но, потратив некоторое время, решил: «Ну его нафиг».
Есть уже планы, что добавить в 9-ку?
Никита Попов: Скорее, хотелось бы многое убрать. Например, reference если убрать, то все станет намного проще.
Дмитрий Стогов: Преобразование типов налету, сравнение строки с числом — вот от этого неплохо уйти уже в PHP 9, допустим.
Есть и мысли, что добавить. Например, вместо include’ов и require было бы хорошо сделать систему модулей настоящих, чтобы было понятно, какие классы и переменные откуда у нас приходят.
Это было бы очень круто, но это гигантская работа: просто понять, как все это должно выглядеть даже — в Jave модули выглядят ужасно, на мой взгляд. В Python… можно было бы сделать что-то такое, но с учетом, что у нас все динамично. Но может быть где-то есть что-то лучше.
Есть еще один момент, для меня достаточно интересный.
Если сейчас посмотреть на боттлнеки в PHP-парсере, например, это все обращения к массивам.
В JavaScript можно встретить такое: единый тип массив, но в многих случаях он может работать более оптимально, если его представлять тем или иным способом. То есть это адаптивный массив. Например, если есть массив целых чисел, то его можно так и представлять. Но как только туда вставляется что-то другое, он должен преобразоваться во что-то другое.
Это поможет, если мы обрабатываем матрицу какую-то на PHP: она будет плоской, как в C это представлено. Соответственно, работать с ней будет намного быстрее, особенно если мы используем это в JIT. Ничего сложного в этом нет, все «закладки» для этого уже заложены.
Для пользователя при этом ничего не изменится, просто будет работать быстрее.
Сейчас много реализаций PSR-7. Может вам сделать что-то одно и затащить в ядро?
Никита Попов: Я считаю, что в ядро надо затаскивать вещи, которые важны для производительности. Это не тот случай.
Думаю, лучше, если вопросы request-response будут решаться в userland, — там можно соревноваться, делать какие-то изменения. Если мы загрузим это в ядро, тогда это навсегда: а если выяснится, что там что-то не то, сложно будет всем.
p.s. Спасибо Роману Пронскому за помощь в редактуре расшифровки. Читайте продолжение интервью, которое осталось за кадром стрима, в одном из следующих постов.
===========
Источник:
habr.com
===========
Похожие новости:
- [Программирование, Java, Scala] Scala 3: новый, но необязательный синтаксис (перевод)
- [Программирование, Разработка мобильных приложений, Dart, Flutter] Flutter под капотом: Owners
- [Open source, Тестирование IT-систем, Программирование, Java] Вжух, и прогоны автотестов оптимизированы. Intellij IDEA плагины на службе QA Automation
- [Программирование, C, История IT] «Чертовски глупое решение»: история появления языка C (перевод)
- [Программирование, R, Data Engineering] Логирование выполнения скриптов на языке R, пакет lgr
- [Программирование микроконтроллеров, Схемотехника] Изучаем RISC-V с нуля, часть 1: Ассемблер и соглашения
- [Программирование, Rust] Rust crashcourse. Итераторы (перевод)
- [Программирование, Java, Scala, Компиляторы] Идеальный SAST. Тестируем парсеры
- [Программирование, Управление персоналом, Карьера в IT-индустрии] Проблема: возраст, опыт и трудоустройство
- [Программирование, Java, Администрирование баз данных, API] Java и базы данных: обзор библиотек и API (перевод)
Теги для поиска: #_php, #_programmirovanie (Программирование), #_intervju (Интервью), #_php, #_php_8, #_blog_kompanii_skyeng (
Блог компании Skyeng
), #_php, #_programmirovanie (
Программирование
), #_intervju (
Интервью
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 15:18
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Несколько недель назад русскоязычное PHP-сообщество проводило стрим по случаю выхода мажорной версии языка. По ходу трансляции зрители могли задать вопрос Никите Попову и Дмитрию Стогову, — а в конце те подключились и ответили на часть из них (остальные ответы мы опубликуем письменно, просто не успели уложить почти 100 вопросов в 40 минут — следите за постами pronskiy).  Вы можете посмотреть видеоверсию интервью тут. Часть ответов уже разлетелась по чатам в виде цитат («Я все языки не люблю, но меньше других — Rust», «Когда вcе заговорили о PHP++, я задумался о PHP+-»), а остальные яркие моменты мы решили сложить в этот пост. Каждый подзаголовок — это кратко переформулированный вопрос. Местами ответы приведены в усеченном виде, но без потери смысла. Про нативные enum’ы в PHP Никита Попов: Надеюсь, они будут в PHP 8.1: по крайней мере, есть план, как это будет выглядеть, и люди, которые над этим работают. Изначально будут достаточно простые, стандартные enum, которые будут имплементированы как специальные объекты. Каждый член enum — это отдельный класс. Дмитрий Стогов: Зачем для этого классы? Почему не взять enum как набор констант и объединить их в один тип? Никита Попов: Классы — чтобы можно было их как-то типизировать. Если enum – это числа 1, 2 ,3, то нельзя отличить числа от членов enum. Думаю, возможность типизации это главное, если ее нет, то можно просто использовать класс с константами. Мы хотели бы все-таки, чтобы тип проверялся. Например, есть какой-то enum параметр, ты туда посылаешь просто integer или string — и тогда получаешь ошибку. А не сделать ли PHP компилируемым? Дмитрий Стогов: Никто не мешает сделать компилируемым язык с динамической типизацией. Просто он будет работать точно так же, как интерпретатор: проверять, какой у нас тип, и иметь ветки кода для каждого возможного типа. По сути, у нас есть режим function для JIT, который можно рассматривать как ahead of time компилятор. Если включите его, то все, что загружается, будет сразу компилироваться. Но большого смысла я не вижу: вам все равно потребуется вся виртуальная машина, все библиотеки. Хотя, можно как в GraalVM – cделать какой-то урезанный пак. Но это большая работа, а увеличения производительности не будет. Tracing JIT показывает лучшие результаты, а он возможен только на этапе выполнения. Если вы заинтересованы не в производительности, а хотите код скомпилировать и давать людям только бинарник, чтобы они код не видели, – это другая задача. Я не вижу смысла делать open source продукт для людей, которые будут зарабатывать деньги, скрывая свои сорцы. Перспективы асинхронности в PHP Дмитрий Стогов: Большого выигрыша от асинхронности для всех в PHP я не вижу: это сложность, это очень узкое применение для определенного круга задач. Добавить async/await – нет никаких проблем, это синтаксический сахар. Добавить файберы и корутины? В принципе, думаю, не так уж сложно. Вопрос — кто этим займется и доведет ли он это до ума. Я готов помогать. Никита Попов: Там как раз кто-то опять работает над этой темой. Но основная проблема в куче синхронного кода: это же причина того, почему в том же Китае так популярен Swoole, который заменяет PDO и так далее версией, которая работает асинхронно. Но я как-то не совсем знаю, хотим ли мы это иметь на уровне ядра. Потому что это точно сделает все более сложным. Дмитрий Стогов: Вероятно, нам потребуется редизайнить stream layer. Если с ним разобраться, то все остальное будет проще. Анатоль Бельский пытался за это браться, но, потратив некоторое время, решил: «Ну его нафиг». Есть уже планы, что добавить в 9-ку? Никита Попов: Скорее, хотелось бы многое убрать. Например, reference если убрать, то все станет намного проще. Дмитрий Стогов: Преобразование типов налету, сравнение строки с числом — вот от этого неплохо уйти уже в PHP 9, допустим. Есть и мысли, что добавить. Например, вместо include’ов и require было бы хорошо сделать систему модулей настоящих, чтобы было понятно, какие классы и переменные откуда у нас приходят. Это было бы очень круто, но это гигантская работа: просто понять, как все это должно выглядеть даже — в Jave модули выглядят ужасно, на мой взгляд. В Python… можно было бы сделать что-то такое, но с учетом, что у нас все динамично. Но может быть где-то есть что-то лучше. Есть еще один момент, для меня достаточно интересный. Если сейчас посмотреть на боттлнеки в PHP-парсере, например, это все обращения к массивам. В JavaScript можно встретить такое: единый тип массив, но в многих случаях он может работать более оптимально, если его представлять тем или иным способом. То есть это адаптивный массив. Например, если есть массив целых чисел, то его можно так и представлять. Но как только туда вставляется что-то другое, он должен преобразоваться во что-то другое. Это поможет, если мы обрабатываем матрицу какую-то на PHP: она будет плоской, как в C это представлено. Соответственно, работать с ней будет намного быстрее, особенно если мы используем это в JIT. Ничего сложного в этом нет, все «закладки» для этого уже заложены. Для пользователя при этом ничего не изменится, просто будет работать быстрее. Сейчас много реализаций PSR-7. Может вам сделать что-то одно и затащить в ядро? Никита Попов: Я считаю, что в ядро надо затаскивать вещи, которые важны для производительности. Это не тот случай. Думаю, лучше, если вопросы request-response будут решаться в userland, — там можно соревноваться, делать какие-то изменения. Если мы загрузим это в ядро, тогда это навсегда: а если выяснится, что там что-то не то, сложно будет всем. p.s. Спасибо Роману Пронскому за помощь в редактуре расшифровки. Читайте продолжение интервью, которое осталось за кадром стрима, в одном из следующих постов. =========== Источник: habr.com =========== Похожие новости:
Блог компании Skyeng ), #_php, #_programmirovanie ( Программирование ), #_intervju ( Интервью ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 15:18
Часовой пояс: UTC + 5