Как стать автором
Обновить

Комментарии 429

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

чуть глаза не сломал от вашего комментария… пора отдыхать)))
Похоже, у нас с вами одинаковые браузеры и операционки.
У меня, похоже, другая ось. Какая у вас и почему сглаживание даёт такое размытие?
Дело не в оси. Если реже глаз, значит, один LCD монитор RGB, а другой BRG. Отсюда и цветной вырвиглаз.
Как влияет монитор на файл скриншота?
Субпиксельное сглаживание зависит от последовательности пикселей.
От монитора зависит система, которая и сглаживает.
Если увеличить скриншот, то видно, что буквы не чёрные, а красно — синие.
Вот тут ru.wikipedia.org/wiki/ClearType сказано, почему ClearType не работает на ЭЛТ.
я звизда!
Вот и повелитель Хабра!
скорее очередной актер похапэ
Судя по профилю (пункту «О себе» и карме) — я бы даже сказал «Чёрный властелин»
Не, Чёрный властелин вроде еще до этого пытался захватить хабр.
<голосом рассказчика длинной поучительной истории>
… но попытка была неудачной… Карму ему слили, комменты минусовали, топики критиковали… Он расстроился и ушел на имиджборды.
</голосом рассказчика длинной поучительной истории>
Опасно вешать такой коммент в конце дня пятницы!
Я знаю, как Deffe может исправить ситуацию.
Ничего лучше «пыхи» здесь быть не может? :-)
Капитан ПХП идет на помощь!

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

(Сорри, не могу вставить картинку прямо в комментарий.)
Я понимаю что после написания Вашего поста прошло 6 лет, 5 мес. 1 нед. и 4 дня, но не могли бы Вы перезалить картинку? А то ссылка не работает.
Я тоже сначала пост по вашей ссылке прочитал, а потом здесь
Зачет!
Написал, что статья зачетная — заминусовали. Как вас понять?
> Да, у PHP сейчас лучший менеджер зависимостей из всех языков.
говорить так и менеджере зависимостей, который был inspired by npm — это по крайней мере смешно

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

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

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

Аргументируете? Сами-то на чем пишете? Чем оно лучше? Оно успешнее РНР?
На последний вопрос сам и отвечу: как видно из предоставленной в статье статистики — нет.
> PHP все еще является наипростейшим языком для изучения не-техническими людьми
> и именно это же является одной из его слабых сторон

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

(написано по просьбе 1999)
Если вы говорите, что PHP быстро развивается, то точно не видели Ruby и Python. Эти языки чуть ли не на прорядок быстрее развиваются.
Гиперболы в разговорах о PHP, как я вижу, не редкость, а норма.
Я ещё меньше года назад программировал на PHP… не успел я ещё гиперболизироваться.
Чтобы не быть голословным…

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

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

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

3 месяца vs 3 года
Надеюсь, что зависимость не линейная от времени. Composer понравился :)
Я не совсем понял, вы сравнили количество скачанных ruby пакетов с количеством добавленных php пакетов?
725 млн. вс 1 млн
41114 вс 1900
3 года вс 3 месяца
Так и не понял, что вы хотели сказать этими цифрами. Что за 3 года ruby пакетов добавили больше, чем php за 3 месяца?

Судя по твитам Фабьена, следующая его статья будет о том, чем, собственно, composer лучше bundler'a ;)
Что сравнивали не количество закачек гемов с количеством пакетов композера.
Бандлер работает. Чем composer может быть лучше вещи, которая просто работает?
Тем, что он работает лучше? :)
Одна тонкость — для руби это официальный и едва ли не единственный источник?
Для PHP же — это одна из множества альтернатив, о которой ещё далеко не все знают, поскольку неофициальная.
Сравнение некорректно.
Это не тонкость, а сила языка. Нормальные программисы просто так делятся нормальным кодом.
А в PHP-мире каждый второй сидит со своей CMS или велосипедом, боится показывать… иногда правда показывает и просит не малую цену.
С другой стороны как-то нет на слуху CMS на языках отличных от PHP. Фреймворки есть, CMS нет.
Те, кому нужны были CMS на Ruby, знают хотя бы парочку. Причем больная часть CMS — это надстройка над ROR.
Обычно людям нужна (если формализировать их требования) просто CMS, может несколько кастомных модулей к ней. Почему-то выбирают CMS на PHP и заказчики, и исполнители. Сам не знаю почему выбираю :) Может мало документации?
В 2000-2005 году рынок был переполнен дешевыми китайскими велосипедами с кучей перделок и все их покупали. Сейчас не один нормальный человек за такую кучу стали не сядет.

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

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

Я это заметил и потому больше «финансовую подушку» не создаю, иначе встречу интересную задачу и буду приплачивать за возможность её решить :)
Ещё китайцы не тратились на прочность, плевали на материал (сталь вместо алюминия)… в общем все самое дешевое.

До ларька за пивом сьездить можно, но что-то серьёней и он разваливается. В общем не удачно сравнение выбрал, возможно не у всех есть такой транспорт.
НЛО прилетело и опубликовало эту надпись здесь
Люди выставляют «ТЗ», я уточняю неясные моменты и предлагаю ценник и сроки. За интересные задачи — скидка. Что они считают за качество мне не интересно, вся инфа (плюс-минус лапоть) у них есть.
НЛО прилетело и опубликовало эту надпись здесь
Я предлагаю на выбор сайт на симфони и на рельсах, на рельсах в 1,5 раза дольше и в 1,5 раза дешевле. Никто не выбрал на рельсах!
НЛО прилетело и опубликовало эту надпись здесь
Просто «бурятку» нужно дольше заводить до состояния «огня». Но это приятно, вот и скидка :)
Тьфу, негритянку.
НЛО прилетело и опубликовало эту надпись здесь
Час работы с положительными эмоциями стоит много дешевле чем с отрицательными. За костыль я беру больше денег чем за возможность покрыть тестами, отрефакторить и нормально внедрить фичу.
НЛО прилетело и опубликовало эту надпись здесь
На рельсах в 2-3 раза быстрее получается, если сравнивать ROR и Symfony.
НЛО прилетело и опубликовало эту надпись здесь
Разработка.
НЛО прилетело и опубликовало эту надпись здесь
Я делаю. В среднем на рельсах в 1,5 раза дольше чем на симфони. Слышал и противоположные мнения.

