Жизнь PHP-разработчика

http://jonkuperman.com/life-of-a-php-developer/
  • Перевод
Вступление от переводчика: очень давно веду разработку на 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 — проекта который, поможет подключить вам на сайте прием платежей или массовые выплаты. Обращайтесь!
Web-payment.ru 72,87
Отраслевое финтех СМИ
Поделиться публикацией
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама
Похожие публикации
Комментарии 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 напишут он уже нафиг никому не нужен будет.
                                                                                                                      С пхп все несколько веселее, прототип — за месяц на коленке, тут главное опыт иметь и чтот-то вроде архитектуры придумать. Далее можно тупо кусками тяжелые моменты запиливать, например, демонами на с++. На больших данных и тяжелых манипуляциях с ними — с++ джаву сделает только в путь.