Блеск и нищета php. Эволюция языка от 4.x к 7.1

[SaturnTeam]

Как вы думаете, есть ли своя ниша у php, и в чем она заключается?

На мой взгляд везде, где не требуется GUI без браузера, и не слишком критична скорость выполнения.

[SaturnTeam]

господа минусующие, а не проясните ли мне, в чем же это я не прав? И собственно за что минуса? за мое личное мнение?

[jrip]

Не минусил и PHP люблю, но думаю за слово «везде».

[FractalizeR]

Я думаю, все дело в аргументации. Когда речь идет о нише языка программирования, я полагаю, нужно учитывать его особенности. Я бы выделил следующие особенности PHP:

• Изначальная ориентация Расмусом на web-разработку, что во многом определило курс развития языка.
• В экосистеме PHP доминируют библиотеки нацеленные именно на веб-разработку
• Низкий порог вхождения в язык (легко найти разработчиков, много уже написанных продуктов, библиотек)
• 99% внедрений используют PHP для выполнения кода без сохранения состояния внутри интерпретатора (параллельно исполняемые экземпляры почти не влияют друг на друга кроме как через кеш или персистентное хранилище данных)
• Большое количество услуг PHP-хостинга, высокая ценовая конкуренция в этом сегменте

Все это вместе (и некоторые другие факторы тоже, конечно) и определяют нишу этого языка сегодня.

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

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

[SaturnTeam]

но никаких других ограничений, кроме как отсутствие некоторых узконаправленных библиотек нет. Вот к чему я клонил.

[FractalizeR]

Я не думаю, что Тьюринг-полные языки программирования имеют "ограничения". На ассемблере тоже можно интернет-магазин написать. Ограничений нет. В данном случае лучше говорить не об ограничениях, а о тенденциях.

[jrip]

ниша != можно если зачем-то хочется.

[NeoCode]

Я хочу чтобы в мейнстриме появился нормальный компилируемый язык со статической типизацией для веб-разработки. Да, конечно что-то есть, можно хоть на си писать сайты… но это не распространено. А распространены именно динамически типизированные языки php, python, ruby и js. Интересно почему?

Об уровне — это чистая правда. Я не веб-разработчик, но когда в старые времена для каких-то целей нужно было создать сайтик (по сути простой веб-интерфейс для доступа к БД в локалке), я это сделал на «php4» вообще не задумываясь — настолько все было просто.
Что там творится теперь — мне непонятно. Уровень абстракции очень сильно вырос, количество абстрактных прослоек выросло, и это привело к тому что я «не чувствую» ни сложности алгоритмов, ни низкоуровневой структуры программы. То есть современные фреймворки работают, но их работа превратилась в некую магию, для полного понимания которой нужно, вероятно, глубоко изучить внутреннюю структуру фреймворков на самом низком уровне. Все ли к этому готовы?
Все руководства по фреймвокам сводятся к написанию «hello-world» сайтов практически без объяснения внутренней работы самого фреймворка. Я после безуспешных поисков такого глубокого руководства пытаюсь сам разобраться понемногу в свободное время, может статью напишу:)

[SonicGD]

Посмотрите на .Net Core

[DexterHD]

Go посмотрите. Уже 13 позиция в TIOBE индексе (по сравнению с 48 в прошлом году). Вполне себе «мейнстрим».
Нормальный, компилируемый, со статической типизацией, лишенных кучи ненужного синтаксического сахара.

[naghtigall]

Если вы про этот индекс языков — то там Go на 16 позиции.
http://www.tiobe.com/tiobe-index/

[polifill]

Я хочу чтобы в мейнстриме появился нормальный компилируемый язык со статической типизацией для веб-разработки

Существует.
И уже как несколько лет в мейнстриме у серьезных разработчиков.
В т.ч. в production очень серьезных контор (как Dropbox, к примеру).

Называется Go, golang.

Да, конечно что-то есть, можно хоть на си писать сайты… но это не распространено. А распространены именно динамически типизированные языки php, python, ruby и js. Интересно почему?

Потому что вы просто не знаете об использовании в крупных веб-проектах Go, Java, Scala, C#.
Почему не знаете — потому что не сталкивались.
Почему не сталкивались тоже понятно — ведь хоумпейджи на них крайне редко пишут.

[Aleks_ja]

Я не веб-разработчик, но когда в старые времена для каких-то целей нужно было создать сайтик (по сути простой веб-интерфейс для доступа к БД в локалке), я это сделал на «php4» вообще не задумываясь — настолько все было просто.
Что там творится теперь — мне непонятно.

Ничто не мешает и теперь на php7 накидать. Более того, и ваш старый код скорее всего будет работать.

[calvin_rus]

Вроде как часть расширений убрали, в частности mysql ( и это не большая проблема, там где это вынесено в отдельный класс, а если это бесконечные mysql_query, написанные неким индусом?) А такого кода на РНР просто море, в виду того, что «работает не трогай», и «Вась, там кнопочку выведи еще одну, что бы отчеты в эксель строило». Хотя, признаюсь, сидим на работе глубоко на 5.х, и пробовал на 7.0 проект перевести только на одной шабашке, именно с подключением к БД и были проблемы.

Конечно, накидать нечто подобное по новой не составляет проблемы, но лично мне подобные изменения (углубление в ООП) в РНР нравятся.

[vanxant]

Ну за mysql (при наличии pdo, mysqli и mysqlnd я уж не знаю, десяток лет точно) надо карать. Я думаю, через пару лет к этому и придёт, когда php5 хостинг будет в 2 раза дороже php7.

[http2]

А какая разница, что человек использует mysql, кроме mysqli?
Ну кроме того, что он не поддался хайпу?
Запросы выполняются? Все, отлично.

https://habrahabr.ru/post/316506/

[Fesor]

А какая разница, что человек использует mysql, кроме mysqli?

mysql_* функции удалены из php7+. А так ничего.

Запросы выполняются? Все, отлично.

все завязано на устаревший функционал? Все отлично.

[M-A-XG]

Так карать-то зачем? :)
Я написал обертку для вызовов mysqli_ ф-й из mysql_ функций для php7 и продолжаю писать в привычном стиле :)

[Fesor]

продолжаю писать в привычном стиле :)

Если всю работу с данными вы изолировали, и SQL не размазан по всему проекту, то "карать" действительно незачем. Особенно если в "привычный стиль" не входят штуки вроде "интерполирую ка я айдишку в строку с SQL". Ну мол prepared statements, параметры и все такое...

[M-A-XG]

Я бы сказал, что если SQL размазан, то карать нужно независимо от того, mysql_*, mysqli_* или PDO. :)

[Grox]

А распространены именно динамически типизированные языки php, python, ruby и js. Интересно почему?

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

[Splo1ter]

Вы случайно не под vax пишите ?)
Я понимаю что ядро linux будет не 15 минут компилироватся(хотя возможно я ошибаюсь и это происходит быстрее), но давно уже прошло время когда те же самые java/C#/C/C++ компилировались.

[VolCh]

Теперь они интерпретируются? :)

[Splo1ter]

ошибочка вышла, «долго компилировались»

[dsrk_dev]

да, .net core при разработке можно юзать именно что в режиме интерпретатора

[Grox]

Я вот слышал, что браузеры собираются сутки. Но это к слову.
Для примера, если вы почитаете интервью с разработчиками Facebook, то они как раз и упоминали большую скорость разработки, когда мотивировали отказ от других языков.

P.S. даже если проект будет собираться 1-2 минуты, это уже долго, потому что таких минут для всей команды будет набираться на полчаса-час в день на разработчика, а в переводе на суммарные затраты времени будет очень большим.

P.P.S. Да и зачем компилирование? Скорость скриптовых языков достаточно велика. Качество кода? С новыми версиями PHP можно писать надёжнее. А если будут весомые аргументы, то и сейчас есть компилируемые языки, которые можно использовать. Тот же Nginx не на PHP написан.

[Splo1ter]

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

[Grox]

Ну PHP в версии 7, как раз обладает возможностями статической типизации и не компилируемый. Честно говоря, я не вижу преград в создании транслятора компилируемых языков. Те же С и С++ могут быть сконвертированы в кода на JS во многих случаях. И ещё и JS приблизился к скорости выполнения компилируемых.

О качестве.
if (a = b) сработает также хорошо, как и if ($a = $b). От этого защитит разве что статический анализатор или warning компилятора (если он умеет). А стат.анализаторы есть и для PHP.

Возможностей же выстрелить в ногу, что на С, что на С++ и других компилируемых предостаточно. И скриптовый язык может быть даже безопаснее, потому что он в редком случае завалит(?) систему, приложение же на компилируемом языке может вызвать «BSOD».

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

[Psih]

Zephyr

[Grox]

А немного подробнее?

[Zazza]

Об этом речь: https://zephir-lang.com/ Фреймворк Phalcon, как реализация

[Melkij]

> Есть ли ЯП которые имеют статическую типизацию и не компилируются?
SQL
Если в чистом виде SQL по вашим убеждениям не является достаточным чтобы являться ЯП, то есть ещё хранимая логика.

[merlin-vrn]

врут. Сутки собирается webkit-gtk, нормальные браузеры собираются за пару-тройку часов.

[vanxant]

Думаю, не в компиляции дело, а в доскональном прописывании интерфейсов.
Зачем, если в вебе можно «херак херак и в продакшн», и оно будет работать.
Помню дикую боль при разработке веб-морды на старой Java, когда для каждой долбаной кнопки нужно было создавать свой класс с единственным перегруженным методом онклик. А потом создавать экземпляр этого класса. Зачем?

[asdf87]

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

Это всего лишь вопрос синтаксического сахара для удобства разработки. Принципиальных проблем тут нет. Что касается именно Java, то это консервативный язык. Он долго перенимает инновации, поэтому к нему легко придираться в таких холиварных обсуждениях.

[Anakros]

Инкрементальное компилирование не просто так сделали.

[Serj_By]

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

[varanio]

Ну, насчет десктопа спорно. По-моему swing уже устарел морально. javaFX по слухам загибается тоже.

[terryP]

хотя тут не уверен, возможно есть и под другие платформы уже свои костыли

