Как стать автором
Обновить

Комментарии 145

да, но нет.
в php есть асинхронность, многопоточность, довольно удобная (на мой взгляд) работа с бинарщиной, голые сокеты и куча самых разнообразных вещей. а какое-то время назад вполне себе здравствовали обертки для gtk и qt, народ даже окошечки рисовал из php (сейчас можно обойтись без биндинг библиотек и дергать через ffi)
и даже свой аналог async-await есть.


и статья немного выглядит как "какой такой Tcp Listener? в похапэ я просто писал <?= 'Hello '. $world ?> и буквы сами попадали в браузер" — нет, то что вы не сталкивались с чем-то в php нисколько не показатель что там этого нет или что на нем нельзя так писать.


а сахара вон в 8ке насыпали, но сахар то всего лишь абстракция, которая позволяет впихнуть больше смысла в меньше строк, а не сделать магию.

ReactPHP и pThreads всякие это скорее то, что есть, но этим пользуются люди с особым вкусом. Меня аж целый раз спросили во время собеседования умею ли я в многопоточность в пхп, я в голове то в этот момент не сумел в неё, а они про пхп. Это все там не нужно. А окошечки и подавно.
нисколько не показатель что там этого нет или что на нем нельзя так писать.

Можно же, но не надо, пожалуйста.
pthreads старое не стабильное. Сейчас кажется пользуются www.php.net/manual/ru/book.parallel.php

ReactPHP неплох, но лично я предпочёл мигрировать на amphp.

Знаете, в те времена, когда начал программировать я, "плохим" первым языком считался бейсик, и люди у которых первым языком был паскаль, си или ассемблер очень сочувствовали тем, кто начинал с бейсика… считалось, что это будет мешает им стать хорошими программистами. Доля правды в этом, конечно, была, но по моим наблюдениям те, кто начинал с бейсика, просто разделились на две группы — одна с незначительными сложностями осилила си/паскаль и стала профессионально программировать, а вторая переключилась на разные варианты простых/специализированных языков — от уже непомню чего-то там для работы с БД времён DOS (Clipper?) до макросов в офисе и позднее 1C.


Мне лично учить PHP в своё время помешала сильная неконсистентность языка — как только увидел в начале изучения кучи стандартных функций с похожими названиями и делающие примерно одно и то же, но при этом принимающие примерно одни и те же параметры в совершенно разном порядке — так сразу с изучением и закончил. Чуть позже вышла та известная статья про "фрактал плохого дизайна", которая полностью описывала моё собственное впечатление, чем подтвердила что это просто "не мой" язык.


Я это к тому, что, да, плохих инструментов (почти) не бывает, и практически любому найдётся своё применение. И да, PHP за последние годы сильно развивался. И сильных разработчиков на PHP хватает. Но люди все разные, вкусы у них разные, и языки программирования тоже каждому подходят разные. И вот тем, для кого PHP попал в категорию "мой язык", осваивать другие современные языки действительно может быть сложнее. С другой стороны, PHP вряд ли грозит участь бейсика, так что им ничего не мешает и дальше писать на языке, который им нравится, и вполне эффективно решать проблемы бизнеса.


Можно ли считать "плохим программистом" того, кто вполне успешно решает проблемы бизнеса, но с точки зрения кого-то другого не знает чего-то такого, что "должны знать все хорошие программисты"? Лично я бы об этом вообще не парился, каждому своё. Для кого-то и я, со всем своим опытом, статьями и кучей опенсорсных проектов, выгляжу недостаточно образованным и не очень-то квалифицированным. Это — просто чужое мнение, не стоит уделять ему слишком много внимания. Лучше просто заниматься тем, чем нравится и писать на том языке, который нравится.

Я начинал с Бейсика :) Потом был Clipper, FoxPRO. Потом Perl. И потом уже C/C++, начиная с Borland c++ Builder. В конечном счете ушел на Си в микроконтроллерах. Одно время была Java в мобильных разработках (еще под телефоны, а не смартфоны).
Не считаю себя хорошим программистом, но встающий задачи решаю и зарабатываю себе этим на хлеб :)

Начинал с бейсика на спектруме, помню в школе от нечего делать в тетради написал игру "танчики", ничего при этом не зная про функции — вся логика в одном большом цикле для игры, подциклах для танчиков и снарядов, "рендеру" (PRINT строк из массива) и кучке GOTO.
ЧСХ игра заработала практически сразу после вбивания в спектрум.


Потом появились игровые консоли, где нельзя было программировать, и я забросил программирование лет на 20, если не считать одной попытки прочитать "выучи С++ за 21 день", где я здался на 4-й день, и пары маленьких программ на Visual Basic уровня "калькулятор".


И вот в 33 годика я остался без работы, вокруг все "входят в Айти" и приятель подкинул книжку "Python для сисадминов".
Через полгода первая работа, с которой выгнали с диагнозом "медленно учится", но где я за месяц выучил BASH.
Потом вторая — израильский "стартап" с одним продуктом на JS, который тоже пришлось по быстрому выучить.
И так вот спустя несколько лет я с удивлением замечаю, что за сезон спроектировал и написал асинхронный сервер для IoT устройств, API для управления этими устройствами, подключил к этому API существующий Web-клиент (внедряя в него патчи в процессе), все это наладил и запускаю + написана кучу документации и все это еще и работает.


Не считаю себя "отличным" программистом, а вот хорошим и решающим задачи бизнеса — вполне.

Начинал с бейсика на спектруме

Я на ДВК-2М, когда о Спектрумах в наших краях никто еще и не слышал :)
Я начинал ан ПК Агат-7. Там в бейсик можно было вставлять коды ассемблера.
Начинал с бейсика и пишу на PHP. Все, комбо, «вон из профессии» :-)

А вообще, ИМХО, все это «кто на каком языке» — ерунда по большей части, главное — понимание парадигм и принципов, а они к языку относятся поскольку-постольку

