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

[@nuclear]

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

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

[@zapimir]

Толку от этих гемов для рельсов, если нет нормальных готовых продуктов на них, или хостинг фиг найдешь. Если бы Ruby/Python был бы таким белым и пушистым он бы уже давно вытеснил PHP. А все эти рассуждения о красивости, мейнстримовости, для всяких языкодрочеров.

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

[@or10n]

во всем виноваты маркетологи :/

[@zapimir]

Скорее в этом виноваты программеры, которые вместо того, чтобы делать классный софт — пишут статьи о плохом php.

[@TROODON]

Самый разумный комментарий за последнюю неделю

[@vmuha]

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

[@VolCh]

Пожалуй, всё же лучше. Эти языки объективно более целостные.

[@Andre_487]

И господство 1С в сфере учета. С Битриксом проще всего хоть как-то настроить интеграцию — не через ручной обмен в XML или CSV, а автоматизированный, по оригинальному и крайне изящному протоколу 1С.

[@9ikopb]

> по оригинальному и крайне изящному протоколу 1С.
> изящному
> 1С

[@Andre_487]

Именно :)

[@vorobiev]

хостингом для php можно считать любой сервер с настроенным apache + mod_php только потому, что у большинства php apps/frameworks нет другой стратегии деплоя кроме как «закачайте файлы на сервер по ftp»

[@VolCh]

Для этого ещё надо настроить ftp. :) Но вообще наличие стратегии «закачайте файлы на сервер по ftp» для подавляющего большинства php приложений — это плюс, и большой плюс.

[@vorobiev]

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

[@VolCh]

Лучше раз в день бэкапиться, чем не бэкапиться вообще. И лучше деплоить по ftp, чем только удаленно работать.

[@ashofthedream]

Думаю мейнстрима, как во всех нормальных языках, не будет еще долго. Хотя, да, что-то начинает вырисовываться (сектор сайтов-визиток, я думаю, эта тенденция не затронет никогда).

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

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

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

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

[@slimus]

а вы symfony 2 смотрели и пробовали?

[@ashofthedream]

Как раз о ней и говорю. И смотрел, и прбовал

[@slimus]

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

[@Aliance]

Возьмем к примеру тот же symfony, как наиболее продвинутый фреймворк

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

[@ashofthedream]

Вы с этим не согласны? Тогда предлагайте свой вариант.

[@VolCh]

Обычно в комментариях пишут своё мнение, а «аксиомы» указывают со ссылками на авторитетные источники ;)

[@ualinker]

Расскажите мне о более продвинутом фреймворке, чем Symfony2.

[@Aliance]

Вам это сделают где-нибудь в «религиозных войнах», но не здесь и не я.

[@youlose]

А выложите пожалуйста пример какой-либо несложной формы с валидацией, чтобы было с чем сравнивать?

[@nfx]

Symfony2 вродь попопулярнее будет сейчас, некий драйвер комьюнити.

[@faost]

На гитхабе популярней (sf2, zf2), разработчики друпал 8 выбирали между этими двумя фреймворками и выбрали именно компоненты symfony 2 для ядра новой версии.

[@nfx]

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

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

[@Ogra]

какой PHP-фреймворк сравниться по количеству гемами для рельсов?

rubygems.org/ — 37 483 гема для Руби (сколько из них для подходят/используются для рельсов? не знаю)
drupal.org/ — 15 583 модуля.
Это, как минимум, «сравнимо». Количество гемов для языка общего назначения всего лишь вдвое больше количества модулей под одну CMS/CMF.

[@nuclear]

Мне интересен именно фреймворк, а не CMS. Как бы Drupal не был похож на обычный фреймворк, это все равно другое.

[@Ogra]

В данном случае — не другое. Потому что многие модули, такие как Views, CCK, Image являются именно «плагинами к фрэймворку». Иначе, я бы говорил о 20 000 дополнений к Вордпрессу ;).

[@Ogra]

Общего больше, чем различий.

[@VolCh]

По сути все более-менее популярные CMS являются фреймворками с набором модулей, включая админку, заточенную на этот набор. Собственно потому они и популярны, что стандартное поведение можно изменить не лазя в код CMS, а перехватывая управление — чем не фреймворки?

[@VolCh]

Про Sharepoint не знаю и за все конструкторы скажу, но которые встречал — нет, свой модуль, исполняемый на сервере и с доступом к среде выполнения самого конструктора не получить

[@pechorin]

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

[@Ogra]

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

[@pechorin]

Лучшая, это потому что поддерживает совместимость с php4? :)

[@Ogra]

Это вы на пару лет с этим вопросом опоздали. 5.2 — минимум.

[@pechorin]

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

[@Ogra]

Drupal 8 требует 5.3, наверное что-то из этого использует. Правда, неизвестно еще, когда он выйдет.

[@Cord]

Главное чтобы не как Перл6

[@pechorin]

Я продолжу — все плагины, которые видел я даже не использовали шаблонизатора. Код друпала хоть на сколько-то покрыт тестами? Там их вообще пишет кто-нибудь?

[@Ogra]

Шаблонизатор не используется в CI, ZF, Wordpress… дальше продолжать?
Код ядра покрыт тестами.

[@Ogra]

К Drupal, тоже прикручиваются с половины тычка. Просто в качестве «шаблонизатора по умолчанию» используется PHP.

[@VolCh]

8-й использует Symfony Components, а значит использует нэймспэйсы, да и замыкания никто не запрещает использовать, как и ООП в 6-м.

[@VolCh]

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

[@Cord]

Это в ней авторы принципиально пишут без ООП в 21 веке?

[@Ogra]

Писали когда-то.

[@pechorin]

Вот это хороший комментарий :) Кстате говоря — я лично наблюдал работу самого высоконагруженного друпала в России ;) Который потом был переписан нами на рельсы. Со стороны юзера все очень удобно, поставил модули (через ssh, а не какой-то там удобный интерфейс, lol) и работай себе на здоровье :)

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

[@Ogra]

Ссылку в студию ;)

[@Ogra]

Я программист, мне нравится.
А медленновато — это да. Правда, до ZF 2 далековато по тормознутости, но неправильной разработкой можно это исправить!

[@jesteracer]

Автоваз — очень популярен, много запчастей, еще больше специалистов. Опять же — дешевле и ездит.

[@vyacheslav_ka]

Согласен с вами. Будучи студентом, подрабатывал делая «сайты на заказ». Большинству заказчиков важным фактором была стоимость, получалось в пределах 200-300 долларов. Им все равно было что будет внутри, главное результат и удобный интерфейс. С моей же стороны нужно было вкладывать в это как можно меньше усилий. PHP с его огромным количеством готовых CMS и просто морем плагинов для них, прекрасно подходит. Лишь тем заказчикам, которым действительно нужно было что то хитрое, масштабируемое и с заделом на будущее, делалось на более серьезных штуках.

[@nuit]

Будучи человеком знакомым с такими студентами, часто приходилось как-то модифицировать плагины для популярных cms под нужды заказчика, тк студенты были не в состоянии сами что-то сделать, но отлично находили клиентов. Так вот, на решение проблем заказчика используя рельсу/джангу и написание небольших сайтов уходило значительно меньше времени, чем сидеть и разбираться в говнокоде этих плагинов.

[@DarthSim]

ИМХО все эти допиливания CMS до нужного состояния — это костыль говнокодович.

[@DarthSim]

Если нужен постоянный допил, то я бы вообще никогда не делал ставку на готовую CMS. У любого решения есть предел расширяемости, и если у фреймворков он почти бесконечен (мы говорим о хороших фреймворках), то у CMS крайне ограничен. Конечно, в тех случаях, когда нужно только добавить пользователю новое поле и разместить на сайдбаре няшную штучку, смысла изобретать велосипед и переписывать вордпресс с нуля нет. Но когда из того же вордпресса пытаются сделать магазин, я хватаюсь за пистолет… Как было сказано выше и ниже, если появляется нужда в допиливании, задайтесь вопросом: а не быстрее ли написать нужный функционал на %frameworkname%?

[@aleks_raiden]

как-то категорично про вордпресс, который давно не только блог — тот блог с которого начиналось

[@VolCh]

Drupal, Wordpress и Joomla вполне себе полноценные CMS, просто в каждой из них прослеживается их родословная.

[@nuit]

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

[@nuit]

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

[@gaelpa]

Не поверите, но ГАЗели. Аккурат выбор небольшого бизнеса.

[@jesteracer]

Охотно верю, просто тот факт, что большинство выбирает что-то не делает это что-то лучше остального(или хуже).

[@Riateche]

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

[@Gorthauer87]

Увы, но иффиктиные манагеры именно так и думают, а решают, к сожалению, они!

[@soomrack]

Почему люди выбирали PHP?
Возможно потому, что он понятнее, чем Perl, и потому, что писать на нем сайты проще, чем на C++.
Все остальные языки 10 лет назад не имели достаточной аудитории, чтобы рассматривать их в качестве кандидатов для изучения с последующим применением к веб-разработке.
А сейчас его выбирают, скорее всего, из-за того, что он доминирует на рынке.

[@Cord]

Ну если Руби с гемами, или Питон с Джангой в 10 раз круче, и существуют в расцвете уже года три минимум (для широкой общественности), почему они не откусили рынок?

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

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

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

Но все возможно… Когда-то правила Альтависта, Яха, Лайкос и Хотбот, рулил Нетскейп, а Гуглеры были студентами-ботанами, работающими над диссером… А потом они запатентовали алгоритм со свистелками и перделками, и все заверте.

[@salvator]

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

[@diamant]

Инстаграм — это, как и Фэйсбук, исключение из правил. Нужно брать обычные веб-проекты.

[@Fedcomp]

хром откусил рынок своей огромной рекламой.

[@rwz]

Руби — сложный язык. Намного сложнее питона и пхп. РоР — сложный фреймворк. За последние пару лет он стал очень newbie-unfriendly.

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

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

[@VolCh]

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

Под качественным сайтом я имею в виду качественный код сайта, потому как дизайн и прочее юзабилити к компетенции php/python/ruby/… программиста не относится.

[@VolCh]

Я как-то делаю один, умудряясь не выступать в роли дизайнера и юзабилиста. Бывает верстаю по макету, а чаще предлагаю на выбор из разных коллекций (в т.ч.платных). Хотя какие-то знания по веб-дизайну есть, но так, для общего развития. И вообще с трудом человека представляю, который сможет и качественный дизайн сделать, и качественный код написать — по-моему совершенно разные способы мышления нужны.

[@TycoooN]

Руби никак нельзя назвать сложным языком. Приведите, пожалуйста, пример, в чем конткретно он «сложнее» как язык, чем пхп?
RoR сложный фреймворк? Думаю, он попроще аналогичных фреймворков на пхп. У него отличная документация, есть масса статей и бесплатных скринкастов в интернете. Не знаю, что там unfriendly.
Или вы сравниваете применение RoR с созданием пары тестовых php-страниц и запуском на денвере?

[@VolCh]

Куда чаще используется функциональная парадигма — проще от этого язык уж точно не становится.

[@rwz]

Документация у RoR — говно. Об этом все коммьюнити ноет последние года полтора как. Райан Бигг вяло пытается ее как-то дописывать, но ему последнее время сильно не до этого, он занят книгой своей. Плюс, она написанна так, как хочет ДХХ, а кроме ДХХ так никто все равно не делает. Пример – Test::Unit. Я давненько не встречал проекта, тесты которого написанны на Test::Unit. В 99% случаев он сразу выкидывается и заменяется на RSspec.

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

Да просто можно посмотреть внутрь того же RSpec. Врядли после этого повернется язык назвать руби простым.

[@rwz]

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