Производительность команды субъективна.
НЛО прилетело и опубликовало эту надпись здесь
Ни что не объединяет Ruby и Python разработчика так, как затролить PHP =)
Это точно.
НЛО прилетело и опубликовало эту надпись здесь
У вас быстрее, у меня медленнее. На рельсах у меня быстро прототипы получаются, решения в лоб и т. п. Когда начинаются нестандартные сценарии, то предпочитаю переходить на симфони.
НЛО прилетело и опубликовало эту надпись здесь
> Когда начинаются нестандартные сценарии, то предпочитаю переходить на симфони.
Пример, пример пишите. Никогда у меня такого не было, все гладко списывается.
Может у вас более глубокие знания Ruby и/или RoR чем у меня. А может у меня более глубокие symfony2. И уж точно production окружение для php на голом debian/ubuntu я быстрее разверну раз в 100 чем рельсовое, лезть в ману или гуглить не потребуется.
Есть такие решения как capistrano и подобные. На голом сервере все само разворачивается одной командой.

Руками приложение я разворачивают 5-10 минут… и то большая часть времени качаются пакеты и гемы.
НЛО прилетело и опубликовало эту надпись здесь
capistrano я пользуюсь чтобы разворачивать php приложения :)
Кажется мы уже где-то общались…
Конечно, я ни одной такой темы не пропускаю :)
Смотрите, ставите…
— nginx
— postgres
— rvm

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

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


> Мне почему-то пассажир ближе, а там тоже заморочки…
Если использовать passenger, то ограничиваете себя одной версией Ruby.
Именно, доступ к серверу к серверу на исполнение нужен. Можно, наверное, обойтись обойтись копированием файлов по всей ФС, о как-тов туториалах такой путь не освещается и не освяается.
Я предпочитаю ровно наоборот. Максимум нагрузки на бэкенд. И да, через RESTful. :)
НЛО прилетело и опубликовало эту надпись здесь
PUT /hubs/123/posts/15678/comments/56689['carma' => '+1']
Вообще лучше сделать просто…
PUT /comments/56689['carma' => '+1']

Иначе Rails сделает 3 запроса вместо одного.
Путь обеспечивает выбор нужного представления для редиректа.
Обычно такие запросы посылаются асинхронно… тут это не нужно, надуманно.
Так они и посылаются асинхронно. Просто в разных ситуациях разное представление.
Не понимаю о каком вы представлении. Ответ должен быть в виде JSON с кодом выполнения (успешно или нет) и вспомогательной информацией типа нового значения кармы.
Ответ может быть в любом виде. Технология AJAX подразумевает, что ответ в XML виде. Если вы называете «аяксом» технологию возвращающую не XML, то это ваши трудности. 'X' в 'AJAX' означает именно XML, а не JSON или HTML.
AJAX уже давно не подразумевает XML. Да, изначально подразумевал. Сейчас — это общее обозначение таких вызовов, и пофиг, что там назад возвращается.
Простите, а что такого нестандартного на RoR равно экзекуции, а на Symfony/Yii/etc — нормально?
Скорее самого языка касается, а не фреймворков. Проблемы составляет реализация бизнес-логики сложнее чем CRUD. Мне (почти) очевидна её реализация на PHP или C, а на Ruby я постоянно удивляюсь, если получается нагуглить решение.
Возможно вы плохо знакомы с языком? Метапрограммирование довольно хитрая вещь.
Я этого не отрицаю. Книги по метапрограммированию читал, но счёл, что большей частью оно схоже использованию отражений в PHP, то есть годится для библиотек или фреймворков с тщательно и подробно документируемым поведением. Я избегаю «магии» в коде.
В Ruby магия сплош и рядом. И при длительном изучении все получается очень просто. Такое поведение заложено в философии…