Ну тот php что был лет 10-15 назад и текущий php это немного разные вещи.
Теперь тут есть и асинхронность и многопоточность.
Плюс очень много интересных новых инструментов (привет roadrunner и тп)
Так что возможно перейти/выучить другие языки будет трудно (тут не берусь судить) но когда все есть что написал выше… а стоит ли учить/переходить? )))

Теперь тут есть и асинхронность и многопоточность.

Ну как есть… Формально да, можно. На практике так практически никогда не пишут. Впрочем оно и не нужно.
Проблема когда мы пытаемся погрузиться в парадигму нового языка не до конца выйдя из парадигмы старого. Сначала ловим кучу негатива от того, что какие-то простые вещи в пару строк кода на старом языке на новом приходится делать через пень-колоду. Но по мере погружения в контекст нового языка это будет проходить. Для каких-то задач вы найдёте удобные инструменты, про которые пока не знаете, каких-то вещи будете делать слегла по-другому (например, формировать json-api таким образом, чтобы его можно было разобрать со строгой типизацией), а каких-то вещей просто будете избегать. И со временем даже забудете что можно писать по-другому.

Пока вы находитесь на этапе «сперва формирую фразу на русском, затем в уме перевожу её на английский, затем произношу» — будут сложности. Когда вы перейдёте на этап «сразу формулирую и произношу на английском» — сложностей не будет, а о каких-то вещах из мира PHP вы вообще возможно будете вспоминать с содроганием.

Ну и есть масса задач, для которых лучше всего подходит как раз PHP. Если задачи такие, то может и нет смысла переходить на что-то ещё?

Как минимум, если ты не можешь с одинаковым профессионализмом решить задачу на двух языках, то сказать какой подходит лучше, сложно. Я вот про какие-то задачи могу сказать "я решу её на PHP за пару часов, ещё пара часов на пайплайны, мониторинги и т.п… А на Java… Ну не знаю, месяц может, хотя вроде Spring похож на Symfony, а Hibernate на Doctrine — 2 недели, из которых одна уйдёт на доведение до production ready примера hello world для веба на Java, а вторая на поиски аналогий.


Но это не будет best practice Java, это будут перенесенные с PHP практики. Типа контроллер должен принимать реквест и возвращать респонс, в себе дергать метод сервиса приложения, можно аннотациями/конфигами/миддлварами прикрутить декораторы, уменьшающие количество http бойлерплейта и т. п. Может оно и в java применимо, вот на 99% уверен, что открывать соединение к базе, редису (если он нужен в java везде там, где нужен в php) на каждый http запрос так себе идея. И это только то что знаю, по слухам...


А проффи на java сделает это если не быстрее меня на php, то, например, эффективней в плане технических метрик работы в продакшене, какие-никакие гарантии типобезопасности в компайлтайме и т. д. Да и в принципе большее число людей смогут это решение поддерживать с минимальным погружением в стэк задачи: спринговиков, имхо, больше на рынке чем симфонистов за плюс-минус те же деньги.

Да, но это так поначалу. При переходе на новую технологию часть знаний приходится выбрасывать, а часть знаний будут скорее мешать, чем помогать. Но через какое-то время работы в среде Java+Spring+Hibernate, особенно если работать в команде, нужные практики придут. Да, это порог, который нужно преодолеть, но не такой большой порог, как если бы нужно было изучать что такое фреймворки и ORM с нуля. И да, всё равно будут вещи, которые профи на PHP напишет проще и быстрее, чем такой же по квалификации профи на Java. И наоборот.

Я к тому, что чтобы самому по задаче понять, что лучше подходит для решения надо на достаточном высоком уровне знать несколько стэков. Не, если надо написать IDE, я не буду писать её на PHP. А вот если веб-приложение: я могу навскидку оценить трудоёмкость на PHP, какие мощности под задачу надо при планируемой нагрузке, что ms sql server не стоит выбирать как базу для php приложения под Linux и т. п. С nodejs и typescript есть опыт коммерческий в проде. Ну и всё из актуального. Так-то за последние лет 10 на многих языках писал, включая ту же Java, но это не были полноценные проекты, так поддержка легаси или плагинчик/коннектор какой-написать для соединения с тем же PHP или нодой.

Плохой программист != программист на PHP.
Просто из-за кучи шуток, почему-то у людей часто возникает такая ассоциация.
Я вот тоже пишу на PHP уже 15 лет, начинал с Перла.
Потом JS, Android.
До сих пор ваяю свою CMS-ку, которую еще в универе начал накидывать на PHP.

Плохой программист — это тот, который не вникая в суть, хочет со стековерфлоу стянуть кусок кода и потом там же накидать ошибок от того, что этот код не выполнился.

В PHP сейчас столько интересного и вкусного внедрили, что хватает на все задумки веб-программиста с головой. А если брать популярные компоненты от Laravel, например, и ковырять их изнутри, то можно такие чудеса творить!

Пишем свой код, читаем книжки, читаем чужой код, ломаем чужой код, фиксим чужой код — делаем это постоянно и не будет возникать вопросов «плохой ли я программист», просто времени на это не будет )

Kmx.ru, wen.ru — знакомые сайты? Сейчас, уже, наверное и закрыты уже.


Да, я тоже начинал со школы делать WAP сайты, лет с 14 имел с мобилки список сайтов-конструкторов, было интересно.


PHP всегда был для меня чем-то крутым, это уже не HTML какой-то. Но освоить было то тяжело, то лень.


В 2009 примерно начал программировать на PHP, потом с БД и т.д. Дальше больше.
Заработок был мелкий и нестабильный, фриланс конкуренция высокая.


В 2013 нашёл себе работу инженера техподдержки, с тех пор перестал программировать. Работа намного примитивнее, но высокооплаяиваемая.


После 5 лет работы ушёл с этой работы, решил вернуться в PHP.


Последнее, что помню, это версия PHP 5.2 Sta bil & 5.3 Beta. Захожу в интернет, а там уже php 7, причём параллельно ветке 5.x. Ой, как себя динозавром почувствовал.


