Пользователь
0,0
рейтинг
6 июля 2012 в 15:18

Разработка → PHP гораздо лучше, чем вы думаете из песочницы

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

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



Прежде чем начинать говорить о достижениях PHP сообщества за последнее время, давайте посмотрим на некоторые интересные цифры: PHP используется как основной язык на 77,9% среди всех сайтов, где язык платформы известен. Wordpress используется в 16,6% среди всех сайтов мира. Если вы посмотрите на топ 3 CMS, Wordpress на первом месте с 54,3%, Joomla на втором с 9,2% и Drupal на третьем с 6,8%. Топ 3 продукта, все написаны на PHP.

Это не спроста: в PHP явно что-то сделано верно, не находите?

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

PHP: Язык


В PHP 5.0 (вышедшем в 2004) ввели стабильную объектную модель… стоп стоп. Я же говорю о чем-то, что было почти 8 лет назад. Давайте-ка вернемся в настоящее.
В современном релизе PHP, 5.4, есть все плюшки, о которых вы могли бы мечтать, пользуясь современным веб языком: да, PHP поддерживает пространства имен; да, PHP поддерживает замыкания; да, PHP поддерживает типажи (traits).

На это ушло время, но PHP 5.4 включает в себя немного синтаксического сахара, который делает процесс разработки лучше: да, PHP поддерживает [] для обозначения массива; да, PHP поддерживает вызов метода на созданном объекте ((new Foo())->bar()); да, PHP поддерживает вызов элемента массива из произвольного выражения ($foo->bar()[1]).

В PHP учатся на своих ошибках: register_globals и magic_quotes убраны с потрохами.

И напоследок, в PHP встроен веб-сервер, упрощающий локальное тестирование… и он запускается в считанные миллисекунды.

Задача на будущее: как «обновить» все гайды по PHP в интернете? Какой лучший способ поддержки вебсокетов в PHP проекте?

PHP: Экосистема


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

Git

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

Composer

Два года назад мне очень хотелось избавиться от страшного PEAR-хака, который я использовал в symfony 1 для поддержки плагинов. Мне хотелось заменить его на что-то, что могло управлять зависимостями на уровне проекта, а не иметь глобальный установщик как PEAR. Управление зависимостями — не простая задача, поэтому я попытался найти наилучший алгоритм для её решения. Я просмотрел все: от Perl до Ruby, от Debian до RedHat. Ни один не был удовлетворительным — кругом самопальные решения, которые просто работают… эмпирически. А потом я наткнулся на ZYpp. Это было оно. В ZYpp используется SAT анализатор для управления зависимостями. И теперь, благодаря колоссальной работе Nils Adermann и Jordi Boggiano, у PHP есть один из лучших менеджеров зависимостей, Composer.

Да, у PHP сейчас лучший менеджер зависимостей из всех языков.

И благодаря Git, Composer и встроенному серверу PHP скачивать, устанавливать и тестировать PHP проекты еще не было так просто!

Хотите попробовать Symfony (используя PHP 5.4)?

$ composer.phar create-project symfony/framework-standard-edition
$ cd framework-standard-edition
$ ./app/console server:run


Хотите попробовать Silex?

$ composer.phar create-project fabpot/silex-skeleton
$ cd silex-skeleton
$ php -S localhost:8888 -t web/


Не слышали о Composer? А он того стоит. Загляните на Packagist — основной репозиторий для Composer: в нем уже находится более 1900 пакетов и они были установлены более миллиона раз меньше чем за 3 месяца.

Задача на будущее: внедрить Composer в следующую версию PHP?

Сотрудничество

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

phpBB, Drupal, ez Publish, Symfony, phpDoc, PHPUnit, Behat, Zikula, Propel, Doctrine, Midgard и многие другие имеют совместный код. Да, они «конкуренты», но они все поняли что интероперабельность — это круто. И Composer в этом большой помощник.

Задача на будущее: убедить еще больше проектов влиться в тренд?

Напоследок:


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