Язык следует принципу «наименьшей неожиданности»: программа должна вести себя так, как ожидает программист. Однако в контексте Ruby это означает наименьшее удивление не при знакомстве с языком, а при его основательном изучении.
Я сомневаюсь, что любой программист на Ruby сможет понять мой код не изучая код моих переопределений операций типа сравнения. Могу гарантировать что он будет удивлён сначала неожиданным поведением, потом тем что я поменял местами операции равенства и неравенства…
Вы скорее всего гораздо лучше знаете PHP, только и всего. Github на рельсах написан, а логика там явно за рамками CRUD. Да и Ruby позволяет такое, чего я на PHP даже не представляю (это уже со своей колокольни) :-)
НЛО прилетело и опубликовало эту надпись здесь
Большая часть метапрограммирования, блоки, все, благодаря чему можно писать лаконичный и красивый код. попробуйте на php написать гем (ну ладно, PEAR модуль или что там сейчас в моде), который будет предоставлять такой синтаксис:
every 3.hours { awesome 'task', option: 'value' }
Задача «предоставлять такой синтаксис» заведомо не корректна. Сформулируйте какую функциональность этот синтаксис предоставляет и как часто она встречается в проектах, написанных с нуля.
Функциональность? Писать лаконичный и понятный код, это для многих уже достаточный аргумент. Встречается во всех хороших проектах :-) Если знакомы с рельсами, должны были увидеть что различные DSL распространены довольно широко. Да, все это можно написать и на php, но будет гораздо уродливее (даже Yii сравнить с RoR, видно что ребята старались соответствовать, но сам язык подвел).
Я так подозреваю, что гитхаб всё же основан на какой-то СУБД и/или плоском хранилище. Какие операции доступа к внешнему сервису позволяет руби и не позволяет пэхэпэ?
Обычно людям нужно решить опеределенную задачу. И они обращаются к специалистам. А специалистам задачу решать не нужно. Специалистам нужно зарабатывать как можно больше денег, тратя на это как можно меньше времени. Отсюда и CMS. Которые, как известно, пишут только на PHP. :)
Я предпочитаю решать задачу заказчика наиболее эффективным из известных мне способов. Я считаю деньги заказчика, чтоб за как можно меньшее число часов ему мне пришлось платить. Если задача интересная, то ещё и скидку делаю.
А говорите ли вы себе «СТОП», если понимаете, что возможностей CMS для решения задачи явно недостаточно?
Даже немного раньше :) Мне интересней разрабатывать под фреймворками или даже с нуля.
НЛО прилетело и опубликовало эту надпись здесь
По личному опыту CMS (вкупе с популярными модулями/плагинами/...) решают задачи процентов на 90.
НЛО прилетело и опубликовало эту надпись здесь
Управление контентом, как ни странно :)
НЛО прилетело и опубликовало эту надпись здесь
Глубже конечно. Но беглое знакомство даже с малознакомой CMS как правило показывают, что модули уже есть.
НЛО прилетело и опубликовало эту надпись здесь
Субъективно быстрее откастомить.
НЛО прилетело и опубликовало эту надпись здесь
Мои заказчики ни разу за 10+ лет моего программирования на PHP не высказывали недовольства моим кодом.
На всякий случай, чтобы вы случайно не приняли меня за злобного тролля… Я каждую неделю трачу значительное количество своего рабочего времени на сопровождение корпоративного сайта. Так получилось, что сайт сделан на CMS (Bitrix). И вот честно, че-то мне не кажется, что CMS — это именно то, что нужно людям. Bitrix помог исполнителям заказа быстро срубить хорошие деньги, да. Но тем, кто сейчас занимается поддержкой этого супа с топором — поверьте, CMS нифига не кажется воплощением наших пожеланий.
Значит вы (сайт я как понял ваш?) не смогли сформулировать свои требования. Я, как исполнитель, в случаях когда «ТЗ» заказчика допускает двоякое трактование всегда уточняю все нюансы. В частности интересует заказчика ли заказчика стоимость поддержки. Верите — нет, но мне зачастую проще и экономически выгоднее накидать костылей на CMS, я уточняю у заказчика и если его это устраивает делаю ему скидку.
НЛО прилетело и опубликовало эту надпись здесь
Встречный вопрос — вас интересует качество или скорость?
Я правильно понимаю, что вы лично только что косвенно подтвердили, что CMS — средство для быстрого создания некачественных сайтов? :)
НЛО прилетело и опубликовало эту надпись здесь
Нет. CMS средтсво создания сайтов близких к оптимому качество/себестоимость.
Нет, я лично писал ТЗ, и все важные моменты там были оговорены. Но у меня не было полного контроля над процессом принятия решения «быть, или не быть». В результате, ТЗ реализовано где-то на 60% (формально — т.е., 60% оговоренного функционала как-бы доступны, но логикой в способе доступа к ним даже не пахнет).

Сайт не мой — я всего-лишь сотрудник близкого ИТ-партнера крупной компании.
Ребят, неужели вас так легко затроллить? :)

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

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

Просто это мой субъективный взгляд со стороны на статьи об PHP. Одни хотят унизить PHP посильнее, а вторые вознести к небесам. Мне нравится язык, но объективность точки зрения в статьях часто страдает.
Действие рождает противодействие. Если не возносить к небесам, то унизят и общая картина объективна не будет. А так минус на плюс даёт ноль и общую картину можно считать объективной. :)
«средняя температура по больнице — комнатная».
Какой смысл в движке конкретно под PHP 5.4. Поясните, пожалуйста.
Движок пишется не под PHP 5.4, а с его использованием. То есть с использованием тех особенностей, которых не было в предыдущих версиях. Не совсем корректно выразился изначально.

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

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

И тому подобное.
Просто такие конструкции в определённых ситуациях сильно пригождаются, позволяют писать более компактный и быстрый код. А ещё чаще это просто удобно.
За одну возможность писать [...] вместто array(...) я был готов продать душу дьяволу, но обошлось без этого. Жду предложения по типизации выражений и…
Я чуть меньше года назад ушел с PHP, но слежу за всеми новостями из этого, копаюсь в новых фреймворкам. Иногда просят что-то подправить на PHP-сайтах.
Вы не правы. О быстром развитии — это вовсе не гипербола. Гиперболы в разговорах о PHP чаще всего только в разговорах о недостатках этого языка. Мало кто знает о его реальных возможностях. Чаще всего люди под влиянием всех этих «критиков» уходят из PHP раньше, чем успевают изучить его, а потом рассказывают о преимуществах других языков и недостатках PHP.
Изменения в PHP пока что по большому счёту были обратно-совместимыми. Разве что выпиливание отдельных элементов типа register_globals.

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

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

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

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