Хотел бы вернуться в программисты, писать свои миры, быть вольным художником. Но тяжко, всё так вперёд ушло.
Да и зрение подводит. :)

wen.ru работает до сих пор) Я в свое время там баловался с телефона. Более того там даже живет wml версия wen.ru/wml не сайт, а музейный экспонат, но сам конструктор закрыт example.wen.ru
Тоже начинал с веника, но потом надоело копипастить, попробовал в перл, но с с пхп оказалось попроще, так же учил на телефоне и писал на h2m свой сайтик, по тихому прочитал с десяток книжек, по наступал на грабли в своих велосипедах, начитался про фрэймворки, паттерны, и прочее, следил за новым в php, но так как хобби дальше и не пошло, но например в архитектуре даже в той же яве вижу косяки, вижу как упростить или сократить, просто наверное не нужно, потому дальше и не пошел, а многое зная в одном языке помогает в других
Да, первый сайт был на ковчеге, а второй на h2m.ru уже с PHP, по-взрослому)

Знаете, когда я ради интереса сделал за нее небольшое домашнее задание, первым вопросом преподавателя было "что за phpшник это писал?"


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

Там был Свифт, но код был написан в стиле php.

Не знал что у PHP есть стиль :)
Вордпресс и Симфони оба php, но между ними пропасть.
в стиле php

Это как?

Можно пример того как написано на php, а как должно на свифт (или другом языке)?

Раньше PHP выделяли глобальные переменные и функциональный подход, сейчас начиная с 7-й версии вполне полноценный ООП язык.
Не соглашусь с градацией «начиная с 7-й версии». Что именно добавили в 7ке, чтобы начать называть его полноценным ООП?

На мой взгляд PHP стал полноценным ООП с выходом PHP 5.

Кроме того, считаю PHP4 так же ООП-языком (но не полноценным), функциональный подход там не был сильно распространён.

Мне кажется, вы путаете функциональное программирование с процедурным, их часто смешивают, как Яву и Яваскрипт.
Функциональный подход стал возможен частично в 5 версии, но в любом случае а практике применяется довольно редко.
РНР является по сути процедурным языком с возможностью использования ООП и функционального программирования.

Продолжу не соглашаться. Языковые конструкции предлагаемые PHP4 (более ранние версии помню достаточно плохо) уже позволяли использовать как функциональное, так и процедурное программирование.

Функциональное и процедурное программирование — это больше про стиль написания кода. Нет проблемы написать процедурную программу на функциональном языке.

И вы очень резко поменяли тему. Речь шла про ООП. Чтобы язык считать ООП-полноценным — в нём должны быть определенные языковые конструкции, позволяющие полноценно использовать парадигмы ООП.

PS: Кажется за отсутствием аргументов в ход пошли минусы :-)

Не, функциональное программирование — это совсем же не про стиль, а скорее про состояние. И четвёрка не позволяла писать декларативно. Ну или я чего-то совсем не помню.


Если считать парадигмами ООП инкапсуляцию, наследование и полиморфизм, то да — РНР в 4 версии реализовывал их, не могу спорить.
Другое дело что сама реализация сильно оставляла желать лучшего — проблемы с производительностью, которые были решены в cемёрке, плюс отсутствие неймспесов и автолоада, прямо скажем, сильно затрудняли построение мало-мальски сложных структур и использование сторонних библиотек.


Так что предлагаю сойтись на формулировке что юзабельным ООП стал в РНР ближе к 7 версии.

В контексте сравнения функционального и процедурного программирования — это про стиль. Декларативное и императивное программирование — это вообще отдельно, касается ООП и функциональщины в равной степени.

4-ка не даёт все три парадигмы. Они недостижимы без области видимости переменных и методов, которых в PHP4 не было. Поэтому я и ссылаюсь на PHP5, как на полноценное ООП.

Неймспейпы — это так же PHP 5 (конкретно PHP 5.3). Вообще там до 5.6 было много клёвых изменений.

А вот проблемы производительности к ООП отношения не имеют. Это всегда было фичей языка :-) Функциональщина тоже тормозила и в PHP7 так же ускорилась.
В контексте сравнения функционального и процедурного программирования — это про стиль.
т.е. в ходе сравнения двух парадигм, вы пришли к выводу, что отличие только в стиле? Или как это понимать?
Декларативное и императивное программирование — это вообще отдельно, касается ООП и функциональщины в равной степени.
ФП это декларативная парадигма программирования, ООП — императивная. Как видите, далеко не «в равной степени».
И ООП гораздо ближе к процедурному подходу, чем ФП.
4-ка не даёт все три парадигмы. Они недостижимы без области видимости переменных и методов, которых в PHP4 не было

Сокрытие не необходимо для полноценности ООП, только инкапсуляция, а она была.

Функциональный подход стал возможен частично в 5 версии

В 3-ей уже можно было выбирать между функциональным подходом и процедурным местами: передача функций/параметром переменной и её вызов были, array_reduce и ко тоже были.

С 5.3 )

Мне достался на допилку в своё время андроид проект, в котором после нажатия на какой-нибудь UI-элемент (кнопочку/итем в списке и тд) идентификаторы и параметры сериализовались в строку и записывались в невидимый EditText, после этого вызывалась функция, которая доставала строку из этого эдиттекста, десериализовала и проводила дальнейшие операции…
Спакуха, я бросил тоже после 10 лет ПХП

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

в новых RFC обещают дженерики

Это в каких, например?

Писали об этом давно на Хабре, сейчас уже не найду пост, но вот ссылка на драфт в RFC wiki.php.net/rfc/generics

Не новый и в черновике = ничего не обещал никто.

Суть статьи: "программировал 10 лет на языке %language_name% и не очень хорошо разбираюсь в других технологиях"


Причем тут PHP?