Я очень люблю sass, coffeescript и asset_pipeline. Они реально чудесные и повышают производительность программиста на отличненько. Но я уже много лет во всем этом варюсь и у меня была куча времени вникнуть в эти фичи. А новичок со знанием css/html/javascript/ruby скорее всего обломится.

[@TycoooN]

Не знаю, чем так плоха документация рельсов. Документация по API отлично оформлена, есть очень удобный аякс-поиск. Еще есть отличные guides.rubyonrails.org/… Сообщество руби слишком любит поныть имхо.

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

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

[@serjoga]

Не такой уж сложный. Думаю сложнее настроить сервер под него. А для PHP под Windows есть Denwer и т.д. Скачал установил и начинай писать

echo "Hello world";

[@DarthSim]

Пример в корне неверен. ФФ и хром активно продвигаются в массы, Руби и Питон продвигать нафиг никому не сдалось. Да и как долго ФФ с Хромом что-то там себе отхватили? Еще несколько лет назад IE безраздельно властвовал на рынке, несмотря на давнее существование ФФ и Оперы. Пока, собственно, альтернативные браузеры не начали продвигать.
Вот вам другой «банальный пример»: в мире существует Windows, Mac OS X и Ubuntu. И не смотря на то, что третья неплоха, а вторая прекрасна, с отрывом лидирует первая.

[@gkirok]

некому продвигать Руби и Питон?
да я уже немогу без головной боли на хабр зайти, чтоб не наткнутся на какого нибудь «евангелиста»
а год работы на роре у меня отбил все желание пересекаться с руби сообществом
потому что такого агрессивного продвигания своих «правильных идей» надо поискать
аллергию чес слово заработал

[@DarthSim]

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

[@Ogra]

Покажите хоть один MVC фрэймворк, где такое происходит.

[@gkirok]

| В противном случае получим ситуацию, сложившуюся в PHP-сообществе, когда вставка html-кода в модель или контроллер является вполне обыденным явлением.

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

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

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

[@DarthSim]

> где такое сложилось, я с такими не знаком :)
Да вы счастливый человек!

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

Ммм… пример?

[@gkirok]

> Да вы счастливый человек!
к сожалению не настолько, я видел такое в рор проекте :)

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

как то так

[@DarthSim]

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

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

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

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

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

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

Вы выглядите как слепой фанатик php, уж простите…

[@gkirok]

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

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

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

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

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

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

[@DarthSim]

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

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

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

[@gkirok]

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

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

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

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

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

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

хорошо писать понятный код :)

[@DarthSim]

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

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

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

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

[@Nail]

> Это настолько неестественно для 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

[@VolCh]

Вы хотите сказать, что в RoR нельзя вставить html в модель или контроллер?

[@Roler]

Ну, одно дело — поменять браузер, другое — язык, на котором пишешь.

[@Ogra]

По-моему, C# неплохо так занял место под солнцем ;)

[@Barsik107]

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

[@zapimir]

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

[@Barsik107]

Я вааще не об этом спрашивал. Может вы ошиблись веткой?

[@zapimir]

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

[@Barsik107]

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

[@rednaxi]

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

[@ragus]

напишите простенький аналог erlyvideo или flumotion на php.

[@rednaxi]

PHP это язык для разработки веб-сайтов (PHP: hypertext preprocessor)

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

но предлагать на пхп реализовать сервер для стриминга видео это все равно что предложить на vbscript написать сервер для мморпг.

[@ragus]

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

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

либо крестик снимите, либо трусы наденьте.

[@rednaxi]

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

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

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

[@ragus]

а в чём сложность с онлайн-трансляцией на сайте?

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

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

[@rednaxi]

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

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

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

[@ragus]

>а отдавать контент с сервера будет апач или nginx или какое нибудь специализированное решение.

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

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

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

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

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

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

[@rednaxi]

ну это уже слишком толстый троллинг.

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

прикрываясь пунктом 2 я пытаюсь закрыть глаза на пункты 1 и 3.

[@ragus]

спасибо, поржалъ! 8))))

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

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

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

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

[@VolCh]

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

У php в подобных случаях нет сильных сторон, из-за которых стоило бы использовать именного его. И одна откровенно слабая — нет многопоточности. Реализовать вроде можно, но сложно. А главное зачем?

[@aleks_raiden]

легко — есть такое. Пример: mark.koli.ch/2009/02/07/streamer.phps

[@zim32]

Пишу последние годы на ПХП одни нестандартные проекты. Проблем нет вообще никаких. Полностью всего хватает с головой

[@Davert]

А есть с чем сравнивать?

[@zim32]

Главный вопрос зачем? Лично мне производительность PHP вполне хватает. И я не думаю что другой интерпретируемый язык тут что-то поменял бы в корне. Если уж реально надо получить прирост скорости (5-10 раз) — тогда на джаву смотреть надо. Обычно так и делаем — самые нагруженные демоны выносим на джаву, все остальное — ПХП.

[@fenrirgray]

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

[@zim32]

Ну и в чем проблема. Я использую набор классов из Symfony2 для роутинга и валидации основанной на аннотациях, Twig шаблонизатор, Doctrine для ORM. Почему бытует такое мнение, что раз PHP то это сразу неудобно и говнокод сплошной?

[@ApeCoder]

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

Это играет тем большую роль, чем больше у вас своего кода.

[@ApeCoder]

Напишите на 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>

[@ApeCoder]

ну вот это я и называю «приходится дублировать код»

[@propovednik]

return '<li>'.implode('</li><li>',$array).'</li>';

Не?

[@ApeCoder]

cработает ли implode со строкой?
с множеством?
со множетсвом ключей dictionry?
со можеством его жлементов?

[@Sannis]

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

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

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

[@ApeCoder]

не является ли естественным, что строка — это массив символов?
implode с этим итератором будет работать?

[@Sannis]

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

[@ApeCoder]

>>>Не очевидно, что при передачи строки «abc» в такую функцию в результате будет список из трёх элементов.

Почему? Если вы согласились, что строка концептуально — массив символов, то почму передача такого массива в функцию, которая представляет последовательность в виде списка, не должна преставить эту конкретну последовательность в виде html списка? По-моему это логично, абстрактно и мощно

[@Sannis]

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

[@ApeCoder]

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

[@VolCh]

Для PHP не является. Это скалярный тип прежде всего, который в некоторых ситуациях может работать как массив. Но не во всех. Далеко не во всех, прежде всего приведение (array)$str (как и любого другого скалярного типа) вернёт массив с одним элементом. Отсюда и пляшем при использовании.

[@beono]

> cработает ли implode со строкой?

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

[@ApeCoder]

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

[@zibada]

Не.
С пустым array() будет

<li></li>

[@defuz]

Не. Ответ не верен, если массив пуст.

[@zim32]

function make_list($obj){
for($res = ''; $i=each($obj); $res.= "$i[1]");
return $res;
}

[@ApeCoder]

В документации по each написано что она работает только с массивами — join работает с iterable

[@zim32]

Странная подсветка кода. Вообщем там $res = в li оборачивается. Будет работать с массивами и всем что реализует Iterator

[@ApeCoder]

Странно, я не вижу в доке про iterator там явно написано array, но так как строка — не объект, ей потребуется особое приглашение?

[@Smerig]

А зачем вообще в коде генерировать html?

[@ApeCoder]

во-первых, это просто пример. Можно привести в пример itertools и functools как часть того, что можно сделать еще.

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

[@VolCh]

В лоб:

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 это скорее извращение будет в данном случае.

[@ApeCoder]

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

[@VolCh]

Угу, смотрел, как и в сторону Ruby. Ни один из этих трёх языков не могу назвать идеальным для веба. Вот смешать бы их :)

[@ApeCoder]

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

[@VolCh]

Не совсем в языке — простота разворачивания и администрирования среды выполнения для типовых задач (под пакетными дистрами) прежде всего. Хотя, вроде, стало получше с этим у python и ruby в последнее время. Но пока для меня это главный плюс.

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

[@ApeCoder]

>>>Чисто как в языке — тесная интеграция с HTTP, включая сессии

Нужно ли это прям в языке?

[@VolCh]

Не мешает при использовании не в вебе, помогает в вебе. Почему нет?

[@ApeCoder]

Помогает на одну конструкцию import или больше?

[@VolCh]

Больше, и даже несколько import аналогичной функциональности не дадут.

[@youlose]

конечно не дадут аналогичной, ибо дадут БОЛЬШЕ и более качественной функциональности чем в PHP =)

[@youlose]

Хорошо, я поясню на примере 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. по сути это микрофреймворк, только его не надо настраивать и както определённым образом устанавливать — установил модуль, подключил одной строчкой и небольшой или средний сайт напишешь в очень короткие сроки.

[@VolCh]

use Mojolicious::Lite и всё? То есть это стандартная библиотека? Может и зря 10+ лет назад, выбирая между Perl и PHP, выбрал последний.

[@youlose]

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

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

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

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

[@VolCh]

В том-то и дело, что это не стандартный модуль. Нет, если его файлы можно скопировать куда-то в /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, или запускаются как демон?

[@youlose]

Его можно скопировать в папку с проектом и всё будет работать.

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

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

Сайты на Perl (да и для PHP) у меня работают через FastCGI. Деплою и то и другое я тупо git'ом, ибо это удобно. Так что здесь какого-то преимущества у PHP я не вижу.

[@VolCh]

Так для 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) { ... }), но восторгов это не добавляет.

[@ApeCoder]

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

[@VolCh]

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

[@ApeCoder]

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

[@VolCh]

Прежде всего в синтаксисе и семантике языка, на худой конец в стандартной библиотеке. $_SESSION в PHP — элемент языка. В Python — в стандартных либах не нашёл аналога. Правда от корки до корки описания не читал.

[@Ogra]

Библиотеки, функции, классы, «недублирование кода» — это скилл разработчика, а не фича языка.

[@ApeCoder]

в языке должны быть механизмы для запасания кода.

[@sectus]

Что это за термин такой новый? Раскройте что это за механизм такой есть в одном языке и нет в другом?

[@ApeCoder]

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

По поводу питона и пхп, попробуйте посмотреть на комментарий habrahabr.ru/post/142342/#comment_4764012 и написать такую же функцию, но на PHP. Если захочется поииследовать как работает — можно сходить на www.trypython.org/#

[@sectus]

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

[@ApeCoder]

Мы щас как раз рзбираемся можно ли написать такую же функцию на php. Или придется писать по одной на каждый тип данных.

[@Sannis]

Да, можно написать одну функцию.

[@ApeCoder]

можно увидеть ее код?

[@Sannis]

Написал, что дальше? Вас пугает что она на пару строк длиннее?

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

[@ApeCoder]

>>>Написал, что дальше

Дальше мы посмотрим на их свойства

[@ApeCoder]

>>>И не нужно говорить, что это просто пример

это просто пример.

[@ragus]

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

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

[@zapimir]

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

[@ragus]

а этого человека волнуют дыры в его интернет-магазине? когда его сломают через дыру в жумле/её плагине и уведут персональные данные клиентов. 152 ФЗ не дремлет.

[@VolCh]

А что, использование python/ruby/perl/js/… даёт автоматические гарантии отсутствия дыр? Особенно если писать в «cgi режиме» или свой сервер с ноля, а не пользоваться наработками сообщества?

[@ragus]

ммм… свой сервер «с ноля»? ок. покажете веб-сервер на 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

[@VolCh]

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

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

[@ragus]

простите, а какие 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

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

[@VolCh]

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

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

[@ApeCoder]

>>>что оставлю я или нет возможность sqlinj от языка на котором писать буду никак не зависит.

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

[@VolCh]

C http приходят же строки?

[@ApeCoder]

и что?

[@Nail]

PHP более популярен, поэтому в нем больше находят уязвимостей.

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

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

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

[@Cord]

