Зачем писать на PHP в 2020?

Главные вкладки

18.06.2020
Онлайн

В начале июня один из ведущих подкаста «Цинковый прод» разместил на Хабре резонансную статью «Какая ниша у языка и поможет ли PHP8 решить [его] насущные проблемы (спойлер: имхо, нет)». Незадолго до этого мы решили, что пора бы сделать доклад, зачем выбирать PHP, когда вокруг расцветают сто цветов языков. Эти вещи так совпали по времени, что захотелось устроить совместный эфир и обсудить нишу и перспективы языка — с разных точек зрения.

Что обсудим

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

  • Как и кем формируется рынок PHP-разработки, кто по факту решает, на чем писать и переписывать проекты.
  • Тяжелое детство, взросление и текущее состояние 25-летнего языка — что поправили, что научились решать иначе. С чем и кто обычно столкнется в реальности. И что из того, что хочется, реально нужно.
  • Почему PHP, который хоронят лет 20, может быть “новым коболом” — и какая кому от этого выгода.
  • Посравниваем с другими языками: ну куда же без этого. И, конечно, обсудим саму статью и реакцию на нее.

Подключайтесь к трансляции 18 июня в 20 часов по Москве — комментарии на ютубе обязательно попадут в выпуск. А может и с голосовым общением что придумаем.

Ссылка на видео-трансляцию: https://www.youtube.com/watch?v=QrlWrFILjMk


Расшифровка обсуждения появится в июле-августе отдельным материалом. Мы сделаем апдейт к этому посту со ссылкой на нее.

Источник: https://habr.com/ru/company/skyeng/blog/506704/

Комментарии

Аватар пользователя OldWarrior OldWarrior 18 июня 2020 в 17:06

Меня, кстати, (если уж на то пошло) ближе к старости всё больше и чаще занимает безумный вопрос: почему в 2020 году вообще весь Web всё ещё держится на тексте? Smile

Вся web-механика от транспорта/передачи (HTTP) данных до разметки лэйаута и стилей страниц - всё по сути в текстовом виде и всё на парсинге текста и регулярках. Понятно, что тут гипертекст в основе, природа его такая, наследие и все дела. Но что мешает придумать более компактный (возможно, бинарный) формат передачи разметки и самого веб-контента?

Мы обрабатываем и таскаем по сети порой (ну, чисто эмпирически) до 80-90% информации, относящейся к теговой разметке или стилевому оформлению страниц. И эта информация всё в том же текстовом виде. А какая потребность в этом в наше время? И насколько быстрее была бы обработка и передача "компилированного" контента, в котором вся разметка отдельного блока сводилась к считанным байтам (возможно, даже из каких-то наиболее типичных пресетов-паттернов).

Просто как пример - ну, навскидку:

// Настоящее.
...
<div class="card card-secondary rounded border-dark">
  <div class="card-header">Однажды в студёную <b>зимнюю</b> пору</div>
  <div class="card-body">Я из лесу вышел, был сильный мороз...</div>
</div>
...
// Мрачное светлое будущее
...
^¶Ⱪ0ae>Ǹ~Однажды в студёную ^*6зимнюю пору
3≤1a>¿~Я из лесу вышел, был сильный мороз...
...

При этом текстовое содержимое остаётся текстом. Поисковым машинам, по-моему, уже давно всё равно, в каком виде будет представлено и размечено веб-содержимое. Не всё равно разве что гикам-программистам, поскольку код вряд ли можно будет назвать human-readable и руками писать его будет затруднительно чуть менее чем всегда. Smile Ну, собсна на то компиляторы и существуют.

Аватар пользователя bumble bumble 18 июня 2020 в 19:04

Услышал Вашу мольбу и жалобы, взвесил и отправился назад во времени на пару лет. Придумал для Вас HTTP/2 и вебсокеты.
Не благодарите!

Аватар пользователя OldWarrior OldWarrior 19 июня 2020 в 1:15

bumble wrote: HTTP/2 и вебсокеты

HTTP/2 бинарный транспорт, но не разметка (как сжатый/компилированный аналог формата HTML). Т.е. во многом тот же текст, только в бинарном виде. Вебсокеты - ну, полезная и долгожданная плюшка, но выше речь главным образом о "всё-ещё-текстовом-вебе" в 2020 году.

bumble wrote: Не благодарите!

Так и не за что Smile

Аватар пользователя bumble bumble 19 июня 2020 в 18:10

А Вы хотите вперемешку? О_о
Вы же понимаете, что это: ¶Ⱪ0ae>Ǹ~ - не бинарные данные?
И что бинарные данные + не бинарные данные = не бинарные данные. В чем же профит?

Аватар пользователя OldWarrior OldWarrior 19 июня 2020 в 23:36

bumble wrote:... ¶Ⱪ0ae>Ǹ~ - не бинарные данные ...

Да это просто ASCII-представление некоей компилированной/компактной разметки - для сравнения с типичным HTML-маркапом. Которое, кстати, вполне себе может быть и в бинарном виде. Пример же здесь просто с "потолка", у меня разумеется нет какой-либо законченной реализации.

