Вступление


Для начала расскажу одну историю, которая будет знакома, возможно, большинству из тусовки хаба «PHP».

Будучи школьником, ты играл в GTA Vice City и CS 1.6 в компьютерных клубах в начале за 8, потом за 10 рублей в час (60 ночь). Деньги раздобыть было не проблемой, можно всегда навешать лапши на уши родителям, что завтра нужно срочно сдать на ремонт школьного крыльца. Потом родители купили тебе собственный компьютер (для учебы, конечно же). Буквально за пару лет компьютеры появились в каждой семье и компьютерные залы закрылись. Кто-то продолжает и сейчас только играть за компьютером, но не ты. Ты пассионарен и сразу захотел написать свою игру, либо гайд на героя из Доты в формате HTML и JS, либо создать свой форум по играм и разместить там в футере рекламу.

В школе ты учился на «4», редко скатывался в тройки. Среди парней ты был вторым по успеваемости. Ты мог учиться и на 5ки, как те два парня на параллели, но сидеть 2 часа и зубрить отличия митоза от мейоза — задача непосильная, когда дома есть компьютер, а в нем — какой-то сериальчик или возможность попробовать разместить счетчик на своем сайте. Какое тебе дело до этого митоза? И вообще, ты не понимаешь, зачем начинать делать курсовую работу сейчас, когда можно за день до сдачи погуглить, скачать, ознакомиться и своими словами навешать лапши на уши учителю.

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

Вскоре ты уже являешься типичным представителем среднего класса. А те парни-отличники с твоей параллели получили два высших образования и теперь либо работают консультантом в разделе утюгов Эльдорадо, либо стали Java программистом и давно уехали в США, оставив Россию наедине с PHP.

Минусы PHP


Статья с содержанием «минусы PHP» выходит стабильно раз в год. Здесь не хочу снова мусолить темы, о которых все и так знают: нейминг SPL функций, нейминг операторов, неожиданное поведение функций, скорость выполнения сценариев. Все это мелочи, либо попытка вывести PHP вне своей весовой категории. Здесь я перечислю пару архитектурных минусов, чего не видел в других статьях, но это очень важно.

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

<?php

//Эталонный набор данных типа "массив" из главной палаты мер и весов
$array = [
	'foo' => 1,
]; 
//Эталонный набор данных типа "объект" из главной палаты мер и весов
$object = new stdClass; 
$object->foo = 1;

//Теперь создаем копию:
$arrayCopy = $array;
$objectCopy = $object;

//Подменяем данные:
$arrayCopy['foo'] = 2;
$objectCopy->foo = 2;

//Выведет 12
echo $array['foo'];
echo $object->foo;


Если вы попробуете изменить $objectCopy->foo, вы измените и $object->foo. А в случае с массивом, меняя foo в $arrayCopy, вы измените данные только в $arrayCopy, не касаясь $array.

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

2. Нестабильность архитектуры. В настоящий момент PHP разных версий похож на Perl, C++, Java. В каждом из перечисленных языков есть что-то свое, хорошее. Наверно, к этому хорошему стремились разработчики PHP, каждый раз поворачивая на 180 грудусов со своего пути. Наиболее эпичным стало добавление ООП в PHP, когда вода с низов давно утекла и утверждение «ООП — это когда все является объектом» к PHP применено быть уже не может, ведь в этом ЯП всё может является всем.

Если мы хотим хотябы на 99% объектно-ориентированный PHP проект, где мы будем «жестить» и наследовать низкоуровневые объекты типа «строка», нам придется делать некоторые страшные и глупые вещи, например:

<?php

class String {
	private $string;
	
	function __construct($string) {
		$this->string = $string;
	}
	
	function char($num) {
		$num = $num-1;
		//да-да, не удивляйтесь, мы используем метод объекта для возвращения символа строки как массива
		return $this->string[$num];
	}
}
//Выведем второй символ строки Hello World
echo (new String('Hello World'))->char(2);


Интересно, что мы не можем проверить тип $num в char ООП'шным способом: «function char(integer $num)», хотя этот integer в системе есть. Нам придется проверять тип функцией SPL, либо писать свой собственный class Integer, такой же как String.

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

3. Излишняя свобода. В PHP нестрогой является не только типизация. Тут вообще мир добра и единорогов. Можно взять и прямо в футере шаблона, посреди HTML кода, сделать подключение к базе и записать туда какие-то входящие от пользователя данные из глобальной переменной без экранирования. В других языках программирования за это светит синтаксическая ошибка. Но PHP создавался, как шаблонизатор и тянет за собой эту тяжелую ношу всю жизнь. Это является еще и плюсом.

Плюсы PHP


А теперь самое интересное. Перечислю конкретные плюсы PHP.

1. Мужественность. Я разрабатываю на PHP уже 10 лет. За это время мимо меня прошло куча модных альтернатив, типа Ruby (on rails) или NodeJS. У всех этих решений не было лишних конечностей или ампутированной головы, как у PHP. Но все они быстро приходили и куда-то уходили, оставив после себя кучу полуживых разрозненных островков готового кода. А PHP оставался и развивался, хоть и не в сторону усовершенствования языка. В итоге, мир получил мощную инфраструктуру веб-разработчика: любой маленький людишка может сесть за консоль и через Composer установить себе терабайт разных мелких и больших штучек под каждый чих.

2. Стабильность. PHP развивается, не отказываясь от прошлого. Это по-прежнему шаблонизатор, но в 2016 — еще и с надстроенными сверху этажами абстракции, которые по высоте обогнали все другие ЯП. Теперь на шаблонизаторе PHP может быть написан другой шаблонизатор, типа Smarty.

Недавно я встретил человека, который ушел из Java в PHP. Человек был вполне психически здоров, умен и востребован в мире Java. Тогда-то я и осознал, что архитектура в PHP на верхах уже очень хороша. И, что самое важное, в PHP уже можно писать все на верхах — о трудном детстве и деревянных игрушках PHP напоминают только разные странные операторы, ну и огромный костыль (или фишка) «магия» с этими нижними подчеркиваниями.

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

3. Сообщество хороших парней. Нам, высокопассионарным парням, которые в учебе не дотягивали до отличников, но умели быстро мобилизироваться и самообучаться, PHP очень помог стать человеком. Тогда, будучи школьником, я бы не смог преодолеть порог языка со строгой типизацией, даже с хорошим учителем (это скучно и сложно). Как итог — я бы не стал программистом, не писал бы сейчас эту статью. Возможно, пил бы водку с наркоманами и проститутками, грабил прохожих. Благодаря PHP, я смог сам себе навешать лапши на уши, убедить себя, что программирование — это просто и интересно, сделать первый шаг, простой шаг, без типизации и ООП. Деньги пришли сразу, а все остальное приходит позже, на практике.