Поддерживаю обоими руками!!!
Проблема не в языке, проблема в людях. Если за 10 лет так и не понял принципы работы ЭВМ, то это не проблема языка.
Не соглашусь. Скажите, какой процент людей, работающих на PHP многие годы углубленно знают про управление памятью, как работает процессор или почему для майнинга лучше подходит GPU? Это будут единицы, которые работали/работают на специфических проектах. PHP в повседневной работе абсолютно не требует этих знаний, оставляя это как «домашнюю работу», которую многие не делают.

Знаете, однажды к нам пришел на собеседование парень, который начинал с какого-то фреймворка, и все время на нем и работал. Так вот он знал только в теории, как без ORM получить данные из БД, а оптимизация запросов для него была темным лесом.

P.S. в большинстве случаев для того, чтобы понимать и разбираться в чем-то еще — необходимо иметь постоянные пет-проекты или хотяб просто задачи, отвлеченные от своей основной деятельности. Однако, как показывает практика, очень многие разработчики не делают ничего кроме тасок в JIRA.
Скажите, какой процент людей, работающих на PHP многие годы углубленно знают про управление памятью, как работает процессор или почему для майнинга лучше подходит GPU?

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


Какой процент людей, которые "майнят на GPU", знают хоть что-либо из веб-разработки?
¯\_(ツ)_/¯


в большинстве случаев для того, чтобы понимать и разбираться в чем-то еще — необходимо иметь постоянные пет-проекты или хотяб просто задачи, отвлеченные от своей основной деятельности

Холиварно, но в общем случае не правда. Есть куча людей, которые делают на 10/10 свою работу с 9 до 6, а потом проводят время со своей семьей и за хобби и не имеют пет-проектов.

Отвечу только на последний абзац: хорошо, когда у тебя работа не состоит из ежедневного клепания сайтов «на скорость» (а это — львиная часть аутсорс-компаний)

Это будут единицы, которые работали/работают на специфических проектах

Или которые прошли путь типа:


  • BASIC+ASM
  • ASM
  • C
  • Pascal/Delphy
  • Visual C++
  • PHP последние 20 лет
Ну а, скажем, на JS, который нынче считается хорошим и прогрессивным (не то что этот ваш PHP) — это не так, все поголовно специалисты по низкоуровневой архитектуре?

Кроме того, большая часть знаний про «управление памятью, как работает процессор или почему для майнинга лучше подходит GPU» для веб-разработчика, в общем-то, бесполезна. Там вместо этого полно своих заморочек… В плане «понимать и разбираться в чем-то еще» ему гораздо полезнее API браузеров, настройка сервера, криптография, сетевые протоколы, языки разметки, API сторонних сервисов и тд и тп. Причем среди «тасок в JIRA» все это — далеко не редкость

Как раз про это и говорил, что проблема в людях, а не в языке!
Многие ведь как, когда наслушаются как все круто в другом языке, особенно когда вокруг него много хайпа (Допустим в Java и C# отсутствует множественная наследовательность и сделали это намеренно т.к. с ней много проблем, но она есть в Python вокруг которого много хайпа, в итоге у Дмитрия Стогова спросили «когда будет в PHP множественная наследованность?», на что он четко ответил «Никогда» (слава богу)) столкнувшись с какой то не стандартной задачей начинают думать о другом ЯП.
Пример из жизни — был как то на собеседовании, не помню точный вопрос, но вспомнил про yield и начал рассказывать про генераторы, на что собеседующий сказал «мы сейчас говорим о PHP, а не о Python»! Как Вы думаете, какая была моя реакция и кого винить за незнание ЯП, сам ЯП или человека? Напомню, генераторы появились еще в PHP 5.
Вот и говорю, проблема не в языке, проблема в людях. И людей которые знают только то, с чем работают очень много и не только в PHP, но не надо за это винить ЯП.

А какие есть практические задачи для генераторов на PHP при работе с php-fpm. Так-то я знаю, что они есть в PHP, но зачем не очень понятно. Разве что промисы попробовать реализовать как в JS

Промисы уже есть — amphp, recoilphp.

Можно и без промисов. Простой пример — делаем запрос в базу, получаем N (для примера возьмём большой N) строк, которые превращаем в ActiveRecord (чтобы явно понять плюс от генераторов) и итерируем через генератор.

Можно и без генератора, менее эффективно и зачем?

А итераторы эту проблему не решат? Даже название намекает :)


P.S. Вот мне видится, что генераторы полезны прежде всего для асинхронщины, но без async pdo это только для каких-то очень специфических задач, для которых может лучше было бы выбрать Go или Node.

Бинго! Генератор — это специальный тип итератора, позволяющий реализовать итератор намного проще. Кроме того он имеет свои фишки (send, yield from, корутины).

Одноразовый итератор, забыли сказать, без rewind

Если итерация уже начата, то выбрасывает исключение.
В PDO есть async. Кроме того вам не нужен PDO — можете взять любую асинхронную библиотеку и использовать. У Go или Node нет сильно больших преимуществ перед PHP, кроме слегка большего комьюнити в области асинхронного программирования. Я пишу асинхронщину на PHP — я точно знаю о чём речь =)
В PDO есть async.

А можно ссылочку? Я только про async mysql знаю...


Кроме того вам не нужен PDO — можете взять любую асинхронную библиотеку и использовать.

Я-то могу взять, а вот Doctrine, например, или Eloquent не может.


У Go или Node нет сильно больших преимуществ перед PHP

Нормальная асинхронщина у них из коробки, да и вообще экосистема (либы, фреймворки, тулинг)...


кроме слегка большего комьюнити

Интересно, почему? :)

Виноват, в PDO нет async. Я наврал. Скорее всего у меня сложилось такое впечатление из-за того, что видел async в pgsql (pg_send_execute) и mysql (mysqli_multi_query).

С Doctrine и Eloquent не работал, у меня другой стек. Если речь про собрать запрос, отправить в базу, результаты сложить в ActiveRecord — то любой адекватный фреймворк легко расширяется для этого.

