Отраслевое финтех СМИ и Digital + PR агентство
71,76
рейтинг
23 ноября 2015 в 11:32

Разработка → Жизнь PHP-разработчика перевод

Вступление от переводчика: очень давно веду разработку на PHP. Хоть я знаком с рядом других технологий и вижу некоторые недостатки PHP, но в целом я им доволен, и мне кажется несправедливым, что этот язык программирования подвергается нападкам чаще всего. Недавно нашел статью как раз на эту тему, думаю, позиция автора близка многим php-программистам, поэтому публикую перевод. Старался специально для корпоративного блога нашего проекта о платежных сервисах Web-payment.ru. Кстати, если вам понадобится подключить оплату на сайте — обращайтесь. Ну а далее перевод:
Субъективное восприятие языков программирования не только порождает дискуссии среди скучающих программистов. Оно также влияет на принятие важных решений — прием на работу и финансирование.
Эта фраза заставила меня всерьез задуматься над тем, как сообщество воспринимает PHP.

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

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

Посмотрите, каким негативом окружен PHP в сообществе программистов:

Цитаты по типу этой повсюду: «Тех, кто учит PHP, надо изолировать от общества».

Примечание переводчика: и Хабр не исключение.

После такого задаешься вопросом — а не выбрал ли я плохой язык?

Все написано на PHP


Может вы даже начнете сомневаться в себе из-за того, что поставили не на ту лошадь. Ведь всем, похоже, нравится Clojure, Haskell и JavaScript, но никому — PHP.

Давайте посмотрим в интернете, какие проекты все-таки используют PHP:
  • Facebook
  • WordPress
  • Yahoo
  • Wikipedia
  • 4chan

Значительная доля крупнейших сайтов мира написана на PHP. Кажется бесспорным, что PHP — достойный и практичный язык для создания веб-приложений, но мы отвлеклись.

Сейчас не 2004 год


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

Сегодня в PHP есть классы и нормальное ООП. Есть прекрасные фреймворки, например, Laravel и Symfony.

У PHP есть менеджер пакетов, который работает с огромным архивом опенсорсных пакетов.

У PHP есть прекрасные фреймворки для тестирования: например, PHPUnit для юнит-тестирования, Behat и Codeception для BDD.

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

Как это влияет на разработчиков


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

Часто кажется, что PHP-разработчики оказались заперты в замкнутых микро-сообществах. Из-за того, что в более крупных сообществах их не приветствуют, они часто устраивают собственные митапы, юзергруппы и конференции.

Забавная история


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

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

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

Прошло 10 лет, но проблема та же — только отвлекает другое. «На удивление хорошо знаешь информатику для PHP-разработчика». Фу.

К сожалению, я не вижу подвижек в решении этой проблемы. Зачастую люди жалуются на PHP просто потому, что это модно. Но, к сожалению, конца этому не видно.

Это очень грустно. Мы оказались в ситуации «курица-яйцо»: если PHP-разработчиков постоянно унижать, они будут покидать сообщество, и в нем будет оставаться все меньше хороших PHP-программистов.