Есть как и конвертирование Java проекта с Андроида на Аpple, так и просто JVM для Аpple.

Ну, насчет десктопа спорно. По-моему swing уже устарел морально. javaFX по слухам загибается тоже.

Нет, можно делать и десктоп, просто на Java предпочитают делать вебприложения, так как обычно Java используют в бизнес секторе, а там порталы удобнее десктопов. В принципе большинство задач можно решить с помощью вебприложений, если приложение только для win, то лучше взять что-то вроде C#, если приложение требуется кросплатформенное, то пойдет и Java.

[flancer]

Слой REST/JSON-сервисов в web-приложениях, если удастся вывести PHP из сферы действия Apache/Nginx и поднимать как standalone сервер (типа ExpressJS, Tomcat/java, WSGI/python). Ну или в рамках Apache/Nginx запускать PHP-приложения со стадиями инициализации приложения, обработки запросов, завершения приложения (типа servlet'ов). Делать вот это все на каждый GET/POST запрос с web'а — весьма расточительно, не говоря уже о сборке HTML'а на стороне сервера. В web-разработке позиции PHP весьма сильны, но с фронта всех теснит JS — остается back.

[Fedcomp]

есть php-pm

[flancer]

Да, очень похоже на то, что нужно :)

<?php
require 'vendor/autoload.php';

$i = 0;
$app = function ($request, $response) use ($i) {
    $response->writeHead(200, array('Content-Type' => 'text/plain'));
    $response->end("Hello World $i\n");
    $i++;
};

$loop = React\EventLoop\Factory::create();
$socket = new React\Socket\Server($loop);
$http = new React\Http\Server($socket, $loop);

$http->on('request', $app);
echo "Server running at http://127.0.0.1:1337\n";

$socket->listen(1337);
$loop->run();

[TSR2013]

Есть еще altorouter

[Fesor]

Из минусов — на данном этапе он требует php-cgi для воркеров, что я считаю недостатком. Я понимаю конечно почему так было сделано — поскольку в некоторых дурных скриптах стоят проверки на SAPI, но если хочется именно через CLI — то надо писать свой менеджер процессов.

[alekciy]

Почему недостатком?
Имхо, менеджер в более менее серьезном приложении приходится в любом случае писать самому.

[xotey83]

А также есть amphp/aerys — не просто сервер, но и с супервизором (как php-pm)
Мне кажется, что это самый развитый проект http-сервера на PHP

[merlin-vrn]

вывести PHP из сферы действия Apache/Nginx и поднимать как standalone сервер (типа ExpressJS, Tomcat/java, WSGI/python)

uWSGI с php-плагином очень к этом близок

[tribesman]

Я сначала сидел на php потом зачем то, пересел на rails, а потом снова вернулся на php + Yii. Сейчас мне очень нравиться PHP + Yii, а RubyOnRails вспоминать не хочется.

[tribesman]

На php очень дешёвая инфраструктура, легко поддерживать проекты на Yii ( мне кажется, что именно благодаря рельсам на php появилось столько замечательных фреймворков), при этом на php 7 + Yii порог входа все же сильно ниже .Net

[varanio]

Да, Yii точно был создан по мотивам рельсов

[zorgzerg]

Yii — отличен, и про порог входа верно сказано. Я, не имея никакого практического опыта веб-разработки быстро въехал, и даже начал что-то делать. Но надо сказать, что у Yii, все же, неплохая документация, хотя есть и сложные (для не профессионала, по крайней мере) моменты, этого не отнять

[v-derckach]

Ух ты! Сколько встречал историй ухода с php на Python+Jango или Ruby+RoR, абсолютно все они заканчивались словами «о php теперь и вспоминать не хочется!»
И вот впервые встретил хотя бы кого-то, кто сказал, что вернулся с рельсов на php и о рельсах не хочет вспоминать!

[dizews]

я вам больше скажу, в последнее время, тенденция что ли формируется, обратный переход на php. Сужу по общению с работодателями, которые говорят: «мы переписываем с rails или даже java на php» Хотя может это связанно, опять таки, с относительной дешевизной рабочей силы.

[jrip]

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

[DieSlogan]

Если уходили действительно, когда на PHP было кошмарненько, то приходя в Java/Spring сначала одуревали от сложности этой штуки, а потом говорили — вау, практически ничего не надо делать, само заводится и круто пашет.
Сейчас, соглашусь, переходить сейчас чуть проблемнее ибо те же фреймворки, только иначе.

[vshemarov]

Про тенденции сказать не могу, но знаю несколько проектов, которые изначально создавались на Руби, а сейчас переписываются на ПХП. Примечательно, что во всех случаях основным мотивом создания на Руби было то, что на нем «невозможно писать плохой код» (до сих пор популярное утверждение среди рубистов). Но потом оказывалось, что код-то, может, и красивый, но от плохого результата это не спасает, а найти людей на поддержку и сопровождение тяжелее и дороже. А на ПХП с его низким входом не только говнокодеры плодились, но и вполне себе грамотные программеры выросли

[alekciy]

Наверное сказывается выход PHP7 и информационный шум связанный с этим. Много обсуждений, разговоров. И он да, действительно получился достаточно вкусным. От расширения DS вообще пришел в полный восторг (нужны были множества, оказались, что они там работают даже быстрее, чем в Redis).

[ls18]

ИМХО, пока в PHP можно писать как хочешь(не используя ООП и кучу других печенек), то поток «вечных новичков» в PHP не уменьшится. Но есть вопрос: ведьPython тоже не сложный, так почему там такого нет?

[Archon]

Потому что на нём сложнее написать Hello World и мгновенно получить положительную эмоцию от того, что всё завелось. Порог входа в PHP действительно самый низкий из всех платформ на рынке. Можно просто положить файлик из одной строчки на копеечный хостинг и всё заработает само собой.

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

[Zazza]

Часто, почему-то сравнивают с .net. Но копеечный хостинг и windows сервер с iis это разные категории.
Недавно проскакивала статься про delphi, и там было правильно подмечено, что огромное число разработчиков на delphi перешли на сторону .net. Те же кто испытывал «теплые чувства» к unix перешли на другую сторону и выбрали perl, php.
Про себя скажу, что я много лет проработал администратором разных unix, поэтому и php. И кстати python с django, но это спустя много лет, после php4 и затем php5 (как было правильно замечено, что 4 и 5 это разные, если не языки, то принципы и подходы). Сравнивать, что лучше python (или отдельно django) или php считаю не уместным, всё хорошо где-то на своём месте.
И еще вектор развития задаёт учеба. Раньше в институтах изучали pascal+delphi. Сейчас появилась тенденция преподавать python.
Еще роль играет география. Если на php вакансии есть везде, то c# это Москва и филиалы. А разные местечковые компании выбирают 1с-bitrix.
Так и получается, что php универсальнее и переживет много других языков, хотя идейным вдохновителем для других не был и не будет.

[Archon]

У PHP есть ещё одно важнейшее преимущество, о котором многие профессиональные разработчики успешно забывают. Сайт на PHP — это просто набор скриптов, раскиданных по разным каталогам. Надо добавить на существующий сайт форум? Качаем движок форума, кладём его в /forum, всё мгновенно заводится. Клиенты попросили отдавать им какую-нибудь мелкую фигню в их формате? Не вопрос, пишем маленький скриптик, кидаем туда же, и он просто берёт и работает. Не надо перенастраивать сайт, не надо пересобирать весь проект, не надо ничего хитро проксировать, даже не надо ничего перезапускать, просто кладёшь файлик и он работает.

Поэтому никаких разумных альтернатив PHP для отдачи по HTTP кучи бессвязной фигни, не объединённой в общее понятие «приложение», я не вижу.

[Zazza]

Ага, заказчики или люди из другого «лагеря» не понимают, почему я:
— «Не хочу подзаработать и сделать маленький сайтик на wordpress, там делов-то на пару часов»
или:
— «Как? Ты не знаешь „1С-Bitrix!?“

Php очень сильно расслоился на крайности между cms и symfony с doctrine. Ну и люди, там мечутся соответствующие, я бы еще третий лагерь, где-то между выделил — YII. Ничего не имею против, отличный инструмент, прям даже уникальный получился.

[ls18]

Можно по подробней про Yii? В чем его уникальность? Это не попытка оспаривания, а чистый интерес. Сам сейчас работаю ~1.5 месяца с Yii2.

[Zazza]

Что на ум пришло (если подумать, можно еще придумать):
— порог входа ниже чем у того же symfony
— следует из предыдущего, удачно выбранные инструменты/функционал: приятный AR, ненавязчивый DI, хорошо и понятно структурирован внутри, без всякий сервисов, бандлов. Но если требуется, можно и закопаться в более advanced решениях
— много и очень много виджетов и плагингов, причём как низкоуровневых, так и для фронтенда
— достаточно хорошая поддержка и развитие, здесь же много информации в интернете

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

[Zazza]

Решил добавить: я прохладно отношусь к yii. За то, что для большинства разработчиков это первый фреймворк, они не знаю паттернов, антипаттернов, psr. Продолжать чужой проект на этом фреймворке — боль, прям как во времена php4. Но тогда я был моложе и лезть в чужой код было неким experience.

[0x9d8e]

Вот я такой разработчик. Два-три года писал почти только на собственном CMF компании, перерос его и больше не хочу с ним работать над проектами «сложнее полугода». До этого пару лет писал либо на всяких вордпрессах, либо на голом php. В ближайшее время собираюсь начать проект на YII2 и немного беспокоюсь о том, что буду сильно велосипедить. Большинство паттернов и антипаттернов описание которых встречал вызывали реакцию «эх, это всё уже описано, а я так долго сам к этому шел через все грабли». К PSR кмк мне просто привыкнуть нужно, тем более, что к некоторым вещам оттуда как раз сам начал приходить.
Но беспокоит то, что не знаю лучших практик и рискую вляпаться. Беспокоит, что не знаю библиотек, расширений и, скажем так, практики их применения т.е. какие там есть неявные проблемы, нужно ли заранее к этому свои обёртки написать или можно считать «верным клинком». Не знаю кода фреймворка «в глубину» и сложности которая стоит за вызовом каждого метода.
Толкового описания таких вещей не попадалось, а сам могу это всё приобретать ещё год-два.

