Ads
Comments 532
Статья огромная. Слэнговая. Я считаю оно в любом случае того стоило :)
Однозначно стоило. Хотя бы для того, чтобы разместить на Хабре. Автору мегареспект.
Перевод неплохо. Просто, видимо, у автора не так много переводческого опыта и он спешил.
Переводческого опыта определённо нет. И да, признаюсь, спешил, боялся перегореть и забить.
При переводе очень больших статей (особенно со сленгом) привыкаешь к середине и странные языковые конструкции становятся привычными. Так что скорее просто недостаток опыта.
Я конечно ждал, что эта нетленка будет переведена на Хабрахабре… Но не в таком виде.

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

Кидайте мне в почту (sergey.sega.vasilenko → gmail.com) вариант с маркапом. Сегодня-завтра причешу.
Хотел написать много всего, но решил ограничиться следующим:

1. Надеюсь, автору оригинала и переводчику значительно лучше спится после такой полезной и оригинальной статьи.

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

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

И такого пол текста.

3. Всегда думал, что если что-то не нравится, то не бери и не пользуйся. Ощущение, будто автора пытали программированием на PHP несколько лет и в сыром подвале. Потом его спасла полиция и вся эта статья — исповедь перед журналистами. Для чего потрачено столько времени?
Вы знаете. Не промтом. Вручную. Над процитированным предложением долго бился, а вот с родом и правда промахнулся. Ща поправим.
Не обижайтесь, но по-моему, здесь тот случай, когда проще «сделать заново», нежели исправить.
Забейте на всех этих умников — они просто завидуют, что Вы смогли сделать такой здоровенный кусок работы, а они нет. Я прочитал с удовольствием, спасибо за перевод.
Да бросьте вы.
Сделать много работы и сделать много работы хорошо — разные вещи. Не понимаю, чего все так переводчика защищают. Или вам плевать, что вам предлагают к прочтению? Как можно «с удовольствием читать» несогласованные предложения, где смысл не всегда понятен?
Нам не плевать. Вот мы вместо того, чтобы судачить об этом скидываем в личку переводчику багованые места. И по-тиху статья становится лучше.
Мне не наплевать на то, что я читаю. Если взялся переводить, то делай это хорошо. Лично я не вижу никаких подов исправлять чужой перевод. По-моему, в наше время, можно любой текст перевести без проблем, при этом владея только тем языком, на который осуществляется перевод.

В общем ладно, продолжайте хвалить другу друга и заниматься обоюдным вытиранием соплей. В нашей стране так принято — человека стоит хвалить за одно только желание что-то делать. Качество результата второстепенно. Толерантность и кармодрочество хабра возводят все это в степень.
У нас тут вообще-то сообщество. Если нашел ошибку или неточность — сообщи автору в лс. Никто никому ничего не обязан. Ишь ты, не нравится ему перевод.
Да, простите. Я забыл, что быть нем-то недовольным запрещено. Нужно всем широко улыбаться и говорить спасибо даже за то, что в принципе внимания не достойно.
Есть такой принцип в мире opensource: «Открывать рот может только тот, кто что-то сделал». Если бы у Вас в профиле висел десяток грамотных переводов и значок «Переводчика» — Ваши замечания были бы приняты и имели бы смысл. Заявления «Надо делать хорошо! Я вот ничего не сделал, но если бы сделал — это было бы сделано ужасно круто» — Вы сами слышите как звучат.
Перевод статьи из разряда «Язык программирования @name@ — говно» — это opensource? Выходить, всем известное слово из трех букв, написанное на заборе — тоже opensource и не дай Бог кому-нибудь возмутиться на этот счет…

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

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

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

По сути статьи меня бесит еще вот что: пхп позаимсвовал у перла много библиотек (с теми же именами), поэтому когда гуглишь что-то перловое… натыкаешься на кучу к делу не относящегося.
О, блин, точно :) Бывает забудешь слово и клещами его не достать.
Поддержу про перевод. Прежде чем переводить с английского, неплохо бы выучить русский. Глядишь и проблем с переводами меньше будет.
> 3
Вот мне тоже интересно, как он собрал такую огромную подборку. Это надо быть или коллекционером, или мазохистом.

Пока работаешь на php половины из этого не замечаешь, ко второй привыкаешь и это не так беспокоит. Проблемы видно со стороны. После Питона, например.
Я хотел автору оригинала нечто подобное написать (это я про пункт 3) и даже пытался адаптировать наше «мыши плкали, кололись, но продолжали жрать кактус» для инглиш-спикеров, но вспомнил картинку «в интернете кто-то не прав» и решил, что оно того не стоит — у каждого свои заморочки.
Пусть ruby, java, python, erlang программисты тужатся, обсирая PHP, мне как-то пофиг — для меня PHP — инструмент, так же, как Python и Java.
Для чего потрачено столько времени?
Быть может, для того, чтобы его не тратили другие, выбирая себе инструмент для работы?
Много честно, но много и гипертрофированно. Аналогия с кривыми инструментами не верна, там скорее о кривых руках и незнакомых инструментах надо было писать.
Как php-developer подписываюсь под бОльшей частью претензий, но менять язык не собираюсь, знакомые болячки на уровне разработки как рутина обрабатываются, а новых болячек новых языков никакой устоявшийся проект не утерпит
Я думаю что эта статья больше для новичков, чтобы лишний раз задумывались перед выбором инструментов.
Любители php обиделись и вымещают злость на переводчике. Чем выкобениваться, лучше помогите ему, указав на слабые места перевода и предложив свой вариант. Почему-то, ни у кого из прокомментировавших «ужасный перевод», я не обнаружил в профиле десятка отлично переведенный статей. А с виду казались такими умными, начитанными ребятами.

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

Что касается автора данного «труда» — очевидно что он просто теоретик.
Да, он много знает, но все это теория. Все эти доводы актуальны только когда речь идет о «программировании ради программирования». Но автор забывает что программирование — это работа, которая делается для того чтобы (о, боже!) получать деньги. А когда мы начинаем говорить о деньгах на первый план выходят совсем другие вопросы:
— скорость развертывания;
— количество специалистов на рынке;
— стоимость обучения;
— размер сообщества;
— количество аутсорсных компаний;
и т.д.

Да какая мне, черт побери, разница что python имеет более правильный синтаксис массивов, если python-разработчика я буду искать полгода, а php — две недели?
Потому что каждый раз когда вам надо что-то поменять — вы снова будете искать 2 недели еще одного разработчика на PHP, еще неделю он будет переписывать все, т.к. ему просто не понятно что там накалякал предыдущий…

Главные свойства любой системы, которая должна проработать дольше недели — стабильность, поддерживаемость, повторяемость\предсказуемость результата. Если вы пишете код который выбрасываете через неделю — я вам сочувствую, имхо вы проживаете свою жизнь зря, тратя ее на такой бессмысленный труд.
Жизнь слишком коротка чтобы заниматься говенной работой.
Вдогонку — это не касается конкретного языка — я не пишу на PHP или Python (хотя последний порывался попробовать\изучить), это именно фундаментальные принципы, которые должны соблюдаться продуктом для надежности его функционирования.
Прочитав статью до половины и сломав мозг на некоторых вещах, типа левоассоциативного ?: (ну почему Horse-то ?8-\?), я понял что обрисованная картина довольно печальная. Хорошо что я ушел из PHP очень рано.
Кстати про horse тоже не понял, хотя php не знаю, но логика-то должна быть хоть какая-то :)
( $arg == 'B' ) ? 'bus' :
             ( $arg == 'A' ) ? 'airplane' :
             ( $arg == 'T' ) ? 'train' :
             ( $arg == 'C' ) ? 'car' :
             ( $arg == 'H' ) ? 'horse' :
             'feet' )

Раз вернулся horse, значит
( $arg == 'B' ) ? 'bus' :
             ( $arg == 'A' ) ? 'airplane' :
             ( $arg == 'T' ) ? 'train' :
             ( $arg == 'C' ) ? 'car' :
             ( $arg == 'H' )

вернул 'car'. bool('car') -> True А 'car' он вернул потому что
( $arg == 'B' ) ? 'bus' :
             ( $arg == 'A' ) ? 'airplane' :
             ( $arg == 'T' ) ? 'train' :
             ( $arg == 'C' )

вeрнул 'train'. А 'train' он вернул потому что
( $arg == 'B' ) ? 'bus' :
             ( $arg == 'A' ) ? 'airplane' :
             ( $arg == 'T' )

вернул true. Потому что $arg == 'T" и
( $arg == 'B' ) ? 'bus' :
             ( $arg == 'A' )

вернул false, потому что $arg != 'B' и $arg != 'A"
Ужас, а не код. Пионеры прочитают и будут так делать, ох.