Статья переведена специально для корпоративного блога Web-payment.ru — проекта который, поможет подключить вам на сайте прием платежей или массовые выплаты. Обращайтесь!
Автор: @vladislavPetushkov Jonathan Kuperman
Web-payment.ru
рейтинг 71,76
Отраслевое финтех СМИ и Digital + PR агентство
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Комментарии (344)

  • +20
    PHP-разработчиков постоянно унижать, они будут покидать сообщество, и в нем будет оставаться все меньше хороших PHP-программистов.

    Как говорит Жорес Алферов — тут остались одни оптимисты, потому что пессимисты уехали.
  • +1
    Ну на дворе уже правда не 2004 год, и нападок на PHP я почти не слышу. А слышу их обычно от тех, чье мнение никак не:

    влияет на принятие важных решений — прием на работу и финансирование.
    • 0
      Это вам видимо везло. У меня периодически проскакивают клиенты, которым «знакомые разработчики» сказали, что всё, что написано на PHP — говно, и поэтому они против PHP в качестве основного языка проекта
      • 0
        Такие клиенты есть на любой язык. Кто-то когда-то им что-то сказал. У меня недавно один клиент спросил про «перспективный javascript-фреймворк» под названием Bootstrap. Он был искренне удивлен тому, что мы его не используем. Ему тоже кто-то ляпнул какую-то чушь.
    • 0
      У PHP низкий порог входа. Очень много новичков посмотревших в документации пример работы с MySQL начинают программировать, но качество их работы очень низкое, порой их код нечитаем (быдлокод). Наверное в этом и причина негативного отношения к PHP — на нем можно писать некачественный код и он будет работать.
      • 0
        на нем можно писать некачественный код и он будет работать.

        Это самая сильная сторона PHP (минимум усилий вплодь до деплоя что бы получить что-то работающее), она же является его бедой, но далеко не все застревают где-то на уровне wordpress.
      • 0
        Вы знаете, сейчас на любой мало-мальски распространенной платформе можно писать некачественный код, и он будет работать. Это тренд, а не исключение.
        • –1
          В сложном языке программирования работает естественный отбор, на той же Java недоучка не сможет ничего сделать
          • 0
            Да ладно, Java разная бывает. Не забывайте про андроид. Гугл вложил кучу усилий для того что бы любой человек мог написать свое приложение под андроид.
          • 0
            Да ладно, по программе института, прохожу уравнительный семестр Java с 1 годками, смотря исполнения некоторых лаб могу сказать, можно писать и там не читаемый код.
            • 0
              можно писать и там не читаемый код.

              нечитаемый код можно писать на чем угодно.
              • 0
                имелось ввиду «код нечитаем (быдлокод)».
                • 0
                  у определенного процента людей не выходит даже свою речь адекватно построить, из чего можно сделать выводы что дело не в языках программирования.
          • 0
            Да ладно, как раз с тех пор, как появился VB, потом Java и вслед за ними прочие языки четвертого поколения, которые сделали возможным программирование без управления памятью, необходимая планка квалификации, чтобы написать «шоб хоть как-то работало», значительно упала.
  • –5
    Статья целиком состоит из нытья по поводу того, что к PHP относятся как-то не так, как хотел бы автор.

    «Всё очень плохо, и нужно лучше, а вот не получается, и что делать я не знаю».

    Вместо написания статьи имело бы больше смысла молча принять к сведению все преимущества\недостатки и использовать эти знания при выборе инструментария для конкретного проекта.
  • +15
    Да пусть разработчики на «настоящих» языках и дальше снобствуют, нам-то что с того? Наоборот, приятно наблюдать, когда эти мегаджедаи явы и асп обсираются и срывают проект, который пилили по 2-3 года, а ребята на PHP переписывают его за полгода, с значительно меньшими издержками. Ну да, за то «У НАС ЖЫ ЫНТЫРПРАЙЗ!»
    • +2
      Ну к примеру Python явно не ЫНТЫРПРАЙЗ, но на нём можно писать ещё быстрее чем на PHP (банально строк меньше выходит :) ). Это я к тому, что с java/C# не только PHP сражается но и Python,Ruby,JavaScript и теперь Go.
      • –11
        А Ruby разве ещё жив?
        Python? А что для веба на нём вообще написано? ИМХО, как язык скриптов и десктоп приложений он очень и очень хорош, но в вебе он как РНР в десктоп ПО.
        JavaScript — согласен, нода очень и очень хорошо выстрелила, с интересом смотрю на неё. Как и на Go.
        • +4
          насчёт python вы сильно ошибаетесь, django, flask посмотрите для старта
          • –5
            Я знаю про них, но что на них особо пишут? Какие известные проекты? Даже на Ruby я могу вспомнить GitHub, а на Python ничего в голову не приходит из такого же уровня.
            • +7
              Instagram, Disqus и Pinterest — на Django
              • +11
                Спасибо за ответы, признаю, был неправ про Python.
              • 0
                Disqus на Go теперь.
                • 0
                  Go — всё-таки немного другая ниша. Это скорее язык на который переписывают проекты, когда им становится тесно в лимитах интерпретируемых языков, а не на котором начинают новое (если ты не гугл).
                  • 0
                    Не согласен. По мне, Go сейчас прямой конкурент PHP, Питону и Ноде на бэкенде.
                    Он простой, быстрый, компилируемый и имеет отличную поддержку конкаренси из коробки.
                    Конечно, по распространенности он не может сейчас бороться с вышеперечисленными языками, но за последний год растет очень быстро.
                    • 0
                      Go — кокурент ноды для долгоживущих сокет-серверов и C для эффективной обработки массивов данных. По части веб я пока в нём конкурента не вижу.
                      • 0
                        Go — кокурент ноды

                        уж извините, но нода для го не конкурент.

                        По части веб я пока в нём конкурента не вижу.


                        web это работа с вводом/выводом по большей части, и тут Go очень выгодно использовать.
            • +8
              Reddit, Dropbox, Yelp, Quora и многие други.
              • 0
                Dropbox на Go переходит.
                • 0
                  Ну им теперь тесно, переходят же то не потому что Python это плохо. Далеко не у каждого проекта будут такие проблемы.
                  • 0
                    Ну да, я просто уточнил :)
                • 0
                  Странно что не на Scala, у них же хороший евангелист там есть — Li Haoyi. Продуктивности этого чувака может позавидовать любой разраб… Хотя учитывая то, насколько Go активно пиарится и что он в разы проще, не удивительно что выбор пал именно на него.
                  • 0
                    Ну да. Простой, быстрый, без СМС JVM
            • +1
              bitbucket например ;)
              дело даже не в этом, Вы просто очень категорично к python отнеслись
              мне как PHP-разработчику очень интересно работать с python/django, там есть чему поучится и что можно было бы применить/уже применяется в PHP мире
              к примеру, тот же Symfony вдохновлён как Spring, так и Django, и Rails
              • 0
                От спринга в симфонии архитектура и похожий на гибернейт ORM, от джанго — похожий шаблонизатор. А что в Symfony от Rails? Всегда считал, что воплощение рельс на РНР — Yii.
                • +2
                  Yii 1.0 был воплощением рельс. 1.1 уже был прилично не похож. 2.0 унаследовал разве что философию.
                • +1
                  Symfony года на 3 старше Yii и сначала (до Symfony 2) влияние Рельс там очень ощущалось, собственно, заимствования идей и даже прямое портирование кода не скрывалось, например:
                  We have converted code written in other languages to PHP, like the Ruby on Rails helpers. But most of the time, we have implemented our own solution based on the community experience. This is the case for the new form framework, for which I borrowed a lot of ideas from two Python projects: the Django framework and the formencode library. In symfony 2.0, we will have a Dependency Injection framework, inspired by the Java Spring framework. Instead of reinventing the wheel over and over again, we can build better tools thanks to existing ones.
                  • 0
                    Не не, это нельзя сравнивать. У Symfony и Symfony 2 кроме названия и авторов общего нет ничего от слова «совсем». И, кмк, первый был убогонький, зато второй просто шикарен.
                    • 0
                      Ну, про «совсем» не надо.
              • 0
                Я Flask распробовал — мне он даже больше Dajango понравился. Если не нужна джанговская админка — самое оно. А если надо event-driven, то Twisted.
                • 0
                  Если нужна «джанговская» админка – есть flask-admin. К тому же, моя практика показывает, что именно джанговская админка с реальными задачами справляется не очень хорошо.
                  • 0
                    Да ну, я от джанговской админки как раз сбежал ) Не хочу пока фласк в джангу превращать. Хотя конечно зарекаться не буду.
                • 0
                  Мне вот во Flask дико не хватает вменяемого RBAC :( У джанги он из коробки, и прям отлично работающий я бы даже сказал.
                  • +1
                    Ну flask все-таки и не fullstack фреймворк. Я не искал пока, может и управление доступом можно вменяемое подмешать во фляжку )
                    • 0
                      Разумеется, но всё таки это часто нужная вещь, и я весьма удивился, когда обнаружил, что flask community до сих пор не сделала ничего вменяемого :(
                      Есть flask-rbac, flask-security и что-то ещё было, но чего-то так же хорошо работающего как в джанге — я не видел.
    • +5
      Мой опыт говорит совершенно об обратной ситуации.
      В данный момент в компании идет десяток проектов с привлечением внешних исполнителей. Внешние исполнители как интегрируют свои продукты, так и разрабатывают проекты с «нуля».
      — Крупный и известный исполнитель со своим продуктом, сроки пролетели уже в несколько раз. Свой продукт на PHP, минимальная интеграция с API компании — аутентификация. Не могут 2 месяца наладить её. Последний перл — дайте нам API с возможностью читать ваш список пользователей постранично (пользователей всего 750, в списке только логины).
      — Разработка ПО для терминала. Yii, php. 5 месяцев разработки функционала на 4 страницы (регистрация, каталог, товар, корзина). Ошибок столько, что плакать хочется, причем все детские, будто скрипткидисы пишут. Я каждый день просто тыкая в экран пальцем ловлю 2-3 ошибки. Это уже второй исполнитель по данному проекту обещавший, что сделает лучше и быстрее первого.
      — Портал на Битрикс 24, писали-писали 1 год. Плюнули, поставили Sharepoint, за 1,5 месяца все сделали своими силами с помощью мышки и JS.
      — Интернет-магазин, исполнитель со своим продуктом на PHP. Срыв сроков на 6 месяцев. Суд идет.
      И это не за какой-либо период, это происходит прямо сейчас. Никто из исполнителей пишущих на C#/Java такого себе не позволяет.
      Стоимость каждого из проектов, примерно, как квартира в Москве. Плюс ТЗ, танцы проджект-менеджеров, встречи-обсуждения. Это я к тому, чтобы не было мысли о том, что это делают школьники\студенты.

      Думаю уровень знания, опыта и ответственности среднего программиста C# в «ЫНТЫРПРАЙЗ», выше чем программиста который работает только с PHP, в силу разноплановости разития, и не только из-за большего порога входа, тут и формы, и вэб, и по-настоящему большие проекты с коопразработкой. Где надо думать над архитектурой, и стиль — «оп-оп и в продакшн» просто не взлетит в силу того, что это просто не будет работать.

      Я сам работал с PHP с 2001 по 2004 год. Но в 2005 ушел в ЫНТЫРПРАЙЗ с C#, правилами, паттернами, кодревью, оптимизацией, сетью и БОЛЬШОЙ ОТВЕТСТВЕННОСТЬЮ за написанный софт.
      • +8
        Поддерживаю. Мой опыт говорит о том же. Я не сомневаюсь, что есть хорошие программисты на PHP, которые следуют стандартам, паттернам и прочим «ЫНЫТЫРПРАЙЗ» штучкам, но та реальность с которой сталкиваешься каждый раз уныла, чуть более чем совсем.
        • +1
          Я не следую «ЫНЫТЫРПРАЙЗ» штучкам (за исключением редких ситуаций, когда реально надо), но проекты сдаю вовремя и оттестированными. Что я делаю не так? :)
          • 0
            Я про то и пишу — таких как Вы, меньшинство, к сожалению. Я в своей практике очень редко встречался с грамотными PHP-шниками.
          • 0
            Ох, извиняюсь, прочитал неправильно, на заметил «не» :)
            Мое мнение, что каждой задаче — свой инструмент. Это касается и языков и паттернов и методологий. Если нужно забабахать страничку в вебе или интернет-магазин, то почему бы не использовать PHP (даже без ООП, обожемой, что я говорю!), если он Вам по душе. Но все-таки на серьезные проекты, где требуется жесткий контроль за качеством выходного продукта, лучше взять тех же джавистов, чем пхпшников, имхо. Так сложился рынок…
            Хотя опять же оговорюсь, если у Вас команда толковых PHP-шников, в которых Вы уверены, то почему бы и не использовать их :) Я вот таких не встречал, о чем написал выше.
            • +7
              Я пять лет писал веб на J2EE. Это ужасно (по крайней мере было) по сравнению с PHP. Мордочки больших Java-проектов и то пишут на PHP потому что развивать их так проще: деплой проще, отлаживать проще, из коробки больше всего. С нормальных фреймворком даже на косяки PHP не наступаешь. Вообще красота!

              Контроль не зависит от языка. Тут либо самодисциплина, либо грамотный управленец. Раздолбаев на Java не меньше, просто они лучше шифруются за ЫНЫТЫРПРАЙЗ-ом и паттернами.
              • 0
                Ваша правда, если мы уж затронули тему веб мордочек, то джава тут явно не на первом месте :)

                А вот по контролю не соглашусь. PHP тут скорее исключение и именно из-за сложившейся конъюнктуры. В подавляющем большинстве PHP-программисты менее квалифицированы, чем Java-программисты. Сужу по людям и конторам, где работал, хотя понимаю, что мне могло тупо не везти :)
                • 0
                  Ваша правда, если мы уж затронули тему веб мордочек, то джава тут явно не на первом месте :)

                  У джавы тут все великолепно. Но часто получается так, что веб пилят те же программисты, что и всё остальное. У них громадный опыт программирования в их области и практически никакого в веб. Результат — соответствующий.
                  • +1
                    Ну не знаю, меня всегда билд и деплой ради горстки HTML вымораживал. Я из за этого на кофе подсел, всё-равно делать нечего пока билдится…
                    • 0
                      Ради HTML я не билдил ничего никогда. Даже jsp в servlet api древнем автоматом подливаются. Для тяжёлых случаев есть JRebel :).
                      • +1
                        Ну, не пихать же какую-никакую логику в JSP? Так и так что-то да будет. Из базы данные выбрать, рассортировать, показать, юзера залогинить…
              • +1
                Мне интересно, вы действительно не знаете про velocity, freemarker, thymeleaf и прочие шаблонизаторы? Которые для той самой джавы и созданы (+ некоторые портированы с других игроков, например handlebars), И как раз, чтобы бекэндщикам не приходилось гнать говённый UI (который они всё равно не умеют готовить).
                • 0
                  Конечно, сейчас в Java всё немного удобнее стало, но когда я последний раз делал веб на Java, Thymeleaf и FreeMarker точно не было. С Velocity 1.5 как-то работали. Также припоминаю XSLT в качестве шаблонизатора. Голый PHP на тот момент уделывал их по удобству.
              • +1
                Контроль не зависит от языка. Тут либо самодисциплина, либо грамотный управленец. Раздолбаев на Java не меньше, просто они лучше шифруются за ЫНЫТЫРПРАЙЗ-ом и паттернами.


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

                Если бы обычная практика разработки на компилируемых языках не включала обязательный статический анализ, то вряд ли что-то сильно бы отличалось от того же PHP, лучшие практики разработки на котором мало отличаются от практик той же Java. Включая статический анализ кода перед не то, что деплоем или коммитом, а даже запуском, в который (анализ) входит в том числе и проверка явного объявления переменных и типов (PhpDoc), и проверка на использование неявного приведения типов.
            • 0
              Мое мнение, что каждой задаче — свой инструмент. Это касается и языков и паттернов и методологий. Если нужно забабахать страничку в вебе или интернет-магазин, то почему бы не использовать PHP (даже без ООП, обожемой, что я говорю!), если он Вам по душе. Но все-таки на серьезные проекты, где требуется жесткий контроль за качеством выходного продукта, лучше взять тех же джавистов, чем пхпшников, имхо. Так сложился рынок…


              Вот в этом и проблема основная — PHP разрабы пытаются все написать на нем…
              • +1
                и в чем тут проблема? я думаю если бы средний php разработчик просто так взял java/scala то все бы пошло куда более плохо.

                А то что php разработчики используют для решения задач язык который они хорошо знают, то проблемы нет. Другое дело что большинство свой язык не очень хорошо знают.
                • 0
                  Такому среднему типичному PHP разработчику бы пришлось разобраться со статической типизацией, нормально начать использовать эксепшены и разобраться с ООП. Так что спорно. Весь этот набор необходимых сопутствующих знаний прокачал бы его.
                  • +1
                    Весь этот набор необходимых сопутствующих знаний прокачал бы его.

                    Для всего этого не надо менять язык или пытаться пописать на Java (хотя это очень полезный опыт, вопробовать пописать еще на парочке языков).

                    Более того, вероятность того что человек разберется с ООП и т.д. только потому что возьмет java примерно такая же как и с PHP (я знаю достаточно java разработчиков которые понятия не имеют о SOLID или о том как работать с исключениями, а java 1.8 вообще позволяет в этом плане не особо заморачиваться).

                    Тут проблема в том что люди не знают что учить (хотя как мне кажется просто не хотят).
      • +5
        функционала на 4 страницы

        Стоимость каждого из проектов, примерно, как квартира в Москве.


        Немного странно, не находите?
        • +11
          Да там небось обычная ситуация, «а ну давай те вон тех наймем на пхп, они занедорого напишут».
          А далее парят мозг, каждый день что-то заставляя менять, либо внезапно окажется, что проблема вообще не в пхп, а в том что кто-то не сказал, что верстка под мобильные устройства, например нужна.

          Ну да так повелость, что парни на с# — java обычно и берут сильно больше и договор грамотно составляют, так что бы потом на просьбу «поиграться со шрифтами» выставить нифиговый счет.
          Только это не проблема в языке, это проблема в мозгу всех причастных.
        • 0
          С чего вы решили?
        • +11
          В ЫНТЫРПРАЙЗЕ так принято. 100500 совещаний менеджерья всех уровней, и за неделю до дедлайна дают Васе, который эти 4 странички напишет и получит свои скромные 50тыр/мес. А квартира разойдется по этим милым и прекрасным эффективным менеджерам.
      • +21
        С людьми вам не везёт. Ни язык ни фреймворк тут не при чём.
      • +4
        Писал большой развернутый коммент, но, к сожалению, не ушел :(

        Если кратко:
        По первой части: дебилы есть везде, это не аргумент. У вас свой опыт, у меня свой. Я чаще встречал идиотов, которые ради трехстраничного магазинчика с криком «ОЛОЛО, ЫНТЫРПРАЙЗ» брали J2EE/Spring/ещё-какое-то-страшное-говно и весело залипали на полгода-год. Очень частая и грустная история.
        Offtop: ПО для терминала на РНР? ЛОЛШТО? Как? Зачем? Почему? Они бы ещё, ***, микроконтроллер на РНР программировали! При всей моей необузданной любви к РНР, он — только для веба и смежного (ну сервисные скрипты/демоны для этого проекта)

        По второй части, как это коррелирует с языком? Неужели язык запрещает продумывать архитектуру, методологии? Неужели язык заставляет делать «оп оп и в прод»? А взяв какой-нибудь богомданный C#/Java программист тут же превращается в крутого синьёра, который пишет код, взглянув на который Дейкстра и Кнутт в обнимку будут плакать от умиления?

        В последней части вы подставились. Вы всерьез думаете, что за 10 лет ничего не изменилось и мы всё так же барахтаемся в своём болоте? Для справки за последние 10 лет мир РНР изменился до неузнаваемости: появились нормальные стандарты кодирования, отличные инструменты, фреймворки, способные дать под зад этим разным спрингам.

        Вроде ничего особо не забыл.
        • 0
          Я написал про опыт, свой опыт, он говорит обратное к
          когда эти мегаджедаи явы и асп обсираются и срывают проект, который пилили по 2-3 года, а ребята на PHP переписывают его за полгода,


          А взяв какой-нибудь богомданный C#/Java программист тут же превращается в крутого синьёра, который пишет код, взглянув на который Дейкстра и Кнутт в обнимку будут плакать от умиления?

          Я считаю, что скрипткиддис от PHP может спокойно и долго работать, а программисту от «энтерпрайза» не дадут второго-третьего шанса. Там рулит бабло.

          В последней части вы подставились. Вы всерьез думаете, что за 10 лет ничего не изменилось и мы всё так же барахтаемся в своём болоте? Для справки за последние 10 лет мир РНР изменился до неузнаваемости

          Я за то, чтобы бить гвозди молотком, а не микроскопом. У PHP свой мир, где лучше него нет, а у C#/Java, свой мир. И я пишу о том, что каждый инструмент хорош для того, для чего его создавали. Я понимаю, можно и большие решения на GUI под окошки писать на JS. Но, зачем?
          • 0
            Дык я же согласился, что опыт у всех разный, у меня свой, у вас обратный. Тем не менее, и тот и тот есть в реальности.

            Я считаю, что скрипткиддис от PHP может спокойно и долго работать, а программисту от «энтерпрайза» не дадут второго-третьего шанса. Там рулит бабло.


            Эм, откуда там вообще тогда есть программисты, если там такая Спарта? Неужели там только эльфы, которые не совершают (и не совершали никогда) ошибок от слова «совсем»? Выходит, так. Или где-то меня пытаются обмануть ;)

            У PHP свой мир, где лучше него нет


            Именно, шулай! И этот мир — веб разработка. Я тоже за то, чтобы РНР из этого мирка никуда не перелезал. Но и за то, чтобы в этот мирок не лезло отребье из других областей.
            • –19
              Как раз из веба одно отребье в пыхе и торчит. Более серьезные вещи делаються в том же руби, Python и тд. Посмотрите хотя бы биржи фриланса, как платят пхпышникам и как всем остальным. У пхпе ниша — одностраничники и сайтики за 2 недели ну и легаси, которое обставляют костылями типа hack, чтобы хоть как то справляться с нагрузками, смиритесь уже с этим. Как хорошо, что я перешел на Python
              • +4
                Вам ещё раз дать список проектов, сделанных на PHP, и зарплаты в этих проектах?
                • –3
                  Это все легаси, если бы у них был выбор все переписать с нуля, я уверен больше чем на 100% что они бы выбрали другой инструмент. Они вынуждены работать с этим. тот же фейсбук и контакт лагают чаще чем раз в неделю. Если бы не балансировщики и стопицот серверов — давным давно пролетели
                  • +5
                    spotify.com is powered by the @symfony framework and many great packages from http://packagist.org using Composer by @seldaek
                    Странные ребята, и rails уже был, и django, а эти дурни опять полезли в этот пыхапе!11
                  • +1
                    2gis, wikimart, Innova, Alawar, flamp, runet-id, Etsy, mailchimp… можно вечно продолжать. О, ещё хабр, кстати ;)

                    blog.mailchimp.com/ewww-you-use-php
                    • –2
                      Вы так говорите, как будто у тех же 2gis сам продукт написан на PHP. Вы хотя бы, прежде чем людей вводить в заблуждение, посмотрели хотя бы вакансии этих фирм, а если уж совсем не лениво то блоги их почитали бы. Там от всего что написано, на PHP поди одна страничка, а не окрепшие умы будут думать, что Innova Линейку на PHP написала(хотя они вообще лишь локализаторы) :-D
                      • +1
                        Ну да, у 2gis API на PHP и Yii. Я у команды был в офисе в Новосибирске, всё видел собственными глазами. Вы же не думаете, что я утверждаю, что у них приложение для iOS на PHP написано? :)

                        У Innova весь веб на PHP и Yii. Линейка, естественно, нет :)
                        • 0
                          Да в курсе про, то что у них API и контент для юзеров PHP отдает. Но не зря же у них постоянно вакансии C++/Java разрабов в интернетах висят. Плюс ко всему на глаза попадалась часто фразы в духе «2Gis, scala developer».
                          Вообще такой подход многих фирм — это достаточно логичный выбор. Они понимают, что им нужно N количество девелоперов чтобы сделать отдачу контента например, и знаю что лучше взять язык X, даже не по соображениям продуктивности, а по соображениям где они будут брать этих самых девелоперов.
                          • 0
                            Они же занимаются не только отдачей готовых данных. Все эти данные они ещё и собирают. Огромный штат картографов и контентщиков (не знаю, как правильно назвать тех, кто уточняет данные по фирмам). Надо тучу утилит, чтобы всё это приятно вбивать и обрабатывать. Ну и, скорее всего, тяжёлую обработку они делают сейчас не на PHP. Это нормально.
                    • +2
                      Хабр это был первый проект Денискина, другие вот проекты уже делали на рельсах.
                      Хабр на PHP, на RoR brainstorage.me, hantim.ru, freelansim.ru и autokadabra.ru.
                      Toster.ru тоже на PHP.

                      habrahabr.ru/company/xakep/blog/203094/#comment_7028358
                    • 0
                      Какая смешная получается статья. Такое себе оправдание, аля «да, мы смогли сделать нормальный продукт на PHP». Не, ну хорошо, если руки ровные, только как это все добавляет плюсиков самому PHP, я не понимаю.
                      • 0
                        Это отнимает у него минусики :)
              • 0
                Поподробнее расскажите про серьезные вещи
                • –7
                  Youtube, Flickr, Instagram — мало? Это все на Python написано
                  • +2
                    Flickr вроде всегда был на PHP: highscalability.com/flickr-architecture
                    • –1
                      Перепутал с Disqus. А еще есть Pinterest, Reddit, Quora, DropBox, Bitbacket
                      • 0
                        Никто не спорит, что питон был очень популярен когда Django был трендовым. Такое случалось со всеми платформами и не удивительно, что есть написанные практически на любой нормальной платформе отличные проекты.
                        • +1
                          а почему именно был?
                          • +1
                            Потому что сейчас он не трендовый, а просто отличный и самый крупный фреймворк на питоне. То же с RoR. Во времена «блога за 15 минут» на рельсы бежали все сломя голову. Потом мода прошла, люди поняли, что рельсы код за них писать не будут и успокоились. Рельсы стали просто замечательным руби-фреймворком, но сломя голову на них бежать перестали.

                            Сейчас в тренде нода, хотя уже самый пик спадает.
                            • +3
                              сейчас тренд Go ;)
                              • +1
                                Да, но тоже пик проходит потихоньку. Go у нас прижился как очень эффективная молотилка данных.
              • +4
                Почему мы должны смиряться? Потому что какой-то странный человек так сказал? Ха-ха-ха. Нет уж, с вашего позволения, продолжу делать прекрасные большие проекты на PHP/Symfony 2.
                • –2
                  Потому что называть других людей отребьем вызывает у меня слишком бурную реакцию, вот и не сдержался, теперь сожалею
                  • +1
                    Да я вообще-то отребьем назвал технологии…
                    Но и за то, чтобы в этот мирок не лезло отребье из других областей.

                    Мир РНР — мир [технология]. В этот мир не лезло что? Отребье [технологии] из других областей. Причем тут люди? То то я ваш коммент понять не мог, про то какое отребье в РНР торчит.
        • 0
          Offtop: ПО для терминала на РНР? ЛОЛШТО? Как? Зачем? Почему?


          Что такое современный терминал знаете? Обычная персоналка с купюроприемником и сенсорным экраном. Для его задач ресурсов более чем достаточно, чтобы поднять обычную десктопную ось, запустить в ней браузер и какой-нибудь веб-серверный стэк (включая даже «взрослую» БД) в практически однопользовательском режиме. Почему не «LAMP»? Работа с купюропреемником (через либы вендора) инкапсулируется в расширении PHP, или отдельном относительно тупом сервере на, например, питоне и большинство задач по интерфейсу может решать обычный «сайтостроитель».
          • 0
            Знаю, даже делал оболочку к нему (но не на РНР). Вопрос остаётся. Разве не проще взять какой-нибудь nw.js в kiosk-mode (и да, к купюроприёмнику там интерфейс есть через расширение node.js). Или, о ужас, написать нативную десктоп приложуху на практически чём угодно.
            Любой, даже самый двинутый «сайтостроитель» может в js, так что вариант с nw.js вполне может взлететь. Да даже есть всякие извращения типа для созданий «нативных» приложений на РНР, для самых упоротых.
            Вот только зачем там веб-фреймворк то? Не вижу ни одной объективной причины.
            • 0
              Кому проще, а кому нет. Сроки, опять же. Ещё есть такое слово «унификация». Как правило, у компании есть сайт, где можно провести те же операции, что и в терминале только вместо кэша карты и электронные деньги — писать два раза одну логику? Или и сайт делать на node.js? Не вижу ни одной объективной причины писать сайт платежной системы на node.js. А обёртку купюроприемника вполне может быть на чём угодно, включая node.js. А внутренний сервер логично писать на веб-фреймворке, коль скоро принято решение, что интерфейс будет в браузере. Какой фреймворк на каком языке — это уже ситуационные решения.
      • +2
        Проекты в конечном итоге делают не инструменты, их делают люди. Одна команда делает на технологическом стеке «А» быстро и качественно, а другая на стеке «Б» делает кое-как. А третья и «А» не умеет готовить… Так было и есть. И веротяно еще не изменится какое-то время.
      • 0
        У меня есть другой опыт. Был серьезный проект для очень крупной компании. Поскольку «php-ники ж не шибко умные, не серьезно все это» взяли джависта. Что такое юнит тестирование — не знаем. Зачем нужно писать тесты — не знаем. SOLID — что это, зачем это все надо.

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

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

        p.s. Я лично за 6 лет ни разу не видел адекватно написанного проекта на Yii. Как-то так сложилось (сам 3 года работал с ним и знаю его хорошо, сам ходил по всем возможным граблям), что проекты как только приобретали определенную сложность (что-то сложнее CRUD-а, например интернет магазин со специфичной бизнес логикой или биржа труда) разработчики сразу же превращали код в мессиво (и сам таким грешил, ибо фреймворк сам по себе потворствовал этому).

        Я хорошо помню один комментарий в ишус трекере Yii (увы не дословно) при обсуждении добавления IoC или контейнера зависимостей: We don't need some fancy patterns. Он очень хорошо передает суть.

        исполнитель со своим продуктом на PHP

        А вот это уже проигрыш сразу. Если разработчик собирается использовать решение которое поддерживать может только он то от него надо бежать.
        • +1
          Т.е. вы, сами не обладая экспертизой в Java за каким-то «надом» наняли отдельного java-программиста (о навыках которого не могли судить)? И это «серьёзный проект»? Да с тем же успехом вы могли фрилансера нанять! Никаких гарантий, если нет опыта работы с конкретным человеком. В целом же — самостоятельный проект требует квалификации близкой к сениору — у большинства мидлов просто не хватит опыта, чтобы во всех узких местах пролезть.
          • 0
            Т.е. вы, сами не обладая экспертизой в Java за каким-то «надом» наняли отдельного java-программиста

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

            Никаких гарантий, если нет опыта работы с конкретным человеком.

            Есть еще проекты различной сложности. Скажем вы могли успешно сотрудничать с человеком в рамках простых проектов, а чуть сложнее и начинется веселье.
        • 0
          Fesor Не сочтите за рекламу. Вот часть проектов над которыми мне пришлось работать. В основном это ERP системы и им подобные. Все написаны на Yii: часть на первой версии, часть на второй. Ни разу не испытывал проблем с архитектурой.
          Да, у фреймворка есть архитектурные проблемы (особенно у первой версии, у второй почти все нормально). Но они никак не мешают строить грамотную архитектуру своего кода.
          И сейчас новые пректы я пишу именно на нем т.к. этот фреймвокр, на мой взгляд, предоставляет наилучшее соотношение возможностей и простоты. В нем все очень хорошо и «правильно», но без фанатизма.

          Для справедливости отмечу, что я не использую его для генерации html сайтов (разрабатываю только rest api) и про эту часть фреймворка сказать ничего не могу.я
          • 0
            Ну… я как бы не вижу ничего сложного в этих проектах (в плане архитектуры). Если у нас там чисто REST/HTTP API, мало бизнес логики (по сути у вас там только работа с данными, выборки из базы, возможно CQRS какой-нибудь можно вкатить). То есть конкретно Yii тут мало палок в колеса может поставить (только active record и то сомневаюсь).

            Я же говорю о проектах где например есть десяток сущностей с кучей отношений между друг дружкой, с кучей бизнес правил и т.д.
            • 0
              Из-за NDA не могу там указать подробности работы. Открыто могу расскащать про перую работу в списке — самую свежую.
              Сейчас уже 12 крупных модулей, которые с одной стороны полностью изолированны друг от друга, с другой тесно взаимодействуют. Отключение любых из них является штатной ситуацией. Поддерживаются различные версии, кастомизация, версионирование данных. В базе под 500 таблиц. Программных сущностей чуть меньше. Содержит около 2000 классов. Архитектура чистая, гибкая, устойчивая к сбоям. Система работает распределенно на нескольких серверах. Думаю, это можно назвать сложным пректом.

              Остальные проекты не такие сложные но по несколько десятков взаимосвязанных сущностей в них есть.
              • 0
                Я не спорю что на Yii можно писать нормальные поддерживаемые приложения, особенно если само приложение будет изолировано от фреймворка (хотя бы частично). И уж темболее можно писать адекватно на Yii2.

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

                Что говорить о том что я нахожу XSS уязвимости в каждом проекте на Yii который приходит ко мне на ревью.
                • +2
                  Я лично за 6 лет ни разу не видел адекватно написанного проекта на Yii.

                  Хотел чтобы вы увидели хоть один :)
                • 0
                  > Что говорить о том что я нахожу XSS уязвимости в каждом проекте на Yii который приходит ко мне на ревью.
                  Намекните плз где чаще всего они находятся?
                  • 0
                    везде где выводятся значения вбиваемые пользователями. Начиная с имени фамилии и заканчивая поиском, комментариями и т.д. Просто не экранируют вывод. + встроенные js библиотечки в Yii (или в экстеншенах) тоже могут чего-нибуть выводить без экранирования.

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

                    Для новичков это черевато проблемами. Им вообще бандаж нужен, а не язык или фреймворк который позволяет все на свете и не ругает ничего.
                    • 0
                      понятно, спс, в моделях валидатор со strip_tags назначаемый на любые вводимые строковые значения уже видимо решает эту проблему? плюс в стандартных виджетах выводятся строки по умолчанию с экранированием, хотя где выводятся строки без виджетов проследить непросто конечно
                      • 0
                        вообще я лично считаю это неправильным, менять пользовательские данные. Вдруг человек хотел поделиться в комментариях снипетом кода? Всякое бывает. А тут взяли и порезали. Ну и да, разработчик может и забыть это сделать. Ну и опять же, возможны ситуации когда должны быть разрешены отдельные теги (хотя через strip_tags это можно захэндлить).

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

                        В Twig например экранирование происходит по дефолту, если мы не задали при выводе других параметров. Стандартный вывод значения ({{some.prop}}) прогонит значение через фильтр. При желании мы можем подифицировать параметры экранирования через фильтры (raw и т.д.)
                        • 0
                          Про Twig — также работают все стандартные виджеты, тоже по умолчанию используется формат с экранированием, но можно его изменить. Для вывода вне строчек используем функцию шорткат — коротко-удобно и настраивается в одном месте, но опять же конечно надо постоянно следить, чтобы никто не забыл обернуть вывод…
                    • 0
                      > Им вообще бандаж нужен
                      как вариант — тим лид хорошо помогает для начала, но не всем с этим везет конечно :)
                      • +1
                        тим лид это один человек, а когда технология ограничивает и учит правильным вещам это намного лучше. Когда уже привыкаешь к хорошим практикам и осознаешь почему они хорошие, тогда уже можно потихоньку снимать ограничения.
        • 0
          > Если разработчик собирается использовать решение которое поддерживать может только он то от него надо бежать.
          Вообще, если исходный код передается заказчику, то ничего страшного. И, у меня есть положительный опыт: я работал в vipro.ru мы писали свою CMS, где все было сделано для людей. Битрикс рядом не валялся.
      • +3
        Может вам просто стоит начать искать команды проф. разработчиков для таких проектов, которые вы упоминаете, или сменить место поиска (если задачи на команду не тянут)?
        А то возникает чувство (поправьте, если я не прав), что вы пытаетесь в той тусовке, где 90+% заказов «поправить что-то на вордпрессе» найти людей, которые не имеют опыта корпоративной разработки.
    • 0
      Честно скажу что мне встречались обратно противоположные сценарии, когда php разработчики превращали проект в серое болото, тут скорее у кого от куда руки растут. Хотя в php еще пару лет назад можно было встретить больше полоруких разработчиков, маслом им что ли там намазано.
  • 0
    Интересно, а есть ли (хотя бы в планах) что-то типа форка РНР, который бы не обеспечивал обратную совместимость, но убирал бы значительную часть костылей древности?
    • 0
      Такой язык никому не нужен. Собственно часть «нападок» на PHP в целом из-за ощущения, что это lagecy. Если в PHP поломают капитально совместимость, то другие языки стоять и ждать не будут.
      • 0
        Именно поэтому я говорю про форк, а не ставлю вопрос «когда-нибудь в РНР уберут уже эту strpos-substr?».
        Такой язык никому не нужен.

        Это личное предположение или результат какого-то исследования?
        • 0
          Это личное предположение или результат какого-то исследования?

          Результат личного исследования. Новому PHP надо будет сражаться со старым PHP + с Python, Ruby, Go, JS, C# и т.д.
          • 0
            Python 3 — все таки решились, там много не совместимых нововведений, из-за этого на него очень неспешно переходят конечно, но процесс идет
            • 0
              При том, что комьюнити Python с трудом можно назвать консерваторами… у PHP мне кажется с этим будет всё хуже, но тут уже моё личное ИМХО.
              • 0
                Python 3 вышел 7 лет назад, и как широко он используется сейчас?
                Через 7 лет после выхода PHP 5.0 он был уже на 90% сайтов.
                • 0
                  Я не понимаю как ваш вопрос связан с моим комментарием.
                  • 0
                    Это был риторический вопрос. По этой статистике только 1% сайтов на Python использует третью версию.
                    • 0
                      Это тут причём? У PHP разве был рывок когда они поломали полностью обратную совместимость при наличии конкурентов?

                      ЗЫ интересно как они считали? Я уже как 3 года использую тройку.
                    • 0
                      у PHP все очень жестко завязано на обратную совместимость (и я не считаю что это плохо). Просто иногда читай php internals начинаешь расстраиваться, ибо некоторые люди сводят хорошие идеи к обсурдным. Но это так же нормальное явление в большом комьюнити. Всегда найдутся недовольные.
    • +3
      Только вчера слышал тот-же вопрос про Java. Опыт Python показывает, что это очень опасно для языка. Хотя «эффект бега с развязанными шнурками» тоже очень неприятная штука. Возможно, самый правильный путь — не остановиться и завязать шнурки, а потихоньку выдавливать «древности» в deprecated и по одной запрещать в каждом следующем релизе. Тогда сразу много всего переписывать не придётся, исправления старого кода будут простыми и вреда будет меньше, чем пользы от отказа от этих вещей. В этом русле собственно и идёт развитие PHP.
      • 0
        Отлично, что есть чей-то опыт, с которым можно сравнить! Согласен, вероятно, это не самый лучший сценарий, но… если бы оно уже было, я бы как минимум попробовал. Очень нравится как развивается РНР в последнее время — и направление, и темпы.
      • +2
        Python к слову вроде наконец до вязал почти все шнурки и троечка становится основой новых проектов. Но мне больше интересен Pyston.
    • 0
      ну как вариант форка — Hack
    • +1
      Не форк, но язык очень похожий на PHP и при этом без костылей: Hack — уже production ready.
      Есть ещё JPHP — PHP под JVM, но не уверен насчёт production.

      А в целом чем вам мешают «костыли древности»? Просто не пользуйтесь «плохими» частями языка.
    • 0
      Ну вообще PHP 7 — большой шаг в этом направлении, с очень достойной совместимостью
    • 0
      А смысл, если не будет обратной совместимости, можно просто взять любой хороший существующий язык, с уже созданной архитектурой. Или в PHP есть что-то такое уникальное и близкое к вашему сердцу, и вы хотите это сохранить?
      • +1
        Может я ошибаюсь, но среди мэйнстрим языков нет ни одного с такой же легкостью деплоя и прочего администрирования веб-приложений на эталонных реализаций как у PHP. Основной юзкейс PHP в вебе — не апп-сервер, общающийся с веб-сервер, а скрипт, вызываемый веб-сервером. Даже с оберткой php-fpm тот факт, что технически есть fast-cgi сервер, скрывается от разработчика. Для него это всего лишь одноразовый скрипт, который отрабатывает и умирает, что позволяет минимально думать об отдаче ресурсов, даже если бы не было автоматического сборщика мусора.
        • +1
          Вы можете взять любое приложение под веб-сервер на любом языке программирования, и схема взаимодействия с веб-сервером будет такая же.
  • +5
    Давайте посмотрим в интернете, какие проекты все-таки используют PHP:

    И выбрали его т.к. на тот момент особо не было альтернативы.

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

    Увы, проекты которые написаны на PHP образца нулевых, всё ещё встречаются и осложняют жизнь. А так, сейчас конечно к самому PHP претензий гораздо меньше.
    Подскажите как обстоят дела в PHP с написанием долго живущих демонов и асинхронных веб приложений?
    • 0
      Подскажите как обстоят дела в PHP с написанием долго живущих демонов и асинхронных веб приложений?

      Кардинально ничего не поменялось. Либо менять архитектуру (например, sub-pub), либо использовать другие инструменты.
      • +1
        Воу, воу. Решений полно, например этот проект затисался уже в php-fig, надеюсь в скором времени увидеть фреймворки с коробочной многопоточностью.
        • 0
          Отличная библиотека кстати, спасибо! Но всё же, проблемы PHP с утечками и т.д. уже исправлены? Где про это можно почитать?
          • 0
            С утечками сталкивался года два-три назад последний раз, но и то можно было списать на мою криворукость.
            Думаю, что почитать про актуальные и закрытые утечки можно здесь.
        • 0
          Подобные инструменты появились довольно давно. Насколько они стабильны, производительны и надёжны — [для меня] вопрос открытый. Опять-таки, для себя я этот вопрос решил использованием более подходящих инструментов (в моём случае — Go).
  • –2
    Пробовал разбираться с Java. С удивлением обнаружил, что первые изучаемые конструкции мало чем отличаются от PHP. Правда приходится жёстко расписывать какая переменная что хранит, т.е. кода получается больше.
    • +16
      Попробуйте ещё английский поучить. Вы будете приятно удивлены, что там многие слова тоже из PHP заимствованы.

      > Правда приходится жёстко расписывать какая переменная что хранит, т.е. кода получается больше.
      Если без шуток, то по моему личному опыту строгая типизация — это преимущество, а не недостаток. Лишние байты кода на производительности труда сказываются незаметно, а ряд ошибок/опечаток, которые отлавливаются на этапе компиляции, время и нервы экономят намного больше.
      • –1
        Я к тому, что если нет специфических требований использовать другой язык, то и смысла бросать PHP нет.
        • +2
          А что такое «специфические требования»? Вы в большинстве случаев не сможете использовать Java там, где сможете использовать РНР, и не сможете использовать РНР там, где сможете использовать Java. Несмотря на схожесть закорючек. Изучая Java, вы расширяете свой кругозор в сторону серверов приложений, или разработки для мобильных устройств, например, которые вам недоступны как РНР-программисту.
          • +2
            Вы в большинстве случаев не сможете использовать Java там, где сможете использовать РНР, и не сможете использовать РНР там, где сможете использовать Java.


            В большинстве случаев можно использовать и Java, и PHP, и C#, и С, и C++, и asm, и Brainfuck — возражения против того или иного языка носят экономический и религиозный характер в большинстве случаев.
            • +1
              Разве? А мне казалось, что возражения против того или иного языка в подавляющем случае определяются возможностями имеющихся библиотек, фреймворков или сред выполнения, имеющихся для этого языка. И что соответствующие «экосистемы», например, для Java, PHP или С практически не пересекаются. Вы, если вам важен сугубо теоретический результат, сможете написать веб-сайт и на ассемблере. Сделать CGI-приложение, которое генерирует контент, подцепить это к веб-серверу, и оно как-то будет работать. Но в реальном проекте ведь такой вариант вы никогда не будете рассматривать просто по технологическим соображениям. Вы скорее всего даже между взаимозаменяемыми технологиями вроде PHP и ASP.NET выбирать не будете (кроме частных случаев, когда проект делается вообще «на голом месте»), а сузите свой круг выбора до того, что лучше впишется в имеющуюся инфраструктуру. Виндовый домен, майкрософтовский софт, внутреннее корпоративное приложение — будет ASP.NET ± MVC. Публикация на хостинге? Вероятно, PHP или что-то аналогичное. И т.д.
              • 0
                Имеющаяся у заказчика инфраструктура — это чисто экономический вопрос приобретения осей. Но, кстати, современные движения в области системного софта, прежде всего в части виртуализации и контейнерации, вполне допускают запуск PHP-приложений в системах с Windows на железе в виртуальным *nix окружением (вроде как Windows Server 2016 вообще нативно поддерживает запуск Linux и FreeBSD контейнеров Docke), равно как запуск .NET-приложение в *nix окружении. Чем дальше — тем меньше приходится думать разработчику о том под какой осью реально будет крутиться приложения, это становится заботой исключительно администраторов.
                • 0
                  Так денюжка — это же универсальный измеритель, и вообще любой вопрос при желании можно свести к экономическому :) Например, можно ли на PHP писать под PDP-11? Да можно, конечно. Нанять программиста, чтобы он портировал интерпретатор под PDP-11, и можно. Сугубо экономический вопрос на трудозатраты, верно?
                  А если без шуток, то это как раз вопрос технологический. Если инструмент предназначен для выполнения каких-либо задач, но его использование дороже или требует квалификации, то это экономика. Если не предназначен, то это технология. РНР не подходит для работы в Windows-домене, просто потому, что там сама исполняемая среда не имеет вменяемых средств интеграции с Windows-приложениями. Поэтому для таких задач вы действительно не будете его рассматривать. А если вдруг будете — это признак непрофессионализма. Вроде «Я знаю только этот инструмент, поэтому я буду плакать, жрать кактусы, срывать сроки, но упорно крутить костыли, пытаясь его сюда впихнуть».
        • +5
          Смыл бросать php есть когда:

          * Нужна выская производительность.
          * Нужна поддержка многопоточности.
          * Нужен удобный механизм хранения разделяемых ресурсов в оперативной памяти.
          * Хочется исключить ошибки, которые можно исключить системой статической типизации.
          * Когда достала необходимость ставить доллары перед каждой переменной.
          • –5
            * Нужна выская производительность. -> писать тормозные и тяжелые решения можно на любом ЯП
            * Нужна поддержка многопоточности. -> есть много потокобезопасных библиотке
            * Хочется исключить ошибки, которые можно исключить системой статической типизации. -> php7
            • +4
              писать тормозные и тяжелые решения можно на любом ЯП

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

              Нету поддержки concurrency в языке.
              php7

              Развивается язык. Это не может не радовать. Проверка типов при компиляции или в рантайме произходит?
              • +1
                Компиляции как таковой нет, но есть статические анализаторы, которые вы можете запустить, например, перед коммитом в репозиторий — это и будет аналог проверки типов «при компиляции». В рантайме проверка тоже будет происходить, если указаны интерфейсы и, начиная с PHP 7, скалярные типы.
          • +1
            >* Когда достала необходимость ставить доллары перед каждой переменной.
            Ну это прям мега довод) Или это изза нынешней финансовой ситуации и ипотеки в валюте?))

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

            >* Нужна поддержка многопоточности.
            Тоже есть.

            >* Нужна выская производительность.
            Если нужна высокая производительность то тогда не php надо бросать, а учить с++ и писать частично на нем именно те части, которые требуют высокой производительности, java тут будет не полноценным выходом.

            >* Хочется исключить ошибки, которые можно исключить системой статической типизации.
            выше написали про php 7, но в целом никто не мешает запилить например ассёрты уже сейчас.

            • +1
              Перед каждой переменной нужно ставить дополнительный символ, которы набирается с шифтом. Это раздражает.

              Есть удобный механизм для хранения разделяемых ресурсов в памяти? Чтобы, например, каждый запрос использовал один и тот де коннекшн к БД? Когда я интересовался вопросом, для этого нужно было использовать отдельный сервер. В языке для этого ничего не было.

              Есть поддержка многопоточности? Прямо concurrency? Если это так, то язык за последние 2 месяца сделал гигантский прорыв. Можно снипет, как создать 2 потока, которые имеют доступ к разделяемой переменной? Как сделать критическую секцию? Есть ли модификатор volatile?
              Если нужна высокая производительность то тогда не php надо бросать, а учить с++ и писать частично на нем именно те части, которые требуют высокой производительности, java тут будет не полноценным выходом.

              Всё зависит от требуемой производительности. И наличия легаси кода. С легаси кодом — действительно легче переписывать куски. Если проект новый, то java (дажа java) даст рост производительности в разы.
              выше написали про php 7, но в целом никто не мешает запилить например ассёрты уже сейчас.

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

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

                >Есть удобный механизм для хранения разделяемых ресурсов в памяти?
                >Чтобы, например, каждый запрос использовал один и тот де коннекшн к БД?
                Это т.е. несколько хттп запросов к пхп и конекшен один? А зачем так? Берем тогда phpDaemon, производительность у него на уровне nodeJS. Если именно ресурсы как данные, то apc есть.

                >Есть поддержка многопоточности? Прямо concurrency?
                Сыплете терминами всякими, прям как гуманитарий какой. Мы то люди простые, вы задачу опишите, которую хотите решить, там и понятно будет может это пхп или нет. На счет же всяческих указателей компилятору что оптимизировать что нет, тут конечно же нет.

                >Если проект новый, то java (дажа java) даст рост производительности в разы.
                Ну да, правда есть такой огромный шанс, что когда его на java напишут он уже нафиг никому не нужен будет.
                С пхп все несколько веселее, прототип — за месяц на коленке, тут главное опыт иметь и чтот-то вроде архитектуры придумать. Далее можно тупо кусками тяжелые моменты запиливать, например, демонами на с++. На больших данных и тяжелых манипуляциях с ними — с++ джаву сделает только в путь.

                • +1
                  > Это т.е. несколько хттп запросов к пхп и конекшен один? А зачем так?
                  Хм. Хороший вопрос. Я вспомнил, как лет семь назад писал к PHP свой экстеншен, только для того, чтобы была возможность обеспечить один разделяемый пул коннектов в рамках всех запросов. Потому что иначе сервер просто ложился под нагрузкой.
                  • –2
                    Ложился только от коннектов? Странно. Или вы так что-то вроде кеширования намутили?
                    Если речь идет про то что база не справлялась, то понятно дело, что PHP тут не причем.
                    Если же про то что application сервер падал, ну т.е. там где PHP крутится — то тут у нас все делается по другому, таких серверов ставится несколько, добавляются по мере необходимости, пока их пара десятков это выгодно, т.к. железо в целом стоит дешевле программистов :)
                    • +2
                      Ничего странного. Любой коннект к базе — это значительные накладные расходы на сам коннект плюс на поддержание пользовательской сессии в СУБД. Поэтому если есть возможность их переиспользования, производительность вырастает очень существенно. В моем случае единый пул коннектов вообще убрал в этом узле проблему производительности как класс, без необходимости наращивать мускулы железяке. Это только кажется, что сервер дешевле программиста. Обычно оценивают только стоимость самого сервера, но при этом забывают, что на чашу весов сервера надо положить ещё его установку, конфигурирование и далее эксплуатационное обслуживание, причем тоже живыми людьми с вполне недешевым рабочим временем. Плюс, новый сервер — новая точка отказов.
                      • 0
                        >Ничего странного. Любой коннект к базе — это значительные
                        >накладные расходы на сам коннект плюс на поддержание пользовательской сессии в СУБД.
                        Коннект по сравнению со всем остальным это копейки обычно, опять же непонятно что вы такое делали? Да и что за база была? Ну ни разу даже не слышал про проблему с такой стороны. У вас был пучок пхп скриптов запущенных как демоны? Вообще обычно узкое место — это хранение данных, т.е. сколько можем записать прочитать, какой язык это уже дело второе.

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

                        > Обычно оценивают только стоимость самого сервера, но при этом забывают,
                        > что на чашу весов сервера надо положить ещё его установку,
                        >конфигурирование и далее эксплуатационное обслуживание,
                        >причем тоже живыми людьми с вполне недешевым рабочим временем.
                        Сочувствую, что вам приходится работать с людьми, которые забывают столь важные вещи)
                        Впрочем я про то, что 10 или 20 серверов разницы по поддержке почти нет, они же типовые будут. Все разворачивается и настраивается почти автоматом, если, конечно, все профессионально делать. Сейчас огромная куча разных программных средств, которые очень сильно облегчают работу. По сути добавление сервера сводится к загрузке образа и запуску установочного скрипта. Для мониторинга также есть куча всяких средств.

                        >Плюс, новый сервер — новая точка отказов.
                        Это вы вообще про что?) Ну как бэ банально балансер же можно настроить, чтоб он дальше запрос перекидывал, если какое-то железо сдохло)
                        • +2
                          Со «всем остальным» — это какое остальное вы имеете в виду? Найти запись по индексу в таблице? Нет, коннект обычно будет осуществляться дольше. Сложный запрос с кучей условий/объединений, и потом обновление по нему? Ну да, коннект обычно будет осуществляться быстрее. И то, и другое — достаточно типовые задачи. Поэтому что тут смущает, непонятно. Конкретно эта система — это был автомат для платежной системы, который должен был быстро молотить выборки по состоянию счетов для сети собственных терминалов и гейтов банков.

                          > Так можно посмотреть на цены, ну и мы же не имеем ввиду джуниоров работающих за еду в роли программиста?
                          _Любого программиста_ Сколько стоит, скажем, месяц работы хорошего программиста? Ну четыре-пять тысяч долларов в столице. Если он потратит пару недель своей работы на то, чтобы сэкономить на установку целого сервера, это окупится за полгода.

                          > Впрочем я про то, что 10 или 20 серверов разницы по поддержке почти нет, они же типовые будут.
                          Т.е. в тех задачах, где можно было просто оптимизировать код, вы предлагаете не просто забить на оптимизацию, а поставить уже даже не дополнительный сервер, а целую ферму. И развернуть инфраструктуру для обслуживания этого добра. Мне кажется, экономическую часть вашего диплома вы в своё время завалили :)

                          > Это вы вообще про что?) Ну как бэ банально балансер же можно настроить, чтоб он дальше запрос
                          > перекидывал, если какое-то железо сдохло)
                          Ну да, только это будет для следующего запроса, а не тех, которые были на железке в момент сбоя. И то, когда железо перестанет откликаться. И в том сферическом случае, когда у вас такой сервис, который всё-таки предполагает целую ферму серверов в кластере.
                          • –1
                            >Если он потратит пару недель своей работы на то,
                            >чтобы сэкономить на установку целого сервера, это окупится за полгода.
                            Откуда такие цифры как пара недель и целого сервера? Обычно речь идет о процентах, ну мыж не говорим о системе которую писали джуниоры и ни разу не проверяли под нагрузками?

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

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

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

                            >Ну да, только это будет для следующего запроса, а не тех, которые были на железке в момент сбоя.
                            Чтото я туплю, но разве повысится статистически шанс потерять запрос при увеличении количества серверов и таком же количестве запросов? Учитывая что время обработки сильно отличаться не будет.
                            • 0
                              > Откуда такие цифры как пара недель и целого сервера? Обычно речь идет о процентах
                              Цифры условные. Я просто обозначил порядок. Мы ведь говорили об оптимизации, которая позволит обойтись без кластера.
                              > Нет я лишь говорю что вы асбоютно не правы, и что в нормальном проекте
                              > для еще десятка серверов не придется заводить в два раза больше админов.
                              Вы просто забыли сначала упомянуть, что «нормальный проект» в вашем понимании — это когда трудится большая ферма с балансировщиком нагрузки, и плюс десяток/минус десяток серверов, это не проблема. Т.е. остальные 99.99% проектов, которые прекрасно помещаются на одном хосте, не нормальные. Но я всё-таки имею в виду большинство, а не достаточно редкий частный случай.

                              > Мой опыт показывает, что сервис на java дольше разрабатывается, раза в два, прогеры в целом стоят
                              > больше, а в результате выйгрыш на серверах раза в два в лучшем случае.
                              Мы вообще про Java сейчас не говорили, а только про РНР :) По-всякому бывает на самом деле. И в любом случае, эти две платформы крайне редко конкурируют в рамках одного или даже одинаковых проектов.

                              > Ну и также покупать серваки смысл есть не всегда, есть аренда, а там окупаемость совсем другая.
                              Математика тут простая. Любой облачный провайдер будет нести те же затраты на сервер, что и вы, плюс он ещё платит свои налоги и хочет поиметь прибыль. Экономия для клиентов достигается за счет того, что облачный провайдер разделяет свои ресурсы между многими клиентами, каждый из которых «в среднем» потребляет чуть-чуть от арендуемой мощности. Если же ваш проект употребляет сервер «под завязку», вам всегда будет дешевле иметь собственный сервер, чем арендовать.

                              > Чтото я туплю, но разве повысится статистически шанс потерять запрос при увеличении количества
                              > серверов и таком же количестве запросов?
                              Нет, статистически не повысится. Речь была о том, что балансер — не панацея от проблем, и не избавит клиентов от потери транзакции.
                        • +1
                          Коннект по сравнению со всем остальным это копейки обычно, опять же непонятно что вы такое делали?

                          Установка соединения это вечность. Если по запросу надо только вернуть небольшой кусок данных, а это характерно для REST API — большая часть времени будет затрачена именно на установку соединения.
                          • 0
                            Как бы отдавать напрямую данные из базы довольно фиговая ситуация, однако в среднем большая часть должна быть покрыта кешами.
                            • 0
                              Обработка данных это тоже мгновения. А запросы к бд кешируются, но надо сначала установить коннект.
                            • +2
                              Именно такие комментарии и делают плохую репутацию пхп разработчикам. Вам стоит почитать Тенебаума прежде чем что-то утверждать. И даю подсказку — чтобы взять данные из кеша к нему тоже стоит подключиться, т.е. установить коннект.
                          • 0
                            Всё зависит от времени формирования этого куска. Одно дело выбор одной строки по ключу из уникального индекса, совсем другое сложный агрегирующий запрос, почти не использующий индексы.
                            • 0
                              Хм. Вообще-то если вы видите «сложный агрегирующий запрос, почти не использующий индексы», его обычно нужно брать и переписывать так, чтобы он был менее сложный, и использовал индексы, а не возражать: «Нууу, коннекшен иногда выполняется быстрее, чем выборка» :)
                  • 0
                    Не могу не накинуть чуть справедливости по поводу постоянных коннектов php.net/manual/en/features.persistent-connections.php
                    Они есть и очень очень давно.
                    • 0
                      А это не совсем то, что требовалось. Нужен был именно пул подключений, с возможностью наращивания числа открытых коннектов при росте нагрузки на узел, и с их высвобождением, и т.д.
                      • +1
                        Ну как бы, это можно реализовать поверх pconnect. Да и в чем смысл организовывать пул своими силами, если у нас и так есть ограничения, сколько одновременно запросов может обрабатываться (по количеству воркеров). А держать постоянно открытыми 3-4 соединения в принципе не затратно.

                        Все же другие варианты где это имеет смысл (ну или я вижу в этом смысл) только в контексте демонов. И даже в этом случае «экстеншены» свои писать не надо.
                        • 0
                          В рамках скрипта PHP ведь не организуешь — он отработал и ушёл. Разделяемых ресурсов как таковых там нет, чтобы как-то организованно управлять пулом. Плюс, была необходимость вешать запросы в очередь при заполнении пула, т.к. количество лицензий на подключение к базе данных было лимитировано «сверху». Я уже всех деталей не вспомню, всё-таки столько времени прошло, но помню, что проблему со всех сторон мучили, прежде чем решиться на разработку экстеншена. И pconnect, и конфигурированием апача, и т.д.
                          • 0
                            В рамках скрипта PHP ведь не организуешь — он отработал и ушёл.

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


                            опять же, у вас ограниченное количество воркеров (пых синхронный по дефолту), у каждого свое соединение, не надо никаких очередей.

                            В целом я думаю что разработка экстеншена для управление соединением с базой это… мягко скажем дикая крайность. Потому меня так и заинтересовало выяснить причины — любопытно какие задачи это решало.
                • +4
                  Ага вот, поэтому появляется что-то вроде scala, которая как java, но не совсем.

                  Которая как джава, но не совсем это groovy. scala это совсем не как джава, но исполняемая в джава машине.
                  Почему-то никто не плодит всяких «улучшенных пхп»

                  В основном потому, что это технически сложно. Сделать новый язык, который будет исполняться в джава манине —
                  задача отностительно простая. Автоматом этот язык будет иметь доступ к джава коду.
                  Поэтому таких языков много.
                  Ну и есть ещё одна причина. Когда java программист уставал от джавы у него не было альтернатив. Так и
                  появились эти языки. У программиста на php альтернатив море — начиная от ruby и кончая Go. Для перехода с
                  php ему не надо ничего, кроме желания.
                  Это т.е. несколько хттп запросов к пхп и конекшен один? А зачем так?

                  Чтобы не поднимать новый коннекшн на каждый запрос.
                  Берем тогда phpDaemon, производительность у него на уровне nodeJS. Если именно ресурсы как данные, то apc есть.

                  Вот я и говорю, удобно это не сделаешь. Только приблудами всякими.
                  Сыплете терминами всякими, прям как гуманитарий какой.

                  Эти термины знает каждый программист. Кроме тех, конечно, которые используют языки не поддерживающие многопоточность.
                  Чтобы раскрыть что такое многопоточность и зачем она нужна нужно написать целую книгу и не одну.
                  php многопоточность, увы не поддреживает.
                  На счет же всяческих указателей компилятору что оптимизировать что нет, тут конечно же нет.

                  volatile нужен не для оптимизации, а чтобы прорамма вообще работала.
                  Ну да, правда есть такой огромный шанс, что когда его на java напишут он уже нафиг никому не нужен будет.

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

                  На джаве примерно так же, только можно не запиливать демоны.
                  На больших данных и тяжелых манипуляциях с ними — с++ джаву сделает только в путь.

                  Большие данные это зачастую Hadoop и Spark.
              • +1
                >Перед каждой переменной нужно ставить дополнительный символ, которы набирается с шифтом. Это раздражает.
                Ну детский сад, ну IDE уже наконец настройте чтобы он за вас это делал. Вы еще скажите что по пять мегабайт кода в день пишите, что от лишнего нажатия на шифт устаете.
                • 0
                  Шутки шутками, а я как-то увлекшись процессом «пробил» мизинцем на ноуте клавиатуру как раз в районе левого шифта. Точнее сломал крепления, поддерживающие плату с клавишами в том районе. Так что, обилие нажатий на шифт в процессе программирования на РНР действительно вредно. шучу
              • 0
                Перед каждой переменной нужно ставить дополнительный символ, которы набирается с шифтом. Это раздражает.


                Если этот аргумент серьезно рассматривается, то PHP умрёт (или, хотя бы, опустится до доли Perl-а — когда-то своего основного конкурента) очень не скоро :) Плюс в явном разделении пространств имён переменных и других сущностей есть свои плюсы. Как минимум меньше ограничений при выборе имён.
            • +1
              «Если нужна высокая производительность то тогда не php надо бросать, а учить с++ и писать частично на нем именно те части, которые требуют высокой производительности, java тут будет не полноценным выходом.»
              Просто интереса ради почитайте про HFT, а, заодно, на чём там пишут. Не ручаюсь за полный список языков, но java там точно участвует и не на последних ролях.

              ">Нужен удобный механизм хранения разделяемых ресурсов в оперативной памяти.
              Он там есть."
              Вот прям не велосипеды и не Mongo/etc, а прямо сервер приложений/ядро оного на языке, способные обслуживать множество запросов? И скрипт не грузится перед каждым выполнением заново? Если так — мои поздравления, язык наконец-то начинает подбираться к промышленным/«энтерпрайз»-языкам.
              • 0
                >Просто интереса ради почитайте про HFT
                Ок спасибо, просто в некоторых задачах на практике c++ показал себя сильно намного лучше, возможно я что-то делал не так.

                >И скрипт не грузится перед каждым выполнением заново?
                Да это давно уже нет, nginx воркеры все такое, а есть еще hhvm

                >Вот прям не велосипеды и не Mongo/etc, а прямо сервер приложений/ядро оного на языке,
                >способные обслуживать множество запросов?
                Можно и так сделать, только смысла особого не имеет, реализации общей памяти да, могут показаться надстройкой, однако для решения задач вполне себе хватает и пользоваться в целом удобно.
                • +1
                  Большинство сравнений, где с/с++ выигрывают больше нескольких процентов — неудачная реализация на Java. Есть случаи, когда Java действительно плохо подходит, но их не так уж и много.

                  Пока сам не работал с джавой — даже не задавался мыслями о пользе разделяемых данных… правда я достаточно быстро ушел на Java (о чём не жалею) и вот тут уже и увидел пользу.
        • +1
          Если смотреть совсем узко, то Java тупо ест на порядок меньше ресурсов на отрисовку такой же страницы. Плюс Java — это язык, на котором написан весь сервер, а не только модуль для Apache, хотя насколько это важное преимущество — ещё вопрос.

          Там, где есть LAMP, смысла бросать PHP точно нет. Вообще смысл «бросать» что-то бывает довольно редко.
          • 0
            PHP — это не только модуль для Apache. Можно и без Apache вполне обойтись используя Nginx для отдачи статики и проксирования запросов к PHP-FPM. На счёт ресурсов ничего не могу сказать. Измерений не делал. Но при небольшой нагрузке связка работает и на виртуалке с 512Мб помяти.
            • +1
              Скажем так, сейчас для использования Apache мне нужны веские доводы.
              • 0
                Я пока только один довод слышал — требуется исключительно поддержка .htaccess. Если бы к nginx прикрутили заменитель, но большинство бы от Apache совсем отказалось.
                • 0
                  Есть ещё один довод — имеющаяся инфраструктура уже работает на Apache и параллельную никто разворачивать не собирается. Тогда приходится вспоминать как пишется .htaccess :)
          • +5
            Про вас уже писали, что вы застряли в прошлом десятилетии. Какой модуль apache?!
          • 0
            Можно поподробнее про «на порядок»? И что считается «ресурсами на отрисовку» — память, выделяемая при запуске сервера до прихода первого запроса туда входит или нет? Как минимум, потребляемая память состоит из постоянных ресурсов на поднятие сервера и ресурсов потребляемых на один запрос (а после него освобождаемых).
  • +7
    Ну да, а ABAP использует такой гигант как SAP.
    Facebook использует не чистый php, и разрабатывают Hack.

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

    P.S. Какой удобный пост, чтобы словить минусов в карму
  • +3
    Ну так пусть ноют. И валят куда подальше. У остающихся будет выше зарплата )))

    А если серьезно — то у PHP на ближайшие лет пять альтернативы нет. И вряд ли появится. Особенно это очевидно стало с выходом PHP 7.
    • –5
      Вангую угрозу со стороны JS после реализации классов и прочего ООП. Над nodeJS работает очень много крутых специалистов с мощным матаном, сам не пользую, но наработки типа libUV очень впечатляют.
      Конечно не пять лет, но не будем зарекаться, впрочем.
      • +2
        Я про пять лет потому, что это как раз средний срок жизни технологий и экосистем. PHP уже третий такой срок переживает (условно — «старый», «пятерка» и теперь «семерка») и ничего — делается только лучше.

        Не вижу я угрозы со стороны JS, вот что хотите делайте. Не в состоянии себе среднестатистический джуниор быстро и решительно сломать себе мозг, чтобы хорошо писать на JS. На PHP же за год активной работы любое криворучье при наличии вменяемого тьютора доводит себя до промышленных стандартов.
      • 0
        На nodeJS большой проект писать и поддерживать дороже, там не только с ООП проблемы, их там еще оч много, пока все допилят и привыкнут, те же лет пять точно пройдут а скорее намного больше.
  • 0
    Критика нужна, даже неконструктивная! Вернитесь на те же 10 лет назад и всспомните какой поток негатива изливался на Java, всё ещё живо предубеждение что Java тормозной, хотя быстродействие кода в 99% зависит от прокладки между ТЗ и кодом. Критикуется то что развивается, имхо.
    Уверен что через 10 лет не меньше критики будет в отношении JS.
    • +1
      В отношении JS и сейчас немало критики, но разница в том, что JS безальтернативен для фронтенда (если не учитывать языки, компилирующиеся в JS, типа TS или CS).
      • +1
        На фоне критики php, критика JS — это ворчание из угла. То ли ещё будет когда начнётся массовое использование стека с nodejs…
        • +22
          Как front-end разработчик заявляю: у js адское количество проблем. Не буду говорить за всех, но у меня сложилось примерно такое ощущение:
          php-разработчики любят php
          python-разработчики обожают python
          ruby-разработчики влюблены в ruby
          js-разработчики на одном месте вертели js (повторюсь, чисто мое ИМХО)

          Посмотрите сами — каждый день появляется по десятку библиотек и фреймворков, в которых авторы пытаются закрыть несовершенство языка. Раз в год появляются крупные и громкие релизы, которые переворачивают всю разработку с ног на голову (jQuery, потом Backbone, потом Angular и Ember, вот недавно React, ждем, что же будет дальше). Раз в три-четыре года появляются надстройки типа CoffeScripts, Dart, TypeScript, EJX, которые теперь еще начали перемешиваться между собой с адской силой. Теперь еще и релизы ES каждый год. Браузеры еще в ES6 толком не могут (нативно), а на подходе ES7 (ES2016 вроде, теперь по годам называют), который вдобавок ужасно вкусный.
          Ну и все это заправлено соусом из пугающих новичков странных правил вывода типа, кучи мест с граблями, всплытия переменных и рвущим пришедшим из других языков мозг прототипным ООП.
          Но, как будто бы этого мало — чтобы быть топовым разработчиком, необходимо знать это все сразу. Кучу самых новых и адски старых библиотек, технологий, сборщиков. И мало того, чтобы просто знать — нужно постоянно отслеживать новейшие подходы. Облизываться, вытирать слюнки и продолжать пилить проект на легаси, потому что если начнешь переделывать — не успеешь, обязательно выйдет что-то еще новее, еще круче. И вот, ты мегакрутой разработчик, используешь самые передовые технологии, сходил в отпуск на месяц, вернулся — уже устарел и бомж в свой стартап не позовет.
          Так что в отношении JS очень много критики. Просто она какая-то не такая отъявленная, покуда выхода то нет… С другой стороны, не припомню ни одного другого столь стремительно развивающегося и обрастающего библиотеками языка.

          Что касается PHP — язык как язык. Со своими недостатками и преимуществами. Мне сильно подпортило впечатление о нем, что у него очень низкий порог входа, в следствие чего, многие начинают свою карьеру разработчиками именно с него, а в итоге приходится работать с кучей Legacy настолько отвратительного качества, что появляются мысли на подобие «ужасный язык», хотя он лишь инструмент и все зависит от того, как его использовать.
          • 0
            Прочитал)) Это я про js циклюсь под впечатлением от копания под капотом nodejs.
            В целом достойные замечания о бешенной динамике, буду теперь более сочувственно относиться к фронтендщикам.
            А про принятие новых стандартов даже ещё не слышал((
  • +3
    Есть язык программирования С на котором написано на порядки больше, чем на php. Никто, однако, (кроме разве что Линуса Торвальдса) не спорит, что у него есть объективные недостатки.
    В случае с php ситуация похожа, только хуже. Недостатков куча (чего стоит только одна необходимость ставить знак доллара перед каждой переменной), а вот из достоинств только низкий порог входа и повсеместная распространённость на хостингах. Мало того, есть вещи, которые php просто не может (например concurrency).
    Так что программистам на этом языке можно только поапплодировать. Используя очень ограниченный инструмент они умудряются создавать отличные высококачественные продукты.
    Это делает честь программистам, но ничего не меняет в том, чем на данный момент является php. Правда я, как и многие другие, ещё помню времена, когда не было и того. php постепенно развивается и возможно когда-нибудь он изменится настолько радикально, что критиковать его станет сложно. Но это момент ещё не наступил.
    • НЛО прилетело и опубликовало эту надпись здесь
      • +18
        Вчера только новость проскакивала, что госдума призывает отказаться от php из-за необходимости использования знака доллара
        • +6
          Нужно сделать форк пхп, где вместо $ будет image.
      • –1
        Перед каждой переменной нужно набрать символ, для набора которого надо зажать шифт. Кто-то будет спорить с тем, что это неудобно и глупо? Кто-то скажет, что это даёт хоть какие-то преимущества?
        • +3
          Меньше вариантов в автокомплите? :)
          • –2
            Ну, если ты не помнишь первых букв названия переменной, то наверное да :). Но вообще современные IDE думаю способны выдать список переменных, доступных в скоупе.
        • НЛО прилетело и опубликовало эту надпись здесь
          • +1
            Вы про то, что нужно указывать тип переменной? Да, есть такой косяк. Во многих языках его потепенно устраняют автоматическим выводом типа.
            Но, в отличие от доллара в php, тип в java надо указать только при объявлении, а не при каждом использовании. И, в отличие от доллара в php, польза от статической типизации огромна и неоценима.
          • 0
            Обычно в Java тип переменной автоматически проставляется с помощью IDE;-). Это если, конечно, не хочется специально поупражняться и понабивать шишки в блокноте…
    • +3
      С чего хоть вы взяли, что в PHP низкий порог входа? Это настолько распространенный, насколько же и неверный миф.
      PHP — сложный язык. Реально сложный. И хорошо писать на нем не легче, чем на Java, например.

      P.S. Посмотрел в мониторинге, как себя чувствует мой демон, написанный на PHP, работающий с Websokets (чат между клиентами и менеджерами). Чувствует нормально. Аптайм — две недели. Что я делаю не так?
      • +1
        Для того, чтобы просто взять и начать писать — на php достаточно низкий порог входа. Ниже, чем у большинства других языков. Причем, этого низкого уровня достаточно, чтобы клепать сайты-визитки. Однако многие, почему-то, считают, что этого им достаточно и пытаются начинать пилить большие проекты. Как аналогия — научиться прятать формочки при клике на крестик в js можно за 5 секунд гугления: $('#button').click('form').slideUp(). Вот только между подобной конструкцией и строчкой «я знаю js» — пропасть в несколько лет. Так же и в php — между страничкой с инлайновыми SQL запросами до «я знаю php» — большая разница. Вот только часто люди, находящиеся на первом этапе, идут в разработчики, которые потом разрастаются, становятся неподдерживаемыми и их даже страшно открывать.

        P.S. И, в конце концов, смотря с чем сравнивать. На PHP гораздо проще научиться писать, чем на том же C, C++, D или ASM, Haskell, F# и erlang. Про verilog, vhdl и lustre (на нем кто-то пишет?) промолчим, по уровню вхождения до ним всем далеко.
        • +1
          $('#button').click(() => {
          $('form').slideUp();
          });
          

          Конечно же, что это со мной.
          • 0
            Тогда уж
            $('#button').on('click', (e)=>{
            $('#form').slideUp();
            e.preventDefault();
            });
            .on('click', ...) позволит вешать больше одного обработчика на кнопку, а preventDefault на случай, если вы всё-же не собираетесь отправить форму этой кнопкой.
            • +1
              Я про начинающих разработчиков. Какие там preventDefault? Только return false; только хардкор. Да и какие arrow functions? Кому нужны эти babel, сборщики?
              Ну и тогда уж $('form').on('submit'...), чтобы максимально корректным. Ну и если это единственная вставка js, то vanillaJS наше все. Но это отдельный разговор.
      • 0
        С чего хоть вы взяли, что в PHP низкий порог входа?

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

        Да, это так. И это ужасно. Сложность — для языка программирования не достоинство.
        И хорошо писать на нем не легче, чем на Java, например.

        Да, хорошо писать на Java значительно легче. Хотя экосистема Php в последнее время во многом копирует экосистему java.
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Что неправда? То, что php повсеместно распространён? Или про низкий порог входа?
        • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            Какие ещё у php есть достоинства по сравнению с другими языками?
            • +1
              Share nothing.
              • +1
                Реализуемо в любом языке.
                • +1
                  Да, только в случае PHP когда внезапно прилетает проект «ааа!!! трафик!!!» можно что-то сделать потому как share-nothing по умолчанию, а вот в случае, например, Java, чаще всего уже поздно.
                  • 0
                    Если проект пишут неопытные разработчики, то наверное так и есть. Но такие с трафиком в любом случае будут иметь сложности. А если разработчики понимают, что делают, то у джавы есть огромное количество проверенных методов распараллеливания кода. По принципу делай раз, делай два, делай три.
                    • +1
                      В том-то и дело, что внезапно выстреливший прототип на PHP (а прототипы не стоит делать за 100500$ сразу потому что они чаще всего не выстреливают) можно заставить справиться с нагрузкой пока реализуется чистовая версия проекта. На Java во-первых по финансам у нас получится 2 прототипа вместо 20 на PHP, а во-вторых по скорости эти прототипы будут выдаваться раз в несколько медленней.
                      • 0
                        Ну собственно как я и говорил. Квалификация программистов на php ниже, стоят они дешевле, прототип собирают дешевле. Быстрее, чем у джава программистов с нормальной квалификацией, правда, не получится. Но стоить будет действительно меньше. В том числе поэтому php и пользуется такой популярностью.
                        А вот чтобы прототип кто-то хоть раз переписывал начисто я не видел вообще никогда :(.
                        • +2
                          В смысле все прототипы благополучно сдохли?
                          • 0
                            В смысле как только прототип выстреливает менеджеры сразу переходят в режим запиливания фич и не понимают зачем переписывать то, что и так работает.
                            • +2
                              Такое бывает :)
                        • +2
                          Быстрее, чем у джава программистов с нормальной квалификацией, правда, не получится.


                          Почему не получится? Что есть в джава, что ускоряет разработку? Чего нет в пхп?
                          • 0
                            Да ничего особо нет. Поэтому скорость изготовления простых проектов примерно одинаковая. Поэтому на php не получится быстрее, чем на java.
            • +1
              Большой выбор серьёзных и развивающихся фреймворков.
              • +1
                Большой выбор серьёзных и развивающихся фреймворков есть в java, ruby, python, go, c#, scala. Пара веб фреймворков есть даже для С++. Это не отличает php от всего остального.
                • +1
                  Так мы киллер-фичи ищем или просто плюсы перечисляем?
                  Ну и имелось ввиду что фреймворки ориентированы на вэб и их много. Кроме RoR и django ничего сравнимого с symphony, yii, laravel etc не вспоминается.
                  Пара же фреймворков на плюсах пригодны для эмбедед только. А про java в вэб отписывался SamDark
                  • 0
                    Вы правы, насчёт того, что кроме RoR и Django нет ничего особо известного, не считая вариантов с Flask, Bottle, Sinatra
                    но есть такой нюанс — данные фреймворки так или иначе повлияли на имеющиеся в PHP.
                    та же ситуация и с библиотеками, например, behat, на который повлиял cucumber.
                    но я сходу не вспомню фреймворков/библиотек, на которые повлияли Symfony, Laravel, Yii.

                    да, PHP развивается, я как PHP-программист очень этому рад.
                    но иногда создаётся впечатление, что PHP играет «в догонялки» с другими языками.
                    а я бы искренне хотел, чтобы на PHP-инструменты равнялись, при создании инструментов в других языках
                    • +2
                      Какая разница, кто был первый?

                      Yii повлиял на Symfony, Laravel и совсем немного на RoR. Они, в свою очередь, повлияли на Yii. Мы не в вакууме живём и у разработчиков фреймворков не священная война, а обмен опытом.
                      • 0
                        Разница есть в том, что тот кто первый, первый и находит недочёты и исправляет их.
                        В тех же рельсах уже давно как отказались от настроек массового присваивания для моделей и обосновали почему — я с ними полностью согласен. А в Eloquent до сих пор protected $fillable и меня это, как PHP-разработчика, немного угнетает — чувствуется именно отставание.

                        Не надо, конечно же, демонизировать PHP — вполне себе неплохой развивающийся язык. Но надо всё же признать, что ряд вещей в том же python с ruby и, соответственно, фреймворках, сделаны намного удобнее и яляются более зрелыми именно по причине первости.
                        • +3
                          Как-бы нет. Видит и исправляет недочёты второй, если этот второй не тупо копирует, а понимает, что делает. Первый уже завязался на ошибки. Надо обратную совместимость сохранить и так такое.

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

                          Мы в Yii ещё в 2010 переделали умолчания для массового присвоения несмотря на то, как делали в рельсах. Рельсы с GitHub и Хомяковым прилично на этом погорели через несколько лет. Тейлор в Laravel тоже много всего поправил при заимствовании (из Yii 1.1 много штук было ещё в Laravel 3), хотя ему тяжелее. Он фактически в одиночку пилил до недавнего времени фреймворк и, к тому же, ему постоянно надо думать, как с фреймворка получить денег потому как это его основное занятие. Это несколько смещает приоритеты и отвлекает.

                          Что-то в RoR и Django лучше, но что-то хуже.
                          • 0
                            Для того, чтобы не тупо копировать, а понимать, нужно иметь длительный опыт использования копируемого, чтобы отследить все тонкие ситуации.
                    • +1
                      но я сходу не вспомню фреймворков/библиотек, на которые повлияли Symfony


                      Джанга )
                  • 0
                    Я стараюсь перечислить плюсы, которые отличают php от других решений. Большое количество хороших фреймворков к таковым не принадлежит ибо характерно не только для php.
                    Для java есть play framework, есть Spring который на первый взгляд ну очень поход на laravel, только чутка поудобнее, для scala есть play framework2. Для go названий не помню, но там тоже есть.

                    Что есть на php, чего нет на других языках это Wordpress :).

                    Судя по тому, что пишет SamDark он немного отпустил руку с пульса. :)
                    • 0
                      Django-cms(Python); Keystone.js, Ghost(Node.js) с вами не согласны
                      • 0
                        Со мной? Я как раз говорил, что фреймворков много не только на php.
                        • 0
                          а я про cms, которые не только в php
                          • 0
                            Аааа. Про вордпресс это была ирония. Именно вордпресс, а не cms вообще :)
                    • 0
                      Да, я под веб давно ничего на Java не делал. Последний раз это были Spring и Wicket. Ну и, конечно, Hibernate и ещё туча всякой тяжёлой дряни. Сейчас Java использую для Android. Очень приятно.

                      • 0
                        Сейчас у Java с Веб все огонь. Тот же Spring Boot позволит в пару телодвижений сделать апликуху с rest, CRUD любой бд без единого запроса(привет Spring Data), кэши и сессии в каком-нибудь Redis, сечьюрность, какой-нибудь модный-молодежный template engine в духе handlebars и прочие прекрасности. Еще парой телодвижений прикручиваешь Spring Loaded или JRebel(а может XRebel, не в курсе их линейки продуктов, не юзал), чтобы не страдать при разработке от «изменил, сбилдил, задеплоил, посмотрел...».

                        Те кто говорят, что разработка на Java в n раз медленнее X скриптового языка, просто видимо не трогали Java с тех пор(или вообще не трогали и судят с позиции диванного теоретика), как все умные люди поняли, что JavaEE это вообще не комильфо.
                        В последнее время еще очень понравился Play2, там все так же удобно только «нативненько» со Scala и очень многое доступно «из коробки», плюс очень большой упор на асинхронность.

                        Ко всему прочему, не нужны никакие XML не для сборки, не для конфигов(и Spring и Play поддерживают «нормальные» конфиги; билдить и подтягивать зависимости в Gradle/Sbt весьма удобно). Пишешь код на том на чем больше «штырит» под JVM и радуешься.
                • 0
                  Ладно, это всё выше — болтология. Неплохо сформулирована проблема в статье: дискредитация профессиональная и в оплате из-за предубеждений к конкретному стеку технологий.
                  • 0
                    Дискриминация профессиональная — потому, что подавляющее большинство программистов на php имеют низкую квалификацию. Дискриминация по оплате — потому, что большиство задач стоящих перед программистами на php не требуют высокой квалификации для решения.
                    Высококвалифицированных программистов никто не будет упрекать в том, что они используют php, недостатки которого им самим хорошо известны.
                    • 0
                      Вооот, яркий пример — ваше же высказывание. Большинство программистов на любом ЯП имеют квалификацию ниже среднего, ибо градация так сделана, чтобы на 5 мидл один сеньёр приходился, условно. Я знаяю мало плохих программистов, пишущих на php, гораздо больше скрипт-кидди от python и js. А, ещё «плюсисты» полторы лабы скатавшие в универе часто встречаются. Самый плохой вариант php-быдлокодеров — это мамонты, которым ничего кроме легаси десятилетней давности не дававали. Были и на хабре статьи, затрагивающие актуализацию стека, и на тостере трогательные (в хорошем смысле) вопросы встречаются про то как бы вырваться из прошлого.
                      Упрекают за php, инстенктивно, поддаваясь стадному чувству. Совсем свежий анектод: «А зачем вам phalcon, вот у нас круто из фронта запросы строить!» (хз что за стек они используют).
                • 0
                  Какой выбор фреймворков в C#, например? Там есть ASP.NET и все… по большому счету
    • 0
      >Есть язык программирования С на котором написано на порядки больше, чем на php.
      >Никто, однако, (кроме разве что Линуса Торвальдса) не спорит, что у него есть объективные недостатки.
      Фигня в том, что PHP прост, а вот изучить нормально С «обсирателям» уже не получается, поэтому гавнакод на С кажется им адски крутой магией.
      • –2
        в 2015 C/C++ уже не приоритет, у школьников пошла новая волна Haskell
  • +4
    >Тех, кто учит PHP, надо изолировать от общества
    Раз так ненавидят, значит боятся! правильным путем двигаемся!
  • 0
    Я думаю, вся ненависть к PHP из-за вордпресса, друпала (etc...), специалистов по ним за 20 тыр и студий с рекламой на заборе. Вобщем так сложилось: какой спрос, такое и предложение. Был бы это, допустим, python — такое отношение было бы и к нему. Как-то так.
  • +1
    Главный недостаток PHP, по-моему, это даже не знаки доллара перед переменными и не согласованные сигнатуры стандартных функций, а тот факт, что многие вещи задаются настройками самого интерпретатора, подключаемыми к нему расширениями и т.д.
    Ввиду чего использование того же composer несколько ограничено. Раньше, видимо, поэтому и сделали общесистемный PEAR по аналогии с расширениями.
    В каком ещё интерпретируемом языке такое есть?
    • 0
      В Ruby?
      • 0
        В Ruby нет разницы между библиотекой и расширением — это всё gem-ы.
        По-умолчанию они ставятся в систему, с появлением bundler-а куда хочется — чаще всего в папку с проектом, т.е. не нужны права суперпользователя.
        Но и в первом случае нет никаких системных ruby.ini файлов, которые задают как должны работать проекты, использующие его.
        • +1
          Но разве ультрамодная ныне концепция докеров и прочих контейнеров не призвана как раз нивелировать данный мелкий недостаток?
  • +12
    Мне кажется, что позиционирование себя как «программиста на языке х» вообще изначально ущербно. Синтаксис, концепции, парадигмы они во многих языках схожи, есть исчисляемое количество подходов к написанию программ. Сильно ли визуально отличается код на Java, C++, C#?
    Если есть база, то новый язык выучить не так уж и сложно, не сложнее, чем очередной фреймворк. Сложнее понять новую парадигму, другую модель памяти.
    • НЛО прилетело и опубликовало эту надпись здесь
    • +4
      а опыт, а ньюансы? чем больше кода пишешь на языке тем продуктивнее становишься. новый язык все равно будет не привычен.
      • –2
        На голом опыте далеко не уедешь, можно быстро превратится в телефонистку или представителя какой-нибудь ещё вымершей профессии.
    • +3
      Сильно ли визуально отличается код на Java, C++, C#
      По какому-то странному стечению обстоятельств перечислены только языки со строгой типизацией, а два из них так и вообще безопасные;-)

      Если из списка отбросить C++, то оставшиеся два — точно не столько из серии «программист на языке х», сколько из серии «программист под платформу y», позиционирование себя как «программиста под платформу y» уже не ущербно. А вот PHP, Python, JavaScript, Visual Basic — это да, «программист на языке». C++ такой большой, что сам как платформа. Но и то тут рпаспадается на области: PHP, Python, Node JS — это «веб», JavaScript (безальтернативно) — «клиентский веб», Visual Basic — «под Windows», C++ — «под Windows» и «низкоуровневое». Так что у тех, кто «на языке», есть смежная область, куда можно расширять кругозор…
      • +1
        Нода не только веб (кстати, не самая популярная для серверсайда платформа). Это ещё сокетные бэкенды и консольные тулзы (особенно для фронтенда).
  • –3
    Вот и отечественный язык Parser-3 находится едва ли не в худшем положении. Многие до сих пор принимают его за шаблонизатор Parser-2, который закончился в далеком 2002м, а кто-то до сих пор ассоциирует с полной багов поделкой Parser первой версии. В то время как это тьюринг-полный объектный язык, поддерживаемый и развивающийся, а встроенность конструкций в html и возможность покраски данных делают его едва ли не лучшим языком для веб-разработки небольших проектов.
    • 0
      встроенность конструкций в html и возможность покраски данных

      А разве не за это раньше ругали PHP? Ну или ругают, те, у кого знания о РНР >= 10 летней давности. Это уж точно не повод для гордости и не аргумент за «лучшесть для веба».
      Для динозавров: PHP сейчас слава б-гам уже давно отошел от этой парадигмы, если что. Сейчас HTML только через шаблонизаторы принято делать.
      • 0
        Возможно, в случае с PHP тогда проблема была в его кривости, а не во встраиваемости. Я видел и то и другое, меня коробит от встроенных <? но конструкции с ^ выглядят вполне читабельно, особенно если правильно подсветить.
        Хотя скорее, дело в том, что мы слишком увлеклись MVC, и спешим выбросить всё, что в него не укладывается.
        • 0
          Эх, а я так надеялся, что ваш первый коммент про Parser был сарказмом :) было бы гораздо смешнее
          • +1
            Ну вы же понимаете, что высмеивание — это аргумент самого низкого качества.
        • 0
          Меня тоже коробит от <?, поэтому в моём коде всегда ровно один <?php в начале файла и никаких ?> (и то, он проставляется автоматически PhpStorm'ом). С html работает шаблонизатор twig, в котором синтаксис, ИМХО, гораздо органичнее вписывается в html, чем php или тот же parser.
          И да, посмотрел на сайт парсера, судя по датам релизов, он уже начинает отдавать мертвичинкой. А слова apache и cgi заставили нервно дёрнуться. Как в этом вообще можно жить?
          • 0
            Как жить? Если это помогает решать задачи лучше чем другие варианты, то вполне комфортно. Сейчас все популярные инструменты перешли в раздел командной разработки, с максимально жесткой типизацией, многоуровневыми библиотеками объектов и ограничением тех практик, которые в командной работе могут приводить к хаосу. Их даже стали называть «плохими практиками», придав определению характер абсолюта, безусловности.
            Но для индивидуального разработчика все эти вещи только тормозят работу. Всё, что ему нужно — готовая среда и управление видом страницы в коде. Как Arduino.
  • +4
    Это так забавно. Иногда складывается впечатление, что проблема PHP-программистов в том, что они PHP-программисты.
    Поясню.

    Официально я PHP-программист. Т.е. зарабатываю этим денег. Много.

    Но я могу говнокодить на любом языке программирования. Из недавнего вот приходилось на Erlang, C++ и, конечно же, bash script.
    Я уж не говорю про Питон, Руби и ещё тут ваше название. Может на brainfuck с разбегу не напишу, но уверяю вас через час тоже наговнокодю.

    Любой язык это инструмент. Любой инструмент нужно знать и уметь пользоваться.
    До смешного доходит, когда люди узнают, что в языке есть такие конструкции:
    // Контекст: опции передаются в консольный скрипт
    if ($this->getOpt()->{'log-path'})
        return $this->getOpt()->{'log-path'};
    

    Начинают к языку отношения менять (сарказмЪ).

    Если ты не знаешь, что такое кеширование, ORM, паттерны, какая разница на чем писать?
    Проблема не в языке, а в образовании, как бы не банально это звучало.
    • 0
      На Java под какой-нибудь сервер приложений вы что-нибудь писали?
      • 0
        Так чтобы писать нет. Дебажил игры под j2me. Но очень давно, так что уже и не правда.
    • 0
      Но Вы же прекрасно понимаете, что таких PHP разработчиков как Вы сравнительно маленький процент, в отношении тех кто дальше PHP никуда не смотрел. Как показывает практика, люди, нашедшие в себе силы, изучив любой другой язык, на PHP назад почти не возвращаются. Отсюда риторический вопрос — «Почему!?».
      Изучение новых технологий, платформ, языков всегда дает плюс, хотя бы с точки зрения знаний альтернативных решений той или иной задачи.
      P.S. сам начинал писать на PHP. Вовремя перешел на Java, последние пол года очень зацепила Scala. Ни один день в своей жизни не жалел, что инвестировал свое время в изучение новых языков.
      • 0
        Три-четыре последние года следую схеме «каждый год изучить новый ЯП». Писал и на Java, и понравилcя Scala, но реально пригодилися только узкоспециализированный R.
        Как по мне, так специализацию надо строить от области применения знаний, а не стека технологий. Вэб сейчас ограничен php/python/js/ror.
        • 0
          Полностью с Вами согласен. Когда люди не понимают, что для решения какой-либо задачи проще что-то освоить и сделать правильно — городят костыли, а потом еще и удивляются что их (и попутно их технологию) критикуют.
      • +5
        Перешёл с Java на PHP для веб, ни разу не жалел :)
        • 0
          Распространённая история.
        • 0
          Не нужно выдавать исключение из правил за повсеместное явление )
          Плюс ко всему, Вы видимо хорошо понимаете Ваши задачи и для чего конкретно Вам нужен PHP. А не просто потому-что «мне на форуме подсказали что PHP рулит и теперь буду со всеми спорить и говорить что он самый хороший, хотя даже не знаю с чем сравнить» (с)
          • 0
            Не, ну конечно это не совсем типично :)
          • 0
            Как раз на форумах скажут совершенно обратное, причём не важно какая задача.
        • 0
          Александр что с подвигло на переход?
          • +5
            1. Относительно сложный и не быстрый билд и деплой.
            2. Spring и тяга всей команды делать в приложении столько же слоёв, сколько там… а лучше ещё больше. Wicket был получше, но ынтырпрайзить от этого не перестали.
            3. Дебаг Hibernate, нахождение бага в нём и попытка его поправить.
            4. Конфиги в XML адовой вложенности.
            5. «Отличное» отношение к вопросам на всех форумах кроме доброго лося.
            6.…
            • 0
              спасибо.
              Ну сообщество php должно только порадоваться этому :)
      • +1
        Ну, это у кого как путь лег.

        Я начинал с Visual Basic + ASP, потом микроконтроллеры (хотя это не очень честно, там был «визуальный» язык программирования).
        Потом c++. А потом PHP. Хочу уточнить, что это мой путь только с коммерческой точки зрения. Я получал за это деньги. И остался на PHP.
        Так получилось, что я лучше всего знаю как готовить именно его.

        Так что я из тех, кто ушел в PHP. Да, много знакомых уходит, изучив новый ЯП. А потом пишут о проблемах с версиями в питоне, отсутствием окружения для явы на продашене, криворуких писателей библиотек для C++ и т.д.

        Учить язык, не обязательно. Нужно просто всегда учиться. Узнавать что-то новое.
        Каждый делает как может. Кто-то делает интерпретатор brainfuck на php.
        Мне проще столкнуться с задачей и решить её новыми инструментами или почитать умных людей.
        Нужно просто инвестировать своё время, как вы правильно выразились. А уж в новые языки, чтение Робина Мартина, или интерпретаторы, это кому что.
      • 0
        По всей видимости ваша «практика» касается в основном студентов, которые 2 месяца пописали на php, а потом решили, что php это не солидно, когда остальные пишут на крутых JS/Ruby/Scala.
        Изучение JS не заставило меня переписать всё на Node.js. Изучение питона с его костылями вроде GIL и подчеркиваний для приватных свойств было увлекательным, но не более того. Примерно то же самое можно и про Java и Go сказать. Нормальные инструменты для своих задач, но отнюдь не повод отказываться от php, тем более имея большой опыт его готовки и зная большинство его подводных камней и ограничений.
      • 0
        Как показывает практика, люди, нашедшие в себе силы, изучив любой другой язык, на PHP назад почти не возвращаются. Отсюда риторический вопрос — «Почему!?».

        Возможно потому, что как здесь уже говорили — php хорош как язык для начинающих, ибо «начать делать» можно быстро. С Си, Джавой и прочими «Мощными и проверенными временем» решениями не сравниться. Мой опыт веб-программирования начался с php. Можно сказать от скуки решил сделать маленький полезный проект, взял книжку, читал её три дня, а потом начал кодить и недельки за две уже было годное под мои задачи приложение. При полном отсутствии опыта разработки под веб до того времени. Думаю мало какой ещё язык позволяет так легко начать делать что-то реальное (для себя). Потом я увлёкся вебом, пару лет писал на пхп, но познакомился с пайтон-джанго. После Joomla это было невероятно круто. А дальше началась полноценная разработка под веб, пришлось заняться фронт-эндом, а потом и нодой. В итоге сейчас мне порой любопытно чтож там твориться-то в пхп. Однако есть гораздо более интересные вещи на которые и трачу время, а к пхп вернутся нет стимула. И дело не в языке. Мы в компании используем иной стек технологий, так что мне это просто не к чему. Думаю у многих ситуация схожая. Когда пхп первый язык, то возвращается к нему поздно — т.к. ты уже не одиночка и надо оглядываться на команду.

        P.S. По теме топика — мне кажется, зачастую нападки на язык больше из-за людей, которые на нём пишут. Всё-таки я очень много встречал упоротых Пыхеров (я иначе их не назову, без обид) которые ничего кроме раздражения не вызывают. И язык на котором они пишут виноват только в том, что он в начале прост настолько, что даже упоротые быдлокодеры смогли им овладеть.
      • +1
        Кто-то писал, что перешел с PHP на Go, но после того как в PHP 7 появились новые фичи (в особенности поддержка статической типизации) вернулся обратно в PHP )
        • –1
          Вы же на основании новости о том, что кто-то упал с 10го этажа и остался жив, не сделаете вывод, что 10 этаж это вовсе не высоко и можно падать не боясь разбиться!? )
  • –3
    Почему самоущещение автора и других PHP разработчиков должно изменить мое отношение к этому языку? Каким образом использование PHP в Facebook делает его хорошим языком? Язык – это спецификация. И язык PHP – это плохой язык. Объективно плохой. И если специалист не может смирится с этим фактом, пользуйясь принципом «все равно его не брошу потому что он хороший», то тогда профессиональность такого специалиста можно поставить под сомнение.

    «На удивление хорошо знаешь информатику для PHP-разработчика»

    В чем вина человека, сказавшего это, если большинство PHP-разработчиков объективно плохо знают информатику?
    • +1
      Языки уже дано не только и не столько спецификация, а сколько конкретные реализации и сложившиеся вокруг них экосистемы.

      В чем вина человека, сказавшего это, если большинство PHP-разработчиков объективно плохо знают информатику?


      И у вас есть объективные данные, конечно же?
      • –2
        «Языки уже дано не только и не столько спецификация, а сколько конкретные реализации и сложившиеся вокруг них экосистемы.
        В более широком смысле – да, только что это меняет? По сравнению с другими языками у PHP впечатляющая реализация? Или фантастическая экосистема?

        И у вас есть объективные данные, конечно же?
        К сожалению, я не занимаюсь аналитикой в подобных вопросах, но могу попробовать порассуждать логически и объяснить, почему такое утверждение мне кажется истинным. Даже в статье есть некоторые факты, которые указывают на это: „есть несколько причин, по которым новые разработчики выбирают PHP...“

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

        Так что это тоже самое, что „средняя женщина управляет автомобилем хуже, чем средний мужчина“ или „средний чернокожий зарабатывает меньше, чем средний европеоид“. Кому-то эти утверждения могут показаться не очень тактичным или приятным, но от этого они не становится менее объективными, потому что есть общая тенденция.
        • 0
          Или фантастическая экосистема?

          Не фантастическая, но очень и очень конкурентоспособная. Только связка LAMP+WordPress чего стоит.

          Именно эти начинающие, которых в PHP больше, чем в других языках

          Голословно. Как по мне, то куда больше начинающих на JavaScript. И начинающие на PHP разбираются в информатике, как правило, лучше начинающих на JavaScript по объективно-статистическим причинам: PHP в подавляющем большинстве случаев используется в связке «клиент-сервер» или в трехзвенной архитектуре, а JS — только на клиенте.

          средняя женщина управляет автомобилем хуже, чем средний мужчина


          Вроде как статистика опровергает.
          • +1
            Не фантастическая, но очень и очень конкурентоспособная. Только связка LAMP+WordPress чего стоит.
            Насколько мне известно, стало действительно приемлемо за последние годы, но это точно не козырь PHP. Как-то не вижу я толп желающих пересесть не PHP из других языков, потому что у PHP хорогая экосистема. Может не туда смотрю?

            Что такого особенного в связке LAMP+WordPress я вообще не понимаю. Объясните?

            Голословно. Как по мне, то куда больше начинающих на JavaScript.
            Может быть, но как по мне что PHP, что Javascript – два сапога пара. Извините, но в «javacsript все еще хуже» – это не сильный аргумент. Я оба языка считаю не удачными. И javascript тут оправдывает только то, что альтернативы к сожалению нет.

            Вроде как статистика опровергает.
            Как скажете.
            • 0
              > Что такого особенного в связке LAMP+WordPress я вообще не понимаю. Объясните?
              Я с нулевым опытом в веб-дизайне могу сесть и сделать за день сайт, такой же, какой профессиональная студия сделает за месяц и много денег. Мой сайт будет выглядеть профессионально, поддерживать разные броузеры и размеры экранов и т.д. Да, он будет тяжелым и тормознутым. Но во многих случаях клиент смотрит на внешний вид.
              Это такой себе Delphi для веб-разработчиков.
              • 0
                Я с нулевым опытом в веб-дизайне могу сесть и сделать за день сайт, такой же, какой профессиональная студия сделает за месяц.

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

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

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

                Не во многих случаях, а всегда.
                • 0
                  > Не сможете. Вернее сможете, но если вы вообще не будете делать свой дизайн.
                  «Свой дизайн» — не смогу. Но полезность Вордпресса как раз в том, что он избавляет от необходимости делать свой дизайн. Я смогу купить за сумму порядка $50 одну из множества гибко настраиваемых и профессионально сделанных тем, и мышкой настроить её так, как будет красиво. И заказчик будет доволен, он не увидит внешней разницы между «разработать и сверстать» и «нарисовать мышкой».

                  > Обратите внимание, вы только что стали php разработчиком. Потому, что получили деньги за работу с php.
                  > А потом люди удивляются откуда о php разработчиках предвзятое мнение.
                  Ну как сказать… вот Libre Office написан на C++. Означает ли скачивание этого пакета и создание документов в нем то, что вы стали разработчиком С++?
                  WordPress — это прикладное приложение, среда для быстрой разработки сайтов вообще без навыков веб-разработки. Конечно же, зная PHP и JavaScript, вы можете делать сайты в ней лучше, преодолевать ограничения тем и самой среды, но прелесть WordPress как раз в том, что это знание опциональное, а не обязательное. И это опять ответ на ваш вопрос:
                  > Что такого особенного в связке LAMP+WordPress
              • –2
                И это что, какая-то уникальная фишка Wordpress и того, что он написан на PHP? Может быть Wordpress действительно в этом неплох, но я могу ровно тоже самое сделать и на другой платформе.

                А PHP тут как-то вообще не причем.
  • –1
    Честое слово, детский сад какой-то. Что автор вообще хотел сказать? «Пожалуйста, не критикуйте больше мой любимый язык, потому что мне от этого грустно и обидно»?

    «После такого задаешься вопросом — а не выбрал ли я плохой язык?»

    И каков ответ? Или такой шквал критики на PHP вы оправдываете тем, что он такой популярный, а другим завидно?
    • +2
      Кстати, вполне вписывается :) 81.6% всех веб-проектов бегает под ним. Работы на менее популярных языках меньше. Обидно! :)
      • –1
        Не обидно, потому что на других языках задачи обычно гораздо интереснее, а спрос не сильно меньший (в пересчете на к-во владеющих языком).
        • +1
          Ну как это не обидно, если такая реакция? PHP-шники недопрограммисты заняли рынок и отбивают работу у крутых адептов языка X, не?
          • –2
            Да никто не отбирает работу, успокойтесь. Прямо сплю и вижу, как пхапешники вымрут, и я наконец смогу клепать блоги и интернет магазины на PyWordPress и PyJoomla. Но наступает утро, и я c унынием иду писать асихронные сервера на python, которые держат тысячи соединений на процесс и успевают еще делать machine learning. Аж зубы от злости сводит, ага.
            • +1
              Я не настаиваю, просто версия :)
  • –2
    Я думаю, стоит также добавить, что автор статьи всю свою професиональную жизнь писал только на PHP и Javascript. Выводы, что называется, делайте сами.
  • +3
    По поводу concurrency в PHP:

    'Parallel PHP' намечается в следующих релизах (возможно 8).

    Multi-threading в PHP возможно использовать уже сейчас с pthreads:
    Asynchronous Concurrency - Vanilla PHP
    <?php
    class Task {
        function Task($id, $start, $end) {
            $this->id    = $id;
            $this->start = $start;
            $this->end   = $end;
            $this->pos   = $this->start;
        }
    
        function execute() {
            if ($this->pos < $this->end) {
                return $this->pos++;
            } else return false;
        }
    }
    
    $range     = range(1, 100);
    $ranges    = array_chunk($range, 10);
    $tasks     = array();
    
    while (count($ranges)) {
        $range = array_shift($ranges);
    
        $tasks[] = new Task(
            count($tasks) + 1,
            array_shift($range), 
            array_pop($range));
    }
    
    while (count($tasks)) {
        foreach ($tasks as $id => $task) {
            if ($task->execute() === false) {
                printf("task %d complete\n", $task->id);
                unset($tasks[$id]);
            } else printf("task %d position %d\n", $task->id, $task->pos);
        }
    }
    ?>
    


    Также есть non-blocking concurrency framework Amp
  • 0
    $LovePhp
    $phpIsHTMLtemplate
    И его синтаксис, особенно создание переменных.
  • –8
    Слушайте, тенденция брать статьи, переводить, даже забыв про копирайт, и публиковать, тупо внизу написал что угодно про свою компанию — она прямо вымораживает мозг. Конечно, важно взять больную тему, такую, чтобы побольше комментов было.

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

    Помните, как в анекдоте: «Это рыба, и шерсти у нее нет. Но если бы шерсть была, то в ней жили бы блохи — и далее про блох».

    Не стыдно за (видимо, когда-то любимый) ресурс, товарищи платноаккаунтщики?

    P.S. А ссылку на оригинал и указание «перевод» — этому вас не учили, профи от мира электронных платежей («проекта который, поможет подключить вам на сайте прием платежей или массовые выплаты» — хоть Word натравите на фразу, чтобы запятые расставить)?