PHP гораздо лучше, чем вы думаете

[@Nickel3000]

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

[@keenz]

чуть глаза не сломал от вашего комментария… пора отдыхать)))

[@StopDesign]

Похоже, у нас с вами одинаковые браузеры и операционки.

[@Mine]

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

[@ainu]

Дело не в оси. Если реже глаз, значит, один LCD монитор RGB, а другой BRG. Отсюда и цветной вырвиглаз.

[@Lici]

Как влияет монитор на файл скриншота?

[@ainu]

Субпиксельное сглаживание зависит от последовательности пикселей.
От монитора зависит система, которая и сглаживает.
Если увеличить скриншот, то видно, что буквы не чёрные, а красно — синие.
Вот тут ru.wikipedia.org/wiki/ClearType сказано, почему ClearType не работает на ЭЛТ.

[@chetzof]

я звизда!

[@Nickel3000]

Вот и повелитель Хабра!

[@Aios]

скорее очередной актер похапэ

[@Xazzzi]

Судя по профилю (пункту «О себе» и карме) — я бы даже сказал «Чёрный властелин»

[@Nickel3000]

Не, Чёрный властелин вроде еще до этого пытался захватить хабр.

[@Xazzzi]

<голосом рассказчика длинной поучительной истории>
… но попытка была неудачной… Карму ему слили, комменты минусовали, топики критиковали… Он расстроился и ушел на имиджборды.
</голосом рассказчика длинной поучительной истории>

[@vitalets]

Опасно вешать такой коммент в конце дня пятницы!

[@heroOfOurTime]

Почти дежавю: habrahabr.ru/post/147247/#comment_4963128

[@Nickel3000]

Я знаю, как Deffe может исправить ситуацию.

[@Holy_Cheater]

Ничего лучше «пыхи» здесь быть не может? :-)

[@Deffe]

Капитан ПХП идет на помощь!

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

(Сорри, не могу вставить картинку прямо в комментарий.)

[@DOGG]

Я понимаю что после написания Вашего поста прошло 6 лет, 5 мес. 1 нед. и 4 дня, но не могли бы Вы перезалить картинку? А то ссылка не работает.

[@Holy_Cheater]

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

[@frentsel]

Зачет!

[@frentsel]

Написал, что статья зачетная — заминусовали. Как вас понять?

[@1999]

> Да, у PHP сейчас лучший менеджер зависимостей из всех языков.
говорить так и менеджере зависимостей, который был inspired by npm — это по крайней мере смешно

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

> Давайте я вам рассскажу маленький секрет успеха PHP
нет, спасибо

[@Xazzzi]

именно это же является одной из его слабых сторон

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

нет, спасибо

Аргументируете? Сами-то на чем пишете? Чем оно лучше? Оно успешнее РНР?
На последний вопрос сам и отвечу: как видно из предоставленной в статье статистики — нет.

[@nickon]

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

когда простота была «плохой»?

[@1999]

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

[@esc]

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

[@theproof]

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

(написано по просьбе 1999)

[@sdevalex]

Если вы говорите, что PHP быстро развивается, то точно не видели Ruby и Python. Эти языки чуть ли не на прорядок быстрее развиваются.

[@nazarpc]

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

[@sdevalex]

Я ещё меньше года назад программировал на PHP… не успел я ещё гиперболизироваться.

[@sdevalex]

Чтобы не быть голословным…

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

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

Ещё стоит учитывать, что Ruby разработчиков меньше, чем PHP…

[@Ents]

маленькая особенность: since July 2009

3 месяца vs 3 года

[@VolCh]

Надеюсь, что зависимость не линейная от времени. Composer понравился :)

[@gen]

Я не совсем понял, вы сравнили количество скачанных ruby пакетов с количеством добавленных php пакетов?

[@VolCh]

725 млн. вс 1 млн
41114 вс 1900
3 года вс 3 месяца

[@gen]

Так и не понял, что вы хотели сказать этими цифрами. Что за 3 года ruby пакетов добавили больше, чем php за 3 месяца?

Судя по твитам Фабьена, следующая его статья будет о том, чем, собственно, composer лучше bundler'a ;)

[@VolCh]

Что сравнивали не количество закачек гемов с количеством пакетов композера.

[@dizer]

Бандлер работает. Чем composer может быть лучше вещи, которая просто работает?

[@VolCh]

Тем, что он работает лучше? :)

[@BlessMaster]

Одна тонкость — для руби это официальный и едва ли не единственный источник?
Для PHP же — это одна из множества альтернатив, о которой ещё далеко не все знают, поскольку неофициальная.
Сравнение некорректно.

[@sdevalex]

Это не тонкость, а сила языка. Нормальные программисы просто так делятся нормальным кодом.
А в PHP-мире каждый второй сидит со своей CMS или велосипедом, боится показывать… иногда правда показывает и просит не малую цену.

[@VolCh]

С другой стороны как-то нет на слуху CMS на языках отличных от PHP. Фреймворки есть, CMS нет.

[@sdevalex]

Те, кому нужны были CMS на Ruby, знают хотя бы парочку. Причем больная часть CMS — это надстройка над ROR.

[@VolCh]

Обычно людям нужна (если формализировать их требования) просто CMS, может несколько кастомных модулей к ней. Почему-то выбирают CMS на PHP и заказчики, и исполнители. Сам не знаю почему выбираю :) Может мало документации?

[@sdevalex]

В 2000-2005 году рынок был переполнен дешевыми китайскими велосипедами с кучей перделок и все их покупали. Сейчас не один нормальный человек за такую кучу стали не сядет.

Надеюсь и web-программисты образумятся.

[@VolCh]

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

[@sdevalex]

> Лучше плохо ехать, чем хорошо идти. Дарёному (почти) коню в зубы не смотрят.
Вообще не понял, о чем вы…

> Нормальных людей больше интересует соотношение цена/качество
У нас множество людей интересует только халява =)

[@VolCh]

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

Я это заметил и потому больше «финансовую подушку» не создаю, иначе встречу интересную задачу и буду приплачивать за возможность её решить :)

[@sdevalex]

Ещё китайцы не тратились на прочность, плевали на материал (сталь вместо алюминия)… в общем все самое дешевое.

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

[@VolCh]

Люди выставляют «ТЗ», я уточняю неясные моменты и предлагаю ценник и сроки. За интересные задачи — скидка. Что они считают за качество мне не интересно, вся инфа (плюс-минус лапоть) у них есть.

[@VolCh]

Я предлагаю на выбор сайт на симфони и на рельсах, на рельсах в 1,5 раза дольше и в 1,5 раза дешевле. Никто не выбрал на рельсах!

[@VolCh]

Просто «бурятку» нужно дольше заводить до состояния «огня». Но это приятно, вот и скидка :)

[@VolCh]

Тьфу, негритянку.

[@VolCh]

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

[@sdevalex]

На рельсах в 2-3 раза быстрее получается, если сравнивать ROR и Symfony.

[@sdevalex]

Разработка.

[@VolCh]

Я делаю. В среднем на рельсах в 1,5 раза дольше чем на симфони. Слышал и противоположные мнения.

Производительность команды субъективна.

[@sdevalex]

Ни что не объединяет Ruby и Python разработчика так, как затролить PHP =)

[@VolCh]

Это точно.

[@VolCh]

У вас быстрее, у меня медленнее. На рельсах у меня быстро прототипы получаются, решения в лоб и т. п. Когда начинаются нестандартные сценарии, то предпочитаю переходить на симфони.