Обычно популярные реализации ActiveRecord сами собирают и отправляет запросы и под капотом использует PDO

Не сами, а через прослойку типа DAO. Отправка так же через отдельный класс представляющий из себя соединение с базой (который и нужно заменить + слегка подшаманить интеграцию под асинхрон). Если ActiveRecord сам собирает и отправляет запросы, то кажется у нас проблема с архитектурой.

Может и через прослойку, но сильно на неё завязан. И, главное, клиентский код о прослойке ничего не знает, он вызывает ORM как-то вроде $activeUserRecords = User:where('isActive', true)->all();

Да и это нормально расширяется.

Подменяется только класс Connection. QueryBuilder и ActiveRecord с которыми пользователь работает — остаются прежними.

А вот all() — это уже из Connection (или из ResultSet, если разработчик сильно любит дробить классы). И это синхронная операция, если мы хотим писать асинхронный код — пользователю нужно делать иначе (асинхронно итерировать или явно выбирать момент, когда этот all требуется).

Обычно all() это из BaseRecord типа


$result = new Collection();
foreach ($connection->execute($this->builder->getSQL()) as $row) {
  $result[] = new static($row);
}
Значит расширяйте, сделать ExtendedBaseRecord в котором определить all.

Синхронную логику нужно заменить, без вариантов. Либо использовать асинхронные фреймворки сразу и не пытаться натянуть сову на глобус (хотя оно и не трудно).

Либо оставить синхронную, а асинхронную реализовать параллельно.

По сути, значит, свой асинхронный форк фреймворка/либы сделать...

Да, это нормально. Или взять готовое. Если взять синхронную библиотеку на Go — то будет ровно тоже самое.

В сторону готового я смотрел немного, но там готовые не асинк версии нужного мне, а полностью другие продукты. И, да, аналогов Doctrine (DataMapper, а не ActiveRecord) не встречалось.


С Go имхо повыше шансы, что произвольная либа работы с БД, очередями, файлами и т. п. поддерживает асинк из коробки :)

Первое что приходит в голову, это обработка больших объемов данных, на собеседовании кажется об этом речь и шла, допустим необходимо обработать большую (по объему) таблицу БД имея маленький доступный объем оперативной памяти.
Но я даже не об этом, а о том, что кто то даже не знает что есть в пыхе и плохо понимает что на самом деле в этом языке не так, восхищаясь другими языками не зная что и там есть проблемы.
Возможно я плохо расписал суть проблемы, у меня не так много опыта написания статей, но речь все таки о том, что PHP — слишком прост, и позволяет слишком многое.
С одной стороны — это как читать 10 лет бульварные романы, а затем попробовать открыть Кафку.
С другой — язык не учит сложным вещам, мы не задумываемся об очень многих процессах во время написания кода.

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

В ваших терминах это как уметь писать книги и 10 лет писать бульварные романы, вместо того, чтоб написать "Кафку". Буквы одни и те же, вопрос в том, как вы их применяете. То есть это ваш выбор и ваша проблема, а не языка.


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

Чем это плохо? Ну, разрабатывайте веб на С, думайте о сложных вещах. При чем тут PHP?

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

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

В экосистеме PHP есть много программніх способов ограничить неоднозначніе, скажем так, возможности. Нужно только хотеть внедрить их на своём проекте или сменить проект, если внедрять нельзя или нет желания заниматься именно внедрение.

Аналогия с романами и Кафкой для подтверждения ущербности языка на мой вкус — очень неудачная. Написано-то и то и другое на одном и том же языке. А архитектура и стиль рулят, да…
На Php надо знать много фреймворков для устройства на работу? Если сравнивать с java.Я имею ввиду, вот на java надо 1-java core, 2-spring, 3-spring boot, 4-spring security, 5-jsp, 6-hibernate, 7-sql, 8-postgre,9-rest,10-soap, 11-junit, 12-maven,13- git. И не всегда обязательные kafka, и т.д. И все это надо в голове поддерживать до «актуальных» версий. В мире php меньше в голове надо поддерживать инфы, или больше? Просто от обилия фреймворков уже поднадаедает.
Там несколько основных, но требуют обычно один. А вообще, фреймворки это приходящее, если есть основа, то любой осваивается за месяц.
Там несколько основных, но требуют обычно один.

Один — это хорошо. Но как его звать?
А вообще, фреймворки это приходящее, если есть основа, то любой осваивается за месяц

Это да. Но главное чтобы их(фреймворков) не было много.
Один — это хорошо. Но как его звать?

Как вам нравится, так и будут звать. В чём проблема искать работодателя по фреймворку? Обычно прямо в вакансии пишут.
Это да. Но главное чтобы их(фреймворков) не было много.

Если они осваиваются быстро, то какая разница?
А так из крупных и активных я могу назвать штук 5, не больше.
И кстати часть перечисленных вами позиций к Java отношение не имеет, например git сейчас требуют все адекватные работодатели вне зависимости от языка.

Зависит от ожиданий. Если что-то серьёзное, то требуется понимание ООП плюс базовое понимание ORM и связанных с ним проблем. Просто потому все распространенные РНР фреймфорки — это всего лишь веб-интерфейсы: принять запрос клиента и передать в собственно твоё приложение. Ну и плюс кучка библиотек — тот же ORM, логгер, отправка емейлов. Nо есть работа с фреймворком составляет процентов 10 всего приложения. Самым правильным считается Симфони.


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

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

П.С. eloquent я защищать не буду. Благо при желании его можно не использовать.
Уже не первый раз слышу и читаю вот этот «факад». Что за факад? Откуда факад? Почему не фасад?
Привычка. Примерно как нотификации, а не уводомления.

facade

Это если вы английский знаете, слово хотя бы в пассивном словаре, транскрипции смотрите и что-то в них понимаете. Я вот, навскиду, никак не запомню notice — "нотис" или "нотайс", event — "евент" или "ивент", да даже error — "еррор" или "иррор"? Английский начал учить одновременно с программированием и единственным "учебником" английского было два карманных словаря. Школьный и институтский английский потом чуть-чуть поправил русскую ИТ-терминологию, notice уже не "нотице".