Викимедиа подходит? Или, например, Фейсбук?

Цукеберг передает привет с собственного острова за пару десятков миллионов.

[@Barsik107]

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

[@kazmiruk]

Уж очень субъективные у Вас ответы. Вы анализировали количество фреймворков в ruby\python? Да и количество программистов не говорит об их качестве. Придет к вам 28 миллионов программистов пхп, но на деле лишь пару процентов окажется действительно программистами, а остальные лишь кодерами, которые «фейсбук» вам не сделают. Python\ruby — более высокий порог вхождения и потому программистов меньше, но их качество выше, а значит выбирать легче. Правда с выводом статьи я согласен. Делал высоконагруженные проекты как на php, так и на python (на ruby не довелось). Мой выбор — php. Да и узкие места при высоких нагрузках вовсе не в написанном на php\python\ruby коде возникают, а в запросах к базам данных.

[@fenrirgray]

Почему php? Действительно ведь в плане нагрузки разница минимальная должна быть между языками, т.к. узкое место это I\O к БД.

[@kazmiruk]

Это чисто субъективное мнение. Боюсь его здесь высказывать, дабы не навлечь на себя гнев python'истов, но раз вы спросили. Python радует простотой и элегантностью синтаксиса… но только до определенного периода. Django мне показался набором каких-то неведомых костылей, а сам фреймворк держит в жестких рамках, предоставляя довольно низкий уровень абстракции по сравнению с yii, например. У php же фреймворки более обобщенные. yii и zf просто дают набор классов и рекомендации, а разработчик делает с ними что хочет. Да и сиподобный синтаксис мне ближе. За 2 года использования питона мне все также кажется нелепым контролировать отступы (хотя все меня убеждали, что это невероятно крутая фишка). Опять же я не могу говорить за все фреймворки и нюансы языка, так как я их просто не знаю (ни php, ни python), но те задачи, с которыми я сталкивался мне было проще решить на php, а, как вы заметили, разница в производительности на продакшене между ними минимальна.

[@samally]

Тоже никак не могу понять «крутости» отступов. Зачем вообще к этому привязываться в языке…

[@mrjj]

Ничего, со временем догонишь какую роль имеет читаемость кода.

[@samally]

ИМХО Читаемость кода не должна быть завязана в синтаксисе языка.

[@ApeCoder]

Почему?

[@kazmiruk]

А кто вам сказал, что делая такие отступы код становится читаем? Мне удобнее читать, когда кроме отступов я вижу начало { и конец } блока.

[@ApeCoder]

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

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

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

С моей точки зрения такая штука должна быть, так как заставляет соблюдать единый стандарт по всему языку — в нормальных командах поверх языка еще есть нечто вроде StyleCop который не дает зачекинить код, не отвечающий принятому в команде стилю. В данном случае, я был бы не против, если бы StypeCop был бы в самом языке.

[@kazmiruk]

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

def asd():
    blablabla
    blablabla2
    if True:
        blablabla3
        if True:
            blablabla4
if False:
    blablabla5

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

[@mrjj]

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

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

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

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

[@kazmiruk]

Вы не забывайте, что пустые строки я могу расставлять и в теле функции, например для отделения смысловых действий. Т.е. мне нужно будет делать 1 отступ в теле и 2 после функции. Где здесь экономия места по сравнению с begin\end? На отступы никто не посягает ) Просто как видно в данном примере без них хуже, чем с ними. И я реально видел такой код. Почему кстати он не очень показательный? Я определил функцию и потом начался основной код (кстати, я не могу вынести функцию в конец файла, что было бы опять же удобней.)

[@danSamara]

Всё познаётся в сравнении:

def asd(){
    blablabla
    blablabla2
    if True{
        blablabla3
        if True{
            blablabla4
        }
    }
}

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

И, кстати, вот такую ошибку в PHP визуально сложно отловить:

<?php
function my(){
    if (true)
        do_something();
        do_another();
}
?>

Только вбивание в голову привычки ставить скобки всегда. А после питона их обилие раздражает.

[@kazmiruk]

Для меня стало лучше. Теперь если за блоком пойдет другой код я сразу по скобке увижу, что он не в теле функции.
А ошибка в пхп… А вам не кажется, что нотификация zend не зря рекомендует так не делать? Если бы Вы здесь поставили скобки, то код читался бы прекрасно. А вот в питоне:

def my():
    if True:
        do_something()
    do_another()

Мне кажется хуже

[@danSamara]

И не только в zend. Меня больше удивляет, что скобки не являются обязательными для IF, аналогично FUNCTION.
Ну а по-поводу скобки vs отступы — у нас просто разные вкусы/взгляды. А спорить о вкусах — дело пустое.

[@kazmiruk]

Ну наконец хоть кто-то услышал меня ) Именно про это я и говорил. Я сказал, что питон мне не понравился потому что для меня он оказался неудобен )

[@p0is0n]

Ничего не хочу сказать против Вас, но мне легко найти. Возможно это просто опыт/привычка?

[@kazmiruk]

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

[@nuit]

Меня вот больше бесит отсутствие некоего 'end'а для оформления окончания блока, чтобы текстовые редакторы могли понимать где и сколько отступов надо вставить. Прям выносит мозг при рефакторинге долбить в таб, переключая уровни отступа в емаксе. В руби как раз end был добавлен только по причине что автор языка использовал емакс и понимал насколько это удобно.

[@ApeCoder]

Не могли бы вы пока зать на примере? Почему редактор, грубо, говоря не может сам держать в уме все эти begin и end — они же однозначно выводятся из отступов?

[@nuit]

а какое должно быть поведение у редактора при нажатии кнопки «сделать правильный отступ для этой строки», если с помощью отступов определяются блоки. Поэтому при нажатии на эту кнопку, редактор начинает переключаться по всевозможным блокам и предлагать различные варианты. А в случае когда блок определяется явными begin/end, то у редактора не возникает никаких проблем выставить нужный отступ при первом же нажатии.

[@ApeCoder]

//«сделать правильный отступ для этой строки», если с помощью отступов определяются блоки

сделать такой же отступ как и у предыдущей строки.

[@nuit]

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

[@Ghostwriter]

> но редактор не может этого знать, тк нет явных границ блоков.

Редактор может определять необходимую вложенность для следующей строки по формальным признакам выхода из блока — return, except, raise, else, eleif.

[@nuit]

except, raise, else, eleif — это всё как бы начало блока ;)
А после return'а емакс определяет конец блока и не прыгает дальше чем нужно.

[@nuit]

return и raise конечно же :)

[@Ghostwriter]

Это не только индикаторы начала блока, но и индикаторы окончания вложенности предыдущего блока.

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

[@Regis]

Попробуйте PyCharm. Он с отступами в Питоне нормально работает.

[@zapimir]

но на деле лишь пару процентов окажется действительно программистами

А чего Вы решили что среди программеров Руби/Питона прям все сплошные гении? :) Как будто если человек пишет на ООП, то он типа не может написать говнокод :)

[@lukashes]

Я, почему-то, не вижу сильного различия в пороге вхождения php и python. Уж если бы я отдал питону 3 года своей жизни, не думаю что я бы знал его хуже чем php за тот же период.

[@kazmiruk]

Я говорю о другой величине. К примеру через сколько вы сможете начать писать что-то адекватное на php и на python. Не знаю как у вас, но втянуться в php с нуля у меня получилось за 3 месяца где-то написания своего велосепеда. С python у меня было все менее успешно, хотя к тому моменту я уже имел опыт программирования. Да и каждый человек индивидуален. Я ведь указал, что это относится только ко мне, так же как и то, что написал автор относится только к нему.

[@zapimir]

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

[@kazmiruk]

Ну ведь здесь речь было немного о другом. Посмотрите сколько сейчас открылось студий веб-дизайна. Я успел поработать в 3 таких. Большинство «программистов» там — студенты, написавшие «форум с нуля на php» и считающие себя крутыми спецами. А потом они приходят в «фейбук» и говорят: «я крут, давайте мне з\п побольше». Несомненно и на php есть выдающиеся специалисты. Просто процент кодеров на php выше, мне кажется.

[@ApeCoder]

Не могли бы вы проанализировать какие особенности питона вам помешали?

[@kazmiruk]

Ну тут уже почти все это упоминалось, но повторю:
1. Неудобное использование ООП. Таскать за собой self по всем методам (не знаю больше ни одного языка. где сделан такой же маразм. Что помешало в питоне сделать по-человечески — не понимаю).
2. Неудобочитаемость кода, когда я вижу кучу отступов, но не вижу четкого конца блока. Кто-то от этого приходит в восторг, но меня такой код угнетает.
3. Нет возможности внести изменения и сразу их увидеть. Приходится постоянно делать лишние операции.
4. Нет адекватного фреймворка. Вернее даже не так. Из тех популярных решений, которые я пытался использовать меня ни одно не устроило.

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

[@ApeCoder]

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

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

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

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

[@kazmiruk]

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

Кто сказал что php мой любимый язык? Просто мы рассматриваем веб. Для веба — пхп мне кажется наиболее разумным. Питонисты любят приводить в достоинства питона всякие фичи (типа как вы с объектами), но согласитесь, что эти возможности очень редко используются в реальных проектах. А фича ради фичи мне не нужна. (приведите пример реального проекта, где python сделал бы что-то такое, чего не смог бы php)
И не пытайтесь переделать всех под себя. Не стали ли вы жертвой этого вашего блаб-парадокса? (первый раз услышал такое понятие)

[@nuit]

>(приведите пример реального проекта, где python сделал бы что-то такое, чего не смог бы php)
Ну тут важно насколько элегантно сделано. Наглядный пример — это убогие ОРМки в php.

[@kazmiruk]

Обогие ОРМ? Чем же они убоги? ) Вы все ОРМ на php перепробовали? А на питоне? Думаете там меньше убогости? И Вы не привели пример. Скорее всего, потому что его нет. А убогость кода связана не с языком, а программистом )

[@nuit]

Ну возьмём наиболее популярные решения Doctrine/Propel(php), SQLAlchemy(python).

и вспоминаем то что вам ненравится :)
>Нет возможности внести изменения и сразу их увидеть.

[@kazmiruk]

По сути между ними разница минимальна в плане возможностей. Ну Вы не поверите: я не использую Doctrine. А знаете почему? Мне кажется он неудобным. Я не могу многого рассказать про него, так как попробовав раз я понял, что это монстр, который на продакшене пускать не стоит. Да и любая ОРМ — лишние запросы в БД. Хотя бы тот же describe. Я предпочитаю Pdo + обыкновенный sql

[@nuit]

Ну мы же не обсуждаем ваши предпочтения.
А про использование/создание инструментов, которые часто используются в веб деве. Для создания dsl'ей тут как бы и питон всосёт, если начинать демонстрировать RSpec, сделаный на руби. Но ОРМки с компиляторами на пхп — это вообще из разряда какого-то геморроя. Ладно там на Java/C++ я плачу удобством за высокую производительность, но php/ruby/python — это все тормозные язычки, где я в последнюю очередь думаю о производительности, а в первую — это удобство использования.

[@kazmiruk]

Разве? А по-моему я уже не раз писал, что выбор языка — сугубо личное и так как между ними нет особой разницы, то каждый выбирает то, что удобно именно ему. Я конечно понимаю, что холивар разжигает огонь в душах, но неужели так трудно понять, что питон ни чем не лучше и не хуже пхп (можете взять другие интерпретируемые языки). Тут дело в том, что мне удобней. Так почему вы пытаетесь меня убедить, что питон мне удобней, если я попробовал и это оказалось не так.

[@Psih]