Cпасибо, PHP!

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


  1. eee
    02.04.2016 13:27
    +8

    1. Отсутствие стандартизации на низком уровне

    В PHP 7 можно включить строгую проверку типов:
    <?php declare(strict_types = 1);
    1. Нестабильность архитектуры

    По мне так надуманная проблема. ООП ради ООП?
    1. Излишняя свобода.
      Можно взять и прямо в футере шаблона, посреди HTML кода, сделать подключение к базе и записать туда какие-то входящие от пользователя данные из глобальной переменной без экранирования.

    Плата за низкий порог вхождения. Да и другие языки позволяют такое делать. На PHP можно писать качественный код.
    В целом язык развивается. PHP 7 тому подтверждение.


    1. DrPass
      02.04.2016 13:42
      +10

      > Плата за низкий порог вхождения.
      Я никогда не понимал, почему отсутствие строгой типизации называют «платой за низкий порог вхождения». В первом случае надо всего лишь объяснить, что такое тип переменной. Во втором случае надо объяснять на пальцах, чем 2 отличается от «2», и потом мучительно долго вылавливать мелкие гадостные ошибки, где вместо 4 получается 22 (ладно, в случае PHP спасибо хоть на том, что конкатенация строк и сложение чисел обозначаются разными операторами). По-моему, нетипизированные языки придумали как раз ленивые матёрые программисты, чтобы им было меньше писать кода, а новички больше страдали :)


      1. eee
        02.04.2016 14:13
        +7

        Новичок будет страдать везде: и в строго-типизированных, и в не типизированных языках. Другое дело, когда новичок так и остается быдлокодить не понимая архитектуры языка.


        1. wordwild
          03.04.2016 09:44
          +2

          Но ведь работает же!!!


        1. Fesor
          03.04.2016 13:16
          +1

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

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


    1. bapewka
      03.04.2016 09:44
      -1

      declare(strict_types = 1);
      Работает только на тайп-хинтинг, то есть отключает приведение типов в аргументах функций.
      Такая каша всё равно допустима:
      print 1+1; // 2
      print 1+'1'; // 2


  1. lukdiman
    02.04.2016 13:49
    +50

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


    1. FForth
      02.04.2016 15:24
      +1

      А какие фреймворки предпочитают PHP программисты? Есть их рейтинг?


      1. lukdiman
        02.04.2016 15:45
        +3

        Буквально пару дней назад был пост про выбор фреймворка для PHP.


      1. Rastishka
        03.04.2016 01:01


    1. mafia8
      02.04.2016 15:24
      +4

      Это не приоритетная задача. (с) Т2.


    1. alexkunin
      02.04.2016 15:24
      +2

      Исповеди исповедями, а вот гугл на запрос «php производительность site:habrahabr.ru» (а также «site:geektimes.ru») выдет десятки релевантных ссылок. Некоторые в контексте фреймворков, да. По «zend engine site:habrahabr.ru» тоже немало (в основном про написание расширений, но есть и просто про внутренности движка).


    1. unStaiL
      03.04.2016 13:25

      Мне как то сказали, не важно какую технологию вы используете на своем проекте. Если вы можете быстро стартовать с RoR или Django то стартуйте с нее, если проект себя оправдает, вы всегда сможете переписать на более надежную и проверенную технологию, где как вы думаете, ваш проект будет проще масштабировать, поддерживать и т.д.


      1. heathen
        04.04.2016 19:10
        -1

        А вот это такой вопрос… неоднозначный. С одной стороны, согласен целиком и полностью. С другой — будет ли у вас время на переписывание, миграцию данных? Особенно при взрывном росте и появлении ста пятисот тысяч клонов? Вам нужно будет пилить новые штучки, а не переписывать движок. Конечно, если подобрать правильную архитектуру на старте, можно избежать многих косяков, но это уже отход от "быстро стартовать".


      1. Fesor
        04.04.2016 19:15
        +1

        вы всегда сможете переписать на более надежную и проверенную технологию

        Как круто живется в вашем розовом мире. В реальности никто в здравом уме не будет принимать решение "переписывать". Если это монолитное приложение — постепенно критические места будут выпилены как отдельные микросервисы и тогда уже можно их реализовать на чем-то другом. Либо проект просто будет постепенно перепиливаться целиком на микросервисы. Но переписывать именно никто не даст. Практика показывает что на крупных проектах монолитным остается где-то половина приложения, просто потому что там не важно.


  1. oxidmod
    02.04.2016 13:50
    +8

    >> Да-да, в PHP оператор присваивания "=" либо клонирует данные, либо передает их по ссылке в зависимости от того, данные какого типа следуют за оператором
    Это описано в документации. Объекты передаются по ссылке. Если хотите, то можно и массив и строку и число передать по ссылке. А можно объект скопировать, точней склонировать.

    >> Нам придется проверять тип функцией SPL
    а можно использовать php.net/manual/en/book.spl-types.php, если вам действительно нужно завернуть примитивы в объекты

    >> Излишняя свобода
    как и в реальном мире свобода сама по себе не является проблемой. Другое дело как Вы ею распорядитесь, но PHP тут ни при чем.


    1. gro
      02.04.2016 21:40
      -8

      Объекты не передаются по ссылке. Во всяком случае не так, как «по ссылке» подразумевается в мане.


      1. SerafimArts
        02.04.2016 23:09
        +1

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


        1. gro
          03.04.2016 00:04
          +3

          Мне не совсем понятны ваши пассажи про «узколобый мирок», но не будем.

          Термин «по ссылке» в PHP используется вместе с операцией "&" и как не спорить о терминах, за ним стоят совершенно другие механизмы, чем за передачем объектов.

          В первом случае ссылка между именами переменных, во втором между значениями. Ещё любят говорить «объекты передаются по значению, коим для них является ссылка на собственно объект».

          Если опять таки не холиварить о терминах, различия явно видны на примерах:

          $a = &$b;
          $b = 5; // $a тоже присваивается 5

          $a = $object;
          $object = 5; // $a не затрагивается. Оператор = рвёт связь между переменной obj и значением объекта


          1. oxidmod
            03.04.2016 00:23

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

            вот и вся разница. в пхп4 объекты присваивались как и примитивы, по значению, что приводило к ряду не совсем очевидных на тот момент проблем. тогда же появился &, который позволял передать любую переменную по ссылке. в пхп5 такая передача стала основной для объектов.


          1. SerafimArts
            03.04.2016 00:33
            +3

            Да, вы совершенно правы, есть такое. Прошу прощения за "пассаж". Это действительно может быть не очевидным для тех, кто перешёл с других языкв, слишком уж "замылилось" подобное поведение гуру-php, чтобы воспринимать его как нечто необычное.


          1. Fesor
            03.04.2016 01:00

            Так, давайте упростим. Представим себе что переменные всегда хранят ТОЛЬКО значения. И есть такой вариант значения как ссылка. Ссылку можно получить явно:

            $foo = &$bar; // тут явно мы берем ссылку на $bar и присваиваем ее $foo

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

            А теперь задумаемся почему объекты всегда передаются по ссылке (во всяком случае со времен php 5.0, в php4 объекты передавались по значению, потому что по сути это были тупые структуры данных). У объектов внутри могут быть зависимости, какое-то состояние, циклические ссылки на другие объекты. И на любой чих копировать все это несколько сложно. В итоге во всех языках программирования это решили отдать на откуп разработчикам, мол "вот тебе чувак clone и делай как хочешь".


            1. MacIn
              03.04.2016 01:02

              Необязательно; есть же С++ со своим "конструктором копирования". Который реализован по умолчанию как бинарная копия 1 в 1.


        1. MacIn
          03.04.2016 00:39

          В ряде сообществ некоторых языков сложилась своя терминология.
          В частности, в том же С++ "передача по ссылке" — это, внезапно, не то же самое, что и "передача через указатель". Отсюда иногда происходят тонны батхерта и непонимания, когда общаются люди из разных "миров".


          1. Fesor
            03.04.2016 01:01

            Потому что ссылка это не указатель.


            1. MacIn
              03.04.2016 01:04

              facepalm. Вы приводите статью "Ссылка (C++)", при том что я ровно о том и сказал — что в С++ ссылка — это не указатель:

              в том же С++ «передача по ссылке» — это, внезапно, не то же самое, что и «передача через указатель».

              Как?


              1. Fesor
                03.04.2016 13:20

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


                1. MacIn
                  05.04.2016 02:36

                  Нет, вы сказали что они должны быть «то же самое»

                  Это ложь.
                  Я сказал, что у разных языков разная терминология. И в ряде языков ссылка и указатель — это разные понятия. В частности, в С++.
                  Вот точная цитата, еще раз:
                  В ряде сообществ некоторых языков сложилась своя терминология.
                  В частности, в том же С++ «передача по ссылке» — это, внезапно, не то же самое, что и «передача через указатель»

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


                  1. Fesor
                    05.04.2016 09:18
                    -1

                    Я возможно не так вас понял.

                    В частности, в том же С++ «передача по ссылке» — это, внезапно, не то же самое, что и «передача через указатель».

                    Меня смутило слово "внезапно". В PHP нет указателей, есть только ссылки. В C++ же есть ссылки и указатели, так что слово внезапно тут не подходит. Да и указатель это такое же значение как и ссылка.


                    1. MacIn
                      05.04.2016 21:04

                      «Внезапно» — это просто саркастический элемент, призванный отметить то, что некоторые люди не понимают того, что в некоторых языках (и в некоторый период времени) ссылка и указатель — синонимы, а в других — нет. «внезапно» для них.
                      Пассажи вида «передать по значению / ссылке» появились задолго до и PHP и C++.


      1. denis-n-ko
        03.04.2016 09:44

        А можете более детально развернуть мысль?


    1. Flex25
      05.04.2016 20:26
      +1

      >> Да-да, в PHP оператор присваивания "=" либо клонирует данные, либо передает их по ссылке в зависимости от того, данные какого типа следуют за оператором

      По поводу этого лишь добавлю, что в Java ситуация аналогична: примитивные типы присваиваются по значению, объекты — по ссылке. Так что не вижу повода для паники.


      1. pistol
        06.04.2016 05:31

        Речь шла про хранилища данных, типа массив и объект. Я не точно выразился в том абзаце.


        1. Fesor
          06.04.2016 10:37

          Массивы в php это такие же скалярные значения, как и строки. Объекты же не тупо хранилища даных, они должны предоставлять нам поведение, а внутреннее состояние — это детали реализации и мы не должны об этом думать.

          Для случаев с value object-тами, где копирование объектов по значению оправдано, была дискуссия на php-internals отностельно недавно, но я не смог ее быстро найти. Предлагалось либо ввести отдельный модификатор для класса либо вовсе ввести структуры данных по аналогии с C#.


          1. pistol
            06.04.2016 12:28

            Заменил в статье обычный объект на stdClass, чтобы было понятнее, о чем я говорю. Уже в нескольких проектах, где была конвертация массива в объект и обратно, начиналась наркомания на определенной фазе жизни проекта. Программисту (особенно такому, кто работает не только с PHP) такое поведение неочевидно, сколько бы документации не держал он в голове.

            Буду очень благодарен, если найдете ту дискуссию, интересно :)


            1. Fesor
              06.04.2016 15:10

              вы можете заменить объект вашего типа на объект типа stdClass, разница не существенна. На данный момент все объекты передаются по ссылке. А массивы — не объекты.

              Ссылку поищу.


  1. RussianSpy
    02.04.2016 13:57
    +21

    Я бы не сказал, что Ruby и тем более node.js «куда-то уходили». Та же нода последние два года развивается очень активно. Безусловно, не без проблем. Ну, а у кого их нет?
    А вообще такое ощущение, что вы испытываете комплекс вины за то, что используете PHP.


    1. FranzK
      03.04.2016 09:44
      -2

      Высокопассионарный парень навешал лапши на уши


    1. 4unkur
      03.04.2016 09:44
      -2

      Тест


  1. NekitoSP
    02.04.2016 14:12
    +20

    Ностальгическая история про (до)школьное время и GTA:VC была, пожалуй, самой интересной частью статьи.


    1. Skull
      02.04.2016 14:47
      +4

      А дальше лучше и не читать. Что минусы высосаны из пальца, что плюсы с намеком что PHP язык для хорошистов, не то что Java!


      1. hmntnl
        03.04.2016 09:44

        с намеком что PHP язык для хорошистов
        Ага, а еще для «пассионариев». Хотя стремление к тому, чтобы было без всякой зауми, попроще-побыстрее- это все что угодно, но только не пассионарность. Для этого есть другое слово ;).


  1. schroeder
    02.04.2016 14:16
    +11

    Погуглил по "исповедь java программиста". Ничего не нагуглил. Господа пхпэшники, что с вами? Мыши плакали, кололись, но продолжали есть кактус?


    1. sayber
      02.04.2016 15:36
      +2

      Все просто.
      Многие разработчики упираются в определенный уровень знаний PHP и дальше не понимают как развиваться.
      Что то свое придумать не могут а изучить и использовать проф. инструменты не могут.
      Вот и начинают писать всякую ересь.


      1. atc
        03.04.2016 09:44
        +1

        А что вы подразумеваете под «проф. инструментами»?


        1. sayber
          03.04.2016 19:43

          Из банального — профессиональная готовка проектов на Symfony (не давний опрос показал, что более 70% разработчиков не осилили его)
          Столько же или больше разработчиков при работе с БД используют свои велосипеды и/или AR а когда смотрят в сторону data mapper, то хватаются за волосы и проходят мимо (doctrina, spot ...).

          Как выяснилось, с composer тоже мало кто дружит. Знают как добавить сторонний код и все.

          Я уже не говорю про сторонние разработки которые облегчают жизнь PHP программисту.
          Вообще тут можно писать очень долго и начать долгий спор.

          P.S.
          Еще есть такой слой ПхПешников, которые слыша вокруг — PHP плохой, это вообще не язык и т.д. — начинают ныть в унисон и стараться на что то пересесть.

          Сам работаю с PHP (15 лет), JS (серверный уровень), Go, Java


          1. atc
            03.04.2016 20:01

            Не со всем согласен, composer сейчас используется во всех современных фреймворках, а добавление кода из своих репозиториев\использование скриптов — совсем не редкость. По поводу сложности Data Mapper, кажется вы её слегка преувеличиваете, чаще всего достаточно внимательно прочитать документацию и написать несколько конфигов, в остальном оно не сложнее типичного AR из Laravel\Yii2.

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

            Не встречал таких, чаще всего стеб по поводу php слышу от людей, которые пробовали его либо слишком давно, либо на простых и примитивных задачах.
            PS: Вопрос по поводу Symfony, чем он примечателен на фоне zend\laravel\yii, раз вы его специально выделили в своем ответе?


            1. Fesor
              03.04.2016 22:37
              -2

              По поводу сложности Data Mapper, кажется вы её слегка преувеличиваете

              Если мы про доктрину, то data mapper это гдето 10% того что такое доктрина.
              в остальном оно не сложнее типичного AR из Laravel\Yii2.

              От часть да, но возможностей намного больше. Как и ограничений.
              Вопрос по поводу Symfony, чем он примечателен на фоне zend\laravel\yii,

              Ну вот Zend еще может потягаться с Symfony, а Laravel — это хороший фреймворк, но он хорош только для простых проектов. Хотя опять же, если для апишек, и заменить элоквент доктриной — все очень даже неплохо.

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


          1. webmoder
            04.04.2016 13:14

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


            1. VolCh
              04.04.2016 13:16

              Освоить, для начала, Symfony :)


              1. Fesor
                04.04.2016 13:19

                Я бы еще посоветовал учиться писать тесты и тестируемый код.


              1. Diden05
                06.04.2016 05:38

                Зачем? Почему именно Symfony, а не ZendFramework etc?
                То что знание Symphony для вас является признаком хорошего php программиста, ну это слабо мотивирует :)
                Коммент выше про тесты, мне кажется даже более актуальным. Код должен быть тестируемым.


                1. oxidmod
                  06.04.2016 09:16
                  +1

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


  1. shoomyst
    02.04.2016 14:21
    +2

    Куда Node уходит? В том же 2015 была такая движуха, что крышу сносило. Каждый день новый фремворк, как в PHP в лучшие времена :)
    Ruby действительно как-то потерялся, возможно просто страсти поутихли, и он занял свою нишу. В том же tiobe index у него неплохие позиции.
    Python как-то постабильнее


    1. Fedcomp
      02.04.2016 15:23
      +2

      не знаю куда ruby уходит, скоро rails 5 выходит, используемые лично мной гемы периодически обновляются. Это скорее стабильность.


      1. MartinX
        03.04.2016 09:44

        Ruby тихо сидит себе на рельсах, в других областях мало используется, в отличии от того же Java, Python, C++ (хоть его в статье упомянули, но целиком использовать для веб разработки ИМХО слишком, имеет смысл лишь какие-то алгоритмы выносить).


        1. googol
          03.04.2016 19:33

          Python сливается потихоньку, многие питонисты которых я знаю перешли на Go как основной язык для новых проектов.


          1. MartinX
            03.04.2016 19:37

            Да я бы так не сказал. Как бы не говорили, что Python/C/PHP/ect отмирают, но они живут (сужу по проектам и упоминанию).


          1. SowingSadness
            05.04.2016 12:43
            -1

            github.com/search?utf8=?&q=created%3A>%3D2014-01-01+created%3Ahttps://github.com/search?utf8=?&q=created%3A>%3D2015-01-01+created%3A


        1. sl_bug
          05.04.2016 09:01

          Sinatra, hanami — не только рельсами живет руби. Да и не только веб фреймворками (тот же менеджер пакетов для osx — homebrew).


      1. eoffsock
        03.04.2016 09:44

        Ruby и Rails просто перешли из разряда «хипста-игрушек» в разряд рабочих инструментов. Ну, тут конечно у всех свое мнение, но для меня это так.
        То есть тут нет необходимости уже как-то разжигать интерес: кому нужно, тот работает.


  1. akubintsev
    02.04.2016 14:45
    +13

    Вступление как-то мимо меня. Я школу покинул на рубеже нового тысячелетия, то есть вырос в «тяжелые 90-е», а компьютер был с 11 лет. Восторгов вокруг CS и GTA никогда не понимал. Деньги обманом не клянчил у родителей. Но что характерно, никогда в отличники не стремился. Так что да, 4-3 — характерно :)
    В компьютерные клубы ходил только потому что это было единственной доступной возможностью поиграть с кем-то по сетке в StarCraft или Quake.

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

    Комментарии про «минусы»:

    > 1. Отсутствие стандартизации на низком уровне.

    Просто надо почитывать changelog-и версий php. А то, что в js объекты тоже передаются по ссылке вы тоже не знали, js плохой?

    > 2. Нестабильность архитектуры

    Если приведенный пример иллюстрирует реальную проблему в решении поставленной перед программистом задачи, то наверное стоит использовать другой ЯП. Но назвать нестабильностью динамическую типизацию минусом — это странно как-то.

    А на счёт плюсов всё так. Я бы еще добавил то, что специалисты этого ЯП хорошо востребованы практически везде и оплачиваются достойно.


    1. MacIn
      03.04.2016 00:45

      А то, что в js объекты тоже передаются по ссылке вы тоже не знали, js плохой?

      И в С#, и в Delphi.


    1. Source
      03.04.2016 00:48

      Вы всерьёз приводите js в качестве примера языка, хорошо продуманного на низком уровне? JavaScript?
      Посмотрите хотя бы https://www.destroyallsoftware.com/talks/wat


      1. Fesor
        03.04.2016 01:04

        Это историческое наследие. посмотрите последние стандарты — они прекрасны. Хотя если так на PHP смотреть там тоже не так плохо. Я же все надеюсь на то что проект yay взлетит и это сильно ускорит развитие PHP.


        1. Source
          04.04.2016 01:49

          Да я ещё стандарт Javascript 2.0 помню, он тоже был неплох )
          Только от обратной совместимости они вряд ли откажутся, поэтому так и останется WAT на низком уровне.


          1. Fesor
            04.04.2016 10:10

            Вот честно, за 4 года работы с JS я ни разу не испытывал проблем с WAT. Это просто странности, в реальной жизни таких ситуаций практически не возникает. А потому можно.


            1. SerafimArts
              04.04.2016 10:48
              +2

              Ну раз пасуешь и не было проблем за 4 года с WAT — повбрасываю, с вашего позволения:

              ['1','2','3','4','5'].map(parseInt);

              Если знать что происходит — никакого WAT нет, но для неискушённой детской психики результат вывода может её травмировать.


              1. Fesor
                04.04.2016 12:56

                тут даже не WAT, тут банально здравый смысл. у praseInt как бы два аргумента, в чем тут WAT?

                ['1','2','3','4','5'].map(str => Number(str));


                1. Source
                  04.04.2016 16:29

                  WAT хотя бы в том, что функцию с одним или с двумя аргументами можно вызывать в качестве коллбека с 3-мя аргументами.
                  Если абстрагироваться от опыта работы с JS, то понятно, что это совсем неочевидное и даже нелогичное поведение.
                  Вы пишете "это просто странности", но когда осваиваешь несколько языков, понимаешь, что именно JS просто таки пропитан этими странностями.


                  1. Fesor
                    04.04.2016 16:40

                    функцию с одним или с двумя аргументами можно вызывать в качестве коллбека с 3-мя аргументами.

                    вообще-то так можно сделать в любом динамическом языке программирования, доступ то к аргументам всеравно есть (arguments в js, func_get_args в php и т.д.), variadic arguments и все такое. Скажем вот такой код:
                    function foo(a, ...b) {
                       // ...
                    }
                    
                    fo(1, 2, 3, 4, 5);

                    Это более чем нормально.


                    1. Source
                      05.04.2016 15:17

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


      1. herr_kaizer
        03.04.2016 15:21
        +1

        Скажите честно: какой из приведенных примеров может стать проблемой в реальной разработке?


        1. Source
          04.04.2016 01:54

          Любой. Или Вы считаете, что это всё выдуманные кейсы? Тогда ведь нет никакой проблемы в следующей версии стандарта кидать TypeError?
          Так нет же, эти извраты используются в куче уже написанного кода.


          1. herr_kaizer
            04.04.2016 08:51

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


            1. Source
              04.04.2016 10:55

              1) В крупных проектах существуют разные edge-кейсы, и там где по коду предполагалось сложить 2 массива, по факту может получиться, что оба массива оказались пустыми или вместо массива пришёл объект, и всё — получайте либо пустую строку, либо Object, либо 0. Т.е. даже если Вы явно не полагаетесь на WAT, то вполне можете получить трудные в отладке ошибки, связанные с таким поведением. А чтобы исправить подобные ошибки придётся в явном виде учитывать это неадекватное поведение.
              2) JavaScript — вообще источник несчётного количества WAT, вот для примера ещё несколько, как минимум 2 из которых часто используются и всё так же вызывают недоумение у людей, которые не съели собаку на странностях JS

              -new Date()
              0-new Date()
              +new Date()
              0+new Date()
              15/7|1
              15/7|0

              Можете, не выполняя код, сказать какой будет результат каждой строки?


              1. Fesor
                04.04.2016 13:01

                предполагалось сложить 2 массива

                arr = a.contact(b);

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

                Я знаю что такой код не пройдет код ревью. Достаточно знать что возвращает valueOf у даты и в каких случаях происходит каст к строке. А с побитовыми операциями надо просто знать приоритеты операторов. Я просто не позволяю двусмысленные операции в коде, все должно быть явно с одного прочтения.


                1. Source
                  04.04.2016 16:08

                  arr = a.contact(b);
                  т.е. продолжая мысль herr_kaizer: «никакому здравомыслящему человеку не придёт в голову складывать массивы с помощью оператора сложения, ведь это же JS»

                  Я знаю что такой код не пройдет код ревью.
                  Вы так это сказали, как-будто на code review есть стандарт и он гораздо лучше, чем стандарт на JavaScript :-)
                  А вообще изначальный тезис был в том, что не стоит упоминать JS в качестве языка, хорошо продуманного на низком уровне.
                  И то, что на нём можно писать понятный код, не отменяет тот факт, что можно писать и непонятный.
                  А продуманность языка как раз заключается в том, чтобы непонятный код не работал (не компилировался, сразу валился с TypeError и прочее).


                1. Source
                  04.04.2016 16:21

                  ну и, кстати, concat не особо уменьшает кол-во сюрпризов

                  // V8 version 4.9.385.28 [sample shell]
                  > [].concat([])
                  
                  > [].concat([]) == []
                  false
                  > a = [].concat({})
                  [object Object]
                  > a.concat([])
                  [object Object]


                  1. Fesor
                    04.04.2016 16:43

                    И все сюрпризы из-за того что люди не читают документацию?

                    valueN
                    Arrays and/or values to concatenate into a new array. See the description below for details.

                    так что приведенный вами код вполне себе валидный и логичный.
                    [].concat([], [1], 1, 'foo', {bar: 'bar'}); //[1 , 1, foo, object Object]


                    1. Source
                      05.04.2016 14:54
                      +1

                      Понимаете в чём дело, от того, что что-то описано в документации, это не становится логичным автоматически.
                      Добавление элемента в массив и конкатенация массивов — это 2 разных операции. И то, что concat делает и то и то, это нифига нелогично.

                      [1].concat([2, 3]) // => [1, 2, 3] //ok
                      [1].concat(2) // => [1, 2] // WAT?
                      

                      Хоть жирным капсом на главной странице документации об этом напиши, всё равно это останется WAT.
                      Попробуйте найти хотя бы 2-3 других ЯП, в которых добавление в массив и объединение массивов делается одинаково в рамках стандартной библиотеки.


          1. Fesor
            04.04.2016 10:11

            Вообще-то да, это вполне себе выдуманные кейсы.


    1. RomanPyr
      03.04.2016 19:27

      Достаточно вспомнить мысль, что каждый ЯП выполняет свой спектр задач.

      Писать шаблоны HTML-страниц?


  1. M-A-X
    02.04.2016 14:57
    -7

    Бред :)


  1. michael_vostrikov
    02.04.2016 15:00
    +3

    Если вы попробуете изменить $objectCopy->foo, вы измените и $object->foo

    Как вы лихо записали документированное поведение в архитектурные минусы и отсутствие стандартизации) Не говоря уже о том, что такое поведение есть и в других языках.

    Если мы хотим хотя бы на 99% объектно-ориентированный PHP проект, где мы будем «жестить» и наследовать низкоуровневые объекты типа «строка», нам придется делать некоторые страшные и глупые вещи

    В C++, представьте себе, вообще нет встроенного типа для строк, и там точно также надо писать свой класс (либо использовать готовый). C++ из-за этого не объектно-ориентированный?

    Интересно, что мы не можем проверить тип $num в char ООП'шным способом

    Каким образом проверка типов связана с ООП?

    В других языках программирования за это светит синтаксическая ошибка

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


    1. grossws
      02.04.2016 15:57

      В C++, представьте себе, вообще нет встроенного типа для строк, и там точно также надо писать свой класс (либо использовать готовый). C++ из-за этого не объектно-ориентированный?

      А чем вам std::string в качестве стандартного типа строк не угодил?


      1. michael_vostrikov
        02.04.2016 17:37

        Я имел в виду, что он не поддерживается на уровне языка, как например char и int. Это отдельно написанный класс с исходным кодом на этом языке, аналогично примеру из статьи.


    1. pistol
      03.04.2016 10:10

      "Не говоря уже о том, что такое поведение есть и в других языках." в каких, например? Обычно везде массив тоже является объектом.


      1. michael_vostrikov
        03.04.2016 11:21
        +1

        Эм, то есть вы ожидали не что объект скопируется, а что исходный массив будет присвоен по ссылке и изменится? Ну извините, из вашей заключительной фразы "Да-да, в PHP оператор присваивания "=" либо клонирует данные, либо передает их по ссылке в зависимости от того, данные какого типа следуют за оператором" это не очень непонятно. Потому что например скалярные типы и константы по ссылке не передаются, и складывается впечатление (и судя по комментам, не у меня одного), что у вас вызывает удивление поведение объектов при присваивании. В любом случае, присваивание массивов по значению это тоже документированное поведение.


        1. pistol
          03.04.2016 13:18
          -1

          Я ожидал, что массив и объект ведут себя одинаково (не важно, клонируются или по по ссылке передаются). Так это работает во всех других языках, которые я ковырял.
          Согласен, не совсем ясно и четко выразил мысль в статье.


  1. boodda
    02.04.2016 15:06
    +3

    по-моему автор не совсем понял, что же такое ооп, оно вообще не про типы


    1. coh
      02.04.2016 15:18
      +4

      Судя по предыдущему посту про битрикс автор не в ту сторону PHP ушел.


  1. psrafo
    02.04.2016 15:21
    +5

    Ага, только вместо "ты" должно было быть написано "я".


  1. alex1covo
    02.04.2016 15:26
    -1

    Весь цимес написан в конце статьи в самом последнем абзаце. Согласен на 100% Добавлю, что ко всему прочему пхп является языком для веб разработки, что на мой скромный взгляд является мейнстримом. 10 лет назад это не было так очевидно и можно было запросто свернуть в сторону скажем делфи и стать не веб, а прикладным программистом. Поэтому спасибо пхп!


  1. Naymen
    02.04.2016 15:26
    -11

    Я всегда вспоминаю доклад Сергея Рыжикова, который создал компанию 1С-Битрикс и активно внедряет PHP в государственные структуры.
    И вот он как раз и говорит, почему многие перестали писать на Java и других языках программирования.
    Все потому-что, PHP проще всех развернуть на любом компьютере или сервере. Вам все лишь останется открыть браузер и заходить в свое приложение из любой точки мира и с любого устройства.
    Люди давно стремятся придумать универсальный язык, который подходил бы всем и на нем можно было легко написать.
    Я считаю PHP идеальный вариант. Он прост в изучении и написать простой сайт нам нем не проблема.
    Если бы PHP изучали со школы, то у нас была бы армия программистов с кучей сайтов и веб-приложений :)
    Ссылка на его доклад: www.youtube.com/watch?v=x7HWRTbHgAU


    1. Naymen
      02.04.2016 22:12
      -1

      Почему минусы, что я не так написал?


      1. SerafimArts
        02.04.2016 23:13
        +13

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


        1. Naymen
          02.04.2016 23:30
          +1

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


          1. boodda
            04.04.2016 10:52
            +1

            Давно уже не идеальный ?

            Это вы сейчас про "Битрикс"?
            К этому УГ продукту, можно разные эпитеты придумать, но "не идельный". Это…
            Laravel 5 не идеальный, Symfony 2/3 не идельный, а Битрикс — это ад для программиста и рай для маркетолога.


    1. roswell
      03.04.2016 09:44

      В фидах с Upwork-а ежедневно встречается как минимум пара-тройка десятков (ежедневно, десятков, Карл!) задач на тему «My Wordpress (Joomla, etc) is hacked, need this fixed ASAP». Так что всё это было бы забавно и даже интересно, если не было настолько печально.


  1. Blumfontein
    02.04.2016 15:39
    -5

    Для языка, ориентированного на веб, нестрогая динамическая типизация — очень удобно. Попробуйте распарсить json на PHP и на java.


    1. lukdiman
      02.04.2016 20:56
      +1

      А в чем проблема распарсить на java?


      1. Fesor
        03.04.2016 01:05

        Ну скажем так, не так удобно с этим работать. В Java намного удобнее мэпить json на объекты определенного типа а не генерить все рефлексией.


      1. Blumfontein
        03.04.2016 08:07

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


        1. lukdiman
          03.04.2016 10:34
          +3

          Добавляете в classpath любую библиотеку, которая работает с json и будет вам в одну строчку и парсинг и мапинг на объект. Может в php это встроено в язык, но по сути это одно и тоже. Я могу даже сделать, чтобы эта библиотека всегда была доступна. Только зачем. Не всегда нужен парсинг json в java. А самое главное я могу не видеть json, а просто посмотреть в существующем коде на что мапится этот json и понять какие данные содержатся в нем. Это очень упрощает понимание людям, которые этот код не писали.


          1. Blumfontein
            03.04.2016 12:40

            >> Добавляете в classpath любую библиотеку, которая работает с json и будет вам в одну строчку и парсинг и мапинг на объект

            Ну тут вы слукавили. В одну строчку не получится, потому что объект, на который вы маппите, писать тоже надо как бы. Ну и от библиотеки зависит: а вдруг у вас в json придет невалидный тип данных в какое-то поле, скажем «1234» вместо 1234, вот уже и exception хандлеры пишем.


            1. lukdiman
              03.04.2016 13:46
              +1

              Уж лучше exception, чем невалидные данные. Я узнаю об этом сразу и если это json из внешней системы, то я просто говорю им, что они сами дураки, что присылают мне невалидные данные. Можно вообще заюзать json schema или xsd написать для xml. И будет вполне себе понятный exception о том, что данные не по схеме. Или вы предпочитаете распарсить кое как, а потом где-то в коде будут валится странные ошибки из-за того что json или xml у вас не той структуры или невалидные данные. А хуже если и вообще валиться ничего не будет, а будет передаваться null куда-то, потому что php позволил хранить любую структуру, даже если она вообще не соответствует вашим нуждам.


              1. Blumfontein
                03.04.2016 16:28

                >> Уж лучше exception, чем невалидные данные.

                Стоп, стоп, валидацию никто не отменял. Валидировать данные мы и на PHP будем. Но и на джаве, написать объект для маппинга — это еще не валидация. В итоге полноценная валидация будет что там, что там. Но при этом в PHP строку json преобразовать в структуру, с которой можно работать можно за 11 символов независимо от размера json-a (json_decode), тогда как в языках со статической типизацией символов потребуется гораздо больше в силу этой самой статической типизации.


                1. solver
                  03.04.2016 19:08
                  -1

                  Сразу видно PHP-шников, никогда в глаза не видевших нормальных языков)
                  И о статической типизации имеющих весьма посредственное представление.

                  >Но при этом в PHP строку json преобразовать в структуру, с которой можно работать

                  Вот пример из мира статической Java. Дает структуру с которой можно работать, в одну строку.

                  Map map = mapper.readValue(json, new TypeReference<Map<String, Object>>());

                  Даст хешмапу с данными. Работай сколько влезет.


                  1. atc
                    03.04.2016 20:06

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


                    1. solver
                      04.04.2016 00:25
                      +1

                      Т.е. в PHP за этой одной строчкой ничего не стоит? Серьезно?

                      P.S. Уже даже не смешно такую чушь читать. А потом еще удивляются, чего это о ПХП-шниках многие так плохо отзываются…


                      1. atc
                        04.04.2016 00:42

                        Вероятно вы недостаточно внимательно читали ответ выше, там было что-то о простоте реализации данной функциональности в условиях динамической типизации.
                        Попробуйте поискать что-то вроде https://github.com/FasterXML/jackson-databind для php, все найденные пакеты будут на порядок проще, а чаще всего — совсем не нужны, в силу элементарности реализации.
                        PS: сколько у вас java опыта и когда вы в последний раз серьезно использовали php?


                      1. Fesor
                        04.04.2016 00:47

                        Т.е. в PHP за этой одной строчкой ничего не стоит? Серьезно?

                        В целом для разработчика — ничего, все из коробки. Если же нам нужен честный мэппинг json на объекты то уже ставим пакет и тогда процесс с java не особо различается.
                        Основной холивар тут — статические структуры vs динамические. По моим наблюдениям джависты не особо любят возиться с последними, ибо возможность представить все в виде кэшмэп не очень то устраивает людей. Взять хотя бы такой простенький json:
                        {
                            "foo": "string",
                            "bar: false,
                            "date": "2016-01-01T23:28:56.782Z"
                        }

                        Я не хочу для него заводить объект, но и хэшмэпа мне уже неудобно. Как быть?


                  1. Blumfontein
                    04.04.2016 08:12

                    >> Map map = mapper.readValue(json, new TypeReference<Map<String, Object>>());

                    А что если у вас в Object будет еще один json?


          1. Fesor
            03.04.2016 14:48

            и будет вам в одну строчку и парсинг и мапинг на объект.

            Если мы говорим о сериалайзерах/мэпперах, в PHP тоже все это есть на уровне сторонних библиотек (symfony/serializer как пример).

            Но суть то в том что бы сделать так:
            $data = json_encode($request->getContent()); // динамическая структурка
            $errors = $this->validator->validate($data, [
                'name' => new Assert\NotBlank(),
                'email' => new Assert\Email(),
                'date' => new Assert\Date('iso8601'),
            ]);
            if (empty($errors)) {
                throw InvalidRequest::fromValidationErrors($errors);
            }

            Ну то есть исключение это хорошо, но я хотел бы еще на клиенте получить список того что пошло не так. Скажем я не очень уверен можно ли красиво и понятно в jsonschema описать что даты надо присылать исключительно в iso8601 и т.д.

            А если именно мэппинг интересует...
            $data = $this->serializer->deserialize($request->getContent(), Person::class, $request->getFormat());


            1. lukdiman
              03.04.2016 15:01

              Я не спорю что в php такое есть. Речь шла о том что в java так нельзя. Я написал что можно.


              1. Fesor
                03.04.2016 16:10

                Я написал что можно.

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


            1. genom_by
              05.04.2016 10:57

              не совсем понял ваш пример >>
              if (empty($errors)) {
              throw InvalidRequest::fromValidationErrors($errors);
              }
              выбрасывать исключение когда нет ошибок?


              1. Fesor
                05.04.2016 11:26

                опечатался, там должно быть !empty.


        1. impwx
          04.04.2016 11:36

          В C# есть ключевое слово dynamic, которое позволяет работать с объектами "вслепую", как в PHP или JS. Распарсить Json можно в одну строчку:

          dynamic value = JObject.Parse("{number:1000, str:'string', array: [1,2,3,4,5,6]}");

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


          1. Blumfontein
            04.04.2016 17:26

            https://habrahabr.ru/post/280730/#comment_8837332


            1. impwx
              04.04.2016 17:51

              Я читал ваш комментарий, но речь не про валидацию. На выходе из json_decode получаем ассоциативный массив, либо объект (что в php практически одно и то же), и с ключами этого массива придется работать, как со строками. Из этого — сразу целый ворох неприятных моментов:

              • Можно банально опечататься в одном из мест и заметить не сразу
              • IDE будет очень сложно/невозможно вывести адекватные подсказки
              • Рефакторинг также невозможен

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


              1. VolCh
                05.04.2016 09:40
                +1

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


            1. Fesor
              04.04.2016 18:30

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


        1. molchanoviv
          04.04.2016 13:14

          Я ниразу не джавист, но даже я знаю как сделать это в одну строчку.
          gson.fromJson(jsonString, JsonObject.class)


          1. Blumfontein
            04.04.2016 17:19

            Так нет же. JsonObject.class Пушкин писать будет? Или сам собой волшебным образом появится?


            1. molchanoviv
              04.04.2016 17:28

              он уже есть. его не надо писать


              1. Blumfontein
                04.04.2016 17:41

                Можно ссылочку на описание этого класса? Или вы про org.json.JSONObject? Его нельзя использовать в таком контексте, насколько я знаю.



    1. gtkuler
      03.04.2016 09:44
      +1

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


  1. zim32
    02.04.2016 16:09
    +1

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


    1. yvm
      02.04.2016 16:37
      +8

      Я сама пэхапэшница. Дочь сисопа. Просто поверьте, — у нас не все так однозначно… Никто не хочет писать чистый код!


      1. zim32
        02.04.2016 16:47
        +5

        Думаете если у вас заменили бы пхп на к примеру питон, все стало бы по-другому?


        1. slonopotamus
          02.04.2016 19:43

          Конечно, нет. Потому что эти языки ничем существенным друг от друга не отличаются.


          1. VolCh
            04.04.2016 10:08

            В Питоне строгая типизация.


          1. Fesor
            04.04.2016 10:13

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


            1. slonopotamus
              04.04.2016 16:14

              Я не приравнивал джаву к хаскелю. Я приравнивал php к питону (и ruby с perl'ом в ту же кучу). Между ними есть небольшие различия, но они ничтожны между пропастью, которая лежит между любым из этих языков и каким-нибудь C или Prolog.


              1. Fesor
                04.04.2016 17:47
                +1

                небольшие различия

                То есть полностю различающиеся объектная модель, система типов и т.д. это "небольшие различия"? Ну ладно тогда.


  1. SuperKozel
    02.04.2016 16:20
    +2

    а вот и нет! У меня был свой проводной интернет с локалкой и я рубал в CS 1.3-1.6 сидя дома с фпс 1-5 кадров в секунду


  1. Fesor
    02.04.2016 17:40
    +6

    Отсутствие стандартизации на низком уровне.

    PHP — язык со слабой динамической типизацией. Важный момент, существует слабая и сильная система типов. Например в python и ruby — сильная динамическая. А строгий/не строший — это уже вольности перевода.

    Станадртизация на низком уровне есть, просто появилась она всего-то лет так 7 назад, и искоренить просчеты при проектировании языка, накопленные за десятилетие существоания, при наличии миллиарддов и миллиардов строк легаси кода написанного на PHP — задача не из простых.

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


    в высоконагруженных сложных системах, где типизация крайне важна

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

    В любом случае, есть php7, там тайпхинтинг покрывает значительную долю этих ошибок. В php 7.1 появятся (надеюсь) typed properties, и возможно к версии 7.2 подвезут дженерики, и тогда тайпхинтинг будет полностью обеспечит предсказуемость системы типов PHP. В целом же PHP в этом плане постепенно растет, просто слишком много кода на эти фичи завязаны, потому переход будет очень долгим. Скорее всего мы придем к тому, как строгая динамическая типизация реализована в hack.


    Если вы попробуете изменить $objectCopy->foo, вы измените и $object->foo. А в случае с массивом, меняя foo в $arrayCopy, вы измените данные только в $arrayCopy, не касаясь $array.

    Ну то есть тот факт что массивы всегда передаются по значению а объекты — по ссылке вас не смущает? То есть массив — это просто значение. Когда мы просто сделали переменную $arrayCopy мы сделали переменную со ссылкой на массив, а при записи срабатывает copy-on-wirte и массив явно копируется перед изменением. Объекты передаются по ссылке не только в PHP, но и в Python, Ruby и практически во всех языках. Что бы передать объект по значению нужно явно произвести копирование. Есть правда исключения вроде data-only классов в kotlin и т.д. Что-то подобное недавно обсуждалось в php-internals.

    Так что сидушку стоит тушить от того что к работе в сложной системе допускают людей, которые не разобрались с основными концепциями языка программирования, который они используют каждый день.
    Наиболее эпичным стало добавление ООП в PHP, когда вода с низов давно утекла и утверждение «ООП — это когда все является объектом»

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

    Я подозреваю что вы просто не знаете зачем нужно ООП на самом деле. То что внутри объектов — не столь важно сколько взаимодействие оных.
    Я разрабатываю на PHP уже 10 лет.

    Чисто для статистики… Вы пишите тесты? Как часто? Сколько у вас было максимум тест кейсов на одном проекте?
    Сообщество хороших парней.

    Отсутствие культуры разработки. Собственно ваши минусы — это следствие культуры разработки. Типизация — решается тестами + тайп хинтингом. Архитектура — решается банально архитектурой, то есть от PHP тут ничего не зависит, объектную модель слизанную у java/c# оно вам предоставляет и ок. А плюсы… ну они из пальца высосаты. Единственный плюс PHP — это то что можно не замарачиваться в большинстве случаев по поводу побочных эффектов. PHP отработал, почистил за нас все, и это позволяет писать страшнейший но работающий говнокод. Это его плюс и одновременно минус, поскольку первые два-три года похапэшники просто говнокодят, пока что-нибудь не случается в их головах.


  1. Old_Chroft
    02.04.2016 17:48
    +6

    нам придется делать некоторые страшные и глупые вещи
    //Выведем второй символ строки Hello World
    echo (new String('Hello World'))->char(2);

    На самом деле — страшно и глупо.
    
    // возьмем набор данных типа "строка" из главной палаты мер и весов
    $str = 'Hello World';
    // воспользуемся ЗАДОКУМЕНТИРОВАННЫМИ возможностями языка "типизация"
    echo $str[1]; // Да, строка в PHP - это еще и массив символов
    
    Не надо ругать молоток за то, что он попал не по гвоздю, а по пальцу.


    1. Akhristenko
      03.04.2016 09:42
      +1

      К сожалению это работает только для однобайтных кодировок, так как строка в php это массив байтов, а не символов.


      1. Old_Chroft
        03.04.2016 15:57

        Пример из статьи, который я вынес в цитату — делает ровно тоже самое:

        function char($num) {
        $num = $num-1;
        //да-да, не удивляйтесь, мы используем метод объекта для возвращения символа строки как массива
        return $this->string[$num];
        }
        Своим комментарием я хотел выказать удивление: зачем автор нагородил целый класс для того, чтобы обращаться к символу "по номеру", а не "по индексу"? Какие-то трудности со счетом от нуля?
        А вот кодировки — другой разговор, и это на самом деле не выдуманная проблема. Насколько я помню, PHP-6 как раз из за трудностей с кодировками и бросили.


        1. shoomyst
          03.04.2016 17:13

          Только автор может легко добавить поддержку юникода, а вам придется бегать по всему проекту и городить костыли.
          PS. Я не очень вникал в предмет спора, просто 5 копеек почему в этом случае ооп-обертка может быть полезна


        1. pistol
          03.04.2016 18:29
          +1

          Я нагородил целый класс, чтобы в будущем его можно было унаследовать, взаимодействовать с другими классами. Чтобы у нас был объект, а не "не пойми что".


          1. boodda
            04.04.2016 10:57

            но зачем ?


            1. pistol
              04.04.2016 13:16

              Чтобы можно было подменить этот самый ->char в каких-то ситуациях. Редко, но это бывает нужно и на низком уровне. Это я назвал "жестить" в статье.


              1. boodda
                04.04.2016 21:05
                +1

                чем вас функция не устроила, зачем на все лепить объекты ?


                1. pistol
                  05.04.2016 07:57

                  Либо вопрос глупый, либо я его не понимаю :) Потому что хочу ООП и на верхнем и на нижнем уровне.


                  1. zhigalin
                    05.04.2016 13:07

                    А ЗАЧЕМ это вам?


                    1. pistol
                      05.04.2016 13:12

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


                      1. Fesor
                        05.04.2016 14:24
                        +1

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


                        1. pistol
                          05.04.2016 14:43

                          Я знаю, что такое ООП ради ООП :) И видел кучу ужасных проектов, где не используется $this вообще, но все на классах.


                          1. Fesor
                            06.04.2016 10:41

                            Это уже процедурщина, а не ООП.


    1. my_lord
      03.04.2016 09:42

      Особенно тем, кто не читал инструкции к молотку ))


  1. cyber-security
    02.04.2016 19:04
    -3

    image


  1. dim_s
    02.04.2016 21:19
    +1

    Все перечисленные минусы в PHP есть в других языках. Слабая типизация? Она достаточно комфортная и предсказуемая, но не строгая, слабая типизация не должна быть строгой, она должна быть предсказуемой, а в php она более предсказуемая чем например в JS.
    Другой минус, который описан в статье, это ООП. Да ладно, далеко не во всех языках все является объектом! В той же Java и C#.
    Излишняя свобода? Тоже сомнительный минус, во многих шаблонизаторах на других языках есть возможность исполнять любой код, можно и базу дергать из шаблона если передать нужный объект.
    P.S. Не нужно перед кем-то оправдываться, что вы пишите на PHP, все эти холивары языковые бессмысленная трата времени и сил.


    1. Veikedo
      03.04.2016 09:42
      -2

      В c# (да, наверное, и в java) всё является объектом.
      А вот копируется ли объект или только ссылка на него (при передаче/присвоении) это другое дело.


      1. grossws
        04.04.2016 00:52
        +1

        Расскажите это примитивам. И там, и там они есть.


        1. Veikedo
          04.04.2016 07:29
          -2

          То, что тип "примитивный" не делает его не объектом.
          Можете объяснить, как отличить примитивный тип от непримитивного?
          В C# "примитивный" int (Int32) является экземпляром System.Int32.
          Никто не мешает мне написать:
          Int32 i = new Int32();
          или
          Console.Write(457.ToString())


          1. Veikedo
            04.04.2016 07:45

            Я не учёл unsafe код и интерфейсы. Действительно не всё является объектом


          1. grossws
            04.04.2016 13:08
            +1

            С шарпом и CLR не знаком, поэтому скажу за JVM. Примитив хранится как примитивное значение на стеке jvm (byte, char, short, int, float — 4 байта, long и double — 8), не имеет методов и внутренней структуры.

            А объект располагается в куче (на стеке или в полях других объектов хранится указатель размером 4 байта на 32bit/64bit+CompressedOOPS, 8 байт на 64bit без компрессии указателей). По указателю на объект лежит сложная структура, состоящая из заголовка объекта и его содержимого.

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

            В частности, примитивы не имеют методов (т. к. не имеют vtable), но может выполняться прозрачный боксинг в объекты-обёртки, который дают примитивам набор методов (например, в scala это так). В java автоматический боксинг происходит при работе с коллекциями из java.util.collection и подобными, т. к. эти коллекции хранят только объекты.

            В scala пошли другим путём и коллекции примитивов могут существовать (если на классе коллекции есть аннотация @specialized, которая указывает компилятору на необходимость генерации набора реализаций под примитивы).


  1. gro
    02.04.2016 21:46
    +4

    в функциональных языках не все сущности являются функциями.
    в процедурных не все процедурами.
    почему в ООП обязательно сто процентов должно быть объектами?


    1. MacIn
      03.04.2016 00:58

      почему в ООП обязательно сто процентов должно быть объектами?

      Как с этим в Java?


      1. grossws
        03.04.2016 02:44
        +1

        Кроме объектов есть примитивы (char, byte, short, int, long, float, double).


        1. MacIn
          03.04.2016 03:35

          Нет, это само собой, я о методах/процедурах.


          1. grossws
            03.04.2016 08:34
            +1

            Это приводит к активному использованию static-методов и static initializer'ов, да.

            Если же говорить за примитивы, то в том же ruby или smalltalk'е они просто отсутствуют. Ещё более чистые ОО-языки, нежели java.

            В scala эти же примитивы не выглядят таковыми за счёт наличия implicit class'ов в predef, которые добавляют большое количество методов к этим "объектам". Плюс они могут использоваться в качестве generic-параметров. Для тех же коллекций крайне удобно (плюс, в отличии от явы, легко сгенерировать специализированные под примитивы коллекции с помощью стандартной аннотации @specialized)


            1. MacIn
              05.04.2016 02:40

              Ещё более чистые ОО-языки, нежели java.

              Да, я согласен. Просто Java используется для обучения программированию, например, в ВУЗах, и у подхода "только хардкор, только ООП" ноги растут, втч и отсюда.


              1. grossws
                05.04.2016 09:59

                Это где как. У нас Си был, но вполне допустимо было использовать плюсы.


                1. MacIn
                  05.04.2016 17:49

                  Разумеется. В моем ВУЗе у нас был Паскаль в первом семестре, потом объектный Паскаль во втором семестре и С++ в третьем. Но ты было давно, уж почти 10 лет как, а сейчас с первого на Java сажают.


              1. Fesor
                05.04.2016 10:07

                У нас был C# и javascript, как попытка ознакомить студентов с разными объектными моделями. Но сути это не меняет, из 100-ни студентов что такое инкапсуляция знали все, а вот понимание оной — ну хорошо если 10 человек додумались. Это как бы и не требовалось. И различные принципы вроде SOLID давали мельком сильно позже, и то типа в порядке факультатива. А про GRASP вообще никогда никто не говорит.

                А без понимание что такое инкапсуляция, полиморфизм, из которых все эти принципы вылазят, какой толк от такого ООП? А ведь могло бы быть все чуть подругому.


                1. MacIn
                  05.04.2016 17:51

                  А без понимание что такое инкапсуляция, полиморфизм, из которых все эти принципы вылазят, какой толк от такого ООП?

                  Нам давали понятие ООП во втором семестре, с контрольными и прочими прелестями. Вроде все усваивали. Ну, из тех, кто программировать вообще мог — как и в других местах, были люди, которые пошли на эту специальность из-за «моды».
                  Но поскольку мы проходили втч и через чисто процедурную методологию, нет стремления использовать ООП ради ООП. А вот у тех, кого учат сегодня, начиная с Java, с этим иначе.


  1. Prapor
    02.04.2016 22:09
    +2

    Пока все остальные решали как лучше делать, PHP решал проблемы.
    ЗЫ.
    Всё остальное, попытка оправдать почему PHP смог, а они нет.


  1. dmandreev
    02.04.2016 23:35

    программирование — это просто и интересно


  1. KpuTuK
    03.04.2016 09:43
    +1

    Имя класса/интерфейса PHP 5.0.0
    array PHP 5.1.0
    callable PHP 5.4.0
    bool, float, int, string PHP 7.0.0
    wiki.php.net/rfc/typed-properties
    Типизация семимильными шагами входит в php


  1. LexaZ
    03.04.2016 09:43
    +2

    Отсутствие стандартизации на низком уровне
    дочитал до этой фразы. дальше читать уже не надо. все ясно-понятно. пишите сайты на с++ и другим советуйте.


  1. andrievski88
    03.04.2016 09:43

    Вопрос, скорее к автору:
    – Сейчас реально пройти путь, который вы начали 10 лет назад начиная с все того же PHP?


    1. pistol
      03.04.2016 09:43

      Конечно :)


  1. vasac
    03.04.2016 09:43

    каждый раз поворачивая на 180 грудусов со своего пути.
    какие 180? как раз относительная стабильность и плавность одно из немногих его преимуществ.
    по сравнению с JS, где как только ты наконец смог осилить какую-нибудь самую супер-пупер мейнстримовую штучку, как оказывается она уже давно устарела и теперь в тренде другая супер-пупер-мега-штучка-пердучка. Правда на гитхабе уже и для неё есть пятьдесят конкурентов непонятно от кого, которые обязательно сделают её устаревшей уже завтра.
    или с питоном, где уже скоро десятый год, как на 3-ю версию перейти не могут.


  1. Misanthropist
    03.04.2016 09:43

    В целом, кроме пункта о присваивании и передаче по ссылке, согласен; но(!) документацию никто не отменял. Периодически нахожу там (в документации) очень интересные вещи. Поэтому, обычно, мне трудно ответить на вопрос: чтобы вы хотели добавить в PHP: думаю — скажу, а это там уже есть.
    Несомненный плюс PHP — низкий порог вхождения. В универе я начинал с C, а уже в 27 — начать разработку на Python было сложновато. И это ЯП с достаточно высоким порогом входа. А вот PHP пришелся как раз кстати.


  1. andrievski88
    03.04.2016 09:55

    Ответьте человеку, который только начал изучать PHP, что менее печально из двух зол:

    1. Игнорировать все холивары на тему это лучше, а это хуже, постигая все сугубо на практике и набивая 100500 шишек.
    2. Читать 100500 тем с холиварами в надежде найти истину и понять, что лучше, а что хуже.
      P.S. Вариант три, забить на 1 и 2 и просто учить язык с практикой и нужной литературой.
      ???


    1. pistol
      03.04.2016 10:21

      Учи PHP и все, он сейчас очень хорош с хорошим фреймворком. Раньше, выучив PHP, было нефиг делать на других языках, сейчас ситуация выровнялась.


      1. andrievski88
        03.04.2016 10:45
        -1

        Я уже года два клепаю разные "говно сайтики" на free cms и понимаю, чтобы с него (говна) соскочить, надо знать PHP и JS. Начал с PHP. И мне реально это нравится. Я даже забил на все игрухи, которые пожирали невероятно много времени.


    1. coh
      03.04.2016 10:25

      Не читайте холивары, читайте исходники современных гигантов типа Zend, YII, Doctrine, итп. Изучайте архитектуру, приемы программирования.


    1. KpuTuK
      03.04.2016 12:55

      п1 и п3 поглядывая время от времени в п2.


    1. Fesor
      03.04.2016 13:28

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

      В любом случае я рекомендую вам, если вы хотите развиваться, выучить еще один два языка, желательно не java/c#, то есть использующие совершенно другую объектую модель или фундаментально отличные от пыха идеи (python, ruby, javascript, rust, Clojure). Просто что бы знать что можно делать дела подругому. При этом не нужно бросать PHP.


  1. MartinX
    03.04.2016 14:42
    +1

    Я не могу сказать, что PHP дико плохой язык, но костыльность и сохранение старья в нем есть. По факту начинал свой путь в программировании с Delphi, но очень быстро перебросился на PHP (веб все же нужен был мне). По началу это удобно, типизация не парит, можно в процедурном стиле писать.
    Но со временем понимаешь, что не все в нем удобно для больших проектов. Да и вообще функции стандартной библиотеки (те же строковые) не имеют общего стиля именования, что неудобно (хотя IDE все решает, но без нее приходится подглядывать в документацию). Нестрогая типизация начинает тоже мешать, как и стиль работы PHP: "отработать любой ценой скрипт и умереть".
    ООП в нем есть, но язык не является полностью ООПшным. Это просто придаток, которым можно не пользоваться. В отличии от того же C#, Ruby, которые являются полностью ООП языками. Что бесит — это исключения есть, но стандартные функции почти ими не пользуются. Надо городить свои костыли над error_handler.
    Что язык являлся шаблонизатором — это да. Но по факту решается тем, что в начале файла просто стоит <?php. Хотелось бы в будущих версиях иметь опцию отключения такой вот возможности смешивания HTML с кодом. Хотя это имеет плюсы, что шаблонизатор не нужен или довольно удобно транслировать шаблоны в PHP-мешанину.
    Хоть мне и нравится тот же Python и большие проекты на нем удобнее писать. Как и библиотеки намного понятнее (смотрел Symfony2, но это какой-то академический монстр. та же Django более лаконичная. как и многие другие библиотеки в Python — есть она одна и хорошо выполняет свои функции). Однако же для каких-то простых целей (вроде накидать форму обратной связи) не будешь тащить весь стек другого языка. PHP есть везде и пишется это за пару минут.
    То же самое с популярными CMS. PHP есть везде, разработчиков много, порог вхождения низкий, все прекрасно создается. Однако CMS — это тоже отдельная тема. Большинство тоже застряли во временах PHP4, написаны по большей части в процедурном стиле (к ООП лишь при необходимости прибегают), порой опять же та же мешанина из кода и разметки. Хоть они и работают на последних версиях PHP (но это чисто фиксы, тот же WordPress и php-fusion довольно жестоко написаны).
    Однако радует, что в последних версиях язык карабкается и улучшается, избавляется от всяких magic_quotes и safe_mode. Я бы не назвал NodeJS приходящей и уходящей платформой, она успешно используется. Среди таких языков я бы скорее выделил всякие Rust, Go, D и прочие, которые молодые, хотят потеснить C/C++, к которым относятся к опаской в серьезных проектах.
    И, кстати, JS тоже веселая штука. Возраст с PHP примерно одинаков. Однако имеется прототипная модель ООП, мешанина с object и array (с этой точки зрения в PHP рай), множество реализаций (разные JS движки у разных браузерах, разные версии используемых браузеров у пользователей. но это уже особенность среды исполнения так сказать, ибо серверная часть более контролируемая).


  1. xmeoff
    03.04.2016 19:07
    +2

    Впервые встречаю исповедь, написанную не от первого лица. Весьма оригинально, ничего не скажешь.
    Начинается вроде привычно (для исповеди): "Для начала расскажу одну историю...". А дальше идет что-то непонятное, то ли обвинение, то ли агитация. Но больше всего это напоминает вступление к рекламе ("Ты все еще молод и дерзок? Приходи к нам!"). Только вместо рекламы идет какое-то невнятное и скомканное описание минусов и плюсов PHP. Заголовки пунктов, не имеющие почти ничего общего с их содержанием. Как связаны динамическая типизация и стандартизация? (чего, кстати?) В минусах — нестабильность, в плюсах — (внезапно!) стабильность. Но что особенно доставило, так это мужественность:). Чего, кого? — языка, его создателей, разработчиков пишущих на нем, или, может, лично автора?


  1. onqu
    04.04.2016 04:48
    +3

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


  1. sl_bug
    05.04.2016 09:09

    1. Fesor
      06.04.2016 00:22

      Занятные видяшки. Спасибо.

      из них я могу сделать вывод что чувака смущает тот факт, что могут быть stateless-объекты, содержащие только поведение без состояния. Вот только он не учитывает в своих примерах зависимости и параметры. Допустим для Net::FTP нам нужны параметры подключения, которые по хорошему должны пробрасываться в конструктор объекта. Путь к файлу — по хорошему тоже (а еще лучше разделить эти методы на отдельные маленькие объекты-сервисы). У нас есть зависимость от FasterCSV. Ну и конечно же работа с транзакциями и т.д.

      Вывод — чувак умело скрывает тот факт, что помимо изоляции сайд эффектов ООП позволяет управлять зависимостями.

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


      1. MacIn
        06.04.2016 21:47

        Что вы подразумеваете под stateless объектом? Если мы создали объект, скажем, «connection» и инициализировали через конструктор его параметрами соединения — это stateless или нет?


        1. Fesor
          06.04.2016 22:11
          +1

          Для начала давайте условимся что понастоящему stateless вещей не бывает. Даже если мы возьмем любую чистую функцию — на каком-то уровне всегда будет состояние.

          Что до вашего примера, соединение с базой данных — это состояние. Так что объект вроде-бы stateful. Однако:

          function foo(Connection $connection) {
             // ...
          }
          


          тут мы понятия не имеем имеет ли объект типа `Connection` какое-либо состояние. Точнее даже, мы знаем что какое-то состояние у него есть, но какое — это детали реализации этого объекта. Скорее всего `Connection` это не конкретная реализация а лишь интерфейс. Соединение с базой? А друг там ленивая инициализация, и пока мы не дернем метод соединения не будет? А возможно это вообще фэйковая реализация, и она просто будет отдавать одинаковый результат на все вызовы.

          И в этом собственно весь смысл. Мы как пользователи этого объекта не должны париться о тех побочных эффектах, которые возникают внутри этого объекта. Этот объект должен хэндлить их за нас.

          А если же взять какой-нибудь сервисный объект, например, хэшер паролей, у какой-то из реализаций оного может попросту отсутствовать внутреннее состояние. Скажем внутри используетя старый добрый `password_hash` которому кроме аргумента метода больше ничего и не нужно. Никаких зависимости и никаких параметров. Но с точки зрения кода, который будет использовать этот объект, мы не будем об этом знать.


          1. VolCh
            08.04.2016 11:45

            Точнее даже, мы знаем что какое-то состояние у него есть, но какое — это детали реализации этого объекта.… Мы как пользователи этого объекта не должны париться о тех побочных эффектах, которые возникают внутри этого объекта. Этот объект должен хэндлить их за нас.


            Не совсем так. Контрактом объекта могут быть предусмотрены вполне конкретные состояния, доступные пользователю объекта, как для чтения (через какие-то срезы), так и для модификации (через какие-то команды), которые мы можем, а то и должны учитывать, и по другому некоторые вещи реализовать если и не невозможно, то весьма проблематично. Но хороший контракт объекта (включая, но не ограничиваясь чисто синтаксическими интерфейсами) максимально абстрагирует нас от того, как и где это состояние хранится в самом объекте, как обрабатывается, мы не имеем никакого доступу к самому состоянию, можем лишь получать какие-то его характеристики, и влиять на него, вызывая какие-то команды. Скажем, для объекта соединения с СУБД, мы можем указать кодировку символов наших последующих запросов и его ответов, мы знаем о таком состоянии объекта как «текущая кодировка», знаем как его узнать, знаем, что без нашего вмешательства она измениться не может, но понятия не имеем отдаёт ли объект команду СУБД по переводу кодировки один раз и запрашивает её когда нам нужна текущая, не храня её сам, или хранит и применяет при каждом вызове, а может хранит, но лишь в целях кэширования, чтобы не грузить СУБД запросами если нас заинтересует какая сейчас. Состояние объекта нам известно, мы можем его попытаться изменить, но не должны знать как оно реализовано. По крайней мере пока не столкнёмся с непредсказуемыми изменениями состояния (или отсутствия предсказуемых), нарушающими публичный контракт и не решим дебажить и патчить код объекта сами. А до тех пор у нас лишь абстракция реального состояния, реальной кодировки реального состояния реального соединения (как правило, какой-то переменной в процессе/потоке СУБД, может быть на другом конце мира) «все наши запросы интерпретируются в указанной нами ранее кодировки», кто, где и когда учитывает наше указание, нас не волнует, пока нет признаков, что не учитывает. Побочный эффект от указания кодировки не просто налицо, а он нам требуется, но мы не знаем и не должны знать при обычном использовании как именно этот эффект реализован.

            Собственно, можно сказать, что у хорошо инкапсулированного объекта мы, как правило, можем спокойно узнать некоторые аспекты его состояния, а некоторые даже пытаться менять, но не имеем доступа к полному состоянию напрямую и даже не должны знать не то, что как оно реализовано, а каково оно вообще, полное. Разработчик объекта дал нам публичные свойства и методы (или какую-нибудь их магическую имитацию) для получения и изменения тех аспектов реального состояния, которые нас должны интересовать, но это лишь абстрактная модель реального состояния для пользователей, то есть нас. Скажем, простая (вроде бы) коллекция, реализующая ArrayAccess, для нас выступает почти как обычный массив, но реально может хранить данные на другом конце света, причём без нашего ведома на сервере разработчика :)


  1. kai
    05.04.2016 23:36
    +1

    Забавная статья, но она не про PHP, а про неумение читать документацию.