$arg = 'A';
$items = array('A' => 'airplane', 'B' => 'bus' ...);
if (in_array($arg, array_keys($items) ))
{
echo $items[$arg];
}
приведённый выше пример решает, конечно, не совсем ту задачу, скорее это пример упрощения.

С кучей вариантов if-elseif-else/switch-case всегда лучше для последующего использования, чем инлайн-условие, использованное не по делу.
«инлайн условие» лучше тем, что не заставляет повторять n раз одно и то же.
в php нет функции с параметром который возвратится если ключа нет массиве?
В python это было бы так:

{'B':'bus', 'A' : 'airplane', 'T': 'train', 'C':'car', 'H': 'horse'}.get(args, 'feet')
Вот за что я люблю перл, что там все определенно (ну если знать как работают умолчания, конечно)

exists $items{$arg} && defined $items{$arg} ? $item{$args} :  'default'
Всё это великолепие можно (да и НУЖНО) написать как:

$item{$arg} // 'default'
Нет, так писать нельзя, проверка $items{$arg} = '0'

Я же не указал в условиях задачи, что является валидным вводом ;)
Хотя для большинства случаев вы правы — но я хотел продемонстрироать именно проверку разных состояний exists и defined
Полный аналог этой строки в PHP, видимо:

array_key_exists($arg, $items) && isset($items[$arg])? $item[$args]: 'default';
ну значит не всё так страшно. единственное, что действительно имена функций не очевидные согласованые, хотя код вполне читаем
Кстати, вы ошибку скопипастили. В перл она нестрашная, ибо сразу вылезет exception при use strict (а тех, кто не пишет первой строчкой use strict, на работу не берут, ибо диагноз)
PHP тоже выдаст два предупреждения (Notice) в этом случае (в логи или прямо на странице, смотря как настроено). Исключение не выбросит, но в случае PHP его и не должно быть, я считаю.
Имелась ввиду ошибка компиляции. Имхо — это более правильно, чем предупреждение в логах — кто их читает пока не припрёт? ;)
я пишу use strict четвертой строчкой. пора увольняться? :)

#!/usr/bin/perl

use warnings;
use strict;
каждый раз когда вам надо что-то поменять — вы снова будете искать 2 недели еще одного разработчика


Если вы пишете код который выбрасываете через неделю


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

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

Но при этом вы упускаете из виду фундаментальные свойства, от которых зависит качество работы и сопровождения системы. Вы же не будете развертывать ее каждый день по новой, заказывать аутсорсинг или обращаться к коммунити. Один раз развернутая система должна работать. А создавать систему на «слабопредсказуемом» языке ( дао horse из текста я еще пока не постиг) — довольно опрометчиво.

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

Я знаю (видел) что и на ПХП тоже можно писать качественные и сложные системы, но как правильно замечено в статье — талантливый программист перепишет любое решение хоть на brainfuck'е. Но зачем? Зачем делать что-то правильно когда сам язык мешает это делать, когда его поведение нелогичное, когда оно непредсказуемо и зависит от 2-3-5 параметров исходной системы, настроек компиляции или локали установленной при развертывании.
Создавать продукты для такого окружения — тратить время своей жизни на борьбу с ветрянными мельницами — можно, но бесполезно. Хотя это ваше время и вам выбирать на что вы его потратите.
Ну я понял. PHP это зло по определению и любые его плюсы — всего лишь заблуждение.
Миллионы людей пользуются им лишь потому что он прост, а питон невероятно сложен, ок.
Ну какие у него плюсы как у языка программирования?

P.S. PHP просто только для непосвящённого человека, чтобы примеры для новичков выглядели симпатично, на самом деле надо писать МНОГО неудобного и некрасивого кода и единственный выход для какой-никакой гибкости — это уход в жёсткое ООП, что для новичков не особо-то радостная новость.
Я все написал в первом комментарии этой ветки.
Проблема в том, что спорят со мной программисты — то есть те люди, который видят лишь одну сторону медали — написание кода. Думать о том что этот код нужно будет потом продать — не их работа.
На самом деле в веб программировании клиенты не очень часто выставляют предпочтения на чём для них писать и как писать. Их больше интересует скорость, дешевизна и чтобы продвижение было дешёвое. Потому предлагать им можно что угодно, самое главное оправдывать данные обещания.
Да и можно переубедить при желании.
А большинство пишут на PHP не из-за каких-то сложных мыслей и забот, а потому что не знают что есть что-то иное и более лучшее.
Пару-тройку лет назад ещё большим доводом в пользу php была огромная проблема с хостингами для ruby/python.
А вот сейчас, если не считать хостеров с сервисом 'всё за пять копеек', то этой неприятности уже нет.
Ну как сказать, я пару месяцев назад так и не нашел хостинга с актуальной версией руби и рельс. Пришлось брать VPS. И неделю его мучать в попытках поставить весь набор.
Неделю? Что же вы делали неделю, интересно? Когда мне понадобился хостинг для работы django, я просто купил первый попавшийся VPS и настроил все за два часа.
Приложения на рельсах, джанге, куче других языков (Java, Scala, Clojure, Erlang, Node.js, PHP, etc) можно очень быстро задеплоить на Heroku.
Ну, тем более — если это ускорит процесс еще больше (сам не пробовал пока, но спасибо за наводку), то о какой неделе настройки говорить вообще? :))
Фактически деплой приложения на Heroku сводится к

$ heroku create --stack cedar
$ git push heroku master


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

И кстати, на хероку можно запускать не только веб-приложения. Это могут быть и всякие background worker'ы, и боты.

Масшабировать приложения тоже не тяжело:

$ heroku scale web=10 worker=20 # будет 10 веб dyno и 20 воркеров


Ну и легкая установка аддонов:

$ heroku addons:add sendgrid:starter # smtp
$ heroku addons:add mongolab:starter # mongodb


По своим возможностям, IMO, Хероку является очень гибким и простым решением.
В том то и дело, что предлагать «все что угодно» можно далеко не всегда.

Для сравнения два варианта для предложения клиенту:

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

2. Мы сделаем все на Django, но вам потребуется VDS и сисадмин который все это развернет и настроит. Если хостинг разонравится — вам нужно будет повторить операцию на новом VDS. Для доработок вам нужен будет специалист по Django, которого трудно найти и он дорого стоит.

Какой вариант выберет клиент?

Я согласен что PHP имеет кучу проблем. Не спорю с этим, это очевидно.
Но продавать решения на нем — легче. Потому что он популярен.
Так что надо быть объективнее и не делать крайних утверждений.
Давно уже это неверно, как минимум с выхода PHP 5.3, ибо на многих хостингах стоит PHP 5.2 и так запросто всё не заработает (если замыкания используются и.т.п.). Да и клиенты сами с хостинга на хостинг на моей памяти не переезжали, всегда за отдельную плату, либо на основании каких-то договорённостей просили наших специалистов перенести им сайт.

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

Далее, обычно продавая сайт продают ещё и целый пакет услуг в которые входит и поддержка и доработка творения, потому выбор языка важен только если веб-студия разругалась с клиентом и/или не доделала всё в полной мере, такое бывает не часто и таким веб-студиям выбор ЯП не поможет =)

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

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

P.S. опять же клиенту можно и про говнокодеров на PHP рассказать каждый последующий из которых за его деньги будет переписывать ему один и тот же код =)
P.P.S. сам сейчас поддерживаю достаточно посещаемый проект, после последнего говнокодера сайт просто перестал работать. Сейчас на том же железе производительность подняли в 6 раз и, думаю, ещё столько же выдержим. Так вот, эти сторонние фрилансеры-разработчики ни о какой безопасности вообще не задумывались, сайт был дырявый как дуршлаг. Про индексы для БД они тоже не слышали и о том что профилировать запросы можно тоже не знали. Кеширование — тоже какое то непонятное слово, при том что платили им от 1500/час. Вот тебе и PHP фрилансеры нанятые человеком не разбирающимся в вопросе.
Ну клиент будет сравнивать именно 2 предложения. И первое выглядит заманчивее. А что бы второе стало интереснее вам пришлось написать 6 абзацев текста.
Предложения выставлены однобоко и не особо-то и приближены к истинному положению вещей, о чём я и написал. Для того чтобы доносить такое и большее количество информации до клиентов есть менеджеры и они с этим, надеюсь, справятся.
Все ваши плюсы не относятся к языку программирования, а к сложившейся на рынке ситуации. И, как мне кажется, автор оригинальной статьи исходит гневом именно по той причине, что наибольшее инфраструктурное преимущество имеет язык с одним из худших дизайнов. Это… огорчает.
Однако авторы подобных статей — не конструктивны. На тему того, что PHP плох — вылито уже прилично помоев. Но ещё никто не придумал, как внедрить в инфраструктуру веб лучший язык. А без этого все подобные статьи — неуместный троллинг и пережёвывание одного и того же. Впрочем, именно эта статья наверно должна была быть написана, переведена и прочитана каждым — титанический труд собрать всё это вместе и систематизировать. Надеюсь это поможет как-то изменить ситуацию со временем — то ли в сторону развития PHP как языка, то ли в сторону популяризации Ruby или Python'а.
Авторы подобных статей конструктивны в том смысле, что до сих пор встречаю фанбоев PHP, пытающихся рассказать о его достоинствах именно как языка. Можно не тратить время на призывы к здравому смыслу, а просто давать линк на статью.
Удобно.