Когда у вас появляется нагрузка, которую нужно оптимизировать — любая ORM/AR становится убогой. Потому что оно не способно сгенерировать запрос, который может написать человек руками.
К примеру довольно не редко на сложных выборках эффективно использовать derived queries для отфильтровывания лишнего и только потом джойнить данные. Покажите мне хоть одну ORM которая это сделает за меня? Ниодной, потому что это уже не ООП — раз, а два — имея конкретную базу данных я могу использовать её особенности и дополнительный функционал: это может сократить время запроса на порядок, а то и 2-3 порядка; в спечефичных случаях иногда и в сотни раз.

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

[@VolCh]

А если использовать ORM без функциональности DBAL? Запросы писать ручками, а средствами ORM только приводить их результаты/аргументы к модели?

[@nuit]

Когда у вас появляется нагрузка, которую нужно оптимизировать — php/ruby/python становятся убогими. Потому что они не способны отработать риквест с такой же скоростью, с которой сможет Си.

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

[@Nail]

Когда у вас появляется нагрузка, то узким местом практически всегда является БД, а не php/ruby/python.

На фанатов обрушивается ведро холодной воды, и… упс, ORM из объекта поклонения превращается в обузу.

[@pechorin]

Слушайте, вот давайте предметно. 300 rps — это нагрузка?
Причем на обычный http 1.0, а не websocket какой-нибудь.

[@Nail]

С чем конкретно вы не согласны?

[@nuit]

Тут как бы намёк на то что 300rps — это нагрузка у одного из популярных проектов в рунете ;) И они не испытывают проблем с базой данных из-за ОРМа.
Тк либо архитектура самого приложения — гавно, либо людей занимающихся проетками, в которых ОРМ будет обузой можно встретить достаточно редко и в большинстве случаев они понимают почему они отказываются от ОРМа. А для всех остальных ОРМ отлично справляется с задачей и уж лучше пусть будет всё сделано по-тупому, вместо умников, которые думают что могут что-то отоптимизировать, что в итоге выливается во всякий геморрой с кэшами итд.

[@Nail]

Зависит от:
1) что имеется в виду под rps — количество некешируемых pageviews в секунду или то что отдает кеширующий прокси?
2) на скольки железяках это крутится (может у них там ферма из серверов под эти 300rps)
3) объем данных — может там все RAM умещается

[@nuit]

Когда появляется нагрузка перед нами есть множество различных вариантов решения проблемы, которая не ограничивается вертикальным масштабированием какого-нибудь Postgre. И Взяв в руки Си++ можно будет решить те же проблемы на порядки эффективнее(например так как в гугле) вместо того чтобы использовать архитектуру в виде php бэка, суть которого делать sql запросы и рисовать хтмльки.
Я не понимаю что вы хотите сказать, что ОРМ — гавно? ОРМ вполне хороший инструмент для своих задач. В 99% случаев разработки вебсайтов он отлично справится с задачей и человек, который вдруг придёт на смену вам будет только рад тому что тут не гора sql'ой аптемезации.

[@Nail]

ORM — гавно когда база является узким местом.

Удачи вам переписывать хранилище данных на C++.

[@pawnhearts]

sqlalchemy может всё

[@ApeCoder]

1. функциями типа map пользовался постоянно, когда писал на питоне. Имхо достаточно взять любую достаточно навороченную библиотеку типа BeautifulSoup и там можно найти кучу примеров.
2…

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


Знакомо ли вам понятие тьюринг-эквивалентность?

[@kazmiruk]

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

[@ApeCoder]

Дык он может больше и лучше, только это больше и лучше не значит принципиальную невозможность сделать то же самое на брейнфаке.

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

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

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

[@kazmiruk]

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

[@ApeCoder]

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

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

Вот это интересно — вы заводите объект, не зная для чего он вам нужен? Можно пример?

[@Sannis]

В PHP тоже есть итераторы, если что.

[@ApeCoder]

itertools там можно написать? будет ли оно работать со диапазонами, строками, и всем тем что представляет собой концептуально последовательность

[@kazmiruk]

Какой объект? Вы про что? ) Из каких моих комментариев вы вынесли эту мысль? Я говорю, что если мне нужно 'asd' => 2, то я пишу array('asd' => 2), а если мне нужно просто 2, то я пишу array(2). А про «все объект»… И что? Вы мне реальную необходимость этого приведите?

[@EvilBlueBeaver]

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

[@kazmiruk]

Да, в курсе. А как это реализовано в php Вы в курсе? Я, например нет. Может там все не так плохо как вам кажется. И вы опять говорите не о том.
1. ЯП — в исключительных ситуациях является узким местом в реальных проектах
2. Если не заморачиваться по поводу 20 мс выигрыша в скорости работы, то я выберу то, что мне удобней.
3. Если ваш код делает что-то тяжелое и разница в работе python\php существенна, то может стоит подумать о том, чтобы такой код перенести на что-то действительно производительно? Например Си.
Примерно таких пунктов я придерживаюсь. пхп — фронтенд, С++ — критичный по скорости бекэнд. На питоне я обычно пишу прототипы скриптов. Действительно быстро и удобно. Но для увеличения производительности я выберу C++.

[@EvilBlueBeaver]

1. Вы знаете, а многие ли любители пхп знают это?
2. 20 мс например в моем случае очень даже неплохо так.
3. Если мой код будет заниматься числодробилками, то я возьму к примеру numpy. но когда кто-то например вместо ассоциативного массива использует обычный массив и каждый раз ищет объект полным перебором, то меня это коробит. как впрочем и когда наоборот, массив объектов пихает в ассоциативный массив, когда заранее понятно, что по ключу они дергаться не будут.
4. Я считаю, что если написано array, то это должен быть именно массив, а не ассоциативный массив, пока я этого явно не напишу. вот вы подразумевали обычный массив и писали по индексу, а в другом месте другой программист этого не знал и стал писать по строковым ключам и у него это прокатит.

[@kazmiruk]

А «ваш случай» в чем заключается. Для числодробилок я бы все таки выбрал С++ )

[@EvilBlueBeaver]

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

[@kazmiruk]

Кто сказал что мне лень? Просто мне лень использовать все «нужные» структуры питона вместо использования «нужных» структур пхп. Тем более приобретя эти нужные структуры я потеряю удобство и понятность. Достаточно нагруженный это какой? У кого-то нагруженный — 10000 посетителей в день, а у других — 500000 )

[@EvilBlueBeaver]

пару тысяч в секунду, так устроит? сразу скажу, не веб в чистом виде

[@kazmiruk]

Ну не слабо. Просто стоит разделять: основная нагрузка на запросы к бд идет или при обработке данных. Вы хотите сказать, что пхп не справлялся бы с такой нагрузкой? А если критична скорость работы прямо до миллисекунд, то я вообще не считаю интерпретируемые языки разумным выбором. Быстрее С пока еще ничего не придумали на высоком уровне. А если все совсем печально и вы боретесь за доли милисекунд, то пишите на асме ) Но не стоит говорить, что пхп медленно, я буду писать на питоне. он быстрее. Я участвовал в таком проекте ) Мне было смешно, но мое мнение никто не спрашивал ) В итоге сейчас этот проект все также загибается от нагрузок, а потрачено 2 месяца на переписывание.

[@EvilBlueBeaver]

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

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

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

[@VolCh]

Насчёт неудобства пхп по сравнению с питоном спорно, особенно если рассматривать «коробочные» продукты, предназначенные для установки неквалифицированным пользователем.

[@EvilBlueBeaver]

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

[@VolCh]

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

[@kazmiruk]

«получить\сохранить данные в бд» вы сталкнетесь с тем, что при увеличении кол-ва данных вам понадобиться увеличение количества серверов с бд. А это не просто скопировал и запустил еще один. Это шардинги, рапределение нагрузки и т.п. И поверьте увеличение производительности в полтора раза (15 мс для вашего пример) вам покажется никчемным. Я, например разницу в 15 миллисекунд не замечу на глаз. А по поводу кол-ва серверов — сомнительно утверждение ) Задача, которая выполняется на одном сервере 30 мс на двух тоже будет выполнятся 30 мс, но параллельно смогут работать 2.

[@EvilBlueBeaver]

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

[@kazmiruk]

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

[@EvilBlueBeaver]

может я неправильно выразился. простой бенчмарк показал, что за секунду пхп успевает обработать где-то в полтора раза меньше запросов(точно не помню, давно было), чем питон при полной загрузке проца (с учетом xcache). если учесть, что время выборки из базы фиксировано как для питона, так и для пхп, то получается, что питону надо меньше процессорного времени, чем пхп. то есть 2 сервера на питоне обработают столько же запросов, что и 3 на пхп.

[@nuit]

>вы в курсе, что массивы и ассоциативные массивы это разные структуры данных?
немного не в тему, но просто тут на днях пришлось на питоне делать такой изврат, который на Си делается элементарно. Суть была в том что нужно было каждой ноде в даг графе присвоить битовый вектор для определения принадлежностей нодов к разным группам. Так пришлось брать листы, состоящие из True,False вместо какого-нибудь обычного BitArray'а, с которым элементарно работать на Си. Попытки оптимизировать различными способами, и даже прикручивание Сишного кода на моей задаче не давали особого прироста производительности, только уменьшали потребление памяти, что пришлось оставить так как есть :) Пришлось дописать комментарием что понимаю что код убог, но не вижу варианта как сделать лучше.

[@EvilBlueBeaver]

pypi.python.org/pypi/bitarray/0.3.2
не?

[@nuit]

>pypi.python.org/pypi/bitarray/0.3.2
на моей задаче было в ~2.5 раза медленее при использовании bitarray.

[@ApeCoder]

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

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

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

codepad.org/dRTXxV1U

Теперь оно работает вообще со всеми объектами, у которых есть метод __str__ включая встроенные

[@kazmiruk]

Каким другим? Не понимаю Вас.

А по поводу примера… А зачем? Вы реально работаете с другими объектами кроме строк в проекте? Максимум с числами, но на пхп это еще проще реализовано. Мне трудно представить реальную необходимость работы с другими типами данных. Как фишка языка — очень даже интересно.

[@ApeCoder]

А бизнесобъектов вы не делаете? Типа там Заказ, Пользователь прочее?

[@kazmiruk]

Во-первых, комментарий ниже ) А во-вторых: делаю, но с трудом могу себе представить ситуацию, когда мне понадобится обработать Заказы и Пользователей в одной куче ) Я напишу 2 различных обработчика для этого случая.

[@ApeCoder]

То есть у списка заказов и у списка пользователей нет ничего общего?

[@kazmiruk]

А что у них общего? ) Это две разные сущности. Можно найти сходство, но чтобы им воспользоваться — не знаю какой должен быть случай )

[@ApeCoder]

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

[@kazmiruk]

У самолета и гвоздя тоже дохренища общего ) Они оба из металла )

[@ApeCoder]

и для работы с ними использут ту же физику и химию :)

[@nuit]

В php есть magic function __toString() и это очень полезная вещь.

[@p0is0n]

Блин.

[@p0is0n]

Глупый пример, я пишу и на пхп и на питоне.

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

[@ApeCoder]

я пхп знаю поверхностно — может вы подберете пример получше?

[@hlx]

Так если вы знаете его поверхности, то зачем сравниваете и спорите? Сравнивать наличие различных функций блаблабла напоминает как на «пацаны» на «тачках» стоят с открытыми капотами и мерятся «письками», хотя любая машина, навороченная или нет, свою основную функцию транспортную функцию выполняет.

[@ApeCoder]

Так веселее! Для вас машины все одинаковы?

[@hlx]

Нет конечно :) Но кричать друг другу «У меня есть такая функция, а у тебя нету, а еще я могу написать функцию на 1 строчку меньше» это как, по аналогии с машинами — «У меня есть кондиционер, а у вас нету. Вы все плохие. Как можно ездить в машине кондиционера? А еще у меня есть парктроники. У Вас их нет?! Зачем тогда жить?» :)

