Comments 145
да, но нет.
в php есть асинхронность, многопоточность, довольно удобная (на мой взгляд) работа с бинарщиной, голые сокеты и куча самых разнообразных вещей. а какое-то время назад вполне себе здравствовали обертки для gtk и qt, народ даже окошечки рисовал из php (сейчас можно обойтись без биндинг библиотек и дергать через ffi)
и даже свой аналог async-await есть.
и статья немного выглядит как "какой такой Tcp Listener? в похапэ я просто писал <?= 'Hello '. $world ?> и буквы сами попадали в браузер" — нет, то что вы не сталкивались с чем-то в php нисколько не показатель что там этого нет или что на нем нельзя так писать.
а сахара вон в 8ке насыпали, но сахар то всего лишь абстракция, которая позволяет впихнуть больше смысла в меньше строк, а не сделать магию.
нисколько не показатель что там этого нет или что на нем нельзя так писать.
Можно же, но не надо, пожалуйста.
ReactPHP неплох, но лично я предпочёл мигрировать на amphp.
Знаете, в те времена, когда начал программировать я, "плохим" первым языком считался бейсик, и люди у которых первым языком был паскаль, си или ассемблер очень сочувствовали тем, кто начинал с бейсика… считалось, что это будет мешает им стать хорошими программистами. Доля правды в этом, конечно, была, но по моим наблюдениям те, кто начинал с бейсика, просто разделились на две группы — одна с незначительными сложностями осилила си/паскаль и стала профессионально программировать, а вторая переключилась на разные варианты простых/специализированных языков — от уже непомню чего-то там для работы с БД времён DOS (Clipper?) до макросов в офисе и позднее 1C.
Мне лично учить PHP в своё время помешала сильная неконсистентность языка — как только увидел в начале изучения кучи стандартных функций с похожими названиями и делающие примерно одно и то же, но при этом принимающие примерно одни и те же параметры в совершенно разном порядке — так сразу с изучением и закончил. Чуть позже вышла та известная статья про "фрактал плохого дизайна", которая полностью описывала моё собственное впечатление, чем подтвердила что это просто "не мой" язык.
Я это к тому, что, да, плохих инструментов (почти) не бывает, и практически любому найдётся своё применение. И да, PHP за последние годы сильно развивался. И сильных разработчиков на PHP хватает. Но люди все разные, вкусы у них разные, и языки программирования тоже каждому подходят разные. И вот тем, для кого PHP попал в категорию "мой язык", осваивать другие современные языки действительно может быть сложнее. С другой стороны, PHP вряд ли грозит участь бейсика, так что им ничего не мешает и дальше писать на языке, который им нравится, и вполне эффективно решать проблемы бизнеса.
Можно ли считать "плохим программистом" того, кто вполне успешно решает проблемы бизнеса, но с точки зрения кого-то другого не знает чего-то такого, что "должны знать все хорошие программисты"? Лично я бы об этом вообще не парился, каждому своё. Для кого-то и я, со всем своим опытом, статьями и кучей опенсорсных проектов, выгляжу недостаточно образованным и не очень-то квалифицированным. Это — просто чужое мнение, не стоит уделять ему слишком много внимания. Лучше просто заниматься тем, чем нравится и писать на том языке, который нравится.
Не считаю себя хорошим программистом, но встающий задачи решаю и зарабатываю себе этим на хлеб :)
Начинал с бейсика на спектруме, помню в школе от нечего делать в тетради написал игру "танчики", ничего при этом не зная про функции — вся логика в одном большом цикле для игры, подциклах для танчиков и снарядов, "рендеру" (PRINT строк из массива) и кучке GOTO.
ЧСХ игра заработала практически сразу после вбивания в спектрум.
Потом появились игровые консоли, где нельзя было программировать, и я забросил программирование лет на 20, если не считать одной попытки прочитать "выучи С++ за 21 день", где я здался на 4-й день, и пары маленьких программ на Visual Basic уровня "калькулятор".
И вот в 33 годика я остался без работы, вокруг все "входят в Айти" и приятель подкинул книжку "Python для сисадминов".
Через полгода первая работа, с которой выгнали с диагнозом "медленно учится", но где я за месяц выучил BASH.
Потом вторая — израильский "стартап" с одним продуктом на JS, который тоже пришлось по быстрому выучить.
И так вот спустя несколько лет я с удивлением замечаю, что за сезон спроектировал и написал асинхронный сервер для IoT устройств, API для управления этими устройствами, подключил к этому API существующий Web-клиент (внедряя в него патчи в процессе), все это наладил и запускаю + написана кучу документации и все это еще и работает.
Не считаю себя "отличным" программистом, а вот хорошим и решающим задачи бизнеса — вполне.
А вообще, ИМХО, все это «кто на каком языке» — ерунда по большей части, главное — понимание парадигм и принципов, а они к языку относятся поскольку-постольку
Ну тот php что был лет 10-15 назад и текущий php это немного разные вещи.
Теперь тут есть и асинхронность и многопоточность.
Плюс очень много интересных новых инструментов (привет roadrunner и тп)
Так что возможно перейти/выучить другие языки будет трудно (тут не берусь судить) но когда все есть что написал выше… а стоит ли учить/переходить? )))
Пока вы находитесь на этапе «сперва формирую фразу на русском, затем в уме перевожу её на английский, затем произношу» — будут сложности. Когда вы перейдёте на этап «сразу формулирую и произношу на английском» — сложностей не будет, а о каких-то вещах из мира 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, то, например, эффективней в плане технических метрик работы в продакшене, какие-никакие гарантии типобезопасности в компайлтайме и т. д. Да и в принципе большее число людей смогут это решение поддерживать с минимальным погружением в стэк задачи: спринговиков, имхо, больше на рынке чем симфонистов за плюс-минус те же деньги.
Я к тому, что чтобы самому по задаче понять, что лучше подходит для решения надо на достаточном высоком уровне знать несколько стэков. Не, если надо написать IDE, я не буду писать её на PHP. А вот если веб-приложение: я могу навскидку оценить трудоёмкость на PHP, какие мощности под задачу надо при планируемой нагрузке, что ms sql server не стоит выбирать как базу для php приложения под Linux и т. п. С nodejs и typescript есть опыт коммерческий в проде. Ну и всё из актуального. Так-то за последние лет 10 на многих языках писал, включая ту же Java, но это не были полноценные проекты, так поддержка легаси или плагинчик/коннектор какой-написать для соединения с тем же 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. Ой, как себя динозавром почувствовал.
Хотел бы вернуться в программисты, писать свои миры, быть вольным художником. Но тяжко, всё так вперёд ушло.
Да и зрение подводит. :)
Знаете, когда я ради интереса сделал за нее небольшое домашнее задание, первым вопросом преподавателя было "что за phpшник это писал?"
Так какой язык надо изучить, чтобы понравится преподавателю вашей жены? Тема не раскрыта.
Там был Свифт, но код был написан в стиле php.
Вордпресс и Симфони оба php, но между ними пропасть.
в стиле php
Это как?
Можно пример того как написано на php, а как должно на свифт (или другом языке)?
Раньше PHP выделяли глобальные переменные и функциональный подход, сейчас начиная с 7-й версии вполне полноценный ООП язык.
На мой взгляд PHP стал полноценным ООП с выходом PHP 5.
Кроме того, считаю PHP4 так же ООП-языком (но не полноценным), функциональный подход там не был сильно распространён.
Мне кажется, вы путаете функциональное программирование с процедурным, их часто смешивают, как Яву и Яваскрипт.
Функциональный подход стал возможен частично в 5 версии, но в любом случае а практике применяется довольно редко.
РНР является по сути процедурным языком с возможностью использования ООП и функционального программирования.
Функциональное и процедурное программирование — это больше про стиль написания кода. Нет проблемы написать процедурную программу на функциональном языке.
И вы очень резко поменяли тему. Речь шла про ООП. Чтобы язык считать ООП-полноценным — в нём должны быть определенные языковые конструкции, позволяющие полноценно использовать парадигмы ООП.
PS: Кажется за отсутствием аргументов в ход пошли минусы :-)
Не, функциональное программирование — это совсем же не про стиль, а скорее про состояние. И четвёрка не позволяла писать декларативно. Ну или я чего-то совсем не помню.
Если считать парадигмами ООП инкапсуляцию, наследование и полиморфизм, то да — РНР в 4 версии реализовывал их, не могу спорить.
Другое дело что сама реализация сильно оставляла желать лучшего — проблемы с производительностью, которые были решены в cемёрке, плюс отсутствие неймспесов и автолоада, прямо скажем, сильно затрудняли построение мало-мальски сложных структур и использование сторонних библиотек.
Так что предлагаю сойтись на формулировке что юзабельным ООП стал в РНР ближе к 7 версии.
4-ка не даёт все три парадигмы. Они недостижимы без области видимости переменных и методов, которых в PHP4 не было. Поэтому я и ссылаюсь на PHP5, как на полноценное ООП.
Неймспейпы — это так же PHP 5 (конкретно PHP 5.3). Вообще там до 5.6 было много клёвых изменений.
А вот проблемы производительности к ООП отношения не имеют. Это всегда было фичей языка :-) Функциональщина тоже тормозила и в PHP7 так же ускорилась.
В контексте сравнения функционального и процедурного программирования — это про стиль.т.е. в ходе сравнения двух парадигм, вы пришли к выводу, что отличие только в стиле? Или как это понимать?
Декларативное и императивное программирование — это вообще отдельно, касается ООП и функциональщины в равной степени.ФП это декларативная парадигма программирования, ООП — императивная. Как видите, далеко не «в равной степени».
И ООП гораздо ближе к процедурному подходу, чем ФП.
4-ка не даёт все три парадигмы. Они недостижимы без области видимости переменных и методов, которых в PHP4 не было
Сокрытие не необходимо для полноценности ООП, только инкапсуляция, а она была.
Функциональный подход стал возможен частично в 5 версии
В 3-ей уже можно было выбирать между функциональным подходом и процедурным местами: передача функций/параметром переменной и её вызов были, array_reduce и ко тоже были.
С 5.3 )
Тут хорошо вправит мозги теория, когда видишь в языках частные случаи теории, то куда проще скакать между ними. Хотя да, не соответствие некоторых вещей бесит.
в новых RFC обещают дженерики
Это в каких, например?
Суть статьи: "программировал 10 лет на языке %language_name% и не очень хорошо разбираюсь в других технологиях"
Причем тут PHP?
Проблема не в языке, проблема в людях. Если за 10 лет так и не понял принципы работы ЭВМ, то это не проблема языка.
Знаете, однажды к нам пришел на собеседование парень, который начинал с какого-то фреймворка, и все время на нем и работал. Так вот он знал только в теории, как без ORM получить данные из БД, а оптимизация запросов для него была темным лесом.
P.S. в большинстве случаев для того, чтобы понимать и разбираться в чем-то еще — необходимо иметь постоянные пет-проекты или хотяб просто задачи, отвлеченные от своей основной деятельности. Однако, как показывает практика, очень многие разработчики не делают ничего кроме тасок в JIRA.
Скажите, какой процент людей, работающих на PHP многие годы углубленно знают про управление памятью, как работает процессор или почему для майнинга лучше подходит GPU?
И что это доказывает? То что специализация стала более узкой и люди хорошо знают то, чем занимаются и что приносит им пользу, а плохо знают остальное? Поздравляю, вы открыли Америку.
Какой процент людей, которые "майнят на GPU", знают хоть что-либо из веб-разработки?
¯\_(ツ)_/¯
в большинстве случаев для того, чтобы понимать и разбираться в чем-то еще — необходимо иметь постоянные пет-проекты или хотяб просто задачи, отвлеченные от своей основной деятельности
Холиварно, но в общем случае не правда. Есть куча людей, которые делают на 10/10 свою работу с 9 до 6, а потом проводят время со своей семьей и за хобби и не имеют пет-проектов.
Это будут единицы, которые работали/работают на специфических проектах
Или которые прошли путь типа:
- BASIC+ASM
- ASM
- C
- Pascal/Delphy
- Visual C++
- PHP последние 20 лет
Кроме того, большая часть знаний про «управление памятью, как работает процессор или почему для майнинга лучше подходит GPU» для веб-разработчика, в общем-то, бесполезна. Там вместо этого полно своих заморочек… В плане «понимать и разбираться в чем-то еще» ему гораздо полезнее API браузеров, настройка сервера, криптография, сетевые протоколы, языки разметки, API сторонних сервисов и тд и тп. Причем среди «тасок в JIRA» все это — далеко не редкость
Многие ведь как, когда наслушаются как все круто в другом языке, особенно когда вокруг него много хайпа (Допустим в Java и C# отсутствует множественная наследовательность и сделали это намеренно т.к. с ней много проблем, но она есть в Python вокруг которого много хайпа, в итоге у Дмитрия Стогова спросили «когда будет в PHP множественная наследованность?», на что он четко ответил «Никогда» (слава богу)) столкнувшись с какой то не стандартной задачей начинают думать о другом ЯП.
Пример из жизни — был как то на собеседовании, не помню точный вопрос, но вспомнил про yield и начал рассказывать про генераторы, на что собеседующий сказал «мы сейчас говорим о PHP, а не о Python»! Как Вы думаете, какая была моя реакция и кого винить за незнание ЯП, сам ЯП или человека? Напомню, генераторы появились еще в PHP 5.
Вот и говорю, проблема не в языке, проблема в людях. И людей которые знают только то, с чем работают очень много и не только в PHP, но не надо за это винить ЯП.
А какие есть практические задачи для генераторов на PHP при работе с php-fpm. Так-то я знаю, что они есть в PHP, но зачем не очень понятно. Разве что промисы попробовать реализовать как в JS
Можно и без промисов. Простой пример — делаем запрос в базу, получаем N (для примера возьмём большой N) строк, которые превращаем в ActiveRecord (чтобы явно понять плюс от генераторов) и итерируем через генератор.
Можно и без генератора, менее эффективно и зачем?
А итераторы эту проблему не решат? Даже название намекает :)
P.S. Вот мне видится, что генераторы полезны прежде всего для асинхронщины, но без async pdo это только для каких-то очень специфических задач, для которых может лучше было бы выбрать Go или Node.
В PDO есть async.
А можно ссылочку? Я только про async mysql знаю...
Кроме того вам не нужен PDO — можете взять любую асинхронную библиотеку и использовать.
Я-то могу взять, а вот Doctrine, например, или Eloquent не может.
У Go или Node нет сильно больших преимуществ перед PHP
Нормальная асинхронщина у них из коробки, да и вообще экосистема (либы, фреймворки, тулинг)...
кроме слегка большего комьюнити
Интересно, почему? :)
С Doctrine и Eloquent не работал, у меня другой стек. Если речь про собрать запрос, отправить в базу, результаты сложить в ActiveRecord — то любой адекватный фреймворк легко расширяется для этого.
Обычно популярные реализации ActiveRecord сами собирают и отправляет запросы и под капотом использует PDO
Может и через прослойку, но сильно на неё завязан. И, главное, клиентский код о прослойке ничего не знает, он вызывает 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);
}Синхронную логику нужно заменить, без вариантов. Либо использовать асинхронные фреймворки сразу и не пытаться натянуть сову на глобус (хотя оно и не трудно).
Либо оставить синхронную, а асинхронную реализовать параллельно.
По сути, значит, свой асинхронный форк фреймворка/либы сделать...
В сторону готового я смотрел немного, но там готовые не асинк версии нужного мне, а полностью другие продукты. И, да, аналогов Doctrine (DataMapper, а не ActiveRecord) не встречалось.
С Go имхо повыше шансы, что произвольная либа работы с БД, очередями, файлами и т. п. поддерживает асинк из коробки :)
Но я даже не об этом, а о том, что кто то даже не знает что есть в пыхе и плохо понимает что на самом деле в этом языке не так, восхищаясь другими языками не зная что и там есть проблемы.
С одной стороны — это как читать 10 лет бульварные романы, а затем попробовать открыть Кафку.
С другой — язык не учит сложным вещам, мы не задумываемся об очень многих процессах во время написания кода.
И исходя из этого при попытке перехода на язык «посильнее» приходится многие вещи начинать «с нуля».
С одной стороны — это как читать 10 лет бульварные романы, а затем попробовать открыть Кафку.
В ваших терминах это как уметь писать книги и 10 лет писать бульварные романы, вместо того, чтоб написать "Кафку". Буквы одни и те же, вопрос в том, как вы их применяете. То есть это ваш выбор и ваша проблема, а не языка.
С другой — язык не учит сложным вещам, мы не задумываемся об очень многих процессах во время написания кода.
Чем это плохо? Ну, разрабатывайте веб на С, думайте о сложных вещах. При чем тут PHP?
В экосистеме PHP есть много программніх способов ограничить неоднозначніе, скажем так, возможности. Нужно только хотеть внедрить их на своём проекте или сменить проект, если внедрять нельзя или нет желания заниматься именно внедрение.
Зависит от ожиданий. Если что-то серьёзное, то требуется понимание ООП плюс базовое понимание ORM и связанных с ним проблем. Просто потому все распространенные РНР фреймфорки — это всего лишь веб-интерфейсы: принять запрос клиента и передать в собственно твоё приложение. Ну и плюс кучка библиотек — тот же ORM, логгер, отправка емейлов. Nо есть работа с фреймворком составляет процентов 10 всего приложения. Самым правильным считается Симфони.
Если тупо фигачить "шмяк-шмяк и в продакшен", то учить Ларавель, который заточен под режим работы "максимально быстро выпустить рабочий вариант с минимумом кода". Но там надо всерьёз учить всю его магию.
П.С. eloquent я защищать не буду. Благо при желании его можно не использовать.
facade
www.merriam-webster.com/dictionary/facade
Это если вы английский знаете, слово хотя бы в пассивном словаре, транскрипции смотрите и что-то в них понимаете. Я вот, навскиду, никак не запомню notice — "нотис" или "нотайс", event — "евент" или "ивент", да даже error — "еррор" или "иррор"? Английский начал учить одновременно с программированием и единственным "учебником" английского было два карманных словаря. Школьный и институтский английский потом чуть-чуть поправил русскую ИТ-терминологию, notice уже не "нотице".
Так и есть. У меня "ретурн" был лет 10, пока английский был на уровне чтения документации. Когда говорить научился, понемногу исправился.
У меня ещё иногда срабатывает переключение контекстов — на русском скажу или напишу "ретурн", на английском "ретёрн"
По-моему, перечислены просто общие 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 Не самая удобная в работе, есть обёртки над ней и альтернативные реализации.
Причем тут фреймворк и java?
Все эти технологие, ну или добрую половину из них серьезные компании (50+ человек) спрашивают с джунов при приеме на работу. Намешали в кучу лиш бы было…
По поводу фреймворков их три основных, прилично разных между собой: Symfony, Laravel, Yii. Есть еще куча мелких/старых/забытых и куча CMS, но это совсем другая история…
По опыту работы c разработчиками как админ/девопс и отзывам коллег, собеседуюших программистов, есть такая корреляция, что сегодня php программисты гораздо сообразительнее и имеют более широкий кругозор, чем фронтенд программисты на node.js
Не начинайте с Pascal…
Не начинайте с PHP…
Не начинайте с JS…
Наверняка уже помимо статей «с какого языка начать» есть статьи «с каких языков не следует начинать» или «в каких языках не следует задерживаться надолго». Такое досужее чтиво.
После выхода PHP8 считаю, что это лучший язык не только для веба, но и многих других задач (но потребуется время для прокачки библиотек).
И юникод-строки нормально (по крайней мере для кириллицы) обрабатывает в операторе конкатенации. Сравнение строк может глючить, но оно всегда глючило везде если локаль не учитывать.
mb_ функции — это жалкий костыль, а не нормальная поддержка. Другие современные языки уже давно позволяют не думать лишний раз о кодировке в строке, а PHP застрял в болоте своего легаси, откуда выбраться ему вряд ли суждено.
Но вот заканчивается день, ложаться спать дети, и я иду на YouTube смотреть записи выступлений с C++ конференций…
Я начинал свой путь с delphi6 с книжки из мгту, которую взял у сестры. Писал компоненты, программы, даже с железом работал 2 раза, первое мы с другом сделали ик порт и пульт к компу, для управления пк. Это было хобби. Позже данные с атс samsung считывал для сохранения разговора в бд. В колледже я изучал паскаль, бесило…
Начинал также с пхп4 и до 7.4 я использую пхп. 8 версию не использую в проде, обновлением ПО на серверах занимается отдельный человек, поставит — буду использовать.
Также использую ноду как бекенд/фронтент и мне нравится
А вот то, что php дает очень много свободы и многое прощает — это правда. Но тут уже дело каждого, кто-то копает глубже в силу своей любознательности, а кто-то продолжает работать по накатанной. И, вероятно, оба счастливы, так зачем менять что-то :)
можно… синхронно, можно асинхронно. Так же, как и процессы, потоки, сетевые сокеты.
Из того что я сходу могу вспомнить:
pcntl_* работает только на *nix, тут довольно очевидно.
rand() когда-то давно на Windows выдавал плохой рандом, т.к. использовал системные библиотеки (сейчас проблем нет, там теперь вихрь Мерсена во всех функциях связанных с рандомом).
Но это связанно именно с переключением между linux и windows. Такие проблемы типичны для всех языков. Вы кажется говорите про какие-то проблемы при переключении хостов в рамках одной ОС.
Уверен дело было вовсе не в PHP. Про неблокирующую проверку буфера не скажу, нужны факты. Про разрыв соединения — скажу, есть три варианта:
1. Удаленный сервер просто ничего не отвечает, например такое поведение если выключить сетевую карту.
2. Удаленный сервер внезапно присылает RST, тогда стрим закрывается. Такое случается если убить приложение на сервере, тогда ОС сама закроет все связанные с ним TCP-соединения (в зависимости от ОС конечно, но в целом должна).
3. Удаленный сервер проводит штатную процедуру закрытия канала, с учётом специфики используемого протокола. Например сервер может прислать PDU (в зависимости от ипользуемого внутри протокола) о том что стрим завершается, получить подтверждение клиента и только после этого прислать RST. Т.е. ситуация когда клиент ожидает закрытие стрима, пункт номер 2 про ситуацию когда закрытие стрима не ожидается.
Нужно тестировать все три сценария, в т.ч. их граничные случаи. Очень многие библиотеки грешат тем, что не умеют корректно обрабатывать все эти ситуации.
Есть fread при помощи которого можно прочитать строку и strlen чтобы узнать длину прочитанной строки. О том что соединение было закрыто (получен RST) можно узнать при помощи функции feof. Функционала PHP вполне достаточно, чтобы обработать все три варианта разрыва (я успешно пишу на php свои кластерные коннекторы к базам, тут работа с tcp-подключениями самое важное звено и никаких проблем на этом уровне нет).
Именно поэтому важно то, что я написал выше. Такое поведение у вас будет на любом языке программирования, если вы не обрабатываете все варианты обрыва.
Причем об этом явно сказано в документации: «Если подключение, открытое при помощи fsockopen(), не было закрыто сервером, feof() повиснет. Для варианта обхода этого поведения смотрите следующий пример:». Единственное что нет уточнения про неблокирующий режим (который подразумевает, что вы знаете что делаете).
разбирался с одной из широко известных в узких кругах CMSЭто случайно не dcms? В те времена тоже с телефона ковырял php код, заливал на бесплатный php wap хостинг, заточенный для мобильных телефонов и обсуждал такие вопросы на форуме. Даже делал какие-то зачаточные сайты чисто на wml, там была интересная концепция карточек, чтобы не загружать страницы заново, но это уже отмирало.
А по теме: сам после школы писал на php в университете, но потом сменил направление на Java, а сейчас вообще пишу под Python. Но часть старого кода пет проектов на php всё ещё функционирует и работает в качестве телеграм ботов и парсеров.
А я вот очень хорошо понимаю посыл автора, который многие пропустили мимо.
Синтаксис. Я на каком-то внутреннем уровне сопротивляюсь языкам с «нечеловеческим синтаксисом». Тем, на чей код кинув беглый взгляд, ни черта не поймёшь. Где надо сидеть и вникать в каждую строку.
Причём это палка о двух концах. Где-то перенасыщение спецсимволами — эти самые стрелочки, нижние подчёркивания и т.п. И чем дальше, тем больше всего этого городят.
А где-то наоборот — как распихают код по всяким классам (.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, в которую что-то добавляют и жить играет новыми красками :)
Отпусти меня, PHP