[@sdevalex]

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

[@VolCh]

Может у вас более глубокие знания Ruby и/или RoR чем у меня. А может у меня более глубокие symfony2. И уж точно production окружение для php на голом debian/ubuntu я быстрее разверну раз в 100 чем рельсовое, лезть в ману или гуглить не потребуется.

[@sdevalex]

Есть такие решения как capistrano и подобные. На голом сервере все само разворачивается одной командой.

Руками приложение я разворачивают 5-10 минут… и то большая часть времени качаются пакеты и гемы.

[@VolCh]

capistrano я пользуюсь чтобы разворачивать php приложения :)

[@sdevalex]

Кажется мы уже где-то общались…

[@VolCh]

Конечно, я ни одной такой темы не пропускаю :)

[@sdevalex]

Смотрите, ставите…
— nginx
— postgres
— rvm

Дальше создать пользователя в базе, подправить конфиг. Качаете гемы и запускаешь unicorn… все…

[@VolCh]

Это я умею (только мускул предпочитаю, вроде же в рельсах есть DBAL), правда не нравится что при установке rvm приходится осуществлять лишние разумные действия — не заскриптуешь.

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

[@sdevalex]

> И вообще само «качаете гемы» предполагает большее взаимодействие с сервером чем закачка файлов по scp.

bundle install

> Мне почему-то пассажир ближе, а там тоже заморочки…
Если использовать passenger, то ограничиваете себя одной версией Ruby.

[@VolCh]

Именно, доступ к серверу к серверу на исполнение нужен. Можно, наверное, обойтись обойтись копированием файлов по всей ФС, о как-тов туториалах такой путь не освещается и не освяается.

[@VolCh]

Я предпочитаю ровно наоборот. Максимум нагрузки на бэкенд. И да, через RESTful. :)

[@VolCh]

PUT /hubs/123/posts/15678/comments/56689['carma' => '+1']

[@sdevalex]

Вообще лучше сделать просто…
PUT /comments/56689['carma' => '+1']

Иначе Rails сделает 3 запроса вместо одного.

[@VolCh]

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

[@sdevalex]

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

[@VolCh]

Так они и посылаются асинхронно. Просто в разных ситуациях разное представление.

[@sdevalex]

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

[@VolCh]

Ответ может быть в любом виде. Технология AJAX подразумевает, что ответ в XML виде. Если вы называете «аяксом» технологию возвращающую не XML, то это ваши трудности. 'X' в 'AJAX' означает именно XML, а не JSON или HTML.

[@dmitriid]

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

[@int03e]

Простите, а что такого нестандартного на RoR равно экзекуции, а на Symfony/Yii/etc — нормально?

[@VolCh]

Скорее самого языка касается, а не фреймворков. Проблемы составляет реализация бизнес-логики сложнее чем CRUD. Мне (почти) очевидна её реализация на PHP или C, а на Ruby я постоянно удивляюсь, если получается нагуглить решение.

[@sdevalex]

Возможно вы плохо знакомы с языком? Метапрограммирование довольно хитрая вещь.

[@VolCh]

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

[@sdevalex]

В Ruby магия сплош и рядом. И при длительном изучении все получается очень просто. Такое поведение заложено в философии…

Язык следует принципу «наименьшей неожиданности»: программа должна вести себя так, как ожидает программист. Однако в контексте Ruby это означает наименьшее удивление не при знакомстве с языком, а при его основательном изучении.

[@VolCh]

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

[@int03e]

Вы скорее всего гораздо лучше знаете PHP, только и всего. Github на рельсах написан, а логика там явно за рамками CRUD. Да и Ruby позволяет такое, чего я на PHP даже не представляю (это уже со своей колокольни) :-)

[@int03e]

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

every 3.hours { awesome 'task', option: 'value' }

[@VolCh]

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

[@int03e]

Функциональность? Писать лаконичный и понятный код, это для многих уже достаточный аргумент. Встречается во всех хороших проектах :-) Если знакомы с рельсами, должны были увидеть что различные DSL распространены довольно широко. Да, все это можно написать и на php, но будет гораздо уродливее (даже Yii сравнить с RoR, видно что ребята старались соответствовать, но сам язык подвел).

[@VolCh]

Я так подозреваю, что гитхаб всё же основан на какой-то СУБД и/или плоском хранилище. Какие операции доступа к внешнему сервису позволяет руби и не позволяет пэхэпэ?

[@VolCh]

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

[@VolCh]

Даже немного раньше :) Мне интересней разрабатывать под фреймворками или даже с нуля.

[@VolCh]

По личному опыту CMS (вкупе с популярными модулями/плагинами/...) решают задачи процентов на 90.

[@VolCh]

Управление контентом, как ни странно :)

[@VolCh]

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

[@VolCh]

Субъективно быстрее откастомить.

[@VolCh]

Мои заказчики ни разу за 10+ лет моего программирования на PHP не высказывали недовольства моим кодом.

[@VolCh]

Значит вы (сайт я как понял ваш?) не смогли сформулировать свои требования. Я, как исполнитель, в случаях когда «ТЗ» заказчика допускает двоякое трактование всегда уточняю все нюансы. В частности интересует заказчика ли заказчика стоимость поддержки. Верите — нет, но мне зачастую проще и экономически выгоднее накидать костылей на CMS, я уточняю у заказчика и если его это устраивает делаю ему скидку.

[@VolCh]

Встречный вопрос — вас интересует качество или скорость?

[@VolCh]

Нет. CMS средтсво создания сайтов близких к оптимому качество/себестоимость.

[@Inori]

Ребят, неужели вас так легко затроллить? :)

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

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

[@nazarpc]

Я знаю, сам пишу движок под PHP 5.4, и будьте уверенны, в курсе, как он развивается.

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

[@VolCh]

Действие рождает противодействие. Если не возносить к небесам, то унизят и общая картина объективна не будет. А так минус на плюс даёт ноль и общую картину можно считать объективной. :)

[@oxpa]

«средняя температура по больнице — комнатная».

[@anycolor]

Какой смысл в движке конкретно под PHP 5.4. Поясните, пожалуйста.

[@nazarpc]

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

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

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

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

[@VolCh]

За одну возможность писать [...] вместто array(...) я был готов продать душу дьяволу, но обошлось без этого. Жду предложения по типизации выражений и…

[@sdevalex]

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

[@LayneBuchyn]

Вы не правы. О быстром развитии — это вовсе не гипербола. Гиперболы в разговорах о PHP чаще всего только в разговорах о недостатках этого языка. Мало кто знает о его реальных возможностях. Чаще всего люди под влиянием всех этих «критиков» уходят из PHP раньше, чем успевают изучить его, а потом рассказывают о преимуществах других языков и недостатках PHP.

[@everzet]

Ага, развиваются: python3wos.appspot.com/ :)

[@TiGR]

Изменения в PHP пока что по большому счёту были обратно-совместимыми. Разве что выпиливание отдельных элементов типа register_globals.

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

Возможно, разработчики PHP просто поступают осторожнее, внося изменения аккуратно.

[@everzet]

Ну я как бы и не утверждал обратного.

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

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

[@anycolor]

У меня огромный проект перешел с 5.2 на 5.3 вообще без никаких проблем.

Да, с переходом с 4 на 5 версию были бы проблемы, но время 4 ветки ушло еще в 2005 году, сегодня наверняка прощелучше переписать приложение, будет и быстрее и более поддерживаемее.