[@gkirok]

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

[@ApeCoder]

Насколько я понял магические методы это весьма ограниченный набор методов — в python это просто методы классов, они есть у int и у str. Базовые операции сделаны ими (в любой момент времени можно получить функцией dir список методов переданного объекта) и вы можете при желании передать в код, например не число, а свой объект который придаст коду новый смысл, например, вмеcто простого выполнения странслирует в SQL (наподобие LINQ).

[@Psih]

Вы вот не в курсе, что в PHP массивы это hash-map.

[@ApeCoder]

Не, про это я был в курсе — я пытаюсь понять, какая в этом выгода

[@kazmiruk]

Не мог не скинуть Вам этот баян )

[@p0is0n]

Скорее дело в другом, когда хомячок захотел стать программистом, он начинает писать (с вероятностью в 99%) на пхп.

Через несколько дней он считает себя уже хорошим разработчиком сайтов… и +1 к 30 миллионам резюме по запросу «пхп резюме».

[@eydemidov]

Порог вхождения это ведь не только «сложность» языка. Можно купить книжку «PHP для чайников за 21 день», накидать «сайт» и гордо назвать себя PHP программистом. Сомневаюсь, что такое вышло бы с Python'ом или Ruby.

[@kazmiruk]

Спасибо, именно это я и пытался донести )

[@Silaev]

Проходишь туториал (который заводит чуть дальше «Hello World», на примере руби-учит делать «твиттер») и гордо называешь себя Ruby программистом?

[@kazmiruk]

Твиттер на раби? Не видел такого туториала ) На рельсах — да.

[@bezumkin]

По моему, это только в плюс PHP.

[@eydemidov]

А я нигде и не говорил, что это какой-то минус языку о_О

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

Вбил потенциальный программист в гугол «как делать сайты», нашел про html и php, скачал/купил книжку, поставил Denwer/LAMP, создал файл «privet_mir.php» и все, пиши не хочу. И все последующие проекты выглядят так же просто и понятно — создаешь php файлики да пишешь.

[@kazmiruk]

Неужели так сложно прочитать внимательно? Я не говорю что это минус пхп. Да, язык легок в освоении. Но именно поэтому в нем столько говнокодеров.

[@kazmiruk]

Эх… Вы кажется отказываетесь читать. Я про это и говорю. Автор привел в плюс пхп то, что на нем больше программистов. Я же говорю о том, что количество программистов — не основополагающий фактор. Главное их качество.

[@Ogra]

Количество — простой фактор, его можно посчитать.
А вот качество — сложный. Докажите мне, что средний программист на Python лучше, чем средний программист на PHP. Только реальными фактами, а не домыслами ок? Или еще лучше — сравните время, которое требуется на то, чтобы найти трех программистов на PHP и трех программистов на Python с адекватным качеством работы. Я вот не знаю, как такое считать — только эксперимент устраивать ;)
Любые разговоры о факторах, которые нереально просчитать — лишь спекуляция.

[@kazmiruk]

Я знаю, что когда мы искали php программиста, то из 10 соискателей к нам приходило: 5 студентов, ничего не знающих про детали разработки, 3 — те кто разобрались в joomla или другой cms, и только 2 — более-менее адекватные. А вот когда был набор python — программистов (проект переписывался с php на python из-за того, что питон «быстрее». решение не мое и меня никто не спрашивал согласен ли я с этим), то после собеседования с 4 мы взяли на работу 3 и закрыли вакансию. Может нам повезло просто )

[@danSamara]

Нет, это не везение — описал похожую ситуацию комментом ниже.

[@danSamara]

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

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

Резюме — да, программистов на PHP гораздо больше, но выбор от этого не становиться легче.

[@kazmiruk]

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

[@fenrirgray]

>Мое мнение — на Python ООП реализовано в разы хуже, чем в php.

Я понимаю конечно, что это всего лишь ваше мнение, и все такое, но право слово… В пхп просто есть прикрученное сверху ООП. А питон — объектно-ориентированный язык. Уж где, где, а в питоне ООП реализовано в полном объеме, в отличии от того же пхп, где даже замыкания вон только в 5.3 появились.

[@kazmiruk]

Ну я не против. Но то что он изначально объектно-ориентирован не говорит о том, что ООП в нем реализовано хорошо. Чего стоит хотя бы таскание за собой по методам self в атрибутах.

[@EvilBlueBeaver]

Таскать self как по мне, так это потрясающе. Больше не надо разбираться, локальная это переменная или поле класса. Не надо вырабатывать стиль, как писать this.<> или просто <>. Все четко и понятно. Опять же, нет этого самого магического this.

[@ApeCoder]

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

[@LE0N]

<?php
class Blabla {
 public function blabla() {
   var_dump($this);
 }
}
?>
Blabla::blabla()

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

[@Sannis]

Да, есть в PHP косячок со статиками — при ошибках выдают максимум варнинг.

[@kazmiruk]

А может стоит как-то подумать над тем, чтобы не называть переменные также как поля класса? )

[@kazmiruk]

И появился этот самый магический self )

[@nuit]

> Чего стоит хотя бы таскание за собой по методам self в атрибутах.
neopythonic.blogspot.com/2008/10/why-explicit-self-has-to-stay.html

[@kazmiruk]

Вернее я понял про что Вы. Велась речь не про релизацию самого ООП, апро удобство его использования. Думал просто что это будет понятно между строк )

[@fenrirgray]

Удобство использования — вещь сугубо субъективная же… Вам удобней в пхп — ну и замечательно :)

[@kazmiruk]

Если вы внимательно прочитаете мой коммент, то заметите, что я и говорил о сугубо субъективном мнении. Потому что говорить и глобальном удобстве для всех — разжигать очередной холивар. Да и глупо как-то.

[@EvilBlueBeaver]

Замыкания вообще каким боком к ООП?

[@xmeoff]

>>> Да и количество программистов не говорит об их качестве.
Дык ТС и не делал выводов о качестве программистов из их количества. Про качество там вообще ни слова. Речь в основном о конкуренции на рынке и ценах на нем с точки зрения заказчика. А вывод в том, что php в этом смысле намного привлекательнее, для обычного заказчика.

[@kazmiruk]

А потом ТС говорит о том, что «фейсбук» проще сделать на php, так как и программистов больше (тут возникает вопрос об их качестве) и cms есть крутая.

[@emelezhik]

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

[@samally]

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

[@SamDark]

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

[@mrjj]

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

[@SamDark]

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

[@Eternalko]

> Придет к вам 28 миллионов программистов пхп, но на деле лишь пару процентов окажется действительно программистами

Про нормальное распределение слышали? (:

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

Так везде и всюду. Гаусс рулит )

[@mrjj]

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

[@Eternalko]

Боюсь, что из школьной программы узнают сейчас все меньше и меньше. Какой там гаусс…

[@Seekeer]

>Голливуд снимает лучшие блокбастеры потому что там снимают в 10 раз больше проходных фильмов.
Для интереса погуглите, сколько фильмов снимается в Болливуде и сравните с Голливудом:)

[@Eternalko]

И?

[@fenrirgray]

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

[@Cord]

Да, Джанго охуенный, это правда

[@RockPresident]

В PHP есть Symfony, которая тоже очень удобная. (Может быть есть и получше, но не по наслышке знаю именно про Symfony.)

[@fenrirgray]

Мне лично yii куда больше нравится, попробуйте)

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

[@mrjj]

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

[@Cord]

Зенд? Вы так говорите, как будто это что-то плохо.

[@ashofthedream]

Долго работал с зендом, много что приходилось делать на нем нетривиального. И если mvc в нем еще ничего, то все остальное… напильником-напильником. Такое ощущение что два компонента, которые по идее должны использоваться вместе без особых проблем, делались в разное время разными людьми с разным пониманием миробытия, и поэтому необходимо либо писать кучу glue-кода, либо свою обвязку и использовать ее. С локалями такая жопа была точно, такое ощущение, словно локали в зенде — нечто чужеродное.

[@Cord]

Да, в изящности Зенд нельзя упрекнуть

[@ashofthedream]

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

ZF — это несомненно j2ee way, от которого даже сама ява постепенно начала отходить, потому как немыслемо тратить десятки строк кода (без учета хмл-ных портянок) на всякую ерунду. В яве это заменили аннотациями — теперь простые вещи делаются хоть как-либо просто, зачастую вообще однлй аннотацией. В пхп альтернатив нет, поэтому зенд будет продвигать престарелого EE монстра и дальше.

Symfony. Жалкая копия Spring. Жалкая во всем — по функционалу не дотягивает, на противопоставление ee-миру тоже. Но они хотя бы попадают в тренд, осталась самая малось — начать

[@Cord]

Ну вот. Еще лет 5 назад PHP бы и не подумали с Явой сравнить, сегодня говорят как о равных, и не вы — первый.

[@ashofthedream]

Мир меняется:
Пять лет назад и ява была другой, помню году в 2006-м увидел проект на яве: фабрика на фабрике фабрикой погоняет, несколько тысяч строк кода всевозможного, а толку никакого. Я примерно тоже самое в каше из php + js + html в одном файле сделал на 300 строк.

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

А по поводу сравнения отписался комментом ниже.

[@ashofthedream]

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

Doctrine — клон hibernate и точка (точнее точка и немного nosql). Ребята молодцы, постарались притащить аннотации, в остальном же такой монстр врядли кому-нибудь потребуется.

[@mrjj]

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

[@kmike]

Про количество фреймворков (и другого кода) — чушь. По ощущениям (когда несколько лет назад с php на питон перешел) — количество готового кода и экосистема у того же питона уж получше, чем в php.

php pear: 586 пакетов;
pypi.python.org 20000+ пакетов:
rubygems: 37000+ гемов;
cpan: 25000+ distributions.

гитхаб (видимо, % от общего числа репозиториев):

JavaScript 20%
Ruby 15%
Python 9%
Shell 8%
Java 8%
PHP 7%

По-моему тридцатикратным преимуществом php близко не пахнет.

[@Cord]

Да, если погуглить по репозиториям, разные цифры.

Но давайте посмотрим на коробочный софт:

www.hotscripts.com/
Ruby on Rails (99)
Python (141)
ASP.NET (1,873)
Java (1,842)
PHP (17,561)

[@Cord]

Но вообще ИМХО самый отцовский это CPAN. Я давным давно три года писал на Перле, прикольный язык.

[@friday]

Это говорит только о не раз уже доказанной неистребимой тяге пхп-программистов к велосипедостроению. В то время, как большинство программистов делают работу за деньги, попутно обобщая, выделяя части кода в модули и делясь наработками с сообществом, толпы школьников, прочитавших «РНР за 21 день», каждый день пишут новые революционные мегафреймворки/супер-пупер-цмс/форумы/галереи/скрипты-всё-в-одном®, которые представляют из себя по сути чёрные ящики с прибитой гвоздями веб-мордой, неспособные интегрироваться ни с чем без (порой основательной) правки кода. И эти поделки никакого отношения к коробочному софту не имеют.
Я не спорю, есть и весьма достойные проекты на пхп, но тем не менее, общая картина именно такая.

[@zapimir]

Типа в гитхабе нет заброшенных корявых проектов.
Что касается гемов и пакетов, толку от их количества, без привязки к реальному использованию? Да один WordPress может юзать больше народу, чем юзает все эти 40 тысяч гемов… Да и большая часть этих гемов дублируют функционал друг друга, толку с них.

[@or10n]

на гитхабе много руби проектов, т.к. гитхаб сделан на рельсах и по сути является основным репозиторием в мире руби.
на том-же google-code или bitbucket ситуация будет другой.

[@Mox]