Да, с переходом с 4 на 5 версию были бы проблемы, но время 4 ветки ушло еще в 2005 году, сегодня наверняка прощелучше переписать приложение, будет и быстрее и более поддерживаемее.
НЛО прилетело и опубликовало эту надпись здесь
Я бы сюда ещё C# приплел, угнаться за ним многим сложно.
Главная задача на близкое будущее — чтобы поддержка 5.4 появилась в услугах виртуального хостинга, а не только при ручной настройке сервера. Многие рядовые пользователи пользуются именно такой услугой, а там только 5.3, да и то не так давно появился.
А Руби-то с Питоном на виртуальных хостингах завались, конечно.
Есть не мало решений типа heroku.com, есть дешевле.
Про Руби не знаю, но Питона, вообще-то, завались.
Шо ви говорите?
Вот я прям щас попытался найти хостинг с поддержкой Python 3.2 и не нашел ничего на первой странице выдачи + рекламе. (Если точнее, ни на одном хостинге «с поддержкой Python» я не нашел указания версии совсем.)
обычно у заказчика требующего python/ruby найдётся 10-20уе/мес на нормальный VPS…
хотя если вы намекаете, что ниша РНР — малонагруженны сайты на 1 долларовых недохостингах, тогда вопросов не имею)

ну и про «хостинг» (хостинги в том виде, в котором они есть в РНР, малопопулярны в других языка) с py3.2 — docs.webfaction.com/software/python.html
Зато хостинги в таком виде популярны у заказчиков, не имеющих в штате грамотных сисадминов. Установить приложение по ftp может чуть ли не секретарь.
А что, много проектов есть на Python 3.2?
Думаю, примерно как на PHP 5.4
С питоном немного другая история. Насколько я знаю, сообщество до сих пор саботирует переход на python 3.x, т.к. обратной совместимости нет, а пользы от него мало. Полезные нововведения дублируются в ветке 2.x. Главный фреймворк — Django — только еще анонсирует экспериментальную поддержку Python 3.3. Какой смысл держать на хостинге Python 3? Для крутых программистов, которые хотят экспериментировать? Так вирутальный хостинг им не подходит по многим другим причинам.
Я как бы в курсе :)
Ветка началась с жалобы на то, что развитие PHP задерживает отсутствие 5.4 на виртуальных хостингах.
Ну так вот, с актуальными версиями Питона и Руби (да и вообще с хостингом Питона и Руби) всё куда как печальнее. А про node.js я вообще молчу.
Всё так, но актуальная версия Python — 2.7.3.
А PHP — 5.0 ;)
Я понимаю, что вы шутите, но нас читают дети.
Для них я на всякий случай напишу это:
PHP 5 was released in July 2004.
Python 2.7.3 — 11 April 2012.
Я не понял смысла вашего ответа.
«Актуальная» версия PHP — это 5.2.17, выпущенная 6.01.2011
Именно оно и стоит на большинстве хостингов, потому что ветки 5.0-5.2 практически не отлисаются в плане обратной совместимости.
5.3 и 5.4 — совсем другая песня. Не того, конечно, масштаба, что Python 3.x или Ruby 1.9, но что-то рядом. Его пока ставят неохотно — оно и понятно.

Так что ситуация, в общем-то, очень похожая у PHP и у Python/Ruby
Да, люди часто друг друга не понимают. Есть такая проблема.
Ну вот у меня 3.1 есть (и в тарифах написано). Нужен 3.2? Не проблема — никто не спрашивал. Может на следующей неделе и сделаю. diphost.ru
Вообще странно про «ни на одном». В РФ практически три хостинга когда-либо позиционировавшие себя как хостинги с Python — netangels, мы и каким-то боком jino.
По первой же ссылке есть целый список. ХЗ почему гугль такое буквосочетание считает нерелевантным для нас. Мы вообще были первыми кто здесь mod_wsgi в традицию ввёл, весь хабр в своё время замусорили этим.
Было бы круто там еще RoR… Через passenger ( видимо 3.2 ) или Unicorn…
Эх, а то в рунете пока кроме locum толком не податься.
Неясна ситуация со стабильностью руби 1.9.3. Судя по списку рассылки freebsd что-то там провалилось с портированием. Самим кишка тонка. Также не ясно кто будет и как поддерживать пользователей. RoR — это как и Java совершенно отдельная религия. Мы сами программисты, мы можем и Python посмотреть, и php, и Си. Но RoR это идеология и там уже начинается. Вопрос — сможем ли мы обеспечить поддержку пользователей на хотя бы удовлетворительном уровне?
Ну если FreeBSD и проблемы с портами то действительно сложно.
Ну и без Rails девелопера да, может быть сложновато учитывать нюансы.

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

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

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