А насчёт придумки — пфф, тут и думать нечего. Просто используйте другой язык. Вот так просто. Впрочем, в российских реалиях можно ещё попытаться нарисовать законодательный запрет на PHP с уголовной ответственностью :)
Вот так просто

И что в этом простого? Если я для своего проекта выберу другой язык — популяризации этого языка это поспособствует мало, а вот я огребу все недостатки низкой популярности этого языка — отвратная документация, отсутствие вменяемого сообщества, отсутствие соответствующего предложения на рынке труда. Хорошо, если проект — крупный и расчёт изначально идёт на то, что труд высококлассного программиста на порядки дешевле затрат на железо, всё окупится. Крупные проекты, собственно, так и поступают. Но если проект небольшой, специалисты на него нужны недорогие, то простотой здесь не пахнет ну никак. Небольших проектов значительно больше, чем крупных. Энтузиастов, готовых облагораживать за свой счёт индустрию — не много.
По моему скромному мнению, PHP вообще развивается быстрее, чем альтернативные языки откусывают долю от рынка.
> По моему скромному мнению, PHP вообще развивается быстрее, чем альтернативные языки откусывают долю от рынка.

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

Банальный пример:
трудозатраты на реализацию решения с использованием языка «Х» — это сумма «5хS». Для доработки или для повторения решения (сделать и развернуть еще 1-2-100 копий) необходимы затраты «K».

Трудозатраты на реализацию решения с использованием языка Y — это сумма S, сумму вы смогли уменьшить за счет массовой конкуренции на рынке программистов на Y. Но с большой вероятностью вы получили некачественное или сложноподдерживаемое решение. Если вас это устраивает — все ОК, одноразовые вещи должны делаться как можно дешевле.
Если вам необходимо сопровождать\повторять это решение для каждого заказчика — стоимость сопровождения будет не K, а например 3хК. Очевидно что деньги сэкономленные в S против 5xS, вы потратите при доработках.

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

Да, вместо X и Y могут быть любые другие языки, не обязательно упомянутые ;).

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

PS: и я до сих пор не понял почему мне нужно будет искать нового разработчика каждый раз, как я захочу что-либо поменять в PHP-коде.
Меня в институте бесил Access. Почти вся группа, из которой, если говорить честно, задатки программистов были у двух трех человек, на Access сделала вполне приемлемые приложения. Я же, «звездочка», с трудом сделал троечную работу, за которую мне поставили 4ку практически за старые заслуги.

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

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

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

Если уж брать что-то что ты непонимаешь, как работает (к чему зачастую приходят вполне логичные и понятные проекты, начинающиеся с легкого фреймворка вне зависимости от языка), то лучше брать то у чего болшеекомьюнити… И менее заносчивое комьюнити, кстати.
UFO landed and left these words here
Вот это и удивительно — как майрософт ухитрился сделать среду разработки, интуитивно понятную новичкам и «убивающую» спецов, привыкших «копать глубже».

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

А где я тут в долбаном захолустье найду вакансию javascript или ruby или чего там еще ТруЪ?
Ну да, ну да. Звучит правильно и красиво. Ну а как иначе можно выразиться на таком уважаемом ресурсе. Только вот мне надо пару лет переучиваться, менять подходы, искоренять php из головы, сказать на это время семье и детям — счас мы будем пару лет жить хуже, потому что в интернете дядя мне сказал что на пхп работать низя, и чтобы постичь дзен нужно кодить на питоне…

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

Пару лет? Это же не обучение программированию с нуля. Шаблоны проектирования и прочие MVC они и на питоне работают. База Данных и там и там.
Раз вы хороший специалист, то вы, вероятно, выделяете время для обучения, и, скорей всего, вы программируете не только на PHP. А значит можете изучать тот же питон параллельно работе.
Ну вот смотрите. я представляю что такое mod_php, fcgid, fastcgi, fpm и примерно как их нужно варить и сколько солить; каковы особенности работы с тяжелыми данными на php, как разруливать и делать достаточно нетривиальные конфигурации. Знаю как расширять некоторые cms, их косяки, вижу сразу «индусский код», знаю что мне ждать от xcache а что от других опкешеров, как защитить те или иные вещи и овер 9000 остального. На любой вопрос я почти сразу знаю ответ как это сделать правильно, безопасно, быстро.

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

Для того, чтобы делать что-то интересное например на питоне, мне нужно знать его историю, знать его косяки, знать на нем как минимум пару различных *MS, архитектуру ядра хотябы в первом приближении, около 50 разных библиотек…

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

Так что развлекайтесь с вашими питонами как душе угодно, но работы на PHP больше раз в 100500. И реалии таковы, что если сразу не начал с этого лет 5 назад, то свободно все бросить можно только при наличии тыла, свободного времени, и уверенности что это еще кому то нужно…
Вы это всё к чему вообще? Вы спросили — где найти вакансию. Вам ответили — работать с зарубежными заказчиками. Какое отношение к этому имеют рыдания по поводу «переучиваться»?
У нас один программист работал. «У нас» == крупный богатый интегратор. В котором, сотрудников не считали. Посему там можно было не работать (при некоторой пофигистичности и фрондерстве). Ибо з/п одного специалиста ни на что не влияла, а количество спецов влияло — на престиж отдела. Т.е. никого увольнять за профнепригодность там даже и не пытались, просто игнорировали.

А вот этого товарища уволить собирались. Ибо косячил… Везде. eval «action_$USER_INPUT» — это просто мелочи, рабочие моменты.

Но не успели уволить, сам исчез. Объявился в Канаде, либом с приличной зарплатой. Оттуда продолжал по аське задавать дурацкие вопросы, в основном по ПХП. Гуглящиеся на раз-два.

Так что и с ПХП можно уехать и устроиться… Главное чтобы руки язык из нужного места рос.
Вы можете стать профессионалом и в PHP, более того — зная все тонкости, описанные в статье, вы будете очень, очень ценным кадром, т.к. вы сможете своим «участием» в проекте на PHP придать языку качества, которыми он «не обладает в стандартной поставке».
Но только надо тогда уж становиться профессионалом, а не убеждать себя в стиле «буду работать как все и на массовом рынке» (возможно вы таким и становитесь, я не знаю).

Есть просто одна проблема работы на массовом рынке — люди стареют и качественно делать одну и ту же работу — невозможно. молодые обойдут на поворотах, срежут углы за счет 3 бессонных ночей, подрежут на хаках, которые вы себе не позволяете. Поэтому надо сдвигаться всегда в сторону «штучности».
В «массе» очень трудно жить, ну если только вы не пасете всю эту массу =)
«Работа, чтобы получать деньги»… нет, не слышал. Я-то всегда думал, что это занятие, к которому лежишь всей душой, от которого получаешь удовольствие, ну и, как побочный эффект, за это ещё и хорошо платят. Какой смысл разрабатывать на чем-то, что не нравится концептуально, идеологически или просто неудобно, не радует эстетически, в конце концов? К чему эдакий мазохизм? Но если «работа» от слова «раб», то ок ;-)

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

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

Стоимость обучения… специалистов обучать не надо вообщем-то, они и сами отлично обучаются. Это только «специалистов» надо доучивать или переучивать. На эту тему — предыдущий абзац. Остальные случаи «обучения» тоже эквивалентны вполне, хотя бы, исходя из «затраты/польза».

С сообществом всё тоже самое, что и со «специалистами», — можно иметь орду «индусов», из которых лишь процент — идеологические спецы, или же сообщество поменьше, но где каждый самоценен.

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

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

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

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

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

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

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

На питоне можно написать ничуть не медленнее. Можете посмотреть на примеры экстремального программирования, когда делали сервис на Django за 2 суток. На выходе читаемый код, быстро вносить изменения и тд. Берите толковых студентов (питон изучить — ничего сложного), платите нормальную для студента зарплату и делайте качественные продукты. Так нет ведь, столько менеджеров думает что «говнокод» и «говнодизайн» — это такие прихоти программистов.
В итоге мы пришли к тому, с чего все началось.
А именно — к мысли «каждый инструмент хорош для своих задач».
Моя претензия к автору изначально не в том что он ругает PHP, а в том что он умалчивает о возможности его эффективного применения там, где это уместно.
О том, чем PHP хорош и так кричат на каждом углу.

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

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

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

