Team Lead
0,0
рейтинг
18 апреля 2012 в 21:09

Разработка → Почему многие выбирают PHP

PHP*
Тут было задано много вопросов в одном топике, ответы на которые частично дали в другом.

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

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

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

Посмотрим, какие ответы дает PHP на типовые вопросы разработки веб-приложений, какой выбор вариантов ответов существует.

Вопрос (В): Сколько программистов могут сделать мне сайт?
Ответ (О): По запросу «резюме php» в Яндексе находится 28 млн. ответов, «резюме python» / «резюме ruby» — один миллион. Nuff said. Навскидку, в 30 раз больше PHP-разработчиков. Значит, и конкуренция среди них выше, и оплата труда разумнее, и найти легче.

Вопрос (В): Я хочу поднять сайт-визитку. Есть ли готовые движки?
Ответ (О): Да, сотни. Навскидку: Joomla, Drupal, ModX, Битрикс.

Вопрос (В): А если интернет-магазин?
Ответ (О): Нет проблем! Magento, PHPShop, osCommerce и т.д

Вопрос (В): Еще потребуется форум и блог.
Ответ (О): Wordpress для блогов, vBulletin/IPB для форумов.

Вопрос (В): А если небольшую социальную сеть с блогами, типа Хабра?
Ответ (О): Livestreet — лучший движок ИМХО. Вообще, очень крутой.

Вопрос (В): Так. Хочу Фейсбук, поеду зарабатывать свои первые миллиарды.
Ответ (О): Нет проблем. PHPfox — out of the box лицокнига движок.

Вопрос (В): Фух, вроде все проекты продумал, движки нашел. А как с хостингами?
Ответ (О): На любом хостинге стоит PHP+MySQL. Over 9000 их.

Вопрос (В): Хорошо. А если нужно доработать сайты?
Ответ (О): Нет проблем. Любые студии, фриланс-сайты. См. пункт про резюме программистов на PHP.

Вопрос (В): А как же с нагрузкой? Мой Фейсбук будут посещать много-много людей!
Ответ (О): Прекрасно. Вконтакте, Фейсбук, Викимедиа — отлично работают под нагрузками.

Вопрос (В): А мне что-то друг рассказывал, что вроде PHP это говно, а рулит Питон.
Ответ (О): Питон рулит, несомненно. В 28 раз меньше программистов, в 30 раз меньше готовых фреймворков, готовых движков единицы. Посчитать тебе, сколько будет стоить разработать твои проекты с нуля? — Давай. — $3,000,000 — Спасибо, окей, попробуем Питон в другой раз. Заряжай своей команде, будем делать.

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