P.S. Это перевод статьи PHP is much better than you think, написанной Fabien Potencier. Честно пытался отметить топик, как перевод, но так и не нашел где.
Роман Маринченко @Inori
карма
21,2
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

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

  • +66
    Сразу вспомнилось:

    • +38
      чуть глаза не сломал от вашего комментария… пора отдыхать)))
    • +9
      Похоже, у нас с вами одинаковые браузеры и операционки.
      • 0
        У меня, похоже, другая ось. Какая у вас и почему сглаживание даёт такое размытие?
        • 0
          Дело не в оси. Если реже глаз, значит, один LCD монитор RGB, а другой BRG. Отсюда и цветной вырвиглаз.
          • 0
            Как влияет монитор на файл скриншота?
            • 0
              Субпиксельное сглаживание зависит от последовательности пикселей.
              От монитора зависит система, которая и сглаживает.
              Если увеличить скриншот, то видно, что буквы не чёрные, а красно — синие.
              Вот тут ru.wikipedia.org/wiki/ClearType сказано, почему ClearType не работает на ЭЛТ.
    • +99
      я звизда!
      • +31
        Вот и повелитель Хабра!
        • –9
          скорее очередной актер похапэ
        • +2
          Судя по профилю (пункту «О себе» и карме) — я бы даже сказал «Чёрный властелин»
          • 0
            Не, Чёрный властелин вроде еще до этого пытался захватить хабр.
            • +1
              <голосом рассказчика длинной поучительной истории>
              … но попытка была неудачной… Карму ему слили, комменты минусовали, топики критиковали… Он расстроился и ушел на имиджборды.
              </голосом рассказчика длинной поучительной истории>
    • +4
      Опасно вешать такой коммент в конце дня пятницы!
    • +1
      • 0
        Я знаю, как Deffe может исправить ситуацию.
        • 0
          Ничего лучше «пыхи» здесь быть не может? :-)
        • 0
          Капитан ПХП идет на помощь!

          itmages.ru/image/view/585443/11cf38f0

          (Сорри, не могу вставить картинку прямо в комментарий.)
      • 0
        Я тоже сначала пост по вашей ссылке прочитал, а потом здесь
    • –2
      Зачет!
      • 0
        Написал, что статья зачетная — заминусовали. Как вас понять?
  • –27
    > Да, у PHP сейчас лучший менеджер зависимостей из всех языков.
    говорить так и менеджере зависимостей, который был inspired by npm — это по крайней мере смешно

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

    > Давайте я вам рассскажу маленький секрет успеха PHP
    нет, спасибо
    • +8
      именно это же является одной из его слабых сторон

      Это преимущество, а не недостаток. То, что таким образом появляются «непрофессионалы» — проблема их самих, а не языка.
      нет, спасибо

      Аргументируете? Сами-то на чем пишете? Чем оно лучше? Оно успешнее РНР?
      На последний вопрос сам и отвечу: как видно из предоставленной в статье статистики — нет.
    • +3
      > PHP все еще является наипростейшим языком для изучения не-техническими людьми
      > и именно это же является одной из его слабых сторон

      когда простота была «плохой»?
      • –3
        Простота плоха тем, что привлекает в область много профанов, которые считают, что научились программировать после того как сделали свой первый сайт. Этим же плохи современные доступные по цене зеркалки.
        • 0
          А вам то что до них? Ну профаны и профаны, конкуренцию специалистам они не сощдают, заполняя те ниши, которые те самые специалисты считают для себя недостойными.
          • 0
            Я же не писал, что переживаю из-за них. Просто таков сам факт и это в свою очередь формирует представление о языке и навыках, необходимых для разработки того или иного продукта.

            (написано по просьбе 1999)
  • +29
    Если вы говорите, что PHP быстро развивается, то точно не видели Ruby и Python. Эти языки чуть ли не на прорядок быстрее развиваются.
    • +24
      Гиперболы в разговорах о PHP, как я вижу, не редкость, а норма.
      • +1
        Я ещё меньше года назад программировал на PHP… не успел я ещё гиперболизироваться.
      • +3
        Чтобы не быть голословным…

        > Загляните на Packagist — основной репозиторий для Composer: в нем уже находится более 1900 пакетов и они были установлены более миллиона раз меньше чем за 3 месяца.

        rubygems.org/
        725,855,681 downloads
        of 41,114 gems cut since July 2009

        Ещё стоит учитывать, что Ruby разработчиков меньше, чем PHP…
        • +10
          маленькая особенность: since July 2009

          3 месяца vs 3 года
          • +2
            Надеюсь, что зависимость не линейная от времени. Composer понравился :)
        • +2
          Я не совсем понял, вы сравнили количество скачанных ruby пакетов с количеством добавленных php пакетов?
          • 0
            725 млн. вс 1 млн
            41114 вс 1900
            3 года вс 3 месяца
            • –2
              Так и не понял, что вы хотели сказать этими цифрами. Что за 3 года ruby пакетов добавили больше, чем php за 3 месяца?

              Судя по твитам Фабьена, следующая его статья будет о том, чем, собственно, composer лучше bundler'a ;)
              • +1
                Что сравнивали не количество закачек гемов с количеством пакетов композера.
              • 0
                Бандлер работает. Чем composer может быть лучше вещи, которая просто работает?
                • +1
                  Тем, что он работает лучше? :)
        • +15
          Одна тонкость — для руби это официальный и едва ли не единственный источник?
          Для PHP же — это одна из множества альтернатив, о которой ещё далеко не все знают, поскольку неофициальная.
          Сравнение некорректно.
          • +6
            Это не тонкость, а сила языка. Нормальные программисы просто так делятся нормальным кодом.
            А в PHP-мире каждый второй сидит со своей CMS или велосипедом, боится показывать… иногда правда показывает и просит не малую цену.
            • 0
              С другой стороны как-то нет на слуху CMS на языках отличных от PHP. Фреймворки есть, CMS нет.
              • –1
                Те, кому нужны были CMS на Ruby, знают хотя бы парочку. Причем больная часть CMS — это надстройка над ROR.
                • 0
                  Обычно людям нужна (если формализировать их требования) просто CMS, может несколько кастомных модулей к ней. Почему-то выбирают CMS на PHP и заказчики, и исполнители. Сам не знаю почему выбираю :) Может мало документации?
                  • 0
                    В 2000-2005 году рынок был переполнен дешевыми китайскими велосипедами с кучей перделок и все их покупали. Сейчас не один нормальный человек за такую кучу стали не сядет.

                    Надеюсь и web-программисты образумятся.
                    • 0
                      Лучше плохо ехать, чем хорошо идти. Дарёному (почти) коню в зубы не смотрят. И т. п. Нормальных людей больше интересует соотношение цена/качество, а не качество само по себе.
                      • 0
                        > Лучше плохо ехать, чем хорошо идти. Дарёному (почти) коню в зубы не смотрят.
                        Вообще не понял, о чем вы…

                        > Нормальных людей больше интересует соотношение цена/качество
                        У нас множество людей интересует только халява =)
                        • 0
                          Что-то мне подсказывает, что китайские велосипеды дешевле своих «оригиналов» были. Причём в цену оригиналов была и заложен т. н. интеллектуальная собственность и прочий НИОКР, на который китайцы не тратились.

                          Я это заметил и потому больше «финансовую подушку» не создаю, иначе встречу интересную задачу и буду приплачивать за возможность её решить :)
                          • 0
                            Ещё китайцы не тратились на прочность, плевали на материал (сталь вместо алюминия)… в общем все самое дешевое.

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

                        И вдвойне хорошо, когда сайт сам в себе сочетает все эти плюшки.
                        • 0
                          Люди выставляют «ТЗ», я уточняю неясные моменты и предлагаю ценник и сроки. За интересные задачи — скидка. Что они считают за качество мне не интересно, вся инфа (плюс-минус лапоть) у них есть.
                          • 0
                            Да ну глупость говорят и те, и другие. Все пускаются в обсуждение каких-то дебрей, которые не имеют отношения к PHP вообще никакого. Ни к PHP как языку, ни к PHP как к платформе. А так хотелось конструктивного общения.
                            • –1
                              Я предлагаю на выбор сайт на симфони и на рельсах, на рельсах в 1,5 раза дольше и в 1,5 раза дешевле. Никто не выбрал на рельсах!
                              • 0
                                «У меня есть негритянка и бурятка… негритянка 5000, а бурятка 3000… негритянка — просто огонь, но ее придется 8 часов подождать, а бурятка вот она». Уж простите мне что приходится общаться понятными для всех категориями.
                                • 0
                                  Просто «бурятку» нужно дольше заводить до состояния «огня». Но это приятно, вот и скидка :)
                                  • 0
                                    Тьфу, негритянку.
                                  • 0
                                    Ну нет, оплата у нас по часам )))
                                    • 0
                                      Час работы с положительными эмоциями стоит много дешевле чем с отрицательными. За костыль я беру больше денег чем за возможность покрыть тестами, отрефакторить и нормально внедрить фичу.
                                      • 0
                                        А я думаю о заказчике. О том, как он будет зарабатывать деньги не без помощи сайта. Он же не ради «потусить» пришел…
                              • +1
                                На рельсах в 2-3 раза быстрее получается, если сравнивать ROR и Symfony.
                                • 0
                                  Быстрее что?
                                  • +1
                                    Разработка.
                                    • 0
                                      Блин… ну почему все делают только тесты производительности выполнения компом фреймворков? Почему никто не сделает тесты производительности команд, разрабатывающих сайты на этих фреймах?
                                      • 0
                                        Я делаю. В среднем на рельсах в 1,5 раза дольше чем на симфони. Слышал и противоположные мнения.

                                        Производительность команды субъективна.
                                    • 0
                                      У одних быстрее на RoR, у других — на Django. Почему все сравнивают все только с PHP?
                                      • +9
                                        Ни что не объединяет Ruby и Python разработчика так, как затролить PHP =)
                                        • 0
                                          Это точно.
                                          • 0
                                            Вообще неправда. Случалось мне встречать такие сайты, к которым и хотелось бы придраться, да не получится. Все стройно и красиво. Да, они на PHP, но все очень прозрачно и легко доделывать. Прям низкий поклон их создателям!
                                • 0
                                  У вас быстрее, у меня медленнее. На рельсах у меня быстро прототипы получаются, решения в лоб и т. п. Когда начинаются нестандартные сценарии, то предпочитаю переходить на симфони.
                                  • 0
                                    Вот!!! Нестандартное — для RoR равносильно экзекуции… А что касается меня, я предпочитаю облегчать бекенд и больше нагружать фронтенд. Для меня RESTful — манна небесная (ух, не надо мне писать про индексацию, я знаю о ней все). Так что, мне, по большому счету, вообще параллельно, на чем все это писать. Лишь бы не на батниках.
                                    • –1
                                      > Когда начинаются нестандартные сценарии, то предпочитаю переходить на симфони.
                                      Пример, пример пишите. Никогда у меня такого не было, все гладко списывается.
                                      • 0
                                        Может у вас более глубокие знания Ruby и/или RoR чем у меня. А может у меня более глубокие symfony2. И уж точно production окружение для php на голом debian/ubuntu я быстрее разверну раз в 100 чем рельсовое, лезть в ману или гуглить не потребуется.
                                        • –1
                                          Есть такие решения как capistrano и подобные. На голом сервере все само разворачивается одной командой.

                                          Руками приложение я разворачивают 5-10 минут… и то большая часть времени качаются пакеты и гемы.
                                          • 0
                                            Замечательно, что есть холивары. Вот был бы PHP полным бесповоротным отстоем — ну зашли бы мы, поплевались бы и вышли. Как в топике про Михалкова… скучно. А так — тренируем мозги, спорим.
                                          • 0
                                            capistrano я пользуюсь чтобы разворачивать php приложения :)
                                            • 0
                                              Кажется мы уже где-то общались…
                                              • +1
                                                Конечно, я ни одной такой темы не пропускаю :)
                                        • 0
                                          Смотрите, ставите…
                                          — nginx
                                          — postgres
                                          — rvm

                                          Дальше создать пользователя в базе, подправить конфиг. Качаете гемы и запускаешь unicorn… все…
                                          • 0
                                            Это я умею (только мускул предпочитаю, вроде же в рельсах есть DBAL), правда не нравится что при установке rvm приходится осуществлять лишние разумные действия — не заскриптуешь.

                                            А кроме единорога есть ещё 100500 способов запустить рельсы. Мне почему-то пассажир ближе, а там тоже заморочки… Причём вроде есть deb пакет, но он совместим только с дебиан, а под убунтой не разрезолвить. И вообще само «качаете гемы» предполагает большее взаимодействие с сервером чем закачка файлов по scp.
                                            • 0
                                              > И вообще само «качаете гемы» предполагает большее взаимодействие с сервером чем закачка файлов по scp.
                                              bundle install
                                              


                                              > Мне почему-то пассажир ближе, а там тоже заморочки…
                                              Если использовать passenger, то ограничиваете себя одной версией Ruby.
                                              • 0
                                                Именно, доступ к серверу к серверу на исполнение нужен. Можно, наверное, обойтись обойтись копированием файлов по всей ФС, о как-тов туториалах такой путь не освещается и не освяается.
                                    • 0
                                      Я предпочитаю ровно наоборот. Максимум нагрузки на бэкенд. И да, через RESTful. :)
                                      • 0
                                        Как же у вас это выходит? ))))
                                        • 0
                                          PUT /hubs/123/posts/15678/comments/56689['carma' => '+1']
                                          • 0
                                            Вообще лучше сделать просто…
                                            PUT /comments/56689['carma' => '+1']

                                            Иначе Rails сделает 3 запроса вместо одного.
                                            • 0
                                              Путь обеспечивает выбор нужного представления для редиректа.
                                              • 0
                                                Обычно такие запросы посылаются асинхронно… тут это не нужно, надуманно.
                                                • 0
                                                  Так они и посылаются асинхронно. Просто в разных ситуациях разное представление.
                                                  • 0
                                                    Не понимаю о каком вы представлении. Ответ должен быть в виде JSON с кодом выполнения (успешно или нет) и вспомогательной информацией типа нового значения кармы.
                                                    • 0
                                                      Ответ может быть в любом виде. Технология AJAX подразумевает, что ответ в XML виде. Если вы называете «аяксом» технологию возвращающую не XML, то это ваши трудности. 'X' в 'AJAX' означает именно XML, а не JSON или HTML.
                                                      • 0
                                                        AJAX уже давно не подразумевает XML. Да, изначально подразумевал. Сейчас — это общее обозначение таких вызовов, и пофиг, что там назад возвращается.
                                    • 0
                                      Простите, а что такого нестандартного на RoR равно экзекуции, а на Symfony/Yii/etc — нормально?
                                      • 0
                                        Скорее самого языка касается, а не фреймворков. Проблемы составляет реализация бизнес-логики сложнее чем CRUD. Мне (почти) очевидна её реализация на PHP или C, а на Ruby я постоянно удивляюсь, если получается нагуглить решение.
                                        • 0
                                          Возможно вы плохо знакомы с языком? Метапрограммирование довольно хитрая вещь.
                                          • 0
                                            Я этого не отрицаю. Книги по метапрограммированию читал, но счёл, что большей частью оно схоже использованию отражений в PHP, то есть годится для библиотек или фреймворков с тщательно и подробно документируемым поведением. Я избегаю «магии» в коде.
                                            • 0
                                              В Ruby магия сплош и рядом. И при длительном изучении все получается очень просто. Такое поведение заложено в философии…

                                              Язык следует принципу «наименьшей неожиданности»: программа должна вести себя так, как ожидает программист. Однако в контексте Ruby это означает наименьшее удивление не при знакомстве с языком, а при его основательном изучении.
                                              • 0
                                                Я сомневаюсь, что любой программист на Ruby сможет понять мой код не изучая код моих переопределений операций типа сравнения. Могу гарантировать что он будет удивлён сначала неожиданным поведением, потом тем что я поменял местами операции равенства и неравенства…
                                        • +1
                                          Вы скорее всего гораздо лучше знаете PHP, только и всего. Github на рельсах написан, а логика там явно за рамками CRUD. Да и Ruby позволяет такое, чего я на PHP даже не представляю (это уже со своей колокольни) :-)
                                          • 0
                                            Приведите пример того, что вы представляете на Ruby, ни не представляете на PHP?
                                            • 0
                                              Большая часть метапрограммирования, блоки, все, благодаря чему можно писать лаконичный и красивый код. попробуйте на php написать гем (ну ладно, PEAR модуль или что там сейчас в моде), который будет предоставлять такой синтаксис:
                                              every 3.hours { awesome 'task', option: 'value' }
                                              
                                              • 0
                                                Задача «предоставлять такой синтаксис» заведомо не корректна. Сформулируйте какую функциональность этот синтаксис предоставляет и как часто она встречается в проектах, написанных с нуля.
                                                • 0
                                                  Функциональность? Писать лаконичный и понятный код, это для многих уже достаточный аргумент. Встречается во всех хороших проектах :-) Если знакомы с рельсами, должны были увидеть что различные DSL распространены довольно широко. Да, все это можно написать и на php, но будет гораздо уродливее (даже Yii сравнить с RoR, видно что ребята старались соответствовать, но сам язык подвел).
                                          • 0
                                            Я так подозреваю, что гитхаб всё же основан на какой-то СУБД и/или плоском хранилище. Какие операции доступа к внешнему сервису позволяет руби и не позволяет пэхэпэ?
                  • +2
                    Обычно людям нужно решить опеределенную задачу. И они обращаются к специалистам. А специалистам задачу решать не нужно. Специалистам нужно зарабатывать как можно больше денег, тратя на это как можно меньше времени. Отсюда и CMS. Которые, как известно, пишут только на PHP. :)
                    • 0
                      Я предпочитаю решать задачу заказчика наиболее эффективным из известных мне способов. Я считаю деньги заказчика, чтоб за как можно меньшее число часов ему мне пришлось платить. Если задача интересная, то ещё и скидку делаю.
                      • 0
                        А говорите ли вы себе «СТОП», если понимаете, что возможностей CMS для решения задачи явно недостаточно?
                        • 0
                          Даже немного раньше :) Мне интересней разрабатывать под фреймворками или даже с нуля.
                        • +1
                          Часто бывает такое, что у CMS куча возможностей, но ни одна из них не подходит для решения поставленной перед тобой задачи. И понеслась генерация говнокода. Лично я за использование фреймворков и полное уничтожение CMS как класса.
                          • +1
                            По личному опыту CMS (вкупе с популярными модулями/плагинами/...) решают задачи процентов на 90.
                            • 0
                              Господи-боже… какие же это задачи?
                              • 0
                                Управление контентом, как ни странно :)
                                • +1
                                  Ясно… тогда ТЗ должно звучать так: создать сайт, который бы позволял управлять контентом сайта для компании «Водка-Селедка Консалт». Да? Ведь задачи-то глубже. Нет?
                                  • 0
                                    Глубже конечно. Но беглое знакомство даже с малознакомой CMS как правило показывают, что модули уже есть.
                                    • 0
                                      К сожалению, это только если бегло с ними знакомиться. Если знакомиться подробно, то грузчики покраснеют, если я выскажу свое мнение.
                                      • 0
                                        Субъективно быстрее откастомить.
                                        • 0
                                          Субъективно? У меня, иной раз, дефицит матерных слов случается, когда открываю откастомленное такое… произведение. И это не смешно, между прочим. Это грустно. Благодаря таким вот товарищам, заказчики ненавидят всех сайтоделов как класс. Они думают, что задача сайтодела в том, чтобы срубить побольше бабла и создать побольше проблем.
                                          • 0
                                            Мои заказчики ни разу за 10+ лет моего программирования на PHP не высказывали недовольства моим кодом.
                  • 0
                    На всякий случай, чтобы вы случайно не приняли меня за злобного тролля… Я каждую неделю трачу значительное количество своего рабочего времени на сопровождение корпоративного сайта. Так получилось, что сайт сделан на CMS (Bitrix). И вот честно, че-то мне не кажется, что CMS — это именно то, что нужно людям. Bitrix помог исполнителям заказа быстро срубить хорошие деньги, да. Но тем, кто сейчас занимается поддержкой этого супа с топором — поверьте, CMS нифига не кажется воплощением наших пожеланий.
                    • 0
                      Значит вы (сайт я как понял ваш?) не смогли сформулировать свои требования. Я, как исполнитель, в случаях когда «ТЗ» заказчика допускает двоякое трактование всегда уточняю все нюансы. В частности интересует заказчика ли заказчика стоимость поддержки. Верите — нет, но мне зачастую проще и экономически выгоднее накидать костылей на CMS, я уточняю у заказчика и если его это устраивает делаю ему скидку.
                      • 0
                        я уточняю у заказчика и если его это устраивает делаю ему скидку
                        Пожалуйста, попробуйте у меня уточнить это…

                        Я недавно оказался в славном городе Подольске. Первый вопрос, который мне задала девушка, был «на какой ЦЭМЭЭСКЕ работаешь?» Прямо как в СИЗО (не дай бог) побывать…
                        • 0
                          Встречный вопрос — вас интересует качество или скорость?
                          • +1
                            Я правильно понимаю, что вы лично только что косвенно подтвердили, что CMS — средство для быстрого создания некачественных сайтов? :)
                            • 0
                              Браво!
                            • 0
                              Нет. CMS средтсво создания сайтов близких к оптимому качество/себестоимость.
                      • 0
                        Нет, я лично писал ТЗ, и все важные моменты там были оговорены. Но у меня не было полного контроля над процессом принятия решения «быть, или не быть». В результате, ТЗ реализовано где-то на 60% (формально — т.е., 60% оговоренного функционала как-бы доступны, но логикой в способе доступа к ним даже не пахнет).

                        Сайт не мой — я всего-лишь сотрудник близкого ИТ-партнера крупной компании.
      • +18
        Ребят, неужели вас так легко затроллить? :)

        Понятно что Fabien в некоторых моментах приукрасил, просто чтобы привлечь внимание (что, кстати, явно удалось :D). А внимание он (ну и я, как переводчик) хотел привлечь к тому что PHP — уже давно не то, что вы пробовали в школе в 2005 году.

        Теперь это полноценный язык, который очень быстро развивается и с очень активным коммюнити. И прежде чем писать очередной пост ненависти в сторону PHP — посмотрите что нового произошло. Вполне может быть что вам даже понравится.
        • +2
          Я знаю, сам пишу движок под PHP 5.4, и будьте уверенны, в курсе, как он развивается.

          Просто это мой субъективный взгляд со стороны на статьи об PHP. Одни хотят унизить PHP посильнее, а вторые вознести к небесам. Мне нравится язык, но объективность точки зрения в статьях часто страдает.
          • 0
            Действие рождает противодействие. Если не возносить к небесам, то унизят и общая картина объективна не будет. А так минус на плюс даёт ноль и общую картину можно считать объективной. :)
            • +2
              «средняя температура по больнице — комнатная».
          • 0
            Какой смысл в движке конкретно под PHP 5.4. Поясните, пожалуйста.
            • 0
              Движок пишется не под PHP 5.4, а с его использованием. То есть с использованием тех особенностей, которых не было в предыдущих версиях. Не совсем корректно выразился изначально.

              Например, поведение $this в замыканиях, вызовы типа

              echo (new Class())->{'some crazy function with spaces'}($value)[0][1];
              

              И тому подобное.
              Просто такие конструкции в определённых ситуациях сильно пригождаются, позволяют писать более компактный и быстрый код. А ещё чаще это просто удобно.
            • 0
              За одну возможность писать [...] вместто array(...) я был готов продать душу дьяволу, но обошлось без этого. Жду предложения по типизации выражений и…
        • 0
          Я чуть меньше года назад ушел с PHP, но слежу за всеми новостями из этого, копаюсь в новых фреймворкам. Иногда просят что-то подправить на PHP-сайтах.
      • +2
        Вы не правы. О быстром развитии — это вовсе не гипербола. Гиперболы в разговорах о PHP чаще всего только в разговорах о недостатках этого языка. Мало кто знает о его реальных возможностях. Чаще всего люди под влиянием всех этих «критиков» уходят из PHP раньше, чем успевают изучить его, а потом рассказывают о преимуществах других языков и недостатках PHP.
    • 0
      Ага, развиваются: python3wos.appspot.com/ :)
      • 0
        Изменения в PHP пока что по большому счёту были обратно-совместимыми. Разве что выпиливание отдельных элементов типа register_globals.

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

        Возможно, разработчики PHP просто поступают осторожнее, внося изменения аккуратно.
        • 0
          Экзистенциализм же
        • +1
          Ну я как бы и не утверждал обратного.

          Это просто ответ на комментарии «PHP недостаточно быстро развивается» и «другие языки развиваются быстрее».

          Есть разница между развитием и переделыванием. Python как раз переделали — получили 2 активно используемые, но практически несовместимые версии и сообщество, которое вот уже 4 года не могут заставить перейти на новую ветку.
        • 0
          У меня огромный проект перешел с 5.2 на 5.3 вообще без никаких проблем.

          Да, с переходом с 4 на 5 версию были бы проблемы, но время 4 ветки ушло еще в 2005 году, сегодня наверняка прощелучше переписать приложение, будет и быстрее и более поддерживаемее.
    • 0
      Вспоминается притча о двух музыкантах. Один музыкант перебирал струны, брал аккорды, а другой, постарше, дергал за всего одну струну и брал только один аккорд. Мораль такова: первый только ищет, а второй уже нашел.
    • 0
      Я бы сюда ещё C# приплел, угнаться за ним многим сложно.
  • +7
    Главная задача на близкое будущее — чтобы поддержка 5.4 появилась в услугах виртуального хостинга, а не только при ручной настройке сервера. Многие рядовые пользователи пользуются именно такой услугой, а там только 5.3, да и то не так давно появился.
    • +23
      А Руби-то с Питоном на виртуальных хостингах завались, конечно.
      • +1
        Есть не мало решений типа heroku.com, есть дешевле.
      • +3
        Про Руби не знаю, но Питона, вообще-то, завались.
        • 0
          Шо ви говорите?
          Вот я прям щас попытался найти хостинг с поддержкой Python 3.2 и не нашел ничего на первой странице выдачи + рекламе. (Если точнее, ни на одном хостинге «с поддержкой Python» я не нашел указания версии совсем.)
          • +4
            обычно у заказчика требующего python/ruby найдётся 10-20уе/мес на нормальный VPS…
            хотя если вы намекаете, что ниша РНР — малонагруженны сайты на 1 долларовых недохостингах, тогда вопросов не имею)

            ну и про «хостинг» (хостинги в том виде, в котором они есть в РНР, малопопулярны в других языка) с py3.2 — docs.webfaction.com/software/python.html
            • +3
              Зато хостинги в таком виде популярны у заказчиков, не имеющих в штате грамотных сисадминов. Установить приложение по ftp может чуть ли не секретарь.
          • +3
            А что, много проектов есть на Python 3.2?
            • +2
              Думаю, примерно как на PHP 5.4
              • +1
                С питоном немного другая история. Насколько я знаю, сообщество до сих пор саботирует переход на python 3.x, т.к. обратной совместимости нет, а пользы от него мало. Полезные нововведения дублируются в ветке 2.x. Главный фреймворк — Django — только еще анонсирует экспериментальную поддержку Python 3.3. Какой смысл держать на хостинге Python 3? Для крутых программистов, которые хотят экспериментировать? Так вирутальный хостинг им не подходит по многим другим причинам.
                • 0
                  Я как бы в курсе :)
                  Ветка началась с жалобы на то, что развитие PHP задерживает отсутствие 5.4 на виртуальных хостингах.
                  Ну так вот, с актуальными версиями Питона и Руби (да и вообще с хостингом Питона и Руби) всё куда как печальнее. А про node.js я вообще молчу.
                  • +1
                    Всё так, но актуальная версия Python — 2.7.3.
                    • –5
                      А PHP — 5.0 ;)
                      • 0
                        Я понимаю, что вы шутите, но нас читают дети.
                        Для них я на всякий случай напишу это:
                        PHP 5 was released in July 2004.
                        Python 2.7.3 — 11 April 2012.
                        • –1
                          Я не понял смысла вашего ответа.
                          «Актуальная» версия PHP — это 5.2.17, выпущенная 6.01.2011
                          Именно оно и стоит на большинстве хостингов, потому что ветки 5.0-5.2 практически не отлисаются в плане обратной совместимости.
                          5.3 и 5.4 — совсем другая песня. Не того, конечно, масштаба, что Python 3.x или Ruby 1.9, но что-то рядом. Его пока ставят неохотно — оно и понятно.

                          Так что ситуация, в общем-то, очень похожая у PHP и у Python/Ruby
                          • 0
                            Да, люди часто друг друга не понимают. Есть такая проблема.
          • 0
            Ну вот у меня 3.1 есть (и в тарифах написано). Нужен 3.2? Не проблема — никто не спрашивал. Может на следующей неделе и сделаю. diphost.ru
            Вообще странно про «ни на одном». В РФ практически три хостинга когда-либо позиционировавшие себя как хостинги с Python — netangels, мы и каким-то боком jino.
            • 0
              www.google.com/search?q=python+хостинг
              Вижу только Джино с Питоном 2.7
              • 0
                По первой же ссылке есть целый список. ХЗ почему гугль такое буквосочетание считает нерелевантным для нас. Мы вообще были первыми кто здесь mod_wsgi в традицию ввёл, весь хабр в своё время замусорили этим.
            • +1
              Было бы круто там еще RoR… Через passenger ( видимо 3.2 ) или Unicorn…
              Эх, а то в рунете пока кроме locum толком не податься.
              • +1
                Неясна ситуация со стабильностью руби 1.9.3. Судя по списку рассылки freebsd что-то там провалилось с портированием. Самим кишка тонка. Также не ясно кто будет и как поддерживать пользователей. RoR — это как и Java совершенно отдельная религия. Мы сами программисты, мы можем и Python посмотреть, и php, и Си. Но RoR это идеология и там уже начинается. Вопрос — сможем ли мы обеспечить поддержку пользователей на хотя бы удовлетворительном уровне?
                • +1
                  Ну если FreeBSD и проблемы с портами то действительно сложно.
                  Ну и без Rails девелопера да, может быть сложновато учитывать нюансы.

                  Но ниша открыта, реализуется это либо через mod_rails(passenger) к Apache/Nginx, либо через reverse proxy к unicorn.
                  • 0
                    1. freebsd хрен с ним. там была проблема что не все порты зависимые пересобрались с 1.9.3. это в контексте обсуждения не существенно
                    2. а вот девелопер — это да. представьте его ФЗП и какая наценка должны быть только чтобы его существование окупить.
                    3. мы уже проходили с wsgi это. ниша открыта, мы в неё первыми удачно вломились вплоть до хостинга clck.ru и прочих бобуковских проектов и это… 5% наших клиентов. такой расклад делает неокупаемым (2)
                    4. ну я не первый день замужем :) естественно я отлично знаю как это делается. на хостинге даже сделано для ruby 1.8.6, но введено в тарифы и возможности хостинга, используется только для внутренних проектов.
                    • +2
                      По поводу второго пункта — вполне может быть, раз вы сами знаете что такое passenger и unicorn, то вам понадобятся просто консультации, а не человек в штате.
                      Или, например, просто открытость к тикетам в поддержку со стороны Rails проектов.

                      По поводу «ниши» — это какая-то история с положительной/отрицательной обратной связью. Нету shared Rails хостинга — никто не берется делать сайты в этой нише на Rails, никто не берется — нету хостинга. Это скорее стратегический проект, который бы помог бы выделится на фоне конкурентов. Ну и совершенно не обязательно делать Rails в дешевых тарифах.

                      Но вообщем конечно да, не моя компетенция считать что Вам выгодно, а что — нет.
                    • 0
                      на хостинге даже сделано для ruby 1.8.6

                      Ruby 1.8.6 уже сильно не актуален. Уже состоялся последний релиз Ruby 1.8.7, осталось 11 месяцев, в которые при необходимости будут выпускать security-патчи и на этом всё.
                      Так что если будете делать хостинг для Ruby, делайте поддержку только 1.9.3+
            • 0
              Кстати, а почему jino каким то боком? Полноценно вроде поддерживает да и саппорт может нужную тебе версию поставить.
        • 0
          Завались то завались, но в основном через cgi работает питон, а какой нибудь wsgi это большая редкость или за такие деньги, что проще vds дешевый взять. Но к минусам я это не отношу )
      • +3
        Просто распространенность PHP на виртуальном хостинге одно из ключевых преимуществ. Легко найти хостера, легко найти CMS, легко установить и пользоваться — для многих это существенный плюс.
        • +8
          И легко найти того, кто сам всё это сделает за смешные деньги. Иногда кажется, что админы-фрилансеры ценник заряжают не по трудоемкости, а по ключевым словам в ТЗ. Увидели Django — +N%, увидели RoR — +2N%, увидели Node.js — +5N%.
          • –2
            Как Вы же сказали выше — для установки пхп-приложения достаточно знаний секретаря. Для настройки VPS под руби/питону — недостаточно.
            • +1
              Для установки на шаред хостинг. На VDS субъективно трудозатраты одного порядка. По сути нужно только «прослойку» между nginx/Apache/etc и СУБД настроить.
            • +1
              Секретари Фейсбука и Вконтакта только что не только, что посмотрели… подумали про вас очень неодобрительно…
    • +4
      Не скажу за всю Одессу © Но среди ведущих хостингов Украины php5.4 уже поддерживается вовсю. У мелких меинстрим тем более никогда не был проблемой.
      • +1
        Спрашивал у своего хостера, сказал, что PHP 5.4 пока не достаточно стабильный.
        Бред, имхо, но у меня всё равно VDS, так что неудобств особых не испытываю.
      • 0
        Ну вот на nic.ru до сих пор 5.2
        • +2
          Я вам могу найти и с php4, но nic.ru не в нашей юрисдикции. :)
        • 0
          Ну у них для каждого клиента отдельный Apache. Можно самому установить нужные модули в ручном режиме. У меня 5.4 встал без особых проблем с первого раза. Хотя да, жалко что 5.4 нельзя из панели хостинга выбрать.
    • +2
      Друг вообще откатился пол года назад на 5.2 на своём сервере из-за того, что одно проприетарное решение не работало на 5.3. Вот и не торопятся на хостингах. А то вроде бы и не виноваты, а клиент материт.
    • –1
      Не понимаю тех, для кого проблема взять под проект дешевый vds с поддержкой от хостера, если чего-то нет на шареде. Это ж какой бюджет должен быть у сайта, чтобы такое не понятнуть.
      • +1
        Не в бюджете дело, а в администрировании. На шареде почти все настройки ОС, nginx/Apache, MySQL, самого PHP вне зоны ответственности разработчика сайта. Максимум рекомендует тот или иной хостинг. А рекомендуя VDS заказчику сразу встаёт вопрос, а кто его будет настраивать и поддерживать. А поддержка от хостера уже не дешевое удовольствие.
        • 0
          Не знаю, сейчас хостеры так налегают на облака, что готовы предоставлять саппорт типовых конфигураций за весьма небольшие деньги, иногда даже бесплатно. Если в типовой конфигруации поменять версию php, сильно ситуация не поменяется.

          hostpro.ua/ru/cloud — обещают помогать чуть ли не бесплатно. Ну это первое что подвернулось под руку.
    • +1
      Любой виртуальный хостинг поддерживает PHP, а уже бонусом может идти руби и питон.
    • 0
      У нас уже недели как три есть. Особо никому не нужно.
      • 0
        Отрадно, но как по мне, то версия становится нужной когда она есть хотя бы у половины хостеров. Снижение рисков «hoster lock-in» :)
        • 0
          Это понятно. Сделают. Мы всегда задавали тон. Хотя об этом никто и не знает. К осени уже все догонят.
    • 0
      Здесь есть существенная ложка мёда (и отдушина для Ruby с Python'ом) — VPS это уже не редкость и все более менее солидные хостинги его предлагают по цене не дороже привычного виртуального. А там уже можно настроить многое, чего не будет на виртуальном и даже более того, выше уровень обеспечения безопасности, если она имеет хоть какое-то значение (для меня это уже давно насущный вопрос) — она уже не зависит от соседей по хостингу.
  • +3
    Просто, быстро, удобно. Надо будет, перейду на что-нибудь другое.
  • +4
    Быстрая эволюция языка — как раз свидетельство серьезных проблем, заложенных изначально. И куча головной боли, для разработчиков, заодно.
    • +3
      Соглашусь. Хотя, с другой стороны, в случае php эта эволюция обеспечена сменой назначения языка.
      С простого инструмента для создания динамических страничек,
      до простого средства разработки несложных сайтов,
      до средства разработки проектов средней сложности с большим порогом входа,
      потом еще несколько этапов и наконец до универсального языка разработки веб-проектов любой сложности.

      Естественно, для того чтобы шагнуть на новую ступень, нужно многое изменить. Радует, что дальше вряд ли будут сильно менять уже. Разве что, захотят идти в энтерпрайз, но думаю, не захотят.
    • +9
      Linux тоже оч шустро развивается. Что, конечно же, свидетельствует о серьезных проблемах, заложенных изначально.
    • +4
      А вот выше сказали что питон и руби развиваются быстрее :)
  • –5
    Я уже перешёл на похапэ, вот уже как 7 лет.
    • –2
      ну вот, убили мне карму :(((((((((((
  • +1
    Меня в php радует поддержка большими компаниями и появление таких замечательных утилит, как hiphop, которые позволяют получить отличную скорость и работы кода и разработки, одновременно.
    • 0
      cython, сто лет как.
      • 0
        Берем обычный код на питоне, обрабатываем этой штукой и получаем с++ код, который компилится и работает практически как нативный на с++? Я не думаю.
        • –2
          Ну, зря, думать полезно.
          • 0
            Смотря о чем
          • +1
            Читая википедию: Cython — язык программирования, упрощающий написание модулей С/С++ кода для Python.. Я не в курсе деталей, возможно там не сильно корректно написано, но судя по этому, язык все-же не совсем такой и код таки придется переделывать.
            • 0
              Родной питоновский код будет компилироваться cython'ом, за некоторыми ограничениями (которые так же есть у hiphop'a), просто, если использовать специальный диалект (тот же питон + объявления типов данных, которые будут использоваться в c'шном коде (если не указывать, то практически везде будет использоваться тип PyObject)), выгода от компиляции в нативный код будет выше.
              • 0
                У hiphop основное ограничение — не использовать eval и другой динамический код. Остальное связано, в основном, с расширениями. Потому, многие существующие движки, типа вордпресса (с дурным количеством кода) им нормально компилируются. Точнее, движки, часто, надо немного подпилить (избавиться от динамического кода), но объем работ там сравнительно небольшой.

                Кстати, почему вообще пишут на питоне, если есть cpython? Ну я не про небольшие скрипты, а про веб-проекты на джанге, например.
        • –1
          Нет.
          Берете код на питоне, профайлите его, находите узкие тяжелые вычислительные места, например, перемножения матриц.
          С помощью этой штуки переписываете конкретные тяжелые функции на С и легко интегрируете с остальным кодом на питоне.
          Профит.
          • +1
            Хм. Ну можно экстеншн написать и под php, в чем профит? Надо Сишного кодера искать, как минимум. Как максимум, на высоконагруженном сайте может не быть узкого места, а он будет тормозить потому, что будет стандартный код в интерпретаторе крутиться (контроллер, там, проверки разные, подключения библиотек и т.д.).

            Я описывал ниже пример, взял обычный сайт, где код выполняется достаточно ровно и узких мест, как таковых, нет. Просто перекомпилировал через hiphop + g++ и получил скорость отклика в 30 раз быстрее. Не думаю, что у меня получится, если я перепишу узкие места на Си. Ну разве что весь сайт в виже extension делать, но, думаю, даже в этом случае, на инициализацию уйдет много времени.
  • +38
    Лично у меня все претензии не к PHP, а к пехепешникам. Качество кода, количество мозга и так далее…
    • +4
      особенно это видно по govnokod.ru
    • –2
      Не думаю, что качество моего кода или, тем более, количество мозга у меня сильно меняется в зависимости от того на каком языке пишу, будь то PHP, Ruby, Python, Erlang или JS (языки на которых писал что-то посложнее helloworld за последние года 3). Более того, есть подозрение, что код на PHP у меня более качественный. Чисто потому что в куда большем количестве чужого кода разбирался.
      • +2
        Однако, мысль вы не поняли :-)
        • +1
          Что я не понял? У вас претензии к качеству моего кода и количеству моего мозга. :) Я считаю, что эти вещи от языка на котором я пишу никак не зависят.
    • +1
      ИМХО, в каждом языке есть и гуру, но есть и быдлокодеры, просто порог вхождения последних разный. PHP простой и даёт множество функций из коробки (сравните, например, с С++), поэтому многие новички, которые даже не знают, что есть так называемое качество кода, начинают именно с него. Глупо предъявлять претензии ко всем пхпшникам, есть множество грамотных, сам общаюсь с ними лично.
    • +5
      Есть такой момент. Но:

      1) Когда количество кодеров и сайтов на рельсах и джанго догонят пехепе, тогда вы удивитесь, как же много говнокода на любимом руби или питоне :)

      2) Так исторически сложилось, что пхп во многих случаях используется в чистом виде: когда-то фреймворков толком и не было, а сейчас пойди подбери что-то среди этого разнообразия. Зоопарк разных подходов, идей и концепций. Зато наклепать «сайтик» на PHP можно моментально, даже не зная слова «фреймворк». Отсюда обилие велосипедов и говнокода: каждый пишет в меру своей распущенности и язык этому никак не препятствует.

      Рельсы или же джанго загоняют пограммиста в относительно жёсткие рамки: простора для говнокода остаётся гораздо меньше. А без фреймворка, на чистом питоне или руби сайты писать как-то не принято.
      • 0
        Не то что не принято, а очень трудозатратно, если не CGI писать — написать страничку с «hello world» означает сначала написать сервер, обрабатывающий запросы — сокеты и т. п. А PHP в стандартном конфиге сочетает удобство простоту CGI для разработки и куда большую скорость.
        • 0
          Что такое «стандартный кофиг»? mod_php? php-fpm?

          PHP в чем-то знаетели и есть фрэймворк, если разобрать на части, то условном можно сказать, что это Perl (mod_perl) + CGI.pm + TemplateToolkit (или Mason).

          Для Ruby чтобы работать в веб-окружении есть Rack подключается одной строкой, второй строкой подключается любимый сервер thin, третьей берите в руки Erb-шашку и RUBYте всех от плеча! Проблемы нет.
      • 0
        Поэтому я и против бездумной популяризации Питона и Руби. В мире есть PHP. В него сливается большинство начинающих кодеров. А если человеку важна эстетическая составляющая, красота кода, качество библиотек — он задумается и найдет себе подходящее решение. Если нет, то останется с PHP и не будет портить жизнь другим.
        • 0
          Ещё важна инфраструктура, спрос и т. п.
  • +4
    PHP используется как основной язык на 77,9% среди всех сайтов
    windows используется на ещё большем проценте комп«ютеров, так что теперь, на basic-е программировать?

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

    Экосистема — ну, каждый кулик свое болото хвалит, я вот слыхал что на C можно написать вообще все-все, что можно написать на другом языке, куча либ на все случаи жизни, IDE такие что сами код могут писать… Мечта, а не язык.

    Ну и главное замечание к статье — чем же так PHP гораздо лучше, чем мы думаем, автор так и не обьяснил…
    • +8
      Тогда уж на C#, а не на basic. C# клёвый. Рекомендую.
    • 0
      Тем, что у многих о нём устаревшее представление, о PHP5.4 думают как о PHP3, да ещё считают, что пишут на нём только в «спагетти»-стиле. У вас лично может быть объективное и вы прекрасно знаете достоинства и недостатки как самого языка, так и экосистемы. Но многие этим похвастаться не могут, «не читал, н осуждаю» или «не знал, да забыл».
      • +1
        Что ж, не могу не согласиться, что PHP5.4 действительно сильно отличается от PHP3.

        Делает ли это его таким же заслуживающим внимания как PHP3 — сомнительно.

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

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

        По пунктам:
        Производительности perl-а php достиг с третьей версии, и фактически остановился (как и перл, но это другой разговор). Интерпретируемый язык не догонит C никогда, как кукурузник не догонит боинг, сколько реактивных двигателей на него не вешай. pecl-APC (или другие opcode кешеры) ещё помогает не сдохнуть php проектам под нагрузкой, hiphop сильно капризный и специфичный…
        Надежность php обсуждать даже не смешно. Каждый релиз сопровождается тоннами исправленных багов, читаешь relnotes и радуешься «хорошо что меня это не касается и касаться не будет». Несовместимость самых версий, проблемы компиляции модулей на новых версиях… Не будем о плохом.
        Ну и вернемся к самому языку как таковому. Честно признаюсь, не рассматривал подробно новшества php 5.4, не в курсе насколько елегантно они введены. Но учитывая, какой бардак происходит в именовании функций, в передаче параметров эти функциям, как реализованы RE и прочее… Что-то сомнительно что с версией 5.4 php заблистал утонченностью и элегантностью

        В общем, IMHO и ещё раз IMHO, PHP — это как максимум начальный этап карьеры программиста, и чем быстрее его проскочить, тем лучше. Есть куча других языков и технологий, заслуживающих внимания.
        • +1
          Скорость для php не проблема с тех пор, как появился странслятор в с++ код, который после компиляции работает на сравнимом с нативным кодом, уровне. Работает при этом эффективно и надежно (давно не слышал о каких-либо проблем с безопасностью на ФБ и ВК).
          • –3
            > Скорость для php не проблема с тех пор, как появился странслятор в с++ код

            ага. от Facebook'а. Заточенный на Facebook. Неспособный скомпилировать >>90% кода на РНР.
            • 0
              У меня проекты завелись достаточно легко на нем. Пока, правда, служебные, но с ними проблем небыло. Чуть подправить код пришлось, но почти тридцатикратное ускорение того стоит, как по мне. проблемы с основном с расширениями, но, учитывая скорость работы, большую часть из них можно заменить на php классы с аналогичной функциональностью.
              • 0
                А подскажите, тридцатикратное ускорение — оно в чем именно? В процессоре? Может, в оптимизации использования оперативы?
                • 0
                  К-во запросов в секунду. Полагаю, процессор (я в тонкосятх настройки по памяти не разбирался, там встроенный веб-сервер и как там настроить количество воркеров или что-то еще, я пока не в курсе).
                  • 0
                    У вас получилось тридцатикратное увеличение количества запросов в секунду относительно чего? Относительно PHP + APC + nginx? Или чего?
                    • 0
                      Да, был код на php, работал через php-fpm+apc и nginx, я его через hiphop собрал в виде демона и ab показал 3200 запросов против 110 (тот-же сервер, загрузка процессора в обоих случаях 100%). База не использовалась, но работала шаблонизация (шаблоны скомпилены в php код), ну и стандартный контроллер, фильтрация данных и прочее. Код реальный, брал работающий самописный проект.
            • 0
              Я все смотрел в сторону Европы и чуть севернее и ждал комментариев от вас ))) Дмитрий, мне кажется, просветленные не комментируют подобные топики, и даже не пишут
              • 0
                Действительно, если нет аргументов, лучше обсудить личность
                • 0
                  Аргументов против чего? Или в пользу чего? Дмитрий, я высоко ценю тот вклад, который вы сделали в пользу развития Эрланга в рунете. Без сарказмов.
        • 0
          С реализацией да, у PHP постоянные проблемы. Как-то рассматривают частные случаи в строго определенном контексте. Скажем сделали валидными выражения func()[0] и (new Class())->method(), но надо проверять будет ли работать (new Class())[0]->method(); и с большой вероятностью не будет, чисто по опыту — не любят разработчики PHP общих решений. Операторы типа [] -> () применяются не к выражения какого-то типа, а к строго определенным конструкциям. Собственно это скорее не операторы с операндами, а трехэлементные конструкции имеющие смысл в строго определенных контекстах, причём в разных контекстах разный смысл.

          Для меня он стал скорее заключительным этапом, полкарьеры метаний с чуть ли не с ассемблера до лиспа, а потом появилась задача сделать сайт, на Си оказалось неудобно, выбирал между Perl и PHP. Подкупила прежде всего схожесть синтаксиса, что программу на PHP я читать мог без подготовки, а на PERL нет. Для себя я могу писать на python или ruby, могу если приспичит написать на c/c++, ковырялся относительно недавно с Erlang и Scala. Но это для себя, хобби. Работа же — PHP: устойчивый спрос на рынке труда без требований типа «активный аккаунт на github». Были попытки перейти на Ruby(Rails) и Python(Django), но не смог решить организационные вопросы (проще говоря косячил) по причинами с ЯП не связанным — брался за новую работы не подчистив концы.
          • 0
            > чисто по опыту — не любят разработчики PHP общих решений.

            Они вообще боятся трогать парсер и лексер. Видно в многочисленных обсуждениях разных фич, затрагивающих эти два компонента.
            • 0
              Что-то подобное подозревал. Судя по отсутствию формального описания синтаксиса, внутри творится чёрти что.
              • +1
                Сейчас не найду сслыку на обсуждение namespace'ов, но там был ад. Один из ключевых аргументов против :: был именно «лексер (или парсер) не сможет разобраться»
                • +1
                  Они вообще хотят поменять лексер на более современный, ибо тот что сейчас не способен справится с новыми веяниями, у него нету контекста — отсюда и проблемы с тем, что некоторые вещи очень проблемно реализовать.
                  Если мне память не изменяет, то хотят на lemon parser пересесть и какая-то работа за кулисами там шла, но инфы почти нету.
                  • +1
                    В итоге получится, как с Юникодом :) «Много рутинной работы, никому неинтересно, все забили» :)
                  • 0
                    Чтоб менять на более современный нужно, как минимум, формализовать язык. Наверное. Но у ж точно PHP бы это не помешало бы, если не просто формализовать существующий синтаксис, но и упростить его.
                • +3
                  [sarcasm]В том и прелесть PHP — они там вводят всякие closure, threads, closures, а ты просто берешь — и игнорируешь их[/sarcasm]
                  • 0
                    Не игнорируешь а ждешь массового распространения на шаредах версии поддерживающей нововведения. Нэймспэйсы и анонимные функции я сейчас использую активно. Через год-два наверное нчну использовать фишки 5.4.
                    • 0
                      Я использовал «фишки» PHP 5.4 уже через, примерно, месяц после того, как вышел сам 5.4 (стоило бы сделать татуировку, наверное, об этом). Речь-то не о том совершенно. Речь о другом. PHP появился тогда, когда не было, практически, ничего. И не надо говорить про Perl. Он тогда был гораздо менее дружественным к разработчикам. И он навсегда останется в моем сердце.
                      • +1
                        Грубо говоря не знаю когда появился php, но когда мне поставили задачу создать сайт я выбирал из трех языков: C, PHP и Perl/ У PHP было только одно значимое для работодателя преимущество — прототип (как сейчас модно говорить) на нём я создал за день, На сишный мне трое суток понадилось, от перла после суток разбирательства я отказался в принципе.
  • НЛО прилетело и опубликовало эту надпись здесь
    • +6
      99% не динамические? Вы уверены?
      • +2
        Конечно. Жду статические гугл с яндексом и прочие дропбоксы с фейсбуками.
        • +5
          Статический гугл? Скачиваешь список сайтов и там уже ищешь через Ctrl+F?
          • 0
            А вместо браузера вывод на принтер.
            • 0
              Вы только что решили проблему несовместимости html кода в разных браузерах.
              • 0
                А проблема кросс-принтерности не появится?
                • –1
                  Думаю появиться :). Каждый ведь захочет сделать свой принтер особенным.
                  • +1
                    Принтер с поддержкой ECMAScript — это будет АД
                    • 0
                      Печатаешь, потом БАЦ — кликнул по листу, и из принтера новый листок полез… и так Твиттер станет основной причиной крушения человеческой цивилизации
                      • 0
                        особая серая склизкая бумага ^__^
            • 0
              Бумаги не хватит дебажить.
              • 0
                Есть рулоны по 54 метра…
                • +1
                  Кончаются раньше чем рассчитываешь даже без принтеров…
      • 0
        Я думаю имелось ввиду, что сайты вполне могут обойтись без динамики… ну про 99% конечно утрированно, но нереально огромное кол-во сайтов можно было бы сделать статикой + минимум JS скриптов…
        • 0
          Ну. Сейчас обыкновенные заказчики (сайты визитки, сайты портфолио) все хотят либо галерею, либо новости или еще что-то подобное. Крайне неудобно делать такое статикой.
        • 0
          И что в таком случае делать сайтам, которые начинают развиваться?
          В случае с CMS — просто ставится/включается соответствующий компонент, в случае со сгенерированным сайтом — создавать сайт с нуля?
          При этом учтите, в современных CMS хорошо развито кеширование, которое приближает сайты на этих CMS по производительности к сайту на статике.
          Но лично по поводу широкораспространённых бесплатных CMS спорить не готов — большинство из них мне сильно не нравятся (теоретически можно было бы сделать лучше).
          • 0
            Они тащат груз BC, по-моему. Поставь их разработчикам задачу написать такой же по функциональности движок и уверен качество кода будет куда выше. Вот только будет ли кто пользоваться этим движком с оригиналом общее имеющее только название, если заказчики сайтов уже вложили немалые деньги в создание модулей, тем и прочую кастомизацию. Скорее просто кто-нибудь форкнет текущую версию, как это было с, например OpenOffice.org, пускай и причины были другие.
          • –1
            Ставим модуль, генерируем статику по новой, в чем проблема?
            • 0
              Какую статику, если речь идёт про новые функции?
              Считаем что статика — это одна функция: контент.
              Форум на статике или рейтинг постов в блоге — уже не прокатит.
              А ведь это достаточно распространённые функции в современном вебе и список таких функций можно набросать приличный.
              Кроме того, мои заказчики хотят сами управлять контентом — генератор тоже нужно куда-то поставить и настроить. Так CMS же и выполняет эту функцию — это онлайн редактор сайта, с этим самым сайтом и связанный.

              Дело в том, что сама генерация статики, как таковая, имеет смысл для высоконагруженных проектов или кластера проектов — там это экономит деньги. А низконагруженному, где несколько тысяч посетителей в день — вообще без разницы на чём он, по цене он заказчику находится в минимуме. Зато удобство работы с ним — это важный для заказчика вопрос.
              • 0
                Ну я к тому, что если сайт в принципе можно сгенерировать статически, но его можно перегенерировать, если надо в него что-то добавить. То, что любой сайт можно сделать статикой, я не утверждаю. Хотя форум или блог, как раз, сделать не так сложно (пусть и некоторые вещи будут несколько ограничены).

                Важно понимать, что статическим должен быть не весь сайт. Админка в любом случае, будет динамическая. Разумнее и сайт делать хоть немного динамическим (на уровне include, как минимум). Но если брать полностью статически вариант блога, то схема может быть следующей:

                страница списка содержит записи на один календарный месяц. Главная страница, соотвественно, это текущий месяц. При добавлении/редактировании поста, обновляется 2 страницы: страница записей за текущий месяц и страница конкретной записи. Комментарии динамические, но внешние, например disqus или от какой-то социалки. Аналогично и виджеты с последними комментариями. Раз в месяц, придется перегенерировать все страницы, чтобы добавить новый месяц в навигацию.

                Конечно, в обычном случае, так делать нет смысла. Но если сделать, то вполне можно давать ссылку на такой блог с Хабра или откуда-то еще и блог легко вытянет хабраэффект даже на не сильно мощном хостинге. Как правило, проблемы с производительностью у блогов возникают именно в таком случае.
    • 0
      Я думаю, что различные профили пользователей и личные кабинеты есть на большем числе сайтов чем 1% — куда не ткнись всюду требуют регистрации, чтоб даже ознакомиться с контентом. В принципе не очень сложно должно быть сделать блоговый движок на статике, но к нему всё равно нужен динамический бэкенд («админка»), да и СУБД больше как-то подходит для задач типа «найти все посты с таким-то тэгом», чем рыться в HTML файлах. В итоге приходим к системе, которая, по сути, по POST запросам генерирует сначала модель в БД, а потом её представление в файле — в динамических системах это называется файловое кэширование представлений.
  • 0
    Сравнивать языки нужно только в зависимости от контекста их употребления. Для одних задач один язык больше подходит, для других другой. Сказать однозначно и без поворотно, что один язык лучше другого в любом контексте его употребления, по крайней мере глупо. У каждого языка есть изъяны, но в разных случаях эти изъяны либо влияют на корректность работы приложения и на его перформанс либо нет, но так же у каждого есть свои преимущества в той или иной задаче. И как правило на практике в сложных веб-приложения используются несколько разных языков — каждый для своей задачи. И это есть правильно.
    Лучше спорить, что в такой-то данной задаче, в таких-то условиях такой-то язык лучше. А то получается, что камаз лучше, чем порш кайен, а как на порше привезти 5 тонн кирпичей никого не волнует.
  • –4
    Я просто оставлю это здесь — php.net/manual/en/types.comparisons.php
    • –1
      «php» == TRUE
      «php» == 0
      0 != TRUE

      Крутая система типов, да.
      • –1
        Читая документацию, вы, видимо, пропустили следующее:

        «Обратите внимание, что переменная, в зависимости от ее типа в данный момент, в определённых ситуациях может иметь разные значения. Более подробную информацию смотрите в разделе Манипуляции с типами
        • 0
          Я намекаю на то, что само по себе такое поведение говорит о изначальных ошибках в проектировании системы типов и нагроможденных вокруг нее костылях для совместимости.

          А неочевидное поведение — это куча трудноотлаживаемых ошибок, говнокод и головная боль разработчиков.
          • 0
            Неочевидно оно для людей привыкших к строгим языкам. А вот если взглянуть на конструкции типа
            $var = $_GET['var'];
            if ($var) echo 'TRUE'; 
            echo $var * 2;
            

            то всё встаёт на свои места. Непустые строки считаются истинными, кроме строки '0'. При численных операциях строки кастуются к числу. Нужно учитывать, что практически все значения в скрипт поступают в текстовом виде: переменные окружения, запросы, файлы, БД — везде строки. Вывод тоже строковый.
            • –1
              Я привык считать, что такие конструкции — говнокод. Именно из-за неявного приведения.

              В питоне или в руби сравнение строки с число всегда вернет false. Ну просто потому что число и строка — разные классы объектов. И это гораздо более логично.
              А не пустая ссылка всегда истинна. Пустая — ложна.
              • +1
                Приводите типы, сравнивайте строго. Кто мешает?
                • 0
                  Никто ;) Я не пишу на ПХП, там слишком маленькие зарплаты ;)
                  • –1
                    Я бы не стал писать на ПХП даже если бы платили нормально :)
                    • 0
                      А если бы платили только за пхп?
                      • –1
                        Если бы платили только за пхп — я бы ушел в аналитики. Ну или тестировщики.
                        • 0
                          тестировать код на PHP?
                      • +1
                        Все равно. Вы бы пошли писать на КОБОЛе, если бы «только за него платили»? :) Есть пара технологий, с которым я имел несчастье иметь дело, и которыми я больше не притронусь не при каких обстоятельствах. Например MFC. От PHP у меня, правда, нету такой травмы, но язык мне очень сильно не нравится и плохо себе представляю, что может заставить меня с ним иметь дело…
                  • 0
                    Хорошим специалистам хорошо платят.
              • +1
                Всегда ли? А если операцию сравнения переопределить?

                А насчёт логично: спросите у непрограммиста: '123' равно 123 или не равно. PHP кроме всего прочего позиционируется как первый язык, на котором можно начинать писать не зная что такое тип, класс, объект, как они хранятся в памяти и т. п.
                • –2
                  Если вам дали ружье — это не означает, что тут же надо отстрелить себе ногу и размазать мозги окружающих по обоям.

                  Не надо переопределять операцию сравнения, кроме случаев когда вы пишете какой-то очень хитрый eDSL.
                  • +1
                    Просто не люблю квантор всеобщности :)
      • 0
        И слегка неожиданно:
        defined('null'); // true
        defined('NULL'); // true
        define('null', true); // notice нельзя переопределить константу
        define('NULL', true); // true
        NULL===true // false
        ('NULL')===true // false
        ('NULL')==true // true
        
        • 0
          Тут как раз все логично.
        • 0
          а вы хотите так:
          define('true', false);
          define('false', true);
          // счастливой отладки
          

          ?
      • 0
        Loose comparisons with ==
        Strict comparisons with ===
        От вашего коммента складывается впечатление что вы ниасилили перевод этих 2 строк в вашей ссылке.
        • 0
          См. мой коммент выше.
          И осильте любой другой язык с динамической типизацией кроме php и javascript.

          Наличие костылей ДАЖЕ В СИСТЕМЕ ТИПОВ — это один из признаков того, в чем автор поста пытается нас разубедить.
          • +2
            Это не костыли, это осознанно подобранные под конкретную область применения допущения. Если не понимаете ее, привыкли к другому и боитесь трудноотлаживаемых ошибок используйте жесткое сравнение, а не пытайтесь выставить это недостатком языка.
            • –2
              Это не баг, это фича, да ;)))

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

              Неявное преобразование типов с отчетливо разными интерфейсами и поведениями — это нарушение LSP и явная архитектурная ошибка. От которой теперь очень сложно избавиться не порушив совместимость.

              Почему ни в одном другом языке, кроме джаваскрипта, мне не нужно задумываться о том, какое сравнение выбирать? Оно везде тупо одно ;) И если я сравню строку (не указатель на массив как в C, конечно) с числом без явного преобразования, мне рантайм скажет, что я мудак и будет полностью прав.

              Ок, я не буду выставлять это недостатком языка. Я просто скажу, что большинство других языков имеет явное достоинство по сравнению с пхп.
              • 0
                Это просто разные типизация. Транслятор с сильной обзовётся, со слабой выберет наиболее вероятное (по мнению разработчиков) кастование. Хотите сравнить число со строкой — в любом случае правила приведения типов нужно знать.
                • –1
                  Слабая типизация — это когда типизация идет по совпадению контрактов (оно же «утиная» — если квакает как утка… и так далее). Сильная — по совпадению типов и их отношениям в иерархии.

                  И у строки и у числа отчетливо РАЗНЫЕ иерархии и РАЗНЫЕ контракты.
                  • 0
                    В языках со слабой типизацией обычно используется подход под названием «утиная типизация»
                    • 0
                      утиная типизация — это «выглядит, как утка, плавает, как утка, крякает, как утка — значит утка». Строки и числа в PHP — это не утиная типизация, а слабая динамическая типизация.
                      • 0
                        Утиная типизация один из видов слабой типизации.
                        • +1
                          Но только она не относится к этому случаю.

                          Утиная типизация — это, грубо говоря, когда объект типа A удовлетворяет контрактам объекта типа B.

                          В случае с PHP строки и числа не удовлетворяют контрактам друг друга, у тупо прозрачно приводятся к тому или иному типу, причем по весьма странным правилам.
                          • 0
                            Я и написал, что утиная типизация лишь один из видов слабой типизации. Один но далеко не единственный.
                            • 0
                              А, да, перечитал подветку. Так и есть
              • +1
                Не понял, с чего вы с PHP на JavaScript перескочили, в остальном могу лишь еще раз повторить, что причина в конкретной области применения. Если следовать вашей логике получиться шаг назад во времена Perl-a, когда у каждого программера была собственная самописная функция для распарсивания значений из POST&GET и т.п. Если вам кажется непонятным или неправильным существующее неявное преобразование или еще какие-то моменты, просто используйте явное приведение типов и т.п., не надо доказывать, что все остальные не правы. Именно эти «архитектурные ошибки» сделали PHP на порядок эффективнее и как следствие популярнее других языков в веб-разработке.
                • +1
                  Ну про эффективнее — это откровенная неправда ;)

                  А во-вторых, знаете чем кодер отличается от разработчика?
                  Кодер пишет используя один инструмент. И ассоциирует себя с ним.
                  Разработчик решает задачи. Выбирая инструмент под задачу.

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

                  Что в общем уже отчетливо характеризует пхп-комьюнити, уж простите.

                  P.S. Если следовать моей логике надо не возвращаться к перлу, а идти вперед от пхп — к рельсам или дотнету.
                  • +1
                    Я вам в карму не срал, но уверен, что если бы вы пришли в топик про Винду и начали рассказывать какая она плохая и Линукс рулит, то получили тоже самое. Аналогично с темами в хабах Python, Ruby и т.д.

                    Так работает хабр, к сожалению.
                    • 0
                      Стоп-стоп. Перечитайте заголовок. Мне заявляют, что пхп лучше, чем я о нем думаю. Т. е. аудитория статьи не пхпшники, а такие как я как раз.

                      Я захожу и кидаю всем давным давно известный аргумент. Получаю в ответ баттхерт. Это уже не хабр…
                  • 0
                    Что значит откровенная неправда? В чём вы меряете эффективность?
                    • 0
                      В временной стоимости разработки, откладки, поддержки и качестве получившегося.

                      А вы в чем меряют выше, чтобы говорить о «сделали PHP на порядок эффективнее»?
                  • 0
                    Хорошо, перечислите свои инструменты, которые вы используете для решения задач.
                    • 0
                      На данный момент — .net (c#, f#) под виндой; ruby, lisp, ANSI C — в линуксе.
            • +1
              > Это не костыли, это осознанно подобранные под конкретную область применения допущения.

              Нет, это именно костыли. === появился в РНР далеко не сразу и является именно костылем поверх убогой системы типов.
              • 0
                Изначально система типов подобрана под весьма узкую задачу, со временем язык стал популярнее и спектр задач расширился, в связи с чем были добавлены возможности явного приведения, сравнения с учетом типа и т.п. Автор статьи называет это развитием языка, вы называете костылями, от выбора терминологии язык хуже не становится.
                • 0
                  > Изначально система типов подобрана под весьма узкую задачу

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

                  В итоге получилось то, что получилось. === является банальным костылем, который в грамотно спроектированном языке (в котором действительно что-то выбирают прежде, чем реализовать) просто не появился бы.
                  • 0
                    Не понятно почему PHP постоянно пытаются записать в недостатки какие-то факты из лохматых 90х. Давайте проведем аналогию, в 2006 Джек Дорси хотел создать некую платформу, которая позволяла бы ему постоянно обмениваться с друзьями короткими сообщениями, проект планировался исключительно для внутреннего использования. Значит ли это, что Twitter говно? Я так не думаю, потому что на сегодняшний день все проблемы связанные с ограничениями изначальной идеи успешно решены. В свою очередь 100500 заранее продуманных проектов провалились не выдержав столкновения с реальностью.
                    • +1
                      > Не понятно почему PHP постоянно пытаются записать в недостатки какие-то факты из лохматых 90х.

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

                      Все остальные фантазии и непонятно к чему приплетенные аналогии — кому угодно, только не техническому ресурсу.
                      • 0
                        Костылем на технических ресурсах называют нагромождение избыточного кода, при отсутствии нормального решения. === просто еще один оператор, для тех случаев, когда стандартное решение не достаточно строго, никаких избыточных проблем он не создает.
                        • 0
                          Так же костылем называется ничем не оправданное техническое решение, принятое для якобы решения существующих проблем, но эти проблемы не решающее.
                          • +1
                            Это уже фейл какой-то, а не костыль, костыль это все же какое никакое, но решение, а не его отсутствие :)
                            Какие проблемы по вашему не решены? Если вы считаете, что PHP надо переделать по образу и подобию Perl-а или C, то это исключительно ваша проблема. Проблема заключалась в том, что возникла необходимость писать фрагменты кода со строгой типизацией, не утратив изначальной гибкости и простоты, оператор ===, вместе с прочими методами явного приведения полностью решает это проблему.
                            • +1
                              > Это уже фейл какой-то, а не костыль, костыль это все же какое никакое, но решение, а не его отсутствие

                              Именно. Костыль — это «какое-то решение».

                              > Проблема заключалась в том, что возникла необходимость писать фрагменты кода со строгой типизацией, не утратив изначальной гибкости и простоты

                              Нет. Проблема заключалась именно в том, что оператор == давал *видимость* простоты, и *видимость* правильной работы, при том, что он:
                              — создавал больше проблем, чем решал
                              — обладал (и обладает) совершенно идиотскими правилами приведения типов.

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

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

                              Если это не костыль, я не знаю, что называть костылем.

                              Сказки про «гибкость и удобство» оставьте школоте и кодерам, которые уверены, что код типа «$var = «1»; echo $var + 1;» — это хороший качественный безопасный код.
                              • 0
                                который работает так, как изначально должен был бы работать ==, который не заменяет ==, но который настоятельно рекомендуют использовать вместо ==
                                Я сломал мозг…

                                Пойду-ка я дальше изучать Go. Его в этом топике еще не «поливали».
                              • +2
                                У меня остался только один вопрос, почему вы продолжаете дискутировать о PHP, вместо того, чтобы писать скажем на Java?
                                Я могу понять смысл споров, как сделать PHP лучше, но ваши высказывания говорят о том, что вы не согласны с базовыми концепциями языка.
                                Возможность написать:
                                $str = '1';
                                return ++$str;
                                

                                одна из фич, обуславливающая популярность языка, а не его проблема. Если это проблема для вас — смените язык, он никогда не будет соответствовать вашим понятиям о прекрасном.
                                Как это часто бывает в спорах о PHP — определяйтесь, «вам шашечки или ехать».
                                • 0
                                  Главное в жизни — уверенность в том, что выбрал правильный путь
                                • –1
                                  > У меня остался только один вопрос, почему вы продолжаете дискутировать о PHP, вместо того

                                  Я же не могу высказать свое мнение по поводу языка, с которым работал почти 10 лет? Нуну

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

                                  Да, не согласен. И мое мнение достаточно объективно.

                                  > Возможность написать:
                                  > $str = '1';
                                  > return ++$str;
                                  > одна из фич, обуславливающая популярность языка, а не его проблема.

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

                                  Так вот, именно такой код ведет к горе ошибок, SQL-injections, ошибкам валидации вводимых данных и т.п. Если вы не способны этого понять и считаете, что так оно и должно быть, что вы делаете в этой профессии?

                                  > смените язык, он никогда не будет соответствовать вашим понятиям о прекрасном.

                                  При чем тут мое чувство прекрасного? Есть некоторые объективные вещи, которые нужно называть своими именами.

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

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

                                  Таблиц типа Loose comparisons with == вообще не должно существовать, потому что они бессмысленны, нелогичны и ведут к целому классу ошибок.

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

                                  • 0
                                    По вашей логике прежде чем браться за PHP стоит выпилить си и все подобные языки, вы не представляете какие там возможности, скажем при работе с указателями, для проблем с адресацией, утечками памяти и т.п.
                                    Если вы считаете, что язык вместо вас должен заботиться об инъекциях, валидации входных данных и т.п., то вопрос «что вы делаете в этой профессии?» задайте лучше себе. Никакая типизация не защитит вас от ошибок, если у вас не хватает профессионализма, ровно как широкие возможности выстрелить себе в ногу не заставят профессионала это сделать.
                                    • 0
                                      > По вашей логике прежде чем браться за PHP стоит выпилить си и все подобные языки,

                                      Нет, это не по моей логике, а по вашей буйной фантазии

                                      > вы не представляете какие там возможности, скажем при работе с указателями, для проблем с адресацией, утечками памяти и т.п.

                                      Я прекрасно представляю, какие там возможности. И люди не называют это фичами. Люди называют это проблемами и предупреждают всех об опасностях, связанных с этими проблемами и делают все возможное, чтобы этих проблем избегать — включая костыли типа auto_ptr, smart_ptr и т.п.[*]

                                      И только в РНР школота рассказывает о том, насколько РНР крут, что позволят писать адский код типа «$str = '1'; return ++$str;»

                                      В C/C++ за такой код в нормальной конторе уволят на следующий же день. За такой же код на РНР тоже.

                                      «Но ведь эта так крута и гибка!!! одинодинодин». Тьфу

                                      [*] Да, *_ptr — это костыли, чтобы скрыть многие из встроенных в язык проблем, несмотря на их — во многом — хорошую или даже отличную реализацию.
                                      • +1
                                        Возможность написать свой личный smart pointer не означает, что указатели это проблема Си, а наличие === не говорит о том, что == больше не нужен. Вы что-то слишком часто стали называть меня школотой, которую надо уволить, я приму это как признание, что аргументов у вас больше нет и дискуссия окончена.
                                        • +1
                                          Ну да, ну да. Вместо аргументов посчитать, что тебя называют школотой — это явный признак высочайшего профессионализма, да
                                        • –2
                                          Ах, и да.

                                          Сравнить этот код:
                                          > $str = '1';
                                          > return ++$str;

                                          с указателями на С и назвать это гибкой фичей языка способен только исключительно некомпетентный школяр. Гнать таких из профессии ссаными тряпками.
                      • +4
                        за все 7 лет программирования на этом языке я лишь один или два раза попадался на баги, связанные с неправильным приведением/сравнением типов.

                        Стоит ли овчинка выделки? Имхо, это не та вещь, которая мешает писать приложения. Меня лично больше бесит и раздражает порядок аргументов в разных функциях и вообще зоопарк этих самых функций, особенно для работ со строками и массивами с названиями а-ля str_replace или substr.

                        Я бы на этом больше концентрировался, а вы про лохматую типизацию, которая вообще никому не мешает и не создает проблем, либо создает, но редко.
                        • –1
                          > Стоит ли овчинка выделки? Имхо, это не та вещь, которая мешает писать приложения.

                          Стоит и мешает. Через семь лет приучаешься везде писать === «потому что».

                          > Я бы на этом больше концентрировался, а вы про лохматую типизацию,

                          Какая подветка, о том и говорю. Про остальные проблемы РНР я прекрасно знаю, и какой ад там творится, тоже
                  • +1
                    В итоге получилось то, что получилось. === является банальным костылем

                    Ну почему же, представьте теперь ситуацию что нужно получить какое-то значение (допустим из get-параметров) и прибавить к нему n-e число:

                    $var = "1";
                    echo $var + 1; //2
                    


                    Потому что «1» == 1, а если бы в языке отстутсвовало понятие неявного привдения типов, то пришлось бы вам всегда делать что-то вроде этого:

                    (int)$var + 1;
                    

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

                    Или как в Python:

                    var = "1"
                    int(var) + 1
                    


                    PS: На всякий случай хочу обратить внимание, что во времена когда только обсуждался стандарт С++11 предлагалось введение нового оператора идентичности <=>

                    concept EqualityComparable<typename T> 
                    {
                    
                       axiom Consistency(T a, T b) {
                           (a == b) <=> !(a != b);
                        }
                    }
                    

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

                    В конце концов, вы можете не пользоваться этим оператором :)