Тем продажникам, которых потом сожрут разъярённые клиенты из-за потери данных?
xkcd.com/327/
да.
В моей практике был клиент, который раньше нанимал индусов.
Ну что же, всего 2$/hour, вся деревня к вашим услугам.

Всё было ок, да.

Перестал, когда слили базу клиентов, из-за кода что-то вроде
«select * from users where login=$_GET['login']»…
Причем это всё было приколочено к вебмагазину на кейке, вопреки всем заветам MVC, вообще игнорируя все концепции.
Всегда при упоминании трудов программиста идёт речь об аутсорсинге. Я разрабатываю софт для внутреннего использования в компании, и тут выгода полного ООП, канонов программировани и прочих академических штук очивидна. Иногда давят на «надо быстрее запустить», ошибки в процессе попрявятся.
А когда мы начинаем говорить о деньгах на первый план выходят совсем другие вопросы:
— скорость развертывания;
— количество специалистов на рынке;
— стоимость обучения;
— размер сообщества;
— количество аутсорсных компаний;


Серьезный бизнес! И что это мы тут какие-то тупые .Net и Java изучаем. Весь топовый бизнес давно на пхп!
— скорость развертывания;
Со всеми имеющимися жопами с безопасностью, капризами интерпретатора и т.д? Лол.
— количество специалистов на рынке;
Нормальный PHP разработчик (подчеркнуто) зверь редкий, стоит от 100к
— стоимость обучения;
= время обучения. Опять же нормальный, разработчик — это много лет разбирательства в муторной экосреде и мелких костылях и нюансах.
— размер сообщества;
А качество информации не? Хотя за 10 лет оно действительно не могло не разрастись.
>Нормальный PHP разработчик (подчеркнуто) зверь редкий, стоит от 100к

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

Сейчас клепатель модулей под битрикс может иметь весьма достойную зарплату, так как всю эту заваренную кашу надо как-то поддерживать.
Согласен. Имел опыт найма Django и JS разработчиков, и видел со стороны как ищут качественного РНР.
Меньше всего сейчас качественных JS.
Качественных РНР и Django — примерно на рынке одинаково тяжело найти.
Вот если нужен уровень хуже — тут у РНР плюс несомненный.
С JS, несмотря на популярность, кучу документации, либ и полную монополию на клиенте есть одна проблема — он очень сложный. Конечно не в плане лексики, а требовательности к разработчику, функционалка схожая с лиспом, куча асинхронных сопель, динамическая типизация, стремный скоп, среда браузера на клиенте, глючная нода на сервере и т.д. Ну и он просто не предназначался для того, для чего его используют сейчас. (Впрочем, как и PHP, который проложил свой путь из области шаблонизаторов)

Так что перспективы по количеству специалистов мне кажутся умеренными.
Не забывайте еще тот момент, что JS как самостоятельный язык (в том ключе что для него стали нанимать отдельно программистов) выделился совсем недавно, ибо раньше он шел довеском к серверсайду. Отсюда идет следствие что большинство JS гуру так-же отлично знают Ruby/Python/PHP. А это еще + окладу.
Я бы не сказал, что скиллы в резюме нужно просто суммировать в оклад. Да иельзя знать серверсайд совсем не зная клиентской стороны и наоборот.

Если нужен программист, работающий под RoR то его навыки работы с Plone могут быть огромными, но бесполезными — куча локальных скиллов, которые при смене платформы меняют актуальность. Платить JS кодеру за то, что он идеально знает 1С, да нафига, когда поискав можно найти того же, кто его не знает и не захочет этот бонус, который бессмысленен для работодателя.

Имхо, основной плюс к окладу — это насколько сотрудник способен создавать работающие штуки. На js их создавать и тестировать достаточно сложно.
А я и не говорю что если человек может получать 80 за серверсайд, и 70 за JS то в сумме он будет иметь 150. Это показывает общий уровень, не более.

Вы же в свою очередь утрируете приводя пример разработчика на RoR со знанием Plone, которые по сути в одной компании редко используются, а еще реже и в одном проекте. Или вообще абстрактный пример с 1С и JS.
Да, я перегнул немного, пытаясь сделать акцент сильнее, хотя зоопарки всякие попадались.

1C и JS вполне могут ужиться, если ищут кодера-эникейщика на поддержку всякого из низшей касты. Чем выше каста (тупо зарплатная), тем важнее, чтобы специалист ровно решал задачи в рамках весьма определенной области. Писать прекрасные клиенты вообще не вникая что там на заднике это совершенно нормальное явление. Есть описание интерфейса I/O + Т.З. и зашибись.
Платить JS кодеру за то, что он идеально знает 1С

Интеграция сервера на NodeJS с 1С? :)
Непонятно каким боком тезис о сложности языка подтверждается аргументом «схожая с лиспом». Проще лиспа сложно что-то придумать.
сложно ли придумать что-то проще программы на лиспе? например программу на hackel?
я, видимо, сегодня невероятно тупой, но я всё еще не понимаю вопроса. прости.
Там была правильная мысль, что многие талантливые разработчики тикают с php в сторону того же python'а. Да и за две недели хорошего разработчика не найти, а если получится — то не благодаря php, а вопреки.
Лично я ушёл от php после написанного на нём крупного проекта. Вспоминаю как страшный сон, и более не хочу.
Затянувшаяся миграция с 2-й ветки на 3-ю, юникод, локи интерпретатора, экспрешены, динамическая типизация… Уфф, все равно лучше пока не нашел.
Затянувшаяся миграция с 1.8 на 1.9, GIL…

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

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

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

То есть хороший язык, но не мой =)

И на руби под виндой тоже писать не стоит, насколько мне известно (сам я никогда даже не пробовал).
Я слишком ленив. чтобы настраивать виртуалку там, где можно обойтись без оной. Но пока на грабли особо не натыкался.
Хабр дебил. По Enter отправляет пост в черновики. И убивает все комментарии. Уж извините.
Переводчику спасибо за труд. Одного не могу понять, зачем переводить очередной батхерд на тему PHP. Все эти вопросы разбирались уже не раз. Те кто давно и профессионально работает с PHP знает про особенности и подводные камни, кому не по нраву перешли на другой язык. Мне сложно представить человека — фаната профи PHP, который писал бы каверзные статьи на темы других языков. Так что это за попытка? Поднять бурление на изъезженную тему или очередная контрпропаганда? Зачем …?
Что ж? Выражу своё мнение. Просто уж очень часто натыкаюсь на древний софт(который нужно поддерживать или переписать), написаный на PHP и испытываю точно такой же батхёрт. Ужасно устал от самопальных фрэймворков на нём же.
Делов то, смените работу и будете натыкаться на оверинжинирнг в джаве или ещё какую-нибудь беду в другом ЯП.
Речь в статье идёт о серьёзных архитектурных проблемах языка, в других ЯП не так всё запущено. Опять же это влияет и на рост языка и на качество кода.
Ну и что это значит то? В чем смысл этого опуса? Всем надо резко перейти на другие языки? Новички не должны учить php или что?
Ну давайте, переходите, отдайте мне на поддержку всех своих старых клиентов с проектами на php и забудьте про баттхёрт. Ну это так, ради смеха.

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

Что касается новичков — так это порог вхождения и опять же спрос на пхпбыдлокодеров.
Я считаю что новички должны знать что есть ещё языки на которых удобно и приятно программировать, ибо большинство людей тупо учит PHP потому что это «модно» и везде пишут что сайты надо разрабатывать только на PHP, а потом не понимают что же они так несчастливы от рутинного написания говнокода. Язык в этом случае тоже имеет значение.
Я согласен, но для этого лучше писать статьи типа «Питон за шесть часов» или «RoR for dummies» и уж никак не «ПХП ЕСТ ДЕТЕЙ».