[@A1lfeG]

Я бы сюда ещё C# приплел, угнаться за ним многим сложно.

[@nazarpc]

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

[@forgotten]

А Руби-то с Питоном на виртуальных хостингах завались, конечно.

[@sdevalex]

Есть не мало решений типа heroku.com, есть дешевле.

[@StopDesign]

Про Руби не знаю, но Питона, вообще-то, завались.

[@forgotten]

Шо ви говорите?
Вот я прям щас попытался найти хостинг с поддержкой Python 3.2 и не нашел ничего на первой странице выдачи + рекламе. (Если точнее, ни на одном хостинге «с поддержкой Python» я не нашел указания версии совсем.)

[@slav0nic]

обычно у заказчика требующего python/ruby найдётся 10-20уе/мес на нормальный VPS…
хотя если вы намекаете, что ниша РНР — малонагруженны сайты на 1 долларовых недохостингах, тогда вопросов не имею)

ну и про «хостинг» (хостинги в том виде, в котором они есть в РНР, малопопулярны в других языка) с py3.2 — docs.webfaction.com/software/python.html

[@VolCh]

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

[@StopDesign]

А что, много проектов есть на Python 3.2?

[@forgotten]

Думаю, примерно как на PHP 5.4

[@StopDesign]

С питоном немного другая история. Насколько я знаю, сообщество до сих пор саботирует переход на python 3.x, т.к. обратной совместимости нет, а пользы от него мало. Полезные нововведения дублируются в ветке 2.x. Главный фреймворк — Django — только еще анонсирует экспериментальную поддержку Python 3.3. Какой смысл держать на хостинге Python 3? Для крутых программистов, которые хотят экспериментировать? Так вирутальный хостинг им не подходит по многим другим причинам.

[@forgotten]

Я как бы в курсе :)
Ветка началась с жалобы на то, что развитие PHP задерживает отсутствие 5.4 на виртуальных хостингах.
Ну так вот, с актуальными версиями Питона и Руби (да и вообще с хостингом Питона и Руби) всё куда как печальнее. А про node.js я вообще молчу.

[@StopDesign]

Всё так, но актуальная версия Python — 2.7.3.

[@forgotten]

А PHP — 5.0 ;)

[@StopDesign]

Я понимаю, что вы шутите, но нас читают дети.
Для них я на всякий случай напишу это:
PHP 5 was released in July 2004.
Python 2.7.3 — 11 April 2012.

[@forgotten]

Я не понял смысла вашего ответа.
«Актуальная» версия PHP — это 5.2.17, выпущенная 6.01.2011
Именно оно и стоит на большинстве хостингов, потому что ветки 5.0-5.2 практически не отлисаются в плане обратной совместимости.
5.3 и 5.4 — совсем другая песня. Не того, конечно, масштаба, что Python 3.x или Ruby 1.9, но что-то рядом. Его пока ставят неохотно — оно и понятно.

Так что ситуация, в общем-то, очень похожая у PHP и у Python/Ruby

[@StopDesign]

Да, люди часто друг друга не понимают. Есть такая проблема.

[@schors]

Ну вот у меня 3.1 есть (и в тарифах написано). Нужен 3.2? Не проблема — никто не спрашивал. Может на следующей неделе и сделаю. diphost.ru
Вообще странно про «ни на одном». В РФ практически три хостинга когда-либо позиционировавшие себя как хостинги с Python — netangels, мы и каким-то боком jino.

[@forgotten]

www.google.com/search?q=python+хостинг
Вижу только Джино с Питоном 2.7

[@schors]

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

[@Mox]

Было бы круто там еще RoR… Через passenger ( видимо 3.2 ) или Unicorn…
Эх, а то в рунете пока кроме locum толком не податься.

[@schors]

Неясна ситуация со стабильностью руби 1.9.3. Судя по списку рассылки freebsd что-то там провалилось с портированием. Самим кишка тонка. Также не ясно кто будет и как поддерживать пользователей. RoR — это как и Java совершенно отдельная религия. Мы сами программисты, мы можем и Python посмотреть, и php, и Си. Но RoR это идеология и там уже начинается. Вопрос — сможем ли мы обеспечить поддержку пользователей на хотя бы удовлетворительном уровне?

[@Mox]

Ну если FreeBSD и проблемы с портами то действительно сложно.
Ну и без Rails девелопера да, может быть сложновато учитывать нюансы.

Но ниша открыта, реализуется это либо через mod_rails(passenger) к Apache/Nginx, либо через reverse proxy к unicorn.

[@schors]

1. freebsd хрен с ним. там была проблема что не все порты зависимые пересобрались с 1.9.3. это в контексте обсуждения не существенно
2. а вот девелопер — это да. представьте его ФЗП и какая наценка должны быть только чтобы его существование окупить.
3. мы уже проходили с wsgi это. ниша открыта, мы в неё первыми удачно вломились вплоть до хостинга clck.ru и прочих бобуковских проектов и это… 5% наших клиентов. такой расклад делает неокупаемым (2)
4. ну я не первый день замужем :) естественно я отлично знаю как это делается. на хостинге даже сделано для ruby 1.8.6, но введено в тарифы и возможности хостинга, используется только для внутренних проектов.

[@Mox]

По поводу второго пункта — вполне может быть, раз вы сами знаете что такое passenger и unicorn, то вам понадобятся просто консультации, а не человек в штате.
Или, например, просто открытость к тикетам в поддержку со стороны Rails проектов.

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

Но вообщем конечно да, не моя компетенция считать что Вам выгодно, а что — нет.

[@Source]

на хостинге даже сделано для ruby 1.8.6

Ruby 1.8.6 уже сильно не актуален. Уже состоялся последний релиз Ruby 1.8.7, осталось 11 месяцев, в которые при необходимости будут выпускать security-патчи и на этом всё.
Так что если будете делать хостинг для Ruby, делайте поддержку только 1.9.3+

[@kAIST]

Кстати, а почему jino каким то боком? Полноценно вроде поддерживает да и саппорт может нужную тебе версию поставить.

[@kAIST]

Завались то завались, но в основном через cgi работает питон, а какой нибудь wsgi это большая редкость или за такие деньги, что проще vds дешевый взять. Но к минусам я это не отношу )

[@nazarpc]

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

[@VolCh]

И легко найти того, кто сам всё это сделает за смешные деньги. Иногда кажется, что админы-фрилансеры ценник заряжают не по трудоемкости, а по ключевым словам в ТЗ. Увидели Django — +N%, увидели RoR — +2N%, увидели Node.js — +5N%.

[@EvilShadow]

Как Вы же сказали выше — для установки пхп-приложения достаточно знаний секретаря. Для настройки VPS под руби/питону — недостаточно.

[@VolCh]

Для установки на шаред хостинг. На VDS субъективно трудозатраты одного порядка. По сути нужно только «прослойку» между nginx/Apache/etc и СУБД настроить.

[@romy4]

Не скажу за всю Одессу © Но среди ведущих хостингов Украины php5.4 уже поддерживается вовсю. У мелких меинстрим тем более никогда не был проблемой.

[@nazarpc]

Спрашивал у своего хостера, сказал, что PHP 5.4 пока не достаточно стабильный.
Бред, имхо, но у меня всё равно VDS, так что неудобств особых не испытываю.

[@malroc]

Ну вот на nic.ru до сих пор 5.2

[@romy4]

Я вам могу найти и с php4, но nic.ru не в нашей юрисдикции. :)

[@VEG]

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