Ruby 1.8.6 уже сильно не актуален. Уже состоялся последний релиз Ruby 1.8.7, осталось 11 месяцев, в которые при необходимости будут выпускать security-патчи и на этом всё.
Так что если будете делать хостинг для Ruby, делайте поддержку только 1.9.3+
Кстати, а почему jino каким то боком? Полноценно вроде поддерживает да и саппорт может нужную тебе версию поставить.
Завались то завались, но в основном через cgi работает питон, а какой нибудь wsgi это большая редкость или за такие деньги, что проще vds дешевый взять. Но к минусам я это не отношу )
Просто распространенность PHP на виртуальном хостинге одно из ключевых преимуществ. Легко найти хостера, легко найти CMS, легко установить и пользоваться — для многих это существенный плюс.
И легко найти того, кто сам всё это сделает за смешные деньги. Иногда кажется, что админы-фрилансеры ценник заряжают не по трудоемкости, а по ключевым словам в ТЗ. Увидели Django — +N%, увидели RoR — +2N%, увидели Node.js — +5N%.
Как Вы же сказали выше — для установки пхп-приложения достаточно знаний секретаря. Для настройки VPS под руби/питону — недостаточно.
Для установки на шаред хостинг. На VDS субъективно трудозатраты одного порядка. По сути нужно только «прослойку» между nginx/Apache/etc и СУБД настроить.
НЛО прилетело и опубликовало эту надпись здесь
Не скажу за всю Одессу © Но среди ведущих хостингов Украины php5.4 уже поддерживается вовсю. У мелких меинстрим тем более никогда не был проблемой.
Спрашивал у своего хостера, сказал, что PHP 5.4 пока не достаточно стабильный.
Бред, имхо, но у меня всё равно VDS, так что неудобств особых не испытываю.
Ну вот на nic.ru до сих пор 5.2
Я вам могу найти и с php4, но nic.ru не в нашей юрисдикции. :)
Ну у них для каждого клиента отдельный Apache. Можно самому установить нужные модули в ручном режиме. У меня 5.4 встал без особых проблем с первого раза. Хотя да, жалко что 5.4 нельзя из панели хостинга выбрать.
Друг вообще откатился пол года назад на 5.2 на своём сервере из-за того, что одно проприетарное решение не работало на 5.3. Вот и не торопятся на хостингах. А то вроде бы и не виноваты, а клиент материт.
Не понимаю тех, для кого проблема взять под проект дешевый vds с поддержкой от хостера, если чего-то нет на шареде. Это ж какой бюджет должен быть у сайта, чтобы такое не понятнуть.
Не в бюджете дело, а в администрировании. На шареде почти все настройки ОС, nginx/Apache, MySQL, самого PHP вне зоны ответственности разработчика сайта. Максимум рекомендует тот или иной хостинг. А рекомендуя VDS заказчику сразу встаёт вопрос, а кто его будет настраивать и поддерживать. А поддержка от хостера уже не дешевое удовольствие.
Не знаю, сейчас хостеры так налегают на облака, что готовы предоставлять саппорт типовых конфигураций за весьма небольшие деньги, иногда даже бесплатно. Если в типовой конфигруации поменять версию php, сильно ситуация не поменяется.