Сами подумайте, ну прочитает новичок эту простыню по диагонали и что? Да ничего, он все так же пойдет и скачает какой-нибудь вордпресс или друпал и начнет потихоньку делать свой первый говносайт. Среда не располагает к изучению других языков, хоть пять статей напиши.
Начинайте с чего угодно. Речь о среде и о том, что вероятней всего новичок в первую очередь наткнется на PHP со всеми вытекающими, такова правда жизни. В таком контексте статья выглядит абсолютно бестолково.
Потому что вордпресс или друпал можно просто залить на шаред-хостинг за пару баксов, да и на вдске не проблема поднять, не говоря о денвере? И можно «хелловорд» во «все интернеты» выложить без проблем?
Да, а здесь настроить хостинг очень сложно!
И вообще ДЕНВЕР поставить гораздо легче чем какой-то тупой wamp.
Лол, по питону обычно рекомендуют не «питон за шесть часов», а «Dive in the python» и PEP-ы.
А за 6 часов лучше действительно PHP изучить для галочки и забыть.
По-моему как раз наоборот, везде пишут, что НЕ надо разрабатывать на PHP, что Python/Ruby/NodeJS это модно и круто, но дешёвый хостинг и огромное количество готового кода берёт своё.
Я считаю этот текст достаточно ценным хотя-бы в качестве назидания людям, которые сейчас выбирают язык программирования.
Мне кажется, это просто страдание человека, не безразличного к вопросу дизайна языков о том, что ЭТО смогло стать лидером рынка.
Я гналась за вами три километра, чтобы сказать, как вы мне безразличны! © не знаю откуда
Принцесса
Три дня я гналась за вами. Только в бурю потеряла ваш след, встретила охотника и пошла к нему в ученики.

Медведь
Вы три дня гнались за мной?

Принцесса
Да! Чтобы сказать, как вы мне безразличны.

Шварц, «Обыкновенное чудо»
«Обыкновенное чудо».

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

Наверняка, можно написать такую же статью про русский язык.
  • множество заимствований из других языков (бордюр, компьютер ...);
  • множество исключений (оловянный, деревянный и т.п.);
  • множество слов, в которых нельзя проверить согласные ударением;
  • существуют слова, которые нельзя поставить в определённую форму(победю, пылесосу ...);
  • … ;

вам на заметку — в основном сейчас работаю с Java.
Я просто к тому, что пример неудачный — если с победю действительно проблема, то с пылесосением проблемы такой не стоит.
Это всего-навсего была шутка в контексте первого комментария, о языках разговорных, не принимайте близко к сердцу!
Понимаете ли, естественные языки развиваются эволюционно. И только по этой причине имеют столько исключений. В то время как искусственный язык проектируется. Хотя мне иногда, что в случае PHP это не совсем верно :)
Я думаю, что тут можно с уверенностью сказать, что PHP изначально не проектировался вообще.
Ну тогда у нас нет тысяч лет для эволюционного развития чего-то качественного нового из PHP, что может позволить себе природа.
Да уж, после программирования на Python, PHP выглядит как набор костылей из глобальных переменных, операторов вместо функций и ООП заимствований отовсюду.
«Пипл хавает» (с).
UFO landed and left these words here
Не стоит рассматривать естественные языки как нечто совершенное.
Почитайте хотя бы юридические тексты — имхо, неплохая аналогия «программированию» на естественном языке.
Я этого и не утверждаю, даже наоборот эволюционное развитие очень медленно и склонно к падению в локальный минимум.
И ещё, многие любят русский язык за его исключительность…: )
Это можно написать про любой естественный язык. Во всех есть странности, несогласованности и различные недостатки…
Да уж, это вам не эсперанто, но почему-то мало желающих его изучать, парадокс человеческой психики.
Кто может объяснить заголовок статьи? Хотел перевести эту статью просто так, для себя. Но сдался на заголовке. Дословно переводить не хотелось.
Фрактал — самоподобная фигура, то есть PHP — плох по дизайну весь так же, как плоха по дизайну каждая его составляющая?
В статье же написано, почему. Ну, или лень читать, слово «фрактал» поищите по тексту.
Я читал статью в оригинале(вроде даже дважды) и прекрасно понимаю смысл статьи, и намёк в заголовке. Мне интересно как литературно перевести заголовок.
фрактал — бесконечно (теоретически) самоповторяющаяся фигура => php бесконечно самоповторяющийся на глюках язык
примерно такая аналогия получается…
Нет, он имел в виду, что чем глубже закапываешься, тем больше ошибок вылазит
да, кстати, как я проморгал, аббревиатура PHP же содержит в себе смаоповторение, видимо этот момент был обыгран
тут больше имеется ввиду такого рода фракталы:

image

Намек на то, что весь дизайн языка — одна сплошная дырка.
Берем статью, делаем выдержки, и… задаем вопросы на собеседовании ;)
даже на таких граблях
"foo" == TRUE, и "foo" == 0… но, конечно же TRUE != 0.
сколько раз падали. Вопросы мот по круче патернов программирования будут, и многая специфика языка открывается.
Да, что называется смотреть и не видеть. Я сразу же подумал, что «foo» = TRUE = 1.
Я не пойду работать в контору, где на собеседовании дают такие вопросы.
А старые сишные привычки не позволяют попадать в 90% ситуаций с невнятным поведением.
По этой же причине я без понятия что даст, например []+{} в javascript.
UFO landed and left these words here
Ага, на этот ролик я и ссылался. Он забавный, но за годы я не помню, чтобы нарывался на похожие ситуации.
Правильно: зачем знать, что будет при сравнении строки с числом, если никогда не станешь сравнивать строку с числом?
Не так давно, я всерьез собрался менять php в сторону python'a. Остановило меня знакомство с php-фреймворками и конкретно с Yii. Я получил огромный набор инструментов из коробки, которые большую часть описанных в статье недостатков исправляют.

Статья слишком далека от реальности.
В реальных проектах с этими проблемами не сталкиваешься.

>Поэтому следующий код:
>
>$arg = 'T';
>$vehicle = ( ( $arg == 'B' )? 'bus':
> ( $arg == 'A' )? 'airplane':
> ( $arg == 'T' )? 'train':
> ( $arg == 'C' )? 'car':
> ( $arg == 'H' )? 'horse':
> 'feet' );
>echo $vehicle;
>выведет horse.
Вот за такой код в реальном проекте нужно руки отрывать. В реальном проекте будет использован switch-case.
Ну двойная вложенность-то может быть? И проблема имеет место быть. А пример выполнен как гипербола, но смысл проблемы он не искажает.
Видите ли, должный уровень профессионализма накладывает свой отпечаток на видение языка. Вы наступили на грабли 5 лет назад, и сегодня вам кажется, что их нет. Но грабли никуда не делись. Более того, их в принципе не должно было быть.

В качестве доказательства ошибочности вашего мнения «статья слишком далека от реальности», предлагаю вам заглянуть на любой популярный сервис вопросо и ответов (например, ВиО Google), и посмотреть, о чем там спрашивают, и какой код публикуют. Чего стоят только конструкции вида:

$query = "SELECT * FROM users WHERE login='$login';"

Которые приводятся в 99.9% вопросов про PHP в связке с MySQL.

Это реальность. И это косяки языка программирования (ну и говноучебников по его изучению).
т.е. использование старого нерекомендуемого модуля (mysql) или неверное использование новых инструментов (mysqli, pdo etc) новичками — это вина языка?
Этот «старый нерекомендованный модуль» — этакое спецсредство для стрельбы по ногам. Вина языка уже в том, что он в нем вообще появился. И еще большая вина в том, что все еще существует и поддерживается.
Хорошо так говорить, когда другие языки могут учиться на чужих ошибках. Данный модуль создавался давно и расчитан был на старый функционал и защиту скриптов самим программистом.
В данном случае модулем до сих пор пользуются огромное количество программистов, либо новичков, либо тех, кто ведет старые проекты. PHP не может взять и выкинуть модуль. Разработчики плавно отучают пользователей от него (первый этап — только обновления безопасности и обновление документации, дальше — больше).
Поэтому 1) вина в появлении — может быть, но такое есть во всех языках — программист может выстрелить в ногу тысячами способов.
2) PHP не поддерживает больше данный модуль, только обновления безопасности
Поэтому в целом я все равно считаю, что подобные вопросы от новичков — не вина языка.
Хорошо так говорить, когда другие языки могут учиться на чужих ошибках.
Я ни с кем ни о чём не спорю, однако отмечу, что Пайтон появился в 1991, Руби и PHP в 1995.
>>Хорошо так говорить, когда другие языки могут учиться на чужих ошибках.
… а некоторые — не могут
Так предположим, что какие-то языки появились недавно и учились у PHP (C#, Io, Scala, Clojure, ага).
Но ведь в контексте предыдущей дискусии, я предпологаю, сравнивается PHP с его ближайшими «соперниками», а не какими-то абстрактными новыми языками.
Если быть точным, истоки Python Гвидо создал на новогодних каникулах '89 :)
Ну это спорный вопрос, если человек даже не задумывается над безопасностью своего кода… Такое можно написать на любом языке, вот вам на руби:

@user = User.find_by_username("#{params[:username]}")

Я не знаю Ruby. Хотите сказать, что если в usename будет содержаться «1'; TRUNCATE TABLE users;» — это приведет к очистке таблицы?
Да, правильней написать можно например так:

User.where("username = ?", params[:username])

Тогда переменная не летит напрямую в БД, как в первом варианте. Говнокод — всегда говнокод.
Согласен. Только некоторые языки больше располагают к его написанию, а некоторые меньше.

Думаю, вы согласитесь со мной, что в творениях новичков Ruby говнокода будет существенно меньше, чем в коде новичков PHP. А почему? Потому что первый меньше располагает к стрельбе по ногам.
Не могу судить про новичков в руби, сам такой) Но по личному впечатлению, само комьюнити как-то подталкивает искать верные и красивые решения, покрывать код тестами.
в творениях на Руби говнокода ещё побольше будет. Но не потому, что язык плохой, а потому, что есть 100500 способов сделать одно и то же действие. И новичку нужно время, чтобы попробовать их все и придти к своему стилю.
Когда мне демонстрировали «гибкость» Ruby, я офигел от некоторых показанных конструкций и тоже была мысль, что это вроде как преимущество языка можно легко превратить в недостаток.