[@FSA]

Друг вообще откатился пол года назад на 5.2 на своём сервере из-за того, что одно проприетарное решение не работало на 5.3. Вот и не торопятся на хостингах. А то вроде бы и не виноваты, а клиент материт.

[@esc]

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

[@VolCh]

Не в бюджете дело, а в администрировании. На шареде почти все настройки ОС, nginx/Apache, MySQL, самого PHP вне зоны ответственности разработчика сайта. Максимум рекомендует тот или иной хостинг. А рекомендуя VDS заказчику сразу встаёт вопрос, а кто его будет настраивать и поддерживать. А поддержка от хостера уже не дешевое удовольствие.

[@esc]

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

hostpro.ua/ru/cloud — обещают помогать чуть ли не бесплатно. Ну это первое что подвернулось под руку.

[@schors]

У нас уже недели как три есть. Особо никому не нужно.

[@VolCh]

Отрадно, но как по мне, то версия становится нужной когда она есть хотя бы у половины хостеров. Снижение рисков «hoster lock-in» :)

[@schors]

Это понятно. Сделают. Мы всегда задавали тон. Хотя об этом никто и не знает. К осени уже все догонят.

[@BlessMaster]

Здесь есть существенная ложка мёда (и отдушина для Ruby с Python'ом) — VPS это уже не редкость и все более менее солидные хостинги его предлагают по цене не дороже привычного виртуального. А там уже можно настроить многое, чего не будет на виртуальном и даже более того, выше уровень обеспечения безопасности, если она имеет хоть какое-то значение (для меня это уже давно насущный вопрос) — она уже не зависит от соседей по хостингу.

[@Squier]

Просто, быстро, удобно. Надо будет, перейду на что-нибудь другое.

[@kushti]

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

[@esc]

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

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

[@haskel]

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

[@Nerten]

А вот выше сказали что питон и руби развиваются быстрее :)

[@mihas]

Я уже перешёл на похапэ, вот уже как 7 лет.

[@mihas]