Так и есть. У меня "ретурн" был лет 10, пока английский был на уровне чтения документации. Когда говорить научился, понемногу исправился.

У меня ещё иногда срабатывает переключение контекстов — на русском скажу или напишу "ретурн", на английском "ретёрн"

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

Вот с "саве" повезло: расшифровку SOS мне кто-то озвучил, наверное когда радиотехникой начал интересоваться — о программировании чуть позже узнал.

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

Например у нас в вакансии указано два фреймворка — Yii2 и amphp, но для устройства к нам на работу не требуется знать ни одного. У нас больше ожиданий про опыт работы с фреймворками в принципе (перейти с одного на другой — никогда не проблема), и понимание работы языка в целом, знание современных версий PHP, обязательным плюсом знания в смежных областях.
Всем спасибо за ответ. Теперь я понял, что в целом на php легче чем на java.

По-моему, перечислены просто общие web штуки, которые присутствуют (в том или ином виде) в любом web языке.


1-java core = php и его расширения
2-spring = symfony / laravel / yii / мб что-то ещё
3-spring boot — из описания похоже на какой-то универсальный скелетон с фреймворком
4-spring security = просто компонент от симфони или другого фреймворка, возможно есть сторонние — не пользовался
5-jsp = любой шаблонизатор или просто голый php
6-hibernate = doctrine / другой движок внутри отдельного фреймворка
7-sql = sql
8-postgre = postgre / mysql
9-rest = rest
10-soap — лично мне не приходилось работать с этим, но должны быть библиотеки для этого
11-junit = phpunit
12-maven = composer
13-git = git

10-soap — лично мне не приходилось работать с этим, но должны быть библиотеки для этого

Стандартная библиотека PHP — https://www.php.net/manual/en/book.soap.php Не самая удобная в работе, есть обёртки над ней и альтернативные реализации.

«7-sql, 8-postgre, 9-rest, 10-soap, 13- git, 11-junit (насколько понял аналог phpunit)»
Причем тут фреймворк и java?
Все эти технологие, ну или добрую половину из них серьезные компании (50+ человек) спрашивают с джунов при приеме на работу. Намешали в кучу лиш бы было…

По поводу фреймворков их три основных, прилично разных между собой: Symfony, Laravel, Yii. Есть еще куча мелких/старых/забытых и куча CMS, но это совсем другая история…
«7-sql, 8-postgre, 9-rest, 10-soap, 13- git, 11-junit (насколько понял аналог phpunit)»
Причем тут фреймворк и java?

Абсолютно не причем.

По опыту работы c разработчиками как админ/девопс и отзывам коллег, собеседуюших программистов, есть такая корреляция, что сегодня php программисты гораздо сообразительнее и имеют более широкий кругозор, чем фронтенд программисты на node.js

чем фронтенд программисты на node.js

Это как?

Не начинайте с Basic…
Не начинайте с Pascal…
Не начинайте с PHP…
Не начинайте с JS…

Наверняка уже помимо статей «с какого языка начать» есть статьи «с каких языков не следует начинать» или «в каких языках не следует задерживаться надолго». Такое досужее чтиво.
PHP-PHP, я не твой. Отпусти меня, PHP.
После выхода PHP7 перестал страдать фигней в духе «PHP? Для ламеров».
После выхода PHP8 считаю, что это лучший язык не только для веба, но и многих других задач (но потребуется время для прокачки библиотек).
Лучший по каким критериям и для каких задач?
Когда «лучший язык» начнет нормально поддерживать Юникод?
mb_ функции уже отменили? Вроде только перегрузку обещали вырезать, но это была плохая практика. А переменные хоть эмодзями называй, всё работает.

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

mb_ функции — это жалкий костыль, а не нормальная поддержка. Другие современные языки уже давно позволяют не думать лишний раз о кодировке в строке, а PHP застрял в болоте своего легаси, откуда выбраться ему вряд ли суждено.

В С/С++ уже нормальная поддержка?


А вообще, я уже много лет не думал о кодировках — везде UTF-8 и mb_

В С/С++ уже нормальная поддержка?

современные языки

Ну вы поняли намёк.
Зависит от подхода и задач. Мне наоборот нравится работать с набором байтов и по необходимости использовать отдельные функции для работы с кодировкой. Проблема только с именованием функций.
А я вот за 16 лет профессиональной карьеры никак не могу «слезть» с C++. Нет, помимо C++, я активно использую много других языков, в зависимости от задачи — C#, Kotlin, python — и на работе и дома для личных проектов.

Но вот заканчивается день, ложаться спать дети, и я иду на YouTube смотреть записи выступлений с C++ конференций…

А вы хотите с него слезть или нет?

Было время — хотел, потом потянуло обратно как-то само.
Как говорит Страуструп — все C++ ругают, но все продолжают им пользоваться т.к. если пытаешься выжать максимум из железа — особых альтернатив не так много.

Я начинал свой путь с delphi6 с книжки из мгту, которую взял у сестры. Писал компоненты, программы, даже с железом работал 2 раза, первое мы с другом сделали ик порт и пульт к компу, для управления пк. Это было хобби. Позже данные с атс samsung считывал для сохранения разговора в бд. В колледже я изучал паскаль, бесило…
Начинал также с пхп4 и до 7.4 я использую пхп. 8 версию не использую в проде, обновлением ПО на серверах занимается отдельный человек, поставит — буду использовать.
Также использую ноду как бекенд/фронтент и мне нравится

Мне кажется, проблема не в php. Ведь асинхронное программирование существует вне зависимости от php, js или любой другой платформы — можно писать синхронно, можно асинхронно. Так же, как и процессы, потоки, сетевые сокеты. HTTP одинаковый везде, а функция/класс в определенном языке программирования — лишь абстракция над ним. Поэтому старый совет «учите подходы, а не технологии» работает тут не хуже, чем у любого другого программиста с любой другой платформой.

