12 апреля в 10:34

$PHP не нужен* перевод

Хорошо известно, что PHP — это мёртвый язык программирования и его 22-летняя экосистема фактически стала бесполезна, когда появился Node и новые асинхронные фреймворки на его основе. Превосходство Node очевидно, потому что все знают, что однопоточные асинхронные программы более лучше по умолчанию. И быстрее.


«Но Саймон! Почему?!", вы, вероятно, прокричите увидев этот текст на экране. И вот почему:


Перспективы трудоустройства


PHP-разработчики не пользуются спросом. По прошествии 22 лет, все компании, использующие PHP, сразу же отказались от него, как только был выпущен Node v0.0.1, потому что этот стек разработки мгновенно стал лучшим. Кроме того, всем известно, что для успешного запуска (забудем про Slack) вам нужно создавать веб-интерфейсы на Node, а данные сохранять в MongoDB.


Иначе просто невозможно добиться успеха.


Приведем немного научных™ фактов, чтобы доказать эти утверждения:
image
$заголовок = ‘PHP-разработчики не могут найти работу чтобы содержать свои семьи’;


Экосистема языка


Экосистема, вероятно, является самым важным фактором в принятии решения не использовать язык программирования. К счастью для нас, PHP существует достаточно давно, и его экосистема полна крупных, хорошо поддерживаемых и полнофункциональных фреймворков, которые все ненавидят — это и Laravel, своего рода эквивалент Rails, или энтерпрайз решения на подобии Symfony и Zend.


В отличие от PHP, разработчикам Node не нужно беспокоиться о том, чтобы найти фреймворк, который придётся ненавидеть, потому что каждый просто пишет свой собственный. Создавая свои собственные фреймворки, разработчик может действительно выделиться на фоне конкурентов, изобретая колесо таким образом, который имеет смысл только для него самого (разработчика). Эта практика также удваивает гарантию сохранения работы, что очень важно, как показано в результатах научных™ исследований, приведенных выше. Также, это утраивает Фактор Крутости Разработчика™ (Developer Cool Factor™).


Ошеломляющее свидетельство превосходной экосистемы Node можно увидеть на графике ниже:


image


$заголовок = ‘Чем больше фреймворков — тем лучше’;


Временные затраты


Реальный уровень производительности разработчика можно измерить только оценив как он тратит собственное время. Видно, что разработчики PHP больше времени тратят на написание кода и построение функциональных приложений, чем на культивацию Фактора Крутости Разработчика™ и получение звёзд на GitHub. Это, очевидно, отразится на них негативно при работе в стартапе, ведь они используют свое время непродуктивно. Все мы знаем что звёзды GitHub — это количественный способ оценки навыков разработчика.


Неспособность PHP-разработчиков внести свой вклад в сообщество показана ниже:


image
image


$заголовок = ‘Выслушивать жалобы — менее продуктивно, чем жаловаться. Факт.’;


Вещи, которые вы не сможете сделать являясь PHP-разработчиком


  • Программировать асинхронно (по-настоящему!);
  • Получить простую и понятную последовательность параметров функций стандартной библиотеки;
  • Создать свой собственный шаблон приложения React TODO MVC;
  • Реализовать полноценный бэкенд на стороне сервера с фронтендом на стороне клиента;
  • Создавать собственные утечки памяти;
  • Сделать пробел значимым ;
  • Добиться потери данных между запросами;
  • Решить проблему голода во всём мире;
  • Программировать на JavaScript;
  • Признаться людям, что вы — PHP-разработчик.

PHP как инструмент для бизнеса


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


image


$заголовок = ‘Node замечательный и эффективный инструмент зла’;


Заключение


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


  • Оригинальный заголовок статьи — image, однако парсер не позволил ни в каком виде использовать emoji в тексте.