ну вот, убили мне карму :(((((((((((

[@esc]

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

[@soider]

cython, сто лет как.

[@esc]

Берем обычный код на питоне, обрабатываем этой штукой и получаем с++ код, который компилится и работает практически как нативный на с++? Я не думаю.

[@soider]

Ну, зря, думать полезно.

[@esc]

Читая википедию: Cython — язык программирования, упрощающий написание модулей С/С++ кода для Python.. Я не в курсе деталей, возможно там не сильно корректно написано, но судя по этому, язык все-же не совсем такой и код таки придется переделывать.

[@soider]

Родной питоновский код будет компилироваться cython'ом, за некоторыми ограничениями (которые так же есть у hiphop'a), просто, если использовать специальный диалект (тот же питон + объявления типов данных, которые будут использоваться в c'шном коде (если не указывать, то практически везде будет использоваться тип PyObject)), выгода от компиляции в нативный код будет выше.

[@esc]

У hiphop основное ограничение — не использовать eval и другой динамический код. Остальное связано, в основном, с расширениями. Потому, многие существующие движки, типа вордпресса (с дурным количеством кода) им нормально компилируются. Точнее, движки, часто, надо немного подпилить (избавиться от динамического кода), но объем работ там сравнительно небольшой.

Кстати, почему вообще пишут на питоне, если есть cpython? Ну я не про небольшие скрипты, а про веб-проекты на джанге, например.

[@el777]

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

[@esc]

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

Я описывал ниже пример, взял обычный сайт, где код выполняется достаточно ровно и узких мест, как таковых, нет. Просто перекомпилировал через hiphop + g++ и получил скорость отклика в 30 раз быстрее. Не думаю, что у меня получится, если я перепишу узкие места на Си. Ну разве что весь сайт в виже extension делать, но, думаю, даже в этом случае, на инициализацию уйдет много времени.

[@StopDesign]

Лично у меня все претензии не к PHP, а к пехепешникам. Качество кода, количество мозга и так далее…

[@Zerstoren]

особенно это видно по govnokod.ru

[@VolCh]

Не думаю, что качество моего кода или, тем более, количество мозга у меня сильно меняется в зависимости от того на каком языке пишу, будь то PHP, Ruby, Python, Erlang или JS (языки на которых писал что-то посложнее helloworld за последние года 3). Более того, есть подозрение, что код на PHP у меня более качественный. Чисто потому что в куда большем количестве чужого кода разбирался.

[@StopDesign]

Однако, мысль вы не поняли :-)

[@VolCh]

Что я не понял? У вас претензии к качеству моего кода и количеству моего мозга. :) Я считаю, что эти вещи от языка на котором я пишу никак не зависят.

[@antoo]

ИМХО, в каждом языке есть и гуру, но есть и быдлокодеры, просто порог вхождения последних разный. PHP простой и даёт множество функций из коробки (сравните, например, с С++), поэтому многие новички, которые даже не знают, что есть так называемое качество кода, начинают именно с него. Глупо предъявлять претензии ко всем пхпшникам, есть множество грамотных, сам общаюсь с ними лично.

[@basilisk]

Есть такой момент. Но:

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

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

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

[@VolCh]

Не то что не принято, а очень трудозатратно, если не CGI писать — написать страничку с «hello world» означает сначала написать сервер, обрабатывающий запросы — сокеты и т. п. А PHP в стандартном конфиге сочетает удобство простоту CGI для разработки и куда большую скорость.

[@MpaK999]

Что такое «стандартный кофиг»? mod_php? php-fpm?

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

Для Ruby чтобы работать в веб-окружении есть Rack подключается одной строкой, второй строкой подключается любимый сервер thin, третьей берите в руки Erb-шашку и RUBYте всех от плеча! Проблемы нет.

[@StopDesign]

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

[@VolCh]

Ещё важна инфраструктура, спрос и т. п.

[@zuborg]

PHP используется как основной язык на 77,9% среди всех сайтов
windows используется на ещё большем проценте комп«ютеров, так что теперь, на basic-е программировать?

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

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

Ну и главное замечание к статье — чем же так PHP гораздо лучше, чем мы думаем, автор так и не обьяснил…

[@SamDark]

Тогда уж на C#, а не на basic. C# клёвый. Рекомендую.

[@VolCh]

Тем, что у многих о нём устаревшее представление, о PHP5.4 думают как о PHP3, да ещё считают, что пишут на нём только в «спагетти»-стиле. У вас лично может быть объективное и вы прекрасно знаете достоинства и недостатки как самого языка, так и экосистемы. Но многие этим похвастаться не могут, «не читал, н осуждаю» или «не знал, да забыл».

[@zuborg]

Что ж, не могу не согласиться, что PHP5.4 действительно сильно отличается от PHP3.

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

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

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

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

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

[@esc]

Скорость для php не проблема с тех пор, как появился странслятор в с++ код, который после компиляции работает на сравнимом с нативным кодом, уровне. Работает при этом эффективно и надежно (давно не слышал о каких-либо проблем с безопасностью на ФБ и ВК).

[@dmitriid]

> Скорость для php не проблема с тех пор, как появился странслятор в с++ код

ага. от Facebook'а. Заточенный на Facebook. Неспособный скомпилировать >>90% кода на РНР.

[@esc]

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

[@esc]

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

[@esc]

Да, был код на php, работал через php-fpm+apc и nginx, я его через hiphop собрал в виде демона и ab показал 3200 запросов против 110 (тот-же сервер, загрузка процессора в обоих случаях 100%). База не использовалась, но работала шаблонизация (шаблоны скомпилены в php код), ну и стандартный контроллер, фильтрация данных и прочее. Код реальный, брал работающий самописный проект.

[@dmitriid]

Действительно, если нет аргументов, лучше обсудить личность

[@VolCh]

С реализацией да, у PHP постоянные проблемы. Как-то рассматривают частные случаи в строго определенном контексте. Скажем сделали валидными выражения func()[0] и (new Class())->method(), но надо проверять будет ли работать (new Class())[0]->method(); и с большой вероятностью не будет, чисто по опыту — не любят разработчики PHP общих решений. Операторы типа [] -> () применяются не к выражения какого-то типа, а к строго определенным конструкциям. Собственно это скорее не операторы с операндами, а трехэлементные конструкции имеющие смысл в строго определенных контекстах, причём в разных контекстах разный смысл.

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

[@dmitriid]

> чисто по опыту — не любят разработчики PHP общих решений.

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

[@VolCh]

Что-то подобное подозревал. Судя по отсутствию формального описания синтаксиса, внутри творится чёрти что.

[@dmitriid]

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

[@Psih]

Они вообще хотят поменять лексер на более современный, ибо тот что сейчас не способен справится с новыми веяниями, у него нету контекста — отсюда и проблемы с тем, что некоторые вещи очень проблемно реализовать.
Если мне память не изменяет, то хотят на lemon parser пересесть и какая-то работа за кулисами там шла, но инфы почти нету.

[@dmitriid]

В итоге получится, как с Юникодом :) «Много рутинной работы, никому неинтересно, все забили» :)

[@VolCh]

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

[@VolCh]

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

[@VolCh]

Грубо говоря не знаю когда появился php, но когда мне поставили задачу создать сайт я выбирал из трех языков: C, PHP и Perl/ У PHP было только одно значимое для работодателя преимущество — прототип (как сейчас модно говорить) на нём я создал за день, На сишный мне трое суток понадилось, от перла после суток разбирательства я отказался в принципе.

[@Jakeroid]

99% не динамические? Вы уверены?

[@DevMan]

Конечно. Жду статические гугл с яндексом и прочие дропбоксы с фейсбуками.

[@Jakeroid]

Статический гугл? Скачиваешь список сайтов и там уже ищешь через Ctrl+F?

[@haskel]

А вместо браузера вывод на принтер.

[@Jakeroid]

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

[@DevMan]

А проблема кросс-принтерности не появится?

[@Jakeroid]

Думаю появиться :). Каждый ведь захочет сделать свой принтер особенным.

[@nekt]

Принтер с поддержкой ECMAScript — это будет АД

[@nekt]

особая серая склизкая бумага ^__^

[@ShadowPrince]

Бумаги не хватит дебажить.

[@VolCh]

Кончаются раньше чем рассчитываешь даже без принтеров…

[@madproger]

Я думаю имелось ввиду, что сайты вполне могут обойтись без динамики… ну про 99% конечно утрированно, но нереально огромное кол-во сайтов можно было бы сделать статикой + минимум JS скриптов…

[@Jakeroid]

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

[@BlessMaster]

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

[@VolCh]

Они тащат груз BC, по-моему. Поставь их разработчикам задачу написать такой же по функциональности движок и уверен качество кода будет куда выше. Вот только будет ли кто пользоваться этим движком с оригиналом общее имеющее только название, если заказчики сайтов уже вложили немалые деньги в создание модулей, тем и прочую кастомизацию. Скорее просто кто-нибудь форкнет текущую версию, как это было с, например OpenOffice.org, пускай и причины были другие.

[@esc]

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

[@BlessMaster]

Какую статику, если речь идёт про новые функции?
Считаем что статика — это одна функция: контент.
Форум на статике или рейтинг постов в блоге — уже не прокатит.
А ведь это достаточно распространённые функции в современном вебе и список таких функций можно набросать приличный.
Кроме того, мои заказчики хотят сами управлять контентом — генератор тоже нужно куда-то поставить и настроить. Так CMS же и выполняет эту функцию — это онлайн редактор сайта, с этим самым сайтом и связанный.

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

[@esc]

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

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

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

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

[@VolCh]

Я думаю, что различные профили пользователей и личные кабинеты есть на большем числе сайтов чем 1% — куда не ткнись всюду требуют регистрации, чтоб даже ознакомиться с контентом. В принципе не очень сложно должно быть сделать блоговый движок на статике, но к нему всё равно нужен динамический бэкенд («админка»), да и СУБД больше как-то подходит для задач типа «найти все посты с таким-то тэгом», чем рыться в HTML файлах. В итоге приходим к системе, которая, по сути, по POST запросам генерирует сначала модель в БД, а потом её представление в файле — в динамических системах это называется файловое кэширование представлений.

[@web36m]

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

[@retran]

Я просто оставлю это здесь — php.net/manual/en/types.comparisons.php

[@retran]

«php» == TRUE
«php» == 0
0 != TRUE

Крутая система типов, да.

[@IngvarrT]

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

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

[@retran]

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

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

[@VolCh]

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

$var = $_GET['var'];
if ($var) echo 'TRUE'; 
echo $var * 2;

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

[@retran]

Я привык считать, что такие конструкции — говнокод. Именно из-за неявного приведения.

В питоне или в руби сравнение строки с число всегда вернет false. Ну просто потому что число и строка — разные классы объектов. И это гораздо более логично.
А не пустая ссылка всегда истинна. Пустая — ложна.

[@Nerten]

Приводите типы, сравнивайте строго. Кто мешает?

[@retran]

Никто ;) Я не пишу на ПХП, там слишком маленькие зарплаты ;)

[@Zigmar]

Я бы не стал писать на ПХП даже если бы платили нормально :)

[@VolCh]

А если бы платили только за пхп?

[@retran]

Если бы платили только за пхп — я бы ушел в аналитики. Ну или тестировщики.

[@anycolor]

тестировать код на PHP?

[@Zigmar]

Все равно. Вы бы пошли писать на КОБОЛе, если бы «только за него платили»? :) Есть пара технологий, с которым я имел несчастье иметь дело, и которыми я больше не притронусь не при каких обстоятельствах. Например MFC. От PHP у меня, правда, нету такой травмы, но язык мне очень сильно не нравится и плохо себе представляю, что может заставить меня с ним иметь дело…

[@Nerten]

Хорошим специалистам хорошо платят.

[@VolCh]

Всегда ли? А если операцию сравнения переопределить?

А насчёт логично: спросите у непрограммиста: '123' равно 123 или не равно. PHP кроме всего прочего позиционируется как первый язык, на котором можно начинать писать не зная что такое тип, класс, объект, как они хранятся в памяти и т. п.

[@retran]

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

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

[@VolCh]

Просто не люблю квантор всеобщности :)

[@web36m]

И слегка неожиданно:

defined('null'); // true
defined('NULL'); // true
define('null', true); // notice нельзя переопределить константу
define('NULL', true); // true
NULL===true // false
('NULL')===true // false
('NULL')==true // true

[@ngreduce]

Тут как раз все логично.

[@asumin]

а вы хотите так:

define('true', false);
define('false', true);
// счастливой отладки

?

[@AleksDesker]

Loose comparisons with ==
Strict comparisons with ===
От вашего коммента складывается впечатление что вы ниасилили перевод этих 2 строк в вашей ссылке.

[@retran]

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

Наличие костылей ДАЖЕ В СИСТЕМЕ ТИПОВ — это один из признаков того, в чем автор поста пытается нас разубедить.

[@AleksDesker]

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

[@retran]

Это не баг, это фича, да ;)))

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

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

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

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