Всё никак не соберусь погрузиться в Ruby основательно. Python после PHP вызвал у меня культурный шок, интересно, как оно будет с Ruby. :)
Собирайтесь, и не верьте про «говнокода еще побольше будет». Такого как во внутренностях джумлы вы там не встретите никогда :)
Joomla в качестве аргумента против PHP — это уже перебор. Слишком жестоко и несправедливо. )
Исключительно для расширения кругозора. После знакомства с Python/Django, если бы мне пришлось вернуться к PHP, я бы достаточно интенсивно юзал подсмотренные в Django вещи. Думаю, в RoR тоже можно «подсмотреть» много вкусного. Как-то так…
Частично соглашусь, увлёкшись метапрограммированием можно страшного наворотить :)
А вот обилие вариантов делания одного и того же на самом деле огромнейший плюс, позволяющий писать DSL'и и в конкретных ситуациях получать очень компактный выразительный код.
Взять тот же RSpec или что-то подобное Person.where { (name =~ 'Ernie%') & (salary < 50000) | (salary > 100000) }
Языки? Посадите новичка писать «сайт» на чистом руби без фреймворков — он вам и не такого напишет. Ну или давайте сравнивать честно и поставить на сторону PHP какой-нибудь приличный фреймворк.
Не напишет, потому что это не так тривиально, как в PHP. :) Практически любой другой язык, кроме PHP, очень быстро отбивает охоту к велосипедописанию. Даже(!) если задаться вопросом написания велосипеда на том же Ruby или Python — обстоятельства будут подталкивать к переизобретению какого-то подобия MVC.
Первый вариант тоже правильный и не приводит к SQL injection.

Приводит вот это:

User.where(«username = '#{params[:username]}'»)
Да, только что проверил. Но суть не в том как конкретно работают методы find_by_* или where AR'a, а в том что плохой код можно написать на любом ЯПе, что и было замечено.
Конечно, с этим полностью согласен.

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

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

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

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

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

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

Originally used for tracking visits to his online resume, he named the suite of scripts «Personal Home Page Tools,» more frequently referenced as «PHP Tools.»


Если несколько утрировать: есть замечательный язык ЛОГО, но это не значит, что на нем нужно писать интерфейсы к БД.
Ну лично я бы для этой конкретной задачи сделал бы обработчик на голом Rack, имхо тут и Синатра и не нужна.

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

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

Основное отличие в настройке сервера и деплое. Для PHP вы можете поставить апач из пакета, mod_php (если ничего еще не поменялось) и кинуть файл в нужную директорию.

В руби — поднять аппсервер, настроить проксирование, мониторить этот аппсервер.

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

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

Но даже если эти проблемы будут решены, я сомневаюсь, что в этой нише (маленьких задач на 1-2 страницы) Ruby будет более простым решением чем PHP. Равным — вполне возможно.
Во многих дистрибутивах модуль passenger для апача есть в репах. Какая разница, что указывать после aptitude install — mod_php или passenger? С nginx ситуация сложнее, но там для php вообще придётся какой-нибудь php-fpm ставить.
С шаред хостингами всё верно. Но если заказчик не может раскошелиться на VPS или хотя бы heroku, я бы поостерёгся с ним работать.
Хотя если речь не о заказе проекта для ведения бизнеса, а для personal home page — возможно, абстрактному разработчику будет проще. Я бы всё равно выбрал синатру, просто в целях унификации основных проектов с личными.
Кто-то явно не в теме

