Comments 102
Очевидно, что писать бизнес логику на этих языках с админкой, ролями, паблишером, выводом контента и прочими штуками - не самый лучший выбор. Будет долго и неудобно.
А вот мне это не очевидно, почему node.js и go поставлены в один список с rust?
Согласен с Автором, современный подход к разработке на PHP сейчас не имеет ничего общего с тем, что было 10 лет назад. И многие колкости в адрес PHP разработчиков это просто тренд (только ленивый не пнёт PHP в попытке утвердиться, что он выбрал более подходящую платформу для разработки).
Периодически встречаю людей которые удивляются, что PHP может делать то, что как им казалось фишка только их языка.
Частично дурную славу языку сделали "кодеры" которые пренебрегали какими-то было паттернами разработки и минимальным тестированием проекта. В годах 2005 ... 2010 на каждом втором сайте были sql инъекции из-за необдуманной подстановки параметров запроса в sql. В этом была н вина PHP а именно тех кто так делал.
А написать плохо - можно на любом языке.
Не холивара ради, а только в качестве интереса: не могли бы вы привести несколько примеров таких «фишек», которые есть в PHP а не только в языке X, и заодно сам язык X
Если про синтаксис, к примеру лямбды, замыкания, строгая типизация, JIT всё это завезли в PHP.Инфраструктурно - огромное количество пакетов на все случаи жизни, от подключения какого-нибудь менеджера очередей до нейросетей, адаптеры для Oracle и вообще к чему угодно.
заодно сам язык X
А язык с лямбдами, замыканиями, строгой типизацией - например, Haskell.
PHP не так плох с точки зрения того, что в языке возможно сделать используя его конструкции. У меня лично претензии скорее к историческим аспектам. Очевидный шаблонизатор, который практически заставляет настраивать редактор на автоматическую вставку <?php или пользоваться генераторами как в symfony cli, даже если тебе не нужно генерировать html. Стандартная библиотека со странным неймингом и отсутствием модульности, сам язык зовётся препроцессором, а концепция препроцессинга это прям очень сильный даунгрейд во времена C (с его include), язык модула-2 появился на 6 лет позже чем C, но намного раньше чем PHP в 1978м году (из него модульность стащил Python). В PHP нет модулей в стандартной библиотеке, если запустить php -a, то автодополнение будет работать на ~4.8к функций. Ну и слабая типизация не делает чести языку.
Из «фишек», которые есть в PHP, но нет в других языках (скриптовых) - поддержка LSP (не сервера). "Уникальный" тип данных массивохеш (в документации ещё практикуется подмена понятий из других языков) и проверка типов в рантайме без обязательного указания типа или auto. В целом PHP ощущается как C++ от мира веб-разработки, где в язык тащат вообще всё что можно, есть даже goto. Ну и из очевидных вещей не надо всякие wsgi настраивать. Ещё достаточно удобная вещь есть для дебага без дебаггера var_dump и die, в других языках есть аналоги для интроспекции, но в php вывод var_dump сделан хорошо, а die достаточно короток и понятен.
https://www.php.net/manual/ru/language.oop5.basic.php#language.oop.lsp
https://www.php.net/manual/en/control-structures.goto.php
https://www.php.net/manual/en/language.types.array.php
Лично мне очень не хватает объектной стандартной библиотеке с хорошим именованием. Если без объектном библиотеки, то хотя бы оператора pipe |> не хватает, чтобы собирать в цепочку вызовы функций. Ещё очень не хватает хорошего shell'а на манер python, ruby.
"Уникальный" тип данных массивохеш
Он не уникальный, в Lua есть тип table.
Лично мне очень не хватает объектной стандартной библиотеке с хорошим именованием.
Если уж сильно не хватает, можно воспользоваться каким-нибудь пакетом, например https://github.com/azjezz/psl.
Если без объектном библиотеки, то хотя бы оператора pipe |> не хватает, чтобы собирать в цепочку вызовы функций.
Совсем недавно была отклонена вторая попытка добавить этот оператор: https://wiki.php.net/rfc/pipe-operator-v2. Обсуждение и причины можно почитать по ссылкам:
* https://externals.io/message/109734
* https://externals.io/message/114770
* https://externals.io/message/115333
Ещё очень не хватает хорошего shell'а на манер python, ruby.
https://psysh.org/ пробовали?
Он не уникальный, в Lua есть тип table.
Не знал про аналог в Lua, но согласитесь такой тип данных не очень популярен в языках программирования.
Если уж сильно не хватает, можно воспользоваться каким-нибудь пакетом, например https://github.com/azjezz/psl.
За рекомендацию библиотеки большое спасибо, скорее всего в ближайшее время начну использовать.
https://psysh.org/ пробовали?
Пробовал, отличный инструмент, хотелось бы видеть его в поставке самого php вместо php -a, писать var_dump'ы и echo в шелле очень неприятно.
Не знал про аналог в Lua, но согласитесь такой тип данных не очень популярен в языках программирования.
Lua был лишь примером, на самом деле много других языков, которые поддерживают разные типы ключей в ассоциативном массиве, вот пример на Go: https://go.dev/play/p/Eb1MhUTaxr1. Кстати, PHP разработчики проделали огромную работу по оптимизации этого типа, в 7-ке появилась концепция "packed array", в 8.1 packed array оптимизировали, убрав ключи во внутреннем представлении структуры. То есть под капотом разделение на map/array уже реализованно в виде ZEND_HASH_PACKED_*/ ZEND_HASH_MAP_* (совсем недавно был только ZEND_HASH_*). Но я согласен, более специализированные структуры данных не помешают, а пока можно воспользоваться DS :)
много других языков, которые поддерживают разные типы ключей в ассоциативном массиве, вот пример на Go:
Но там же именно что один тип ключа, interface{}.
С таким же успехом можно сказать, что и в PHP один типа ключа — int|string. И его так же можно использовать повсеместно: https://3v4l.org/Y5Vrb#v8.1.3 (или даже так: https://3v4l.org/EFUm3#v8.1.3).
В этом была н вина PHP а именно тех кто так делал.
Несомненно, но... язык (или его sdk) должен максимально оберегать разработчика от выстрела в ногу. И если рассматривать пример с sql-injection, то на рубеже 00-х в php просто не было таких абстракций как prepared-statement и PDO. Был лишь доступ через расширения типа mysql, где пользователи подставляли аргументы прямо в строку запроса и часто забывали делать escape. Конечно же потом в 5 версии все было сделано хорошо, и появился PDO, но огромный багаж написанного с дырами кода никто не бежал рефакторить.
С одной стороны легко сейчас рассуждать о том, что можно было сделать лучше. С другой стороны, если мейнтейнеры php так или иначе перенимали плюшки из java, то могли бы и сразу сделать свой аналог jdbc с блекджеком и prepared'ами.
Как раз недавно встречала мнения, что если топят за какой-то конкретный язык программирования, а другие принижают, то вот "удивительно" этот человек на нем и работает, чаще использует именно его.
А по итогу сейчас (давно) стало просто много распространённых и попросту модных языков (которые таковыми стали в том числе благодаря онлайн школам программирования), но все забывают истину, что язык не главное, это просто инструмент, с помощью которого реализуется проект.
Так что не переживайте, не слушайте никого, занимайтесь тем, что нравится, удобно, всем не угодишь и не докажешь. А так, конечно обидно бывает=))
Язык это инструмент, и плох тот мастер, у которого нет своего набора инструментов. Нельзя всё делать одним молотком.
Поэтому я до конца не понимаю, почему ребята из Cybersport.ru оправдывались в выборе PHP (Symfony), когда они сделали максимально правильное и грамотное решение.
Потому что у успешного независимого человека должен быть какой-нибудь якобы недостаток, за который ему якобы неудобно перед соседями, друзьями, клиентами или родственниками - просто что бы им всем не было слишком завидно и что бы они не лезли конопатить мозги.
Да ладно с имиджем php ещё не всё так плохо, гораздо хуже если вы 1С-ник )))
Есть только два языка: те, которые все гнобят и те, про которые никто не слышал.
Странно ставить в один ряд NodeJS c Rust/Golang. Последние низкоуровневые и предназначены быть в своем роде заменой для C++ в определенных нишах.
А на Node JS уже есть навороченные фреймворки: NestJS (похож на Spring) или Adonis JS (похож на Laravel) и т.д.
Да, и в эпоху микросервисов и облачных провайдеров не имеет смысла чтобы фреймворк вообще реализовывал все подряд. Зачастую авторизацией и ролями управлять будет отдельный сервис (или облачная служба), а файлы хранить и обеспечивать к ним доступ будет облачный провайдер, а вы будете пользоваться лишь SDK. И так далее.
Пишу небольшие микросервисные API на ванильном PHP. Вся логика - запросы к базе, немного арифметики и условий и циклы по массивам. Иногда по очень большим и глубоким массивам. Недавно поймал себя на мысли, что в случае с массивами производительность PHP превосходит мои ожидания. Получается быстрее выдернуть сырые данные из БД и обработать у себя, нежели использовать функции СУБД. К примеру, array_merge() отрабатывает существенно быстрее, чем JSON_AGG() в Postgres. Вкупе с простотой синтаксиса и обширной документацией PHP просто прекрасен. Но не надо писать на нём демоны.
Но не надо писать на нём демоны.
Почему нет? На современном php прекрасно пишутся демоны.
Чем плохи демоны на PHP?
Может быть потому что если речь о производительности, то вместо функций json_xxx следует использовать jsonb_xxx? Тип json в PostgreSQL - это просто строка с навешенными ограничениями на содержимое.
Обычно php это что-то не очень серьезное/второстепенное/сделанное побыстрее на коленке.
Я писал на PHP долгое время и перешел на Java, это был как глоток свежего воздуха.
Очень смелое заявление. А как же Авито, Delivery club, Badoo, facebook в конце концов?
У них глоток свежего воздуха ещё впереди! :)
Facebook давно не пишет на php — они пишут на hack.
Я тоже раньше писал на PHP (около 10 лет), после чего перешел на Java, в основном из-за того что в среднем по больнице оплата джавистов выше, да и не скрою, всегда чувствовалось некое снисхождение от разработчиков на других языках. Хотелось на себе прочувствовать как оно на другой стороне барикады, а вдруг я и вправду "программист второго сорта". Перешел на Java в 2017 году, и вот я senior java developer в очень уважаемой компании. Никакого глотка свежего воздуха в помине не почувствовал, сферы у языков немножко разные, а строгую типизацию можно и в PHP использовать в полный рост, а плохих разработчиков на java пишущих говнокод тоже хватает. Язык безусловно может способствовать выработке правильных методик, но в большей степени этому способствует личное стремление и чтение правильных книг.
А что вы пишете на Java, если не секрет?
Я наоборот свежий воздух почувствовал от php после java. На java все пишется дооолго, когда торопиться некуда.
Ну про дженерики в PHP это громко сказано. Можно сколько угодно хвалить инструмент кроме которого не удалось попробовать что-то еще, только этот инструмент лучше не станет от этого, а лишь появится ложное чувство. Не знаю еще ни одного человека кто с котлина на пхп перешел например, зато наоборот - много случаев. Пока в пхп не появятся нормальные дженерики - не появятся нормальные коллекции и другие структуры данных. Как настрадаетесь с пхпдоком - посмотрите все же по сторонам.
Но... Кроме дженериков все остальное уже есть :(
У вас точно инфа не с нулевых?
Нет, не с нулевых. Последний проект был недавно на PHP 8 + Symfony 5.
Не подумайте, я не хейчу PHP, просто не понимаю тенденцию с его нахваливанием: раз в пару недель стабильно статья на хабре какой же PHP недооцененный.
Кроме дженериков все остальное уже есть :(
А что "всё"? Да, добавили тайпхинты и анотации (атрибуты), это был прорыв, можно сказать. Но...
Так как нет дженериков, как уже и говорил, - нет и нормальных коллекций, и это многого стоит.
Расширения пишутся на потустороннем языке, из-за чего они плохо развиваются, так как "обычный" PHP-шник туда не может контрибьютить.
Нет многопоточности (всё, что есть, это костыли)
Нет возможности использовать функциональный подход хотя бы частично там, где это оправдано. Могу привести в пример Java Streams API, хотя бы. А если сравнивать с Kotlin, то совсем грустно.
Даже если в будущем это всё добавят - PHP всё равно отстал навсегда от таких языков как Java, C#, Kotlin. К сожалению. Я для себя не вижу смысла ждать с десяток лет когда это все появится в PHP. Уже сейчас можно взять язык в котором это всё уже есть и даже больше.
Да, стоит заметить, что под каждую задачу нужно выбирать инструмент индивидуально, где-то PHP не плох, возможно. Но зацикливаться на нем не стоит.
Это просто контр-тенденция. Никто пых особенно не нахваливает, но учитывая количество неграмотного хейта, просто надо ему что-то противопоставить.
Это не совсем нахваливание. Больше похоже на попытку реабилитировать инструмент.
Все же, несмотря на массу недостатков (помимо перечисленных вами), в своей нише он занимает лидирующую позицию.
Применять Java для клепания публичных презентационных приложений (где не требуется ни алгоритмов, ни структур данных, ни производительности высокой) не совсем экономически обоснованно.
А альтернативы в виде питона, котлина и тд ещё слишком молодые и тоже не имеют той кодовой базы, чтобы с аналогичной скоростью и эффективностью деплоить и поддерживать при схожих затратах.
Применять Java для клепания публичных презентационных приложений (где не требуется ни алгоритмов, ни структур данных, ни производительности высокой) не совсем экономически обоснованно.
Для этого достаточно JavaScript и serverless типа Firebase на бекенде (можно даже с алгоритмами).
В теории это возможно, но для десятков тысяч РогаИКопыта экономически не выгодно. Так или иначе запилить за пару часов на каком-нибудь вп или джумле х*як-х*як и в прод на порядок дешевле.
Но, как говорится, на чем разраб умеет, то и использует.
Вы пишите на js, ноде и питоне. Они достаточно популярны и в своей нише удобны.
Я пилю на пыхе, го и изредка шарпе, жаве. Причем первое для быстрых апи, второе для поставляемых коробочных клиентов. Они тоже в своей нише популярны и удобны.
Согласен с приведёнными недостатками. Интересно вводу дженериков не мешает то, что основная структура данных для коллекций это массивохеш.
Не вижу ничего плохого в разработке на PHP. Сам-то я RoR, но старший брат всегда писал на php и как-то все норм. А насчёт малого количества проектов на руби и небольшого интереса молодых спецов: не думал, что такая колоссальная разница будет между Беларусью и Россией (я из Беларуси). У нас очень много проектов как продуктовых, так и на аутсорс, а спецов молодых на RoR очень много (чисто в нашей компании курсы по нему постоянно укомплектованны)
Про то что PHP не подойдёт для websocket и других realtime задач - утверждение как минимум сомнительное. amphp, reactphp, swoole - совершенно замечательно решают этот класс задач. В 8.1 приехали fibers, в связи с чем удобство работы с этими инструментами станет ещё выше. Для особых любителей есть parallel, который позволяет делать realtime-сервисы без асинхронного ввода/вывода (но менее эффективно).
У меня в production stateful сервис асинхронно обрабатывающий realtime трафик, выдаёт по 1000+ RPS на одно ядро (что не много, но вполне прилично и горизонтально шардируется). Никаких проблем с тем что он написан на PHP - нет, у меня в этом сервисе узким местом является не PHP, а rabbitmq, который упирается в 15k RPS в рамках одной очереди (несколько очередей работают корректно, шардируем очереди).
Если есть проблема с realtime-сервисами на PHP, то она у программиста и на других языках будет. Подходы к реализации таких сервисов не отличаются на разных языках, разница присутствует в инструментарии и удобстве работы с ним.
Подходы к реализации таких сервисов не отличаются на разных языках
Вот это как раз и не так. На том же Erlang / Elixir накосячить в real-time приложении невозможно by design, просто потому что язык, а точнее виртуальная машина была как раз для этого и создана. Поэтому меня всегда удивляли всякие попытки написания real-time на всяких скриптовых языках. Да, оно работает, да, оно может вывозить тысячи соединений, но Erlang может вывозить миллионы на том же железе. И резкий скачок нагрузки ведь всегда не вовремя, и приходится потом в впопыхах переписывать все хотя бы на Go.
Ну вот по какой-то причине Phoenix вообще не упомянут в самой статье.
Когда мне говорят Erlang - я предлагаю посмотреть на RabbitMQ. Чего он такой прожорливый, если должен на том же железе вывозить миллионы ?
А много ли удалось написать продуктовых приложений на Erlang за карьеру что получилось составить такое мнение?
P.S. Если что я не против Erlang, что бы это понять достаточно заглянуть в мой профиль. Просто интересно, на чем базируется утверждение про by design.
Про то что PHP не подойдёт для websocket и других realtime задач - утверждение как минимум сомнительное. amphp, reactphp, swoole - совершенно замечательно решают этот класс задач. В 8.1 приехали fibers, в связи с чем удобство работы с этими инструментами станет ещё выше. Для особых любителей есть parallel, который позволяет делать realtime-сервисы без асинхронного ввода/вывода (но менее эффективно).
Сейчас рассуждают как-то так. Нам нужен сервис, обрабатывающий 1000 запросов с ядра. Что будем использовать? Azure и .Net! AWS и Java!! Google Cloud и Go Lang!!!... PHP (вылетает в окно).
Заголовок в стиле: PHP programming matters
PHP был разработан как движок, сильно упрощающий разработку сайтов (по сравнению с "write-only" Perl, который был в этой нише мейнстримом). Как сайд-эффет это означало крайне низкий порог входа для новых специалистов. Оказавшись в нужном месте в нужное время (эпоху доткомов) он быстро стал очень популярным.
Проблема современного повзрослевшего PHP, вобравшего в себя разные навороты из других языков и платформ, в том, что теперь его преимущество не очевидно. Крутые фишки требуют крутых знаний. От былой простоты мало что осталось: в чем-то хуже, в чем-то лучше - он стал как все.
Есть несколько ниш, где PHP может быть ещё долго востребован, чисто по инерции. Это e-commerce (типа 1C Bitrix, Magento), WordPress, несколько CMS ну и разное корпоративное легаси с корнями и традициями разработки из нулевых, которое нужно поддерживать. Но повторить былой глобальный успех ему уже ни когда не удасться.
Чтобы сейчас начинать карьеру в области PHP разработки надо понимать, что в среднесрочной перспективе это путь уникальных специалистов (как COBOL, Perl, Delphi и т.п). Там вероятно можно уже найти неплохие деньги, ввиду специфичности скиллов. Но это рынок работодателя, где увольнение может быть крайне болезненным.
Да ладно.
Вакансий по php море и ещё немного.
И я сейчас говорю о нормальной разработке, а не клепать лентосы на Вордпрессе.
Так что нет, увольнение вот совсем не страшит.
Что вы называете нормальной разработкой, можно пару примеров таких вакансий?
На php куча админок, систем управления делается. В т.ч. и с нуля. Как-то в разработке онлайн банка участвовал. На почту постоянно идет поток предложений рассмотреть ту или иную вакансию. Так что с редкостью COBOL вы уж совсем мимо.
И сам php как язык, отягощенный обратной совместимостью с не самыми лучшими решениями, по сравнению с новыми ЯП может и не очень. Хотя и он неплохо развивается. Но вот удобных фреймворков и библиотек на нем написана масса. Так что в целом разрабатывать легко и приятно.
Наследие эпохи PHP ещё долго будут разгребать и какие-то улучшения там происходить ещё точно будут. Но это не драйв, а движение по инерции. Как я уже говорил, в среднесрочной перспективе вся эта история будет идти только спад: основная масса разработчиков уже развернулась в сторону других языков. https://www.stackscale.com/blog/popular-programming-languages-2021/ Нужны какие-то очень весткие мотивы, чтобы заманить их обратно. Какие?
Даже по вашей ссылке php занимает вполне хорошее место. А с учетом того, что он, в отличие от прочих ЯП, представлен только в одной области, так вообще отличное.
Наследие эпохи PHP ещё долго будут разгребать и какие-то улучшения там происходить ещё точно будут.
Новые проекты на нем все так же пишутся. В своей области он вполне популярен.
Нужны какие-то очень весткие мотивы, чтобы заманить их обратно.
Я считаю, что у php довольно пологая кривая обучения, плюс Очень хорошая инфраструктура в своей области. Часто слышу, что php разрабов проще найти / они меньше стоят, что немаловажно для компаний.
Так что доля php может глобально и снижается, особенно за счет узости его применения. Но жизнь на нем вполне есть. И профессионал, и новичок в ближайшие 10 лет без работы не останутся.
Даже по вашей ссылке php занимает вполне хорошее место. А с учетом того, что он, в отличие от прочих ЯП, представлен только в одной области, так вообще отличное.
Он представлен только на первом графике - использования языка. Этот график отражает ситуацию в настоящем как результат каких-то прошлых событийный.
На графике предпочтений разработчиков PHP теперь на 11 месте (если смотреть не в посте, где показано только первых 10, а оригинал survey на StackOveflow). До этого пару лет держался на 8-м. В процентном соотношении так же виден обратный рост. Думаю на счет 10 лет вы правы.
Когда я услышал, что с восьмой версией PHP стал полноценным современным языком, на котором программировать не стыдно, я решил глянуть, действительно ли всё снисходительное отношение к этому языку должно остаться в прошлом, и теперь всё изменилось?
Увы, у меня сложилось ощущение, что нет. У меня от языка как и раньше остался привкус бессистемной поделки. А нововведения мне показались не вполне успешными потугами сделать "как у взрослых". Хотя, конечно, я допускаю, что могло сказаться моё предубеждение.
Но вот, например, оператор match. Даже стрелочки "=>" как "у взрослых". Однако одно из основных его свойств "у взрослых" - это то, что он исчерпывающий (exhaustive). Это, в частности, позволяет избегать достаточно существенного класса ошибок. В PHP 8 же он ничтоже сумняшеся сделан не исчерпывающим - ну а чё, для "хомяков" норм! Я уж не говорю о таких мелочах, как мощь сопоставления с шаблонами (pattern matching) и ограничений ("if" guards), которая отличает match "у взрослых" от старого доброго сишного switch'а. А у PHP не отличает, да, и он остался по сути тем же самым switch'ем, только чуть более эргономичным.
С другой стороны, почему бы и не гордиться тем, что пишешь на PHP? Сейчас эра бодипозитива и всего такого прочего!
Ну вот собственно еще один типичный "специалист" описанный в статье. Сразу видно, что даже в мануал не глядел:
A
matchexpression must be exhaustive. If the subject expression is not handled by any match arm an UnhandledMatchError is thrown.
Нет, я читал не мануал, а новости о нововведениях в PHP 8 (PHP - не мой язык, я на нём только чужой код чуть подправлял более десяти лет назад). И я точно помню, там про это не писалось. И я решил, что раз об этом весьма важном моменте не написано, значит, этого там и нет.
Что ж, спасибо, значит, был поверхностен. До более тщательного изучения текущей ситуации с этим языком буду избегать суждений о нём.
Я подумал, и понял, что ещё ввело меня в заблуждение, кроме отсутствия упоминания об исчерпывающем характере match'а в тех анонсах, которые я читал. А именно, это примеры приводимого в качестве корректного кода конструкции вида:
<?php
$expressionResult = match ($number) {
1, 2 => foo(),
3, 4 => bar(),
};
?>То есть я слишком привык немного к другому проявлению исчерпывающего характера match - что такой код, без default, просто некорректен в принципе, а не что это может определяться в процессе исполнения путём обнаружения фактически не обработанного значения, и не смог вовремя от этого абстрагироваться. Хотя выброса исключения вполне логично ожидать для интерпретируемого в своей основе языка.
А откуда вы взяли этот пример корректного кода?
Пример был синтетический. Но и правда, лучше обратиться к мануалу, ссылку на который Вы дали.
Там в самом начале приведён Example #2 Basic match usage, который имеет именно указанную проблемную структуру - match делается по строке, от которой обрабатываются только три варианта.
(На самом деле я вспомнил, я таки смотрел в мануал, и увидев пример с откровенно не exhaustive match, не стал читать дальше.)
Все верно, вы должны записать его явно. А кидать exception это как раз таки правильное поведение - забыли указать, отловить в try catch и тем более покрыть тестами - останов, а не как раньше со switch - непонятно что пошло "гулять" дальше по рантайму. Компилятор/интерпретатор не должен за вас решать такие задачи. Не силен в других языках но судя по этому поведение там подобное.
Нет, как раз это дело компилятора и даже интерпретатора. В Скале, Расте и Джаве код не скомпилируется, если компилятор не смог удостовериться, что рассмотрены все варианты. И это очень важно, потому что позволяет избегать большого класса ошибок, в том числе - приводящих к уязвимостям.
Приведённые по вашей ссылке примеры относятся к enum'ам, перебираются все их варианты, и поэтому default не нужен. В Расте можно не ставить рукав "_" например в случае, если match идёт по u8 (байт), и рассмотрены все его 256 вариантов.
Но в конструкциях, аналогичных примеру Example #2 Basic match usage из мануала по PHP, указанные мной языки потребуют рукава, срабатывающего по умолчанию ("_", "default").
PHP - язык в своей основе интерпретируемый. Но это не значит, что ничего нельзя сделать. Например, можно сделать рукав defaul синтаксически обязательным и выдавать ошибку сразу при попадании на match без default (как, например, сейчас в PHP выдаётся синтаксически ошибка при попадании на match с двумя рукавами default). На худой конец, даже если по какой-то причине с языком ничего не сделать, на крайнюю желательность наличия рукава default нужно было бы сделать акцент в документации с самого начала.
В отличие от указанных мной языков, подход PHP с выбрасыванием исключения при выявлении фактического экземпляра непокрытого значения в runtime приводит к тому, что ошибка выявляется не сразу на этапе создания программы, а уже в продакшене, когда пользователь ввёл нетипичные данные, например. То есть этот подход провоцирует на написание не очень хорошего кода. Но безусловно, это несколько лучше молчаливого старого switch.
Как по мне стыдится нужно нынешнего яваскриптового безумия.
И кстати большинство быдлокодеров сейчас идет именно на фронтэнд.
Python не конкурент PHP, они просто созданы были для разных целей, а в процессе эволюции, Python обрастал новыми возможностями для улучшения системы, на которой он изначально запускался (Linux), а эволюция РНР шла другим путем и в какой-то момент затормозилась на много лет и это дало бурный рост фрейворкам РНР, так как рынку нужны были новые функции, а РНР их им не давал, по разным причинам. И теперь это совершенно разные игроки на рынке и между ними конкуренция если и возникает то это во время вопроса "А на чём сверстать лингпединг?". Для остальных выбор очевиден иногда он за Python, а иногда это РНР начиная этак с версии 7, хотя конечно лучше 8.х...
PHP - язык, как язык. Да, он как и питон - некомпилируемый, и куча шибок вылазит при исполнении, а не компиляции. Да, по-моему, там все еще все плохо с многопоточностью и черт его знает, как писать демонов, которым надо все и сразу, а не линейно. Да, всякие приколы по типу массивов, которые и не массивы вовсе, а типа хешмапы с ключом произвольного типа. Да, по сравнению с гошкой или скалой/джавой - тормоз он тот еще, если надо чиселки подробить. Я где-то могу ошибиться, так как давно уже ничего не писал на нем... сорян, если что.
Но с другой стороны - PHP на синтетике до 10 раз быстрее модного питона (тут у питонистов обычно челюсть отваливается). Библиотек / фреймворков на все случаи жизни - навалом. Любая проблема - все уже разобрали на всяких stackoverflow и не надо голову ломать. Всяких модных штук в язык тоже завезли порядком.
У него действительно только одна "проблема". Из-за низкого порога входа туда пришло очень много людей с низкой квалификацией творить дичь. :) Как сейчас - не знаю.
imho.
Наоборот говорю всем и каждому, что прогаю на пхп. Если сам не стыдишься, то и люди начинаю по другому воспринимать это, и даже нет попыток посмеяться надо мной или языком
Ну вот ты сам автор, признал то, чему якобы в своей статье пытаешься противостоять
Java/C# - удачи найти адекватных ребят в команду, когда за ними уже стоит очередь из финтеха, операторов связи, крупного ритейла, российского FAANG'а, галер и крипто-стартапов. Явно контентный проект не сможет на равных конкурировать за ребят на этом стеке.
Получается раз Java/С# востребованы, то зачем этот PHP? Ну переучись ты на другой стек, это не так уж сложно, если голова работает правильно... И будут за тобой стоять очереди эйчаров.
И есть вполне объективные причины, почему эти два языка более востребованы чем PHP.
И сравнивать PHP и Python - не совсем корректно. Phyton - это еще и про bigdata, чего PHP практически не умеет. Не его стезя, в отличии от Python и написанном для него кучи библиотек.
Вот как правильно заметил, остается маленькая узкая ниша, и то, лишь только потому что "мы умеем в это". А других аргументов то и нет.
PHP я думаю это тупиковая ветвь. Рано или поздно вымрет после очередного перехода к какому-нибудь web 4.0.
И правильно. Я бы тоже на месте ребят из симфонии стыдился, именно как ИТ-специалист. Современное ИТ развивается так стремительно, что работа в ИТ это как бег за поездом, который отъезжает с большей скоростью чем ты его догоняешь. И вопрос тут только в том, насколько далеко этот поезд уедет. И очень важно догонять тот поезд, который не упрется в тупик. В случае PHP - у меня лично нет сомнений, что все закончиться тупиком.
На рынке кроме фактора спроса на язык есть еще и предложение спецов, умеющих в него. И на php, imho, проще начинать. В т.ч. из-за кучи фриланса и простых инструментов на нем.
переучись ты на другой стек, это не так уж сложно, если голова работает правильно…
А чем backend на java принципиально лучше, чем на php?
У меня в команде работал чел, перешедший с C# на php. Говорил, что Doctrine получше чем EF. Да и работу новичку проще найти.
И будут за тобой стоять очереди эйчаров.
За толковыми php-шниками тоже очередь. Видимо, везде сейчас так.
Получается раз Java/С# востребованы, то зачем этот PHP?
зачем, зачем. затем... hh.ru, moscow: C# от 205.000 руб.: 359; PHP от 265.000 руб.: 254.
Хм, а какие компании относятся к "российскому FAANG-у" ?
Я правильно понял, в призывах перестать критиковать PHP автор раскритиковал (тут было более грубое слово) все остальные технологии?
Проблема PHP в том, что написанные костыли в до 7-е версии времена, сейчас исправляются новыми костылями.
PHP сам по себе хороший инструмент, но только для тех задач, для которых он изначально был придуман. Для панелек, админок и сайтов лучше ничего нет.
Мелочь всякую можно закрыть, чтоб не изучать новый стек, но писать что-то масштабное исключительно на не предназначенном для этого PHP не стоит. Хлебнёте проблем.
У меня был такой опыт. Правда есть один существенный плюс - опыта хапанёте вагон и маленькую тележку)
Я переходил с php и vb.net на c#. Что касается php, то меня наоборот не устраивает неявная типизация и как следствие проблемная отладка. Ещё меня не устраивает открытый код, поскольку это лишает заработка от поддержки проекта и авторских прав, создавая ситуацию частого рефакторинга кода.
Как по мне: автор не прав в исторической справке. Язык стал считаться позорным до распространения cms, еще когда только появился все к нему относились как к недоязыку - вроде "подумаешь скриптики для хомяков, он ведь даже не компилируется". А потом только список претензий менялся.
Не нужно стыдиться PHP