А вот то, что php дает очень много свободы и многое прощает — это правда. Но тут уже дело каждого, кто-то копает глубже в силу своей любознательности, а кто-то продолжает работать по накатанной. И, вероятно, оба счастливы, так зачем менять что-то :)
Справедливости ради, некоторые вещи в PHP можно сказать, по факту неюзабельны. Что-нибудь не частоиспользуемое вполне спокойно может по-разному работать (или не работать) на разных хостах, «просто потому что». В частности:
можно… синхронно, можно асинхронно. Так же, как и процессы, потоки, сетевые сокеты.
Нужны примеры.

Из того что я сходу могу вспомнить:
pcntl_* работает только на *nix, тут довольно очевидно.
rand() когда-то давно на Windows выдавал плохой рандом, т.к. использовал системные библиотеки (сейчас проблем нет, там теперь вихрь Мерсена во всех функциях связанных с рандомом).

Но это связанно именно с переключением между linux и windows. Такие проблемы типичны для всех языков. Вы кажется говорите про какие-то проблемы при переключении хостов в рамках одной ОС.
С примерами тяжело, было это пару лет назад и код не сохранился. С сокетами, насколько я помню, было две проблемы — во-первых, при неблокирующем чтении проверка состояния буфера приема давала разные результаты, а во-вторых, при разрыве соединения второй стороной обнаруживалось это по-разному. Насчет ОС, не совсем одной, но и не Linux/Windows. На одном был Debian, на втором — кажется, Centos

Смотрели что происходит в wireshark?

Уверен дело было вовсе не в PHP. Про неблокирующую проверку буфера не скажу, нужны факты. Про разрыв соединения — скажу, есть три варианта:
1. Удаленный сервер просто ничего не отвечает, например такое поведение если выключить сетевую карту.
2. Удаленный сервер внезапно присылает RST, тогда стрим закрывается. Такое случается если убить приложение на сервере, тогда ОС сама закроет все связанные с ним TCP-соединения (в зависимости от ОС конечно, но в целом должна).
3. Удаленный сервер проводит штатную процедуру закрытия канала, с учётом специфики используемого протокола. Например сервер может прислать PDU (в зависимости от ипользуемого внутри протокола) о том что стрим завершается, получить подтверждение клиента и только после этого прислать RST. Т.е. ситуация когда клиент ожидает закрытие стрима, пункт номер 2 про ситуацию когда закрытие стрима не ожидается.

Нужно тестировать все три сценария, в т.ч. их граничные случаи. Очень многие библиотеки грешат тем, что не умеют корректно обрабатывать все эти ситуации.
Так а какая разница, сколько вариантов разрыва соединения, если у меня есть только одна функция, которую я могу вызвать и получить либо длину присланной строки (ну или ноль, если ничего не прислано), либо false, если удаленный хост отвалился. Так написано в документации. И вот на одной машине при отвале удаленного хоста действительно возвращается false, а на другой — ноль. ИМХО, это как раз называется «дело в PHP»
Не припоминаю функции позволяющей «получить либо длину присланной строки (ну или ноль, если ничего не прислано), либо false, если удаленный хост отвалился».

Есть fread при помощи которого можно прочитать строку и strlen чтобы узнать длину прочитанной строки. О том что соединение было закрыто (получен RST) можно узнать при помощи функции feof. Функционала PHP вполне достаточно, чтобы обработать все три варианта разрыва (я успешно пишу на php свои кластерные коннекторы к базам, тут работа с tcp-подключениями самое важное звено и никаких проблем на этом уровне нет).

Именно поэтому важно то, что я написал выше. Такое поведение у вас будет на любом языке программирования, если вы не обрабатываете все варианты обрыва.

Причем об этом явно сказано в документации: «Если подключение, открытое при помощи fsockopen(), не было закрыто сервером, feof() повиснет. Для варианта обхода этого поведения смотрите следующий пример:». Единственное что нет уточнения про неблокирующий режим (который подразумевает, что вы знаете что делаете).
Назначение не отличается от fread. А зачем вам понадобилось это расширение?
Для серверных сокетов
В базовой поставке есть stream_socket_server. Лучше использовать его, чем отдельное расширение.
Тоже спрашивают: а почему ты не перейдёшь на другой язык? а почему ты не напишешь какую-нибудь игру и не хапаешь бабки вагонами? Во-первых, каждому своё. А во-вторых, на php было написано столько всякой мути, которую просто так не переведёшь на другой язык и не выбросишь. А в условиях дефицита программеров (из-за перешедших) и работы навалом и ЗП норм.
разбирался с одной из широко известных в узких кругах CMS
Это случайно не dcms? В те времена тоже с телефона ковырял php код, заливал на бесплатный php wap хостинг, заточенный для мобильных телефонов и обсуждал такие вопросы на форуме. Даже делал какие-то зачаточные сайты чисто на wml, там была интересная концепция карточек, чтобы не загружать страницы заново, но это уже отмирало.

А по теме: сам после школы писал на php в университете, но потом сменил направление на Java, а сейчас вообще пишу под Python. Но часть старого кода пет проектов на php всё ещё функционирует и работает в качестве телеграм ботов и парсеров.
да, она родимая.
PHP это не плохо, это уже больше стериотип из-за шуток
Побуду капитаном. Выбирай python. После php заходит на ура, проще чем php и больше библиотек чем под php и они удобнее чем php аналоги. Девопсом-сисадмином со знанием питона быть приятнее чем php программистом на битрикс, а деньги те же.
Пытки в освенциме приятней, чем программистом на битрикс. А на PHP есть вещи и получше этого продукта.
По моим личным ощущениям языки, в которых переменные начинаются со знака $, крайне нечитабельны — глаза цепляются как-раз за эти знаки и мозг быстро начинает уставать. Наверное, к этому привыкаешь, но в свое время для своих несложных задач, выбрал Python т.к. на нем все легче читалось и воспринималось.
У привыкших наоборот, глаза быстрее выделяют переменные.
глаза цепляются как-раз за эти знаки