[@VolCh]

Это просто разные типизация. Транслятор с сильной обзовётся, со слабой выберет наиболее вероятное (по мнению разработчиков) кастование. Хотите сравнить число со строкой — в любом случае правила приведения типов нужно знать.

[@retran]

Слабая типизация — это когда типизация идет по совпадению контрактов (оно же «утиная» — если квакает как утка… и так далее). Сильная — по совпадению типов и их отношениям в иерархии.

И у строки и у числа отчетливо РАЗНЫЕ иерархии и РАЗНЫЕ контракты.

[@VolCh]

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

[@dmitriid]

утиная типизация — это «выглядит, как утка, плавает, как утка, крякает, как утка — значит утка». Строки и числа в PHP — это не утиная типизация, а слабая динамическая типизация.

[@VolCh]

Утиная типизация один из видов слабой типизации.

[@dmitriid]

Но только она не относится к этому случаю.

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

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

[@VolCh]

Я и написал, что утиная типизация лишь один из видов слабой типизации. Один но далеко не единственный.

[@dmitriid]

А, да, перечитал подветку. Так и есть

[@AleksDesker]

Не понял, с чего вы с PHP на JavaScript перескочили, в остальном могу лишь еще раз повторить, что причина в конкретной области применения. Если следовать вашей логике получиться шаг назад во времена Perl-a, когда у каждого программера была собственная самописная функция для распарсивания значений из POST&GET и т.п. Если вам кажется непонятным или неправильным существующее неявное преобразование или еще какие-то моменты, просто используйте явное приведение типов и т.п., не надо доказывать, что все остальные не правы. Именно эти «архитектурные ошибки» сделали PHP на порядок эффективнее и как следствие популярнее других языков в веб-разработке.

[@retran]

Ну про эффективнее — это откровенная неправда ;)

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

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

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

P.S. Если следовать моей логике надо не возвращаться к перлу, а идти вперед от пхп — к рельсам или дотнету.

[@anycolor]

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

Так работает хабр, к сожалению.

[@retran]

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

Я захожу и кидаю всем давным давно известный аргумент. Получаю в ответ баттхерт. Это уже не хабр…

[@VolCh]

Что значит откровенная неправда? В чём вы меряете эффективность?

[@retran]

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

А вы в чем меряют выше, чтобы говорить о «сделали PHP на порядок эффективнее»?

[@Nerten]

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

[@retran]

На данный момент — .net (c#, f#) под виндой; ruby, lisp, ANSI C — в линуксе.

[@dmitriid]

> Это не костыли, это осознанно подобранные под конкретную область применения допущения.

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

[@AleksDesker]

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

[@dmitriid]

> Изначально система типов подобрана под весьма узкую задачу

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

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

[@AleksDesker]

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

[@dmitriid]

> Не понятно почему PHP постоянно пытаются записать в недостатки какие-то факты из лохматых 90х.

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

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

[@AleksDesker]

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

[@dmitriid]

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

[@AleksDesker]

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

[@dmitriid]

> Это уже фейл какой-то, а не костыль, костыль это все же какое никакое, но решение, а не его отсутствие

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

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

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

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

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

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

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

[@AleksDesker]

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

$str = '1';
return ++$str;

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

[@dmitriid]

> У меня остался только один вопрос, почему вы продолжаете дискутировать о PHP, вместо того

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

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

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

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

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

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

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

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

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

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

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

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

[@AleksDesker]

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

[@dmitriid]

> По вашей логике прежде чем браться за PHP стоит выпилить си и все подобные языки,

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

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

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

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

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

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

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

[@AleksDesker]

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

[@dmitriid]

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

[@dmitriid]

Ах, и да.

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

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

[@anycolor]

за все 7 лет программирования на этом языке я лишь один или два раза попадался на баги, связанные с неправильным приведением/сравнением типов.

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

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

[@dmitriid]

> Стоит ли овчинка выделки? Имхо, это не та вещь, которая мешает писать приложения.

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

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

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

[@monolithed]

В итоге получилось то, что получилось. === является банальным костылем

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

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

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

(int)$var + 1;

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

Или как в Python:

var = "1"
int(var) + 1

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

concept EqualityComparable<typename T> 
{

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

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

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

[@dmitriid]

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

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

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

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

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

1. У С++ во многом такая же проблема, как и у РНР — слабая типизация.
2. Цели были другими

[@anycolor]

>(int)$var + 1;

лучше тогда уже intval($var) + 1;

[@ainu]

(int) не функция, а значит, гораздо быстрее.

[@anycolor]

комментарий был не про скорость в целом, а про аналогию с другими языками, по типу int(var) в Python.

[@vasilievvv]

0 != TRUE в таких языках, как C, C++, Python и JavaScript.

[@VolCh]

phpDaemon — asynchronous server-side framework of network applications implemented in PHP using famous libevent which makes possible to handle hundreds and thousands of simultaneous connections.

[@VolCh]

Что в вашем понимании значит платформа? Чем node.js (я правильно угадал? :) ) отличатся от js? Я всегда думал, что это надстройка над языком — библиотеки и биндинги.

[@el777]

Вот только не надо на PHP демонов писать.
Не предназначен он для этого — там все заточено под другую задачу.
Написал нам тут один аутсорсер демона на пхп — за 1 день утекает 4ГБ памяти!!!

[@esc]

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

Зачем винить инструмент, если нафейлил тот, кто не умеет им пользоваться.

[@gigimon]

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

[@esc]

Ну что значит не предназначен? У нас не используется многопоточность — только очереди, а по остальным параметрам все там нормально предназначено. Мне постоянно говорят о таких вещах. То для парсеров php не предназначен. То демонов на нем писать нельзя. То для больших сайто вон плохой.
Мне кажется, что эти все люди живут в каком-то царстве слухов. Да, у языка есть ограничения. Основные — отсуствие многопоточности и оверхед при работе с большими массивами. Если об этих ограничениях знать, то нормальный получается результат.

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

При этом, ряд задач у нас делается на Си потому, что к ним специфические требоавния как по скорости, так и по расходу памяти. Другие языки, приемлимого результата не дадут. Такие задачи на php никто и не пытается решать (даже не смотря на наличие таких инструментов, как hiphop)

[@tnz]

Ну и нода тоже течет, и еще быстрее.

[@Davert]

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

Имхо, у Фабьена когнитивный диссонанс. С одной стороны он утверждает, что PHP очень простой язык, а с другой — для работы с самым популярным PHP-фреймворком необходимы знания об интерфейсах, итераторах, DIC, аннотациях и прочем-прочем-прочем.

[@VolCh]

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

[@Davert]

Градация между junior и senior в PHP огромна как нигде.

Junior PHP должен уметь поковырять форум или друпал и поменять пару функций и переменных.
Senior PHP должен знать Symfony2, Zend, MVC, ORM, Doctrine2, DIC, annotations, Yaml, Json, XML, Git…

Думаю стоит или придерживаться принципа KISS в разработке или не упоминать о простоте PHP.

[@VolCh]

Так может это и есть его основная сила?

[@skywatcher]

PHP используется как основной язык на 77,9% среди всех сайтов
99.(9)% которых являются говносайтами

[@IngvarrT]

… и если переписать их на другом ЯП, то они станут вареньесайтами, да? :)