hostpro.ua/ru/cloud — обещают помогать чуть ли не бесплатно. Ну это первое что подвернулось под руку.
Любой виртуальный хостинг поддерживает PHP, а уже бонусом может идти руби и питон.
У нас уже недели как три есть. Особо никому не нужно.
Отрадно, но как по мне, то версия становится нужной когда она есть хотя бы у половины хостеров. Снижение рисков «hoster lock-in» :)
Это понятно. Сделают. Мы всегда задавали тон. Хотя об этом никто и не знает. К осени уже все догонят.
Здесь есть существенная ложка мёда (и отдушина для Ruby с Python'ом) — VPS это уже не редкость и все более менее солидные хостинги его предлагают по цене не дороже привычного виртуального. А там уже можно настроить многое, чего не будет на виртуальном и даже более того, выше уровень обеспечения безопасности, если она имеет хоть какое-то значение (для меня это уже давно насущный вопрос) — она уже не зависит от соседей по хостингу.
Просто, быстро, удобно. Надо будет, перейду на что-нибудь другое.
Быстрая эволюция языка — как раз свидетельство серьезных проблем, заложенных изначально. И куча головной боли, для разработчиков, заодно.
Соглашусь. Хотя, с другой стороны, в случае php эта эволюция обеспечена сменой назначения языка.
С простого инструмента для создания динамических страничек,
до простого средства разработки несложных сайтов,
до средства разработки проектов средней сложности с большим порогом входа,
потом еще несколько этапов и наконец до универсального языка разработки веб-проектов любой сложности.

Естественно, для того чтобы шагнуть на новую ступень, нужно многое изменить. Радует, что дальше вряд ли будут сильно менять уже. Разве что, захотят идти в энтерпрайз, но думаю, не захотят.
Linux тоже оч шустро развивается. Что, конечно же, свидетельствует о серьезных проблемах, заложенных изначально.
А вот выше сказали что питон и руби развиваются быстрее :)
Я уже перешёл на похапэ, вот уже как 7 лет.
ну вот, убили мне карму :(((((((((((
Меня в php радует поддержка большими компаниями и появление таких замечательных утилит, как hiphop, которые позволяют получить отличную скорость и работы кода и разработки, одновременно.
cython, сто лет как.
Берем обычный код на питоне, обрабатываем этой штукой и получаем с++ код, который компилится и работает практически как нативный на с++? Я не думаю.
Ну, зря, думать полезно.
НЛО прилетело и опубликовало эту надпись здесь
Читая википедию: Cython — язык программирования, упрощающий написание модулей С/С++ кода для Python.. Я не в курсе деталей, возможно там не сильно корректно написано, но судя по этому, язык все-же не совсем такой и код таки придется переделывать.
Родной питоновский код будет компилироваться cython'ом, за некоторыми ограничениями (которые так же есть у hiphop'a), просто, если использовать специальный диалект (тот же питон + объявления типов данных, которые будут использоваться в c'шном коде (если не указывать, то практически везде будет использоваться тип PyObject)), выгода от компиляции в нативный код будет выше.
У hiphop основное ограничение — не использовать eval и другой динамический код. Остальное связано, в основном, с расширениями. Потому, многие существующие движки, типа вордпресса (с дурным количеством кода) им нормально компилируются. Точнее, движки, часто, надо немного подпилить (избавиться от динамического кода), но объем работ там сравнительно небольшой.

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

Я описывал ниже пример, взял обычный сайт, где код выполняется достаточно ровно и узких мест, как таковых, нет. Просто перекомпилировал через hiphop + g++ и получил скорость отклика в 30 раз быстрее. Не думаю, что у меня получится, если я перепишу узкие места на Си. Ну разве что весь сайт в виже extension делать, но, думаю, даже в этом случае, на инициализацию уйдет много времени.
Лично у меня все претензии не к PHP, а к пехепешникам. Качество кода, количество мозга и так далее…
особенно это видно по govnokod.ru
Не думаю, что качество моего кода или, тем более, количество мозга у меня сильно меняется в зависимости от того на каком языке пишу, будь то PHP, Ruby, Python, Erlang или JS (языки на которых писал что-то посложнее helloworld за последние года 3). Более того, есть подозрение, что код на PHP у меня более качественный. Чисто потому что в куда большем количестве чужого кода разбирался.
Однако, мысль вы не поняли :-)
Что я не понял? У вас претензии к качеству моего кода и количеству моего мозга. :) Я считаю, что эти вещи от языка на котором я пишу никак не зависят.
ИМХО, в каждом языке есть и гуру, но есть и быдлокодеры, просто порог вхождения последних разный. PHP простой и даёт множество функций из коробки (сравните, например, с С++), поэтому многие новички, которые даже не знают, что есть так называемое качество кода, начинают именно с него. Глупо предъявлять претензии ко всем пхпшникам, есть множество грамотных, сам общаюсь с ними лично.
Есть такой момент. Но:

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

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

Рельсы или же джанго загоняют пограммиста в относительно жёсткие рамки: простора для говнокода остаётся гораздо меньше. А без фреймворка, на чистом питоне или руби сайты писать как-то не принято.
Не то что не принято, а очень трудозатратно, если не CGI писать — написать страничку с «hello world» означает сначала написать сервер, обрабатывающий запросы — сокеты и т. п. А PHP в стандартном конфиге сочетает удобство простоту CGI для разработки и куда большую скорость.
Что такое «стандартный кофиг»? mod_php? php-fpm?

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

Для Ruby чтобы работать в веб-окружении есть Rack подключается одной строкой, второй строкой подключается любимый сервер thin, третьей берите в руки Erb-шашку и RUBYте всех от плеча! Проблемы нет.
Поэтому я и против бездумной популяризации Питона и Руби. В мире есть PHP. В него сливается большинство начинающих кодеров. А если человеку важна эстетическая составляющая, красота кода, качество библиотек — он задумается и найдет себе подходящее решение. Если нет, то останется с PHP и не будет портить жизнь другим.
Ещё важна инфраструктура, спрос и т. п.
PHP используется как основной язык на 77,9% среди всех сайтов
windows используется на ещё большем проценте комп«ютеров, так что теперь, на basic-е программировать?

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

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

Ну и главное замечание к статье — чем же так PHP гораздо лучше, чем мы думаем, автор так и не обьяснил…
Тогда уж на C#, а не на basic. C# клёвый. Рекомендую.
Тем, что у многих о нём устаревшее представление, о PHP5.4 думают как о PHP3, да ещё считают, что пишут на нём только в «спагетти»-стиле. У вас лично может быть объективное и вы прекрасно знаете достоинства и недостатки как самого языка, так и экосистемы. Но многие этим похвастаться не могут, «не читал, н осуждаю» или «не знал, да забыл».
Что ж, не могу не согласиться, что 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 — это как максимум начальный этап карьеры программиста, и чем быстрее его проскочить, тем лучше. Есть куча других языков и технологий, заслуживающих внимания.
Скорость для php не проблема с тех пор, как появился странслятор в с++ код, который после компиляции работает на сравнимом с нативным кодом, уровне. Работает при этом эффективно и надежно (давно не слышал о каких-либо проблем с безопасностью на ФБ и ВК).
> Скорость для php не проблема с тех пор, как появился странслятор в с++ код

ага. от Facebook'а. Заточенный на Facebook. Неспособный скомпилировать >>90% кода на РНР.
У меня проекты завелись достаточно легко на нем. Пока, правда, служебные, но с ними проблем небыло. Чуть подправить код пришлось, но почти тридцатикратное ускорение того стоит, как по мне. проблемы с основном с расширениями, но, учитывая скорость работы, большую часть из них можно заменить на php классы с аналогичной функциональностью.
НЛО прилетело и опубликовало эту надпись здесь
К-во запросов в секунду. Полагаю, процессор (я в тонкосятх настройки по памяти не разбирался, там встроенный веб-сервер и как там настроить количество воркеров или что-то еще, я пока не в курсе).
НЛО прилетело и опубликовало эту надпись здесь
Да, был код на php, работал через php-fpm+apc и nginx, я его через hiphop собрал в виде демона и ab показал 3200 запросов против 110 (тот-же сервер, загрузка процессора в обоих случаях 100%). База не использовалась, но работала шаблонизация (шаблоны скомпилены в php код), ну и стандартный контроллер, фильтрация данных и прочее. Код реальный, брал работающий самописный проект.
НЛО прилетело и опубликовало эту надпись здесь
Действительно, если нет аргументов, лучше обсудить личность
НЛО прилетело и опубликовало эту надпись здесь
С реализацией да, у 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), но не смог решить организационные вопросы (проще говоря косячил) по причинами с ЯП не связанным — брался за новую работы не подчистив концы.
> чисто по опыту — не любят разработчики PHP общих решений.

Они вообще боятся трогать парсер и лексер. Видно в многочисленных обсуждениях разных фич, затрагивающих эти два компонента.
Что-то подобное подозревал. Судя по отсутствию формального описания синтаксиса, внутри творится чёрти что.
Сейчас не найду сслыку на обсуждение namespace'ов, но там был ад. Один из ключевых аргументов против :: был именно «лексер (или парсер) не сможет разобраться»
Они вообще хотят поменять лексер на более современный, ибо тот что сейчас не способен справится с новыми веяниями, у него нету контекста — отсюда и проблемы с тем, что некоторые вещи очень проблемно реализовать.
Если мне память не изменяет, то хотят на lemon parser пересесть и какая-то работа за кулисами там шла, но инфы почти нету.
В итоге получится, как с Юникодом :) «Много рутинной работы, никому неинтересно, все забили» :)
Чтоб менять на более современный нужно, как минимум, формализовать язык. Наверное. Но у ж точно PHP бы это не помешало бы, если не просто формализовать существующий синтаксис, но и упростить его.
НЛО прилетело и опубликовало эту надпись здесь
Не игнорируешь а ждешь массового распространения на шаредах версии поддерживающей нововведения. Нэймспэйсы и анонимные функции я сейчас использую активно. Через год-два наверное нчну использовать фишки 5.4.
НЛО прилетело и опубликовало эту надпись здесь
Грубо говоря не знаю когда появился php, но когда мне поставили задачу создать сайт я выбирал из трех языков: C, PHP и Perl/ У PHP было только одно значимое для работодателя преимущество — прототип (как сейчас модно говорить) на нём я создал за день, На сишный мне трое суток понадилось, от перла после суток разбирательства я отказался в принципе.
НЛО прилетело и опубликовало эту надпись здесь
99% не динамические? Вы уверены?
Конечно. Жду статические гугл с яндексом и прочие дропбоксы с фейсбуками.
Статический гугл? Скачиваешь список сайтов и там уже ищешь через Ctrl+F?
А вместо браузера вывод на принтер.
Вы только что решили проблему несовместимости html кода в разных браузерах.
А проблема кросс-принтерности не появится?
Думаю появиться :). Каждый ведь захочет сделать свой принтер особенным.
Принтер с поддержкой ECMAScript — это будет АД
НЛО прилетело и опубликовало эту надпись здесь
особая серая склизкая бумага ^__^
Бумаги не хватит дебажить.
НЛО прилетело и опубликовало эту надпись здесь
Кончаются раньше чем рассчитываешь даже без принтеров…
Я думаю имелось ввиду, что сайты вполне могут обойтись без динамики… ну про 99% конечно утрированно, но нереально огромное кол-во сайтов можно было бы сделать статикой + минимум JS скриптов…
Ну. Сейчас обыкновенные заказчики (сайты визитки, сайты портфолио) все хотят либо галерею, либо новости или еще что-то подобное. Крайне неудобно делать такое статикой.
И что в таком случае делать сайтам, которые начинают развиваться?
В случае с CMS — просто ставится/включается соответствующий компонент, в случае со сгенерированным сайтом — создавать сайт с нуля?
При этом учтите, в современных CMS хорошо развито кеширование, которое приближает сайты на этих CMS по производительности к сайту на статике.
Но лично по поводу широкораспространённых бесплатных CMS спорить не готов — большинство из них мне сильно не нравятся (теоретически можно было бы сделать лучше).
Они тащат груз BC, по-моему. Поставь их разработчикам задачу написать такой же по функциональности движок и уверен качество кода будет куда выше. Вот только будет ли кто пользоваться этим движком с оригиналом общее имеющее только название, если заказчики сайтов уже вложили немалые деньги в создание модулей, тем и прочую кастомизацию. Скорее просто кто-нибудь форкнет текущую версию, как это было с, например OpenOffice.org, пускай и причины были другие.
Ставим модуль, генерируем статику по новой, в чем проблема?
Какую статику, если речь идёт про новые функции?
Считаем что статика — это одна функция: контент.
Форум на статике или рейтинг постов в блоге — уже не прокатит.
А ведь это достаточно распространённые функции в современном вебе и список таких функций можно набросать приличный.
Кроме того, мои заказчики хотят сами управлять контентом — генератор тоже нужно куда-то поставить и настроить. Так CMS же и выполняет эту функцию — это онлайн редактор сайта, с этим самым сайтом и связанный.

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

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

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

Конечно, в обычном случае, так делать нет смысла. Но если сделать, то вполне можно давать ссылку на такой блог с Хабра или откуда-то еще и блог легко вытянет хабраэффект даже на не сильно мощном хостинге. Как правило, проблемы с производительностью у блогов возникают именно в таком случае.
Я думаю, что различные профили пользователей и личные кабинеты есть на большем числе сайтов чем 1% — куда не ткнись всюду требуют регистрации, чтоб даже ознакомиться с контентом. В принципе не очень сложно должно быть сделать блоговый движок на статике, но к нему всё равно нужен динамический бэкенд («админка»), да и СУБД больше как-то подходит для задач типа «найти все посты с таким-то тэгом», чем рыться в HTML файлах. В итоге приходим к системе, которая, по сути, по POST запросам генерирует сначала модель в БД, а потом её представление в файле — в динамических системах это называется файловое кэширование представлений.
Сравнивать языки нужно только в зависимости от контекста их употребления. Для одних задач один язык больше подходит, для других другой. Сказать однозначно и без поворотно, что один язык лучше другого в любом контексте его употребления, по крайней мере глупо. У каждого языка есть изъяны, но в разных случаях эти изъяны либо влияют на корректность работы приложения и на его перформанс либо нет, но так же у каждого есть свои преимущества в той или иной задаче. И как правило на практике в сложных веб-приложения используются несколько разных языков — каждый для своей задачи. И это есть правильно.
Лучше спорить, что в такой-то данной задаче, в таких-то условиях такой-то язык лучше. А то получается, что камаз лучше, чем порш кайен, а как на порше привезти 5 тонн кирпичей никого не волнует.
«php» == TRUE
«php» == 0
0 != TRUE

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

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

А неочевидное поведение — это куча трудноотлаживаемых ошибок, говнокод и головная боль разработчиков.
Неочевидно оно для людей привыкших к строгим языкам. А вот если взглянуть на конструкции типа
$var = $_GET['var'];
if ($var) echo 'TRUE'; 
echo $var * 2;

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

В питоне или в руби сравнение строки с число всегда вернет false. Ну просто потому что число и строка — разные классы объектов. И это гораздо более логично.
А не пустая ссылка всегда истинна. Пустая — ложна.
Приводите типы, сравнивайте строго. Кто мешает?
Никто ;) Я не пишу на ПХП, там слишком маленькие зарплаты ;)
Я бы не стал писать на ПХП даже если бы платили нормально :)
А если бы платили только за пхп?
Если бы платили только за пхп — я бы ушел в аналитики. Ну или тестировщики.
тестировать код на PHP?
Все равно. Вы бы пошли писать на КОБОЛе, если бы «только за него платили»? :) Есть пара технологий, с которым я имел несчастье иметь дело, и которыми я больше не притронусь не при каких обстоятельствах. Например MFC. От PHP у меня, правда, нету такой травмы, но язык мне очень сильно не нравится и плохо себе представляю, что может заставить меня с ним иметь дело…
Хорошим специалистам хорошо платят.
Всегда ли? А если операцию сравнения переопределить?

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

Не надо переопределять операцию сравнения, кроме случаев когда вы пишете какой-то очень хитрый eDSL.
Просто не люблю квантор всеобщности :)
И слегка неожиданно:
defined('null'); // true
defined('NULL'); // true
define('null', true); // notice нельзя переопределить константу
define('NULL', true); // true
NULL===true // false
('NULL')===true // false
('NULL')==true // true
Тут как раз все логично.
а вы хотите так:
define('true', false);
define('false', true);
// счастливой отладки