Но, я подозреваю, что если вместо «просто программистов», брать «программистов, освоивших хоть какую-то систему контроля версий», что вообщем хоть какой-то маркер уровня культуры разработки, соотношение между PHP/Python/Ruby кодерами будет не так уж в пользу PHP

Да, на bitbucket инетерсно было бы посмотреть статистику

[@CyberAP]

Для форумов ещё и XenForo есть.

[@zapimir]

Да форумов на php вообще десятки.

[@CyberAP]

А хороших в плане кода и интерфейса?

[@zapimir]

Качество кода вещь весьма субъективная и мало кого из владельцев форумов очень интересует.

[@Sannis]

Напишите статью про хорошесть XenForo, очень интересно почитать.

[@lukashes]

Вообще не понимаю откуда столько ненависти между разработчиками на разных языках? Господи, зачем так низко опускаться (не про этот топик), кто-то пишет на PHP и действительно хорошо пишет и даже горд этим. Есть люди, которые другие языки считают неплохими. Это все напоминает анекдот, когда у деда 90 лет спросили: «Дед, вот ты столько эпох разных застал, скажи при ком из вождей лучше жилось?». Ну дед и ответил, что лучше всего жилось когда он был молодым.

[@ApeCoder]

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

[@lukashes]

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

[@ApeCoder]

Вобще-то, я про встроенные функции самого php :)

[@ApeCoder]

>>>Т.е. если меня в целом устраивает PHP, и я не вижу ниаких особых «неряшливых концепций» — я, по вашей оценке, «нетребовательный лох»?

Я говорил не о свой оценке, а о подходе авторов стандартной библиотеки.

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

Есть другой подход — доабвить например новые возможности, на старые написать предупреждения и постепенно привести в стройность то, что есть. Я не знаю, есть ли в PHP концепция depreciated как в java и python

[@VolCh]

Есть.

[@ApeCoder]

>>>Как вы умудряетесь вообще критиковать PHP, не зная о нем таких базовых вещей?

Для того, чтобы критиковать вообще ничего знать не надо, при желании :). Лет пять назад, мне надо было подкурочить одну CMS на PHP и я почитал про базовые конструкции. У меня осталось весьма гаденькое впечатление от того, насколько неаккуратно и самонесогласованно все сделали.

Интерсно, почему не приняли общую схему для всего что упомянуто в разделе ‣Chunks of the library are wildly inconsistent from one another. и не сделали depreciated для всего остального?

[@RockPresident]

>Большинство — оно не всегда право, конечно.

Я считаю что здесь вопрос всё-таки не в том кто «прав». Потому что нету никакой правды, нету никакого точного ответа «какой язык лучше». У всех своя точка зрения, а Haters gonna hate.

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

Как многие здесь заметили, если чуть-чуть захотеть, найти питон кодеров тоже не проблема, хорошо, их меньше, но найти-то всё-равно несложно. И хостинги тоже можно найти. Ну может их в 2-3 раза меньше, но их всё равно тысячи!

И большинство фреймворков которые автор привёл — они бесплатны. Они писались энтузиастами, в своё личное время. И поэтому экономическая составляющая не могла так сильно воздействовать на выбор языка. Чтобы написать что-то типа wordpress, конечно не нужно быть семь пядей во лбу, нужно просто иметь голову на плечах и если бы был язык который по всем параметрам был в 10 раз лучше PHP (но немного менее распространён), то все эти люди пишушие бесплатно на него сразу же бы пересели! Но этого не наблюдается.

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

[@KonstRuctor]

>Как домохозяйки выбирают Windows.
Знаю двух домохозяек, которые открыли для компьютер, получив в подарок MacBook Air или iMac. До этого все попытки подружить их с компом (Win XP, Win7) не увенчались успехом. Сейчас с компьютером не расстаются. Кстати, друг друга не знают, просто мои знакомые и знакомые знакомых. Это к слову о домохозяйках.
Про PHP: в далеком 2002 увлекся созданием сайтов, пытался писать скрипты на Perl. Друг подкинул идею посмотреть в сторону PHP, это было что-то! Обожаю этот язык. Хотя кроме PHP знаю JavaScript, но он любимым пока не стал :-)

[@Cord]

+100500
эппл рулит

[@Cord]

в плане интерфейсов

[@hazg]

Люди делятся на три категории: завистников, гордецов и прочих

работаю в основном с ROR, но чтобы бложик развернуть (угу, типа как за 15м у Раина) — лучше поставлю вордпресс, и не побрезгую допилить плагины. Вовсе не побрезгую, благо движок 100% покрывает потребности, удобен и вылизан… и не он один.

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

[@RockPresident]

Ну если хочется свалить, сваливайте! Меня к примеру бесит что в питоне можно забыть один пробел где-нибудь и программа перестанет работать, потому что там индентация семантическое значение имеет. А кому-то нравится. Суть в том что объективно можно только оценивать статистику фреймворков, скорость и т.д. (хотя и это не очень хорошее определение того насколько язык «крут») — а по статистике PHP выигрывает. Если хочется пересесть — пересаживайтесь, зачем статьи плодить? (Я не говорю что это вы конкретно интернет статьями против пхп заполняете, я говорю в общем, что что такие разговоры это как сравнивать кому какой больше цвет нравится.)

[@hazg]

Увы. Я субъективен. И да — это мой мизинец противится, о чем я в комментарии развернуто написал. Комментарии для того и созданы?

>> а по статистике PHP выигрывает
да — однозначно.

мне писать на руби на порядок приятнее чем на PHP. Мне, и только мне.

[@cuhuak]

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

[@sectus]

указательным

[@cuhuak]

по мне так, одинаково удобно :)

[@Ogra]

Шифт то при этом нажимается мизинцем.

[@weirdan]

Но другой же руки.

[@hazg]

Я наверно неточно выразился, сорри. Конечно речь шла о шифте+мизинец. Тем не менее виновник распальцовки — доллар.

[@mrjj]

проблема не в долларе, а в том, что по изначальной задумке это шаблонизатор.

[@nvbn]

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

Ха, а теперь ещё нужно всё это бесшовно интегрировать, затрат будет не меньше.

[@aldefalco]

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

[@gkirok]

| Но время движется вперед, и рано или поздно веб сайта становиться мало. Нужно более сложное и комплексное решение — проект состоящее из 10000000 строк кода и человеко-часов.
| И использование PHP в этом случае вызывает сомнение.

на гораздно раннем этапе начинают использовать один из php фрэймворков :)
вам ведь не придет в голову писать большой веб проект на чистом руби или питоне? :)

[@artishok]

Битрикс и джумла для сайта-визитки?

[@Cord]

На Жумле сайтов-визиток овер9000

[@diwms]

Мне кажется, что просто зря Вы лишний раз холивар развели…

[@Zeldan]

Господин Cord что это у вас за мода на ночь заводить топик про PHP с добротным холиваром, а под утро его убирать? Вот я вчера обсуждал, а сегодня лень. Некрасиво поступаете…

[@Cord]

См.почту

[@chEbba]

Может хватит?

[@Cord]

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

Так что мнения бывают разные :)

[@grossws]

Вспоминается cgit (веб интерфейс к гиту). Очень напоминает перловый gitweb (который поставляется по умолчанию). Написан на C. Под CGI вообще без разницы, если стандартными средствами можно прочитать env-переменные и стандартный ввод и писать в стандартный вывод.

[@iXCray]

Пробовал и продолжаю использовать (не считая языков верстки/разметки/веб-скриптов и флеша): php, python, C++, vhdl, RoR, perl. Есть опыт разработки многопоточных приложений, высокоскоростных расчетов на CUDA.

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

Самое главное — адекватный подход к задаче и трезвая оценка соотношения качества и потраченного времени. При правильной архитектуре что сервис на php+memcache/redis, что на RoR — будут летать практически одинаково, за микросекундами пусть бенчмаркеры гонятся — цель не в них, а в конечном продукте.

Когда гнался за микросекундами, использовал C++, assembler и CUDA, тщательно изучая железо, на котором планировалось работать. Здесь вообще все ваши языки глубоко и упорно курят в сторонке. Это я еще VHDL не приводил в пример. К слову, нашел специалиста и для этой задачи всего за неделю.

Учитесь считать в деньгах (ну или в попугаях, кому как нравится).
Я считаю так: есть задача, я могу ее решить, используя различные технологии.
У меня _всегда_ на руках несколько вариантов. Можно и Django, а можно и php.

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

Время = деньги. Чем меньше времени затрачивается для решения задачи (без костылей!), тем больше я получаю попугаев в час — все просто.

Что касается именно PHP: на нем можно сделать все, что угодно, включая десктопные приложения, высоконагруженные сервисы только эффективность разработки (лично моей) для таких задач по сравнению с RoR/python может быть ниже, поэтому выбор падет против PHP. И наоборот: сверстать страницу и собрать веб-сервис каких-нибудь TODO-задач на php занимает для меня 5 часов, а на python/RoR/C++ гораздо больше, и не потому что они такие плохие, а потому что из опыта я уже еще во время верстки могу сразу прикинуть, где какие фреймворки можно использовать, насколько они будут эффективны и проч.

Поэтому все ваши холивары — пустое месево. Пока вы спорите, враг качается ;-)

[@Xobb]

Именно так. Каждая отдельная проблема решается одним инструментов быстрее, а другим медленее. Эффективность должна всегда быть решающей при выборе того или другого ЯП.

[@VolCh]

Кто его должен выбирать — вот в чём вопрос. Владеть всеми инструментами на хорошем уровне невозможно. А говорить заказчику «тут не php-нужен, а lisp, но я его не знаю, а потому — до свидания» как-то странно.

[@EvilBlueBeaver]

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

[@VolCh]

Если могу написать — почему нет? Или на пхп принципиально её нельзя написать? (предположим, что жёсткая реалтаймовость и различные сертификации не нужны). Скажу, что писать её буду столько-то с таким-то рейтом. Предупрежу, что раньше их не писал и готовых не встречал. Дальше пускай заказчик решает.

[@iXCray]

o_O

я вас боюсь и опасаюсь найти на просторах вакансий, если у вас действительно такой подход :D

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

[@VolCh]

Как мне кажется, что совсем не «дополнительно подразумевает», а подобные вещи чётко зафиксированы в ТЗ, хотя бы в виде ссылок на ГОСТы, ISO, требования МАГАТЭ и прочие регламенты. Я их не знаю и потому не могу сказать, выполнимы ли они на php. Интуиция подсказывает, что нет, но если окажется, что выполнимы (пускай и «дрова» для реактора надо будет на C писать, как и для любого языка, у которого нет доступа к железу), то почему нет? Может кто-то где-то сможет написать такую программу на другом языке эффективнее, но я точно буду писать её на PHP, как раз потому что это не поле для экспериментов и набивания руки и если я буду писать на другом языке, то с большей вероятностью пропущу подводный камень.

[@Cord]

>хотя бы в виде ссылок на ГОСТы, ISO, требования МАГАТЭ и прочие регламенты.
Прикольная шутка

[@VolCh]

Даже в ТЗ на урну или скамейку есть ссылки на ГОСТы. Неужели их не будет в ТЗ на ядерный реактор?

[@Cord]

Мне просто понравилось, как звучит.
Вроде как у Экслера, вроде: «землетрясение, авиакатастрофа, падение индекса Доу-Джонса»… :)

[@Xobb]

Это наверное отличает программиста от кодера, что даже если программист не знает конкретный ЯП он сможет за адекватное время подготовится, спроектировать и построить систему на этом ЯП. Также, скорее всего, если вы не знаете lisp и его возможности, то тогда не будете иметь представления, что конкретная проблема на нем решается эффективнее чем на том же php.

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

Все здесь имхо конечно.

[@VolCh]

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

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

[@Xobb]