[@skywatcher]

Никак нет. Просто это выглядит, как попытка задаваить железным фактом. Мол, если 77,9% сайтов на PHP написаны, то PHP прямо такой крутой.

Мне нравится Scala. Но на этом языке не написано и 0.01% веб-сайтов в мире. И это не делает его плохим языком как и хорошим.

[@nekt]

99.(9)% сайтов — говносайты. Независимо от языка.

[@skywatcher]

дык о том и речь.

[@nickon]

дык это не от языка зависит а от их создателей!

[@skywatcher]

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

[@VolCh]

А он и есть сильный. С одной стороны говносайты можно пачками штамповать, с другой такие монстры как ФБ.

[@nickon]

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

а процент показывает лишь популярность языка и не более того (имхо)

[@skywatcher]

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

Полная херня. Я 3 года писал на PHP. 2 года пишу на Java. Так вот я на Java умудряюсь разрабатывать код не медленнее, чем на PHP. Если говорить о веб-сайтах, а не о скриптах из 2-ух страничек.

[@tnz]

Ну вы сужаете круг задач. Иногда нужно и 2-х страничные сайтики делать. Иногда в 10 страниц.

[@skywatcher]

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

С какого это перепугу она лучшая веб-платформа? Вы чего обкурились, уважаемый? Не слишком ли громкое утверждение? Я же не делаю тут сбросы говномасс, что Java это круто, а PHP это не круто.

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

[@heel]

[@skywatcher]

>> Я просмотрел все: от Perl до Ruby

Как-то узко посмотрел. Столько буков между A и P, S и Z.

Особенно с учетом, что можно было бы перенять опыт того, что уже сделано для такой платформы, как JVM. Maven, Ant + Ivy только чего стоят.

[@VolCh]

PHing Is Not GNU make; it's a PHP project build system or build tool based on Apache Ant. You can do anything with it that you could do with a traditional build system like GNU make, and its use of simple XML build files and extensible PHP «task» classes make it an easy-to-use and highly flexible build framework.

[@heel]

Похоже на ответ к другому комментарию))

[@skywatcher]

промахнулся. был ответом на статью

[@nickon]

Почему то читая статьи о ненависти к PHP у меня возникает ощущение что проводится чёрный пиар.

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

[@VolCh]

Заказчики не хотят идти следом. Нужно им помочь :)

[@nickon]

А заказчику не всё ли равно какой язык? :) Судя по моей практике — заказчику важен только результат причём он ему нужен ещё вчера :)

[@VolCh]

Заказчику всё равно какие буквы. Но заказчику не всё равно каковы:
— стоимость и распространенность хостингов
— стоимость и распространенность специалистов
— уровень входа в язык/технологию

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

[@truezemez]

Сериал «PHP. Холивар. Часть 2».
Список серий (для тех кто пропустил):
The PHP Singularity
PHP solves problems. Oh, and you can program with it too!
Where is your Vision Jeff?
PHP is much better than you think
The True Problem With PHP

[@knekrasov]

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

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

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

Это отнюдь не хороший язык. Но это ничего не значит.

[@int03e]

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

O RLY?

[@nDiviD]

Ок ребят, давайте поставим наш извечный вопрос таким ребром:
Я решил, что мне необходимо изучить PHP. С чего начать учить(желательны русскоязычные источники и литература)? И стоит ли учить его, может есть язык способный «выбить» PHP?

[@AleksDesker]

Вы бы хоть точку отсчета указали, человеку мыслящему в плоском С литература нужна будет сильно отличная от того, кто пришел с Java. Если нужен только синтаксис www.php.ru/manual/ и гугла более чем достаточно.

[@dmitriid]

Надо поставить себе цель: зачем учить?

Чтобы выучить язык программирования? Лучше взять Python/Ruby/Scala/Erlang или даже всех их вместе.
Чтобы выучить язык программирования, который даст работу? Лучше взять все вышеперечисленное + C#/Java

Чтобы получить работу бедному студенту? Ну да, PHP подойдет. Но лучше студенту выучить выщеперечисленное и найти болеее высокооплачиваемую работу.

[@dmitriid]

> PHP — даст заработать любому человеку

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

[@dmitriid]

1. У истории нет сослагательного наклонения
2. Работал бы на каком-нить С++.

И?

[@nDiviD]

Цель — удобно чувствовать себя богом в вебе.

P.S. Абстрагируемся от меня =) Считаем, что вроде как на какой-то средненький уровень программирования я претендовать могу, главное синтаксис ^_^

[@dmitriid]

> Цель — удобно чувствовать себя богом в вебе.

:)

Тогда Руби/Питон :)
И параллельно — что-то из функциональщины (Erlang/Haskell) — для общего развития

[@AleksDesker]

Чтобы чувствовать себя богом не достаточно знать один язык, но достаточно шизофрении.
PHP это на сегодня явный лидер в веб-разработке, большой спрос, очень высокая оплата для топ-разработчиков, огромная конкуренция и тотальный демпинг среди новичков. Если вы готовы к конкуренции и считаете, что вы сможете доказать, что вы на порядок лучше 100500 индусов — оно того стоит. Если же вы не слишком уверены в своей потенциальной звездности, тогда конечно лучше Руби/Питон, там вас простят и поймут, просто за то, что вы пишите на языке, на котором замену вам найти очень сложно.
Имея средненький уровень и зная только синтаксис вы навряд ли сможете уйти в отрыв от индусов и школьников, для этого варианта скорее действительно подходит более узкий кусок рынка и менее популярный язык.

[@nDiviD]

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

[@retran]

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

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

[@anycolor]

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

[@EnChikiben]

А когда меня начинают донимать что PHP плох, я просто говорю:
— «На чем написан второй по посещаемости сайт во мире Facebook, и наш ВКонтакте», после чего как правило всякие претензии уходят )

[@AleksDesker]

Ок, Facebook написан на PHP, но ведь PHP написан на С, а С написан на ассемблере… а значит хорош будет только тот, кто написан на Facebook!

[@antoo]

Во-первых, Facebook и ВКонтакте написаны на PHP, а не на С и ассемблере.
Во-вторых, кто-то говорит что С и ассемблер это плохие языки?
Непонятно к чему этот сарказм, дело действительно не в языке, а в программистах.

[@AleksDesker]

Если из крутости FB следует крутость PHP, то по этой же логике если PHP плох, то плохи С и ассемблер, ведь он на них написан.
К тому и сарказм, что по качеству продукта нельзя однозначно судить о качестве языка (особенно в случае с FB, который по сути написан не на PHP, а не собственном компиляторе, использующим PHP синтаксис).

[@Weageoo]

Пошел учить пэхапэ…

[@hazg]

>> PHP гнобят все, кому не лень
Кто против пхп — палец вверх.
Кто за — палец вниз.
Комментарии внизу.

[@ainu]