bumble wrote:... И что бинарные данные + не бинарные данные = не бинарные данные. В чем же профит?

Собственно, речь о том, что все эти тонны теговой текстовой разметки документа (да и сам текстовый контент) можно упаковать в более компактную цифровую форму/структуру, где разметка (в виде каких-то заготовок/паттернов) может даже существовать отдельно от основного текстового/значимого содержимого. Возможно местами применяя ещё и gzip-сжатие цепочек контента. Smile

Скажем, такой простой пример. Большинство современных сайтов интенсивно используют HTML-контейнеры (а-ля универсальный DIV), поведение которых в общем-то обычно приходится "наруливать" другими правилами CSS, чтобы обеспечить требуемое позиционирование и/или размеры контейнера. Что в свою очередь может генерировать много опять же текстовой разметки (порой достаточно просто вывести какие-нибудь ряды данных в Bootstrap 3-4, чтобы убедиться в этом)

Так почему в спецификациях до сих пор нет простых и удобных HTML-контейнеров именно для лэйаута? Какой-нить <box> или <overlay> или <column> или все вместе. Где все типичные необходимые свойства уже предустановлены, и только нюансы наруливаются правилами (не будем про flex'ы, речь именно о разметке).

А если пойти дальше, то лучше вообще отказаться от прожорливой мнемоники в названиях и формировать сущности разметки как некие компактные указатели на встроенные/предустановленные (или расширяемые/загружаемые) ресурсы. Что, разумеется, практически возможно только при использовании каких-то программных средств обработки (а-ля компиляторы). И тогда уже как-то невольно (по крайней мере у меня) возникает мысль о бинарном характере и хранения и транспорта данных в целом как о следующем шаге.

Аватар пользователя bumble bumble 19 июня 2020 в 23:42

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

Ну, а про бинарность - задайтесь вопросом, на сколько удобно Вам было бы писать такой код. Уверен, ответ на этот вопрос сразу материализуется. Не зря ведь, с каждым годом, тренды развития индустрии программирования развивается в сторону от маш-команд к все более высоким абстракциям, не наоборот.

Аватар пользователя OldWarrior OldWarrior 20 июня 2020 в 0:01

bumble wrote:... задайтесь вопросом, на сколько удобно Вам было бы писать такой код.

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

bumble wrote: Не зря ведь ...

А почему не зря, как думаете? Какой сакральный смысл в этом?

Аватар пользователя OldWarrior OldWarrior 20 июня 2020 в 13:24

Думаю, при правильном развитии сценария с компиляцией веб-содержимого - времени на разработку/отладку будет требоваться ещё меньше.

Например, сколько сейчас времени отнимает отслеживание зависимостей и переопределений правил CSS - особенно в случае с фреймворками типа BS. Понятно, что сейчас в каждом утюге есть инспекторы свойств, консоль отладки и т.д., но всё равно это жрёт время и порой существенное.

Да и какой выигрыш от текстового представления разметки и текстового же режима передачи?

Аватар пользователя bumble bumble 20 июня 2020 в 13:49

Вычислительные мощности все еще стремятся вверх. Их стоимости, с другой стороны, вниз. Потому, это все экономия на спичках уже сейчас (уже давно).

Ну, а выигрыш - очевиден:

Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. ...[Therefore,] making it easy to read makes it easier to write.

Robert C. Martin

Аватар пользователя OldWarrior OldWarrior 20 июня 2020 в 14:01

Ладно, сдаюсь: не найду я здесь апологетов и адептов. И мрачное светлое компилированно-бинарное сетевое будущее не состоится.

Аватар пользователя Semantics Semantics 20 июня 2020 в 15:24

Даёшь гипертекстовый векторный бинарный Фидонет.
Конечному юзеру (браузеру) пофиг, какими байтами реализована разметка.
Разработчикам пофиг, потому что всё равно будут какие-то компиляторы или постпроцессоры

Аватар пользователя OldWarrior OldWarrior 20 июня 2020 в 16:39

bumble wrote: Благодарю за дискуссию!

И вам поклон!

Semantics wrote: Даёшь гипертекстовый векторный бинарный Фидонет

Не, я уже не гожусь для таких дерзаний. Боюсь, времени уже не хватит Smile

Собсна, это всего лишь мои личные тараканы. Признак надвигающейся старости, видимо. А то жизнь, братцы, как-то проходит, а ты как пялился более 20 лет назад на все эти километры тегов и стилей, так и пялишься до сих пор. Пора бы уже их с глаз долой, отработали своё, что-то более компактное/удобное взамен.

Semantics wrote:... пофиг, какими байтами реализована разметка ... потому что всё равно будут какие-то компиляторы или постпроцессоры ...

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

Кстати даже старик-апач вполне может быть допущен в светлое бинарное будущее при наличии соответствующего модуля (какой-нить cml.so - Compiled Markup Language - о!).