Ваша точка зрения тоже не лишена логики. Разница наверное заключается в том, что мы выходим с разных начальных условий. Развивая пример с врачом, который вы предложили: когда ко мне прийдет заказчик и скажет: знаете, у меня есть система на RoR/Django/Symphony2 (нужное подчеркнуть) и ее нужно отремонтировать — тогда я буду ремонтировать. Но когда видно, что система находится в ужасном состоянии и ее нужно переделать для того, чтобы она начала удовлетворять требованиям бизнеса, тогда (думайте сейчас об трансплантации печени) я все-таки порекомендую обратится к хирургу или, если мой уровень опыта позволит мне с допустимым риском взяться, за проект сделаю это сам.

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

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

[@VolCh]

Так никто не говорит, что надо браться за проекты, которые с большим риском не потянешь. Я в последнее время предлагаю четыре варианта на выбор: CMS (если есть смысл), голый php, symfony и RoR, с разными сроками и ценой — в последнем случае сроки больше всего, а цена такая же как в предпоследнем. Последний никто не выбирал ещё.

[@Xobb]

В таком случае, если я правильно понимаю, мы подходим к вопросу «чем php предпочтительнее X?» со стороны разработчика — так как намного легче найти заказ.

[@Gorthauer87]

Ничего, эта стена рано или поздно рухнет, когда другие ЯП или фреймворки наберут критическую массу, тогда PHP отправится в след за Delphi и COBOLом на свалку истории, а Н. отберёт победу у ВВП.
Законы эволюции суровы, но справедливы, побеждают более совершенные системы.

[@Cord]

Я бы с удовольствием увидел Питон на этом месте

[@Cord]

Любимая картинка в тему

[@zapimir]

Да вы что, их всех порвет GO c Dart'ом, они же сделаны корпорацией добра :)

[@mrjj]

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

[@Gorthauer87]

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

[@SamDark]

Отлично. Нафиг эту многопочточность. От неё в большинстве случаев только проблемы.

[@mrjj]

Ага REST — дешево, сердито и понятно

[@KlonKaktusa]

Совершенно с вами согласен, erlang во все поля!

[@mrjj]

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

[@ping]

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

В PHP действительно есть немало странных идеологических решений, которые «воспитывают» программистов с мыслью, что так и должно быть и это нормально; но если пропагандировать правильные подходы в программировании и правильные ЯП, которые заставляют писать код верно, то вся IT индустрия от этого только выиграет.

А говорить что «мы привыкли» и «фигня конечно, но ведь всегда так было» — это средневековье и закостенелость :)

[@Eternalko]

Правильный подход менеджера.

[@exdee]

Узнал о волнениях вокруг php после публикации перевода одной статьи на хабре. Если абстрагироваться от темы языка, то я воспринял её как обзор китайской одежды abibas. тонны негативных оценок по каждому пункту одежды, то там пуговицы разные, то рукав отваливается, если ширинку застегнуть, и т. п.
Однако ответной реакцией большинство ответов содержит высказывания вида:
Да вы что?! Пошить абибас гораздо легче и дешевле! Главное деньги! На земле каждый пятый человек может сделать костюм за 4 минуты!
Не пойму как можно на заявления о качестве инструмента отвечать стоимостью разработки с его использованием?

[@Tairesh]

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

[@Aren_SH]

Ну-ну. А потом кому-то эту «дешевизну и скорость выполнения» приходится поддерживать и дорабатывать. И правка какой-нибудь мелочи на 10 минут выливается в пару-тройку часов работ, чтобы конкретный проект конкретного заказчика продолжал радовать конкретных пользователей.

[@VolCh]

Если заказчик не сформулировал в ТЗ требований по поддерживаемости и расширяемости, то виноват ли исполнитель, что он их не выполнил? Аналогия из строительства — сделали скрытую силовую проводку на 10А, замуровав кабель в штробу, отделку закончили, всё поТЗ. И вдруг выясняется, что нужно было сделать лёгкий доступ к кабелю, чтобы заказчик мог потом за 10 минут его поменять, когда 10А ему хватать перестанет. Или слаботочку протащить.

[@Cord]

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

[@VolCh]

Не пойму как можно на заявления о качестве инструмента отвечать стоимостью разработки с его использованием?

Заказываете вы, скажем, ремонт дома. Вас будет интересовать качество инструмента у рабочих? Или всё же скорость, качество и стоимость?

[@youlose]

Так программисты же не как заказчики выступают, а как рабочие =)

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

[@ApeCoder]

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

Для решения этой проблемы у Fog Creek даже свой язык есть с генератором PHP

[@youlose]

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

[@ApeCoder]

Для садового домика это может быть оврекиллом, особенно если раны когда-то придется искать самому

[@EvilBlueBeaver]

а теперь вспомните с чего началось и с какой стороны рассматривается проблема. человек написал что ПХП (инструмент) плох для него как разработчика (рабочего) тем-то и тем то. причем тут стоимость разработки и количество хостингов?

[@VolCh]

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

[@EvilBlueBeaver]

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

[@VolCh]

А заказчику всё равно чем отверстия я буду сверлить, если его моя скорость и цена устраивают.

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

[@milast]

Да Русский язык тоже хорош. Он не логичный, сложный!

Ну зачем эти все слова исключения: стеклянный, оловянный, деревянный…?
Что, сложно было написать единнобразно такие слова, как, например: полдома, пол-лимона, пол-апельсина, полдивана…?
Знаки препинания вообще никто не понимает: казнить нельзя помиловать
Зачем вообще эти лишние буквы «ё» и «й»? Ими всё-равно никто не пользуется.

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

Вот еще приятная мелоч:
«Ключ» == «Ключ» и в то же время «Ключ» != «Ключ»
PHP:
var_dump(«4.2» == «4.20»);

Пустой спор уже не первую статью подряд.

[@gkirok]

озвучили мою мысль.

а еще есть эсперанто где все очень правильно и структурированно, надо всем срочно перейти на него, осталось только на всех языковых кафедрах провести политинформацию :)

[@lair]

«Все мы пользуемся Русским языком, но почему его так не поливают грязью, как PHP?»
Потому что естественные языки «немножко отличаются» от искусственных. В частности, они не создаются намеренно, и не находятся под чьим-то управлением.

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

А еще потому что это банально невозможно.

[@aleks_raiden]

ага, не намеренно создались, сами возникли из вакуума :)

[@lair]

Не из вакуума, очевидно, но сами.

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

[@TreyLav]

Ваш русский невалиден, изучите руководство.

[@nuit]

>На любом хостинге стоит PHP+MySQL. Over 9000 их.
Так если нужно экономить в условиях когда под рукой нет сисадмина, гораздо выгоднее использовать площадки вроде heroku, appengine итд. А все эти шаред хостинги из прошлого века поскорее бы уже ушли в прошлое, разруливание проблем специфичных под каждый из этих 9000 хостингов — это ещё тот головняк.

[@VolCh]

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

[@IlyinEugene]

> А все эти шаред хостинги из прошлого века поскорее бы уже ушли в прошлое, разруливание проблем специфичных под каждый из этих 9000 хостингов — это ещё тот головняк.

Главное что есть выбор, а что выбрать вам — решайте сами.

[@patashnik]

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

[@mrjj]

legacy

[@VolCh]

Далеко не только legacy. Вы не поверите, но новые проекты на php возникают как бы не чаще, чем на всех остальных ЯП вместе взятых.

[@lair]

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

[@lair]

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

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

Ну и конечно, правда же, это можно сделать «на любом хостинге»? Over 9000 их?

[@lair]

«Те самые специалисты, что выполнят расчеты, спроектируют сеть, закупят и установят оборудование, будут его обслуживать, а так же штат программистов, что будет работать под руководством «любого из 28 миллионов программистов php» над разработкой и развитием продукта.»
Во-первых, далеко не любой программист справится с руководством командой. Во-вторых, после этого все остальные аргументы в посте становятся некорректными. Про это — дальше.

«over 9000 было сказано не про количество хостингов, подходящих под нагруженные проекты, а про количество вообще всех хостингов с PHP, не важно какого качества и масштаба»
Тут есть маленький нюанс. Если следовать вашей аргументации, то вот в этой паре вопрос-ответ:
«Вопрос (В): А как же с нагрузкой? Мой Фейсбук будут посещать много-много людей!
Ответ (О): Прекрасно. Вконтакте, Фейсбук, Викимедиа — отлично работают под нагрузками.»
не хватает (в ответе) одного предложения: «но тогда забудь про все остальные ответы, в том числе и про стоимость разработки».

«А если уж говорить про проекты масштаба Facebook — тут не о хостингах надо говорит, а о собственных ДЦ. Не зависимо от языка.»
Именно поэтому ответ про производительность (а при более внимательном рассмотрении — и все остальные ответы), на самом деле, является передергиванием.

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

[@lair]

Не PHP — лохотрон и передергивание, а «ответы» в посте — лохотрон и передергивание. А к PHP я отношусь ровно.

[@ragus]

>В то же время, используя необходимую инфраструктуру, Вконтакте, Фейсбук, Викимедиа отлично работают на PHP под нагрузками.

википедия — это почти ноль динамики. она живёт на толпе squid'ов, которые кэшируют страницы.

$ curl -I www.wikipedia.org/nginx
HTTP/1.0 301 Moved Permanently
Date: Sat, 21 Apr 2012 12:50:13 GMT
Server: Apache
Location: en.wikipedia.org/nginx
Content-Type: text/html; charset=iso-8859-1
X-Cache: MISS from sq62.wikimedia.org
X-Cache-Lookup: MISS from sq62.wikimedia.org:3128
X-Cache: MISS from amssq40.esams.wikimedia.org
X-Cache-Lookup: MISS from amssq40.esams.wikimedia.org:3128
X-Cache: MISS from amssq44.esams.wikimedia.org
X-Cache-Lookup: MISS from amssq44.esams.wikimedia.org:80
Connection: close

[@Nail]

Чего доказать-то пытаемся?
Вконтакте — тоже ноль динамики?

[@truezemez]

Зато любой программист, кроме пхпешника, по-любому сделает. Ведь правда?

[@lair]

Конечно, нет. Но это нигде и не утверждалось.

[@Shedal]

Прекратите уже приводить в пример Фейсбук. Он написан не на ПХП, а на весьма ограниченном его диалекте, который затем транслируется в C++ и компилируется в машинный код. От PHP там остался только базовый синтакс.

[@Nail]

Во-первых, «на весьма ограниченном его диалекте» — неправда. У HipHop есть особенности, да, но ничего «весьма ограниченного» там нет.
Во-вторых, компиляция PHP в C++ дала Facebook снижение загрузки CPU в 2 раза. Все.
В-третьих, кроме Фейсбука есть много чего хайлоадного.

[@ragus]

>Во-вторых, компиляция PHP в C++ дала Facebook снижение загрузки CPU в 2 раза. Все.

это очень мало для таких жертв.

[@Nail]

Это был ответ к комменту о том, что де в Фейсбук хайлоад не из-за PHP, а из-за транслятора в C++ (конечно, а если бы на PHP было, то у них бы все умерло наверно)

P.S.
Для вас это мало, для Facebook — это возможность снижения количества серверов в php-ферме в 2 раза.

[@sneer]

автор напроч забыл про java, c#, js на которых больше разработчиков и зарплата выше чем у хомяков.

[@VolCh]

Серьезно, что на java, c#, js (серверном), разработчиков, специализирующихся на веб-разработке больше, чем нас, «хомяков»?

[@sneer]

js я брал конечно сумарное кол-во. Java на данный момент это 80% веб программирование. Если бы не андроид, то наверное все 90%. Посмотрите растпространенность java и php. Тоже самое касается C# котороый ракетой вверх взлетает. Правда там процент веба чуть поменьше. По сравнению с ними php это карлик.

[@VolCh]