pry(main)> User.find_by_nickname(«test'\»")
User Load (0.2ms) SELECT `users`.* FROM `users` WHERE `users`.`nickname` = 'test\'\"' LIMIT 1
Отрицаете SQL injections в AR?

[22] pry(#<#<Class:0x9c59118>>)> User.where("username = 'user2' OR '1'='1'").first
=> #<User id: 17, username: "admin", email: nil, crypted_password: "$2a$10$mAeQyVoi8.8FlKiTWPH0yOJvSVZlqrKQKBgAVcUFaC2c...", salt: "dGYtwAFYA2f2q9ipXGXE", created_at: "2012-04-07 12:49:51", updated_at: "2012-04-07 12:49:51", remember_me_token: nil, remember_me_token_expires_at: nil, role: "admin">
[23] pry(#<#<Class:0x9c59118>>)> 

Ну так и писали бы сразу нормальный рабочий пример вместо кода, где инъекции нет.
В местах, намеренно предназначенных для вставки голого sql, конечно же ничего само не будет экранироваться.
А в дефолтных ситуациях с User.where(:username => params[:username]) или с выражениями на синтаксисе metawhere/squeel отстрелить себе ногу не выйдет.
Да, конкретно с find_by_* я протупил что-то, спасибо за поправку.
А что тут непонятного? В нем тоже есть неочевидное поведение в некоторых моментах.
Про любой язык так сказать можно. Есть неочевидное уникальное поведение.
У него куда более лаконичный синтаксис, код читать куда приятнее, да и работает он в пару раз быстрее.
UFO landed and left these words here
давайте на этом и закончим! :) о терминах можно спорить ещё дольше и жарче чем о PHP
В JS нет таких ярких проблем с архитектурой.
Неочевидное поведение документировано. А все удивления «как это оно так работает» и «почему у меня везде последнее значение несмотря на цикл» от малого опыта работы с ФП.
В JS ярчайшие проблемы с архитектурой.
Имеющие, кстати, теже самые корни, что и у PHP — делали изначально одно, а потом периодически поверх накручивали совершенно другое.
Да ладно… взять ту же область видимости переменных ограничиваемой функциями — я потерял много часов жизни пока с этим не разобрался. Бредовая идея вообще.
Неоднозначность strict синтаксиса, то есть он вроде бы есть, но им мало кто знает как пользоватся.
ООП непривычное, причём до такой степени что многие эмулируют привычное ООП создавая тормоза и путанницу.
Постоянные заботы об преждевременной оптимизации, что портит нас как программистов. Ибо в firefox — unshift невероятно медленный, а в других браузерах всё ок, вот и тратишь время на всякую чепуху…
Однопоточный интерпретатор, что не является таким уж и большим благом.
да можно ещё продолжать, просто время тратить неохота… не в тему распыляться…
UFO landed and left these words here
Тут пост посвящён PHP, предлагаю не отходить от темы.

Если вам интересно подискуссировать можно это продолжить в личной почте.
UFO landed and left these words here
UFO landed and left these words here
Я это понял и разобрался, просто спросили про типичные проблемы языка, я их частично озвучил. И с этой проблемой сталкивались все кого я знаю, причём не все они разобрались и пишут ужаснейший говнокод на JS и по сей день.
UFO landed and left these words here
Почему же, я тут вижу логическое несоответствие.
Что есть по сути функция?
Это именованный блок кода.
Так почему же именованный блок кода создают «область действия переменной», а обычные блоки кода нет?
Про это часть перевода автора топика, кстати, посвящена, хе-хе…
UFO landed and left these words here
Несмотря на это в джаваскрипт есть переменные которые являются достоянием парадигмы императивного программирования и работают они не так как везде и внятного оправдание именно такого способа их работы я не вижу.

В том же эрланге отлично обходятся без переменных вообще (точнее там есть альясы, но изменять их значение нельзя), вот это ПРЕДСКАЗУЕМОЕ поведение функционального ЯП. А в джаваскрипте непойми что.
В том же Perl область видимости переменных ограничивается блоками и никакого дискомфорта от функционального подхода при программировании на Perl лично я не испытал.

P.S. Ещё раз выделю мысль: «вы так и не объяснили, почему так как сделали в JS — правильно и логично».
В cpp и ещё сотне языков блоки создают отдельный контекст, в питоне и ещё сотне не создают. какая разница, причём тут логично?
Логично что и именованный блок и анонимный по сути одно и тоже, потому разумно ожидать что и с переменными они работают одинаково.

P.S. кстати, а как в питоне дела обстоят с этим?
но функция не просто именованный блок (к тому же она может и неименованной быть :) ).
функция объект, её можно куда-нибудь передавать, вызывать и т.д. простой блок нельзя. и контекст, соответственно, создаётся в момент вызова функции.
Про объект согласен, это уже похоже на разумное объяснение такого поведения, но опять же могли бы сделать блоки кода анонимными функциями (и тоже объектами), тогда бы эта неоднозначность работала бы как в си подобных языках, разве нет?
На каждый каждый блок плодить объекты, скоп и всё такое, а язык и так не быстрый. Ну и создавался изначально для простых вещей. Большинство «программистов» до сих пор не знают ни про «var» ни про то, что функция объект.
В ES5 по-моему можно будет в блоках объявлять переменные.
Функция не просто именованный блок:

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

Из-за этого такие заморочки:
stackoverflow.com/questions/370357/python-variable-scope-question

но этот язык изначально был расчитан на нубов, ещё больше чем PHP. Там даже точки с запятыми сделали необязательными, чтобы прогеры-верстальщики не перенапряглись.
Область видимости переменной — вся функция, а не блок? Такая идея в функциональных языках?
С автором полностью согласен, хотя сам PHP-девелопер.
Однако у PHP есть неоспоримый плюс: поддержка. И проблемы выше элементарно исправились бы, если бы не потеря BC.
После исправления появился бы язык типа Python/Ruby, т.е. все стало бы лучше, но в итоге потеряли бы своих пользователей. А в это время сообщество форкнуло бы старый херовый PHP до изменений, и на него бы почти все и перешли.
Ежики плакали, кололись...? Зачем форкать «старый херовый PHP»?
Нет, ну швейцарский нож классный инструмент, но молоток лучше гвозди забивает, а пила лучше дерево пилит. Я к тому, что как инструмент создания динамических веб сайтов, PHP вместе со всеми своими косяками на ура работает, и все эти ваши интернеты тому доказательство.
Работает, кто же спорит. Но хотелось бы, чтобы самый мейнстримовый язык веб разработки был бы получше…
Перечитайте внимательно, я же написал это.
Скажем так: поддержка и совместимость важнее, чем качество языка, о чем говорит его высокая популярность относительно Python/Ruby.
Ого, у кого-то серьезный баттхёрт. Ну и ладно, пойду дальше писать свои дэйтинги…
PHP плох тут, тут и тут. Не поверите, но разработчики PHP все это знают.
А решение проблемы где?
1) Перейти на другой язык? — Кто может себе это позволить — того не держут, кому важны плюсы PHP пока останутся на нем (сообщество/поддержка/«много из коробки»/фреймворки/рынок труда/...)
2) Исправить все сразу в PHP — моментальная потеря всех вышеперечисленных пунктов из-за полной потери обратной совместимости.
3) Постепенное пусть и медленное исправление недостатоков проектирования языка с разумными сроками «на обновление модулей и проектов»для сообщества и программистов.
Я выбираю третий вариант, а другие пусть разводят холивары.
1) Сообщества и поддержка есть и в других языках, «много из коробки» невозможно использовать и в статье довольно точно написано почему.
Фреймворки у PHP по удобству не особо-то могут соревноваться (возьмите в других языках Sinatra подобные фреймворки, например, я когда людям показываю чуть в обморок не падают от того как рам роутинг сделан) из-за своей монстроидальности из-за проблем языка. Единственное чего много у PHP — это готовые CMS, и они смотряться достойнее чем у конкурентов, но лично мне CMSки готовые не очень удобны, очень много ограничений и получается код за который часто бывает очень стыдно. Рынок труда — тут спорный вопрос ибо хорошие вакансии есть почти для любых ЯП.
2) Согласен и это-то и придаёт оттенок безнадёжности к развитию PHP.
3) А вот тут всё очень сложно, ибо та куча непонятно чего что есть у PHP так и будет тянуться за ним. И в обозримое десятилетие не думаю что PHP как-то качественно сможет измениться из-за этого. Тем более PHP стал эволюционировать в сторону Java (который в моём понимании для метапрограммирования и расширения синтаксиса не особо подходит (поправьте меня, если я не прав)) что загоняет его в тупик.
>> Фреймворки у PHP по удобству не особо-то могут соревноваться.
Приведите примеры, пожалуйста? Пока выглядит очень голословно и субъективно.
ну я привёл пример — покажите мне достойный PHP фреймворк с синатра-подобным роутингом, ну или вообще «удобным роутингом»
Я первый попросил )
Допустим, роутинг ZF мне кажется не менее удобным, чем роутинг синатры (честно прочитал главу про него в туториале).
То есть вы хотите сказать что

$router = $ctrl->getRouter(); // returns a rewrite router by default
$router->addRoute(
'user',
new Zend_Controller_Router_Route('user/:username',
array('controller' => 'user',
'action' => 'info'))
);

так же удобно как и

get '/user/:username' do

end

?

P.S. И что самое забавное, если другие языки к подобному синтаксису смогли подстроится Perl, например (), то в PHP это в принципе в ближайшие годы не будет в лучшем случае парсинг тектовых конфигов, где он также многословен и неудобен + жёсткое джаваподобное ООП, но для этого уже есть java, которая ещё и быстрее к тому же.
java быстрее php?

Имеете ввиду исполнение уже скомпилированного байткода? Так для пхп тоже есть тот же eaccelerator.
Для упоротых есть еще и hip-hop. Но жаба быстрее php раз эдак в 10 несмотря на все ускорялки, ну кроме костылей типа hip-hop.
Благо в таком виде его и не принято использовать (если маршрут не один).
У меня, например, это yaml-файл примерно такого вида:
news:
type: *rroute
route: /news/:section
defaults:
controller: news
action: index
section: index
*там были ямловские отступы, но съелись в процессе отправки
ну вот я про то и говорю — парсинг текстовых файлов + адское ООП и это программирование вашей мечты?

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

Так вот кроме роутинга внутри приходится писать кучу кода, который в других языках либо как-то автоматизируется (намного меньшим количеством кода опять же), либо его просто меньше.
А уж всякие неработающие new Object->method() с ничего не значащими ошибками это вообще за гранью добра и зла…
$app->get('/hello/{name}', function($name) use($app) { 
    return 'Hello '.$app->escape($name); 


Вы типа того имеете в виду?
Вот про это я тоже говорил, вся эта куча лишних скобочек, слов function и use… они не нужны… другие языки десятки лет без этого обходяться и если у Ruby или Perl (или ещё у какого-нибудь ЯП) от этого можно избавиться путём изменения языка, то PHP движеться в сторону java которая совсем не гибкая в этом отношении.
На перл большое влияние оказал пакет List::Util, который сильно подтолкнул программистов на использование map grep конструкций. Сделав их изящнее и понятние. Современный перл — это не нагромождение регэкспов, но куча функциональных блоков/выражений. Хотя наследство у перла тяжёоооолое.

use List::Util qw/first reduce/;

my @a = (
[0.6, 0.25, 0.15],
[0.4, 0.3, 0.3],
[0.9, 0.09, 0.01]
);


sub normal_rnd {
	return map { my ($i, $r) = ($_,rand()); first { 0 > ($r -= $a[$i]->[$_]) } 0..2}; } 0..$#a;
}

sub probability{
       return reduce{ $a * $b} @_;
}

print probability(normal_rnd());
Вот всегда переходите на личности:-)

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

Любую задачу роутинга в веб-приложении может решить компонент почти любого фреймворка на PHP!
ну конечно фреймворки эту задачу должны уметь решать в первую очередь, хехе

но в PHP это особенно неуклюже выглядит по сравнению с другими ЯП
UFO landed and left these words here
Вполне удобно, но только для маленьких проектов на мой взгляд, ибо чтобы изменить роутинг надо будет файлы переименовывать, это на мой взгляд менее удобно чем один файлик поправить, а как там динамические маршруты строятся (где вместо какого-либо уровня может быть выбор из нескольких вариантов)?
UFO landed and left these words here
Опять же, вы показали что проблема удобности в PHP решилась не какими то синтаксическими возможностями языка, а олдскульным способом с файлами которым можно хоть в ассемблере решить таким же способом.

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

Да как платформа он сейчас силён как никогда, но как ЯП он ужасен и улучшить его не превращая его в другой ЯП не видно как.

Также Вы утверждали, что «в PHP это особенно неуклюже выглядит по сравнению с другими ЯП», а в ЯП это на самом деле вообще никак не выглядит — это вопрос фреймворка. CGI-программа на чистом питоне выглядит гораздо более неуклюже, чем любой PHP-скрипт.