Поэтому на данном моменте бизнес выбирает PHP. Как домохозяйки выбирают Windows. Большинство — оно не всегда право, конечно. Может я бы тоже хотел Н. в президенты, однако народ голосует за ВВП.
@Cord
карма
403,5
рейтинг 0,0
Team Lead
Реклама помогает поддерживать и развивать наши сервисы

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

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

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

  • +32
    в 30 раз меньше готовых фреймворков

    Количество — не значит качество. Не хочу обидеть PHP-фреймворки, сам с ними работаю. Но наличие некого мейнстрима не повредило бы
    Посмотреть на те же плагины для фреймворков, какой PHP-фреймворк сравниться по количеству гемами для рельсов?
    • +19
      Толку от этих гемов для рельсов, если нет нормальных готовых продуктов на них, или хостинг фиг найдешь. Если бы Ruby/Python был бы таким белым и пушистым он бы уже давно вытеснил PHP. А все эти рассуждения о красивости, мейнстримовости, для всяких языкодрочеров.

      Возьмем тот же упомянутый Битрикс, даже среди PHP программеров он считается сборником говнокода. И это как бы не мешает ему быть самой продаваемой коммерческой CMS в рунете…
      • +5
        во всем виноваты маркетологи :/
        • +64
          Скорее в этом виноваты программеры, которые вместо того, чтобы делать классный софт — пишут статьи о плохом php.
          • +5
            Самый разумный комментарий за последнюю неделю
          • –3
            Жаль, что голосовать не могу, но полностью поддерживаю!
            Хочу только добавить, мне кажется что, проблемы языка в первую очередь в его популярности. Будет питон или руби таким же популярным, и у них найдутся проблемы и ни чуть не лучше, чем у PHP.
            • +1
              Пожалуй, всё же лучше. Эти языки объективно более целостные.
        • 0
          И господство 1С в сфере учета. С Битриксом проще всего хоть как-то настроить интеграцию — не через ручной обмен в XML или CSV, а автоматизированный, по оригинальному и крайне изящному протоколу 1С.
          • +2
            > по оригинальному и крайне изящному протоколу 1С.
            > изящному
            > 1С

            image
            • 0
              Именно :)
      • 0
        хостингом для php можно считать любой сервер с настроенным apache + mod_php только потому, что у большинства php apps/frameworks нет другой стратегии деплоя кроме как «закачайте файлы на сервер по ftp»
        • +4
          Для этого ещё надо настроить ftp. :) Но вообще наличие стратегии «закачайте файлы на сервер по ftp» для подавляющего большинства php приложений — это плюс, и большой плюс.
          • 0
            системы контроля версий получается тоже херня — можно же раз в день в папочку бекапиться и все
            • –1
              Лучше раз в день бэкапиться, чем не бэкапиться вообще. И лучше деплоить по ftp, чем только удаленно работать.
    • +3
      Думаю мейнстрима, как во всех нормальных языках, не будет еще долго. Хотя, да, что-то начинает вырисовываться (сектор сайтов-визиток, я думаю, эта тенденция не затронет никогда).

      Но php-комьюнити есть какая-то мания, я бы даже сказал, религия велосипедостроения: «Зачем разбиваться в чужом коде, если я это могу написать и сам?! Свой код и лучше и ближе». В итоге имеем кривую, 100500-ю по счету реализацию своей cms, orm, mvc; но зато свою, родную. Которую через полтора-два года выкинут и перепишут заново. Или новая команда разработчиков (а чо, мы разбираться в этом говнокоде будем?), либо текущая, которая поняла, что их идеальное решение не такое уж и идеальное.

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

      Возьмем к примеру тот же symfony, как наиболее продвинутый фреймворк и посмотрим как в 2012м году программисты на php обрабатывают формы: опять работаем на уровне вычленяем данные из запроса, сами вставляем, сами валидируем. На два шага ушли от $_GET['someshit']. В том же java мире эту проблему давно уже решили, для примера отправляю в мануал по spring-framework.

      И если когда-то очень давно ничего кроме помойки в виде phpclasses не было, и такой подход был применим, то последние несколько лет эта практика не применима и ведет к тому, что более-мение адекватные специалисты понимают что они ошиблись с выбором языка. Не многим нравится по несколько раз писать одно и тоже
      • +2
        а вы symfony 2 смотрели и пробовали?
        • 0
          Как раз о ней и говорю. И смотрел, и прбовал
          • +2
            тогда может я не понял ваш комментарий, где в симфони нужно вычленять данные из запроса?
      • 0
        Возьмем к примеру тот же symfony, как наиболее продвинутый фреймворк

        Обычно свое мнение как-то выделяют, чтобы другим не казалось, что это аксиома.
        • –2
          Вы с этим не согласны? Тогда предлагайте свой вариант.
        • +3
          Обычно в комментариях пишут своё мнение, а «аксиомы» указывают со ссылками на авторитетные источники ;)
        • 0
          Расскажите мне о более продвинутом фреймворке, чем Symfony2.
          • 0
            Вам это сделают где-нибудь в «религиозных войнах», но не здесь и не я.
      • 0
        А выложите пожалуйста пример какой-либо несложной формы с валидацией, чтобы было с чем сравнивать?
    • +1
      Мейнстрим есть — это ZF. По популярности среди вакансий он первый, все остальные — примерно столько же в сумме(в порядке популярности: Yii, Kohana, Symfony, ...).
      • +1
        Symfony2 вродь попопулярнее будет сейчас, некий драйвер комьюнити.
        • 0
          По какой статистике она популярнее? Я — по вакансиям.
          • –1
            На гитхабе популярней (sf2, zf2), разработчики друпал 8 выбирали между этими двумя фреймворками и выбрали именно компоненты symfony 2 для ядра новой версии.
          • 0
            по статистике существующих библиотек/компонентом, которые безшовно вписываються в систему на базе конкретного фреймворка. вродь их еще называют «батарейки».

            как один из источников — knpbundles (1131 модуль). можно еще добавить packagist (около 1000 взаимозависимых компонентов) — инициативу единого инсталятора для php composer, некоего аналога ruby gems или python pip.
    • 0
      какой PHP-фреймворк сравниться по количеству гемами для рельсов?

      rubygems.org/ — 37 483 гема для Руби (сколько из них для подходят/используются для рельсов? не знаю)
      drupal.org/ — 15 583 модуля.
      Это, как минимум, «сравнимо». Количество гемов для языка общего назначения всего лишь вдвое больше количества модулей под одну CMS/CMF.
      • 0
        Мне интересен именно фреймворк, а не CMS. Как бы Drupal не был похож на обычный фреймворк, это все равно другое.
        • 0
          В данном случае — не другое. Потому что многие модули, такие как Views, CCK, Image являются именно «плагинами к фрэймворку». Иначе, я бы говорил о 20 000 дополнений к Вордпрессу ;).
          • +2
            А что общего у Друпала с фреймворком?
            • 0
              Общего больше, чем различий.
            • 0
              По сути все более-менее популярные CMS являются фреймворками с набором модулей, включая админку, заточенную на этот набор. Собственно потому они и популярны, что стандартное поведение можно изменить не лазя в код CMS, а перехватывая управление — чем не фреймворки?
              • 0
                MS Sharepoint тоже фреймворк? SaaS конструкторы сайтов? Там тоже есть наборы модулей и переопределение поведения. Это же есть, например, в ERP-системах.
                • 0
                  Про Sharepoint не знаю и за все конструкторы скажу, но которые встречал — нет, свой модуль, исполняемый на сервере и с доступом к среде выполнения самого конструктора не получить
            • 0
              Он позиционирует сябя как CMF (Content Management Framework).
      • 0
        Ну вы же сами понимаете, что друпал — это не самая лучшая система со стороны программиста, там даже ооп нету, причем я хочу заметить — я не фанат ооп, просто я видел как можно делать красиво расширения, и я видел как делают расширения на друпал — игнорирую какие-либо правила и шаблонизаторы ;)
        • –2
          Друпал — одна из лучших систем со стороны программиста. Если, конечно, правила, заложенные в саму систему не игнорировать.
          • +3
            Лучшая, это потому что поддерживает совместимость с php4? :)
            • +1
              Это вы на пару лет с этим вопросом опоздали. 5.2 — минимум.
              • +1
                ого, теперь осталось подождать лет 5 и друпал сможет поддерживать замыкания и неймспейсы? ;)
                • +1
                  Drupal 8 требует 5.3, наверное что-то из этого использует. Правда, неизвестно еще, когда он выйдет.
                  • 0
                    Главное чтобы не как Перл6
                  • 0
                    Я продолжу — все плагины, которые видел я даже не использовали шаблонизатора. Код друпала хоть на сколько-то покрыт тестами? Там их вообще пишет кто-нибудь?
                    • 0
                      Шаблонизатор не используется в CI, ZF, Wordpress… дальше продолжать?
                      Код ядра покрыт тестами.
                      • 0
                        К ZF он прикручивается с половины тычка. К CI чуть сложнее.
                        • 0
                          К Drupal, тоже прикручиваются с половины тычка. Просто в качестве «шаблонизатора по умолчанию» используется PHP.
                • 0
                  8-й использует Symfony Components, а значит использует нэймспэйсы, да и замыкания никто не запрещает использовать, как и ООП в 6-м.
                  • 0
                    Представил себе неймспейсы и ООП в сочетании с друпалевскими хуками

                    • 0
                      А что хуки? Какая разница функция в глобальном нэймспэйсе или метод в локольном?
          • +2
            Это в ней авторы принципиально пишут без ООП в 21 веке?
            • 0
              Писали когда-то.
          • 0
            Со стороны программиста — навряд ли. А вот со стороны человека не знающего программирования вообще — одна из лучших. Можно получить довольно сложный сайт, просто поклацав мышкой. Правда работать будет медленновато, за подобный функционал надо платить большим количством http- SQL-запросов. А с точки зрения программиста — система, мягко говоря, не идеал.
            • 0
              Вот это хороший комментарий :) Кстате говоря — я лично наблюдал работу самого высоконагруженного друпала в России ;) Который потом был переписан нами на рельсы. Со стороны юзера все очень удобно, поставил модули (через ssh, а не какой-то там удобный интерфейс, lol) и работай себе на здоровье :)

              Со стороны программиста это полный п. В стандартной поставке нет даже пакетного менеджера, я уж молчу про обновления :)
              • 0
                Ссылку в студию ;)
            • 0
              Я программист, мне нравится.
              А медленновато — это да. Правда, до ZF 2 далековато по тормознутости, но неправильной разработкой можно это исправить!
  • +63
    Автоваз — очень популярен, много запчастей, еще больше специалистов. Опять же — дешевле и ездит.
    • +1
      Согласен с вами. Будучи студентом, подрабатывал делая «сайты на заказ». Большинству заказчиков важным фактором была стоимость, получалось в пределах 200-300 долларов. Им все равно было что будет внутри, главное результат и удобный интерфейс. С моей же стороны нужно было вкладывать в это как можно меньше усилий. PHP с его огромным количеством готовых CMS и просто морем плагинов для них, прекрасно подходит. Лишь тем заказчикам, которым действительно нужно было что то хитрое, масштабируемое и с заделом на будущее, делалось на более серьезных штуках.
      • +7
        Будучи человеком знакомым с такими студентами, часто приходилось как-то модифицировать плагины для популярных cms под нужды заказчика, тк студенты были не в состоянии сами что-то сделать, но отлично находили клиентов. Так вот, на решение проблем заказчика используя рельсу/джангу и написание небольших сайтов уходило значительно меньше времени, чем сидеть и разбираться в говнокоде этих плагинов.
        • НЛО прилетело и опубликовало эту надпись здесь
          • +1
            ИМХО все эти допиливания CMS до нужного состояния — это костыль говнокодович.
            • НЛО прилетело и опубликовало эту надпись здесь
              • +2
                Если нужен постоянный допил, то я бы вообще никогда не делал ставку на готовую CMS. У любого решения есть предел расширяемости, и если у фреймворков он почти бесконечен (мы говорим о хороших фреймворках), то у CMS крайне ограничен. Конечно, в тех случаях, когда нужно только добавить пользователю новое поле и разместить на сайдбаре няшную штучку, смысла изобретать велосипед и переписывать вордпресс с нуля нет. Но когда из того же вордпресса пытаются сделать магазин, я хватаюсь за пистолет… Как было сказано выше и ниже, если появляется нужда в допиливании, задайтесь вопросом: а не быстрее ли написать нужный функционал на %frameworkname%?
                • НЛО прилетело и опубликовало эту надпись здесь
                  • 0
                    как-то категорично про вордпресс, который давно не только блог — тот блог с которого начиналось
                  • 0
                    Drupal, Wordpress и Joomla вполне себе полноценные CMS, просто в каждой из них прослеживается их родословная.
          • +1
            О том и речь, 99% заказчиков не требовали написать ещё один фэйсбук, либо новый хабр. Сайты были достаточно примитивными, магазины не требовали функционал, который предоставляет магента итп.
            На написание с нуля используя джангу уходило меньше времени, чем на использование цмски, плагин и попытки модификации плагина, которые превращались в кучу костылей.
            Но конечно же не надо забывать что примерно в половине случаев заказчика всё полностью устраивало после установки цмски и настройки пары плагинов, что даже не приходилось прикасаться к коду.
            Да, это всё из разряда создания «говно»-сайтов, но ведь речь ведь сейчас как раз про них, где нужно экономить на всём :)
            • НЛО прилетело и опубликовало эту надпись здесь
              • 0
                Ну тут больше суть не в технологиях, а в том что большинство этих сайтов делалось ради того чтобы он просто был. В случае с магазинами заказчики ожидали что вдруг откуда-то появится поток новых клиентов, не вкладывая никаких усилий в раскрутку. Если это была какая-то информационая площадка, то на контент и периодическое его обновление с таким же успехом забивалось. Вот что я имею в виду под говносайтами :)
    • 0
      Не поверите, но ГАЗели. Аккурат выбор небольшого бизнеса.
      • +1
        Охотно верю, просто тот факт, что большинство выбирает что-то не делает это что-то лучше остального(или хуже).
  • 0
    Глупо делать выводы на основе количества результатов в поисковой системе. По остальным пунктам вы назвали плюсы PHP, но не оценили его в сравнении с другими языками. Разумеется, у PHP есть плюсы, но какие-то плюсы есть у любого реального языка. Ничто не стало очевидным, вы ничего не доказали, вы просто постулируете свою точку зрения.
    • +1
      Увы, но иффиктиные манагеры именно так и думают, а решают, к сожалению, они!
  • +15
    Почему люди выбирали PHP?
    Возможно потому, что он понятнее, чем Perl, и потому, что писать на нем сайты проще, чем на C++.
    Все остальные языки 10 лет назад не имели достаточной аудитории, чтобы рассматривать их в качестве кандидатов для изучения с последующим применением к веб-разработке.
    А сейчас его выбирают, скорее всего, из-за того, что он доминирует на рынке.
    • +8
      Ну если Руби с гемами, или Питон с Джангой в 10 раз круче, и существуют в расцвете уже года три минимум (для широкой общественности), почему они не откусили рынок?

      Банальный пример. Был браузер, глючный, но лидер — IE. Потом его долю откусил ФФ.
      У ФФ была проблема (вроде починили — летает теперь) — утечка памяти, и с плугинами тупил.
      Вышел мегабыстрый Хром — и откусил долю ФФ.

      То есть хорошие вещи откусывают рынок быстро.

      А как это не печально, RoR и Python по совокупности ответов на вопросы -смотри пост — не откусили пока рынок.

      Но все возможно… Когда-то правила Альтависта, Яха, Лайкос и Хотбот, рулил Нетскейп, а Гуглеры были студентами-ботанами, работающими над диссером… А потом они запатентовали алгоритм со свистелками и перделками, и все заверте.
      • +1
        инстаграмм — миллиард. работает на джанге.
        пинтерест — хз сколько. на ней же. уверен, можно еще не один десяток примеров найти. видимо, мы по разному на этот рынок смотрим.
        • +6
          Инстаграм — это, как и Фэйсбук, исключение из правил. Нужно брать обычные веб-проекты.
      • –1
        хром откусил рынок своей огромной рекламой.
      • +3
        Руби — сложный язык. Намного сложнее питона и пхп. РоР — сложный фреймворк. За последние пару лет он стал очень newbie-unfriendly.

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

        У пхп по-прежнему самый низкий порог вхождения, что обеспеивает им постоянный приток студентов, делающих визитки за 300 долларов, а потом продолжающих писать на пхп, потому что «а что, нормальный язык, все работает вон».
        • НЛО прилетело и опубликовало эту надпись здесь
          • НЛО прилетело и опубликовало эту надпись здесь
            • НЛО прилетело и опубликовало эту надпись здесь
              • +1
                А если будут делать качественные сайты за 6000 рублей — это плохо? Если человек более опытен стал, овладел профессиональными инструментами и методиками, то производительность его труда должна возрасти и за тоже время он сделает больше. Почему вдруг за то, что «студент» делает за две недели и 6000, а профи за неделю нужно платить 12 000?

                Под качественным сайтом я имею в виду качественный код сайта, потому как дизайн и прочее юзабилити к компетенции php/python/ruby/… программиста не относится.
                • НЛО прилетело и опубликовало эту надпись здесь
                  • 0
                    Я как-то делаю один, умудряясь не выступать в роли дизайнера и юзабилиста. Бывает верстаю по макету, а чаще предлагаю на выбор из разных коллекций (в т.ч.платных). Хотя какие-то знания по веб-дизайну есть, но так, для общего развития. И вообще с трудом человека представляю, который сможет и качественный дизайн сделать, и качественный код написать — по-моему совершенно разные способы мышления нужны.
                    • НЛО прилетело и опубликовало эту надпись здесь
        • +1
          Руби никак нельзя назвать сложным языком. Приведите, пожалуйста, пример, в чем конткретно он «сложнее» как язык, чем пхп?
          RoR сложный фреймворк? Думаю, он попроще аналогичных фреймворков на пхп. У него отличная документация, есть масса статей и бесплатных скринкастов в интернете. Не знаю, что там unfriendly.
          Или вы сравниваете применение RoR с созданием пары тестовых php-страниц и запуском на денвере?
          • 0
            Куда чаще используется функциональная парадигма — проще от этого язык уж точно не становится.
          • +4
            Документация у RoR — говно. Об этом все коммьюнити ноет последние года полтора как. Райан Бигг вяло пытается ее как-то дописывать, но ему последнее время сильно не до этого, он занят книгой своей. Плюс, она написанна так, как хочет ДХХ, а кроме ДХХ так никто все равно не делает. Пример – Test::Unit. Я давненько не встречал проекта, тесты которого написанны на Test::Unit. В 99% случаев он сразу выкидывается и заменяется на RSspec.

            За примерами «сложности» языка далеко ходить не надо. Практически любой пример из середины и дальше книги Metaprogramming Ruby поставит в тупик среднестатистического разработчика. Мне самому потребовалось олоко двух лет чтобы по-настоящему разобраться и понять все тонкости, описанные в книге и реально начать ими пользоваться. И я по-прежнему иногда путаю instance_eval с class_eval.

            Да просто можно посмотреть внутрь того же RSpec. Врядли после этого повернется язык назвать руби простым.
          • +1
            Ну и плюс из коробки текущие рельсы ставят sass, coffeescript и asset_pipeline. Человек, который только что прочитал «Ruby для чайников», увидев все это, скорее всего крепко задумается и пойдет делать блог на вордпрессе.

            Я очень люблю sass, coffeescript и asset_pipeline. Они реально чудесные и повышают производительность программиста на отличненько. Но я уже много лет во всем этом варюсь и у меня была куча времени вникнуть в эти фичи. А новичок со знанием css/html/javascript/ruby скорее всего обломится.
            • +1
              Не знаю, чем так плоха документация рельсов. Документация по API отлично оформлена, есть очень удобный аякс-поиск. Еще есть отличные guides.rubyonrails.org/… Сообщество руби слишком любит поныть имхо.

              > А новичок со знанием css/html/javascript/ruby скорее всего обломится.
              Так никто же не запрещает использовать голые js/css в asset pipeline или вовсе забить на него и кидать файлы в public директорию.

              По поводу ваших аргументов про метапрограммирование — ну да, там все непросто, но это advanced фичи языка, и ими совершенно необязательно уметь пользоваться, чтобы писать веб-проекты. Я плохо знаю пхп, но подозреваю, что там большинство подобных вещей вообще сделать нельзя. Делает ли это пхп более простым языком? Возможно, но только в смысле количества функционала. Это не делает его более простым в изучении или применении.
        • 0
          Не такой уж сложный. Думаю сложнее настроить сервер под него. А для PHP под Windows есть Denwer и т.д. Скачал установил и начинай писать
          echo "Hello world";
          
      • 0
        Пример в корне неверен. ФФ и хром активно продвигаются в массы, Руби и Питон продвигать нафиг никому не сдалось. Да и как долго ФФ с Хромом что-то там себе отхватили? Еще несколько лет назад IE безраздельно властвовал на рынке, несмотря на давнее существование ФФ и Оперы. Пока, собственно, альтернативные браузеры не начали продвигать.
        Вот вам другой «банальный пример»: в мире существует Windows, Mac OS X и Ubuntu. И не смотря на то, что третья неплоха, а вторая прекрасна, с отрывом лидирует первая.
        • +1
          некому продвигать Руби и Питон?
          да я уже немогу без головной боли на хабр зайти, чтоб не наткнутся на какого нибудь «евангелиста»
          а год работы на роре у меня отбил все желание пересекаться с руби сообществом
          потому что такого агрессивного продвигания своих «правильных идей» надо поискать
          аллергию чес слово заработал
          • 0
            На то они и правильные идеи, чтобы их продвигали. В противном случае получим ситуацию, сложившуюся в PHP-сообществе, когда вставка html-кода в модель или контроллер является вполне обыденным явлением.
            • +1
              Покажите хоть один MVC фрэймворк, где такое происходит.
            • 0
              | В противном случае получим ситуацию, сложившуюся в PHP-сообществе, когда вставка html-кода в модель или контроллер является вполне обыденным явлением.

              где такое сложилось, я с такими не знаком :) а на основании кода видимого мной на роре я могу сделать такие же глобальные выводы :)

              | На то они и правильные идеи, чтобы их продвигали

              я не случайно поставил кавычки «правильные идеи» — потому что эти сообщества колеблятся с линией партии и то что превозносится ими как гениальное и единственно верное решение через пару лет ими же порицается а на пьедестал возносится что либо другое
              и я не люблю секты, но это личное :)
              • 0
                > где такое сложилось, я с такими не знаком :)
                Да вы счастливый человек!

                >я не случайно поставил кавычки «правильные идеи» — потому что эти сообщества колеблятся >с линией партии и то что превозносится ими как гениальное и единственно верное решение >через пару лет ими же порицается а на пьедестал возносится что либо другое

                Ммм… пример?
                • +2
                  > Да вы счастливый человек!
                  к сожалению не настолько, я видел такое в рор проекте :)

                  > Ммм… пример?
                  rjs -> cofeescript
                  erb -> haml
                  «а сейчас вышла новая версия рора которая встотыщь раз лучше всего остального, да кстати и предыдущей версии тоже, так что то что вы написали до этого можете выкинуть на помойку»
                  повальное использования орм

                  как то так
                  • 0
                    Пардон, но это бред)

                    > rjs -> cofeescript
                    Абсолютно разные вещи для разных нужд.

                    > erb -> haml
                    Официальный шаблонизатор рельсов все еще erb. Haml использую те, кому он нравится, так же как и scss, coffeescript, итд.

                    > «а сейчас вышла новая версия рора которая встотыщь раз лучше всего остального, да кстати и предыдущей версии тоже
                    Это настолько неестественно для PHP-сообщества, что новая версия лучше предыдущей? оО

                    > так что то что вы написали до этого можете выкинуть на помойку
                    Эмм… а вы точно с рельсами работали? Рельсы — это гем, который, как и все прочие, спокойно обновляется до последней версии. Более того — разработчики всегда выпускают инструкцию по переводу проекта на новые рельсы.
                    Сам имею проект, начавшийся на RC 3х рельсов и работающий сейчас на 3.2.

                    > повальное использования орм
                    Если вы хотите писать модели без использования AR — пишите. Но зачем?

                    Вы выглядите как слепой фанатик php, уж простите…
                    • +1
                      > Это настолько неестественно для PHP-сообщества, что новая версия лучше предыдущей? оО

                      неестественно что не поддерживается старая :)

                      > Эмм… а вы точно с рельсами работали? Рельсы — это гем, который, как и все прочие, спокойно обновляется до последней версии. Более того — разработчики всегда выпускают инструкцию по переводу проекта на новые рельсы.

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

                      > Если вы хотите писать модели без использования AR — пишите. Но зачем?
                      я использую актив рекорд :)
                      разница в терминологии, актив рекорд да, а повальное использование связей чтобы по аттрибуту конструктор сам сабирал джойны было тогда оч популярно

                      > Вы выглядите как слепой фанатик php, уж простите…
                      ну конешо давайте уже поговорим обо мне :) а почему вы решили что если я против навязывания руби/рор сообществ своих «идеалов» я фанатик php? :)
                      я антифанатик руби :)
                      а питоны, сишарпы, нод джи эсы да сколько угодно, раньше и руби но теперь аллергия :)
                      • 0
                        >неестественно что не поддерживается старая :)
                        К 3.0 и 3.1 выходят обновления. 2я версия да, устарела и не поддерживается. У всего есть свой период поддержки.

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

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

                        • 0
                          > К 3.0 и 3.1 выходят обновления. 2я версия да, устарела и не поддерживается. У всего есть свой период поддержки.

                          я имел ввиду что переход на новую версию настолько труден что выходом чаще остается только переписывание по новой. И насколько я понимаю 2 не поддерживает 1.2 а 3 не поддерживает 2? И каждая следущая настолько другая и лучше предыдущей что становится не понятно кому предыдущая нужна была в принципе :)

                          > Но подозреваю, что руки и нежелание.

                          полностью с вами согласен :) что плохие программисты есть везде

                          > И сейчас популярно. Это плохо — писать меньше кода?

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

                          хорошо писать понятный код :)
                          • 0
                            > я имел ввиду что переход на новую версию настолько труден что выходом чаще остается только переписывание по новой.
                            Это, мягко говор, неправда.

                            > И насколько я понимаю 2 не поддерживает 1.2 а 3 не поддерживает 2?
                            Вот эту фразу я не понял вообще.

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

                            > попробую на примере того самого большого рор проекта: были связаны
                            > все таблицы через модели. и указание аттрибута через точку влекло за
                            > собой выборку через три джойна этого аттрибута из четвертой таблицы
                            Бездумное использование предоставленных возможностей — беда не языка или фреймворка, а человека, использующего из.
                            А если конкретно по примеру, то для каждой ассоциации можно указывать свои SQL-запросы, коль уж не нравятся сгенерированные автоматом. И выглядеть будет красиво, и работать оптимально.
                    • 0
                      > Это настолько неестественно для PHP-сообщества, что новая версия лучше предыдущей?

                      «why switching from Ruby»
                      groups.google.com/forum/?fromgroups#!topic/urug/UZ8fDVcNiOA

                      1) Ruby version hell
                      2) Rails 3 also seems to be imploding on version — it requires at least 1.8.7 but wait, it crashes on the last few p releases
            • +1
              Вы хотите сказать, что в RoR нельзя вставить html в модель или контроллер?
      • 0
        Ну, одно дело — поменять браузер, другое — язык, на котором пишешь.
        • 0
          По-моему, C# неплохо так занял место под солнцем ;)
  • –27
    Вопросы которые вы привели — типичные для быдла, которое хочет тупо заработать бабла на чужой идее. Да — это работает, но только первый после *бога* получает такую возможность.
    Так вот, а что насчет новых, революционных проектов?
    Я к веб программированию не имею никакого отношения, просто мимопроходил.
    • +19
      Думаете человека который хочет сделать себе интернет-магазин волнует красота языка? Его интересуют в первую очередь сроки и цена разработки и поддержки, а какие там гемы бывают у руби ему пофиг.
      • –8
        Я вааще не об этом спрашивал. Может вы ошиблись веткой?
        • +4
          Ну это я к вопросам для быдла. Или вы своих заказчиков быдлом считаете, ну тогда ладно.
          • –6
            А где вы увидели, что я своих заказчиков быдлом считаю? Я спросил у вас — как обстоят дела у пхп с нестандартными проектами, но вы видимо не хотите отвечать на этот вопрос и уходите от ответа.
            • +12
              точно так же обстоят как у любых других языков.
              на пхп при должном умении можно реализовывать любые нестандартные проекты. так же как на руби, питоне, перле, си.
              • 0
                напишите простенький аналог erlyvideo или flumotion на php.
                • 0
                  PHP это язык для разработки веб-сайтов (PHP: hypertext preprocessor)

                  вполне очевидно, что на нем легко и удобно реализовывать любые стандартные (визитка, блог, форум) и нестандартные проекты, из области создания веб-сайтов

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

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

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

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

                      ответ: да, на нем можно делать нетиповые проекты, так же как на любрм другом языке. но не нужно пытаться домкратом накачать колесо
                      • 0
                        а в чём сложность с онлайн-трансляцией на сайте?

                        почему на erlang/python/java это можно сделать, а на php — «домкратом накачать колесов».

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

                        • 0
                          я же один раз уже вам ответил:
                          PHP: hypertext preprocessor.
                          это официальное название этого языка. еще раз: hypertext preprocessor.

                          в пхп нет сложности с онлайн-трансляцией на сайте, просто пхп будет генерировать хтмл-код сайта, отображать видео на клиенте будет флеш или сильверлайт или сам браузер в случае хтмл5, а отдавать контент с сервера будет апач или nginx или какое нибудь специализированное решение.

                          я тоже могу сказать «реализуйте видео-плеер для браузера на эрланге. почему на яве, экшнскрипте и сильверлайте это сделать можно, а на эрланге и питоне нельзя?».
                          • 0
                            >а отдавать контент с сервера будет апач или nginx или какое нибудь специализированное решение.

                            так почему эти «специализированные решения» на erlang/java/python пишут, а на php — нет?

                            вариантов относительно немного:

                            1)язык для этого не подходит(неудобен/противоречив/etc)
                            2)язык для этого не предназначен
                            3)сообщество программистов вокруг данного языка не в состоянии написать

                            Пытаясь защититься пунктом N2, вы сужаете пространство для поиска ответов на пункты N1 & N3.

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

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

                              почему люди не накачивают колеса домкратом?
                              вариантов немного:
                              1. им неудобно качать колеса
                              2. он для этого не предназначен
                              3. сообщество пользователей домкратов слишком слабо чтобы накачать им колесо.

                              прикрываясь пунктом 2 я пытаюсь закрыть глаза на пункты 1 и 3.
                              • +1
                                спасибо, поржалъ! 8))))

                                Но аналогия не верна, т.к вы путаете «не применим вообще» и «ограниченная область применения».

                                Если уж сравнивать компрессоры, то это:

                                «компрессор с питанием от электросети автомобиля или 220V с универсальным набором насадок и опций» vs «компрессор для автомобиля».

                                автомобильным, конечно, можно накачивать что-то отличное от колёс, да только не предназначен он.

                            • 0
                              4) написать можно, но плюсов по сравнению с существующими реализациями на других языках не будет.

                              У php в подобных случаях нет сильных сторон, из-за которых стоило бы использовать именного его. И одна откровенно слабая — нет многопоточности. Реализовать вроде можно, но сложно. А главное зачем?
                • +1
                  легко — есть такое. Пример: mark.koli.ch/2009/02/07/streamer.phps
            • +18
              Пишу последние годы на ПХП одни нестандартные проекты. Проблем нет вообще никаких. Полностью всего хватает с головой
              • 0
                А есть с чем сравнивать?
                • +2
                  Главный вопрос зачем? Лично мне производительность PHP вполне хватает. И я не думаю что другой интерпретируемый язык тут что-то поменял бы в корне. Если уж реально надо получить прирост скорости (5-10 раз) — тогда на джаву смотреть надо. Обычно так и делаем — самые нагруженные демоны выносим на джаву, все остальное — ПХП.
                  • 0
                    Преимущество других языков вовсе не в скорости. Математические расчеты на сайтах вы в больших количествах врядли проводите, а запросы к БД по большому счету безразлично на каком языке составлять.
                    Преимущество в удобстве разработки и поддержки.
                    • +6
                      Ну и в чем проблема. Я использую набор классов из Symfony2 для роутинга и валидации основанной на аннотациях, Twig шаблонизатор, Doctrine для ORM. Почему бытует такое мнение, что раз PHP то это сразу неудобно и говнокод сплошной?
                      • 0
                        В других языках может быть больше возможностей для сохранения результатов своей работы в виде библиотек за счет унификации понятий языка. В результате функций и классов больше область применения — не надо дублировать код.

                        Это играет тем большую роль, чем больше у вас своего кода.
                        • НЛО прилетело и опубликовало эту надпись здесь
                          • –6
                            Напишите на php такую функцию:

                            def make_list(xs):
                                return ''.join('<li>'+x+'</li>' for x in xs)
                            


                            Функция берет то, что можно перечислять, элементов чего является строка (может быть список, строка и т.д) и возвращает строку c элементами исходного объекта, обрамленными тегами li.

                            Пример:

                            print make_list('abc')
                            print make_list(['1', '2', '4'])
                            
                            Output: 
                            
                            <li>a</li><li>b</li><li>c</li>
                            <li>1</li><li>2</li><li>4</li>
                            
                            

                            • НЛО прилетело и опубликовало эту надпись здесь
                              • –2
                                ну вот это я и называю «приходится дублировать код»
                            • +6
                              return '<li>'.implode('</li><li>',$array).'</li>';
                              

                              Не?
                              • 0
                                cработает ли implode со строкой?
                                с множеством?
                                со множетсвом ключей dictionry?
                                со можеством его жлементов?
                                • +1
                                  Если вы подразумеваете, что нужно «проимплодить» каждый символ строки — нет. И, думаю, это не очевидное поведение.

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

                                  Если вы хотите какую-то более сложную структуру, можно создать класс-имплементацию итератора, который будет итерировать хоть по значениям, хоть по ключам, хоть по их сумме — всё зависит от того, что вы хотите сделать.
                                  • 0
                                    не является ли естественным, что строка — это массив символов?
                                    implode с этим итератором будет работать?
                                    • +1
                                      Является. Не очевидно, что при передачи строки «abc» в такую функцию в результате будет список из трёх элементов. Да, вы можете такое сделать, но поддерживать такое неочевидное поведение может потом оказаться накладно. в этом плане подход PHP мне больше импонирует — нужно сделать такую итерацию — лучше явно передать массив символов. если это часто используется — можно сделать класс, который умеет делать .toString() к той же самой строке, но за счёт имлементации итератора его можно использовать как аргумент подобной функции.
                                      • 0
                                        >>>Не очевидно, что при передачи строки «abc» в такую функцию в результате будет список из трёх элементов.

                                        Почему? Если вы согласились, что строка концептуально — массив символов, то почму передача такого массива в функцию, которая представляет последовательность в виде списка, не должна преставить эту конкретну последовательность в виде html списка? По-моему это логично, абстрактно и мощно
                                        • 0
                                          Это, конечно, мощно… Но часто ли используется, особенно в применении к Web? Так что не думаю что это хороший пример того, почему питон сильно лучше.
                                          • +1
                                            Я думаю, вы просто не смотрели пока на код с этой точки зрения — представьте себе что практически все функции, которые работают с массивами работают и со строками и с последовательностями сгенерированными ORM и другими вещами, которые можно представить как последовательность — и этих функций много (например см. модуль itertools)
                                    • +1
                                      Для PHP не является. Это скалярный тип прежде всего, который в некоторых ситуациях может работать как массив. Но не во всех. Далеко не во всех, прежде всего приведение (array)$str (как и любого другого скалярного типа) вернёт массив с одним элементом. Отсюда и пляшем при использовании.
                                • 0
                                  > cработает ли implode со строкой?

                                  Конкретно для вашего примера ваша функция получилась компактнее.
                                  А теперь представьте, что строку не нужно бить по символам.
                                  Как изменится код вашей функции?
                                  • 0
                                    тогда ей не нужно передавать строку, потому, что она работает со перечислениями.

                              • 0
                                Не.
                                С пустым array() будет
                                <li></li>
                              • 0
                                Не. Ответ не верен, если массив пуст.
                            • 0
                              function make_list($obj){
                              for($res = ''; $i=each($obj); $res.= "$i[1]");
                              return $res;
                              }
                              • 0
                                В документации по each написано что она работает только с массивами — join работает с iterable
                              • –1
                                Странная подсветка кода. Вообщем там $res = в li оборачивается. Будет работать с массивами и всем что реализует Iterator
                                • 0
                                  Странно, я не вижу в доке про iterator там явно написано array, но так как строка — не объект, ей потребуется особое приглашение?
                            • +1
                              А зачем вообще в коде генерировать html?
                              • 0
                                во-первых, это просто пример. Можно привести в пример itertools и functools как часть того, что можно сделать еще.

                                во-вторых, можно, например, генерировать интерфейс на основе общих правил, типа «html представление списка объектов — это html представление оъектов, заключенные в li». Чтобы не хардкодить каждую страничу по своему, грубо говоря (ну там придется не зардкодить это li, а обратиться к микрошаблону)
                            • +2
                              В лоб:
                              function make_list($xs) {
                                $result = '';
                                foreach ($xs as $x) {
                                  $result .= '<li>' . $x . '</li>';
                                }
                                return $result;
                              }
                              


                              Работает с тем, что можно перечислять: массивы, простые объекты (перечисление свойств) и объекты, реализующие интерфейс Iterator (коллекции, списки и т. п., включая стандартные вроде FilesystemIterator). Строки, увы, скалярный тип в PHP, неперечисляемый, хотя можно добавить
                              if (is_string($xs)) {
                                $xs = explode('', $xs);
                              }
                              

                              чтобы получить аналогичную функциональность.

                              Можно написать и в функциональном стиле, но для PHP это скорее извращение будет в данном случае.
                              • 0
                                Насколько я знаю, вы смотрели в сторону python и можете сами сравнить, насколько обобщенный код можно написать там и там — я php смотрел несколько лет назад и то, что я увидел, мне сильно не понравилось.
                                • 0
                                  Угу, смотрел, как и в сторону Ruby. Ни один из этих трёх языков не могу назвать идеальным для веба. Вот смешать бы их :)
                                  • 0
                                    А что вам нравится php как в языке (про дешевый хостинг и большую кодовую базу понятно)
                                    • 0
                                      Не совсем в языке — простота разворачивания и администрирования среды выполнения для типовых задач (под пакетными дистрами) прежде всего. Хотя, вроде, стало получше с этим у python и ruby в последнее время. Но пока для меня это главный плюс.

                                      Чисто как в языке — тесная интеграция с HTTP, включая сессии. По сути PHP является микрофреймворком для веба.
                                      • 0
                                        >>>Чисто как в языке — тесная интеграция с HTTP, включая сессии

                                        Нужно ли это прям в языке?
                                        • 0
                                          Не мешает при использовании не в вебе, помогает в вебе. Почему нет?
                                          • –2
                                            Помогает на одну конструкцию import или больше?
                                            • +1
                                              Больше, и даже несколько import аналогичной функциональности не дадут.
                                              • –1
                                                конечно не дадут аналогичной, ибо дадут БОЛЬШЕ и более качественной функциональности чем в PHP =)
                                                • 0
                                                  Хорошо, я поясню на примере Perl:

                                                  use Mojolicious::Lite
                                                  


                                                  И мы имеем мощнейший шаблонизатор позволяющий хранить шаблоны и в коде (отдельно от кода) и отдельными файлами, поддерживающий наследование, блоки, хелперы и.т.п.

                                                  Имеем очень лаконичный sinatra-подобный ДЕКЛАРАТИВНЫЙ роутер (этого в PHP из коробки нет), который поддерживает группы маршрутов, пре- пост- обработчики и.т.п., пример:
                                                    get '/hello/:name' => {name => 'Sebastian'} => sub {
                                                      my $self = shift;
                                                      $self->render('groovy', format => 'txt');
                                                    };
                                                  


                                                  Имеем объектно ориентированный способ работать с запросами и ответами, причём тоже очень краткие и лаконичные, например:

                                                  my $user_agent = $self->req->headers->user_agent;
                                                  


                                                  И обладает целым пакетом утилит для работы с web проектом и для работы с кодировками, даже есть полноценный клиент и парсер веб страниц (парсер позволяет парсить кусок html css-селекторами).

                                                  Поддерживает работу с вебсокетами.
                                                  Можно обрабатывать события разнообразные.
                                                  Есть поддержка для интернационализации.
                                                  Есть поддержка логгирования.

                                                  И имеет встроенный веб сервер.

                                                  Этот модуль не имеет внешних зависимостей и написан pure-Perl, то есть его можно переносить копированием папочки.

                                                  Чем стандартный PHP лучше? Какой ещё модуль надо подключить чтобы получить эту невероятную интеграцию с HTTP?

                                                  P.S. по сути это микрофреймворк, только его не надо настраивать и както определённым образом устанавливать — установил модуль, подключил одной строчкой и небольшой или средний сайт напишешь в очень короткие сроки.
                                                  • 0
                                                    use Mojolicious::Lite и всё? То есть это стандартная библиотека? Может и зря 10+ лет назад, выбирая между Perl и PHP, выбрал последний.

                                                    • 0
                                                      Нет это не стандартный модуль, но он легко устанавливается на любой системе с Perl (либо его можно тупо скопировать).

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

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

                                                      И о том: «и является ли интерграция PHP и HTTP конкурентным преимуществом на сегодняшний день?». Нет и из-за того что это встроено в язык, это ещё и отягчающим неудобством можно назвать.
                                                      • 0
                                                        В том-то и дело, что это не стандартный модуль. Нет, если его файлы можно скопировать куда-то в /var/www вместе с использующим его проектом, то часть проблем снимается. А если нужны права доступа вне /var/www, то это означает резкий уход с рынка веб-мастеров, не являющихся толком ни администраторами, ни программистами, и инструкция типа «этот каталог из архива разместите в ~/www, а этот — в /usr/local/lib или в другом на выбор и пропишите его в PATH» для них будет неподъёмна.

                                                        А в PHP взаимодействие с HTTP-запросами, взаимодействие с веб-сервером — это ядро языка (частично, а частично в либах в функциях вроде header()). Причём, на мой взгляд, это взаимодействие более функционально, чем в стандартных либах python и ruby.

                                                        А синатроподобные фреймворки с декларативным роутингом на PHP есть, даже в одном файле (правда phar):
                                                        require_once 'silex.phar'; 
                                                        
                                                        $app = new Silex\Application();
                                                        
                                                        $app->get('/hello/{name}', function($name) {
                                                            return "Hello $name";
                                                        });
                                                        
                                                        $app->run(); 
                                                        


                                                        И объектные обвязки для HTTP тоже есть там.

                                                        PS А сейчас perl-приложения деплоятся также как 10+лет назад — копируются в /var/www/cgi-bin и работают по cgi, или есть модули типа mod_php, или запускаются как демон?
                                                        • 0
                                                          Его можно скопировать в папку с проектом и всё будет работать.

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

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

                                                          Сайты на Perl (да и для PHP) у меня работают через FastCGI. Деплою и то и другое я тупо git'ом, ибо это удобно. Так что здесь какого-то преимущества у PHP я не вижу.
                                                          • 0
                                                            Так для PHP тоже куча фреймворков, которые инкапсулируют запросы и ответы с постоянно модернизируемыми интерфейсами. Но если возникает желание или необходимость писать без фреймворков и сторонних либ, то в PHP они есть в ядре, а в других языках нет, в лучшем случае надо стандартные либы подключать, в худших — сокеты слушать. Грубо говоря, есть встроенный в ядро уровень абстракции выше чем raw http, пользоваться им или использовать более высокоуровневые (свои или чужие) — выбор исполнителя и заказчика.

                                                            К слову, работу с HTTP и сессиями я обернул в классы как только стал доступен широко на хостингах PHP4 (мой мозг безнадежно, наверное, испорчен «Си с классами», ещё Фортом немного, но это не мэйнстрим и проявляется редко). Почему-то ждал, что в сначала 5.0, а потом в 6.0 это сделают разработчики PHP. Но у них другие приоритеты, видимо :( Восторга от PHP не испытываю давно (после выхода из эйфории по поводу появления ООП в PHP4), просто рабочий инструмент, который изменяется, не всегда однозначно хорошо, вернее почти всегда в духе php — говорят «а», но не говорят «б», например:
                                                            — вводят ООП, но подавляющее большинство библиотеки — процедурные, про «всё — объект» вообще молчу
                                                            — вводя нэймспэйсы, но стандартные библиотеки по ним не распихивают
                                                            — вводят type hinting, но не для скалярных типов и возвращаемых результатов вообще.
                                                            — вводят анонимные функции и замыкания, но опять как-то не полноценно

                                                            Я понимаю, что BC и т. п. и, наверное, очень сложно сделать, например, [1,2,3].walk |$item| { ... } вместо array_walk(array(1,2,3), function($item) { ... }), но восторгов это не добавляет.
                                              • 0
                                                А можете на примере — я прочитал введения и не обнарузил ничего что нельзя было бы сделать средствами языка типа питона — что я проглядел?
                                                • 0
                                                  Может я проглядел встроенный в питон механизм сессий с возможностью в конфиге задавать способ хранения (из зарегистрированных в расширениях, как минимум в файлах и sql)?
                                                  • 0
                                                    Я не про наличие стандартной библиотеки, про решение включить это в сам язык — то есть вы имели ввиду поддержку сессий из коробки или поддержку сессий в синтаксисе и семантике-именно языка (в отличие от стандартной библиотеки или внешних библиотек)?
                                                    • 0
                                                      Прежде всего в синтаксисе и семантике языка, на худой конец в стандартной библиотеке. $_SESSION в PHP — элемент языка. В Python — в стандартных либах не нашёл аналога. Правда от корки до корки описания не читал.
                        • +1
                          Библиотеки, функции, классы, «недублирование кода» — это скилл разработчика, а не фича языка.
                          • 0
                            в языке должны быть механизмы для запасания кода.
                            • +2
                              Что это за термин такой новый? Раскройте что это за механизм такой есть в одном языке и нет в другом?
                              • –5
                                Это образное выражение. Предствьте себе, что у вас язык где нету функций — как не дублировать код, например на брейнфаке?

                                По поводу питона и пхп, попробуйте посмотреть на комментарий habrahabr.ru/post/142342/#comment_4764012 и написать такую же функцию, но на PHP. Если захочется поииследовать как работает — можно сходить на www.trypython.org/#
                                • +3
                                  Представьте, что в PHP есть функции, и я написал ту функцию, о которой Вы говорите. Дальше что, кроме того, что мы получим две бесполезные функции на разных языках?
                                  • 0
                                    Мы щас как раз рзбираемся можно ли написать такую же функцию на php. Или придется писать по одной на каждый тип данных.
                                    • 0
                                      Да, можно написать одну функцию.
                                      • 0
                                        можно увидеть ее код?
                                • +1
                                  Написал, что дальше? Вас пугает что она на пару строк длиннее?

                                  А меня больше пугает что вы такой код пишите на чистом Питоне, вместо того чтобы в шаблоне его писать. И не нужно говорить, что это просто пример :)
                                  • +1
                                    >>>Написал, что дальше

                                    Дальше мы посмотрим на их свойства
                                  • –2
                                    >>>И не нужно говорить, что это просто пример

                                    это просто пример.
                  • 0
                    >Если уж реально надо получить прирост скорости (5-10 раз) — тогда на джаву смотреть надо.

                    если надо ускориться — берем профайлер, ищем горячие точки и переписываем в виде модуля наC/C++

            • +4
              Отлично обстоят, сам делал систему для банкострахования, заказчики в восторге так как с ней оборот вырос на порядок.
      • 0
        а этого человека волнуют дыры в его интернет-магазине? когда его сломают через дыру в жумле/её плагине и уведут персональные данные клиентов. 152 ФЗ не дремлет.
        • 0
          А что, использование python/ruby/perl/js/… даёт автоматические гарантии отсутствия дыр? Особенно если писать в «cgi режиме» или свой сервер с ноля, а не пользоваться наработками сообщества?
          • 0
            ммм… свой сервер «с ноля»? ок. покажете веб-сервер на php, отдающий статику через sendfile() и обрабатывающий события через epoll()?

            Насчёт безопасности я уже писал: php — единственный проект, в котором офицер безопасности отчаялся исправлять дыры и устроил террор, публикуя каждую неделю по новой критической уязвимости.

            Посмотрим, что говорит secunia:

            ruby 1.8

            python 2.5

            python 2.6

            php 5.0

            php 5.1

            php 5.2

            php 5.3

            joomla 1.x

            drupal 6.x

            drupal 7.x

            • 0
              А зачем мне его писать если есть mod_php и fpm из коробки? Пускай будет приложение python+wsgi или ruby+rack (хотя и не совсем корректно такое сравнение, вроде. Сильно безопаснее оно будет, если я его начну писать? Будет автоматически экранировать вывод и SQL-запросы, вставлять токены в формы и анализировать их наличие и корректность в обработчиках?

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

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

                это цена за «интегрированность HTTP в php».

                php 5.0:

                SA24505 — PHP Session Handling Double Free Vulnerabilities(
                SA22653 — PHP «htmlentities()» and «htmlspecialchars()» Buffer Overflows ( Highly critical)
                полный список secunia.com/advisories/product/3919/?task=advisories

                php 5.1:
                secunia.com/advisories/product/6796/?task=advisories

                php 5.2:
                secunia.com/advisories/product/13446/?task=advisories

                php 5.3:
                secunia.com/advisories/product/27504/?task=advisories
                SA47806 — PHP «php_register_variable_ex()» Code Execution Vulnerability
                вообще няшно: Highly critical, System access, From remote

                Джумлу, друпал, вордпресс, джангу, руби и питон найти там легко.

                • 0
                  Какая ORM? Я же пишу с нуля, не пользуясь сторонними разработками, только стандартными биндингами к MySQL API. Не, я конечно, напишу свою ORM (уж больно нравится мне ООП), но, почему-то кажется, что оставлю я или нет возможность sqlinj от языка на котором писать буду никак не зависит.

                  Уязвимости есть везде где не глянул, в PHP 5.3.x и Drupal 7 не нашёл Extremely, а php_register_variable_ex() на хабре уже обсуждали — довольно сложная атака должна быть, рабочего эксплоита вроде нет
                  • 0
                    >>>что оставлю я или нет возможность sqlinj от языка на котором писать буду никак не зависит.

                    если система типов позволяет, то можно сильно себе облегчить защиту от SQL injection.

                    • 0
                      C http приходят же строки?
                      • 0
                        и что?
                • 0
                  PHP более популярен, поэтому в нем больше находят уязвимостей.

                  Вы с этим комментом про секюрити вообще не в тему вылезли.

                  Вспомним недавний взлом Github'а (коммит в RoR) — там была дыра, которую им просто лень было закрывать, пока их не поломали.

                  «В личном блоге Егор написал, что обнаруженная им уязвимость позволяет делать pull/commit/push в любом репозитории на Github. Свой поступок он объяснил раздражением от того, что мейнтейнеры Rails игнорировали баг, о котором он сообщил, и поэтому Егор теперь решил протестировать его на первом попавшемся проекте.»
    • +1
      Викимедиа подходит? Или, например, Фейсбук?

      Цукеберг передает привет с собственного острова за пару десятков миллионов.
      • +1
        Как я люблю тех людей, которые отвечают не на мой вопрос, а на вопрос своего внутреннего голоса, видимо.
  • +7
    Уж очень субъективные у Вас ответы. Вы анализировали количество фреймворков в ruby\python? Да и количество программистов не говорит об их качестве. Придет к вам 28 миллионов программистов пхп, но на деле лишь пару процентов окажется действительно программистами, а остальные лишь кодерами, которые «фейсбук» вам не сделают. Python\ruby — более высокий порог вхождения и потому программистов меньше, но их качество выше, а значит выбирать легче. Правда с выводом статьи я согласен. Делал высоконагруженные проекты как на php, так и на python (на ruby не довелось). Мой выбор — php. Да и узкие места при высоких нагрузках вовсе не в написанном на php\python\ruby коде возникают, а в запросах к базам данных.
    • 0
      Почему php? Действительно ведь в плане нагрузки разница минимальная должна быть между языками, т.к. узкое место это I\O к БД.
      • +10
        Это чисто субъективное мнение. Боюсь его здесь высказывать, дабы не навлечь на себя гнев python'истов, но раз вы спросили. Python радует простотой и элегантностью синтаксиса… но только до определенного периода. Django мне показался набором каких-то неведомых костылей, а сам фреймворк держит в жестких рамках, предоставляя довольно низкий уровень абстракции по сравнению с yii, например. У php же фреймворки более обобщенные. yii и zf просто дают набор классов и рекомендации, а разработчик делает с ними что хочет. Да и сиподобный синтаксис мне ближе. За 2 года использования питона мне все также кажется нелепым контролировать отступы (хотя все меня убеждали, что это невероятно крутая фишка). Опять же я не могу говорить за все фреймворки и нюансы языка, так как я их просто не знаю (ни php, ни python), но те задачи, с которыми я сталкивался мне было проще решить на php, а, как вы заметили, разница в производительности на продакшене между ними минимальна.
        • +10
          Тоже никак не могу понять «крутости» отступов. Зачем вообще к этому привязываться в языке…
          • –3
            Ничего, со временем догонишь какую роль имеет читаемость кода.
            • +9
              ИМХО Читаемость кода не должна быть завязана в синтаксисе языка.
              • +1
                Почему?
                • +5
                  А кто вам сказал, что делая такие отступы код становится читаем? Мне удобнее читать, когда кроме отступов я вижу начало { и конец } блока.
                  • +6
                    Унификация физульаного языка делает код читаемее. О том, что отступы более наглядны чем скобочки свидетельствует то, что
                    — в тех языках где можно обойтись скобочками все равно делают отступы
                    — периодически сталкиваюсь с тем, что если по ошибке отступ сделан неправильно, я читаю его а не скобочки, не смотря на то, что у меня большая привычка к и подобному синтаксису.

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

                    Как-то раз на 1 апреля Гвидо ван Россум написал, что со следующей версии языка в компиляторе будет забит отступ 4 пробела и при его несоблюдении будет ошибка компиляции.

                    С моей точки зрения такая штука должна быть, так как заставляет соблюдать единый стандарт по всему языку — в нормальных командах поверх языка еще есть нечто вроде StyleCop который не дает зачекинить код, не отвечающий принятому в команде стилю. В данном случае, я был бы не против, если бы StypeCop был бы в самом языке.
                    • +10
                      Ладно, если вам трудно понять идею из текста, то скажу прямым текстом: мне не нравится, что разработчики за меня решили какой код будет читаем, а какой нет. Мне трудно беглым взглядом найти конец блока например если идет:
                      def asd():
                          blablabla
                          blablabla2
                          if True:
                              blablabla3
                              if True:
                                  blablabla4
                      if False:
                          blablabla5
                      


                      А теперь представьте, что это все еще смещено на пару вложенностей. Мне уже даже сейчас не хочется воспринимать последний if вне функции. А будь там конец блока } или end, мне было бы удобно. Но питонисты утверждают, что нужно просто всех переделать под себя.
                      • 0
                        Не нужно никого переделывать, но использование отступов — крайне желаемая и общепринятая конвенция во всех языках.

                        Что касается структур begin->end, с ними не без плюсов в виде чуть более явной вложенности и не без минусов — вертикальное, (т.е. самое ценное) место место сильнее расходуется.

                        И без конвенций скобки можно перепутать, сносить и размещать так, что у любого мозг вывихнет (привет js и lisp). Плюс есть стандартная ошибка отсутствия выделения begin-end одной строки, потом к ней дописывается еще одна, не попадающая в тело вызова и мы получаем ошибку, которую хрен найдешь.

                        Условный пример кода не очень показателен и действительно меня смутил, хотя реальный код меня ни разу не смущал подобным образом, немного визуальные паттерны другие. Ну и после метода/функции ему второй пустой строки не хватает, в пепах это прописано.
                        • 0
                          Вы не забывайте, что пустые строки я могу расставлять и в теле функции, например для отделения смысловых действий. Т.е. мне нужно будет делать 1 отступ в теле и 2 после функции. Где здесь экономия места по сравнению с begin\end? На отступы никто не посягает ) Просто как видно в данном примере без них хуже, чем с ними. И я реально видел такой код. Почему кстати он не очень показательный? Я определил функцию и потом начался основной код (кстати, я не могу вынести функцию в конец файла, что было бы опять же удобней.)
                      • 0
                        Всё познаётся в сравнении:
                        def asd(){
                            blablabla
                            blablabla2
                            if True{
                                blablabla3
                                if True{
                                    blablabla4
                                }
                            }
                        }
                        

                        Лучше не стало.

                        И, кстати, вот такую ошибку в PHP визуально сложно отловить:
                        <?php
                        function my(){
                            if (true)
                                do_something();
                                do_another();
                        }
                        ?>
                        

                        Только вбивание в голову привычки ставить скобки всегда. А после питона их обилие раздражает.
                        • +3
                          Для меня стало лучше. Теперь если за блоком пойдет другой код я сразу по скобке увижу, что он не в теле функции.
                          А ошибка в пхп… А вам не кажется, что нотификация zend не зря рекомендует так не делать? Если бы Вы здесь поставили скобки, то код читался бы прекрасно. А вот в питоне:
                          def my():
                              if True:
                                  do_something()
                              do_another()
                          

                          Мне кажется хуже
                          • 0
                            И не только в zend. Меня больше удивляет, что скобки не являются обязательными для IF, аналогично FUNCTION.
                            Ну а по-поводу скобки vs отступы — у нас просто разные вкусы/взгляды. А спорить о вкусах — дело пустое.
                            • +3
                              Ну наконец хоть кто-то услышал меня ) Именно про это я и говорил. Я сказал, что питон мне не понравился потому что для меня он оказался неудобен )
                      • 0
                        Ничего не хочу сказать против Вас, но мне легко найти. Возможно это просто опыт/привычка?
            • +5
              Я видел как на питоне умудряются написать такое ничитаемое г, что хотелось выколоть себе глаза. Поэтому при определенной «квалификации» и энтузиазме можно наговнокодить и в питоне с его супер крутым читаемым синтаксисом )
          • +7
            Меня вот больше бесит отсутствие некоего 'end'а для оформления окончания блока, чтобы текстовые редакторы могли понимать где и сколько отступов надо вставить. Прям выносит мозг при рефакторинге долбить в таб, переключая уровни отступа в емаксе. В руби как раз end был добавлен только по причине что автор языка использовал емакс и понимал насколько это удобно.
            • –2
              Не могли бы вы пока зать на примере? Почему редактор, грубо, говоря не может сам держать в уме все эти begin и end — они же однозначно выводятся из отступов?
              • 0
                а какое должно быть поведение у редактора при нажатии кнопки «сделать правильный отступ для этой строки», если с помощью отступов определяются блоки. Поэтому при нажатии на эту кнопку, редактор начинает переключаться по всевозможным блокам и предлагать различные варианты. А в случае когда блок определяется явными begin/end, то у редактора не возникает никаких проблем выставить нужный отступ при первом же нажатии.
                • 0
                  //«сделать правильный отступ для этой строки», если с помощью отступов определяются блоки

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

                      Редактор может определять необходимую вложенность для следующей строки по формальным признакам выхода из блока — return, except, raise, else, eleif.
                      • 0
                        except, raise, else, eleif — это всё как бы начало блока ;)
                        А после return'а емакс определяет конец блока и не прыгает дальше чем нужно.
                        • 0
                          return и raise конечно же :)
                        • 0
                          Это не только индикаторы начала блока, но и индикаторы окончания вложенности предыдущего блока.

                          Когда внутри try вы пишите except — редактор может понять, что необходимо выйти за границы блока try. То же самое с else и elif.
                          raise — индикатор завершения либо всей функции, либо блока, в котором определен ближайший except, ловящий текущий raise.
            • +3
              Попробуйте PyCharm. Он с отступами в Питоне нормально работает.
    • +14
      но на деле лишь пару процентов окажется действительно программистами

      А чего Вы решили что среди программеров Руби/Питона прям все сплошные гении? :) Как будто если человек пишет на ООП, то он типа не может написать говнокод :)
      • +2
        Я, почему-то, не вижу сильного различия в пороге вхождения php и python. Уж если бы я отдал питону 3 года своей жизни, не думаю что я бы знал его хуже чем php за тот же период.
        • +1
          Я говорю о другой величине. К примеру через сколько вы сможете начать писать что-то адекватное на php и на python. Не знаю как у вас, но втянуться в php с нуля у меня получилось за 3 месяца где-то написания своего велосепеда. С python у меня было все менее успешно, хотя к тому моменту я уже имел опыт программирования. Да и каждый человек индивидуален. Я ведь указал, что это относится только ко мне, так же как и то, что написал автор относится только к нему.
          • +1
            Адекватность программ зависит ои мозгов программиста. Если у человека есть талант он будет на любом языке нормально писать. А нет, так будет на любую элементарную ошибку бежать в форумы
            • +1
              Ну ведь здесь речь было немного о другом. Посмотрите сколько сейчас открылось студий веб-дизайна. Я успел поработать в 3 таких. Большинство «программистов» там — студенты, написавшие «форум с нуля на php» и считающие себя крутыми спецами. А потом они приходят в «фейбук» и говорят: «я крут, давайте мне з\п побольше». Несомненно и на php есть выдающиеся специалисты. Просто процент кодеров на php выше, мне кажется.
          • +5
            Не могли бы вы проанализировать какие особенности питона вам помешали?
            • +4
              Ну тут уже почти все это упоминалось, но повторю:
              1. Неудобное использование ООП. Таскать за собой self по всем методам (не знаю больше ни одного языка. где сделан такой же маразм. Что помешало в питоне сделать по-человечески — не понимаю).
              2. Неудобочитаемость кода, когда я вижу кучу отступов, но не вижу четкого конца блока. Кто-то от этого приходит в восторг, но меня такой код угнетает.
              3. Нет возможности внести изменения и сразу их увидеть. Приходится постоянно делать лишние операции.
              4. Нет адекватного фреймворка. Вернее даже не так. Из тех популярных решений, которые я пытался использовать меня ни одно не устроило.

              Возможно покажется, что какие-то слабые недостатки, но так как на продакшене скорость ЯП не имеет огромного значения, я выбираю чуть более высокий уровень удобства.
              • 0
                1. Кроме использования self ничего не напрягло? Не увидели ли вы в питоне что все является объектом, что интерфейсы объектов унифицированны и вы можете у себя воспроизвести полностью интерфейс строки и большая часть кода работающая со строками будет работать и с вашим объектом?

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

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

                Не могло ли так получиться, что вы стали жертой блаб-парадокса: те возможности которые есть в вашем любимом языке — это и так понятно; tо, что неудобнее чем в вашем любимом языке — это недостаток; то чего нет в вашем любимом языке — просто невидимо/непонятно зачем?
                • +4
                  1. И часто в ваших проектах Вам это пригождалось? ) Мне нет, поэтому и не обратил внимание, хотя сам факт существования возможности знаю
                  2. Вы. Ключевое слово Вы. Почему никто не видет, что каждый человек индивидуален? Вы выискиваете отступы. Я если честно тоже, но без скобочек отступы мне трудно воспринимать. Я в php тоже делаю всегда отступы, но скобочки меня не напрягает ставить. Потому что так мне понятней.

                  Кто сказал что php мой любимый язык? Просто мы рассматриваем веб. Для веба — пхп мне кажется наиболее разумным. Питонисты любят приводить в достоинства питона всякие фичи (типа как вы с объектами), но согласитесь, что эти возможности очень редко используются в реальных проектах. А фича ради фичи мне не нужна. (приведите пример реального проекта, где python сделал бы что-то такое, чего не смог бы php)
                  И не пытайтесь переделать всех под себя. Не стали ли вы жертвой этого вашего блаб-парадокса? (первый раз услышал такое понятие)
                  • –2
                    >(приведите пример реального проекта, где python сделал бы что-то такое, чего не смог бы php)
                    Ну тут важно насколько элегантно сделано. Наглядный пример — это убогие ОРМки в php.
                    • +3
                      Обогие ОРМ? Чем же они убоги? ) Вы все ОРМ на php перепробовали? А на питоне? Думаете там меньше убогости? И Вы не привели пример. Скорее всего, потому что его нет. А убогость кода связана не с языком, а программистом )
                      • +1
                        Ну возьмём наиболее популярные решения Doctrine/Propel(php), SQLAlchemy(python).

                        и вспоминаем то что вам ненравится :)
                        >Нет возможности внести изменения и сразу их увидеть.
                        • –4
                          По сути между ними разница минимальна в плане возможностей. Ну Вы не поверите: я не использую Doctrine. А знаете почему? Мне кажется он неудобным. Я не могу многого рассказать про него, так как попробовав раз я понял, что это монстр, который на продакшене пускать не стоит. Да и любая ОРМ — лишние запросы в БД. Хотя бы тот же describe. Я предпочитаю Pdo + обыкновенный sql
                          • 0
                            Ну мы же не обсуждаем ваши предпочтения.
                            А про использование/создание инструментов, которые часто используются в веб деве. Для создания dsl'ей тут как бы и питон всосёт, если начинать демонстрировать RSpec, сделаный на руби. Но ОРМки с компиляторами на пхп — это вообще из разряда какого-то геморроя. Ладно там на Java/C++ я плачу удобством за высокую производительность, но php/ruby/python — это все тормозные язычки, где я в последнюю очередь думаю о производительности, а в первую — это удобство использования.
                            • 0
                              Разве? А по-моему я уже не раз писал, что выбор языка — сугубо личное и так как между ними нет особой разницы, то каждый выбирает то, что удобно именно ему. Я конечно понимаю, что холивар разжигает огонь в душах, но неужели так трудно понять, что питон ни чем не лучше и не хуже пхп (можете взять другие интерпретируемые языки). Тут дело в том, что мне удобней. Так почему вы пытаетесь меня убедить, что питон мне удобней, если я попробовал и это оказалось не так.
                    • 0
                      Когда у вас появляется нагрузка, которую нужно оптимизировать — любая ORM/AR становится убогой. Потому что оно не способно сгенерировать запрос, который может написать человек руками.
                      К примеру довольно не редко на сложных выборках эффективно использовать derived queries для отфильтровывания лишнего и только потом джойнить данные. Покажите мне хоть одну ORM которая это сделает за меня? Ниодной, потому что это уже не ООП — раз, а два — имея конкретную базу данных я могу использовать её особенности и дополнительный функционал: это может сократить время запроса на порядок, а то и 2-3 порядка; в спечефичных случаях иногда и в сотни раз.

                      Так что вы уж извините, но тут всё сильно зависит от конкретной задачи и рабочего окружения. Все эти ваши ORM работают пока у вас шаблонный функционал.
                      • 0
                        А если использовать ORM без функциональности DBAL? Запросы писать ручками, а средствами ORM только приводить их результаты/аргументы к модели?
                      • 0
                        Когда у вас появляется нагрузка, которую нужно оптимизировать — php/ruby/python становятся убогими. Потому что они не способны отработать риквест с такой же скоростью, с которой сможет Си.

                        Вобщем я это к чему, речь у нас про удобство и простые сайты, а не про очередной фэйсбук или гугл.
                        • 0
                          Когда у вас появляется нагрузка, то узким местом практически всегда является БД, а не php/ruby/python.

                          На фанатов обрушивается ведро холодной воды, и… упс, ORM из объекта поклонения превращается в обузу.
                          • 0
                            Слушайте, вот давайте предметно. 300 rps — это нагрузка?
                            Причем на обычный http 1.0, а не websocket какой-нибудь.
                            • 0
                              С чем конкретно вы не согласны?
                              • 0
                                Тут как бы намёк на то что 300rps — это нагрузка у одного из популярных проектов в рунете ;) И они не испытывают проблем с базой данных из-за ОРМа.
                                Тк либо архитектура самого приложения — гавно, либо людей занимающихся проетками, в которых ОРМ будет обузой можно встретить достаточно редко и в большинстве случаев они понимают почему они отказываются от ОРМа. А для всех остальных ОРМ отлично справляется с задачей и уж лучше пусть будет всё сделано по-тупому, вместо умников, которые думают что могут что-то отоптимизировать, что в итоге выливается во всякий геморрой с кэшами итд.
                                • 0
                                  Зависит от:
                                  1) что имеется в виду под rps — количество некешируемых pageviews в секунду или то что отдает кеширующий прокси?
                                  2) на скольки железяках это крутится (может у них там ферма из серверов под эти 300rps)
                                  3) объем данных — может там все RAM умещается
                          • 0
                            Когда появляется нагрузка перед нами есть множество различных вариантов решения проблемы, которая не ограничивается вертикальным масштабированием какого-нибудь Postgre. И Взяв в руки Си++ можно будет решить те же проблемы на порядки эффективнее(например так как в гугле) вместо того чтобы использовать архитектуру в виде php бэка, суть которого делать sql запросы и рисовать хтмльки.
                            Я не понимаю что вы хотите сказать, что ОРМ — гавно? ОРМ вполне хороший инструмент для своих задач. В 99% случаев разработки вебсайтов он отлично справится с задачей и человек, который вдруг придёт на смену вам будет только рад тому что тут не гора sql'ой аптемезации.
                            • 0
                              ORM — гавно когда база является узким местом.

                              Удачи вам переписывать хранилище данных на C++.
                      • 0
                        sqlalchemy может всё
                  • 0
                    1. функциями типа map пользовался постоянно, когда писал на питоне. Имхо достаточно взять любую достаточно навороченную библиотеку типа BeautifulSoup и там можно найти кучу примеров.
                    2…

                    >>>(приведите пример реального проекта, где python сделал бы что-то такое, чего не смог бы php)


                    Знакомо ли вам понятие тьюринг-эквивалентность?
                    • +2
                      Неужели! )) Вы меня понял? ) От языка ничего кроме удобства не зависит. Все современные языки умеют делать одно и тоже ) И это я пытался донести с самого начала. Но вы меня убеждали, что python может больше и лучше. Так теперь я хочу задать Вам вопрос: Знакомо ли вам понятие тьюринг-эквивалентность? )
                      • –1
                        Дык он может больше и лучше, только это больше и лучше не значит принципиальную невозможность сделать то же самое на брейнфаке.

                        Язык он для человека а не для компа — это ж давно известно.

                        Он может больше и лучше в плане того самого удобства для человека. Он же язык.

                        В питоне больше мезанизмов для запасания знаний и для того, чтобы одинаковый по сути код работал с большим числом разных объектов.
                        • 0
                          Пример. Что может такого питон, чего не может php? Вы опять вернулись к тому, с чего начали. Больше механизмов? Это например список и словарь? А в пхп только массив. Но зато в пхп я не заморачиваюсь и всегда пишу array, не думая нужны ли мне ассоциации или нет.
                          • 0
                            Это например то, что все объект, включая строки числа и прочее. Можно абстрагировать например алгоритмы над последовательностями и оно будет работать везде (см модуль itertools).

                            >>>Но зато в пхп я не заморачиваюсь и всегда пишу array, не думая нужны ли мне ассоциации или нет

                            Вот это интересно — вы заводите объект, не зная для чего он вам нужен? Можно пример?
                            • 0
                              В PHP тоже есть итераторы, если что.
                              • 0
                                itertools там можно написать? будет ли оно работать со диапазонами, строками, и всем тем что представляет собой концептуально последовательность
                            • 0
                              Какой объект? Вы про что? ) Из каких моих комментариев вы вынесли эту мысль? Я говорю, что если мне нужно 'asd' => 2, то я пишу array('asd' => 2), а если мне нужно просто 2, то я пишу array(2). А про «все объект»… И что? Вы мне реальную необходимость этого приведите?
                              • 0
                                и какова алгоритмическая сложность вставки/удаления/получения? вы в курсе, что массивы и ассоциативные массивы это разные структуры данных?
                                • 0
                                  Да, в курсе. А как это реализовано в php Вы в курсе? Я, например нет. Может там все не так плохо как вам кажется. И вы опять говорите не о том.
                                  1. ЯП — в исключительных ситуациях является узким местом в реальных проектах
                                  2. Если не заморачиваться по поводу 20 мс выигрыша в скорости работы, то я выберу то, что мне удобней.
                                  3. Если ваш код делает что-то тяжелое и разница в работе python\php существенна, то может стоит подумать о том, чтобы такой код перенести на что-то действительно производительно? Например Си.
                                  Примерно таких пунктов я придерживаюсь. пхп — фронтенд, С++ — критичный по скорости бекэнд. На питоне я обычно пишу прототипы скриптов. Действительно быстро и удобно. Но для увеличения производительности я выберу C++.
                                  • 0
                                    1. Вы знаете, а многие ли любители пхп знают это?
                                    2. 20 мс например в моем случае очень даже неплохо так.
                                    3. Если мой код будет заниматься числодробилками, то я возьму к примеру numpy. но когда кто-то например вместо ассоциативного массива использует обычный массив и каждый раз ищет объект полным перебором, то меня это коробит. как впрочем и когда наоборот, массив объектов пихает в ассоциативный массив, когда заранее понятно, что по ключу они дергаться не будут.
                                    4. Я считаю, что если написано array, то это должен быть именно массив, а не ассоциативный массив, пока я этого явно не напишу. вот вы подразумевали обычный массив и писали по индексу, а в другом месте другой программист этого не знал и стал писать по строковым ключам и у него это прокатит.
                                    • 0
                                      А «ваш случай» в чем заключается. Для числодробилок я бы все таки выбрал С++ )
                                      • 0
                                        просто достаточно нагруженное приложение. только и всего. я лучше те же 20 мс пожертвую в местах, которые мне добавят понятности, чем просто потому, что мне лень нужную структуру данных использовать.
                                        • 0
                                          Кто сказал что мне лень? Просто мне лень использовать все «нужные» структуры питона вместо использования «нужных» структур пхп. Тем более приобретя эти нужные структуры я потеряю удобство и понятность. Достаточно нагруженный это какой? У кого-то нагруженный — 10000 посетителей в день, а у других — 500000 )
                                          • 0
                                            пару тысяч в секунду, так устроит? сразу скажу, не веб в чистом виде
                                            • 0
                                              Ну не слабо. Просто стоит разделять: основная нагрузка на запросы к бд идет или при обработке данных. Вы хотите сказать, что пхп не справлялся бы с такой нагрузкой? А если критична скорость работы прямо до миллисекунд, то я вообще не считаю интерпретируемые языки разумным выбором. Быстрее С пока еще ничего не придумали на высоком уровне. А если все совсем печально и вы боретесь за доли милисекунд, то пишите на асме ) Но не стоит говорить, что пхп медленно, я буду писать на питоне. он быстрее. Я участвовал в таком проекте ) Мне было смешно, но мое мнение никто не спрашивал ) В итоге сейчас этот проект все также загибается от нагрузок, а потрачено 2 месяца на переписывание.
                                              • 0
                                                пхп и справляется. сейчас именно он используется. новый проект пишем на питоне, не потому что он быстрее (хотя простенькие показали прирост где-то в полтора раза), а потому что на нем банально удобнее писать и потому что текущий пхп проект представляет из себя огромную свалку, хотя писали люди неглупые далеко. Интерпретируемый язык выбран осознанно ввиду простоты написания и простоты деплоя в частности.

                                                основная работа — проверить бизнес-логику и получить-сохранить данные из бд. куда тут впихивать модули на С? но будет запрос идти 60 миллисекунд или 30 все же важно. надо будет в 2 раза меньше серверов.

                                                я к тому, что везде нужен компромисс, здесь компромисс между удобством написания и производительностью. пхп ни скоростью, ни удобством не обладает, плюсы не обладают достаточным удобством. только и всего.
                                                • 0
                                                  Насчёт неудобства пхп по сравнению с питоном спорно, особенно если рассматривать «коробочные» продукты, предназначенные для установки неквалифицированным пользователем.
                                                  • 0
                                                    вот снова. мы сравниваем не «коробочные» продукты, а языки. и не для неквалифицированных пользователей, а для программистов.
                                                    • 0
                                                      Сравнивать языки в вакууме по-моему бессмысленно. А то получится, что лучший язык программирования — это естественный, только вот компиляторов нет.
                                                • 0
                                                  «получить\сохранить данные в бд» вы сталкнетесь с тем, что при увеличении кол-ва данных вам понадобиться увеличение количества серверов с бд. А это не просто скопировал и запустил еще один. Это шардинги, рапределение нагрузки и т.п. И поверьте увеличение производительности в полтора раза (15 мс для вашего пример) вам покажется никчемным. Я, например разницу в 15 миллисекунд не замечу на глаз. А по поводу кол-ва серверов — сомнительно утверждение ) Задача, которая выполняется на одном сервере 30 мс на двух тоже будет выполнятся 30 мс, но параллельно смогут работать 2.
                                                  • 0
                                                    само собой нужен шардинг и прочее, все это уже заложено и предусмотрено. по поводу времени обработки надо пойти с другой стороны. есть приемлемый интервал допустим 30-40 миллисекунд. питон обеспечит это на одном сервере, пхп понадобится два. вот и вся математика.
                                                    • 0
                                                      Как время выполнения одного запроса у вас уменьшается при увеличении количества серверов? Вы как-то распараллеливаете выполнение каждого запроса? В вакууме один и тот же алгоритм всегда будет выполняться с одной и той же скоростью. И он не станет работать быстрее, осознавая, что рядом с ним трудится над такой же задачей еще один сервер. Или я вас не понял? Получается если пхп изначально не вписывается в ваши временные рамки, то сейчас ваш проект не работает? Или все таки сейчас вы рапараллелили задачу каким-то образом?
                                                      • 0
                                                        может я неправильно выразился. простой бенчмарк показал, что за секунду пхп успевает обработать где-то в полтора раза меньше запросов(точно не помню, давно было), чем питон при полной загрузке проца (с учетом xcache). если учесть, что время выборки из базы фиксировано как для питона, так и для пхп, то получается, что питону надо меньше процессорного времени, чем пхп. то есть 2 сервера на питоне обработают столько же запросов, что и 3 на пхп.
                                • +1
                                  >вы в курсе, что массивы и ассоциативные массивы это разные структуры данных?
                                  немного не в тему, но просто тут на днях пришлось на питоне делать такой изврат, который на Си делается элементарно. Суть была в том что нужно было каждой ноде в даг графе присвоить битовый вектор для определения принадлежностей нодов к разным группам. Так пришлось брать листы, состоящие из True,False вместо какого-нибудь обычного BitArray'а, с которым элементарно работать на Си. Попытки оптимизировать различными способами, и даже прикручивание Сишного кода на моей задаче не давали особого прироста производительности, только уменьшали потребление памяти, что пришлось оставить так как есть :) Пришлось дописать комментарием что понимаю что код убог, но не вижу варианта как сделать лучше.
                                  • 0
                                    • 0
                                      >pypi.python.org/pypi/bitarray/0.3.2
                                      на моей задаче было в ~2.5 раза медленее при использовании bitarray.
                              • 0
                                ну то есть вы явно создаете ассоциатиынй массив только указываете, что это ассоциативный массив другим образом?

                                Реальная необходимость — вон например код из моего примера работает только с последовательностями строк. Сделаем чтоб оно работало со всем, что можно представить как строку:

                                def make_list(xs):
                                    return ''.join('<li>'+str(x)+'</li>' for x in xs)
                                print make_list(xrange(0, 10))
                                


                                codepad.org/dRTXxV1U

                                Теперь оно работает вообще со всеми объектами, у которых есть метод __str__ включая встроенные
                                • +1
                                  Каким другим? Не понимаю Вас.

                                  А по поводу примера… А зачем? Вы реально работаете с другими объектами кроме строк в проекте? Максимум с числами, но на пхп это еще проще реализовано. Мне трудно представить реальную необходимость работы с другими типами данных. Как фишка языка — очень даже интересно.
                                  • 0
                                    А бизнесобъектов вы не делаете? Типа там Заказ, Пользователь прочее?
                                    • 0
                                      Во-первых, комментарий ниже ) А во-вторых: делаю, но с трудом могу себе представить ситуацию, когда мне понадобится обработать Заказы и Пользователей в одной куче ) Я напишу 2 различных обработчика для этого случая.
                                      • 0
                                        То есть у списка заказов и у списка пользователей нет ничего общего?
                                        • 0
                                          А что у них общего? ) Это две разные сущности. Можно найти сходство, но чтобы им воспользоваться — не знаю какой должен быть случай )
                                          • +1
                                            по-моему у них дохренища общего. Например, то, что они список. Можно написать шаблон для всех списков, который будет показывать в унифиуированном виде: заголовок, строки, причем четные сервм, нечетные белым фоном, футер, кнопки для редактирования, пейджинг и прочее.
                                            • 0
                                              У самолета и гвоздя тоже дохренища общего ) Они оба из металла )
                                              • 0
                                                и для работы с ними использут ту же физику и химию :)
                                  • 0
                                    В php есть magic function __toString() и это очень полезная вещь.
                                    • 0
                                      Блин.
                                • 0
                                  Глупый пример, я пишу и на пхп и на питоне.

                                  То-что Вы показали как __str__ в пхп есть метод toString().

                                  • 0
                                    я пхп знаю поверхностно — может вы подберете пример получше?
                                    • 0
                                      Так если вы знаете его поверхности, то зачем сравниваете и спорите? Сравнивать наличие различных функций блаблабла напоминает как на «пацаны» на «тачках» стоят с открытыми капотами и мерятся «письками», хотя любая машина, навороченная или нет, свою основную функцию транспортную функцию выполняет.
                                      • 0
                                        Так веселее! Для вас машины все одинаковы?
                                        • 0
                                          Нет конечно :) Но кричать друг другу «У меня есть такая функция, а у тебя нету, а еще я могу написать функцию на 1 строчку меньше» это как, по аналогии с машинами — «У меня есть кондиционер, а у вас нету. Вы все плохие. Как можно ездить в машине кондиционера? А еще у меня есть парктроники. У Вас их нет?! Зачем тогда жить?» :)
                                          • +1
                                            не кондиционер есть у всех :)
                                            а вот у меня есть наклейка на бампере, которая снижает сопротивление воздуха за счет свой гладкости это действительно круто :)
                                  • 0
                                    Насколько я понял магические методы это весьма ограниченный набор методов — в python это просто методы классов, они есть у int и у str. Базовые операции сделаны ими (в любой момент времени можно получить функцией dir список методов переданного объекта) и вы можете при желании передать в код, например не число, а свой объект который придаст коду новый смысл, например, вмеcто простого выполнения странслирует в SQL (наподобие LINQ).
                            • 0
                              Вы вот не в курсе, что в PHP массивы это hash-map.
                              • 0
                                Не, про это я был в курсе — я пытаюсь понять, какая в этом выгода
                • +6
                  Не мог не скинуть Вам этот баян )
                  image
          • +2
            Скорее дело в другом, когда хомячок захотел стать программистом, он начинает писать (с вероятностью в 99%) на пхп.

            Через несколько дней он считает себя уже хорошим разработчиком сайтов… и +1 к 30 миллионам резюме по запросу «пхп резюме».
        • –5
          Порог вхождения это ведь не только «сложность» языка. Можно купить книжку «PHP для чайников за 21 день», накидать «сайт» и гордо назвать себя PHP программистом. Сомневаюсь, что такое вышло бы с Python'ом или Ruby.
          • +2
            Спасибо, именно это я и пытался донести )
          • +4
            Проходишь туториал (который заводит чуть дальше «Hello World», на примере руби-учит делать «твиттер») и гордо называешь себя Ruby программистом?
            • –1
              Твиттер на раби? Не видел такого туториала ) На рельсах — да.
          • +2
            По моему, это только в плюс PHP.
            • 0
              А я нигде и не говорил, что это какой-то минус языку о_О

              К PHP действительно ведь легче придти (несмотря на комментарий про туториал выше который учит делать твиттер).

              Вбил потенциальный программист в гугол «как делать сайты», нашел про html и php, скачал/купил книжку, поставил Denwer/LAMP, создал файл «privet_mir.php» и все, пиши не хочу. И все последующие проекты выглядят так же просто и понятно — создаешь php файлики да пишешь.
            • 0
              Неужели так сложно прочитать внимательно? Я не говорю что это минус пхп. Да, язык легок в освоении. Но именно поэтому в нем столько говнокодеров.
              • НЛО прилетело и опубликовало эту надпись здесь
                • 0
                  Эх… Вы кажется отказываетесь читать. Я про это и говорю. Автор привел в плюс пхп то, что на нем больше программистов. Я же говорю о том, что количество программистов — не основополагающий фактор. Главное их качество.
                  • НЛО прилетело и опубликовало эту надпись здесь
                  • 0
                    Количество — простой фактор, его можно посчитать.
                    А вот качество — сложный. Докажите мне, что средний программист на Python лучше, чем средний программист на PHP. Только реальными фактами, а не домыслами ок? Или еще лучше — сравните время, которое требуется на то, чтобы найти трех программистов на PHP и трех программистов на Python с адекватным качеством работы. Я вот не знаю, как такое считать — только эксперимент устраивать ;)
                    Любые разговоры о факторах, которые нереально просчитать — лишь спекуляция.
                    • +2
                      Я знаю, что когда мы искали php программиста, то из 10 соискателей к нам приходило: 5 студентов, ничего не знающих про детали разработки, 3 — те кто разобрались в joomla или другой cms, и только 2 — более-менее адекватные. А вот когда был набор python — программистов (проект переписывался с php на python из-за того, что питон «быстрее». решение не мое и меня никто не спрашивал согласен ли я с этим), то после собеседования с 4 мы взяли на работу 3 и закрыли вакансию. Может нам повезло просто )
                      • 0
                        Нет, это не везение — описал похожую ситуацию комментом ниже.
                    • +1
                      Чтобы доказать фактами, надо сначала определиться с критериями, что в случае оценки качества весьма сложно и сильно субъективно.

                      Однако могу поделиться недавним опытом поиска программиста на реализацию [относительно] несложной задачи. Суть проблемы описывать не имеет смысла, но можно сказать, что язык для решения задачи был непринципиален — допускалось использовать PHP, python, ruby и даже С. Из PHP программистов большинство (вернее — почти все) имели весьма поверхностные знания в предметной области. Например плохо знали основы реляционных БД, хотя заявляли, что почти асы в базах данных. Был даже преподаватель, который, похоже, первый раз в жизни услышал слово «нормализация».
                      В противовес к ним, специалисты знающие python и C были гораздо профессиональнее и через 15 минут презентации проекта мы уже говорили о его нюансах и возможных проблемах в архитектуре, а не топтались на месте. И мне не надо было объяснять почему на linux-сервере, к которому доступ только по ssh не стоит использовать delphi (да, было и такое предложение :)

                      Резюме — да, программистов на PHP гораздо больше, но выбор от этого не становиться легче.
      • –3
        причем здесь ООП? не совсем понял. Мое мнение — на Python ООП реализовано в разы хуже, чем в php. Просто если взять человека далекого от ЯП и сказать учи php, а второму — python, то первый уже через пару месяцев станет говнокодить сайты-визитки за более-менее приличные деньги и, в большинстве случае, его развитие на этом остановится. А вот с питоном все сложнее. Все вакансии python программистов требует достаточно высокой квалификации. Не видел ни одной вакансии «Требуется Python-программист делать сайты-визитки на Django». Поэтому python'исты вынуждены чуть больше развиваться или уходить в php (как собственно сделал я)
        • +2
          >Мое мнение — на Python ООП реализовано в разы хуже, чем в php.

          Я понимаю конечно, что это всего лишь ваше мнение, и все такое, но право слово… В пхп просто есть прикрученное сверху ООП. А питон — объектно-ориентированный язык. Уж где, где, а в питоне ООП реализовано в полном объеме, в отличии от того же пхп, где даже замыкания вон только в 5.3 появились.
          • –4
            Ну я не против. Но то что он изначально объектно-ориентирован не говорит о том, что ООП в нем реализовано хорошо. Чего стоит хотя бы таскание за собой по методам self в атрибутах.
            • +4
              Таскать self как по мне, так это потрясающе. Больше не надо разбираться, локальная это переменная или поле класса. Не надо вырабатывать стиль, как писать this.<> или просто <>. Все четко и понятно. Опять же, нет этого самого магического this.
              • –2
                А зачем его каждый раз декларировать во всех методах аргументом? Отступы унифицированы а self зачем-то каждый раз надо писать явно.
                • +5
                  <?php
                  class Blabla {
                   public function blabla() {
                     var_dump($this);
                   }
                  }
                  ?>
                  Blabla::blabla()
                  

                  В Python — нельзя даже вызвать такой метод статически, без передачи туда инстанса. Не говоря уже о декораторах вроде @classmethod @staticmethod, которые только добавляют удобства без костылей вроде: static, __CLASS__ etc. Всё это — для удобства программиста и читабельности кода. И ни капельки не напрягает. А self любая нормальная IDE умеет подставлять.
                  • НЛО прилетело и опубликовало эту надпись здесь
                  • 0