[Fedot]

Серебренной пули нет.
Идеально в твоём случае попасть в хорошую команду, где есть люди с понимание и опытом.

Вот я не очень люблю Yii, из за того что мне кажется он уж слишком мало пропагандирует best practics программирования, типа SOLID.
При этом я не могу сказать что, например, Symfony это прям то что нужно что бы эти практики постичь.

Идеально на мой взгляд писать код так что бы он не зависил сильно от фрэймворка. Т.е. когда вся бизнес логика заключена не в ActiveRecord модели, как часто бывает как раз в Yii, и не в контроллерах, а в отдельном месте, и уже для этой логики используется обвязка для использования фрэймвоком этого когда.
А вот как это написать, может сказать только опыт и хорошая команда, в которой такие вещи можно обсудить.

[0x9d8e]

Насчёт отделения кода от фреймворка и библиотек как раз думал. Раз уж не я один такой, то и сомнения прочь. Спасибо. upd: Сейчас вспомнилось как прошлой осенью очень пожалел, что не делал так.
А с командой печаль. Сейчас, можно сказать, один работаю (если клиента, ПМ и маркетологов не считать). Иногда перед кем-то из удалёнщиков в роли живой документации и справочника «а как тут вот такое сделать?» выступаю, вот и всё взаимодействие. Можно было бы место работы сменить, да не хочется, полюбил уже всё. Так что как всегда всё самому.

[Fesor]

Как жаль что люди не собираются в уютных чатиках и не филосовствуют на тему "как делать хорошо".

[0x9d8e]

Сидят. Сижу в таком чате по D https://telegram.me/dlangru
Можно и по PHP такой создать, но мне кажется там бардак будет.

[Fesor]

https://telegram.me/prophp7 — тут душевненько. Ну и там есть смежные ссылки еще на чатики забавные.

[zugo]

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

[v-derckach]

Что не мешает поставить форум в подкаталог.

[http2]

Действительно?

Это в любом фреймворке единая точка входа.

[varnav]

Я примерно то же самое писал несколько месяцев назад, но был заминусован. :)

[PQR]

Отлично подмечено про отдачу кучи бессвязных данных по HTTP не объединённых в «приложение». PHP скрипты по разным папкам — это же микросервисы!

[edogs]

пока в PHP можно писать как хочешь(не используя ООП и кучу других печенек), то поток «вечных новичков» в PHP не уменьшится

Нас всегда удивлял этот «парадокс».
Хочется сложностей? Выбирай яву и ныть по поводу наличия новичков не надо будет.
Что за то ли эгоизм, то ли садомазохизм — выбирать язык где новичков по определению много, а потом ныть по поводу их наличия и требовать «усложнить» язык, что бы новичков оттуда выгнать?
Типичное «залез в монастырь со своим уставом». Ну хочешь сложного языка — выбирай сложный, зачем выбирать простой и прогибать его под себя требованиями усложнить?

[ls18]

А если в твоем городе есть вакансии только под этот язык? В том числе и джуниор позиции? И уехать никак?

[edogs]

Тогда возможно стоит купить в магазине книгу об интернете и узнать наконец о возможности удалённой работы. Особенно если речь о веб-вакансиях.

p.s.: «уехать никак» это всегда не более чем повод остаться, когда уезжать не хочется. Если Вы конечно не в колонии поселении отбываете.

[ls18]

Кто же удаленно возьмет на работу человека без опыта?

[vedenin1980]

Фриланс это тоже удаленная работа, а в фрилансе и без опыта можно получить проект вопрос только в оплате.

[Dromok]

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

[Fesor]

Желательно еще дать эти проектики на ревью (они ж для себя, не под NDA). Благо нынче сложностей с этим нет.

[Dromok]

Если цель зарабатывание на фрилансе, то рефакторинг это лишнее. Тут главное побыстрее наклепать то что хочет заказчик, а качество кода второстепенно. Чем меньше потратишь на проект времени, тем больше в итоге заработаешь. Я лично не парюсь над качеством кода, поэтому код никогда не рефакторю. Правда у меня школа хорошая была — несколько лет в иностранной компании проработал, где делали ревью всего моего кода, и отправляли на рефакторинг если что-то не нравилось. Поэтому имхо у меня сейчас получается достаточно качественный код, так как натаскали меня, но качество кода вообще для меня на десятом месте.

[Fesor]

Если цель зарабатывание на фрилансе, то рефакторинг это лишнее.

Смотря что подразумевать под "рефакторингом". Речь идет о поддержании уровня технического долга на нужном уровне. Если говнокод изолирован — он не приносит много боли. А без опыта "изолированности" не выйдет.

Правда у меня школа хорошая была

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

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

[ls18]

А можно узнать, на чем вы пишете и на какой бирже работаете(вангую Upwork)?

[Dromok]

Yii2, fl.ru. Честно, не понимаю почему на хабре эту биржу не любят. Одно дело, что качество кода их сайта низкое, но ведь не ради этого фриланс биржами пользуются. Но зато заказов там навалом, поэтому там и сижу. Единственная русскоязычная биржа с таким количеством заказов. Upwork пробовал, но там конкурировать с индусами очень сложно и как не парадоксально но на fl.ru в этом плане всё на порядок лучше, т.к. практически сразу реально найти заказ.

[edogs]

почему на хабре эту биржу не любят

Несколько взломов с раскрытием данных, неадекватное разрешение СБР, конские тарифы на всё, мониторинг личных сообщений администрацией, безосновательные задержки выплат денег и так далее — можете почитать на фл.ру в блогах отзывы пользователей.
Ах да, не можете, когда пошло много объективных негативных отзывов в блогах — их снесли на фиг безвозвратно.

[Dromok]

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

[edogs]

А зачем зацикливаться на русскоязычном сегменте, тем более с многолетним стажем в иностранной фирме? Иностранные биржи во многом лучше.

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

Хотя в свое время мы были достаточно активными его пользователями.

[Dromok]

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

[edogs]

есть пул постоянных клиентов

Так и работать с ними напрямую, а не через фл.

необходимости, по крайней мере сейчас, уходит на запад нет

В нулевых не было смысла работать на россию, на западе платили на порядок больше. Постепенно уровень оплаты выровнялся, где-то к 8 году был достаточно близок, но 14 год отбросил российские уровни оплаты в 2 раза.

[Dromok]

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

[elmm]

Интересно, а что может быть причиной прям что «уехать ни как»? (кроме как ни хочется)

[Dromok]

Имхо, не мало причин может быть. Лично я цель — «уехать», никогда не ставил. Но, например, у меня жена ни в какую не хочет уезжать жить далеко от родителей, поэтому даже если бы я захотел уехать, это было бы очень сложно осуществить из-за жены :)

[VolCh]

Подписка о невыезде? )

[w4r_dr1v3r]

Вот кстати да. Очень верно подмечено.

[VolCh]

Ну, «уехать никак» — это обычно гипербола.

[Aleks_ja]

Никто не заставляет на пхп писать «по-сложному», брать какой-нибудь фреймворк.

[vanxant]

Да и не все фреймворки прям таки ужас-ужас монстры с килотоннами документации для написания хелловорлда.

[fishca]

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

Скорее из-за банальной лени. Кто хочет идти вперед, тот не стоит на месте. Наблюдается та же самая песня в мире 1С при переходе от использования обычных к управляемым формам. Кому-то удобнее сидеть в теплом и обжитом болоте, а кто-то перестраивает себя и свое окружение.

[XXXXPro]

Есть еще один вариант: за эти годы разработчик выработал определенные привычки написал себе собственный мини-фреймворк, которого для задач его уровня вполне хватает, и переучиваться на большие смысла нет: в плане результата получаем примерно то же, но свое все же удобнее тем что свое. (Мой случай как раз.)

[Fesor]

Вы поддерживаете все написанные вами проекты? Если да — то ок. Если нет, то для "других" разработчиков "ваше" будет "чужим" и чем больше вы делаете "для себя" тем хуже вы делаете бизнесу, внося огромные риски при поддержке. Да, риски могут не оправдаться (вдруг "ваше" на самом деле неплохое), но всеже.

[DmitryKoterov]

Ну следующим шагом должен быть уже async-await, наконец. Ядро почти к этому готово, осталось event loop встроить в язык, планировщик и библиотеку примитивов для кантования промисов туда-сюда. (Надеюсь, их назовут промисами здесь.)

[xotey83]

Не думаю, что async/await появится раньше версии 8.0
В 2015-м году было обсуждение в php internals. Длинное, тяжёлое.
https://www.mail-archive.com/[e-mail]/msg80837.html

[DmitryKoterov]

Ну почему оно «тяжелое», вроде бы обычный и даже типичный спор между теми, кто понимает, о чем идет речь, и теми, кто не очень. Главное, Дмитрий Стогов настроен позитивно (как мне показалось). Надеюсь, что все же реализуют в первую очередь из следующих больших вещей, потому что иначе опасно… скоро язык без async-await будет так же восприниматься, как язык без… в общем, как Фортран. :)

[merlin-vrn]

Следующим шагом должна стать нормальная, последовательная библиотека. С последовательным порядком аргументов. С последовательным наименованием, а не mysql_query и htmlspecialchars. Не быть тонкой обёрткой над C, и вообще с нормальными абстракциями, а не mysql_real_escape_string. С нормальными обобщениями, а не кучей функий sort/ksort/krsort/usort и так далее.

Пора чистить мусор и выкинуть вот это всё легаси. Тем более, раз уж всё равно порог входа вырос, как вы утверждаете.

[varanio]

Для баз уже все ползьуются PDO
А вот сортировка да, там всё хаотично

[san4ez]

в PDO тоже есть щепотка хаоса, которая вынуждает использовать ту же доктрину, например.

[merlin-vrn]

я понимаю, так вот стоит выпилить тогда из ядра, чтобы остался только PDO

[Corpsee]

Так их и выпилили в 7.0

[v-derckach]