Тут вы не совсем правы, ибо, возможности и удобство работы с фреймворком зависит также и от возможностей языка. Если для того чтобы выбрать из массива элементы большие 5, например, мне приходиться писать 3-5 строк кода — это проблема, в том же Perl (из которого PHP вырос) это делалось в малюсенькую строчку
grep $_ > 5, @arr
, в Ruby и Python это делается не сложнее. И ответьте пожалуйста ещё на один вопрос: «это просто поправить в PHP, без изменения его концепции?»
UFO landed and left these words here
Подсказка HTML::Mason — тот же ПХП вид сбоку. Только очень шустрый, перловый и со средствами организации проектов.

Минусы не прост в настройке — по крайней мере ветка 1.x. Ставился так бы легко как ПХП… на нём было бы море говнокода.
UFO landed and left these words here
Ну это неудивительно — если язык считает, что вы всегда сами знаете, что делаете, то… эту ответственность надо оправдывать, а не злоупотреблять. А злоупотреблять проще. Оно же работает… как-то…
Питон, кстати, после перла бесил неимоверно. Он то как раз считает. что вы не знаете что делаете, поэтому надо постоянно кричать «сюда нэ хади, снег бошка упадёт...» (с)
Блин, да не хочу я чтобы исчезал PHP и код написанный на нём. Это невозможно и нецелесообразно.

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

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

P.S. мне вообще не нравиться Python по некоторым соображениям, я за Perl. Но в ближайший год изучу и Python тоже, чтобы знать что я теряю (а может и не теряю =) )

P.P.S. Perl-CGI — откровенно неудачный способ делать веб-сайты, неудивительно что он тогда проиграл PHP, но из-за своей гибкости как ЯП Perl опять получил очень качественный синатра подобный фреймворк Mojolicious, по простоте и изяществу которого лично я у PHP конкурентов не вижу.

P.P.P.S. И писать на чистом PHP сайты сейчас вовсем не удобно (и небезопасно).
UFO landed and left these words here
И писать на чистом PHP сайты сейчас вовсем не удобно (и небезопасно).

После второго приложения хочешь, не хочешь, а получаешь свой фреймворк (при соблюдении некоторых простых условий, типа тестируемого кода и соблюдения DRY). И писать сайты на чистом Python/Ruby/… я б не сказал, что удобнее чем на PHP, как минимум без «прокладки» типа WSGI/Rack.
Ну просто это один из «плюсов PHP» о котором всегда вспоминают. Я просто выделил что он неактуален.
P.S. мне вообще не нравиться Python по некоторым соображениям, я за Perl. Но в ближайший год изучу и Python тоже, чтобы знать что я теряю (а может и не теряю =) )

Ну что, изучили питон?
Вот это вы вспомнили =)

Да, с тех пор я и с Python познакомился (даже поддерживал несколько проектов на нём на фрилансе и несколько плагинов написал). А также с Erlang/Elixir, сейчас Haskell и Rust изучаю.

Про Perl могу сказать вот что: как только разработка становится командной все эти документированные багофичи парализуют прогресс (и к PHP это относиться в том числе). Его я больше не использую, ни для чего.

Python — очень неплохой и понятный язык программирования, в некоторых областях он монополист (ML и BigData). Так или иначе с ним приходиться сталкиваться и опыт в основном положительный.

Мне всё же больше нравится Ruby для веб разработки и написания инструментов, он более консистентный + разработчики на нём любят удобные интерфейсы использовать, ну и в целом им не чуждо прекрасное + лучшая поддержка unicode среди всех языков (японцы жеж) =)

Самый чемпион по сложности веб фреймворков для меня — Haskell, причём, сам синтаксис и основополагающие концепции оказались проще чем предполагалось, а вот простейшее API сделать за вечер мне далось невероятной болью и страданиями (там надо что-то принципиально новое придумать), для сравнения на Elixir + Phoenix за полчаса с нуля написал приложение, что меня очень сильно удивило.
Покажите пожалуйста, чем силён PHP именно как язык программирования, как он помогает решать проблемы?

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

Ещё плюс по сравнению с python/ruby: Си/«Си с классами»-подобный синтаксис (сам его выбрал именно за это вместо Perl, о серверном JS речи не было тогда).
Дык большинство проектов как раз маленькие. Просто ай-тишники этого незамечают, так как занимаются в основном проктами от среднего. А всякие чебуречные, продавцы сигарет поштучно и прочая «мелочь»… которых миллионы.
Спасибо большое за перевод. Сам на питоне пишу, но было очень интересно почитать.
Удивительно, что у хабратопика все еще положительный рейтинг. Удивительно и приятно. :)
Сочетание слов «PHP» и «плохой» в названии топика на хабре не даст ему уйти в минус.
Я предполагал обратное, исходя из того, что:

1) PHP на данный момент мегапопулярен;
2) Объективность — это не о пользователях Хабра. Сливается всё — то, что непонятно, то, что не нравится, то, что не совпадает с мировоззрением.

Поэтому я удивился и порадовался. Уже трое пользователей сочли это недопустимым, а один даже не поленился заглянуть в мой профиль и понизить карму. :)
Почти все факты в статье верно изложены. Но:
1. Php развивался эволюционно и почти с нуля. Таким образом, большинство нелогичных вещей — это плата за совместимость с прошлыми версиями (и с прошлыми архитектурными ошибками, которые пустили корни). Благодаря этой совместимости php во многом и обрел свою популярность. Тут можно сравнить с microsoft (быги статьи тут про то, какие им приходится расставлять костыли иаде совместимостью с какой-нибудь windows 95 до сих пор).
2. К счастью, на реальной практике приходится сталкиваться менее чем с половиной из указанных несуразностей (т.е. больше половины вещей — хоть и кривы, но очень редко применяются).
3. Подробная документация и большое комьюнити многое компенсируют. По-моему, в этой части php наголову выше большинства других языков.
4. Массовая аудитория программистов имеет тот язык, который заслуживает. Увы, но со статистикой не поспоришь. (Сейчас я за это минусов огребу, знаю.)
5. Где бы сейчас была отрасль веб-программирования, если бы не php? Далеко и глубоко. Ваш 90-летний дед тоже может сейчас противно шамкать и плеваться за столом, но это не умаляет того, что он брал Берлин во время ВОВ.
5. Многие из оставшихся вещей хоть и звучат в теории страшно, но на практике почему-то оказываются почти безобидными (например, фатал ерроры, локальные переменные, инклюды). Сам удивляюсь, почему практика так далеко отстоит от теории здесь.

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

Еще один очень важный момент, касающийся эволюции языка: у PHP в отличие от C++ нет Страуструпа, который бы объяснил, что всё так и должно быть, и по-другому быть не может :)
Или хотябы Стивенсона, который написал бы книжку о ПХП.

С его фантастически научным и экспериментальным подходом. Когда разработчики железа (вроде как даже из cisco) потом говорили «В стандарте было написано неопределенно, но у Стивенсона написано было так. Мы так и сделали.»
PHP-программисты убили родителей автора?
Почему, вместо того, чтобы программировать на своём любимом языке и получать от этого удовольствие нужно писать такую гневную простыню?
Затем что:
1. Молодые программисты, начинающие на пхп, способствуют поддержанию его на плаву.
а это плохо по многим причинам, сами догадаетесь по каким?
2. Врожденные дефекты пхп способствуют возникновению дополнительных багов и уязвимостей, за что мы платим как нервами, так и кошельками.
Первая часть, переведена неплохо, но подробности нуждаются в улучшении (ПРОМТ?)
После:
Отдельные операторы для каждого типа делают язык гораздо более сложным, например вы не можете использовать '==' для строк(что?), вы теперь будете использвать 'eq'. Я не вижу никакого смысла, особенно в таком языка как PHP, где большинство скриптов будут достаточно простыми и в большинстве случаев написаны непрограммистами, которым нужен язык с простейшим логическим синтаксисом и у которого низкий порог вхождения.

читать дальше не смог…
UFO landed and left these words here
В PHP-DEV рассылке данный пост уже обсосали, назвали автора капитаном очевидность, а так же пожеланием автора пропиарится за счёт блогпоста для набивания себе цены.
Всё что думает сообщество разработчиков об этом посте можно почитать в первоисточнике вот тут: marc.info/?t=133418943700005&r=1&w=1 и отделившуюся ветку тут marc.info/?t=133407516900003&r=1&w=1
Сложилось впечатление, что автора статьи (именно статьи, а не перевода), php чем-то обидел…
Да, есть неровности, но где можно увидеть идеальность?
Желаете совершенного языка? Тогда создайте свой — неповторимый и идеальный.
Я тоже могу написать, что чб телевизор «Березка» — говно, хоть сам смотрел его двадцать лет назад.
В «Березке» всякие ручки громкости, контрастности и яркости + здоровенный переключатель каналов, вечно горящие лампы.
Сколько неудобст? Уйма!
Но ведь пользовались…