?
Loose comparisons with ==
Strict comparisons with ===
От вашего коммента складывается впечатление что вы ниасилили перевод этих 2 строк в вашей ссылке.
См. мой коммент выше.
И осильте любой другой язык с динамической типизацией кроме php и javascript.

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

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

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

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

Ок, я не буду выставлять это недостатком языка. Я просто скажу, что большинство других языков имеет явное достоинство по сравнению с пхп.
Это просто разные типизация. Транслятор с сильной обзовётся, со слабой выберет наиболее вероятное (по мнению разработчиков) кастование. Хотите сравнить число со строкой — в любом случае правила приведения типов нужно знать.
Слабая типизация — это когда типизация идет по совпадению контрактов (оно же «утиная» — если квакает как утка… и так далее). Сильная — по совпадению типов и их отношениям в иерархии.

И у строки и у числа отчетливо РАЗНЫЕ иерархии и РАЗНЫЕ контракты.
В языках со слабой типизацией обычно используется подход под названием «утиная типизация»
утиная типизация — это «выглядит, как утка, плавает, как утка, крякает, как утка — значит утка». Строки и числа в PHP — это не утиная типизация, а слабая динамическая типизация.
Утиная типизация один из видов слабой типизации.
Но только она не относится к этому случаю.

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

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

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

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

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

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

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

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