С одной стороны я приветствую приведение всех тех тонн функций к консистентному виду. Как сказал один программер:

array array_filter ( array $input [, callable $callback = "" ] )
array array_map ( callable $callback, array $arr1 [, array $… ] )
Это нельзя понять. Это можно только запомнить

С другой стороны это будет уже не php. Сейчас ещё довольно многие скрипты, написанные под php4, можно запустить под php7.1. Да, скорей всего придётся поправить deprecated и т.д.., но переписывать КАЖДЫЙ вызов КАЖДОЙ функции не придётся. А в случае такой радикальной чистки авгиевых конюшен придётся править и все-все исходники, написанные даже под 7.1. На такой радикальный и резкий слом никто не пойдёт.

[merlin-vrn]

Это переход по смыслу эквивалентен переходу на Py3. Да, некоторое, довольно длительное время, будет два варианта, в старый не вносить новые фичи, чтобы разработчики потихоньку переходили на новый.

[v-derckach]

Вот, мне кажется, пример питона как раз (в том числе) и удерживает создателей языка от такого резкого масштабного изменения. Причём, раз уж его не сделали в php7, когда всё равно резко и масштабно многое поменяли, мне кажется, уже и не сделают. Революционно не сделают. Возможно, сделают эволюционно, за много версий.

[Akdmeh]

Всегда думал: а что мешает создать параллельно специальные объекты для управления стандартными типами.
К примеру:

<?php
$var = array(5, 444, 121);
$var_obj = new SplArrayWrapper($var);
$var_obj->map('someFunction');
?>

То есть, создать специальные оболочки, построенные более грамотно и последовательно, но при этом не нарушающие совместимость?
Ну, как минимум в моем примере идет оверхед на создание нового объекта, но все же, что мешает применять похожий подход?
Я понимаю, подобную оболочку можно написать за пару часов на PHP, но намного большей производительности можно было бы достичь, если написать код на C.
Недостатки, которые я вижу — это еще большая фрагментированность, так как часть кода будет на новых функциях, часть — на старых, и при этом будут возникать кое-какие различия между ними в принципах работы…
Но все же, это лучше, чем рубить с плеча совместимость со старым кодом.
Ну или мириться с тем, что без подсветки параметров функций никогда не можешь быть уверенным, где haystack, а где — needle, что раздражает в современном PHP чуть ли не больше всего

[MetaDone]

https://github.com/nikic/scalar_objects
подобное уже есть

[Akdmeh]

Да, конечно, это интересная реализация и уверен, существует с десяток отличных библиотек на PHP. Но это — расширения и внешние библиотеки, а я размечтался о подобном в стандартной поставке PHP и написанное на C.

[Fesor]

функции аля mysql_query и mysql_real_escape_string были удалены из PHP еще в версии 7.0.

Не быть тонкой обёрткой над C

То есть предлагаете реализовать стандартную библиотеку на PHP? Не ну можно, но это тогда ждем JIT.

С нормальными обобщениями, а не кучей функий sort/ksort/krsort/usort и так далее.

А что именно вам тут не нравится? У каждой функции свое поведение. Нужно сортировать ключи — юзаем ksort. Реверсивная сортировка по ключам — rksort.

Если вам не нравится — вы всегда можете сделать так:

// std.php

namespace array {
    function reverseKeySort(iterable $array): iterable  { \rksort($array); return $array;}
    function keySort(iterable $array): iterable { \ksort($array); return $array);
    function split(iterable $arr, ?string $delimiter): iterable { /** ... */ }
    function join(iterable $arr, ?string $glue): string { /** ... */ }
}

namespace str {
   // по аналогии
}

Я часто вижу вот такое вот "надо переименовать" но никто не переименовывает почему-то.

[merlin-vrn]

Функция сортировки должна быть ОДНА и она должна быть универсальной, с сигнатурой вида:

sort(seq, compare_func)

Порядок сортировки, способ сравнения аргументов (что там, массив целых? Массив хешей и сортируем сначала по полю "size" а потом, если совпало, по полю "weight"? Что угодно) задаётся compare_func, которая принимает два объекта и для них выдаёт ответ: 1 если arg2 должен стоять после arg1, 0 если они равны и -1 если arg2 должен стоять до arg1 в отсортированном массиве.

Для PHP есть примечание — в нём массивы — не массивы, а смесь из массивов и словарей, поэтому в данном случае у коллбек-функции может быть не два, а четыре аргумента — k1 v1 k2 v2, где k — ключ аргумента, v — значение; остальное по-прежнему.

А уж если вспомнить, что есть лямбды, так этот подход вообще идеален. Они как раз и придуманы специально для таких случаев.

[varanio]

вообще-то в php уже есть usort
правда нет стандартных compare_func для неё

[merlin-vrn]

В общем, для того, чтобы стало хорошо, надо теперь убрать старые костыли. Ну и да, стандартные функции сортировки стоит запилить. И хорошо бы, чтобы они в свою очереь всё-таки были параметризуемые.

[Fesor]

Функция сортировки должна быть ОДНА и она должна быть универсальной, с сигнатурой вида:

Ну так сделайте обертку на PHP и распространяйте как composer пакет. Вам же никто не мешает.

А уж если вспомнить, что есть лямбды, так этот подход вообще идеален.

Еще бы каррирование нормально можно было бы делать, вообще б зажили. А еще что бы лексические скоупы а не "один скоуп где все живет и локальный куда надо через use явно копировать".

[michael_v89]

Думаю, лучше наоборот сделать — привести язык в порядок, и сделать composer пакет или расширение, которое включает старые названия.

[Fesor]

Можно организовать к версии 8.0. RFC и вперед.

[franzose]

В семёрке (только на ней проверял) можно осуществить такой вызов:

(func(...$args))(...$args);

То есть почти как в JavaScript, но с дополнительными скобочками.

[Deosis]

А что именно вам тут не нравится? У каждой функции свое поведение. Нужно сортировать ключи — юзаем ksort. Реверсивная сортировка по ключам — rksort.

Есть массив клиентов, как их отсортировать так, чтобы вначале шли вип-клиенты, а потом обычные. Далее отсортировать по именам?

clients.OrderByDescending(c => c.IsVip).ThenBy(c => c.Name)

[Fesor]

// Client.php
// ...
public static function byStatusAndNameComparator(Client $a, Client $b) 
{
    if ($a->isVip() === $b->isVip()) {
        return $a->name <=> $b->name;
    }

    if ($a->isVip()) return -1;
    if ($b->isVip()) return 1;
}

Ну и где надо отсортировать

usort($clients, [Client::class, 'byStatusAndNameComparator']);

что-то в этом духе.

Ну и да, всегда можно сделать что-то типа linq или вообще дикость, сортировать средствами sql.

[wxmaper]

По поводу JIT — это есть у jphp. Вообще он больше предназначен для «GUI на пыхапе», но вроде и для сайтов тоже подходит.

[SerafimArts]

Это есть и в обычном php в веточке jit в репозитории от zend tech, внутри расширения opcache =)

[paratagas]

На мой взгляд, порог входа в PHP в целом вырос из-за того, что получили широкое распространение фрэймворки типа Symfony, Laravel, Yii и др., которые побуждают писать красивый код в ООП-стиле и изучать лучшие практики ООП. Причем фрэймворки активно и своевременно обновляют свои версии под новые версии PHP. Но это верно в основном только для PHP-фрэйморков. Если взять тот же Wordpress (или некоторые другие CMS), то ситуация здесь иная. Глядя на код ядра CMS в некоторых местах и многих плагинов под него иногда волосы дыбом встают. Там просто «лапша» из HTML и PHP, смешанного в самых неожиданных местах. Плюс в качестве основной версии языка выбирается не самая свежая, а 5-10 летней давности, потому что иначе теряется обратная совместимость. В целом экосистема PHP в последние годы переняла лучшее из опыта других языков и платформ и (что радует!) продолжает это делать.

[Rastishka]

Зато в UTF-16 всегда прилетает 2 байта, а в случае UTF-8 может прилететь как 2, так и 1 байт, как повезет.

Поэтому мне тоже кажется, что проще работать с UTF-16 чем с 8, и я тоже удивлен почему разрабы считают иначе.
Кто в теме, может объяснить?

[pacaya]

Не всегда. Иногда символ может выражаться двумя 16-битными словами https://ru.wikipedia.org/wiki/UTF-16

[Melkij]

Почему всегда? В utf-16 же может прилететь один символ в 4 байта.
Фиксированная ширина юникода — это только UTF32
В utf8 может существовать символ из 1, 2, 3 или 4 байт. Последний ли это байт в последовательности — определяется по крайнему биту (старшему или младшему — простите, я их вечно, откуда их надо считать)

[Rastishka]

Да, был не прав, спасибо за прояснение.

[Fesor]

Поэтому мне тоже кажется, что проще работать с UTF-16 чем с 8

Почитайте почему PHP6 не взлетел

[vanxant]

В 7.1 приняли очень спорное решение выпилить настройку mbstring_overload. Кто не в курсе, она прозрачно заменяет однобайтовые строковые функции на многобайтовые.
До сих пор юзается куча легаси-кода, которая не знает про многобайтовые кодировки, но с этой магией нормально работает. Да что там легаси, тот же битрикс штатно работает на этой фигне.
Самое плохое, что нормальной замены до сих пор нет. Есть куча корявых функций из расширения mbstring, типа mb_substr вместо substr. Но оно не является нормальной заменой, так как а) для ряда функций типа регулярок (тот же preg_replace) замены 1-в-1 просто нет; б) часть вещей типа строка-как-массив ($str[2]) в принципе не заменяемая и в) заменить все строковые функции из всех используемых либ, шаблонов и т.д. — то ещё развлечение на тему рефакторинга.
То есть я бы понял, если бы они сначала запилили нормальные многобайтовые строки в ядро, а потом уже воевали с костылями. Но нет.
Поэтому, мне кажется, PHP надолго застынет в версии 7.0.

[Melkij]

Тот же preg_replace умеет сам в юникод. Модификатор u только указать

[vanxant]

Особенно качественно он в него умеет, если таки включен mbstring.func_overload
(дисклеймер: не пытайтесь это повторить в реальном проекте)