Как-то мне казалось, что Java это серьёзный энтерпрайз прежде всего, а C# — десктоп.

[@sneer]

энтерпрайз не может быть вебом? на сишарпе тоже очень много веба и интерпрайзного и не оч. asp.net не плохой стек технологий. И очень популярный. node.js уже тоже проскакивает в списке вакансий даже в наших широтах. После того как на нем появится парочка конкурирующих технологий дающих полный стек технологий… Вобщем мой прогноз 2-3 года и на сервер сайде он будет не менее популярен чем php.

[@VolCh]

Может, конечно, но всё равно кажется, что оценка в 80% сильно преувеличена. По косвенным признакам сужу.

[@sneer]

Не думаю. Особенно если учесть что среди андроидов много ребят эпизодических. То даже уменьшена. За все время работы в java-oriented компаниях не видел ни одного десктоп разработчика. Все веб или андроиды. Андроидов намного меньше. Да и dalvik это не совсем классическая джава скажем. И среди андроидов растет кол-во phonegap технологий где в т.ч. веб на js.

[@peterpro]

Знаете, по-моему, этим комментарием вы дискредитировали питон :)

[@grossws]

Вижу, что грамматика python Вам далась лучше, чем родного языка.

[@grossws]

Извините, если ошибся. Данное сильное предположение базируется на том, что Вы проживаете в Иркутске (судя по профилю). А в Сибири живет существенно меньше иностранцев (id est не граждан РФ) чем, скажем, в Москве или на Дальнем Востоке.

[@VolCh]

Дайте угадаю, 4 сайта на PHP использовали Yii, kohana, CakePHP и symfony и вы запутались как модели в каждом из них организованы?

А без Django, на голом python, только с WSGI легче будет делать?

[@koloebok]

думаю, в 100 раз легче чем на голом пхп

[@VolCh]

Я пробовал — практически так же. Чем-то лучше, чем-то хуже.

[@miraage]

Холивар, такой холивар. Примерно за половину суток 300+ комментов.

[@noRerih]

Уныло вброшенный срыв покровов.

[@2fast4rabbit]

Попса!

[@rosty]

Странно, почему все банки, страховые, телекомы, авиакомпании и тд НЕ выбирают пхп? Видимо там одну дураки сидят, а 30 миллионов настоящих специалистов постоянно ищут работу — кому бы ещё написать фейсбук и сэкономить $3,000,000

[@Cord]

Ну во-первых я написал, для малого и среднего бизнеса.

Во-вторых, скажем, на каком-нибудь дотнете — это же Майкрософт со всеми официальными бумаженциями — ИМХО проще по схеме РОЗ навариться. Да и руководство выбирает «Бренд», как среди движков КМС берут Битрикс — «потому что 1C и у нас их есть их бухгалтерия, мы их знаем».

Или Java — ну она и есть ПЛАТФОРМА, та же J2EE, это ее поле. Она создавалась для Серьезного Бизнеса и прекрасно там устроилась.
В реке щука — щукой, но акула ее порвет — потому что именно акула хищник №1 в данной сфере.

[@rosty]

И джава и дотнет ничем не хуже подходят и для малого и для среднего бизнеса. Честно говоря, очень обидно, что такое говно как пхп первым заняло эту нишу, и теперь доминирует на фоне таких прекрасных вещей как та же java, groovy, python и тд. Так мало того, пхп породило целое поколение недопрограммистов, которые не способны даже обьективно сравнить разные технологии и орут везде, что пхп — это оче круто, потому-что фейсбук и википедия

[@Cord]

Да. А дотнет породила кучу говнопрограммистов, не знающих, что такое IoC, SOLID, к примеру. Зато хотящих в два раза денег, чем PHP программист.

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

Основные проблемы, как верно указали, в БД либо архитектуре приложения.
Проектировать БД умеют единицы, а архитектура, если человек не владеет ООП, теорией графов и прочим матаном, а также не читал кучу умных дядей (Фаулер, Мартин, GoF) и т.д. и не провел, как я, много ночей за попыткой постичь таинства на практике, будет говном.

[@VolCh]

Джава и дотнет всё же хуже подходят, имхо. У PHP очень удачно получилось со средой выполнения скриптов в вебе с экономической точки зрения. Установить веб-приложение на (шаред-)хостинге немногим сложнее, чем установить десктопное приложение под виндой, а весь стэк LAMP бесплатен и «эникейфрендли» — с профессиональной точки зрения он может быть ужасно настроен, но для бизнеса (и некоммерческих проектов) главное, что работает с минимальными расходами.

И, кстати, думаю, что если бы эту нишу занял другой язык, то сейчас бы его поливали говном из-за «недопрограммистов». Скажем как зачастую «тихим добрым словом» поминают VB иди Delphi десктоп или даже клиент-сервер разработчиков. Как говорится, свинья везде грязи найдёт. А разговоры о том, что какие-то языки как-то способствуют правильному написанию кода считаю в большой степени преувеличением. Способствуют учителя, документация, открытые проекты, литература.

[@ApeCoder]

Это техническое преимущество или историческое?

[@VolCh]

Техническое. Интерпретируемый язык, встраиваемый в веб-сервер.

[@ApeCoder]

Интересно, что для питона, например, есть способы встраивания.

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

Мне кажется, если сам по себе язык является примером плозого дизайна, то изучая и привыкая к нему программист приучивается к плозхому дизайну. Я помню свое впечатление нескольких лет назад, когда после написания скриптов и изучения питона, мне понадобилось попвавить скрипт на PHP и я прочитал просто введение, базовые средства языка и стандартные функции работы со строками и регуларными выражениями (там кстати, до сих пор ) — невозможно предсказать как называется функция, странные операторы поджидающие тебя прям на входе (вон во фрактальной статье "== is unusable").

И мне кажется, что это отпечаток мозга сосдателя, который не может не иметь влияния на мозг пользователей.

Мне странно, что при наличие механизма depreciated не приводят постепенно эти вещи в порядок.

[@Nail]

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

[@ApeCoder]

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

Во-вторых, про фортран я мало чего знаю, но мне знакомо выражение «программу на фортране можно написать на любом языке». Опять-таки, является ли фортран примером несистемности и самонесогласованности?

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

[@VolCh]

Мы говорили о Java и .NET. Про jsp и asp я в курсе, но, имхо, это слишком сложно для обычного пользователя (не администратора, не программиста). По крайней мере попытка поднять aspx-хэндлер под Apache на Ubuntu у меня не удалась.

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

Отпечаток, да, но нужно вспомнить историю PHP и основной рынок приложений на нём — по-моему, это люди, которые не владеют ни контролем над кодом, ни контролем над средой его выполнения.

Если честно, то ситуация с библиотеками меня тоже удивляет, с момента выхода PHP5 уж точно. А большинство (если не весь) кода PHP3 на PHP5.4 не заработает. А вот с операторами и прочим синтаксисом проблема: если depicated функции ещё можно поменять на новые сигнатуры через поиск и замену, то код вроде

$a = $_GET['a'];
$b = mysql_fetch_array($result)['b'];
if ($a == $b) {
  die("It must not be equal")
}

так просто не заменишь.

[@nuit]

Разработка вебстраничек для банков, страховых итд? Довольно часто делают на php. Или вы про что?

[@rosty]

Бывает… а потом плюются и переходят на более вменяемые технологии. Ни одного обратного примера.

[@ashofthedream]

Думаю даже бывает — существует только в виде первого прототипа. Потому как интерграция пыха с чем либо… Эм, да она просто отсутсвует. Никто вручную не будет цеплять пых к абс.

[@egoholic]

Ответ автору поста: habrahabr.ru/post/142399/

[@second_pilot]

Я в детстве тоже себя развлекал спорами с воображаемым оппонентом. И я тоже всегда выигрывал.

[@Cord]

Ну я бы тоже хотел, чтобы сайты, к примеру, делались на Play!..
www.playframework.org/

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

[@second_pilot]

Да кому в голову взбредет делать визитки на плей? И кому понадобится делать стартап на жумле или битриксе? Это разные плоскости.

[@rosty]

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

[@second_pilot]

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

[@rosty]

ну а раздавать листовки у метро ещё дешевле, хотя не факт… но мы то обсуждаем технологии

[@second_pilot]

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

[@VolCh]

Ну вот пхп и есть самая дешёвая технология выхода в люди в Сеть. По крайней мере она таковая в массовом сознании.

[@Mox]

Набираем «резюме Php Zend» — тадам — 218 000 ответов. Против миллиона RoR

[@Mox]

И еще в копилочку — по поводу того, кого нанимать для новых более-менее серьезных проектов
github.com/languages

[@nuit]

На пхпшников большой спрос, им некогда заниматься каким-то непонятным опенсорсом :)

[@Sannis]

Ну-ну. Python вровень с shell, надо бы подумать что выбрать…

[@Mox]

— Я думаю что shell используется во всех проектах, и Ruby и Python и PHP. Ну, например, вряд ли лидерство Javascript вызывано популярностью Node.JS — это потому что Javascript приходится использовать во всех проектах

— Во вторых — я думаю что у них есть, конечно, нюансы определения типа языка. :)

[@Illorian]

Как минимум, на мой взгляд, php изучать легче, Pyton или Ruby…

[@VolCh]

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

К тому же о какой лёгкости изучения может идти речь, если нормальной «консоли» у языка нет? И это у интерпретируемого языка. Даже компилируемые умудряются изображать из себя интерпретируемые, а пхп наоборот :)

[@TiGR]

Кажется, что для сайта-визитку куда лучше подойдёт get simple cms или что-то подобное.

[@shuron]

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

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

[@worker]

политики ни в каком виде на сайте, иначе в бан? хм

[@ragus]

господа пхпшники, а как вы решаете вопросы производительности?

Вот допустим, пишем мы агрегатор новостей и есть в коде ф-я somefunc(args). Пусть она занимается классификацией новостей, получаемых от внешних модулей и кушает уж очень много cpu time.

[@aleks_raiden]

она выноситься в виде сервиса — и агрегируется с системой любым вариантом RPC

[@ragus]

ооо… а сервис на php?

[@aleks_raiden]

Обычно первый прототип я бы писал на том же языке что и система. После допиливания и отработки — смотрел по узкому месту. Потому и какой-либо асинхронный RPC — чтобы абстрагироваться от языка. А так что мешает написать всю систему на РНР, а эту часть в виде сервиса на любом другом языке? Не вижу в этом противоречия (впрочем — сами так и сделали правда не с новостями а с биржевыми данными)

[@ragus]

имхо, вы слишком рано заговорили об отдельном сервисе и rpc.

когда я писал эту вещь на python:

1)т.к. 1 функция применяется к коллекции, я использовал filter(somefunc, news_list)
2)когда процессора стало не хватать, somefunc была оттранслирована cython'ом в сишный модуль
3)когда упёрлись в одно ядро в код был чуть-чуть изменён.

если ранее было:

filtered_news = filter(somefunc, news_list)

стало:

from multiprocessing import Pool

#создали пул на 16 процессов
pool = Pool(processes=16)

#получили список вердиктов относительно новостей
filter_list = pool.map(somefunc, news_list)

#убираем ненужное.
#enumerate возвращает нам номер элемента и сам элемент.
#по номеру находим вердикт относительно данной новости

filtered_news = filter(lambda x: filter_list[x[0]], enumerate(news_list) )

покажите такое же на php?

[@Nail]

Вариант1. Компилятор HipHop.
Вариант2. Профайлинг, внутри смотрим участки, которые тормозят, переписываем на C++.

Если вы так любите шашечки и вам лень ручками запустить несколько процессов, есть Gearman — разнесет работу не то что по разным ядрам, а по разным машинам.

[@VolCh]

Очевидно же — покупаем более мощный камень :)