PHP — язык, для разворачивания решений на котором не нужен отдельный сервер в виде приложения, либо рельс, ноды, либо чего-то подобного. Это уменьшает стоимость разворачивания. Этим мне он нравится.
PHP — язык с огромным коммьюнити и богатой документацией, с кучей примеров кода и библиотек на любой вкус. Этим мне он нравится.
PHP — язык, изначально, исторически созданный для Web-приложений (в отличии от питона и руби, к примеру). Поэтому для написания веб-приложения на нём в первую очередь пишутся веб-приложения (а на иных языках — сначала пишется web-сервер). Этим мне он нравится.
PHP — язык, решения на котором дёшево поддерживать. PHP-программистов просто найти и легко обучить. Проще гарантировать заказчику, что его проект не умрёт. Этом мне он нравится.
PHP — язык, который легко собирается под различные платформы. По мне — проще питона, по крайней мере при кросскомпиляции с отсутствующими библиотеками. Имею в виду не голый питон, а например pygame. Тоже самое с Java. Этим мне он нравится.
PHP — язык, богатый на стандартные изкоробочные функции. Например, существуют проекты, которые копируют PHP-шные функции в Javascript, потому что аналогов в яваскрипте нет. Работа со строками в PHP проста и удобна (в отличии от яваскрипта, явы или си). Этим мне он нравится.
PHP прекрасно, просто и удобно из коробки работает с базами данных, в отличие от той же node.js. Этим мне он нравится.
Так что я за PHP.

[@hazg]

Афигеть. Ёпт. Как не скажу что пхп — в жопе. Ну как тут не сказать, что хабр за один лишь пхп не люблю, хоть он и на рельсах работает. Волшебно. Как это??? Гы.

Структурируем:
Документация:
Сам язык документирован в том же объеме, как и остальные популярные языки. Камметы?
>> язык, изначально, исторически созданный для Web-приложений…
Ох, ёпт. удалите меня. Да — это так. Что же в этом хорошего? Веб уже другой.
>> язык, решения на котором дёшево поддерживать…
Факт. Ну там 1с исключение. А так «знатоков» — докуя.
>> язык, который легко собирается под различные платформы.
собирается. это не достоинство языка. Они все собираются.
>> язык, богатый на стандартные изкоробочные функции.
10xМинусов мне в карму. За то что сказать хочу.
>> прекрасно, просто и удобно из коробки работает с базами данных, в отличие от той же node.js. Этим мне он нравится.
Да мне вообще руби нравится с гламурными рельсами и клал я на ноду (даже не пробовал, извиняюсь перед пользователями ноды, я тут холивар развожу). И на пхп я 10 лет писал. Как же за*бали холиварщики.

Да нормальный php, просто ты волнуешься.

[@gaelpa]

В хвалебном топике про пхп? Смело.

[@hazg]

Я знаю, что возражать фанатам 1с и пхп нельзя. Местами вырывается — но кармодрочево меня не прельщает. (+слишком ленив, чтобы писать статьи и затем срать в карму)

Пока не заминусовали:
и да: доллар вы будете набирать еще долго. trollface. Так язык был «спроектирован».

[@Ember]

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

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

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

[@VolCh]

Не советовал бы PHP в качестве первого языка и основы для сравнения. Прежде всего из-за его слабой типизации. Это же относится к JS. Python или C# более предпочтительны, по-моему, для таких задач.

[@Lestat]

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

прямо-таки любая?
уже несколько проектов переписали с PHP на python, в обоих случаях сократилось серваков в N раз и скорость разработки повысилась раза в 2-3 :)
PHP умер, признайте это :)
с каждым годом все больше проектов (серьезных) будут переписывать с PHP на python/ruby/etc.

[@esc]

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

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

[@Lestat]

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

[@esc]

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

Очень объективно и аргументированно, конечно. Если все так, зачем крупные проекты вообще на php пишут?
Почему тот-же Youporn с очень солидной нагрузкой недавно переписал сайт на php, а не питоне, руби или просто заново не сделал на perl'е? Не смогли найти разработчиков или забыли провести экспертизу перед принятием решения?

[@Lestat]

я уже говорил что это получено на своем опыте, еще аргументация нужна? )

круто ) один youporn, и все?

p.s. популярнее не значит лучше, это везде так

[@esc]

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

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

То, что много людей пишут на php черти-как, не означает, что мало тех, кто делает это грамотно.

[@Lestat]

> с ростом проекта, от php пришлось бы избавиться

таких примеров полно :)

[@esc]

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

[@asumin]

ни троллинга ради, а исключительно из профессионального интереса, на каких задачах (из вашей практики) именно PHP стал узким местом?

[@nickon]

хотелось бы увидеть подтверждение ваших слов в цифрах на реальных проектах

[@anycolor]

Ерунда какая-то несустветная.

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

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

[@soider]

У вас hiphop какая-то серебряная пуля?

[@esc]

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

[@anycolor]

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

Хватит уже травить эти басни и слухи.

[@TiGR]

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

Короче, аргумент ни о чём, согласен.

[@shurshur]

Недопереведено… register_globals and magic_quotes…

[@asumin]

Ох уж эти холивары…

• У каждого языка своя ниша, для веба лучше PHP сейчас нет — это отличный клей между веб-сервером, БД, мемкешами, веб-службами, почтовым агентом и т.п. Именно так его и надо воспринимать, писать на PHP синтаксический анализатор многомегабайтных текстов — глупо (но можно, pcre работает довольно шустро), так же глупо писать веб-интерфейс сайта на Си или Си++ (получится тот же php, только хуже). Для тяжелых бэкендов (расчеты графов, рендеры, обработка видео) — пожалуйста никто не мешает использовать другой, более специализированный для конкретной задачи инструмент.
• Nginx + PHP-FPM + APC = высокая производительность.
• Тем кто спрашивал «учить PHP или не учить», отвечаю: «Учить. Платформу для нового проекта выбираютне программисты, а инвесторы (заказчики), а эти парни деньги считать умеют, и понимают, что держать штат PHP программистов, гораздо дешевле и менее рисковано, чем C-, Java-, Python- или Ruby- программистов; и что купить один раз лишний сервер и балансер — тоже дешевле».

[@A1lfeG]

>> что держать штат PHP программистов, гораздо дешевле и менее рисковано, чем C-, Java-, Python- или Ruby- программистов

Тобто PHP программисты малооплачиваемы?

Замените с своём посте PHP на C#, на Ruby, на Java. Мало что поменяется. Уж очень субъективный комментарий.

Все заказчики с которыми я работал, свято верили что им нужен ТОЛЬКО .Net. Это ж не значит, что .Net зохавает весь мир.

[@esc]

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

[@asumin]

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

[@esc]

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

[@sectus]

Я вот Диаблу убиваю… И думаете я хочу убить его раз и навсегда?: )

[@ibooj]

однако от чего же мы так думаем про него?)

[@justthefish]

Как-то так.

[@bugman]

> HP используется как основной язык на 77,9% среди всех сайтов, где язык платформы известен. Wordpress используется в 16,6%
Люблю статистику, она такая шлюха :). Одностраничный г-сайтик hello world, склепанный в качестве первого творения считается? сетки сателлитов, дорвеев и прочих сеошных чмошностей считаются?
Честнее было бы сравнить по трафику. Подозреваю что на эти 77.9% сайтов приходится не так много веб трафика.
PS php тоже люблю

[@VolCh]

1-й (фэйсбук), 6-й (вики), 22-й (вавилон), 23-й (вордпресс) и 32-й (Вконтакте) сайты из топ500 по посещениям по статистике alexa точно используют PHP.

[@bugman]

ок, с 4 из 500 разобрались. Остальные?
ну и опять, честнее было бы по суммарному трафику считать, хотя — who cares?

[@VolCh]

Проводите исследования, считайте, раз что-то считаете нечестным.

[@Inori]

Ну если по траффику сравнивать, то C++ неоспоримый лидер среди языков для веб-разработки, на нём google.com держится.

[@Ubran_Hera]

у вас неточность:

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

имелось в виду:
подходит для школьников