[batyrmastyr]

Вот видите, без подмены функций одной проблемой меньше )
А с третьим пунктом: увы, неизбежная расплата за изначальную завязку на костыли.

Эх, ещё бы setlocale кто-нибудь догадался выпилить.

[alekciy]

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

[dimack]

Мне кажется, PHP жив и будет пока жить, потому что за эти лет 15 накопилась огромная база написанных сайтов, к тому же выросло большое количество PHP-разработчиков. Новые проекты начинают писать на PHP, потому что найти среднего уровня разработчика не так сложно и стоить он будет в среднем дешевле.
PHP сейчас пожинает плоды так сказать своей былой и бурной популярности.

Но эта гонка языка за Java ни к чему хорошему не приведет. Разработчики обучившись ООП, DDD, TDD итп в PHP потом начинают переходить на сам Java, потому что там возможностей на порядок больше. А те, которые хотят что попроще, смотрят в сторону Gо, Python, может JavaScript.

Поэтому с трудом верится в светлое будущее PHP. А вспомнить его исходники и муки написания расширений(по сравнению с ffi того же Python), так вообще перекреститься хочется.

[Aleks_ja]

Знаю людей которые, в своё время, отказались переходить на Java и решили сменить место работы, когда проекты на php закончились.

Лично мне, когда нужно написать какой-то код на Java — жутко бесит. Как-то переносил кусок кода из Java в PHP — в итоге, задумавшись, строк 100 Java кода заменил одной строкой PHP.

[terryP]

Лично мне, когда нужно написать какой-то код на Java — жутко бесит. Как-то переносил кусок кода из Java в PHP — в итоге, задумавшись, строк 100 Java кода заменил одной строкой PHP.

Такое бывает только если плохо знать Java (и хорошо на PHP), на ней тоже можно писать быстро и коротко, другое дело что для этого нужно её довольно неплохо знать.

[VolCh]

Разработчики обучившись ООП, DDD, TDD итп в PHP потом начинают переходить на сам Java, потому что там возможностей на порядок больше. А те, которые хотят что попроще, смотрят в сторону Gо, Python, может JavaScript.

Вы не поверите, но есть и те, кому множество возможностей Java (как вариант C#) кажутся излишними, но тянущими лишний оверхид (хотя бы в виде необходимости компиляции), но «попроще» тоже не устраивает, хочется многоуровневых абстракций, инкапсуляции, сокрытия и т. п… Из скриптовых языков PHP больше всех, субъективно, подходит для ентерпрайза и как язык, и как экосистема. Только одна Doctrine даёт огромную фору по сравнению с другими скриптовыми языками. В экосистемах Ruby и Javascript ничего подобного нет, в Python — похожа sqlalchemy, но по защите данных PHP уже как язык отрывается.

[knagaev]

Когда уже, в конце концов, эту КДПВ запретят Женевской конвенцией…

[dmtrrr]

PHP как был fractal of bad design, так им и остался. Делать на нем что-то можно, но не нужно.

[dmtrrr]

Минусующие, вы хотя бы понимаете, что у вас стокгольмский синдром?

[Anakros]

А у вас отсутствие не только весомых, но и аргументов вообще. Зачем был написан комментарий?

[dmtrrr]

Все аргрументы давно известны: PHP: a fractal of bad design
PHP имел понятную нишу в эпоху shared hosting, сейчас смысла в этом «языке» нет.

[xotey83]

Статья 2012-го года. С тех прошло больше 4-х лет. С тех появились вышли версии 5.4, 5.5, 5.6, 7.0, 7.1
PHP шагнул далеко вперёд.

Нет, ну некоторые момент остаются актуальными: неконсистентная стандартная библиотека функций, неконсистентная последовательность аргументов (haystack-needle). Но вещи, которые там описаны постепенно становятся неактуальными. Посмотрите сколько было задепрекейчено к релизам 7.0, 7.1, 7.2
И это всё постепенно отпиливается.

Да, увы, тяжёлое наследие прошлого не даёт возможность сразу всё исправить и сделать красиво ибо тогда язык постигнет та же ситуация, которая сложилась вокруг раскола Python 2/3.
Но постепенно всё будет причёсано.

Зря вы так яростно апеллируете к этой уже очень старой статье.

З.Ы.
Очень надеюсь, что когда-нибудь этот RFC воплотят в жизнь (скорее всего, к версии 8.0): https://wiki.php.net/rfc/consistent_function_names

[dmtrrr]

Есть кривая технология, которую пытаются выпрямить.
Зачем тратить время на изучение/применение кривой технологии, если можно взять что-то сразу нормально сделанное?

[merlin-vrn]

Да любая прямая технология начиналась с кривого глючного hello, world-а. Если PHP выпрямят, будет только лучше. А фанатизм вида "говно всегда останется говном" как раз наоборот, ни к чему хорошему не приводит.

[dmtrrr]

Если сравнивать именно с php, то не любая.
И я видел какой код пишут php программисты, и как кривизна языка отражается на них.
В 2016 году есть альтернативы, поэтому начинать что-то делать на php довольно странно.

[SerafimArts]

А ну-ка? Вот простой класс сообщений: https://gist.github.com/SerafimArts/798adfa04844bc3b311620a930c7727a чем этот код отличается от джавовского или шарпеца, например? Ну за исключением того, что он на порядок лаконичнее. Где эти хвалёные "костыли", которых я из-за "замыленного" глаза просто не замечаю?

[SerafimArts]

P.S. Если не найдёте — это некоторый повод задуматься на тему: "Может вы видели код совсем даже не программистов, а любителей, которых в любом языке предостаточно?"

[terryP]

Ну за исключением того, что он на порядок лаконичнее. Где эти хвалёные «костыли», которых я из-за «замыленного» глаза просто не замечаю? Ну за исключением того, что он на порядок лаконичнее.

Банально:

 if ($this->rendered === null) {
            $this->rendered = $this->injectParameters($this->body->textContent, $this->parameters);
        }
return $this->rendered;

На Java (которую ругают за многословность) записалось бы как:

     if (rendered == null) {
            rendered = injectParameters(body.textContent, parameters);
        }
    return rendered

Без всяких ужасных многократных $this и созданий лишних переменных. Так что

на порядок лаконичнее.

Крайне спорно.

[vedenin1980]

удалено

[SerafimArts]

В пыхе это тоже можно заменить, например на return static $rendered = $this->injectParameters(...);, что будет ещё короче, но плохо с точки зрения качества кода.

Согласен на счёт возможности опускания this, но это просто из-за того, что в джаве просто нет общего неймспейса, отсюда в пыхе требуется явное указание контекста, для исключения аффектов переопределения методов глобальным неймспейсом. Так что это, по-моему, не проблема языка, а способ реализовать те возможности, которые просто захардкожены в джаве (имеется ввиду автоимпорт java.lang.String и аналогичных).

[dmtrrr]

Вы приводите один класс, к-й почти ничего не делает. Что это должно показать?
Я, например, видел как люди писали в лог без таймстэмпа, то есть элементраные вещи делали криво.

[merlin-vrn]

Так эти люди и в django не встроенный механимз логирования (модуль python logging) будут использовать, а писать в текстовый файлик без таймстампа. Язык-то тут при чём?

[dmtrrr]

Язык при том, что люди привыкшие к тому, что есть http запрос и магически сформированные глобальные массивы, плохо понимают все что выходит за эти рамки.
А современный бэкенд это далеко не всегда обработка http запроса.

[SerafimArts]

Ну так я и показываю пример только того, что какие-то косяки языка — довольно стереотипны, при этом явно написал об этом, парируя утверждение про то "зачем M, если есть N". Так же явно упомянул, что если вы сталкивались с любителями — это не значит, что все такие.

А отвечая на ваш пример, могу даже сообщить, что в пыхе есть рекомендация (которую в 2016ом году можно считать стандартом) по реализации логгирования: http://www.php-fig.org/psr/psr-3/ И соответсвующая популярная либа, реализующая PSR-3: https://github.com/Seldaek/monolog/tree/master/src/Monolog/Handler То, что кто-то делал логи без даты как раз и говорит об уровне знаний ваших знакомых, а не о языке и его сообществе.

В каком ещё языке есть интерфейс логгирования на уровне почти что стандарта? Где написаны адаптеры под все возможные популярные APM и сервисы? И да, они с таймстампом.

[dmtrrr]

Вы говорите, что если сильно прищурить глаза, то php будет похож на java. Ну офигеть теперь.
Эти любители проходили собеседование и получали зарплату, так что не нужно додумывать.
Например, в python модуль logging входит в стандартную библиотеку.

[http2]

А на чем лучше стартовать проект, имея опыт PHP и не имея опыта другого серверного языка? :)

[merlin-vrn]

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

Короче, считайте, что если вы хотите не наговнокодить по-быстрому, а реально делать проект по-человечески, у вас нет опыта нового PHP. И далее — см. рис. 1

[http2]

Я как бы уточнял на

В 2016 году есть альтернативы, поэтому начинать что-то делать на php довольно странно.

К чему Ваша писанина, я хз. :)

[merlin-vrn]

К вашему "имея опыт PHP" — я говорю, что ваш "опыт PHP" нерелевантен. Вам следовало сказать: "не имея опыта разработки сайтов ни на каком современном языке".

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

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

[SerafimArts]

Прошу заметить, что процентов 80% этих вредных советов из прошлого PHP являются стандартной практикой, например на JS + Node в настоящем. Да, конечно, некоторые неактуальны в связи с наличием commonjs, манки-патчинга и прочих штук, но в целом ведь картина примерно такая же, нет?… Открываешь сырцы какого-нибудь JQuery (до компиляции т.е.) и вспоминаешь времена тысяч реквайров и чистой процедурщины на пыхе 4, ностальгия ;)

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

[http2]

Сравнивать JQuery и PHP — как бы не совсем правильно. :)

[SerafimArts]

Сравнивать подходы в одном языке и в другом, а не сравнивать либу с языком. =)

Как давно вы в php видели код подобного вида? А в JS?

<?php
return (function() {
    function a() {
        // ...
     }
})();

[http2]