Перевод: Simon Yousoufov
eudj1n @eudj1n
карма
50,7
рейтинг 43,5
Разработчик
Похожие публикации
Самое читаемое Разработка

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

  • +3

    Только пару часов назад читал оригинал и так и не понял — это стёб, наброс на вентилятор или серьёзно?

    • +73
      Конечно серьезно, посмотри на графики
      • +19
        Моя жена думает что я пишу на java… Как объяснить ей, что скоро нам придется голодать?
        • +5
          Как только я стал реже приносить домой чёрную икру, то моя жена сразу догадалась.
    • +6
      стеб конечно :)
      • +18
        Ну, если наука и графики для вас стеб — то я уже не знаю…
        • +2
          Знаете, я постоянно слышу, PHP мертв и вот Х язык/технология теперь будет топ.
          Языки/технологии приходят и уходят а PHP как был востребован так и есть.
          Помнится Ruby (RoR) появился в тренде, сколько проектов стали на нем разрабатывать, сколько вайна на PHP было и т.д.
          Затем питон так же ворвался в нашу экосистему, занял конечно свою нишу, там и сидит.
          Вот и NodeJs…

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

          P.S.
          17 лет опыта разработки веб-проектов, 10 лет HL++
          • +1

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

            • +1
              В каком плане похож на джаву?
              • 0

                Ну стала появляться строгая типизация. ООПестей пых стал как джава.

                • +4
                  Опционально же. Наоборот супер-приятно, что где надо можно всё делать уже весьма строго, а где не надо, можно и $$var продолжать юзать.
                • +1
                  Ну стала появляться строгая типизация

                  Как будто что-то плохое.
              • 0

                В общем и в целом, начиная с 5.0 по ощущениям очень многое берётся именно из Java в плане ООП, да и многие открытые PHP-проекты по архитектуре напоминают Java-аналоги, а то и явно заимствуют не просто идеи, но вплоть до названий классов, методов и т. п.

                • +1
                  Это в свою очередь гораздо упрощает гибридную разработку (разные модули на разных языках)
                  • 0
                    Поддерживаю.
                    На данный момент как раз смесь из Java+PHP (у каждого своя роль). Со временем вышла очень сильная гибридизация… вплоть до JavaScript кода в java.
                    В мир java много лет назад пришел из мира PHP. А сейчас java-like код пишу уже на PHP. Вот такое взаимообогащение,
                    • 0
                      Со временем вышла очень сильная гибридизация… вплоть до JavaScript кода в java.

                      Эммм… JS разрабатывался изначально как раз как клиентский Java-подобный язык.
                      Пруф: https://habrahabr.ru/company/livetyping/blog/324196/
                      • 0
                        Вы сами-то по вашей ссылке ходили? Там достаточно ясно написано, что это было скрещивание ежа с ужом: на кривую версия LISP'а натянули ситаксис Java.

                        Сказать что это «Java-подобный язык» в таких условиях может только маркетолог…
                        • 0
                          Комментарий, на который я отвечал, был изменён, поэтому искажается и суть моего комментария. Предлагаю на этом остановиться.
          • +8
            Но реальные проекты, выбирают PHP или Java.

            Как вы так сразу все мои проекты обозвали нереальными :-(

          • +1
            Реальные проекты выбирают гибрид из разных технологий. Например.
            • +4
              Согласен.
              Стандартный стек в текущее время, у меня таков: PHP (DDD/CQRS/CBus etc) / Go / Nginx / MongoDB + Pecona / Redis
              Но основной язык PHP.

              JS сейчас в топ рвется, но далеко не как бекенд.
          • –4
            Но реальные проекты, выбирают PHP или Java.


            Расскажите-ка об этом гуглу или яндексу, они поржут :)
            • 0
              Уговорили, если соберусь писать свой поисковик, то буду писать не на яве или пыхе.
            • 0
              Эээээ. Простите? В Яндексе не пишут на Java? Как то в списке их вакансий другая информация.
              Тыц!

              Про гугл ничего не знаю, никогда не смотрел, что у них там требуется.
            • +2
              В яндекс пишут на java, так же как и в гугл.
              В обеих компаниях, так же есть проекты и на php, js и др. языках. Но основное, это Java.
              • 0

                В Я если и есть что-то на пхп, то только купленное уже готовое. Тот же Кинопоиск пытались перепились на православной Яве. Не осилили.

                • 0

                  Если не ошибаюсь, Яндекс.Доставка на php.

              • +2
                В обеих компаниях, так же есть проекты и на php, js и др. языках.

                Известная байка:
                на phpconf у Marcus`a спросили как они используют php в google. Он ответил, что у них есть страничка, через которую они пиццу заказывают, так вот она написана на php
            • 0
              Ну так Google активно используют Java для кодинга почти всего.
          • 0
            А некоторые языки еще востребованы…

            как пример: https://geektimes.ru/post/287922/
    • +6
      У кого-то 1 апреля наступило на 12 дней позже )))
  • –1
    Наверно я как «Шелдон», тут сарказм или мне показалось?
    А так, каждому свое)
    • +24
      Что вы, какой сарказм.
      Node действительно превосходит PHP в возможности создавать собственные утечки памяти и в отличие от PHP, позволяет добиться потери данных между запросами.
      А потом, вы не видите сами, что вокруг практически все отказались от PHP?
  • +3
    Я изобрел машину времени и я в прошлом/будущем и сегодня 1 апреля?
    • +11
      Все верно, статья из прошлого. Сейчас Node.js уже мертв, а PHP интересен только с точки зрения палеонтологии. Староверы Ruby и Python живут в лесах и шлют друг другу запросы по локалке. Весь веб только на Go и Elixir.
      • 0
        Как будто какую-то книжку-фэнтези прочитал.
      • 0
        Протестую. Кроме веба есть и другие области. Тот же python в data science используют.
        • 0
          Зачем в лесу data science?
          • 0
            Я о том же. В этой будущей реальности, питонисты живут не в лесах, а как и все нормальные выжившие после атомной войны люди — в подземных бункерах.
    • 0
      Я даже глянул на дату поста, не первое ли апреля, оказалось нет =)
  • +4

    Чуть не повелся :)

  • 0
    Ну не знаю, для меня php в данный момент — это зона комфорта. И я без проблем могу бэк связать с фронтом. Сколько уже можно форсить тему неприязни к php =) Я не защищаю его, я просто считаю его одним из инструментов разработки, достойного быть в обиходе.
    И, да, мне удобнее использовать один общедоступный популярный фреймворк, а не городить очередной велосипед)
    Я понимаю, что, скорее всего, данный пост — это какой-то жесткий троллинг. Но в каждой шутке есть доля шутки =)
    • +10

      Поговорил с пастой — день прошёл не зря :-)

      • 0
        Ой, и не говорите, сразу полегчало =))
        • +2
          Выслушивать жалобы — менее продуктивно, чем жаловаться. Факт.
  • 0
    я уж было поверил :)
  • +1
    Автор знатный тролль :)
    • +2
      Это уже даже не троллинг, а пародия на троллинг…
    • 0
      В наше время использовали слово «сатирик».
  • 0

    Сегодня 1 апреля по календарю Майя?

    • +1
      По старому стилю.
      Плюс временной сдвиг на пару суток, чтобы точно не опоздать.
      • +2

        Это какая-то из стандартных функций PHP так делает?

  • +4
    $PHP = '💩';

    & #x1 F4 A9;
    • 0
    • 0
      Кстати, а вот в JS:
      > '💩'.length === 2;
      < true
      
      • 0
        А в PHP ещё хуже:
        > echo strlen('💩');
        < 4
        
        • +3
          А в PHP ещё хуже:

          Потому что mb_strlen()
          • +4
            > echo mb_strlen('👩‍❤️‍💋‍👩');
            < 8
            

            Have fun!
            • 0

              В Ruby:


              > ''.length
              < 1
              > ''.bytes.length
              < 4
              • 0
                Враньё

                [1] pry(main)> ''.length
                => 0
                [2] pry(main)> ''.bytes.length
                => 0
                • 0

                  Это хабр порезал. Скорее всего, из-за кармы.

                  • 0
                    Ааа, если это про символ какашки, то всё верно.
                  • +1
                    Парсер Хабра режет любые emoji если их вставлять как есть. Нужно через коды символов и HTML разметку: "&#x 1F4A9;" без пробела.
                • 0
                  Он имел в виду:
                  > '💩'.length
                  < 1
                  > '💩'.bytes.length
                  < 4
                  

                  А со сложными emoji как-то так:
                  > '👩‍❤️‍💋‍👩'.length
                  < 8
                  > '👩‍❤️‍💋‍👩'.bytes.length
                  < 27
                  


            • 0
              Ладно, сдаюсь, у UTF может быть разное количество байт на символ.

              Но юзать strlen() на чем-то кроме латиницы это кощунство
              • +1
                Согласен. Я не часто сталкиваюсь с PHP и мне как-то даже в голову не пришло, что для более корректного определения длинны строки там есть отдельная функция с неочевидным названием.
                -_-
                • +3

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

                  • +2
                    Не только функция: «оператор разрешения области видимости» называется T_PAAMAYIM_NEKUDOTAYIM («два раза двоеточие»).
                    • 0
                      Не просто «два раза двоеточие» но на древнееврейском!
                    • 0

                      Не оператор так называется, а константа токена в коде транслятора.

                      • 0

                        Если бы она еще не выводилась в сообщениях об ошибках...

                        • 0

                          Это пасхалка. Все любят пасхалки. Почему пасхалка ПХП вызывает столько попоболи?

                          • 0

                            Потому что ошибка трансляции — не самое удачное место для пасхалки.


                            Как вообще предполагается без гугла понимать, что сообщение вида "ожидался T_PAAMAYIM_NEKUDOTAYIM, обнаружено что-то другое" означает "пропущен знак $ перед переменной"?

        • 0
          А в PHP ещё хуже:


          Ну вот обычно php ругают те кто в нём не разбирается…
          • +1
            Т.е. как минимум две функции для подсчёта длинны строки, одна из которых считает её не в символах, а вторую можно найти только случайно и для задания кодировки, в которой она должна работать, нужно вызывать третью функцию, это нормально?
            Я действительно плохо разбираюсь в PHP, но это ни разу не нормально.
            • 0

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

              • 0
                > Плохо было если бы каждая функция для работы со строками могла бы менять локаль.

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

                Вот в том-то и проблема, что функция strlen подсчитывает байты. Впрочем, конкретно эта проблема досталась PHP по наследству от языка Си.

            • 0

              Просто нужно прочитать, что такое строка в PHP: "A string is series of characters, where a character is the same as a byte. This means that PHP only supports a 256-character set, and hence does not offer native Unicode support. See details of the string type." (http://php.net/manual/en/language.types.string.php)

            • 0
              Достаточно использовать класс Collator, и не нужны никакие танцы с бубном вокруг функций (хотя порой нужно подсчитать именно байты).
              • 0
                Если я правильно понял этот класс применяется для сортировки строк. Можешь объяснить как его применить для вычисления длинны строки?
                • 0
                  Что-то я был «слегка» невнимателен (собственные надстройки порой сбивают)… но помимо указанных двух есть еще iconv_* (которые используются наряду с mb_*). Вызов третьей функции можно сделать единожды на проект для упрощения (как правило, setlocale, mb_internal_encoding, bind_textdomain_codeset,… выставляются в utf8), или вовсе не использовать, оперируя вторым параметров функции для задания кодировки.

                  В качестве альтернативы:
                  $length = preg_match_all('(.)su', $text);
                  • +1
                    preg_match_all('(.)su', $text); — слишком просто и результат тот же, что и у mb_strlen / iconv_strlen в данных случаях.

                    Если уже на то пошло, то я обнаружил там ещё grapheme_strlen(), который считает в графемах и в случае c '👩‍❤️‍💋‍👩' выдаёт 4, что явно ближе к истине так-как игнорирует символы zero-width joiner, используемые между частями этого emoji, и считает ❤️ одной графемой (mb_strlen и iconv_strlen считают двумя символами, хотя там один символ ❤ и модификатор красного цвета).
            • +1
              Т.е. как минимум две функции для подсчёта длинны строки

              Я вас умоляю… В python для такого же функционала, две версии языка

              • 0

                В питоне есть одна понятная функция len() которая считает длину строки, списка, кортежа, а не этот бред в 5 функций с непонятными именами

                • 0
                  И функция strip вместо trim… В свое время меня очень удивила своим названием.
                  • 0

                    Да, детка! Обнажи своего удава свою строку!

                • 0
                  да, в питоне всё намного сложнее и интереснее:

                  Python 2.7.10 (default, Feb  6 2017, 23:53:20) 
                  [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
                  Type "help", "copyright", "credits" or "license" for more information.
                  >>> len('💩')
                  4
                  
                  


                  Python 3.5.2 (default, Nov 17 2016, 17:05:23) 
                  [GCC 5.4.0 20160609] on linux
                  Type "help", "copyright", "credits" or "license" for more information.
                  >>> len('💩')
                  1
                  
                  • 0

                    Основная причина создания python 3 — переход на юникод по умолчанию, потому что во 2 питоне юникод строка должна начинаться с буквы u


                    Заголовок спойлера

                    image

                    • –1
                      Так про это выше ukko и писал =)
                      • 0

                        В обоих версиях нормально считается длина юникодовой строки

                        • 0

                          А как вы определяете юникодовая строка или нет на глаз?


                          Приведу пример есть файл в файле есть текст. Требуется сказать какая у него длина.


                          указывать u при вызове или не указывать ?

                          • 0

                            Python3 по умолчанию работает с юникод строками, неважно, откуда они пришли. Если нужно работать с байтовыми строками, тогда строку нужно начинать с символа b


                            len(b'')
                            4

                            Также можно и для Python2 включить юникодовые строки по умолчанию, если в начале файла импортировать модуль


                            from __future__ import unicode_literals
                            
                            len('')
                            1
                            • 0

                              Хабр порезал символы(

                        • –1
                          И всё же новичок гарантированно ошибётся… В этом то и странность Питона, в нём вроде бы всё есть и работает, но надо постоянно знать и помнить о куче багофич, ограничений и странностей как в Perl. Вот в том же PHP во всех версиях эти две функции действуют однообразно и в большинстве случаев новички справятся (хотя там тоже есть всякие опции типа mbstring.func_overload, которые вносят хаос и боль)

                          P.S. Perl очень люблю, но там объективно куча особенностей, которые документированы, но охота думать о решении задач, а не вспоминать где и какие особенности могут встретиться.
                          • 0

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

                            • 0
                              ну только если религия не позволяет xDebug поставить
                              • 0
                                ну только если религия не позволяет xDebug поставить

                                В питоне дебаггер в стандартной библиотеке и ничего не надо устанавливать

                                • 0

                                  В пхп существует несколько дебагеров. Поэтому ставится отдельное расширение + для прода оно не нужно к чему лишний хлам таскать.
                                  А ставится оно одной командой минимальная настройка 3 строчки.

                            • –2
                              Как раз наоборот, это совершенно не проблема и вовсе не странность, это изучается один раз при изучении типов данных питона.

                              К примеру: Американец написал либу для питона по работе с текстом где не использует unicode строки (многие из них вообще не знают о том что существуют другие раскладки). Я поставил себе на комп разработчика (там убунта и Python 3.5 из коробки), всё работает и тесты проходят. А на продакшне (там Python 2.7), ничего не работает, но тесты проходит. Странность? Странность! И знание типов новичку в данном случае не поможет (а если он начал изучать Питон с 3.5 то вообще в прострацию введёт), а вот такой же подход в PHP ошибки не создаст.
                              Я не одобряю подход PHP в разделении на разные функции и костыля mbstring.func_overload, мне больше нравится подход Perl — указывать в начале скрипта версию, мне кажется это проще и понятнее и можно было бы старые библиотеки не переписывать, а в новые добавлять use_version 3.5, например, и не было бы этих шуток про Питоны 2 и 3.

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

                              В Питоне немало людей через print и pprint тоже отлаживают программы, я думаю.
                              А про консистентность, самые консистентные языки (из интерпретируемых с динамической типизацией) я думаю это LISP (там всё крайне однообразно, скобочки =))) ) и Ruby (японский перфекционизм сделал своё дело)
                              • +2
                                Я поставил себе на комп разработчика (там убунта и Python 3.5 из коробки), всё работает и тесты проходят. А на продакшне (там Python 2.7), ничего не работает, но тесты проходит. Странность? Странность!

                                Серьёзно? А если вы запустите пхп скрипт с тайпхинтингом на пхп 5.3? Что он вам скажет? Никто еще не отменял разность версий в любом языке


                                В Питоне немало людей через print и pprint тоже отлаживают программы, я думаю.

                                эти функции ничего не выводят в html, как в пхп, максимум в консоль и пользователи ничего не увидят

                                • –2
                                  А если вы запустите пхп скрипт с тайпхинтингом на пхп 5.3?

                                  Он сообщит об ошибке компиляции, скрытой логической ошибки не будет.

                                  эти функции ничего не выводят в html, как в пхп, максимум в консоль и пользователи ничего не увидят

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

                                    Вы даже не запустите скрипт на разных версиях, если не сделаете его совместимым для 2 и 3 версии. Если скрипт совместим — никаких логических ошибок не будет

                                    • 0
                                      Ну код выше же был совместим?
                                      Также новичок возьмёт и из файла обработает свой текст в юникоде без указания кодировки (на stackowerflow только так и советуют), в разных питонах тоже будет разный результат и не будет ошибки компиляции.
                                      • 0

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

                                      • +1
                                        В разных PHP результат тоже может быть разными и без ошибок компиляции.

                                        Причём это происходит постоянно — и разработчики на это даже не реагируют как на проблему.
                                • +1
                                  Что он вам скажет?

                                  Fatal error. Ни о каком прохождении тестов речи быть не может.

                              • +1
                                И знание типов новичку в данном случае не поможет (а если он начал изучать Питон с 3.5 то вообще в прострацию введёт), а вот такой же подход в PHP ошибки не создаст.
                                Да, точно-точно, правда-правда:

                                $ cat test.php
                                <?php echo htmlentities("Врун") ?>
                                
                                $ php5.3 --version
                                PHP 5.3.10-1ubuntu3.26 with Suhosin-Patch (cli) (built: Feb 13 2017 20:37:53) 
                                Copyright (c) 1997-2012 The PHP Group
                                Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
                                $ php5.3 test.php 
                                &ETH;�&Ntilde;�&Ntilde;�&ETH;&frac12;
                                
                                $ php5.5 --version
                                PHP 5.5.9-1ubuntu4.21 (cli) (built: Feb  9 2017 20:54:58) 
                                Copyright (c) 1997-2014 The PHP Group
                                Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
                                    with Zend OPcache v7.0.3, Copyright (c) 1999-2014, by Zend Technologies
                                $ php test.php 
                                Врун
                                


                                Вы уж врите, да не завирайтесь, а?
                                • –2
                                  1. Некрасиво переходить на личности и перед оскорблениями прочитайте ветку выше, чтобы понимать контекст беседы (и даже в таком случае считаю что оскроблять не стоит).
                                  2. Мы тут говорим про конкретную ситуацию про длины строк, там выше прикололись над Python (и я считаю что заслуженно именно в этом случае). Crandel стал его защищать и восхвалять, что в Питоне таких проблем вообще нет. Они есть и способ решения именно этой проблемы (работа со строками) получился у PHP однообразнее и понятнее, чем в Питоне (в разных версиях). Опять же напомню что мне этот ПХП подход не нравится.
                                  3. ПХП крайне неконсистентный язык программирования и я обратного не заявлял, но учитывая его историю, он может рассчитывать на понимание и снисхождение. Питон в тоже время имеет тоже имеет кучу проблем и странностей (и их количество растёт, в отличии от того же ПХП где их количество стараются уменьшить), но вместо того чтобы их признать и как-то попытаться исправить, им придумываются заумные объяснения, которые приводят к тому что вместо решения задачи надо о них помнить и учитывать (это не значит что Питон плох, просто вот такая особенность коммьюнити и разработчиков).
                                  • +2
                                    Контекст беседы:
                                    Американец написал либу для питона по работе с текстом где не использует unicode строки (многие из них вообще не знают о том что существуют другие раскладки)
                                    Если вы считаете что американец в библиотеке только и исключительно вычисляет длину строки 100500 раз — то вы ошибаетесь. Он ещё и другие функции работы со строками использовать может.

                                    Говорить о том, что в
                                    способ решения именно этой проблемы (работа со строками) получился у PHP однообразнее и понятнее, чем в Питоне (в разных версиях)
                                    как бы несколько странно с учётом того, что работа со строками — это не только вычисление их длины…
                                    • –3
                                      Я не понял что вы мне хотели донести этим сообщением.

                                      Если с unicode строкой работать как с набором байт, то все функции работы со строками будут работать неверно.

                                      В PHP же все строковые функции имеют копии с префиксом mb_.
                                      • 0
                                        Если с unicode строкой работать как с набором байт, то все функции работы со строками будут работать неверно.

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

                                        • –1
                                          Вы хотя бы больше одного сообщения вверх читайте, что пишут =)

                                          Я думаю тут больше незачем переливать из пустого в порожнее, за сим откланяюсь.
  • +1
    В первом абзаце шикарный вброс. Надо было всю статью в том же ключе продолжать, без намека на стёб :)
  • +1
    Автор, спасибо тебе. Понял что потратил долгие годы зря, ушел писать свой фреймворк для nodejs
    • +10
      Разместите обязательно ссылку на GitHub
  • +4
    «Миллионы леммингов не могут ошибаться» (с)
  • 0
    Вы мне это прекратите! С такими статьями… Чуть Кондрат не обнял на первом же графике!
  • +6
    Too fat
  • +1

    Записали каких-то ноунеймов в сторонников ноды и Microsoft который к этому вообще не имеет отношения :\ Записали бы Uber, netflix, linkedin, paypal но тогда не получится высмеять да.

    • –1
      Как это не имеет? А Visual Studio Code с мигалкой? https://geektimes.ru/post/287342/
      • +2

        Причем тут баг хрома к серверсайд разработке? Или если бы MS сделали редактор на пхп — такого бы не было?

        • –1
          Из вики:
          >В частности, Visual Studio Code является надстройкой Electron (бывшим Atom Shell), который объединяет в себе браузерный движок Chromium и Node.js
          • 0

            А чего вы тогда скинули ссылку на баг хрома? Или вы прочитали только заголовок и решили "уколоть"? Даже представить себе боюсь standalone редактор на пхп. Записывать MS в сторонники ноды из-за этого — хм...

            • 0
              Вообще, это опровержение вашего «Microsoft который к этому вообще не имеет отношения». Конечно, для них на js свет клином не сошёлся, но они «реализуют свои продукты на основе Node», если вы не заметили.

              Да и почему бы не уколоть за такую глупость, как написание компьютерных приложений на ХромоНоде? К слову, идея приложений на php тоже была в ходу когда-то, но, по понятным причинам, умерла.
    • +2

      Это так-то тонкий троллинг. Компании в списке часто ассоициируются с чистым злом.
      Microsoft — пояснять не надо.
      Enron — это контора которая ради спекуляций на акциях обесточила неплохую часть штата на некоторое время.
      Monsanto — это создатели GMO семян и гербецидов, так же как и DDT и агента оранжа — которым травили въетнамцев
      BlackWater — это наемники, которые занимаются отстрелом местного населения в странах где натуральные ресурсы плохо охраняются
      Time Warner — те кто вечно всех судят за нарушения авторских прав
      Comcast — один из монополистов на рынке интернета и опять же часто мараются в разборках по авторским правам.


      Плюс это все толстые корпорации с бесконечными цепочками управления.


      А противопоставляется все "модным и хиповым" tesla, facebook, wiki, etc. — которые как бэ в плане PR выглядят побелопушистее.

    • 0
      Этот рисунок, про сторонников ноды, как раз самый тонкий подкол! Меня только с него улыбнуло.
      Компании не ноунеймы для США для которой был написан оригинал.
      1) Microsoft не любят все подряд
      2) Comcast, Time warner cable кабельные и интернет провайдеры. Сам вчера с комкастом мучился, а в поддержку не дозвониться.
      3) Blackwater скандально известная военная компания.
      Локализованый рисунок состоял бы из Сбербанка, Ростелекома и вашего местного ЖКХ
      • 0
        Автор не успел добавить United Airlines в JS-список?
        • 0
          Ну там Древнее Зло а United — просто мелкие хулиганы.
  • +1
    Забавно вакансий 0 на графике и чуть ниже статьи блок МойКруг вакансия «PHP developer от 100 000» )))
  • –13
    Когда видишь подобные петросянские статьи, понимаешь, что мир PHP уменьшается.
    Люди, судя по опросам, уходят на Python и другие языки, но популярность PHP нужно раздувать дальше.
    • +2
      Да ей Богу, лучше бы Python полностью вытеснил PHP. Язык заточенный не только под веб, куча разных тулз.
      • +3
        Лучше наоборот. Что хорошего в трм, что замена табуляции на пробелы ломает программу?
        • 0

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

        • –1

          А что хорошего вы ожидали в замене табуляции на пробелы?

        • +6
          А если к этому еще и кусок кода заменить на анекдот — вообще ничего не работает.
          Плохой python.
          • –2
            Был случай на работе, когда администратор раскатывал скрипт по серверам через копирование и вставку в консоль. Скрипт не заработал. В скрипте были пробелы и табуляция. Можно ругать админа и программиста, но язык от этого лучше не станет.
            • 0
              Т.е. админ бездумно копипастит а виноват язык? Ок.
              • –3
                Написал выше что виноват админ и программист. С PHP или Shell скриптами такой ситуации не возникало.
                • 0
                  У нас — возникало. Так что не надо на python баллоны катить.
                  • 0
                    Что у вас возникало? Опишите ситуацию.
                    • 0
                      Bash скрипт. Ломался точно так же, как и python скрипт при «бездумном копи-пасте». Hint: подумайте о том что обозначает и как работает в bash конструкция
                      command <<-END_OF_TEXT
                      и ответьте себе на вопрос: что с ней будет если её скопировать «мышкой с экрана» (что ваш админ, как я понял, сделал).

                      python отдыхает!
          • –3
            Язык, в котором логические блоки задаются форматированием, не может быть хорошим.
            • +2

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

              • 0
                Вот только скобки везде обозначают именно логические блоки, что в лингвистике, что в математике.
                • 0

                  Особенно в устной речи, ага.

                  • +1
                    Боюсь представить, что в устной речи обозначают табы.

                    (почему в мобильной версии нельзя редактировать?)
                    • 0

                      Ничего не означают. В устрой речи есть только слова и паузы разной длительности.

                      • 0
                        … которые на письме записываются, соответственно, буквами и знаками препинания. Письменность, в которой запятые обозначались бы двумя пробелами, а точки — тремя, вряд ли была бы читаемой.
                        • 0

                          image

                          • 0

                            image

                            • 0
                              Наглядные примеры того, что форматирование не влияет на смысл, да. Зачем вы противоречите сами себе?
                              • 0
                                </sarcasm>
    • +2
      А вот может наоборот сделают компилятор PHP → WebAssembly и все начнут фронтенд писать на PHP. =)

      Пишу как шутку, но кто его знает.......
      • 0

        А шутка в чем?

        • 0
          Шутка в том, что это может случиться, но написать об этом прямо он не смог, поэтому назвал идею шуткой.
      • +1

        Был Delphi for PHP, позволявший всю логику фронтенда реализовывать в PHP на сервере.

    • –4
      Не нужно ничего раздувать. Просто людям обидно. PHP — это Visual Basic наших дней. Язык, заточенный под людей, плохо разбирающихся в программировании, которым нужно «несколько фомочек замутить».

      Со временем люди понимают с каким ужасом они имеют дела и уходят, но общее количество людей, программируюших на PHP и не думает уменьшаться.
      • +1
        с каким ужасом они имеют дела

        Только подобные статьи пишут и про яваскрипт с нодой.
        • 0
          Ничего удивительного: центральная идея («а давайте угадаем чего аффтар хотел») у них та же самая.

          Но всё-таки JavaScript создавали люди с некоторыми знаниями computer science, так что JavaScript — это просто «ужас», но PHP — это «ужас-ужас-ужас»…

          Сейчас эту свинью, впрочем, замазали буквально килограммами «губной помады»… но оригинальный образ всё равно смутно проглядывает…
          • +1
            ЭЭ, знаете, ненавижу php, но он ГОРАЗДО лучше javascript. Javascript это какой то тихий ужас, тем более современный.
            • +2

              Может у меня, конечно, стокгольмский синдром, но что в нём такого ужасного? Особенно в современном.

              • +1

                Все от его шней инфрастуктуры до фреймоврков.


                Вод на днях думаю напишу как я простое приложение на angular2. Думаю что тут сложного. Открываю quickstart angular2
                https://angular.io/docs/ts/latest/quickstart.html вот этот.
                И что я вижу нет там js есть неведомая мне фигня которая называется typescript. ладно думаю чего уж "победю" настраиваю я компиляцию ts в js и что? не взлетает потому что мой браузер чет не знает слов import и прочее.
                после плясок вокруг этого https://angular.io/docs/ts/latest/guide/setup.html я понял что уж лучше php
                чем этот современный js. Почему у меня на любом фреймворке php все взлетает
                в крайнем случае после composer create-project… и composer update

                • –2

                  Думаю, вам понравится этот фреймворк: https://github.com/eigenmethod/mol#quick-start

                • +2

                  А причем Angular 2 к современному JS? Angular это штука которую надо учить отдельно, со своим синтаксисом и правилами.
                  Мне он, кстати, тоже совершенно не нравится, из-за того что при таком высоком пороге входа он предоставляет слишком мало удобных абстракций и структуры. Но это проблемы ангуляра, не JS. Ну, и к сожалению наши проблемы тоже, потому что толпы хомячков теперь ВНЕЗАПНО обнаружили что angular 1 плох, и ломанулись разрабатывать на angular 2.


                  Тем не менее, JS как язык сам по себе, начиная с ES-2015, весьма неплох, и при соблюдении минимальной гигиены (всегда использовать === вместо ==, использовать явное приведение типов, писать es-2015 классы непример) на нем можно писать очень хороший и выразительный код.


                  Какой JS фреймворк хороший? Конечно же тот который напишу я! Не забудьте поставить мне звездочку на гитхабе :)

                  • 0

                    Ну я как понимаю angular2 использует лучшие практики js. Возможно я живу в прекрасном мире php, где мажорные версии php фреймворков сделаны с использованием лучших практик на этот момент. Если стало трендовым подключать модули компосером нате. Laravel 5, Yii 2, Symphony 3 все они подключают модули именно компосером. Стала тредовой архитектура микросервисов нате получите.


                    В общем мир пхп прекрасен и всегда маст-хэв ут.

                    • +3
                      Ну я как понимаю angular2 использует лучшие практики js.

                      Нет. Ангуляр всегда был сборником сомнительных практик.

                    • 0

                      Скорее наиболее популярные фреймворки задают тренды, а не следуют им.

                • 0
                  И что я вижу нет там js есть неведомая мне фигня которая называется typescript

                  Что-то я не вижу логики в ваших действиях: захотели изучать современный javascript и выбрали typescript-фреймворк :-)


                  PS А проблема с импортом решается через указание "module": "amd" или "module": "commonjs" в файле tsconfig.json

                  • 0

                    Ну я сделал просто зашел на HH и обнаружил что всем нужны прогеры со знанием angular 2.


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


                    Так а какой современный js фреймворк стоит изучить что бы можно бэк на божественном пхп делать?

                    • 0

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




                      Лично мне для всех задач пока хватает knockout + jquery + requirejs, но у меня бэк на ASP.NET MVC.


                      Присматриваюсь к связке mobx + react, только не знаю что использовать для сборки и как лучше грузить модули.

                    • 0
                      Так а какой современный js фреймворк стоит изучить что бы можно бэк на божественном пхп делать?

                      Любой.

      • 0

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

        • +3
          А что — всё то, что наворотили до того, как вышла версия 4.0 из языка куда-то делось? Массимы стали вдруг массивами, а не чёрт-знает-чем? Правда E_ACTUALLY_ALL исчез (в смысле E_ALL таки обозначает то же самое, что и -1… в версии 5.4 появилось, да).

          История похожа на C++ — есть куча очень «стильных, модных, молодёжных» примочек, но «изначальные» вещи, криво сделанные в C, никуда не делись и регулярно отравляют людям жизнь…
          • +1

            В C все сделано просто. Обертка вокруг ассемблера. Но вот когда начали делать C++ — вот тут начало повылазивать. Потом это пробовали прикрыть разными костылями.


            Если сравнивать C и C++ сравните сколько в C ситуаций, которые про undefined behavior и сколько в C++

            • +1
              Если сравнивать C и C++ сравните сколько в C ситуаций, которые про undefined behavior и сколько в C++
              Ну дык вопрос не в количестве! Вопрос в качестве. То, что interator на массив из которого удалили элемент больше использовать нельзя — неприятно, но не смертельно.

              А вот то, что нет простой возможности сложить два числа и понять — произошло при этом переполнение или нет (за исключением использования компиляторно-зависимых built-in'ов) — это, согласитесь, несколько странно для «обёртки вокруг ассемблера»! Особенно с учётом того как часто эта проблема «стреляет» в реальном коде…
          • 0

            "Заточен" в моём понимании значит, что подавляющее большинство фич языка под это сделано. А это давно уже не так. Более того, многие фичи версий 5- выпиливаются постоянно. Большинство реального кода, написанного под 3.0, в 7.0 просто не заработает.


            Какая сейчас заточенность под тех, кто не разбирается в программировании? Лично мне в голову приходит только неявное приведение типов с не очень очевидными правилами в очень многих случаях и "киллер-фича" — вывод текста не обрамленного тегами в stdout. Всё по сути. Не хватает чего-то привычного по другим языкам — есть такое. Но заточенность-то в чём?

      • 0
        Инкремент (++) NULL'а выдаёт 1.

        <?php

        echo 1? 2: 3? 4: 5;


        Автор статьи по вашей ссылке, видимо, очень хорошо разбирался в программировании.
      • +1
        Ваше представление о PHP устарело лет на пять минимум.
        • +2
          Что, уже и оператор сравнения стал транзитивным, да?

          Я не спорю — последние версии уже потихоньку начинают напоминать язык программирования. Но сколько «добра» ещё осталось…
          • +1
            Нет же, я о том, он давно уже не заточен под людей, плохо разбирающихся в программировании. Он примерно таким задумывался изначально, но современный PHP уже далеко не такой.

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

            К слову, в том же JS с оператором сравнения так же весело, если не веселее. По моим впечатлениям, ранний JS выглядит гораздо уродливее PHP (того же времени) в плане дизайна языка. Но JS — это уже совсем другая история :)
            • –1
              А то современный js не уродлив
        • 0

          Неужели все функции с непонятными именами в стандартной библиотеке(strpos, str_rot13, ...) переименовали на что-то логически понятное для людей?

          • 0
            В Си вон тоже не торопятся переименовывать :) многие названия позаимствованы оттуда. Да и не надо перечислять все пункты из той статьи, я её читал. Многое из этого никуда не денется, это, конечно, печально, но…

            Я другое хотел сказать: программисты на PHP стали писать код, логически понятный для людей, а не лапшеобразную мешанину всего подряд. Появились стандарты, инструменты, код стайл, композер, вот это вот всё. Уровень вырос, сейчас за всякую лапшу в стиле двухтысячных в нормальном сообществе PHP-программистов просто закидают гов… критикой. А когда-то ничего, и так норм было :)
            • –1

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

              • +1
                Возможно даже не большинство. Но лет пять-семь назад только такие пхп-программисты составляли 97% (с потолка цифра, конечно) индустрии. Часть продолжает двигаться по инерции и копаться в написанном 15 лет назад говнокоде, используя те же «дедовские» приемы организации процесса разработки (если это можно назвать процессом). Но нельзя все-таки не заметить эволюцию PHP-сообщества: если появляются стандарты, значит, они востребованы и нужны. Если развиваются фичи по проверке типов, значит, сообществу это тоже нужно. Ну и так далее.
              • +2
                писатели плагинов к wp это уже не php программисты — это узкоспециализированные wordpress консультанты, не более.
                • 0
                  писатели плагинов к wp это уже не php программисты — это узкоспециализированные wordpress консультанты, не более.

                  С чего бы это? Они еще джумлу умеют)))

                  • 0

                    они могут хоть в Битрикс. Они все равно остаются узкоспециализорованными людьми. Как программисты 1С.

              • 0
                Это говорит лишь о ваших знакомых, не натягивайте из на всех, пожалуйста
                • +1
                  Не знаю, возможно большинство уже и пишут код, логически понятный для людей, но почему-то все мои знакомые пхп-програмисты продолжают писать плагины к вордпресу

                  Где в этих словах вы увидели отсылку на всех пхп программистов?

                  • 0
                    Извиняйте, реально просмотрел :)
  • +2
    Использовать в качестве аргумента за JS необъятную кучу невнятных велофреймворков… Ну не знаю даже…
    Действительно ли так хороши фреймворки, которые устаревают к моменту завершения чтения раздела Getting Started в официальной документации?
    • +6
      Не нашли подходящий фреймворк? Так напишите свой!
  • +3
    Как человек со стороны, я могу сказать, что существующие экосистемы PHP очень плохо интегрируются в взрослые (читай, не «shared hosting») системы. Мало библиотек, плохо проработанные практики для Ci/CD.

    apt-cache search ^php-|wc -l
    540
    apt-cache search ^python-|wc -l
    3898
    apt-cache search ^ruby-|wc -l
    1174
    apt-cache search ^node-|wc -l
    782
    apt-cache search ^lib|wc -l # mostly C/C++
    24620

    Мне как админу с php-софтом работать некомфортно и я постоянно опасаюсь, что он будет от рута исполнять код из каталога с правами 777 (созданного в генераторе превьюшек). Я понимаю, что это не вина языка программирования, но, так сказать, его карма.

    • +2

      Ну, у PHP, Ruby и NodeJS число пакетов одного порядка. Думаю, не в последнюю очередь потому, что у всех трёх есть свои "нативные" менеджеры пакетов.

      • 0
        Угу. Нода у меня вызывает ровно такое же непринятие и неудобства.
        • +1
          Проекты на ноде тоже норовят исполнять код из каталогов с правами 777? о_0 Или здесь все-таки неудобства другого рода? Из любопытства спрашиваю.
          • 0
            Проекты на ноде я, честно говоря, в продакшене почти не видел, так что своего впечатления сформулировать не смог. Вероятнее всего, ситуация менее ужасная, потому что у ноды нет родовой травмы php-экосистемы — shared-хостинга. Нода, всё-таки, это сервер, и подход к нему может быть наплевательский, но другого уровня, чем в случае php обитающегося внутри mod_php и домашнего каталога пользователя.
    • +2
      >Как человек со стороны, я могу сказать, что существующие экосистемы PHP очень плохо интегрируются в взрослые (читай, не «shared hosting») системы. Мало библиотек, плохо проработанные практики для Ci/CD.

      Што. Какое отношение ЯП имеет к CI/CD?
      • +1
        Потому что ЯП обычно — не BNF с интерпретатором, а экосистема. Библиотеки, менеджеры зависимостей, модель декларации этих зависимостей, специфичные приёмы при установке этих зависимостей. Дальше идёт интеграция этих менеджеров зависимостей и стандартных средств сборки с средствами сборки операционной системы. У некоторых это развито идеально (си), у некоторых отлично (python), некоторые больно страдают (ruby, php, node).
        • 0
          А composer чем не ответ на все эти вопросы?
          • 0
            На все? Включая установку правильной версии libssl на хосте?

            У проблемы системных зависимостей нет лёгкого решения. Есть непротиворечивое и работающее — это системные пакетные менеджеры. Интеграция с ними — это сложно.

            Но ладно, composer. Вот, скажите, как у нас с composer сочетается установка нескольких известных php-приложений, допустим: mediawiki, wordpress, phpbb. Они composer'ом устанавливаются в систему?
            • +3
              > Включая установку правильной версии libssl на хосте?
              Подождите, но libssl — это внешняя относительно PHP сущность. Критика как бы не совсем по адресу.

              >Но ладно, composer. Вот, скажите, как у нас с composer сочетается установка нескольких известных php-приложений, допустим: mediawiki, wordpress, phpbb. Они composer'ом устанавливаются в систему?
              Почему бы и нет? К примеру:
              https://www.mediawiki.org/wiki/Composer/ru

              Смотрите, вы накидываете примеры из совершенно разных уровней управления.
              Если вам нужно одноразово приложение — установите его файлами.
              Если нужно поддерживать приложение up-to-date со всеми его внутренними зависимостями — используйте composer.
              Если хочется также возможности фиксации внешних зависимостей — соберите образ или используйте docker.
              Если нужна оркестрация всего этого счастья — используйте менеджер оркестрации.

              Поймите, если чего-то «из коробки» нету в apt — это не значит, что нет красивого способа этим управлять ;)
              • 0
                Конечно, внешняя. В этом и проблема. Сущность внешняя, а «не работает внутри».

                Когда вы делаете полноценный CI/CD, то у вас «внешняя сущность» прописана в зависимостях и будет установлена системным менеджером пакетов.

                Притаскивать докер как решение проблемы зависимостей — это круто. Настолько круто, что у меня слов нет. Вот вышла у нас очереная CVE'шка для openssl. Пробежался у нас по хостам apt-get, эту libssl обновил. А что у вас докеры делают? Ах, они же иммутабельные…
                • 0
                  Собрали образ, разложили каким-нибудь ansible по всем хостам. Не вижу проблем вообще. Причем не важно, есть ли эта CVE в репозитории конкретной ОС или нет, время будет одинаковое.
                  • +1
                    А по какому признаку вы собрали образ? С одной стороны у нас есть security team дистрибутива, которая пристально следит за этими CVE и релизит апдейты. С другой стороны у вас (админы, программисты?) которые должны делать то же самое, но ещё раз и с знанием всех пакетов, которые у них в этом образе есть.

                    Потрясающий апгрейд производительности сотрудников.

                    Ещё больше мне нравится ваша категоричность о том, что вы не видите проблем. Я понимаю, что вы их не видите. Это не значит, что их нет.
          • 0
            Собственно, главная драма, что никто не понимает, что с этим делать. Посмотрите на жалкое состояние спека по пакетированию php-библиотек в debian: http://webapps-common.alioth.debian.org/draft-php/html/
        • 0

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

          • 0
            Простите, а в какой ОС Си — не дефолтный язык? Если что, все *.dll и *.so — это части экосистемы Си. Они так глубоко интегрированы в ОС, что невозможно отделить одно от другого (на самом деле возможно, но путём очень сильной ампутации по функционалу).
            • +3

              Это просто библиотеки, соответствующие соглашению Си о вызове функций. Не только Си поддерживает эти соглашения. Тот же Ди поддерживает и Си соглашение, и Паскаль, и СиИнкремент, и даже ОбъективныйСи.

              • 0
                Разумеется. Ровно то же можно сказать для любого jar'ника, даже если его фигачат kotlin'ом или другой адской экзотикой.

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

                Надо осознать, что Си — это основа всех современых ОС, и его методы подгрузки модулей стали стандартом для ОС на уровне, когда не поддерживая эти стандарты (тем или иным образом) эту ОС использовать просто нельзя. Более того, по сравнению с остальными языками, у Сишного динамического линкера (который по задаче запуска приложения мало отличается от любого «интерпретатора» или vm) особое, привилегированное положение в системе. Например, я могу поставить suid на ELF, но не могу поставить suid на jar.
                • +1

                  Ну, это вы про одну конкретную кривую ОС говорите. В других ОС другие тараканы :-)

                  • 0
                    Я не знаю ни одной generic OS у которой бы тараканы были другими. Возможно, у ios/android ситуация другая, но среди десктопных систем все общеупотребимые (freebsd, linux, macos, windows) жёстко завязаны на сишные интерфейсы во всём.
                    • 0

                      COM, .NET — ни разу не "сишные интерфейсы".

                      • 0
                        Я плохо знаю потрошки COM, но, вроде бы, там идут в финале обычные so'шки (dll) с функциями с специфичными сигнатурами. .net составляет из себя маленькую надстройку над winapi.
                        • +2
                          .net составляет из себя маленькую надстройку над winapi.

                          Нифига себе маленькая.
                        • 0

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


                          А управляемые dll имеют и вовсе свой механизм поиска зависимостей, учитывающий публичный ключ подписи файла.


                          Так что dll — это совершенно не часть экосистемы Си.




                          Теперь про COM. COM — это, на нижнем уровне, общий стандарт на формат публикации таблицы виртуальных функций, который позволяет передавать указатели на объекты между модулями, скомпилированными разными компиляторами.


                          При этом методы объектов не экспортируются из библиотек обычным образом, а остаются внутренними для модулей — и участие загрузчика модулей остается минимальным. Фактически, одной из целей COM является как раз преодоление ограничений си-подобного связывания функций.




                          Кстати, стандартным соглашением о вызовах что в WinAPI, что в COM является stdcall, которое ничуть не похоже не сишное cdecl.


                          Так что попрошу не обобщать опыт линукса в плане засилия Си на другие ОС.

    • +2
      Я понимаю, что это не вина языка программирования, но, так сказать, его карма.
      Нет, это его вина. Весь язык от начала до конца был создан под лозунгом «как-нибудь лучше, чем никак». Малог того, что это приводит к ужасному дизайну — это привлекает кучу разработчиков, которые порождают творения, которые «будут от рута исполнять код из каталога с правами 777 (созданного в генераторе превьюшек)»
      • 0
        «будут от рута исполнять код из каталога с правами 777 (созданного в генераторе превьюшек)»

        Вот этот момент не понятен совершенно. PHP- это скриптовой язык, какой рут, какие 777? Достаточно полных прав процессу интерпретатора и прав на чтение вебсерверу.
        • +1
          Во времена шаред-хостингов PHP обычно работал как модуль веб-сервера и имел одинаковые с ним права.
          • +1
            Ну да. Но при чём тут рут и 777? Это бред какой-то. На том же шареде в большинстве случаев прокатывает или 640, или 600. А уж исполнение пользователских скриптов от рута не встречалось нигде от слова вообще. Так что мимо.
        • +3
          Достаточно полных прав процессу интерпретатора и прав на чтение вебсерверу.
          Достаточно. Но так как сделать права 777 проще — то так зачастую и делали.

          Ситауация с PHP постепенно, очень постепенно, исправляется — но посмотрим чем всё закончится. Когда Visual Basic решили «исправить» одним резким движением и создали Visual Fred — то потеряли почти всех разработчиков. PHP6 свернули и, может быть, со временем PHP и «доведут до ума» — но надежды мало. Уж очень много в нём разных болячек изначально было…
          • –1
            Достаточно. Но так как сделать права 777 проще — то так зачастую и делали.

            Кто, как, зачем? С чего это chmod(777) стал проще, чем chmod(640)?
            И где объяснение исполнения от рута? Никогда такого не видел, вообще.
            • +3
              Кто, как, зачем? С чего это chmod(777) стал проще, чем chmod(640)?
              Дык эта. Первое — работает, а второе — нет. Тут беда в том, что скрипты зачастую заливались пользователем ftp, а исполнялись под пользователем http. Чем разбираться во всяких тонкостях — проще сделать «chmod 777» — и всё будет работать.

              Этим не только PHP грешил, впрочем. Драйвера, которые давали OpenOffice.org (sic!) видели? Вот это — из той же оперы.

              Понятно что это было лет так 10 назад, но код так просто и быстро не умирает, увы…
              • +1
                Этим не только PHP грешил, впрочем.

                А что тогда пенять на PHP? Никакой другой скриптовой язык не справится с нехваткой прав на чтение файлов.

                Могу в третий раз спросить про рута. Только не говорите, что кто-то запускал PHP от рута, чтобы решить первую проблему. Не верю, нигде и никогда такого не видал.
                • 0

                  Виндузятники по привычке всё делали от рута :-)

                • 0
                  А что тогда пенять на PHP? Никакой другой скриптовой язык не справится с нехваткой прав на чтение файлов.

                  Да, но советы вида "да поставь ты всем файлам 777 доступ!" встречались именно на PHP-форумах :-)

      • 0
        Интересно что много из єтой статьи не актуально в 7.1))
    • 0
      Мало библиотек, плохо проработанные практики для Ci/CD.
      Потому что никто в здравом уме не будет ставить библиотеки в PHP глобально, тем более из apt, где они непойми-каких версий.

      В PHP есть прекрасный инструмент для управления зависимостями: composer.
  • 0
    А как насчет того, что на обработчик в Node.js не рекомендуется вешать сверх-вычислительные задачи, поскольку это блокирует столь быструю обработку очереди эвентов?
    • +7
      Будем честны — подобные задачи не стоит возлагать и на PHP.
  • +1
    Лет 15 уже хоронят С/С++.

    С середины 90х всё хоронят Windows в пользу Lunix.

    С распространением Интернета всё хоронили ТВ.

    Думайте своей, а не чей-то, головой
  • 0
    Парсер написан на PHP, судя по всему
  • +12

    Нужно больше "осмысленных" комментариев к стебному посту, больше!

    • +2
      Очень не хватало тега <sarcasm> при написании перевода :(
      • +1

        Скорее, очень не хватает людей, понимающих сарказмы :)

  • +1
    * комментарий про аксиому Эскобара *
  • +1
    Ну конечно же все это серьезно!!! Команды WordPress, Drupal, Bitrix, Laravel и многие другие втайне уже переписывают свои проекты на ноду. Инфа 100% инсайд.
    © Сарказм.
  • +1
    Некоторые люди читают теги.
  • +1
    Пускай всё что угодно переписывают на js пока мы тратим заработанные бабки и нюхаем кокаин
    • 0
      Между прочим, так люди и начинают переписывать всё что угодно на js.
      • 0

        Особого смысла сейчас нет переписывать что-то обычное с PHP на NodeJS. Если уж PHP не устраивает, то с NodeJS проблем вряд ли будет сильно меньше. Если и переписывать, то на что-то компилируемое, типа Go.

  • 0
    Только что на баше:
    xxx: Попросили перед собеседованием на php разработчика прислать кусок кода, которым я горжусь больше всего. Что делать, если я вообще не горжусь того, что пишу на php?
  • 0
    Стравить два самых спорных по качеству дизайна языка — это так толсто, что даже тонко.
  • +1
    Каждый разработчик знает, что самый быстрый и эффективный путь к получению чего-либо — это много жаловаться и каждый раз начинать всё с нуля. Рынок всегда будет ждать запуска вашего стартапа, ведь в первую очередь нужно закончить создание собственного фреймворка.

    Узнал себя. Мне даже как-то непосебе стало. )
  • +4
    Даже не знаю что печальнее — уныние и чрезмерная толстота этого поста, или тот факт что на хабре снова находится толпа индивидуумов, на полном серьезе обсуждающих такое…
    • +1
      Это не печально, это очень весело. Повылазили смешные самодовольные ребята разного рода.
  • +1

    На PHP каждый считал своим долгом написать свой правильный шаблонизатор. JS пошёл чуть дальше — каждый пишет свой фреймворк. Это вы ещё LISP не видели — там вообще каждый считает своим долгом написать свой язык :-D

    • 0
      На PHP в разное время каждый писал свой шаблонизатор, потом свою CMS, потом свой фреймворк, ровно в те моменты, когда этого добра уже было в достатке :)
      • 0

        Потом они прочили, что пхп мертв и посшли писать свои фреймворки на js. Ничего не меняется.

  • +1

    К слову, недавно нашумела статья «Electron — это новый Flash». Ее прекрасно дополнила бы: «Javascript — это новый PHP».

  • –1
    По ходу у автора знатно накипело от Node.js. Точнее от пиара Node.js.
  • +2
    Вещи, которые вы не сможете сделать являясь PHP-разработчиком:
    Признаться людям, что вы — PHP-разработчик.

    Эм… я PHP-разработчик :)
    И юзаю Laravel в работе, как и многие другие.
  • –1
    Взглянув на последнюю картинку понял, что статья есть жирный троллинг)
    • +2

      Разве это не было ясно из первого абзаца?

      • 0
        Из первого абзаца ясно что троллинг) А из последнего — жирный троллинг)
  • –2
    Не понимаю всего этого ажиотажа. Кто хочет, использует php, кто хочет — js. Никто никого не 'убивал'. К вопросу о js — люди говорят о фреймворках, но это всего лишь инструменты. Зачем приводить в пример вещи, которые совершенно необязательны по большей мере? В статье пытаются задеть nodejs-кодеров, но описан только частный случай — далеко не все в js используют кучу фреймворков, а прокрастинируют люди вообще в любой области жизни.
  • 0
    (php + nodejs) > (php || nodejs)
  • –1
    Больше рассмешило, что фейсбук является не удачником :)
    • +2
      Больше всего насмешило, что не умеете писать правильно не со словами.
  • 0
    Можете спорить до потери пульса или сознания. Как по мне, так я люблю python и его фраемворки. Приятно работать. По мне, так и PHP и Node.js мертвы. С точки зрения языка, не технологии или стека, для программиста в смысле, то что PHP что JavaScript это шлак еще тот! А Python потихоньку, тихим сапом, развивается. Есть в нем все. И асинхронность и для быстрых запросов. Если что-то появляется в тренде других языков, то он тоже это прорабатывает. Было время, не умел работать с websocket. Потом все появилось. За то любо дорого работать. Наслаждение и языком и продумонностью технологии. Ну а остальное — кривые руки, имхо, их никто еще не отменял.
    • –1
      Я вот например спорить не хочу. Просто захожу на популярный сайт поиска работы:

      rabota.ua:
      PHP — 795 вакансий
      Python — 151 вакансий
      Node.js — 183 вакансий

      hh.ru
      PHP — 1141 вакансий
      Python — 1021 вакансий
      Node.js — 173 вакансий

      • +1
        Я вот тоже зашел, решил проверить:

        python: Jobs 1 to 10 of 44,996
        php: Jobs 1 to 10 of 17,894

        При этом много работы на PHP связано с drupal/wordpress/… или «full stack web developer» где надо все тот же javascript + css пилить и при этом оплачивается хуже чем более интересные (в среднем) и сложные задачи, которые обычно решают на python.
  • –2
    Зашел на гугл тренды, сравнил языки программирования по рейтингам, зашел на сайт «поиска работы» => считаю что это очередной информационный выброс!!!
    • +3

      Держите нас в курсе ваших дальнейших исследований! :-)

      • –1
        Вот че сарказничать, я не понимаю?! Если я могу нормально написать оптимизированный код на PHP по сравнению со школьником который «на отвали» напишет такой же на Javascript или другом языке — то я считаю важным фактором наличие двух правых рук. Не говоря что кругом бенчмарки ( с предоставленным кодом, который каждый может попробовать проверить на своей машине!!! ) рисуют что php 7 выигрывает у Node.js. Знаете, мне кажется автор (не автор перевода) поленился реально сопоставить факты аналитики. И я больше верю своим глазам, я вижу что PHP востребователен. Зачем вообще каждый раз устраивают войну между языками?! Если не нравится PHP дак не пиши, может просто только ты на нем плохо пишешь. Не преходят ведь такие масштабные проекты как FB, VK на другие, а модернизируют компилятор!!!
        • +2
          Ну как не «сарказничать» в комментах под статьей, которая один больший сарказм )
    • +1
      image
  • 0

    А как же конверторы, простите транслитераторы из пхп в джиэс?

  • –3
    Есть две вещи важных вещи Иисус и нода и то можно на ноду солиться…
  • 0
    С нодой и фронтом сейчас твориться то что было с ПХП со времен с IE5.5 по IE8. Где во времена второй половины IE6 начали появляться фреймворки и начало всё устаканиваться. Сейчас всё только на фреймворках.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.