А вы в чем меряют выше, чтобы говорить о «сделали PHP на порядок эффективнее»?
Хорошо, перечислите свои инструменты, которые вы используете для решения задач.
На данный момент — .net (c#, f#) под виндой; ruby, lisp, ANSI C — в линуксе.
> Это не костыли, это осознанно подобранные под конкретную область применения допущения.

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

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

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

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

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

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

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

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

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

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

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

Сказки про «гибкость и удобство» оставьте школоте и кодерам, которые уверены, что код типа «$var = «1»; echo $var + 1;» — это хороший качественный безопасный код.
НЛО прилетело и опубликовало эту надпись здесь
У меня остался только один вопрос, почему вы продолжаете дискутировать о PHP, вместо того, чтобы писать скажем на Java?
Я могу понять смысл споров, как сделать PHP лучше, но ваши высказывания говорят о том, что вы не согласны с базовыми концепциями языка.
Возможность написать:
$str = '1';
return ++$str;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[*] Да, *_ptr — это костыли, чтобы скрыть многие из встроенных в язык проблем, несмотря на их — во многом — хорошую или даже отличную реализацию.
Возможность написать свой личный smart pointer не означает, что указатели это проблема Си, а наличие === не говорит о том, что == больше не нужен. Вы что-то слишком часто стали называть меня школотой, которую надо уволить, я приму это как признание, что аргументов у вас больше нет и дискуссия окончена.
Ну да, ну да. Вместо аргументов посчитать, что тебя называют школотой — это явный признак высочайшего профессионализма, да
Ах, и да.

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

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

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

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

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

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

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

Ну почему же, представьте теперь ситуацию что нужно получить какое-то значение (допустим из 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);
    }
}

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

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

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

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

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

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

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

лучше тогда уже intval($var) + 1;
(int) не функция, а значит, гораздо быстрее.
комментарий был не про скорость в целом, а про аналогию с другими языками, по типу int(var) в Python.
0 != TRUE в таких языках, как C, C++, Python и JavaScript.
НЛО прилетело и опубликовало эту надпись здесь
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.

НЛО прилетело и опубликовало эту надпись здесь
Что в вашем понимании значит платформа? Чем node.js (я правильно угадал? :) ) отличатся от js? Я всегда думал, что это надстройка над языком — библиотеки и биндинги.
НЛО прилетело и опубликовало эту надпись здесь
Вот только не надо на PHP демонов писать.
Не предназначен он для этого — там все заточено под другую задачу.
Написал нам тут один аутсорсер демона на пхп — за 1 день утекает 4ГБ памяти!!!
А у нас куча демонов на php, и ничего нигде не течет. Хотя, я знаю много способов сделать так, чтобы потекло=)

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

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

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


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

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

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