В мире PHP слабо используют функциональную парадигму. :)

В исходниках JQuery — дерьмо (из-за ограничений языка)?
Сейчас или в году эдак 2008? :)
В JS тоже много нового с 2008 года.

[SerafimArts]

Там ES6, какие ограничения языка при наличии бабела, вы что? =)

На современный пых больше всех похожи исходники Ангулара и Аурелии. Если бы только добавить правило "один файл — один модуль/класс" можно было бы ими даже восхищаться.
Для примера, JS: https://github.com/angular/angular/blob/master/modules/%40angular/router/src/router.ts PHP: https://github.com/illuminate/routing/blob/master/Router.php Подходы очень похожи, родственные я бы сказал.

Но если эти две штуки (Angular + Aurelia) скорее исключение из общего правила node-сообщества и скорее специфика TS (исключение, учитывая наборы решений в npm), то в случае пыха процентов 90% пакагиста содержит код подобного уровня.

[SerafimArts]

P.S. Хотя, начиная с 579ой строки в ангуларе начинается просто неперевариваемая дичь без единого комментария "зачем и почему", достигающая апогея к 1000ой. Макконнелл переворачивается в кровати, бедняга.

[http2]

Там ES6, какие ограничения языка при наличии бабела, вы что? =)

Так к чему было это? :)

Открываешь сырцы какого-нибудь JQuery (до компиляции т.е.) и вспоминаешь времена тысяч реквайров и чистой процедурщины на пыхе 4, ностальгия ;)

Что не так с исходниками JQuery?
JQuery использует бабель?

Значит Ангуляр и Аурелию писали php-программисты :)
Ну и то не JS, а TS. :)

[http2]

Бред.

Тогда ни у кого нету якобы релевантного опыта на php7.

Всем бросать из-за этого php и писать на чем-то другом?

В своем же рассуждении Вы отконились от первоначального вопроса.

По другим языкам тоже куча мусора гуглится.
А в том же питоне и вовсе 2 актуальные НЕСОВМЕСТИМЫЕ ветки, старая никак не умрет.
Возможно и в других языках такое.

Ну и мусор гуглился в 2000-ых.
Тогда параллельно существовали PHP 4 и 5.

Ну и не ответили на каком же языке стартовать проект.

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

Что характеризует преобладающее стадо на ресурсе.

[VolCh]

Чтобы капитально не переучиваться, нужно было переучиваться плавно, с релизом, а ещё лучше хотя бы с RC каждой значимой версией. И за тем, что в экосистеме творится следить постоянно, а не так что писал-писал на PHP3 «с нуля», а тут бац и на 7.1 решил перейти с композером и симфоней или зендом.

[http2]

Чтобы капитально не переучиваться

Неправильная постановка вопроса.

А зачем вообще переучиваться? Почему это стало догмой?

Старый код продолжит работать, нужно поправить чуток deprecated, но это было и между минорными релизами.

Кому нужны новые фичи, пускай учат.
Какие это фичи? Строгая типизация? Чего там ее учить? :)

Сложно не учить, сложно программировать в строгой типизиции.
Именно из-за нестрогой типизации PHP и выстрелил.

А сейчас в язык пришла куча академиков, которые пытаются сделать из него Java.
Большинству это просто не нужно.

[VolCh]

Например, если компания в которой ты поддерживал проект на PHP3, решила его закрыть. Пускай он даже крутился последнее время на PHP5.6 фактически, может даже $a = [1,2,3] использовал, но ООП не использовал вообще. Очень маловероятно, что легко найдешь работу на современном рынке без переучивания — и тут не просто deprecated и syntax sugar надо выучить, а начинать в других парадигмах программировать, забыв процедурную с глобальными переменными как страшный сон.

[http2]

PHP3

Как всегда пример слабо связанный с реальностью. :)

Та боже мой.
deprecated они и так выучили, раз их проект на 5.6.
Будут переходить на 7 — выучат и 7.
Обратная совместимость PHP — еще один его плюс. А не как в уже упоминаемом питоне, фактически имеем 2 разных языка. :)

ООП?
Так в последнее время уже тренд говорить, что ООП — говно.
То наследование не стоит использовать. А без наследования и другие киты, на которых стоит ООП, имеют мало смысла.

Очень маловероятно, что легко найдешь работу на современном рынке

Да, вероятность найти работу падает. Сейчас ищут программиста не по умению думать, а по внешним признакам, вроде знания «чем отличается абстрактный класс от интерфейса», которые:
а) можно натаскать перед собеседованиями.
б) это вряд ли существенные детали. Это реализация. А реализация может быть любой, желательно самой простой.
в) это все равно не используется в проекте. :)

Если человек писал качественный код в процедурном стиле, то он будет его писать и в другом стиле. :)

Ну вот что дает Вам использование ООП? :)

[VolCh]

Абстракции и инкапсуляцию, как минимум.

[http2]

Этому сложно научится тому, кто не работал с ООП? :)
Можно перед собеседованием прочитать? :)

[VolCh]

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

Бумажка, ручка, любой псевдокод, любые вопросы.

[http2]

прямоугольника, квадрата и ромба

Вы хотите, чтобы квадрат наследовал и прямоугольника, и ромба? :)

У вас на проекте используется множественное наследование? :)

Кмк, человек, который ранее с ООП не работал, но имеет мозги, пройдет Ваш тест.

Вторая задача — вообще какой-то бред. :)

[varanio]

дело в том, что есть по сути два современных подхода: ооп и фп, у каждого есть плюсы и минусы. В старом пхп не было ни того, ни другого, только процедурки.
В новом есть нормальное ООП и какие-то зачатки ФП (лямбды и т.д)
Так что выбора особого не вижу тут.

[http2]

Вы о каком выборе говорите вообще?

На вопросы опять нету ответа. :)

[VolCh]

Зачатки ФП были и в PHP3.

[XXXXPro]

На мой взгляд, чего реально в PHP не хватает, так это легкого встроенного шаблонизатора с нормальным экранированием вывода. В результате приходится либо подключать сторонний (что оправдано для больших проектов, но очень сильно «утяжеляет» маленькие), либо городить вечные <?php echo htmlspecialchars();?>

[jrip]

А вы это как себе на практике представляете? Внезапно все echo будут по некой магической директиве принудительно прогонятся через htmlspecialchars, типа такая же веселая штука будет, как незабвенные magic quotes?

[Starche]

на практике это реализуется шаблонизацией) Какой-нибудь встроенный класс-парсер шаблонов с подставлением переменных.
Ну просто чтобы не тащить целый twig в домашнюю страничку.

[jrip]

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

[vanxant]

Нет, ну есть синтаксис <?=, могли бы добавить какой-нибудь условный <?#= для искейпа

[jrip]

В чем проблема для вас определить функцию и делать <?= p()?>? Забыть не сложнее чем <?#=, лишние пара символов играют роль разве? При этом экранирование оно как бы разное бывает, не везде хватит htmlspecialchars, а кое-где его будет много. Собтсвенно c помощью PHP не только html генерят.

[DmitryKoterov]

Не нужно даже ничего изобретать на тему экранирования — «все уже украдено до нас» ((с) «Операция Ы»), называется XHP:

https://facebook.com/notes/facebook-engineering/xhp-a-new-way-to-write-php/294003943919/
https://github.com/facebookarchive/xhp-php5-extension/blob/master/README.textile

Даже расширение для PHP есть, осталось его только включить в дефолтный список.

Вообще, это придумала Мозилла первая, кажется (они заметили, что синтаксис XML не противоречит синтаксису языка, поэтому XML-конструкции пожно вставлять в код не как сторки, а как first-coass citizen). Он позволили встраивать XML в JS при написани движка браузера/расширений. Идея, совершенно лежащая на поверхности, но почему-то потребовалось почти 20 лет, прежде чем она стала использоваться (так бывает; иногда мы совершенно не видим то, что прямо перед нами — другие примеры: async-await, а также банкльное колесо).

[michael_v89]

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

[jrip]

Но мысли там интересные и правильные.

Вообщем-то если подумать, например, когда мы генерим json,
то написание что-то вроде

echo('{var:"'.$var.'"}')

или

{var:"<?=$var?>"}

выглядит довольно странно и обычно так все-таки не делают.

Опять же при генерации XML, обычно стараются делать это на основе каких-то структур.

Однако в Html для браузера мы привыкли делать как-то так:

<input type="text" value="<?=$var?>">

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

[michael_v89]

Во-во, и я о том же)

[jrip]

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

[michael_v89]

Если бы получилось, сделал бы полезную вещь и поучаствовал в разработке известного языка) Чем не мотивация.

[jrip]

Так надо было делать что-то более эпичное) Знак доллара перед переменной, например, попытаться отменить)

[torf]

Не получится. Без бакса — переменная вовсе не переменная, а константа)

[Fesor]

Знак доллара у переменных это не проблема, это способ избавиться от явного объявления новых переменных. Вот лексические скоупы — другой разговор. Или дженерики для пыха.

Для тех кто не хочет вникать в Си, есть другой вариант помочь продвигать фичи — yay. Берем RFC и реализуем как пакет для composer. Тем самым давая возможность народу "покрутить повертеть" фичу на этапе обсуждения. Мало кто не ленится собрать себе пых при наличии MR с новой фичей и покрутить. А так хоть народ вместо "непонятно" будет давать фидбэк внятный.

[SerafimArts]

Доллар играет очень важную роль в языке:

1) Позволяет визуально отличать декларации переменных от структур, например:

$a; // переменная
a; // константа

2) Добавляет грандиозные и консистентные возможности метапрограммирования, например:

$obj->field; // Получение ссылки на задекларированное поле
$obj->$field; // Получение ссылки на поле, имя которого содержится в строковой переменной $field

echo $some; // Вывод значения переменной some
echo $$some; // Вывод значения переменной, имя которой содержится внутри переменной some

3) Позволяет делать интерполяцию без спец.символов (сомнительно очень), например:

$world = 'Вася';
echo "Привет $world";

[jrip]

Да пошутил же я ))
Просто одно время был холивар, ну типа лишний шифт нажимать))

[SerafimArts]