В каких-то ситуациях наоборот повышает читаемоcть. Собственно для жтого они и сделаны — надёжно отличать переменные от всего остального.

Не спорю, потому и написал «по моим личным ощущениям». Начинал я с С и Паскаля, потому и трудно, наверное, привыкнуть. Для меня они как «ъ» в конце слова в дореформенной орфографии. На вкус, на цвет, как говорится )
Не надо прыгать с языка на язык. Выбрать один язык и одну платформу и потихоньку осваивать. Это будет долго и порой мучительно, но только так можно освоить на достаточном уровне. В идеале сразу устроиться на работу на данный стек.
Большая часть комментариев — ностальгические посты, оставшаяся о том, какой же всё-таки ЯП — труЪ.
А я вот очень хорошо понимаю посыл автора, который многие пропустили мимо.
Синтаксис. Я на каком-то внутреннем уровне сопротивляюсь языкам с «нечеловеческим синтаксисом». Тем, на чей код кинув беглый взгляд, ни черта не поймёшь. Где надо сидеть и вникать в каждую строку.
Причём это палка о двух концах. Где-то перенасыщение спецсимволами — эти самые стрелочки, нижние подчёркивания и т.п. И чем дальше, тем больше всего этого городят.
А где-то наоборот — как распихают код по всяким классам (.net или java) и сиди сличай названия классов и методов (а ещё и именования длинные и похожие между собой)…
И искренне не понимаю такого подхода — это что, искусственное завышение порога вхождения? Ну к чему тогда такие полумеры? Давайте на ассемблере писать иди вообще машинным кодом.
Не раз уже упомянутый в статье SinclairBasic был с чрезвычайно простым («человеческим») синтаксисом. Именно благодаря этому (сравните с каким-нибудь Фокалом, который тоже был распространён в то время) куча народа приобщилась к IT.
Или так называемые «jQuery-недопрограммисты». Ну удобно же, быстро, понятно. Всё в рамках довольно простой модели синтаксиса. От того-то так и выстрелил — потому что смог затянуть в сферу разработки тех, кто попробовал — «хм… получилось».
Языки программирования создаются прежде всего для людей. Аппаратная часть все равно понимает только наличие/отсутствие сигнала. Только об этом частенько забывают в погоне за какой-нибудь оптимизацией или попыткой объять необъятное…
Я тоже так в начале думал, когда мои задачи сводились к «вывести форму с отправкой отзывов».
Но чем дальше, тем больше понимал что для чего-то все эти хитрые классы переплетены в невероятные узоры.
Потом я первый раз прочитл «Приемы объектно-ориентированного проектирования. Паттерны проектирования» от банды Четырех. Именно тогда в голове произошел тектонический сдвиг.
Конечно, после первого прочтения я все еще тяжело понимал все эти стратегии, прототипы, одиночки и прочие посредники. Но я понял, что люди с огромным опытом это используют, значит надо и мне.
После я старался каждую свою задачу осмысливать именно с точки зрения паттернов проектирования и очень хорошо продвинулся. После второго прочтения книги «банды четырех», я уже встречал знакомые и понятные конструкции.
Простыми словами — для первоклассника цикл FOR, тоже покажется непонятной и ненужной абракадаброй (хотя сейчас есть такие первоклассники, что ...)
Но вы как программист, надеюсь понимаете ценность этого цикла и юзаете его повсеместно (в разных вариациях).
С паттернами проектировании все, примерно также. Сначала это непотяная хрень, потом привычный инструмент.
И да, новичков твой код теперь будет пугать )
Это ничего. Потом вы начнёте видеть случаи, когда паттерны излишни и лучше писать без них ))

Понятное дело. Но со временем таких задач становится всё меньше. А таких, в которых изменение в одном месте кода может вызвать проблемы в другом — всё больше.
И тут уже без "паттернов" в какой-то момент становится совсем никуда.

Цикл for в РНР — бессмысленная пальцеломная абракадабра, в 99% случаев проще написать foreach :)
Кроме шуток, я даже перебор чисел пишу как foreach(range(5,15) as $i) чем выписывать все эти запяточечки.


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

Обычно абстракции нужно вводить как раз чтобы упростить восприятие кода. Очень удачная абстракция упростит и его объективную сложность, например, число связей. Но если абстракция усложняет и объективные метрики сложности кода, и его субъективное восприятие, то зачем она нужна такая?!

НЛО прилетело и опубликовало эту надпись здесь

Всем привет, меня зовут Вова и из 25+лет коммерческой разработки 20+ PHP был и есть моим основным языком для бэкенда от сайтиков, где бэкенд был только для гостевой книги на файлах до финансовых системам, схожих с оперднём банка.


Пробовал разные стэки как для души, для развития, так и по коммерческим проектам что-то делал, но не один из них не запал настолько, чтобы сменить стэк, опустившись минимум на ступеньку "табели о рангах", а скорее 2-3. Да и работодатели к паре попыток отправить резюме на, например, junior java developer даже без опыта, серьёзно не относились.


С другой стороны, в области разраюокт веб-приложений и сервисов очень мало задач, на которые я своему менеджеру скажу: на пхп это делать нет никакого смысла — я просто возьму и сделаю. Напихаю еслли надо базы, кафки, эластики, может напишу что-то на ноде или гоу (ни одного rод ревью нормального мой гоу-код в Symfony style не пройдёт), сделаю какой-нибудь плагин на java, но "клей", бизнес-логика будет на PHP.


Иногда доастаёт что-то в PHP так, что уже готов на в 3-4 раза меньшие деньги идти на Java или C#, но тут выходит новая версия PHP, в которую что-то добавляют и жить играет новыми красками :)

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.