Помните некогда популярную публикацию: «PHP: фрактал плохого дизайна»? Я, когда впервые её прочитал, работал в дурацком месте с большим количеством устаревших PHP-проектов. Она заставила меня задуматься: должен ли я уйти и заняться чем-то совершенно другим, нежели программирование.
К счастью для меня, вскоре я смог сменить место работы, и, что более важно, PHP сумел «немного» развиться со времён 5.* версий. А сегодня посредством этой статьи я хочу обратиться к людям, которые либо больше не программируют на PHP, либо застряли в устаревших проектах.
Спойлер: на сегодняшний день у PHP, как почти у каждого языка программирования, полно недостатков. Многие основные функции всё ещё имеют несогласованные сигнатуры, настройки конфигурации запутаны, всё ещё полно разработчиков, пишущих дерьмовый код, потому что в их текущем проекте по другому не получается или потому, что они не умеют иначе.
Сегодня же я хочу взглянуть на светлую сторону: давайте сосредоточимся на том, что изменилось, и на способах написания чистого и поддерживаемого PHP-кода. Я хочу попросить вас отбросить на несколько минут предрассудки.
После этого вы можете думать о PHP точно так же, как и раньше. Хотя, скорее всего, вы будете удивлены некоторым улучшениям, сделанным в PHP за последние несколько лет.
TL; DR
- PHP активно разрабатывается, каждый год выходит новый релиз
- Производительность с эры PHP 5 выросла вдвое, если не втрое
- Существует чрезвычайно активная экосистема фреймворков и библиотек
- За последние несколько лет в PHP было добавлено много новых функций, и язык продолжает развиваться
- Инструменты, подобные статическим анализаторам, за последние годы очень развились и продолжают развиваться дальше
Краткая история
Вкратце рассмотрим релизный цикл PHP. Сейчас текущая версия PHP 7.3, а версия 7.4 ожидается в конце 2019 года. PHP 8.0 будет следующей версией после 7.4. Начиная с поздней эры PHP 5.*, команда мейнтейнеров старается поддерживать ежегодный цикл релизов и в течение последних четырех лет у неё это хорошо получается.
В целом, каждый новый релиз активно поддерживается в течение двух лет и получает ещё один год «исправлений безопасности». Цель состоит в том, чтобы мотивировать разработчиков на PHP поддерживать актуальность версии: применить небольшие обновления каждый год намного проще, чем, например, перейти с 5.4 на 7.0.
Обновляемый календарь сроков поддержки разных версий PHP можно найти тут.
Наконец, PHP 5.6 был последним релизом ветки 5.*, а 7.0 являлся следующим. Если вы хотите узнать, что случилось с PHP 6, Вы можете прослушать подкаст PHP Roundtable.
Теперь давайте развенчаем некоторые распространённые заблуждения о современном PHP.
Производительность PHP
В дни версий 5.* производительность PHP была… средней, в лучшем случае. Однако в версии 7.0 значительные части ядра PHP были переписаны с нуля, что привело к увеличению производительности в два-три раза.
Но слов недостаточно. Давайте посмотрим на тесты. К счастью, другие люди потратили много времени на бенчмаркинг производительности PHP. Я считаю, что у Kinsta есть хороший обновлённый список.
Начиная с версии 7.0, производительность только увеличивается. Настолько, что веб-приложения PHP имеют сопоставимую, а в некоторых случаях лучшую производительность, чем веб-фреймворки на других языках. Взгляните на этот обширный набор тестов.
Конечно, PHP-фреймворки не будут превосходить C и Rust, но они намного лучше, чем Rails или Django, и сопоставимы с ExpressJS.
Фреймворки и экосистема
Говоря о фреймворках: PHP больше не ограничивается WordPress. Смею заявить вам как профессиональный PHP-разработчик: WordPress никоим образом не является представителем современной экосистемы.
В общем, есть два основных фреймворка веб-приложений: Symfony и Laravel. И несколько более мелких: Zend, Yii, Cake, CodeIgniter и т. д. Но если вы хотите знать, как выглядит современная PHP-разработка, хорошим выбором будет познакомиться с одним из двух крупнейших.
Оба фреймворка (Symfony и Laravel) имеют большую экосистему пакетов и продуктов. Начиная от административных панелей и CRM до автономных пакетов (в оригинале — «standalone packages»), от CI до профилировщиков, а также многочисленные сервисы, такие как серверы веб-сокетов, менеджеры очередей, интеграции платежей; честно говоря, слишком много, чтобы перечислить все.
Однако эти фреймворки предназначены для непосредственной разработки. Если вы нуждаетесь просто в управлении контентом, такие платформы, как WordPress и CraftCMS, только всё больше и больше улучшаются.
Один из способов измерить текущее состояние экосистемы PHP — посмотреть на packagist — основной репозиторий пакетов для PHP. Он экспоненциально растёт. При ~25 миллионах загрузок в день, можно справедливо сказать, что PHP-экосистема — уже не та слабая сторона, которой она являлась раньше.
Посмотрите на этот график, в котором указано количество пакетов и версий с течением времени. Его также можно найти на веб-сайте packagist.
Кроме фреймворков приложений и CMS, в последние годы мы также наблюдаем рост асинхронных фреймворков.
Это фреймворки и серверы, написанные на PHP или других языках, позволяют использовать поистине асинхронный PHP. Среди примеров: Swoole, Amp и ReactPHP.
С тех пор как мы вошли в асинхронный мир, такие вещи, как веб-сокеты и приложения с большим количеством операций ввода-вывода, стали действительно актуальными в мире PHP.
В списке рассылки internals — месте, где ведущие разработчики обсуждают развитие языка, — также говорилось о том, чтобы добавить libuv в ядро. Для тех, кто не знает libuv — это та же библиотека, которую Node.js использует для обеспечения всей её асинхронности.
Сам язык
Хотя async и await ещё недоступны, за последние годы было сделано много улучшений в самом языке. Вот далеко неполный список новых функций в PHP:
- Стрелочные функции
- Оператор объединения с null
- Трейты
- Типизированные свойства
- Оператор распаковки
- JIT компилятор
- Интерфейс внешних функций
- Анонимные классы
- Декларации возвращаемого типа
- Современная криптография
- Генераторы
- Многое другое
В то время как мы говорим о языковых особенностях, давайте также затронем тему того, как язык развивается сегодня. Существует команда мейнтейнеров-добровольцев, которые двигают язык вперёд, при этом сообщество также может предлагать RFC.
Затем эти RFC обсуждаются в списке рассылки «internals», который также можно прочитать в интернете. Прежде чем новая языковая функция будет добавлена, необходимо провести голосование. Только RFC с большинством голосов, не менее ? от всех проголосовавших, допускаются к включению в ядро.
В голосовании принимают участие около 100 человек, при этом требования голосовать на каждом RFC — нет. В группу людей, имеющих возможность голосовать, конечно, входят мейнтейнеры, т. к. они должны поддерживать кодовую базу. Помимо них, есть группа, участники которой были выбраны в индивидуальном порядке из сообщества PHP. Эта группа состоит из мейнтейнеров PHP-документации, авторов крупных PHP-проектов и выдающихся разработчиков из PHP-сообщества.
Хотя большая часть разработки происходит на добровольной основе, один из разработчиков ядра PHP, Никита Попов, недавно был нанят JetBrains для работы над языком на полный рабочий день. Другим примером является фонд Linux, который недавно решил инвестировать в Zend Framework. Подобные работы и приобретения гарантируют стабильность для будущего PHP и его развития.
Инструментарий
Помимо самого ядра, последние несколько лет мы наблюдаем увеличение инструментов вокруг него. На ум приходят статические анализаторы типа Psalm, созданный Vimeo, Phan и PHPStan.
Эти инструменты статически анализируют ваш PHP-код и сообщают о любых типовых ошибках, возможных багах и т. д. В некотором смысле, предоставляемые ими функциональные возможности можно сравнить с TypeScript (примечание переводчика: статические анализаторы расширяют возможности языка по поиску ошибок\недоработок тем самым улучшая язык, TS условно делает то же самое поверх JS), хотя на данный момент язык PHP не транспилируемый, поэтому настраиваемый синтаксис не допускается.
Несмотря на то, что при этом нам нужно полагаться на докблоки и типизацию, Расмус Лердорф, создатель PHP, упомянул идею добавления механизма статического анализа к ядру. Эта задача содержит в себе много потенциала, но по трудозатратам она огромна.
Говоря о транспилировании, стоит отметить, что были попытки расширить синтаксис PHP не на уровне ядра, а на уровне пользовательских библиотек, как это реализовано в JavaScript. Проект с именем Pre делает именно это: позволяет использовать новый синтаксис PHP, который переносится в обычный PHP-код.
Хотя такой подход зарекомендовал себя в мире JavaScript, он сможет заработать в PHP только если будет обеспечена надлежащая поддержка IDE и статического анализа. Это очень интересная идея, но она должна пройти ещё долгий путь, прежде чем её можно будет назвать «мейнстримом».
В заключение
Несмотря на всё сказанное, не стесняйтесь думать о PHP как об ужасном языке. У него определённо есть свои недостатки и 20-летнее наследие, но я могу с уверенностью заявить, что работать с ним мне нравится.
С его помощью я могу создавать надёжное, хорошо обслуживаемое и качественное программное обеспечение. Клиенты, на которых я работаю, довольны конечным результатом, как и я.
Несмотря на то, что при работе с PHP всё ещё можно написать очень плохой код, я бы сказал, что это отличный выбор для веб-разработки, если его использовать правильно.
Вы не согласны? Напишите в комменты, почему!
Комментарии (65)
AEP
14.06.2019 12:48В целом, каждый новый релиз активно поддерживается в течение двух лет и получает ещё один год «исправлений безопасности». Цель состоит в том, чтобы мотивировать разработчиков на PHP поддерживать актуальность версии: применить небольшие обновления каждый год намного проще, чем, например, перейти с 5.4 на 7.0.
Большинство пользуется ровно тем, что есть в дистрибутивах и, без достаточных на то оснований, предпочитает LTS-дистрибутивы. Без борьбы с LTS-ами этот мотивационный шаг не имеет смысла.
arkamax
14.06.2019 17:38Оба основных игрока на рынке панелей для коммерческого хостинга (cPanel и Plesk) давно и эффективно поддерживают современные версии PHP, и добавляют новые достаточно оперативно по мере их выхода. Я работаю в одном здании с cPanel и ребята в команде EasyApache очень внимательно следят за экосистемой PHP. Конечно, есть люди, которые работают на голых дистрибутивах, но при разработке коммерческих приложений де-факто приходится учитывать скорее то, какие версии PHP доступны на лидирующих хостингах. Плюс к тому, PHP 7 значительно эффективнее с точки зрения CPU и использования памяти, и для хостера это транслируется в экономию ресурсов сервера и, соответственно, затрат — т.е. имеем коммерческую мотивацию.
Gugic
14.06.2019 21:56+2Как бы 2019-й на дворе. Devops, kubernetes, докер, облака. На голом дистрибутиве работать довольно грустно.
vanxant
15.06.2019 15:39Да, ООО «Рога и копыта» для своего лендинга на вордпрессе без kubernetes ну совсем никак.
Gugic
15.06.2019 16:18-1С определенных масштабов даже лендинги на вордпрессе проще рулить через кубернетес или аналогичные решения.
vanxant
15.06.2019 16:52И у скольких компаний сайты/приложения достигли таких масштабов, чтобы им было выгодно содержать банду «рулителей кубернетесов»? 100 на всю РФ? 103?
Gugic
16.06.2019 07:121) Я не считал и в общем-то не в РФ работаю и уже давно не с PHP.
2) Вам не нужна банда рулителей, на небольших объемах рулением может заниматься и один человек (два для резервирования на случай отпусков/болезней/увольнений), причем разделяя эти обязанности с непосредственной разработкой, например. Или с администрированием.
А вот когда работал в РФ PHP-разработчиком в среднего пошиба аутсорсе (НЕ Москва, 150-200 человек всего, включая все сорта мобильных разработчиков, джавистов, сишников и прочих тестировщиков с менеджерами. PHP-команда человек 20 разработчиков, самый крупный отдел, если мне память не изменяет, таких компаний в СНГ должно быть очень много), делал полуавтоматизированную платформу быстрого деплоя PHP проектов для внутренних нужд — Q/A, демонстрация клиентам, проверка на не-девелоперском энвайроменте, обкатывание миграций при передеплое и прочее, естественно с поддержкой разных версий php. Делал руками, поверх виртуальных машин и LTS-убунты, потому что ни докера ни кубернетеса тогда еще не было (2011-й, 2012-й годы), были бы — наша жизнь была бы сильно проще.
БольшАя часть проектов, кстати, была на Drupal (не вордпресс, да, но лучше бы уж вордпресс).
Я к тому что вот это был вполне обыденный аутсорс и там эти технологии были бы применимы и полезны.
И кастомерам можно было бы отдавать готовые к работе контейнеры (сначала мы отдавали просто сорцы, потом какие-то рукодельные скрипты-инсталляторы, потом были chef/ansible/puppet/vagrant, потом я ушел, не знаю как там сейчас.
radist2s
14.06.2019 12:48+1Пара слов в защиту WordPress: существует божественный Bedrock, который как раз реализует экосистему для CMS, и существует WordPress Packagist, который является репозитарием плагинов и тем для CMS. Все ставится композером, существует прозрачная система настройки окружения, манифесты для плагинов, опять же, под разные окружения. Кароче, мир WordPress разработки уже далеко ушел от того, что представляет сам WordPress из себя, теперь это ядро системы, которое обрастает удобным интерфейсом. К слову WordPress это уже давно просто админка для нормальных парней.
Pydeg
14.06.2019 13:13-1Мне кажется, php явно идёт не туда. Это стремление конкурировать с большими языками общего назначения ничем хорошим не закончится, даже сейчас все эти амбициозные планы и реализации выглядят как ченжлоги питона 5-15 летней давности, не говоря уже о java/c#. При этом php растеряет всю свою простоту, которая и принесла ему такую популярность.
ilya_1986
14.06.2019 14:51По моему простота, которая и принесла ему такую популярность, это возможность встраивать код в html разметку, и вряд ли php ее растеряет )
NikitchenkoSergey
14.06.2019 15:14А php и не пытается конкурировать с языками общего назначения. Основная задача 7 ветки была ускорение скорости интерпретации и выполнения, с чем они успешно справились. А JIT просто немного расширит границы применимости: там где сейчас php очень сложно использовать (ML и еще какие-нибудь сложные мат. вычисления), уже можно будет попробовать.
Pydeg
14.06.2019 16:29По-моему в вашем сообщении явное противоречие. Если php не пытается конкурировать с языками общего назначения и его ниша это веб, то зачем ему расширять границы применимости и как он вдруг оказался в ML? Причем, ниша интерпретируемых языков с JIT и асинхронностью уже заняты python/node.js, которые развиваются в этом направлении уже очень много лет и чтобы догнать их, команде и сообществу php придется потратить как минимум столько же времени (для выявления и оптимизации узких мест в реализации, создания экосистемы пакетов, тулинга, адаптации существующего легаси кода и т.д.), тем самым php изначально обрекает себя быть в "догоняющих" с огромным отставанием (~10 лет?), оказываясь в очень неудобном положении.
Мне кажется, что php стоило бы дальше развиваться в направлении веб-ориентированного языка-фреймворка, на котором просто и быстро можно делать сайты, а не пытаться втиснуться в устоявшиеся ниши, не предлагая ничего нового. Это тупиковый путь, имхо.dzsysop
15.06.2019 00:02+1Большой вопрос кто куда пытается втиснуться. 10 лет назад РНР был полновластным хозяином веба. Затем в моду вошел Python и появился NodeJS (первый релиз как раз вышел 10 лет назад). Но Python постепенно растерял свою популярность как язык для разработки сайтов. А Node я бы сказал так: Javascript «сходил» на бэкенд и вернулся на фронт. Да сегодня есть команды которые влюблены в React и Angular, но мне кажется все же большинство серьезных вещей делаются с разделением на фронтэнд и бэкэнд. Где на фронте правят React || Angular а вот на бэкэнде Javascript особо не прижился и там зоопарк из Python || PHP || Java || .Net.
Я категорически не согласен сphp изначально обрекает себя быть в «догоняющих»
На бэкенде у него свои давно завоеванные огромные территории. Он изначально рожден вместе с вебом. Да он слабо применим и практически не используется как универсальный язык. С этим не буду спорить. Но в своей нише он далеко не новичок и общий посыл автора о том что РНР точно не собирается на покой я полностью поддерживаю.
Если вам нужна кроссплатформенность наверное Java. Если вы увлеклись embeded то извольте С и С++. Если вы хотите ML и AI то Python рулит сегодня. И далее по списку. Существуют вполне нишевые языки Ruby, Rust, Haskel, Go на которых написано мало (по количеству проектов), но они решают определенный тип задач лучше всего. PHP тоже нишевой язык.Pydeg
15.06.2019 01:00+1На бэкенде у него свои давно завоеванные огромные территории. Он изначально рожден вместе с вебом..
Это так, но веб, для которого используют php и веб, для которого используют python/node.js/go/etc, это во многом очень разный веб, более явно это разделение очертилось с «эпохой вебсокетов» и SPA. И обычные, «традиционные» сайты и есть ниша php, это очень большая ниша веба, которая никуда не собирается деваться. Но вместо того, чтобы дальше в этом направлении развиваться, php пытается втиснуться в нишу «асинхронного веба» с многолетним опозданием. Я не совсем понимаю зачем это делать и более того, это ведь полностью противоречит идее самого языка с «умирающими» воркерами и полной синхронностью. Перейти на такой php будет не намного проще, чем вообще сменить язык.
PHP тоже нишевой язык.
Вот я как раз за то, чтобы он таким и оставался.Rukis
15.06.2019 10:05В асинхронщину сам язык вроде как не лезет. Сторонние разработки. Основной вектор как мне кажется на добавление «строгих» возможностей, улучшение стат анализа.
JekaMas
16.06.2019 09:42Мне довелось работать в Lazada и на бэке жил php, мы отдельные куски переносили в go, но все равно доля php была 80-85%. И оно жило под нагрузкой. А миграция с 5.5 на 7.0 дала почти двухкратный рост производительности и более чем двухкратное падение потребления памяти.
VolCh
17.06.2019 11:19Как мне кажется, объяснение простое: экономически целесообразно для типовых решений иметь один язык на бэке.
scarab
16.06.2019 00:21А что такое эти ваши языки общего назначения?
В моём представлении, сейчас можно:
— писать под веб
— писать консольные линукс-приложения
— писать графические линукс-приложения
— писать под винду
— писать под ведроид и ios.
С первыми двумя кейсами php справляется вполне успешно. Ну да, питон тоже. Касательно графических приложений под линукс — это какая-то очень узкая и странная ниша. Писать на питоне и на пхп под винду и мобилки — проще выстрелить себе в ногу. Те средства, что есть, настолько костыльны, что лучше бы их не было, наверное.
Единственный реально универсальные язык, который я знаю — это Java. Но он изначально таким и задумывался, кроссплатформенным и переносимым.
Чем питон универсальнее и «общЕе» пхп? Ну вот чем?
edogs
14.06.2019 15:18+1Мы начинали с асма, потом где-то там промелькнул паскаль, бейсик, потом си и снова асм в виде включений в си.
Потом побаловались с флэшем и случайно пришли в веб на пхп. Это был еще то ли пхп2 то ли пхп3. Чем язык понравился? Простотой, возможностями в том числе стрелять себе в ногу. Чем не понравился? Малым количеством функционала и тормозами после с/асма.
Пхп4 оставил простоту и возможности стрелять в ногу, сильно расширил набор функций из коробки и сохранил совместимость. Это было круто, мы подсели на него сильно и даже сдали зендовский экзамен по приколу.
Пхп5 стал отнимать возможность стрельбы себе в ногу, откромсал часть совместимости и стал сложнее. Функционала он почти не добавил, но зато неплохо увеличилась скорость. Стали появляться яваподобные фреймворки.
Пхп7 еще больше отнял возможность стрельбы себе в ногу, откромсал уже солидную часть совместимости и стал существенно сложнее. Функционал почти не добавился, скорость увеличилась кардинально.
С одной стороны нас радует то, что скорость у пхп7 такая, что можно не смотреть на другие языки.
С другой стороны вместо прежнего echo 'hello world' на голом пхп теперь требуется установить композер, подключить автолоадер, прописать неймспейсы, использовать интерфейсы и так далее, иначе ты не модный. Вместо простого языка получилось нечто явоподобное. При этом даже с выходом минорных версий надо сидеть и думать где могла поломаться совместимость, не говоря уже о 5-тых версиях. Уже не первый раз ловим себя на том, что проект неплохо бы завернуть в докер, что бы не думать на какой из подверсий пхп у заказчика сервер, опять же лишний наворот.
Отсюда испытываем смешанные чувства, видим скорее не движение вперед, а скорее дрейф куда-то в бок с сильными и плюсами и минусами, но главное — с изменением идеологии. Не эволюция, а революция. Может быть это хорошо и мы просто жуткие консерваторы, в конце концов 20 лет с пхп это много. Но со времен пхп4 первый раз сильно хочется сменить язык.
p.s.: Це личное мнение, не обязательно правильное:)NikitchenkoSergey
14.06.2019 15:28+2использовать интерфейсы и так далее, иначе ты не модный
Разве код нужно писать по моде? Интерфейсы нужны для связи частей программы. Если Вам нужны контракты — используете интерфейсы, не нужны — не используйте.
При этом даже с выходом минорных версий надо сидеть и думать где могла поломаться совместимость, не говоря уже о 5-тых версиях.
По моему опыту ломаются какие-то неочевидные или неоднозначные выражения (которые вообще по-хорошему не надо было писать, типа $foo->$bar['baz']). Язык идет к строгости и это круто.edogs
14.06.2019 18:59Разве код нужно писать по моде?
Если весь код вокруг модный, а туда вставляется не модный кусок, то нарушается целостность подхода.
По моему опыту ломаются какие-то неочевидные или неоднозначные выражения
В пхп5 это было в бОльшей части верно, хотя уже были нюансы.
А вот в пхп7 уже достаточно неоднозначных и неочевидных изменений.
Это кажется мелочью если ведешь только свои недавно рожденные проекты и/или проекты на последних версиях современных фрейворков, при этом контроллируешь серверное окружение и никто не делает ошибок.
Язык идет к строгости и это круто.
php задумывался как язык с нестрогими возможностями. Это как купить себе трактор, а потом в ходе модификации оказаться на феррари. Все вокруг говорят круто, но это уже не трактор который хотелось.t_kanstantsin
14.06.2019 20:14+1А вот в пхп7 уже достаточно неоднозначных и неочевидных изменений.
Незадолго до релиза php7 появился репозиторий (или даже несколько), с помощью которого можно было проверить совместимость с ним. У меня в нескольких проектах было только в одном месте выражение вида
$foo->$bar['baz']), которое я исправил и успешно забыл о серьёзных различиях.
Не вижу ничего сложного. Если проект дикий легаси седых годов, то с ним в любом случае будут проблемы, даже без обновления. Тем более мажорного релиза php. Тут дело не в php:)
при этом контроллируешь серверное окружение и никто не делает ошибок
а если пишешь только на php5, то внезапно окружение стало контролируемое, а ошибки исправляются сами? Может такое относится к php4? Странная претензия.
edogs
14.06.2019 21:16+1если пишешь только на php5, то внезапно окружение стало контролируемое, а ошибки исправляются сами? Может такое относится к php4? Странная претензия.
Может и странная, но мы ее не высказывали.
У меня в нескольких проектах… Не вижу ничего сложного.
Так потому что это у Вас в своих нескольких проектах. В своих проектах у нас тоже никаких особых проблем нет, более того, изрядная их часть спокойно работает на любых 5.х-7.х версиях без поправок.
Просто мы как правило работаем с чужими проектами в том или ином виде. И если выход пхп5 не напряг почти никак, то вот после выхода пхп7 40% времени уходит на проблемы версионности.
Тут дело не в php:)
Невозможно написать код так, что бы он гарантированно не поимел проблем с новой версией, просто потому что неизвестно что она поломает. И если новая версия что-то ломает, при чем без необходимости, то достаточно странно говорить «пхп тут не при чем, это разработчики которые писали код еще до ее появления были идиоты»©t_kanstantsin
15.06.2019 11:48Странная претензия.
Может и странная, но мы ее не высказывали.Цитирую место, из которого я сделал вывод про претензию (убрал лишние рассуждения, думаю, смысл не поменялся):
А вот в пхп7 уже достаточно… изменений
Это кажется мелочью если… контроллируешь серверное окружение и никто не делает ошибок.Поэтому уточняющий вопрос: случаются ли ошибки при использовании php5? И виноват в этом php или тот, кто эти ошибки сделал? Думаю, второе. Почему с php7 виноват уже он? При обновлении ошибки прогнозируемы и легко устранимы. Если проблема в сторонних решениях — либо заменить, либо забить на обновление, либо контрибьютить совместимось — решения на любой вкус.
«пхп тут не при чем, это разработчики которые писали код еще до ее появления были идиоты»©
теперь моя очередь:) «Может и странная, но мы ее не высказывали»© Я писал о том, что переход с одной мажорной версии на другую — однозначно требует проверки и доработки. Если на них нет времени/денег — значит не надо надеяться на авось.
Просто мы как правило работаем с чужими проектами в том или ином виде
если речь про аусорс и на переход с одной версии на другую не выделялось время, то проблемы версионности — проблемы того, кто изменил версию php на сервере.
если речь про сторониие библиотеки, то я встречал только 1 библиотеку не совместимую с php7.2 phpword. Конечно, это не показатель, но как я писал выше — есть скрипты для проверки совместимости 5. -> 7. если есть какие-то проблемы, то либо пофиксить, либо забить на обновление, если проект не предполагает бюджет на это.edogs
15.06.2019 13:23Поэтому уточняющий вопрос: случаются ли ошибки при использовании php5? И виноват в этом php или тот, кто эти ошибки сделал? Думаю, второе. Почему с php7 виноват уже он? При обновлении ошибки прогнозируемы и легко устранимы
Если велосипидист после обновления велосипедной дорожки стал чаще сталкиваться с пешеходами, то виноват чисто он? Обновлятели не при чем? А если после первого обновления он стал стал сталкиваться на 10% больше, а после второго на 80% больше? То разве второе обновление не напряжнее первого? А если второе обновление на 50% состоит из того, что дорожку адаптировали к стандартам трэкинговых, а не прогулочных дорожек (как было раньше) и именно из-за этого получилось 80%, а не скажем 20%?BeppeGrillo
15.06.2019 15:14Если велосипидист после обновления велосипедной дорожки стал чаще сталкиваться с пешеходами, то виноват чисто он? Обновлятели не при чем? А если после первого обновления он стал стал сталкиваться на 10% больше, а после второго на 80% больше? То разве второе обновление не напряжнее первого
Вы забыли упомянуть что этот велосипедист смотрит не куда едет а на небо.edogs
15.06.2019 16:55Как по нам на нормальной велосипедной дорожке вполне можно посматривать в небо и нет необходимости 100% времени смотреть не врежешься ли во что-то и не изменился ли со вчерашнего дня маршрут.
EvgeniiR
14.06.2019 21:43php задумывался как язык с нестрогими возможностями. Это как купить себе трактор, а потом в ходе модификации оказаться на феррари. Все вокруг говорят круто, но это уже не трактор который хотелось.
Можете возразить, но я считаю что строгость в текущем контексте — с любой стороны хорошо(тем более она опциональна). Потому тут скорее «купить пользованую шестерку, а в ходе модификации получить приору какую-нибудь», до Феррари пока далеко )
HEKET313
15.06.2019 00:07Если весь код вокруг модный, а туда вставляется не модный кусок, то нарушается целостность подхода
Нутк вы ж не школьник, я надеюсь, чтобы следовать слепо за модой, своя же голова есть на плечах. Просто нужно возможностями языка пользоваться в соответствующих местах. Если вам нужно новую страничку или эндпоинт добавить в проект, который написан, скажем, на Symfony 4 — то да, нужно писать всё в том же стиле, что и весь остальной проект, а если нужно сделать
echo 'hello world' на голом пхп
то так и пишите.
То, что сейчас появилась куча стандартов и все стараются писать в соответствии с SOLID, то что есть прекрасный пакетный менеджер и развивающиеся фреймворки с большим комьюнити — это прекрасно. Просто нужно адекватно использовать все эти возможности и не тащить тяжёлую артиллерию туда, где она не нужна.
dzsysop
15.06.2019 00:12С другой стороны вместо прежнего echo 'hello world' на голом пхп теперь требуется
Совершенно ничего не требуется. Все работает ровно так же.
echo 'hello world';
Поменялось и стало более строгим именно там где люди пытались «городить огород» и делали это разнообразными костылями. И им постепенно сказали какими костылями можно пользоваться, а какими нельзя. А потом поотбирали костыли совсем.
Про
композер, подключить автолоадер, прописать неймспейсы, использовать интерфейсы
вам уже написали. Это новые фишки, которые вы можете игнорировать и если ваш код не требует зависимостей и вы не путаетесь в наименовании классов или вообще не используете классы, все будет работать ровно также как работало.
ilyapirogov
14.06.2019 17:06+1Конечно, PHP-фреймворки не будут превосходить C и Rust, но они намного лучше, чем Rails или Django
Очень спорное заявление. Если судить по исходникам тестов, то правильно было бы написать: "Nginx + php_fpm намного лучше чем Gunicorn на чистом Python".
Замени Gunicorn на Nginx + uWSGI или на bjoern и результаты поменяются кардинально.
DarthWazer
14.06.2019 17:35+1В статье нет ничего нового, о чем бы не упоминали регулярно в последние два года.
P.S. Но картинка шикарная. Стиль рисунка напомнил одну, в свое время популярную игру.
«Из зоопарка города Бердичева, похищен слон, необычной, полосатой породы...»
defuz
15.06.2019 04:16А нативную поддержку юникода в главный язык по веб разработке уже завезли?
SerafimArts
15.06.2019 04:56+1А она, извиняюсь, зачем? Ну хоть одну причину сможете назвать?
SerJook
15.06.2019 13:59PHP годится только для веб-разработки. Больше ни для чего.
Серьезные программные продукты никто не станет писать на PHP.
Зачем делать из PHP вторую Java, если уже есть Java? Которая с нормальной типизацией, с «настоящими» аннотациями, а не мимикрирующими под них комментариями, многопоточностью, асинхронностью. Она более логична и не раздражает программиста. Я не хочу умалять заслуги PHP в роли языка для веб-разработки, но если вы хотите иметь возможности для роста, а не застрять в «нише», для которой PHP был придуман, берите другой язык.
Ну а если хотите играть в низшей программисткой лиге и постоянно быть в роли догоняющих, выбирайте PHP.
playermet
15.06.2019 19:21+1> Зачем делать из PHP вторую Java, если уже есть Java?
Примерно затем же, зачем делать из телефона-звонилки современный смартфон, когда уже был компьютер. Новые фичи PHP не мешают старым задачам, а вполне себе даже помогают. То что они есть в других языках только доказывает их полезность.
Gemorroj
17.06.2019 08:17+2По-моему, главное что мешает перебраться пхп в боле высшую лигу, это люди с таким вот мнением, как у вас.
Т.е. проблема более идеологическая, нежели техническая.
morgot
15.06.2019 21:54Подскажите, реально ли сейчас писать на РНР в чисто процедурном стиле? Вот как лет 10 назад. Не с целью холивара, просто интересно — раньше делал небольшие странички, а теперь, как я понял, без ООП никуда. Или, все же, не так все плохо?
Wingtiger
15.06.2019 23:10я динозавр и либо использую вордпресс, либо пишу мелкие скрипты в процедурном стиле. Кстати, так получается короче, чем использовать теперь уже встроенные классы.
porn
16.06.2019 00:02+1Вообще да, но зачем? Собираетесь изобретать велосипеды? На packagist.org есть очень много хороших готовых библиотек для работы с чем угодно. А composer предлагает отличный инструмент для управления этими компонентами в вашем проекте. Впрочем, даже используя либы, которые написаны по ООП, вы можете писать своё приложение так, как вам нравится.
morgot
16.06.2019 00:16Возможно, они действительно удобно и приятно (я помню еще PEAR), но не хочется погружаться во все это… РНР (и веб в целом) не является моими основными направлениями. Моя цель — небольшие скрипты для тех или иных задач.
porn
16.06.2019 00:30Тогда для вас особо ничего не поменялось. Только вот тащить PHP для небольших скриптов… Может для этих целей лучше подойдёт python (хотя бы потому что он искаропки во многих дистрибутивах)?
worldaround
16.06.2019 01:27Я из прошлого века, вопрос: под Windows есть IDE с отладчиком, такая, чтобы установить и нормально работало, хотя бы как в Delphi версии Turbo Pascal?
morgot
16.06.2019 02:20Есть Visual Studio Code, там можно поставить расширение php и отладчик.
Правда я ее не использую, т.к. для мини-скриптов хватает нотепада и браузерной отладки.
smer44
16.06.2019 01:41Ну вот зачем архаичный язык почти такой же как и другие императивные, только со спамом $ тащить в двадцать первый век? Неужели нельзя перестать быдлокодить одни и те же низкоуровневые операции 10000 раз и сделать модуль для веб разработки, генерирующийся из модели???
playermet
16.06.2019 13:22Нельзя просто взять и выкинуть сотни миллиардов строк крутящегося прямо сейчас на серверах кода, уволить сотни тысяч программистов, взять на их место сотни тысяч новых, перекофигурировать миллионы серверов, и совершить множеству других сопуствующих действий в подобных масштабах. Это тупо дорого, долго, сложно, и не стоит полученных преимуществ. Есть возможность перевести что-то свое — переводите, никто вам не запрещает.
evgwed
18.06.2019 09:25Но если вы хотите знать, как выглядит современная PHP-разработка, хорошим выбором будет познакомиться с одним из двух крупнейших.
Можно также упомянуть, что Symfony очень похож на Spring Framework из java со своей ORM Doctrine, которая является аналогом Hibernate.
А Laravel аналог Ruby On Rails с Active Record для работы с бд.
thecoder
18.06.2019 13:52Очень люблю PHP, даже несмотря на все проблемы и косяки, но после 12 лет плотной работы перешел на Go, перевел основные проекты и сейчас понимаю, насколько все было сложно и тяжеловесно. После перехода на микросервисы как-то пропал драйв писать новое на PHP. Реально не для холивара коммент, но просто вдумайтесь, без всяких оптимизаций и кешей, приложение с бизнес-логикой и селектами из базы дает отклик 3-5 мс. Можно так раскочегарить PHP? А если еще на Laravel или Zend? На Go это происходит без малейшего напряга, сохраняя объектную декомпозицию и слабую связность.
На чем вообще поднялся PHP? В 2001, задолго до эпохи VDS, были ровно две альтернативы: perl и с/с++. Причем доступен только shared-хостинг для средней компании. Допустим, если хостинг с perl еще можно было найти, то со своими экзешничками мало где можно было захоститься, если у вас нет своего сервера. И тут возникает нечто, похожее по синтаксису на C, да еще и классы/объекты какие-никакие и можно недорого "скриптик в интернете" сделать. Причем я сразу начинал на ООП писать, а народ крутил пальцем у виска, типа выпендривайся в своем С++ с объектами. Со временем как-то дозрела отрасль и до объектов :)
Сейчас ситуация принципиально иная. Есть недорого хостинг с шелом и возможностью компиляции. Казалось бы, можно и на С/С++, но есть специальный вариант компилируемого С для веба, с интерфейсами/инкапсуляцией и огромным набором библиотек (Golang). Причем понятие фреймворка в принципе чужеродно и не приветствуется. Пакеты(библиотеки) с юниксовым подходом "одну функцию делать хорошо" и возможностью совмещать несовместимое, лишь бы набор методов/аргументов совпал. В PHP, к сожалению, нужно чтобы об интерфейсах имели представление все клиенты библиотек.
Делаешь в проекте россыпь пакетов, в одном из которых сервер, отдельно cli-утилиты, отдельно общие части для повторного использования. И все это со скоростью нативного кода, как будто модуль для nginx написал.
Куча кода PHP на поддержке осталась и если ничего не делать, через пару лет это перестанет работать после обновлений (приходится следить за языком, за нюансами конфига, за поддерживаемыми модулями), в то время как экзешнику без зависимостей пофиг. У меня есть микросервис-долгожитель, написанный на Go за два дня, кропает картинки, работает полтора года без перезапуска, сколько аптайм сервера. И память пока не сожрал.
Изучать ли PHP, инвестировать ли время, писать ли новый проект — гораздо сложнее ответить на этот вопрос сейчас, чем в нулевых. Вроде и ништяков много в языке, но и альтернативы интересные появились.
vav180480
1) Я всегда думал что это CMS ну да ладно…
2) В 2018 «фремворки» PHP ограничивались WordPress, а в 2019 все резко изменилось?
Andchir
Можно долго словоблудить что является фреймворком, а что нет, но, думаю, в данном предложении имелось ввиду, что появились достойные фреймворки, которые пришли на смену низкокачественным поделкам с плохой архитектурой.
mapron
Это очень оптимистично, про «пришли на смену.» Во-первых, Symfony и Laravel не в 2019 году появились, во-вторых, Wordpress сдавать позиции не собирается. 60% или сколько там?
BruAPAHE
не позорься пожалуйста
vav180480
Вы что все на вордпресе сидите?:)