А некоторые не шутят и действительно считают, что без "долларов" лучше, а конкатенировать стоит символом "+"...

[jrip]

>А некоторые не шутят и действительно считают, что без «долларов» лучше
Ну если быть совсем честным, то их мнение имеет право на жизнь, вот на ваши примеры можно вот так посмотреть:

>1) Позволяет визуально отличать декларации переменных от структур, например:
>$a; // переменная
>a; // константа
Обычно константы все-таки заглавными выделяют, типа define («CONST1», "")

>2) Добавляет грандиозные и консистентные возможности метапрограммирования, >например:
А часто ли в реальном коде такое оправдано используется? Почти все случаи, которые я встречал были либо с проблемами в безопасности, либо слабо читаемыми, либо бажными. При этом ктож мешает бакс оставить именно для этого. т.е.

someVar // Вывод значения переменной some
$someVar // Вывод значения переменной, имя которой содержится внутри переменной some

>3) Позволяет делать интерполяцию без спец.символов (сомнительно очень), например:
Опять же как раз в этом случае бакс можно и оставить, так например сделано в Scala:

println(s"${msg}\n\n")

[SerafimArts]

Согласен. Я преувеличил. Но, с другой стороны довольно тривиальный пример:

public function __get(string $field) 
{
    $getter = 'get' . ucfirst($field);
    return method_exists($this, $getter) 
        ? $this->{$getter}();
        : null;
}

[jrip]

Тут сразу большой вопрос, а зачем так делать?
Нужны гетеры — средства современных IDE позволяют их сгенерить нажатием пары кнопок. Ваш же пример, как и многие другие с ипользованием $$ открывает простор для багов. Ошиблись где-то: либо в названии переменной или названии метода и сходу баг уже не обнаружить, а при другом подходе сама IDE нам бы об этом сказала.

[Serj_By]

Ага, и будет как в JavaScript:

[Fesor]

вот бы как в python

13 + "42"

TypeError: unsupported operand type(s) for +: 'int' and 'str'

в целом же всегда есть typescript/flow что бы сделать свою работу чуть более типобезопаснее.

[Serj_By]

Ну это, по крайней мере, более предсказуемое поведение. Хотя, если знать как это работает в JS — все тоже предсказуемо. Но для начинающих разработчиков — это, конечно, мрачный мрак.

[http2]

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

[M-A-XG]

человек, который пишет на современном php, должен как минимум знать кучу ООП best practices, использовать фреймворки и composer, знать кучу фич языка и его расширений

Ничего никто не должен :)

[http2]

Мне тоже интересно, почему это я должен забивать голову мусором? :)

Все это легко гуглится при необходимости.

А вот умение думать — не нагуглишь. :)

[Starche]

Мне болезненно не хватает встроенных в ядро асинхронных возможностей. Ну хотя бы банально — письмо послать без ожидания, в фоновом режиме.

[ganjar]

http://php.net/manual/ru/intro.pthreads.php?

[Starche]

Угу, когда дело доходит до критичного, использую треды. Правда я их не чувствую, пока что сложноватая для меня структура.

[MetaDone]

http://php.net/manual/ru/function.fastcgi-finish-request.php?

[Starche]

Ну, если я использую не лапшекод, то внутри контроллера вызывать такую функцию как-то не очень приятно.

[MetaDone]

вполне возможно использовать так
https://github.com/symfony/http-foundation/blob/master/Response.php#L422
или так
http://symfony.com/doc/current/components/http_kernel.html#component-http-kernel-kernel-terminate

[SerafimArts]

Такое норм? =)

register_shutdown_function(function() {
   // Send email
});

[SerafimArts]

P.S. Ну понятно, что эта штука не асинхронная, но вполне решает подобную проблему без внешних зависимостей. Хотя по-хорошему, конечно, лучше очереди.

[Starche]

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

[Melkij]

Если это единственная проблема — так отпустите сессию и всё. session_write_close

[Starche]

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

[Nicklasos]

Если используется php-fpm, то можно использовать функцию fastcgi_finish_request();

[Roquie]

А что мешает использовать очереди для этих целей?

[Fesor]

в Symfony и swiftmailer для этого есть spool. причем в двух реализациях, через файлы и cli команду или in-memory очередь и fastcgi-finish-request (то есть отправка идет после завершения обработки запроса). Для большинства этого хватает. Если нет — всегда есть очереди, нечего загружать процесс обрабатывающий запросы чушью вроде отправки email-ов.

[ivlasov]

Мое мнение PHP может и должен остаться только как backend JS морд. То есть как прослойка с нормальной аутентификацией между базой и клиентом. REST API и иже с ним
Имею многолетний опыт с PHP и с Yii в частности, последние 2 года полностью переехал на JS и не жалею.

[AmdY]

Основные изменения произошли в инфраструктуре и головах разработчиков, которые начали этой инфраструктурой пользоваться. Ускорили производительность, улучшили синтаксис, много изменений внутри, но ничего принципиально нового, что бы вывело язык на новый уровень не случилось. А вот то, что начали пользоваться компосером и фреймворками сильно всё поменяло, хотя ещё и во времена php4 были pear, pecl, seagull, cakephp и т.д.

Очень хотелось бы чтобы улучшилась асинхронность, многопоточность, появился loop, библиотеки стали неблокирующими, но глядя на костыли с какими добавляются новые фичи, думаю продолжу при надобности подтыкать проект на других языках nodejs, go. Может и не надо делать универсальный инструмент.

[artur_speaking]

Я бы наверно смог писать на php.

Но когда я сделал

$array = array('foo' => 'bar', 33 => 'bin', 'lorem' => 'ipsum');
$array = array_values($array);
echo $array[12];

и php с радостью исполнил мою просьбу и даже продолжил работать дальше — я понял, что это уж совсем перебор.

[Melkij]

Не совсем радостно. Высказал вам своё «фи» в виде E_NOTICE. Но, видимо, у вас вывод этого уровня ошибок выключен.
Продолжил после этого выполнение — к сожалению да. Будет пытаться выполнить любой бред максимально долго. Но нехитрый фокус с set_error_handler, который делают наверное все фреймворки — и можно попросить останавливаться и кидать нормальное исключение.

[Acuna]

На этом примере PHP выдаст Fatal Error, но у Вас просто отключен вывод ошибок. Точно так же как и если попытаться, например, сложить строку с массивом. Или объект со строкой. И так далее. Так что все эти неправильные выводы (как и созданная его репутация) проистекают от поверхностного ознакомления с ним и желание делать преждевременные выводы.

[franzose]

К сожалению, огромное количество php-шников до сих пор используют php как php4, и не хотят учиться.

Люто плюсую.

[shurkandak]

Многие вещи в PHP скопированы из Java к примеру реализация классов, по сути есть разработчик может в ООП на PHP, значит он хороший Java программист.
Так что кода в php добавят виртуальную машину, аннотации, многопоточность php станет джавой.

[Acuna]

А ничего, что многое на PHP (те же лямбды) появилось даже раньше чем в Джаве?)

[Fesor]

А ничего, что до php5 там и так были функции? Да что там, до php4 у вас были только функции для организации кода (подпрограммы тип), как в Си. Так что факт наличия анонимных функций в языке где функции были с самого начала — это просто факт. А вот в java функций как самодостаточных единиц небыло отродясь, теперь есть и это прогресс.

[Acuna]

А Вы, простите, зачем вступаете в оппозицию? Я вас что, в чем-то обвиняю как создателя языка, или обвиняю в чем-то Джаву? Естественно Джава даст сто очков вперед языку для создания веб-страничек, их даже сравнивать бессмысленно. Я просто говорю что что-то там появилось даже раньше чем в Джаве, поэтому не стоит язвить и объяснять, что там было «у нас». Что было «у нас» мы и так знаем, благодарю. Язык, каким бы он ни был, не стоит того, чтобы воспринимать разговоры о нем как личное оскорбление, есть много и других тем, в которых можно оскорбиться, если уж Вы этого так хотите.

[SerafimArts]

Доктриновские аннотации уже стали почти что дефолтом. Многопоточность тоже есть (pthread экстеншн), виртуальная машина 100 лет как, не классическая, но наличие опкодов и их кешеров (opcache, apc, etc) намекает ;)

[begor]

Когда я работаю с динамически типизированным языком, я ожидаю получить скорость и гибкость разработки, отказываясь при этом от sound системы типов. Классический трейд-офф, из палаты мер и весов.
Поэтому, например, в Python все — объекты первого класса (модуль можно передать в функцию форматирования строки, как вариант), что дает гибкость и заменяет некоторые паттерны из GoF простой передачей объектов.
В PHP же совсем недавно появились лямбды (и то весьма странные, с костылем-use вместо нормального скоупинга), первый класс только у скаляров, да объектов, кажется. Отсюда монстроузные решения типа Симфони и Доктрины, которые в динамическом языке выглядят странной пародией на Java-экосистему.
Вопрос: какие преимущества дает PHP, чтобы предпочесть его для нового проекта с одной стороны динамике Python/Ruby, с другой стороны — статике и энтерпрайзу Java?

[varanio]

> В PHP же совсем недавно появились лямбды
7 лет назад

[VolCh]

Динамику по умолчанию с возможностью (псевдо)статики, сокрытие данных, ну и, как вы говорите, «пародия на экосистему». Можно считать, что PHP сочетает лучшее из двух миров. Можно, что худшее, но что сочетает — факт.

[mihacoder]

7-я версия языка порадовала скоростью, вот только большая часть сайтов нашей фирмы на Битриксе, их просто так не переключишь. Те, что на Yii2, вообще не потребовали правок, там уже все готово. А в целом насчет ниши php — уверен, что он так и останется ближайшие годы основным языком для многих сайтов, особенно с невеликим бюджетом. По уровню сложности изучения — да, уровень входа минимальный, даже меньше, чем на python, поскольку на любом серваке поддерживается, больше инфы в сети. Легко учить, но так же легко и писать жуткие вещи, смешивая в одном файле верстку, логику и работу с базой. Это уже вопрос самодисциплины, думаю.

[ls18]

Использование фреймворка и опытного(грамотного) ведущего, который будет стучать по голове в случае чего хорошо прививает привычку писать более менее аккуратно и грамотно.

[mihacoder]

У нас начальство не вникает, кто и как пишет. Поэтому про самодисциплину и написал. А так при желании мог бы просто имитировать, работая значительно меньше :)

[vanxant]

Если битрикс обновлять, и при этом изначально нормально писать свои шаблоны/компоненты/модули/чтотамувас, то всё заводится на 7 без проблем. Даже сайты, которые пятый год в продакшене. Прям удивительно.

[mihacoder]

Вот как раз не обновляли Битрикс, начальство решило поэкономить, поэтому версии не самые свежие. Да они в принципе и работают, только на 5.6. А новые пишем уже на Yii2. Просто хотелось бы и старые чуток ускорить. Ну это не критично.

[zloled]

статистика по использованию php 7
https://w3techs.com/technologies/details/pl-php/7/all

[Fedot]

Особенно радует в этой статистике что указано за какой период она собрана.

[DemosBlack]

Не спеши навешивать ярлык на PHP, тем более на живой, новые диалекты которых появляются чуть ли не каждый месяц. Прежде чем выслушать критику в адрес языка, спроси у собеседника, не имеет ли он в виду версию 15-ти летней давности

[Itachi261092]

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

[varanio]

Я бы начинал с изучения принципов SOLID. В гугле полно статей, видео и т.д.
Книга «чистый код» Роберта Мартина.
Концепция «Domain Driven Design» — подчеркивает важность того, что код и термины в нем должны отражать суть бизнес-задач
У Фаулера есть различные книги, которые стоит почитать.

[xotey83]

Добавлю ещё про Code Complete (Совершенный код) Макконела.
Классика — Gang of Four

[Itachi261092]

Большое всем спасибо. Обязательно всё посмотрю. + поставить не могу — нет кармы.

[http2]

улучшать репутацию PHP

Улучшайте свою репутацию… :)

Книжки?
Я хз, есть ли что-то особенного под PHP.
Но одними книжками сыт не будешь.
Ресурсы?
гугл, стековерфлоу (английский), хабр. Слышали эти ресурсы? :) Ах да, официальная документация и комментарии к ней (тоже на английском).
Нужна прежде всего практика и общее правильное представление о программировании.

Если Вы собрались вообще без английского языка писать на PHP — ну это близко к тупиковому пути. :)

П.С.
Книги, указанные предыдущим оратором поддерживаю (это как раз общие книги).

[varanio]

Кстати, да, английский оооочень полезно знать.

[Itachi261092]

Советчик из разряда «спасибо, кэп». Специально для людей, не умеющих читать, я повторю ещё раз с акцентом:
Подкиньте кто нибудь хороших ресурсов/книжек на русском, которые лично вам помогли лучше в этом разбираться.
Всё что я могу найти самостоятельно в гугле — пока я это не прочту и не изучу, заранее не скажет мне, кому, как, и в чём оно помогло. И помогло ли вообще. Я могу найти абсолютный шизофреничный бред, или категорию литературы, которая не подходит мне по уровню, и не даст никаких адекватных результатов. Я не плохо знаю битрикс, и с этим знанием, я порой нахожу такие неудачные примеры и статьи от левых людей в их говноблогах, от которых хочется повеситься. По битриксу в непрофильных блогах уйма идиотских и вредных советов. Где гарантия что я не наткнусь на такие же, при поиске информации о PHP и ООП? Даже та же «чистый код», которую мне посоветовали выше, была немного раскритикована на этом же хабре
Если тебе нечего сказать конкретно по вопросу — уж лучше бы молчал, чем писать очевидные вещи.

[http2]

Так а нету никаких секретов.
Книжек тебе уже подкинули. Читай. Это общие книги. Я поддержал эти книги, если ты не увидел…
Если умения думать у тебя нету, вряд ли они тебе помогут.

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

А откуда уверенность, что тут Вы получите то, что хотите? :)

была немного раскритикована на этом же хабре

А Вы читали эту книгу? :)
Мало ли что какой-то дурак написал. (Да, последнее время концентрация некомпетентности на хабре зашкаливает, возможно хабр и с натяжкой в списке предложенных мною ресурсов).

уж лучше бы молчал, чем писать очевидные вещи.

Ну почему же. Вот вам:

Но одними книжками сыт не будешь.

Но если Вы, как упертый баран, хотите только книжек без практики, то это тоже путь, близок к тупиковому. :)

Поменяй работу, походи на собеседования.

А чем Вас не устраивает Битрикс? Он же ООП. Там тоже непаханное поле.
Новое ядро — еще ближе к новомодным фреймворкам.

[Itachi261092]

В том то и дело, что практики мне на основной работе и фрилансе пока хватает. Хочу хорошо знать, и применять теорию.

[http2]

Найдите работу, где будет нужна эта теория. :)

А она мало где в действительности нужна. :)

А то на собеседованиях спрашивают ООП и прочую ерунду, а в проекте это и близко не используется. :)

Если Вы будете писать на готовом фреймворке / CMS, то многое будет сделано за Вас, скорее всего Вам не нужно будет городить иерархии наследований и т.п. :)
Вам нужно только их документацию прочитать. Многие разработчики этим и злоупотребляют. Они знают только свой фреймворк, а в незнакомом месте и шагу самостоятельно ступить не могут. :) Самого языка и программирования вообще они, можно сказать, и не знают. :)

Начните свой проект на самописи. :)

Ах да, читайте исходники. :)
Что-то непонятно — в гугл. (что-то по предыдущему предложению, а то еще опять неправильно поймете) :)

[Skit25]

После прочтения, у меня возник эмоушн:



Кодил на php еще с 4х, молча кодил, рос php, что и как не задумывался, просто обновлялся и использовал новые фичи.
Ниша конечно есть! Уверен она никуда не денется. Куча php фреймворков, так и останутся php фреймворками. Когда выбирал фреймворк, увидел, что между ними неплохая конкуренция. Конечно, с повышением уровня входа в php, будет расти вход и на то, что на нем пишется. Очень вдохновляет к личному росту и рад, что успел запрыгнуть в этот поезд. Благодаря php, сейчас углубляюсь и другие языки программирования. Спасибо Расмусу за это!

Кто вперед на PHP 7.1?

[http2]

Вход в PHP вообще-то не вырос. :)
Он остался простым языком. :)

Это фреймворки просто переусложнены. :)

[VolCh]

Фреймворки и библиотеки упрощены за счёт того, что часть сложности перенесена на уровень языка.

[http2]

Упрощены? Сейчас? Вы что? Зачем лгать?

[SerafimArts]

Человек не совсем корректно выразился, подозреваю.

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

[http2]

Это когда же оно было упрощено во фреймворках?

С выходом PHP7? :)
А ниче, что все они работают и на PHP5? :)

часть задач архитектурирования бизнес-логики уже реализована в рамках общих идей конкретного фрейма

То есть программисту не нужно писать кусок бизнес-логики ибо за него это сделано на фреймворке? :)
Что же такого за него реализовали, что ему не нужно писать? :)
Но все равно разработка на фреймворке какая-то оверхедная. Куча ненужных дырявых абстракций, которые нужно постоянно переступать. :)
Кстати, использование фреймворка стимулирует разработчика и дальше все усложнять. :)

либо одноразовая шляпа

Почему же одноразовая? :)
Можно использовать в других своих проектах.
А если проект один и большой, то можно иметь нужную шляпу, а не брать в аренду не совсем нужную. :)

[VolCh]

Грубо называть ложью мнение.

Одно введение в язык позднего связывания значительно упростило фреймворки. Интерфейсы и абстрактные классы. Сокрытие членов классов. Callable, включая анонимные функции с замыканиями. Итераторы. Всего и не упомнить.

Если вы разработку на PHP4 не застали, то поверьте на слово, что фреймворк аналогичный по функциональности Symfony или Yii был бы гораздо сложнее и внутренне, и в использовании.

[http2]

Мнение?

Чет мне показалось, что это как всегда приукрашенное мнение, которое навязывают сектанты фреймворков.
Ну или Вы сами купились на их пропаганду. :)

Одно введение в язык позднего связывания значительно упростило фреймворки.

Это когда было сделано?
С выходом 7? :)
Об остальном и говорить не хочу. Ощущение, будто Вы пытаетесь втянуть меня в какое-то болото. :)

Если вы разработку на PHP4 не застали, то поверьте на слово, что фреймворк аналогичный по функциональности Symfony или Yii был бы гораздо сложнее и внутренне, и в использовании.

Только фреймворк был бы сложнее?
Мой код тоже был бы не таким без упомянутого Вами без причины позднего статического связывания.
Более странно, что его не было изначально. :)

Ах да.
Я человек простой. Вижу тупость или ложь, выражения не особо подбираю. :)

[xotey83]

M-A-XG, перелогиньтесь. Я не узнаю вас в гриме.

[http2]

Так Вы узнаете или не узнаете? :)
Вообще-то, я последователь M-A-XG. :)

[VolCh]

Что значит «приукрашенное мнение»? Парсер в моей голове ломается.

Тред о прогрессе с 4 до 7.

Больше похоже, что вы видите свои фантазии.

[http2]

Возможно мы не поняли друг друга. :)

Я отвечал прежде всего на это.

Конечно, с повышением уровня входа в php, будет расти вход и на то, что на нем пишется.

Перехода 4-5 — можно сказать, не застал. Но не заметил там повышения уровня входа.
Ну и не заметил повышения уровня входа при текущем переходе 5-7.

Где же идет повышение уровня входа — так это на фреймворках.

Были ли фреймворки при переходе 4-5 — хрен его знает. :)
Но при переходе 5-7 во фреймворках ничего не упрощено, так как они хотя бы все совместимы с 5.

Есть вопросы? :)

[Fesor]

Давайте разберемся что такое значит "проще".

Для меня "проще" выражается в возможности вносить изменения не внося изменений в то, что уже было написано ранее. Такие штуки проще поддерживать, проще развивать (потому что риск регрессий меньше). Что для вас проще?

Были ли фреймворки при переходе 4-5 — хрен его знает. :)

Они были