Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 539
Какой ужасный перевод.
Статья огромная. Слэнговая. Я считаю оно в любом случае того стоило :)
Перевод неплохо. Просто, видимо, у автора не так много переводческого опыта и он спешил.
Можете перевести сами: translated.by/you/php-a-fractal-of-bad-design/into-ru/trans/
Сколько пафоса…
Я конечно ждал, что эта нетленка будет переведена на Хабрахабре… Но не в таком виде.
Тут нужен адаптивный перевод с сохранением юмора, а не этот прогон через первокурсника-филолога, ну. Текст заслуживает хорошего перевода.
Тут нужен адаптивный перевод с сохранением юмора, а не этот прогон через первокурсника-филолога, ну. Текст заслуживает хорошего перевода.
Извините, я не филолог. Поможете довести до ума?
Я такие вещи читаю только на языке оригинала.
Тащемта, кому интересно, есть неплохой ответ на статью: blog.ircmaxell.com/2012/04/php-sucks-but-i-like-it.html
Тащемта, кому интересно, есть неплохой ответ на статью: blog.ircmaxell.com/2012/04/php-sucks-but-i-like-it.html
И да, я тоже не филолог :)
Для того, чтобы делать хорошие переводы, не надо быть филологом, надо хорошо знать язык, на который вы переводите (и неплохо — тот, с которого).
Кстати, почему бы и не довести её до ума, раз уж начали.
Кидайте мне в почту (sergey.sega.vasilenko → gmail.com) вариант с маркапом. Сегодня-завтра причешу.
Кидайте мне в почту (sergey.sega.vasilenko → gmail.com) вариант с маркапом. Сегодня-завтра причешу.
читал и плакал
Хотел написать много всего, но решил ограничиться следующим:
1. Надеюсь, автору оригинала и переводчику значительно лучше спится после такой полезной и оригинальной статьи.
2. Надеюсь, промт не сильно устал, когда переводил. И не убеждайте меня в том, что перевод ручной.
«Я пожаловался на это конкретное место разработчикам PHP минимум два года назад, разработчик был встревожен и страница не был с тех пор обновлена»
И такого пол текста.
3. Всегда думал, что если что-то не нравится, то не бери и не пользуйся. Ощущение, будто автора пытали программированием на PHP несколько лет и в сыром подвале. Потом его спасла полиция и вся эта статья — исповедь перед журналистами. Для чего потрачено столько времени?
1. Надеюсь, автору оригинала и переводчику значительно лучше спится после такой полезной и оригинальной статьи.
2. Надеюсь, промт не сильно устал, когда переводил. И не убеждайте меня в том, что перевод ручной.
«Я пожаловался на это конкретное место разработчикам PHP минимум два года назад, разработчик был встревожен и страница не был с тех пор обновлена»
И такого пол текста.
3. Всегда думал, что если что-то не нравится, то не бери и не пользуйся. Ощущение, будто автора пытали программированием на PHP несколько лет и в сыром подвале. Потом его спасла полиция и вся эта статья — исповедь перед журналистами. Для чего потрачено столько времени?
Вы знаете. Не промтом. Вручную. Над процитированным предложением долго бился, а вот с родом и правда промахнулся. Ща поправим.
Не обижайтесь, но по-моему, здесь тот случай, когда проще «сделать заново», нежели исправить.
siasia пожимает плечами.
Забейте на всех этих умников — они просто завидуют, что Вы смогли сделать такой здоровенный кусок работы, а они нет. Я прочитал с удовольствием, спасибо за перевод.
Да бросьте вы.
Сделать много работы и сделать много работы хорошо — разные вещи. Не понимаю, чего все так переводчика защищают. Или вам плевать, что вам предлагают к прочтению? Как можно «с удовольствием читать» несогласованные предложения, где смысл не всегда понятен?
Сделать много работы и сделать много работы хорошо — разные вещи. Не понимаю, чего все так переводчика защищают. Или вам плевать, что вам предлагают к прочтению? Как можно «с удовольствием читать» несогласованные предложения, где смысл не всегда понятен?
Нам не плевать. Вот мы вместо того, чтобы судачить об этом скидываем в личку переводчику багованые места. И по-тиху статья становится лучше.
Мне не наплевать на то, что я читаю. Если взялся переводить, то делай это хорошо. Лично я не вижу никаких подов исправлять чужой перевод. По-моему, в наше время, можно любой текст перевести без проблем, при этом владея только тем языком, на который осуществляется перевод.
В общем ладно, продолжайте хвалить другу друга и заниматься обоюдным вытиранием соплей. В нашей стране так принято — человека стоит хвалить за одно только желание что-то делать. Качество результата второстепенно. Толерантность и кармодрочество хабра возводят все это в степень.
В общем ладно, продолжайте хвалить другу друга и заниматься обоюдным вытиранием соплей. В нашей стране так принято — человека стоит хвалить за одно только желание что-то делать. Качество результата второстепенно. Толерантность и кармодрочество хабра возводят все это в степень.
У нас тут вообще-то сообщество. Если нашел ошибку или неточность — сообщи автору в лс. Никто никому ничего не обязан. Ишь ты, не нравится ему перевод.
Да, простите. Я забыл, что быть нем-то недовольным запрещено. Нужно всем широко улыбаться и говорить спасибо даже за то, что в принципе внимания не достойно.
Есть такой принцип в мире opensource: «Открывать рот может только тот, кто что-то сделал». Если бы у Вас в профиле висел десяток грамотных переводов и значок «Переводчика» — Ваши замечания были бы приняты и имели бы смысл. Заявления «Надо делать хорошо! Я вот ничего не сделал, но если бы сделал — это было бы сделано ужасно круто» — Вы сами слышите как звучат.
> Как можно «с удовольствием читать» несогласованные предложения, где смысл не всегда понятен?
У меня в голове встроенная автозамена, которая согласует слова в предложении, тогда становится понятен смысл, так что все нормально.
Но, немного соглашусь, что перевод местами кривой.
У меня в голове встроенная автозамена, которая согласует слова в предложении, тогда становится понятен смысл, так что все нормально.
Но, немного соглашусь, что перевод местами кривой.
На английском я бы столько не прочитал. Хотя читаю более менее свободно.
Тут воткнулся в пару шероховатостей. Остальное читается, пусть и не всегда легко. Сложный для мня абзац поправил и скинул автору.
А за перевод респект. Хоть я и не пишу на ПХП после того, как провел две почти бессонные недели вычищая код наших аффилированных субподрядчиков. Потому что с их срокам реакции на замечания — так было проще.
По сути статьи меня бесит еще вот что: пхп позаимсвовал у перла много библиотек (с теми же именами), поэтому когда гуглишь что-то перловое… натыкаешься на кучу к делу не относящегося.
Тут воткнулся в пару шероховатостей. Остальное читается, пусть и не всегда легко. Сложный для мня абзац поправил и скинул автору.
А за перевод респект. Хоть я и не пишу на ПХП после того, как провел две почти бессонные недели вычищая код наших аффилированных субподрядчиков. Потому что с их срокам реакции на замечания — так было проще.
По сути статьи меня бесит еще вот что: пхп позаимсвовал у перла много библиотек (с теми же именами), поэтому когда гуглишь что-то перловое… натыкаешься на кучу к делу не относящегося.
И над «нитями» вместо «потоков» бились наверное?
Поддержу про перевод. Прежде чем переводить с английского, неплохо бы выучить русский. Глядишь и проблем с переводами меньше будет.
> 3
Вот мне тоже интересно, как он собрал такую огромную подборку. Это надо быть или коллекционером, или мазохистом.
Пока работаешь на php половины из этого не замечаешь, ко второй привыкаешь и это не так беспокоит. Проблемы видно со стороны. После Питона, например.
Вот мне тоже интересно, как он собрал такую огромную подборку. Это надо быть или коллекционером, или мазохистом.
Пока работаешь на php половины из этого не замечаешь, ко второй привыкаешь и это не так беспокоит. Проблемы видно со стороны. После Питона, например.
Я хотел автору оригинала нечто подобное написать (это я про пункт 3) и даже пытался адаптировать наше «мыши плкали, кололись, но продолжали жрать кактус» для инглиш-спикеров, но вспомнил картинку «в интернете кто-то не прав» и решил, что оно того не стоит — у каждого свои заморочки.
Пусть ruby, java, python, erlang программисты тужатся, обсирая PHP, мне как-то пофиг — для меня PHP — инструмент, так же, как Python и Java.
Пусть ruby, java, python, erlang программисты тужатся, обсирая PHP, мне как-то пофиг — для меня PHP — инструмент, так же, как Python и Java.
Для чего потрачено столько времени?Быть может, для того, чтобы его не тратили другие, выбирая себе инструмент для работы?
Много честно, но много и гипертрофированно. Аналогия с кривыми инструментами не верна, там скорее о кривых руках и незнакомых инструментах надо было писать.
Как php-developer подписываюсь под бОльшей частью претензий, но менять язык не собираюсь, знакомые болячки на уровне разработки как рутина обрабатываются, а новых болячек новых языков никакой устоявшийся проект не утерпит
Как php-developer подписываюсь под бОльшей частью претензий, но менять язык не собираюсь, знакомые болячки на уровне разработки как рутина обрабатываются, а новых болячек новых языков никакой устоявшийся проект не утерпит
Любители php обиделись и вымещают злость на переводчике. Чем выкобениваться, лучше помогите ему, указав на слабые места перевода и предложив свой вариант. Почему-то, ни у кого из прокомментировавших «ужасный перевод», я не обнаружил в профиле десятка отлично переведенный статей. А с виду казались такими умными, начитанными ребятами.
Переводчику спасибо. Представляю каково было переводить эту простыню.
Переводчику спасибо. Представляю каково было переводить эту простыню.
Перевод нормальный, спасибо переводчику.
Что касается автора данного «труда» — очевидно что он просто теоретик.
Да, он много знает, но все это теория. Все эти доводы актуальны только когда речь идет о «программировании ради программирования». Но автор забывает что программирование — это работа, которая делается для того чтобы (о, боже!) получать деньги. А когда мы начинаем говорить о деньгах на первый план выходят совсем другие вопросы:
— скорость развертывания;
— количество специалистов на рынке;
— стоимость обучения;
— размер сообщества;
— количество аутсорсных компаний;
и т.д.
Да какая мне, черт побери, разница что python имеет более правильный синтаксис массивов, если python-разработчика я буду искать полгода, а php — две недели?
Что касается автора данного «труда» — очевидно что он просто теоретик.
Да, он много знает, но все это теория. Все эти доводы актуальны только когда речь идет о «программировании ради программирования». Но автор забывает что программирование — это работа, которая делается для того чтобы (о, боже!) получать деньги. А когда мы начинаем говорить о деньгах на первый план выходят совсем другие вопросы:
— скорость развертывания;
— количество специалистов на рынке;
— стоимость обучения;
— размер сообщества;
— количество аутсорсных компаний;
и т.д.
Да какая мне, черт побери, разница что python имеет более правильный синтаксис массивов, если python-разработчика я буду искать полгода, а php — две недели?
Потому что каждый раз когда вам надо что-то поменять — вы снова будете искать 2 недели еще одного разработчика на PHP, еще неделю он будет переписывать все, т.к. ему просто не понятно что там накалякал предыдущий…
Главные свойства любой системы, которая должна проработать дольше недели — стабильность, поддерживаемость, повторяемость\предсказуемость результата. Если вы пишете код который выбрасываете через неделю — я вам сочувствую, имхо вы проживаете свою жизнь зря, тратя ее на такой бессмысленный труд.
Жизнь слишком коротка чтобы заниматься говенной работой.
Главные свойства любой системы, которая должна проработать дольше недели — стабильность, поддерживаемость, повторяемость\предсказуемость результата. Если вы пишете код который выбрасываете через неделю — я вам сочувствую, имхо вы проживаете свою жизнь зря, тратя ее на такой бессмысленный труд.
Жизнь слишком коротка чтобы заниматься говенной работой.
Вдогонку — это не касается конкретного языка — я не пишу на PHP или Python (хотя последний порывался попробовать\изучить), это именно фундаментальные принципы, которые должны соблюдаться продуктом для надежности его функционирования.
Прочитав статью до половины и сломав мозг на некоторых вещах, типа левоассоциативного ?: (ну почему Horse-то ?8-\?), я понял что обрисованная картина довольно печальная. Хорошо что я ушел из PHP очень рано.
Прочитав статью до половины и сломав мозг на некоторых вещах, типа левоассоциативного ?: (ну почему 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 всегда лучше для последующего использования, чем инлайн-условие, использованное не по делу.
С кучей вариантов if-elseif-else/switch-case всегда лучше для последующего использования, чем инлайн-условие, использованное не по делу.
в php нет функции с параметром который возвратится если ключа нет массиве?
В python это было бы так:
В python это было бы так:
{'B':'bus', 'A' : 'airplane', 'T': 'train', 'C':'car', 'H': 'horse'}.get(args, 'feet')
Если элемент не false или null, то можно так:
$items[$arg] ?: 'feet';
$items[$arg] ?: 'feet';
Вот за что я люблю перл, что там все определенно (ну если знать как работают умолчания, конечно)
exists $items{$arg} && defined $items{$arg} ? $item{$args} : 'default'
Всё это великолепие можно (да и НУЖНО) написать как:
$item{$arg} // 'default'
$item{$arg} // 'default'
Полный аналог этой строки в PHP, видимо:
array_key_exists($arg, $items) && isset($items[$arg])? $item[$args]: 'default';
array_key_exists($arg, $items) && isset($items[$arg])? $item[$args]: 'default';
ну значит не всё так страшно. единственное, что действительно имена функций не очевидные согласованые, хотя код вполне читаем
Кстати, вы ошибку скопипастили. В перл она нестрашная, ибо сразу вылезет exception при use strict (а тех, кто не пишет первой строчкой use strict, на работу не берут, ибо диагноз)
правильней будет просто:
isset($items[$arg])? $items[$arg]: 'default';
isset($items[$arg])? $items[$arg]: 'default';
упс опечатко, но в первой строчке все равно написано use strict;
Ну видите, уже и match появился.
каждый раз когда вам надо что-то поменять — вы снова будете искать 2 недели еще одного разработчика
Если вы пишете код который выбрасываете через неделю
Мне не понятно на чем основаны данные утверждения, как вы пришли к таким выводам и какое отношение они имеют к сказанному мной выше.
Данные утверждения основаны на том, что вы ставите во главу угла количество специалистов на рынке, скорость развертывания и пр. Это все важно, но определенные фичи достижимы при любой платформе, специалисты — вам нужна малая часть, вы же не собираетесь скупить всех свободных пхп прораммистов для реализации своей задачи, а дешевизна — ну о качестве она говорит обычно довольно внятно.
Но при этом вы упускаете из виду фундаментальные свойства, от которых зависит качество работы и сопровождения системы. Вы же не будете развертывать ее каждый день по новой, заказывать аутсорсинг или обращаться к коммунити. Один раз развернутая система должна работать. А создавать систему на «слабопредсказуемом» языке ( дао horse из текста я еще пока не постиг) — довольно опрометчиво.
Поэтому и существует вся эта огромная экосистема — дешевые и в большом количестве программисты, массовые решения, обилие вопросов и ответов в коммьюнити — именно потому что язык нелогичен, и чтобы что-то сложное на нем сделать или отладить — надо 100 раз спросить — как же это работает ( а главное потом — из десятков противоречащих ответов — вычленить один правильный).
Я знаю (видел) что и на ПХП тоже можно писать качественные и сложные системы, но как правильно замечено в статье — талантливый программист перепишет любое решение хоть на brainfuck'е. Но зачем? Зачем делать что-то правильно когда сам язык мешает это делать, когда его поведение нелогичное, когда оно непредсказуемо и зависит от 2-3-5 параметров исходной системы, настроек компиляции или локали установленной при развертывании.
Создавать продукты для такого окружения — тратить время своей жизни на борьбу с ветрянными мельницами — можно, но бесполезно. Хотя это ваше время и вам выбирать на что вы его потратите.
Но при этом вы упускаете из виду фундаментальные свойства, от которых зависит качество работы и сопровождения системы. Вы же не будете развертывать ее каждый день по новой, заказывать аутсорсинг или обращаться к коммунити. Один раз развернутая система должна работать. А создавать систему на «слабопредсказуемом» языке ( дао horse из текста я еще пока не постиг) — довольно опрометчиво.
Поэтому и существует вся эта огромная экосистема — дешевые и в большом количестве программисты, массовые решения, обилие вопросов и ответов в коммьюнити — именно потому что язык нелогичен, и чтобы что-то сложное на нем сделать или отладить — надо 100 раз спросить — как же это работает ( а главное потом — из десятков противоречащих ответов — вычленить один правильный).
Я знаю (видел) что и на ПХП тоже можно писать качественные и сложные системы, но как правильно замечено в статье — талантливый программист перепишет любое решение хоть на brainfuck'е. Но зачем? Зачем делать что-то правильно когда сам язык мешает это делать, когда его поведение нелогичное, когда оно непредсказуемо и зависит от 2-3-5 параметров исходной системы, настроек компиляции или локали установленной при развертывании.
Создавать продукты для такого окружения — тратить время своей жизни на борьбу с ветрянными мельницами — можно, но бесполезно. Хотя это ваше время и вам выбирать на что вы его потратите.
Ну я понял. PHP это зло по определению и любые его плюсы — всего лишь заблуждение.
Миллионы людей пользуются им лишь потому что он прост, а питон невероятно сложен, ок.
Миллионы людей пользуются им лишь потому что он прост, а питон невероятно сложен, ок.
Ну какие у него плюсы как у языка программирования?
P.S. PHP просто только для непосвящённого человека, чтобы примеры для новичков выглядели симпатично, на самом деле надо писать МНОГО неудобного и некрасивого кода и единственный выход для какой-никакой гибкости — это уход в жёсткое ООП, что для новичков не особо-то радостная новость.
P.S. PHP просто только для непосвящённого человека, чтобы примеры для новичков выглядели симпатично, на самом деле надо писать МНОГО неудобного и некрасивого кода и единственный выход для какой-никакой гибкости — это уход в жёсткое ООП, что для новичков не особо-то радостная новость.
Я все написал в первом комментарии этой ветки.
Проблема в том, что спорят со мной программисты — то есть те люди, который видят лишь одну сторону медали — написание кода. Думать о том что этот код нужно будет потом продать — не их работа.
Проблема в том, что спорят со мной программисты — то есть те люди, который видят лишь одну сторону медали — написание кода. Думать о том что этот код нужно будет потом продать — не их работа.
На самом деле в веб программировании клиенты не очень часто выставляют предпочтения на чём для них писать и как писать. Их больше интересует скорость, дешевизна и чтобы продвижение было дешёвое. Потому предлагать им можно что угодно, самое главное оправдывать данные обещания.
Да и можно переубедить при желании.
А большинство пишут на PHP не из-за каких-то сложных мыслей и забот, а потому что не знают что есть что-то иное и более лучшее.
Да и можно переубедить при желании.
А большинство пишут на PHP не из-за каких-то сложных мыслей и забот, а потому что не знают что есть что-то иное и более лучшее.
Пару-тройку лет назад ещё большим доводом в пользу php была огромная проблема с хостингами для ruby/python.
А вот сейчас, если не считать хостеров с сервисом 'всё за пять копеек', то этой неприятности уже нет.
А вот сейчас, если не считать хостеров с сервисом 'всё за пять копеек', то этой неприятности уже нет.
Ну как сказать, я пару месяцев назад так и не нашел хостинга с актуальной версией руби и рельс. Пришлось брать VPS. И неделю его мучать в попытках поставить весь набор.
Неделю? Что же вы делали неделю, интересно? Когда мне понадобился хостинг для работы django, я просто купил первый попавшийся VPS и настроил все за два часа.
Приложения на рельсах, джанге, куче других языков (Java, Scala, Clojure, Erlang, Node.js, PHP, etc) можно очень быстро задеплоить на Heroku.
Ну, тем более — если это ускорит процесс еще больше (сам не пробовал пока, но спасибо за наводку), то о какой неделе настройки говорить вообще? :))
Фактически деплой приложения на Heroku сводится к
(Если язык/фреймворк приложения поддерживается платформой — то больше ничего не надо, если же приложение на чем-то другом — можно найти кастомный билдпак.)
И кстати, на хероку можно запускать не только веб-приложения. Это могут быть и всякие background worker'ы, и боты.
Масшабировать приложения тоже не тяжело:
Ну и легкая установка аддонов:
По своим возможностям, IMO, Хероку является очень гибким и простым решением.
$ 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 имеет кучу проблем. Не спорю с этим, это очевидно.
Но продавать решения на нем — легче. Потому что он популярен.
Так что надо быть объективнее и не делать крайних утверждений.
Для сравнения два варианта для предложения клиенту:
1. Мы напишем вам все на PHP и это будет работать на любом хостинге, который вы сможете сменить в любой момент просто скопировав файлы. Любой из тысяч фрилансеров сможет сделать доработки за небольшую сумму, если потребуется.
2. Мы сделаем все на Django, но вам потребуется VDS и сисадмин который все это развернет и настроит. Если хостинг разонравится — вам нужно будет повторить операцию на новом VDS. Для доработок вам нужен будет специалист по Django, которого трудно найти и он дорого стоит.
Какой вариант выберет клиент?
Я согласен что PHP имеет кучу проблем. Не спорю с этим, это очевидно.
Но продавать решения на нем — легче. Потому что он популярен.
Так что надо быть объективнее и не делать крайних утверждений.
Давно уже это неверно, как минимум с выхода PHP 5.3, ибо на многих хостингах стоит PHP 5.2 и так запросто всё не заработает (если замыкания используются и.т.п.). Да и клиенты сами с хостинга на хостинг на моей памяти не переезжали, всегда за отдельную плату, либо на основании каких-то договорённостей просили наших специалистов перенести им сайт.
Далее: вряд ли компания будет искать фрилансеров не имея квалифицированного товарища для этого, а если он есть — то не важно какой ЯП и платформа используются, так как он эти проблемы решит.
Далее, обычно продавая сайт продают ещё и целый пакет услуг в которые входит и поддержка и доработка творения, потому выбор языка важен только если веб-студия разругалась с клиентом и/или не доделала всё в полной мере, такое бывает не часто и таким веб-студиям выбор ЯП не поможет =)
Я работал в веб студии которая имела собственный хостинг, потому это было совсем не проблемой. Да и за деньги мы подыскивали для клиентов хостинги и переносили их сайты (даже без собственной доработки).
Клиент выберет тех кому доверяет (а тут очень сильно влияют портфолио компании и обаяние менеджера), независимо от платформ и ЯП, ибо он (клиент) обычно не разбирается в этом.
P.S. опять же клиенту можно и про говнокодеров на PHP рассказать каждый последующий из которых за его деньги будет переписывать ему один и тот же код =)
P.P.S. сам сейчас поддерживаю достаточно посещаемый проект, после последнего говнокодера сайт просто перестал работать. Сейчас на том же железе производительность подняли в 6 раз и, думаю, ещё столько же выдержим. Так вот, эти сторонние фрилансеры-разработчики ни о какой безопасности вообще не задумывались, сайт был дырявый как дуршлаг. Про индексы для БД они тоже не слышали и о том что профилировать запросы можно тоже не знали. Кеширование — тоже какое то непонятное слово, при том что платили им от 1500/час. Вот тебе и PHP фрилансеры нанятые человеком не разбирающимся в вопросе.
Далее: вряд ли компания будет искать фрилансеров не имея квалифицированного товарища для этого, а если он есть — то не важно какой ЯП и платформа используются, так как он эти проблемы решит.
Далее, обычно продавая сайт продают ещё и целый пакет услуг в которые входит и поддержка и доработка творения, потому выбор языка важен только если веб-студия разругалась с клиентом и/или не доделала всё в полной мере, такое бывает не часто и таким веб-студиям выбор ЯП не поможет =)
Я работал в веб студии которая имела собственный хостинг, потому это было совсем не проблемой. Да и за деньги мы подыскивали для клиентов хостинги и переносили их сайты (даже без собственной доработки).
Клиент выберет тех кому доверяет (а тут очень сильно влияют портфолио компании и обаяние менеджера), независимо от платформ и ЯП, ибо он (клиент) обычно не разбирается в этом.
P.S. опять же клиенту можно и про говнокодеров на PHP рассказать каждый последующий из которых за его деньги будет переписывать ему один и тот же код =)
P.P.S. сам сейчас поддерживаю достаточно посещаемый проект, после последнего говнокодера сайт просто перестал работать. Сейчас на том же железе производительность подняли в 6 раз и, думаю, ещё столько же выдержим. Так вот, эти сторонние фрилансеры-разработчики ни о какой безопасности вообще не задумывались, сайт был дырявый как дуршлаг. Про индексы для БД они тоже не слышали и о том что профилировать запросы можно тоже не знали. Кеширование — тоже какое то непонятное слово, при том что платили им от 1500/час. Вот тебе и PHP фрилансеры нанятые человеком не разбирающимся в вопросе.
Все ваши плюсы не относятся к языку программирования, а к сложившейся на рынке ситуации. И, как мне кажется, автор оригинальной статьи исходит гневом именно по той причине, что наибольшее инфраструктурное преимущество имеет язык с одним из худших дизайнов. Это… огорчает.
Однако авторы подобных статей — не конструктивны. На тему того, что PHP плох — вылито уже прилично помоев. Но ещё никто не придумал, как внедрить в инфраструктуру веб лучший язык. А без этого все подобные статьи — неуместный троллинг и пережёвывание одного и того же. Впрочем, именно эта статья наверно должна была быть написана, переведена и прочитана каждым — титанический труд собрать всё это вместе и систематизировать. Надеюсь это поможет как-то изменить ситуацию со временем — то ли в сторону развития PHP как языка, то ли в сторону популяризации Ruby или Python'а.
Авторы подобных статей конструктивны в том смысле, что до сих пор встречаю фанбоев PHP, пытающихся рассказать о его достоинствах именно как языка. Можно не тратить время на призывы к здравому смыслу, а просто давать линк на статью.
Удобно.
А насчёт придумки — пфф, тут и думать нечего. Просто используйте другой язык. Вот так просто. Впрочем, в российских реалиях можно ещё попытаться нарисовать законодательный запрет на PHP с уголовной ответственностью :)
Удобно.
А насчёт придумки — пфф, тут и думать нечего. Просто используйте другой язык. Вот так просто. Впрочем, в российских реалиях можно ещё попытаться нарисовать законодательный запрет на PHP с уголовной ответственностью :)
Вот так просто
И что в этом простого? Если я для своего проекта выберу другой язык — популяризации этого языка это поспособствует мало, а вот я огребу все недостатки низкой популярности этого языка — отвратная документация, отсутствие вменяемого сообщества, отсутствие соответствующего предложения на рынке труда. Хорошо, если проект — крупный и расчёт изначально идёт на то, что труд высококлассного программиста на порядки дешевле затрат на железо, всё окупится. Крупные проекты, собственно, так и поступают. Но если проект небольшой, специалисты на него нужны недорогие, то простотой здесь не пахнет ну никак. Небольших проектов значительно больше, чем крупных. Энтузиастов, готовых облагораживать за свой счёт индустрию — не много.
По моему скромному мнению, PHP вообще развивается быстрее, чем альтернативные языки откусывают долю от рынка.
И что в этом простого? Если я для своего проекта выберу другой язык — популяризации этого языка это поспособствует мало, а вот я огребу все недостатки низкой популярности этого языка — отвратная документация, отсутствие вменяемого сообщества, отсутствие соответствующего предложения на рынке труда. Хорошо, если проект — крупный и расчёт изначально идёт на то, что труд высококлассного программиста на порядки дешевле затрат на железо, всё окупится. Крупные проекты, собственно, так и поступают. Но если проект небольшой, специалисты на него нужны недорогие, то простотой здесь не пахнет ну никак. Небольших проектов значительно больше, чем крупных. Энтузиастов, готовых облагораживать за свой счёт индустрию — не много.
По моему скромному мнению, PHP вообще развивается быстрее, чем альтернативные языки откусывают долю от рынка.
Вы или не читаете что я пишу или явно троллите. Я пытаюсь пояснить, почему предсказуемость поведения, защита от незнания секретных ключей\констант, (по сути все это — повторяемость результата) для языка важнее, чем доступность, массовость и дешевизна кодеров.
Банальный пример:
трудозатраты на реализацию решения с использованием языка «Х» — это сумма «5хS». Для доработки или для повторения решения (сделать и развернуть еще 1-2-100 копий) необходимы затраты «K».
Трудозатраты на реализацию решения с использованием языка Y — это сумма S, сумму вы смогли уменьшить за счет массовой конкуренции на рынке программистов на Y. Но с большой вероятностью вы получили некачественное или сложноподдерживаемое решение. Если вас это устраивает — все ОК, одноразовые вещи должны делаться как можно дешевле.
Если вам необходимо сопровождать\повторять это решение для каждого заказчика — стоимость сопровождения будет не K, а например 3хК. Очевидно что деньги сэкономленные в S против 5xS, вы потратите при доработках.
А т.к. жизненный цикл нормального приложения довольно длинный — доработок будет больше чем разработок с нуля. В итоге в длительной перспективе — решение на языке Х дешевле чем на Y, хотя начальные вложения были больше.
Вроде прописные истины, а вы обвиняете что я что-то называю злом по определению.
Выбор платформы должен происходить на основе всего жизненного цикла приложения — короткая жизнь, одноразовый код — берите Y, доработки, сопровождение, надежность — берите X.
Да, вместо X и Y могут быть любые другие языки, не обязательно упомянутые ;).
Банальный пример:
трудозатраты на реализацию решения с использованием языка «Х» — это сумма «5хS». Для доработки или для повторения решения (сделать и развернуть еще 1-2-100 копий) необходимы затраты «K».
Трудозатраты на реализацию решения с использованием языка Y — это сумма S, сумму вы смогли уменьшить за счет массовой конкуренции на рынке программистов на Y. Но с большой вероятностью вы получили некачественное или сложноподдерживаемое решение. Если вас это устраивает — все ОК, одноразовые вещи должны делаться как можно дешевле.
Если вам необходимо сопровождать\повторять это решение для каждого заказчика — стоимость сопровождения будет не K, а например 3хК. Очевидно что деньги сэкономленные в S против 5xS, вы потратите при доработках.
А т.к. жизненный цикл нормального приложения довольно длинный — доработок будет больше чем разработок с нуля. В итоге в длительной перспективе — решение на языке Х дешевле чем на Y, хотя начальные вложения были больше.
Вроде прописные истины, а вы обвиняете что я что-то называю злом по определению.
Выбор платформы должен происходить на основе всего жизненного цикла приложения — короткая жизнь, одноразовый код — берите Y, доработки, сопровождение, надежность — берите X.
Да, вместо X и Y могут быть любые другие языки, не обязательно упомянутые ;).
Да нет, троллите скорее вы.
Сначала вы говорите что писать на PHP это «тратить время своей жизни на борьбу с ветряными мельницами», а теперь выясняется что все таки выбор зависит от задачи. Так это же очевидно, об этом я и говорил в своем первом комментарии.
PS: и я до сих пор не понял почему мне нужно будет искать нового разработчика каждый раз, как я захочу что-либо поменять в PHP-коде.
Сначала вы говорите что писать на PHP это «тратить время своей жизни на борьбу с ветряными мельницами», а теперь выясняется что все таки выбор зависит от задачи. Так это же очевидно, об этом я и говорил в своем первом комментарии.
PS: и я до сих пор не понял почему мне нужно будет искать нового разработчика каждый раз, как я захочу что-либо поменять в PHP-коде.
Меня в институте бесил Access. Почти вся группа, из которой, если говорить честно, задатки программистов были у двух трех человек, на Access сделала вполне приемлемые приложения. Я же, «звездочка», с трудом сделал троечную работу, за которую мне поставили 4ку практически за старые заслуги.
Я просто не мог понять, как это работает. А нужно было не пытаться понять, а просто потыкать мышкой. И написать пару строчек кода в в месте обозначенном на лекциях (на которые я, ессно, не ходил). Потом, уже после интститута мне приходилось чинить чужие аксесовские прилады… Практически методом тыка.
Так что пхп на этом фоне логичен, в конце концов не всё заимствованное с перла (который, как не удивительно, весьма логичен) «упрощено для лучшего понимания».
А наличие готовых конструкторов, которые не надо понимать, а надо только поставить и немного настроить, равно как и громадное количество хостингов заточенных под пхп — это то что делает пхп непотопляемым.
Если уж брать что-то что ты непонимаешь, как работает (к чему зачастую приходят вполне логичные и понятные проекты, начинающиеся с легкого фреймворка вне зависимости от языка), то лучше брать то у чего болшеекомьюнити… И менее заносчивое комьюнити, кстати.
Я просто не мог понять, как это работает. А нужно было не пытаться понять, а просто потыкать мышкой. И написать пару строчек кода в в месте обозначенном на лекциях (на которые я, ессно, не ходил). Потом, уже после интститута мне приходилось чинить чужие аксесовские прилады… Практически методом тыка.
Так что пхп на этом фоне логичен, в конце концов не всё заимствованное с перла (который, как не удивительно, весьма логичен) «упрощено для лучшего понимания».
А наличие готовых конструкторов, которые не надо понимать, а надо только поставить и немного настроить, равно как и громадное количество хостингов заточенных под пхп — это то что делает пхп непотопляемым.
Если уж брать что-то что ты непонимаешь, как работает (к чему зачастую приходят вполне логичные и понятные проекты, начинающиеся с легкого фреймворка вне зависимости от языка), то лучше брать то у чего болшеекомьюнити… И менее заносчивое комьюнити, кстати.
Вот это и удивительно — как майрософт ухитрился сделать среду разработки, интуитивно понятную новичкам и «убивающую» спецов, привыкших «копать глубже».
Формы, кстати фигня, — вот система функций там отдельная песня. Как их можно так назвать и организовать, что поиск нужного выливался в квест? Наверно шаманы работали.
Формы, кстати фигня, — вот система функций там отдельная песня. Как их можно так назвать и организовать, что поиск нужного выливался в квест? Наверно шаманы работали.
Хнык. Хнык.
*ушел дальше заниматься говенной работой*…
А где я тут в долбаном захолустье найду вакансию javascript или ruby или чего там еще ТруЪ?
*ушел дальше заниматься говенной работой*…
А где я тут в долбаном захолустье найду вакансию javascript или ruby или чего там еще ТруЪ?
За рубежом, разумеется. Интернеты есть? Весь мир открыт.
Ну да, ну да. Звучит правильно и красиво. Ну а как иначе можно выразиться на таком уважаемом ресурсе. Только вот мне надо пару лет переучиваться, менять подходы, искоренять php из головы, сказать на это время семье и детям — счас мы будем пару лет жить хуже, потому что в интернете дядя мне сказал что на пхп работать низя, и чтобы постичь дзен нужно кодить на питоне…
А, ну да, еще сказать директору той работы на которой работаю — говно эта твоя работа, тут на пхп всё написано, и плевать что мы первые в рунете и снг по нашей тематике. Этож не тру.
А, ну да, еще сказать директору той работы на которой работаю — говно эта твоя работа, тут на пхп всё написано, и плевать что мы первые в рунете и снг по нашей тематике. Этож не тру.
Только вот мне надо пару лет переучиваться
Пару лет? Это же не обучение программированию с нуля. Шаблоны проектирования и прочие MVC они и на питоне работают. База Данных и там и там.
Раз вы хороший специалист, то вы, вероятно, выделяете время для обучения, и, скорей всего, вы программируете не только на PHP. А значит можете изучать тот же питон параллельно работе.
Ну вот смотрите. я представляю что такое mod_php, fcgid, fastcgi, fpm и примерно как их нужно варить и сколько солить; каковы особенности работы с тяжелыми данными на php, как разруливать и делать достаточно нетривиальные конфигурации. Знаю как расширять некоторые cms, их косяки, вижу сразу «индусский код», знаю что мне ждать от xcache а что от других опкешеров, как защитить те или иные вещи и овер 9000 остального. На любой вопрос я почти сразу знаю ответ как это сделать правильно, безопасно, быстро.
И да, я не хочу работать над какой нить херней, где можно обмусоливать и обсасывать mvc как у кота яйца, делать кашерные красивые коды, которые можно вешать в рамочку на стенку. Мне нравиться работать над большими задачами, задачами с историей, с ограничениями, где вот просто так, взял паттерн, погуглил и решил — не обойдется.
Для того, чтобы делать что-то интересное например на питоне, мне нужно знать его историю, знать его косяки, знать на нем как минимум пару различных *MS, архитектуру ядра хотябы в первом приближении, около 50 разных библиотек…
Да, я программирую на javascript. Для души и для работы. Но не на таком уровне как на PHP. И не могу найти на работе время чтобы достаточно серьезно изучать хотябы его. Ибо задачи рутины и задачи стратегические не могут ждать.
Так что развлекайтесь с вашими питонами как душе угодно, но работы на PHP больше раз в 100500. И реалии таковы, что если сразу не начал с этого лет 5 назад, то свободно все бросить можно только при наличии тыла, свободного времени, и уверенности что это еще кому то нужно…
И да, я не хочу работать над какой нить херней, где можно обмусоливать и обсасывать mvc как у кота яйца, делать кашерные красивые коды, которые можно вешать в рамочку на стенку. Мне нравиться работать над большими задачами, задачами с историей, с ограничениями, где вот просто так, взял паттерн, погуглил и решил — не обойдется.
Для того, чтобы делать что-то интересное например на питоне, мне нужно знать его историю, знать его косяки, знать на нем как минимум пару различных *MS, архитектуру ядра хотябы в первом приближении, около 50 разных библиотек…
Да, я программирую на javascript. Для души и для работы. Но не на таком уровне как на PHP. И не могу найти на работе время чтобы достаточно серьезно изучать хотябы его. Ибо задачи рутины и задачи стратегические не могут ждать.
Так что развлекайтесь с вашими питонами как душе угодно, но работы на PHP больше раз в 100500. И реалии таковы, что если сразу не начал с этого лет 5 назад, то свободно все бросить можно только при наличии тыла, свободного времени, и уверенности что это еще кому то нужно…
Вы это всё к чему вообще? Вы спросили — где найти вакансию. Вам ответили — работать с зарубежными заказчиками. Какое отношение к этому имеют рыдания по поводу «переучиваться»?
У нас один программист работал. «У нас» == крупный богатый интегратор. В котором, сотрудников не считали. Посему там можно было не работать (при некоторой пофигистичности и фрондерстве). Ибо з/п одного специалиста ни на что не влияла, а количество спецов влияло — на престиж отдела. Т.е. никого увольнять за профнепригодность там даже и не пытались, просто игнорировали.
А вот этого товарища уволить собирались. Ибо косячил… Везде. eval «action_$USER_INPUT» — это просто мелочи, рабочие моменты.
Но не успели уволить, сам исчез. Объявился в Канаде, либом с приличной зарплатой. Оттуда продолжал по аське задавать дурацкие вопросы, в основном по ПХП. Гуглящиеся на раз-два.
Так что и с ПХП можно уехать и устроиться… Главное чтобыруки язык из нужного места рос.
А вот этого товарища уволить собирались. Ибо косячил… Везде. eval «action_$USER_INPUT» — это просто мелочи, рабочие моменты.
Но не успели уволить, сам исчез. Объявился в Канаде, либом с приличной зарплатой. Оттуда продолжал по аське задавать дурацкие вопросы, в основном по ПХП. Гуглящиеся на раз-два.
Так что и с ПХП можно уехать и устроиться… Главное чтобы
Вы можете стать профессионалом и в PHP, более того — зная все тонкости, описанные в статье, вы будете очень, очень ценным кадром, т.к. вы сможете своим «участием» в проекте на PHP придать языку качества, которыми он «не обладает в стандартной поставке».
Но только надо тогда уж становиться профессионалом, а не убеждать себя в стиле «буду работать как все и на массовом рынке» (возможно вы таким и становитесь, я не знаю).
Есть просто одна проблема работы на массовом рынке — люди стареют и качественно делать одну и ту же работу — невозможно. молодые обойдут на поворотах, срежут углы за счет 3 бессонных ночей, подрежут на хаках, которые вы себе не позволяете. Поэтому надо сдвигаться всегда в сторону «штучности».
В «массе» очень трудно жить, ну если только вы не пасете всю эту массу =)
Но только надо тогда уж становиться профессионалом, а не убеждать себя в стиле «буду работать как все и на массовом рынке» (возможно вы таким и становитесь, я не знаю).
Есть просто одна проблема работы на массовом рынке — люди стареют и качественно делать одну и ту же работу — невозможно. молодые обойдут на поворотах, срежут углы за счет 3 бессонных ночей, подрежут на хаках, которые вы себе не позволяете. Поэтому надо сдвигаться всегда в сторону «штучности».
В «массе» очень трудно жить, ну если только вы не пасете всю эту массу =)
«Работа, чтобы получать деньги»… нет, не слышал. Я-то всегда думал, что это занятие, к которому лежишь всей душой, от которого получаешь удовольствие, ну и, как побочный эффект, за это ещё и хорошо платят. Какой смысл разрабатывать на чем-то, что не нравится концептуально, идеологически или просто неудобно, не радует эстетически, в конце концов? К чему эдакий мазохизм? Но если «работа» от слова «раб», то ок ;-)
Скорость полноценного развертывания иногда даже сильно ниже, потому что надо ещё собрать правильный PHP от какого-нибудь правильного человека, который прикрыл хотя бы какие-то плеши, со всеми миллионами ключиков. Ну или закрывать все плеши самому. В случае с несерьезными или небольшими проектами, время эквивалетно в целом. Хотя, если разворачивать не заботясь вообще ни о чем, в лучших традициях плохого тона, то да, наверно побыстрее выйдет, со всеми вытекающими последствиями.
Количество «специалистов», особенно на школьных каникулах — зашкаливает, а вот найти человека, который правда умеет нормально писать на PHP иногда посложнее, чем для, скажем, конкурирующих языков. Низкий порог вхождения и то, что PHP позволяет писать плохо — делают своё грязное дело, т.е. насыщают этот самый рынок говнокодерами, в то время, как некие другие языки просто не позволяют писать плохой код, что, в купе с другими факторами, предотвращают распространение заразы. Что лучше, 100 человек, из которых только 6 действительно специалисты, или 20, из которых все или, хотя бы, 19 более, чем достойны?
Стоимость обучения… специалистов обучать не надо вообщем-то, они и сами отлично обучаются. Это только «специалистов» надо доучивать или переучивать. На эту тему — предыдущий абзац. Остальные случаи «обучения» тоже эквивалентны вполне, хотя бы, исходя из «затраты/польза».
С сообществом всё тоже самое, что и со «специалистами», — можно иметь орду «индусов», из которых лишь процент — идеологические спецы, или же сообщество поменьше, но где каждый самоценен.
Даже если исходить из денежных соображений, что само по себе, концептуально, «рукалицо» и «провал», то куда больше рисков и потенциальных трат именно на стороне сабжа.
IMHO.
Скорость полноценного развертывания иногда даже сильно ниже, потому что надо ещё собрать правильный PHP от какого-нибудь правильного человека, который прикрыл хотя бы какие-то плеши, со всеми миллионами ключиков. Ну или закрывать все плеши самому. В случае с несерьезными или небольшими проектами, время эквивалетно в целом. Хотя, если разворачивать не заботясь вообще ни о чем, в лучших традициях плохого тона, то да, наверно побыстрее выйдет, со всеми вытекающими последствиями.
Количество «специалистов», особенно на школьных каникулах — зашкаливает, а вот найти человека, который правда умеет нормально писать на PHP иногда посложнее, чем для, скажем, конкурирующих языков. Низкий порог вхождения и то, что PHP позволяет писать плохо — делают своё грязное дело, т.е. насыщают этот самый рынок говнокодерами, в то время, как некие другие языки просто не позволяют писать плохой код, что, в купе с другими факторами, предотвращают распространение заразы. Что лучше, 100 человек, из которых только 6 действительно специалисты, или 20, из которых все или, хотя бы, 19 более, чем достойны?
Стоимость обучения… специалистов обучать не надо вообщем-то, они и сами отлично обучаются. Это только «специалистов» надо доучивать или переучивать. На эту тему — предыдущий абзац. Остальные случаи «обучения» тоже эквивалентны вполне, хотя бы, исходя из «затраты/польза».
С сообществом всё тоже самое, что и со «специалистами», — можно иметь орду «индусов», из которых лишь процент — идеологические спецы, или же сообщество поменьше, но где каждый самоценен.
Даже если исходить из денежных соображений, что само по себе, концептуально, «рукалицо» и «провал», то куда больше рисков и потенциальных трат именно на стороне сабжа.
IMHO.
Вопрос не в том, что нравится именно вам и от чего вы получаете удовольствие.
Это может быть что угодно, без проблем.
Вопрос в экономической эффективности того или иного инструмента.
И в этом плане на сегодня у PHP нет конкурентов, как ни крути.
Да, есть риски. Но в случае чего я найду фрилансера который все исправит за полчаса.
Пусть это будет «говнокод», окей. Но кому какое дело, по сути? В реальном мире всем важно чтобы «это работало» а не «как это работает».
Если вы или ваша компания может позволить себе тратить время на глубокое проектирование, разработку архитектуры и прочее — то замечательно! Но в реальности это удел лишь крупных успешных компаний. Если же речь идет о начальном этапе — вы либо пишете все быстро и зарабатываете деньги, либо вылизываете каждую фичу до блеска месяцами и поезд уходит.
Я не отрицаю что у PHP есть проблемы, более того, согласен почти со всеми утверждениями автора.
Просто я считаю что нельзя так однобоко судить и делать крайние утверждения.
Это может быть что угодно, без проблем.
Вопрос в экономической эффективности того или иного инструмента.
И в этом плане на сегодня у PHP нет конкурентов, как ни крути.
Да, есть риски. Но в случае чего я найду фрилансера который все исправит за полчаса.
Пусть это будет «говнокод», окей. Но кому какое дело, по сути? В реальном мире всем важно чтобы «это работало» а не «как это работает».
Если вы или ваша компания может позволить себе тратить время на глубокое проектирование, разработку архитектуры и прочее — то замечательно! Но в реальности это удел лишь крупных успешных компаний. Если же речь идет о начальном этапе — вы либо пишете все быстро и зарабатываете деньги, либо вылизываете каждую фичу до блеска месяцами и поезд уходит.
Я не отрицаю что у PHP есть проблемы, более того, согласен почти со всеми утверждениями автора.
Просто я считаю что нельзя так однобоко судить и делать крайние утверждения.
Вопрос в экономической эффективности стоит перед бизнесменами, а программистам должно быть важнее удобство инструментов и скорость проектирования и/или рефакторинга ПО.
Программист — это наемный работник, который пишет то что ему скажут на чем ему скажут.
Если программист сам выбирает инструмент — значит он либо уже на половину «бизнесмен» (хотя я бы предпочел слово «менеджер») и ему это позволено, либо для компании где он работает производство софта — не профильное занятие.
Если программист сам выбирает инструмент — значит он либо уже на половину «бизнесмен» (хотя я бы предпочел слово «менеджер») и ему это позволено, либо для компании где он работает производство софта — не профильное занятие.
Пусть это будет «говнокод», окей. Но кому какое дело, по сути? В реальном мире всем важно чтобы «это работало» а не «как это работает».
Подход « лишь бы это работало» приводит только к дополнительным затратам. На поддержку, на оборудование, чтобы «лищь-бы-работало-код» не тормозил.
Если вы или ваша компания может позволить себе тратить время на такой код — то замечательно!
Вы утрируете. Думаю всем понятно что я имел в виду.
Да, не перевелись еще эффективные менеджеры типа «главное побыстрее сбагрить лоху-клиету, экономя на всем». А что, торговать обносками на базаре — тоже бизнес.
Конечно, лучше пусть клиент ждет три года, он же никуда не торопится.
Я ведь не о корпорации со штатом в 1000 программистов говорю.
Я ведь не о корпорации со штатом в 1000 программистов говорю.
Никто не спорит что делать сайты-визитки на PHP легко и выгодно. Я говорил именно о написании веб-приложений.
На питоне можно написать ничуть не медленнее. Можете посмотреть на примеры экстремального программирования, когда делали сервис на Django за 2 суток. На выходе читаемый код, быстро вносить изменения и тд. Берите толковых студентов (питон изучить — ничего сложного), платите нормальную для студента зарплату и делайте качественные продукты. Так нет ведь, столько менеджеров думает что «говнокод» и «говнодизайн» — это такие прихоти программистов.
На питоне можно написать ничуть не медленнее. Можете посмотреть на примеры экстремального программирования, когда делали сервис на Django за 2 суток. На выходе читаемый код, быстро вносить изменения и тд. Берите толковых студентов (питон изучить — ничего сложного), платите нормальную для студента зарплату и делайте качественные продукты. Так нет ведь, столько менеджеров думает что «говнокод» и «говнодизайн» — это такие прихоти программистов.
В итоге мы пришли к тому, с чего все началось.
А именно — к мысли «каждый инструмент хорош для своих задач».
Моя претензия к автору изначально не в том что он ругает PHP, а в том что он умалчивает о возможности его эффективного применения там, где это уместно.
А именно — к мысли «каждый инструмент хорош для своих задач».
Моя претензия к автору изначально не в том что он ругает PHP, а в том что он умалчивает о возможности его эффективного применения там, где это уместно.
Подход « лишь бы это работало» приводит только к дополнительным затратам. На поддержку, на оборудование, чтобы «лищь-бы-работало-код» не тормозил.
Если вы или ваша компания может позволить себе тратить время на такой код — то замечательно!
вот этот вопрос на самом деле заслуживает простыни раз в 10 подлиннее, чем сама статья.
Перманентных выгод может быть гораздо больше, но те заторы, которые могут случиться в дальнейшем, в критическое время — могут убить все начинания. Тонкая грань, нить, на которой висит выбор умного управленца — это найти такой баланс между инструментом, далекоидущими планами, исполнителями и средствами, которые можно на это направить — талант нужен тот еще…
Пусть это будет «говнокод», окей. Но кому какое дело, по сути?
Тем продажникам, которых потом сожрут разъярённые клиенты из-за потери данных?
xkcd.com/327/
да.
В моей практике был клиент, который раньше нанимал индусов.
Ну что же, всего 2$/hour, вся деревня к вашим услугам.
Всё было ок, да.
Перестал, когда слили базу клиентов, из-за кода что-то вроде
«select * from users where login=$_GET['login']»…
Причем это всё было приколочено к вебмагазину на кейке, вопреки всем заветам MVC, вообще игнорируя все концепции.
В моей практике был клиент, который раньше нанимал индусов.
Ну что же, всего 2$/hour, вся деревня к вашим услугам.
Всё было ок, да.
Перестал, когда слили базу клиентов, из-за кода что-то вроде
«select * from users where login=$_GET['login']»…
Причем это всё было приколочено к вебмагазину на кейке, вопреки всем заветам MVC, вообще игнорируя все концепции.
Всегда при упоминании трудов программиста идёт речь об аутсорсинге. Я разрабатываю софт для внутреннего использования в компании, и тут выгода полного ООП, канонов программировани и прочих академических штук очивидна. Иногда давят на «надо быстрее запустить», ошибки в процессе попрявятся.
А когда мы начинаем говорить о деньгах на первый план выходят совсем другие вопросы:
— скорость развертывания;
— количество специалистов на рынке;
— стоимость обучения;
— размер сообщества;
— количество аутсорсных компаний;
Серьезный бизнес! И что это мы тут какие-то тупые .Net и Java изучаем. Весь топовый бизнес давно на пхп!
— скорость развертывания;
Со всеми имеющимися жопами с безопасностью, капризами интерпретатора и т.д? Лол.
— количество специалистов на рынке;
Нормальный PHP разработчик (подчеркнуто) зверь редкий, стоит от 100к
— стоимость обучения;
= время обучения. Опять же нормальный, разработчик — это много лет разбирательства в муторной экосреде и мелких костылях и нюансах.
— размер сообщества;
А качество информации не? Хотя за 10 лет оно действительно не могло не разрастись.
Со всеми имеющимися жопами с безопасностью, капризами интерпретатора и т.д? Лол.
— количество специалистов на рынке;
Нормальный PHP разработчик (подчеркнуто) зверь редкий, стоит от 100к
— стоимость обучения;
= время обучения. Опять же нормальный, разработчик — это много лет разбирательства в муторной экосреде и мелких костылях и нюансах.
— размер сообщества;
А качество информации не? Хотя за 10 лет оно действительно не могло не разрастись.
>Нормальный PHP разработчик (подчеркнуто) зверь редкий, стоит от 100к
Это же каким упрямством нужно обладать, чтобы в процессе обучения программированию не спрыгнуть с него на более интересные языки и доучиться до мастера!
Это же каким упрямством нужно обладать, чтобы в процессе обучения программированию не спрыгнуть с него на более интересные языки и доучиться до мастера!
Ну, в конце 90-х это была просто прекрасная альтернатива перлу, а питон с руби начали набирать силу как веб-платформы только в середине 2000-х, как раз на этот момент пришелся пик качественных PHP профи.
Сейчас клепатель модулей под битрикс может иметь весьма достойную зарплату, так как всю эту заваренную кашу надо как-то поддерживать.
Сейчас клепатель модулей под битрикс может иметь весьма достойную зарплату, так как всю эту заваренную кашу надо как-то поддерживать.
Согласен. Имел опыт найма Django и JS разработчиков, и видел со стороны как ищут качественного РНР.
Меньше всего сейчас качественных JS.
Качественных РНР и Django — примерно на рынке одинаково тяжело найти.
Вот если нужен уровень хуже — тут у РНР плюс несомненный.
Меньше всего сейчас качественных JS.
Качественных РНР и Django — примерно на рынке одинаково тяжело найти.
Вот если нужен уровень хуже — тут у РНР плюс несомненный.
С JS, несмотря на популярность, кучу документации, либ и полную монополию на клиенте есть одна проблема — он очень сложный. Конечно не в плане лексики, а требовательности к разработчику, функционалка схожая с лиспом, куча асинхронных сопель, динамическая типизация, стремный скоп, среда браузера на клиенте, глючная нода на сервере и т.д. Ну и он просто не предназначался для того, для чего его используют сейчас. (Впрочем, как и PHP, который проложил свой путь из области шаблонизаторов)
Так что перспективы по количеству специалистов мне кажутся умеренными.
Так что перспективы по количеству специалистов мне кажутся умеренными.
Не забывайте еще тот момент, что JS как самостоятельный язык (в том ключе что для него стали нанимать отдельно программистов) выделился совсем недавно, ибо раньше он шел довеском к серверсайду. Отсюда идет следствие что большинство JS гуру так-же отлично знают Ruby/Python/PHP. А это еще + окладу.
Я бы не сказал, что скиллы в резюме нужно просто суммировать в оклад. Да иельзя знать серверсайд совсем не зная клиентской стороны и наоборот.
Если нужен программист, работающий под RoR то его навыки работы с Plone могут быть огромными, но бесполезными — куча локальных скиллов, которые при смене платформы меняют актуальность. Платить JS кодеру за то, что он идеально знает 1С, да нафига, когда поискав можно найти того же, кто его не знает и не захочет этот бонус, который бессмысленен для работодателя.
Имхо, основной плюс к окладу — это насколько сотрудник способен создавать работающие штуки. На js их создавать и тестировать достаточно сложно.
Если нужен программист, работающий под RoR то его навыки работы с Plone могут быть огромными, но бесполезными — куча локальных скиллов, которые при смене платформы меняют актуальность. Платить JS кодеру за то, что он идеально знает 1С, да нафига, когда поискав можно найти того же, кто его не знает и не захочет этот бонус, который бессмысленен для работодателя.
Имхо, основной плюс к окладу — это насколько сотрудник способен создавать работающие штуки. На js их создавать и тестировать достаточно сложно.
А я и не говорю что если человек может получать 80 за серверсайд, и 70 за JS то в сумме он будет иметь 150. Это показывает общий уровень, не более.
Вы же в свою очередь утрируете приводя пример разработчика на RoR со знанием Plone, которые по сути в одной компании редко используются, а еще реже и в одном проекте. Или вообще абстрактный пример с 1С и JS.
Вы же в свою очередь утрируете приводя пример разработчика на RoR со знанием Plone, которые по сути в одной компании редко используются, а еще реже и в одном проекте. Или вообще абстрактный пример с 1С и JS.
Да, я перегнул немного, пытаясь сделать акцент сильнее, хотя зоопарки всякие попадались.
1C и JS вполне могут ужиться, если ищут кодера-эникейщика на поддержку всякого из низшей касты. Чем выше каста (тупо зарплатная), тем важнее, чтобы специалист ровно решал задачи в рамках весьма определенной области. Писать прекрасные клиенты вообще не вникая что там на заднике это совершенно нормальное явление. Есть описание интерфейса I/O + Т.З. и зашибись.
1C и JS вполне могут ужиться, если ищут кодера-эникейщика на поддержку всякого из низшей касты. Чем выше каста (тупо зарплатная), тем важнее, чтобы специалист ровно решал задачи в рамках весьма определенной области. Писать прекрасные клиенты вообще не вникая что там на заднике это совершенно нормальное явление. Есть описание интерфейса I/O + Т.З. и зашибись.
Платить JS кодеру за то, что он идеально знает 1С
Интеграция сервера на NodeJS с 1С? :)
Интеграция сервера на NodeJS с 1С? :)
Непонятно каким боком тезис о сложности языка подтверждается аргументом «схожая с лиспом». Проще лиспа сложно что-то придумать.
Там была правильная мысль, что многие талантливые разработчики тикают с php в сторону того же python'а. Да и за две недели хорошего разработчика не найти, а если получится — то не благодаря php, а вопреки.
Лично я ушёл от php после написанного на нём крупного проекта. Вспоминаю как страшный сон, и более не хочу.
Лично я ушёл от php после написанного на нём крупного проекта. Вспоминаю как страшный сон, и более не хочу.
Спасибо за такую большую статью. Буду ждать пост про Python.
Затянувшаяся миграция с 2-й ветки на 3-ю, юникод, локи интерпретатора, экспрешены, динамическая типизация… Уфф, все равно лучше пока не нашел.
руби? )
Затянувшаяся миграция с 1.8 на 1.9, GIL…
не знаю, о чем именно речь шла в пунктах «юникод» и «экспрешены», динамическая типизация меня не напрягает)
не знаю, о чем именно речь шла в пунктах «юникод» и «экспрешены», динамическая типизация меня не напрягает)
А я вот руби копаю — питон у меня в основном как калькулятор, после того как запостил им ошибку в стандартном пакете «с батарейками», они скинули мне ссылку на более изящный патч, чем мой… который у них уже три месяца пылиться. Правильно — не фиг использовать питон под виндой, да ещё и с не английской кодировкой по умолчанию.
Хотя тут думаю — комплекс профессионала — проблемы питона я знаю и подсознательно боюсь, что повылезают, а об руби я ничего страшного пока не знаю.
Хотя тут думаю — комплекс профессионала — проблемы питона я знаю и подсознательно боюсь, что повылезают, а об руби я ничего страшного пока не знаю.
Я на руби пишу как раз.
Питон юзаю при необходиомсти, но вообще он как-то не пошел у меня: метапрограммирование там кажется на порядок менее естественным, то как применяется его философия меня часто приводит в замешательство, и прочие мелочи…
То есть хороший язык, но не мой =)
И на руби под виндой тоже писать не стоит, насколько мне известно (сам я никогда даже не пробовал).
Питон юзаю при необходиомсти, но вообще он как-то не пошел у меня: метапрограммирование там кажется на порядок менее естественным, то как применяется его философия меня часто приводит в замешательство, и прочие мелочи…
То есть хороший язык, но не мой =)
И на руби под виндой тоже писать не стоит, насколько мне известно (сам я никогда даже не пробовал).
Хабр дебил. По Enter отправляет пост в черновики. И убивает все комментарии. Уж извините.
Переводчику спасибо за труд. Одного не могу понять, зачем переводить очередной батхерд на тему PHP. Все эти вопросы разбирались уже не раз. Те кто давно и профессионально работает с PHP знает про особенности и подводные камни, кому не по нраву перешли на другой язык. Мне сложно представить человека — фаната профи PHP, который писал бы каверзные статьи на темы других языков. Так что это за попытка? Поднять бурление на изъезженную тему или очередная контрпропаганда? Зачем …?
Что ж? Выражу своё мнение. Просто уж очень часто натыкаюсь на древний софт(который нужно поддерживать или переписать), написаный на PHP и испытываю точно такой же батхёрт. Ужасно устал от самопальных фрэймворков на нём же.
Делов то, смените работу и будете натыкаться на оверинжинирнг в джаве или ещё какую-нибудь беду в другом ЯП.
Речь в статье идёт о серьёзных архитектурных проблемах языка, в других ЯП не так всё запущено. Опять же это влияет и на рост языка и на качество кода.
Ну и что это значит то? В чем смысл этого опуса? Всем надо резко перейти на другие языки? Новички не должны учить php или что?
Именно :)
Статья проплачена конкурентами!
Ну давайте, переходите, отдайте мне на поддержку всех своих старых клиентов с проектами на php и забудьте про баттхёрт. Ну это так, ради смеха.
PHP объективно занимает свою нишу на рынке, т.е. отвечает его требованиям. Поэтому все резко никуда не перейдут. Со временем конечно php уступит свое место, но когда это будет… Да и в таком случае, автору и переводчику лучше бы сосредоточиться не на баттхёрте от пхп, а направить свою энергию на развитие питона, руби или от чего они там фанатеют — было бы больше толку и для всех.
Что касается новичков — так это порог вхождения и опять же спрос на пхпбыдлокодеров.
PHP объективно занимает свою нишу на рынке, т.е. отвечает его требованиям. Поэтому все резко никуда не перейдут. Со временем конечно php уступит свое место, но когда это будет… Да и в таком случае, автору и переводчику лучше бы сосредоточиться не на баттхёрте от пхп, а направить свою энергию на развитие питона, руби или от чего они там фанатеют — было бы больше толку и для всех.
Что касается новичков — так это порог вхождения и опять же спрос на пхпбыдлокодеров.
Вот как люди тонко избавляются от конкуренции )))
Я считаю что новички должны знать что есть ещё языки на которых удобно и приятно программировать, ибо большинство людей тупо учит PHP потому что это «модно» и везде пишут что сайты надо разрабатывать только на PHP, а потом не понимают что же они так несчастливы от рутинного написания говнокода. Язык в этом случае тоже имеет значение.
Я согласен, но для этого лучше писать статьи типа «Питон за шесть часов» или «RoR for dummies» и уж никак не «ПХП ЕСТ ДЕТЕЙ».
Сами подумайте, ну прочитает новичок эту простыню по диагонали и что? Да ничего, он все так же пойдет и скачает какой-нибудь вордпресс или друпал и начнет потихоньку делать свой первый говносайт. Среда не располагает к изучению других языков, хоть пять статей напиши.
Сами подумайте, ну прочитает новичок эту простыню по диагонали и что? Да ничего, он все так же пойдет и скачает какой-нибудь вордпресс или друпал и начнет потихоньку делать свой первый говносайт. Среда не располагает к изучению других языков, хоть пять статей напиши.
Не надо фатализма. Всё будет хорошо.
Зависит от новичка. Почему не начать с питона?
Начинайте с чего угодно. Речь о среде и о том, что вероятней всего новичок в первую очередь наткнется на PHP со всеми вытекающими, такова правда жизни. В таком контексте статья выглядит абсолютно бестолково.
Потому что вордпресс или друпал можно просто залить на шаред-хостинг за пару баксов, да и на вдске не проблема поднять, не говоря о денвере? И можно «хелловорд» во «все интернеты» выложить без проблем?
Да, а здесь настроить хостинг очень сложно!
И вообще ДЕНВЕР поставить гораздо легче чем какой-то тупой wamp.
И вообще ДЕНВЕР поставить гораздо легче чем какой-то тупой wamp.
Лол, по питону обычно рекомендуют не «питон за шесть часов», а «Dive in the python» и PEP-ы.
А за 6 часов лучше действительно PHP изучить для галочки и забыть.
А за 6 часов лучше действительно PHP изучить для галочки и забыть.
По-моему как раз наоборот, везде пишут, что НЕ надо разрабатывать на PHP, что Python/Ruby/NodeJS это модно и круто, но дешёвый хостинг и огромное количество готового кода берёт своё.
как зачем? зависть =) и жадность =)
Мне кажется, это просто страдание человека, не безразличного к вопросу дизайна языков о том, что ЭТО смогло стать лидером рынка.
Это же как надо ненавидеть PHP, чтобы столько написать :-D
Я гналась за вами три километра, чтобы сказать, как вы мне безразличны! © не знаю откуда
Принцесса
Три дня я гналась за вами. Только в бурю потеряла ваш след, встретила охотника и пошла к нему в ученики.
Медведь
Вы три дня гнались за мной?
Принцесса
Да! Чтобы сказать, как вы мне безразличны.
Шварц, «Обыкновенное чудо»
Три дня я гналась за вами. Только в бурю потеряла ваш след, встретила охотника и пошла к нему в ученики.
Медведь
Вы три дня гнались за мной?
Принцесса
Да! Чтобы сказать, как вы мне безразличны.
Шварц, «Обыкновенное чудо»
«Обыкновенное чудо».
«Я бежала за вами три дня и три ночи, чтобы сказать вам как вы мне безразличны». Цитата на память, могу чуть исказить.
«Я бежала за вами три дня и три ночи, чтобы сказать вам как вы мне безразличны». Цитата на память, могу чуть исказить.
А мне ссылочки понравились, полистаю на досуге: )
Пришла мысль, она может быть не в тему, но выскажу.
Наверняка, можно написать такую же статью про русский язык.
Наверняка, можно написать такую же статью про русский язык.
- множество заимствований из других языков (бордюр, компьютер ...);
- множество исключений (оловянный, деревянный и т.п.);
- множество слов, в которых нельзя проверить согласные ударением;
- существуют слова, которые нельзя поставить в определённую форму(победю, пылесосу ...);
- … ;
а чем «пылесошу» плохо?
Понимаете ли, естественные языки развиваются эволюционно. И только по этой причине имеют столько исключений. В то время как искусственный язык проектируется. Хотя мне иногда, что в случае PHP это не совсем верно :)
* мне иногда кажется
Я думаю, что тут можно с уверенностью сказать, что PHP изначально не проектировался вообще.
Не стоит рассматривать естественные языки как нечто совершенное.
Почитайте хотя бы юридические тексты — имхо, неплохая аналогия «программированию» на естественном языке.
Почитайте хотя бы юридические тексты — имхо, неплохая аналогия «программированию» на естественном языке.
И ещё, многие любят русский язык за его исключительность…: )
Это можно написать про любой естественный язык. Во всех есть странности, несогласованности и различные недостатки…
Да уж, это вам не эсперанто, но почему-то мало желающих его изучать, парадокс человеческой психики.
Автор маньяк. Да и переводчик
Кто может объяснить заголовок статьи? Хотел перевести эту статью просто так, для себя. Но сдался на заголовке. Дословно переводить не хотелось.
Фрактал — самоподобная фигура, то есть PHP — плох по дизайну весь так же, как плоха по дизайну каждая его составляющая?
Фрактал — самоподобная фигура, то есть PHP — плох по дизайну весь так же, как плоха по дизайну каждая его составляющая?
Берем статью, делаем выдержки, и… задаем вопросы на собеседовании ;)
даже на таких граблях
сколько раз падали. Вопросы мот по круче патернов программирования будут, и многая специфика языка открывается.
даже на таких граблях
"foo" == TRUE, и "foo" == 0… но, конечно же TRUE != 0.сколько раз падали. Вопросы мот по круче патернов программирования будут, и многая специфика языка открывается.
Не так давно, я всерьез собрался менять 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.
Статья слишком далека от реальности.
В реальных проектах с этими проблемами не сталкиваешься.
>Поэтому следующий код:
>
>$arg = 'T';
>$vehicle = ( ( $arg == 'B' )? 'bus':
> ( $arg == 'A' )? 'airplane':
> ( $arg == 'T' )? 'train':
> ( $arg == 'C' )? 'car':
> ( $arg == 'H' )? 'horse':
> 'feet' );
>echo $vehicle;
>выведет horse.
Вот за такой код в реальном проекте нужно руки отрывать. В реальном проекте будет использован switch-case.
Ну двойная вложенность-то может быть? И проблема имеет место быть. А пример выполнен как гипербола, но смысл проблемы он не искажает.
т.е. использование старого нерекомендуемого модуля (mysql) или неверное использование новых инструментов (mysqli, pdo etc) новичками — это вина языка?
Хорошо так говорить, когда другие языки могут учиться на чужих ошибках. Данный модуль создавался давно и расчитан был на старый функционал и защиту скриптов самим программистом.
В данном случае модулем до сих пор пользуются огромное количество программистов, либо новичков, либо тех, кто ведет старые проекты. PHP не может взять и выкинуть модуль. Разработчики плавно отучают пользователей от него (первый этап — только обновления безопасности и обновление документации, дальше — больше).
Поэтому 1) вина в появлении — может быть, но такое есть во всех языках — программист может выстрелить в ногу тысячами способов.
2) PHP не поддерживает больше данный модуль, только обновления безопасности
Поэтому в целом я все равно считаю, что подобные вопросы от новичков — не вина языка.
В данном случае модулем до сих пор пользуются огромное количество программистов, либо новичков, либо тех, кто ведет старые проекты. PHP не может взять и выкинуть модуль. Разработчики плавно отучают пользователей от него (первый этап — только обновления безопасности и обновление документации, дальше — больше).
Поэтому 1) вина в появлении — может быть, но такое есть во всех языках — программист может выстрелить в ногу тысячами способов.
2) PHP не поддерживает больше данный модуль, только обновления безопасности
Поэтому в целом я все равно считаю, что подобные вопросы от новичков — не вина языка.
Хорошо так говорить, когда другие языки могут учиться на чужих ошибках.Я ни с кем ни о чём не спорю, однако отмечу, что Пайтон появился в 1991, Руби и PHP в 1995.
Автор указывает, что документация тоже не сахар :)
Ну это спорный вопрос, если человек даже не задумывается над безопасностью своего кода… Такое можно написать на любом языке, вот вам на руби:
@user = User.find_by_username("#{params[:username]}")
Да, правильней написать можно например так:
Тогда переменная не летит напрямую в БД, как в первом варианте. Говнокод — всегда говнокод.
User.where("username = ?", params[:username])
Тогда переменная не летит напрямую в БД, как в первом варианте. Говнокод — всегда говнокод.
Не могу судить про новичков в руби, сам такой) Но по личному впечатлению, само комьюнити как-то подталкивает искать верные и красивые решения, покрывать код тестами.
в творениях на Руби говнокода ещё побольше будет. Но не потому, что язык плохой, а потому, что есть 100500 способов сделать одно и то же действие. И новичку нужно время, чтобы попробовать их все и придти к своему стилю.
Частично соглашусь, увлёкшись метапрограммированием можно страшного наворотить :)
А вот обилие вариантов делания одного и того же на самом деле огромнейший плюс, позволяющий писать DSL'и и в конкретных ситуациях получать очень компактный выразительный код.
Взять тот же RSpec или что-то подобное Person.where { (name =~ 'Ernie%') & (salary < 50000) | (salary > 100000) }
А вот обилие вариантов делания одного и того же на самом деле огромнейший плюс, позволяющий писать DSL'и и в конкретных ситуациях получать очень компактный выразительный код.
Взять тот же RSpec или что-то подобное Person.where { (name =~ 'Ernie%') & (salary < 50000) | (salary > 100000) }
Языки? Посадите новичка писать «сайт» на чистом руби без фреймворков — он вам и не такого напишет. Ну или давайте сравнивать честно и поставить на сторону PHP какой-нибудь приличный фреймворк.
Первый вариант тоже правильный и не приводит к SQL injection.
Приводит вот это:
User.where(«username = '#{params[:username]}'»)
Приводит вот это:
User.where(«username = '#{params[:username]}'»)
Да, только что проверил. Но суть не в том как конкретно работают методы find_by_* или where AR'a, а в том что плохой код можно написать на любом ЯПе, что и было замечено.
Конечно, с этим полностью согласен.
Но тут важны скорее не крайние случаи, а какой-то «средний» код. То есть то, что пишет человек не особенно задумываясь о хорошести, когда ему надо просто решить задачу.
И если в Ruby/Python человека изначально окружают в целом хорошие решения, то он скорее всего будет использовать подобные хорошие решения, потому что они рядом.
А если вокруг большинство решений плохие, то и новые будут получаться такими же.
Кроме того, я смутно помню, что когда я еще работал с PHP, то делать сколько-то больой проект хорошо там было просто неудобно. С переходом на руби стало на порядок легче. Но при этом делать на RoR одну форму отправки письма — это оверкилл, тут PHP как раз идеален, наверное.
То есть, по всей видимости, некоторые особенности языка/фреймворков хорошо работают в своей нише, а в другой приводят к хаосу.
И в этом смысле, PHP разработан не для тех приложений, где он сейчас повсеместно используется.
Если несколько утрировать: есть замечательный язык ЛОГО, но это не значит, что на нем нужно писать интерфейсы к БД.
Но тут важны скорее не крайние случаи, а какой-то «средний» код. То есть то, что пишет человек не особенно задумываясь о хорошести, когда ему надо просто решить задачу.
И если в 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. Равным — вполне возможно.
Но как мне кажется, причины такого решения лежат уже не в каких-то преимуществах 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 — возможно, абстрактному разработчику будет проще. Я бы всё равно выбрал синатру, просто в целях унификации основных проектов с личными.
С шаред хостингами всё верно. Но если заказчик не может раскошелиться на 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
pry(main)> User.find_by_nickname(«test'\»")
User Load (0.2ms) SELECT `users`.* FROM `users` WHERE `users`.`nickname` = 'test\'\"' LIMIT 1
парсер кавычки побил
User.find_by_nickname("test'\"")
Отрицаете 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 отстрелить себе ногу не выйдет.
В местах, намеренно предназначенных для вставки голого sql, конечно же ничего само не будет экранироваться.
А в дефолтных ситуациях с User.where(:username => params[:username]) или с выражениями на синтаксисе metawhere/squeel отстрелить себе ногу не выйдет.
Интересно что он скажет про JavaScript :)
JS неплохой объектный язык, я не понимаю вашего сарказма.
А что тут непонятного? В нем тоже есть неочевидное поведение в некоторых моментах.
wtfjs.com/ — вот целая куча всякого, типа того, что описано в этом топике про ПХП
В JS ярчайшие проблемы с архитектурой.
Имеющие, кстати, теже самые корни, что и у PHP — делали изначально одно, а потом периодически поверх накручивали совершенно другое.
Имеющие, кстати, теже самые корни, что и у PHP — делали изначально одно, а потом периодически поверх накручивали совершенно другое.
Да ладно… взять ту же область видимости переменных ограничиваемой функциями — я потерял много часов жизни пока с этим не разобрался. Бредовая идея вообще.
Неоднозначность strict синтаксиса, то есть он вроде бы есть, но им мало кто знает как пользоватся.
ООП непривычное, причём до такой степени что многие эмулируют привычное ООП создавая тормоза и путанницу.
Постоянные заботы об преждевременной оптимизации, что портит нас как программистов. Ибо в firefox — unshift невероятно медленный, а в других браузерах всё ок, вот и тратишь время на всякую чепуху…
Однопоточный интерпретатор, что не является таким уж и большим благом.
да можно ещё продолжать, просто время тратить неохота… не в тему распыляться…
Неоднозначность strict синтаксиса, то есть он вроде бы есть, но им мало кто знает как пользоватся.
ООП непривычное, причём до такой степени что многие эмулируют привычное ООП создавая тормоза и путанницу.
Постоянные заботы об преждевременной оптимизации, что портит нас как программистов. Ибо в firefox — unshift невероятно медленный, а в других браузерах всё ок, вот и тратишь время на всякую чепуху…
Однопоточный интерпретатор, что не является таким уж и большим благом.
да можно ещё продолжать, просто время тратить неохота… не в тему распыляться…
Я это понял и разобрался, просто спросили про типичные проблемы языка, я их частично озвучил. И с этой проблемой сталкивались все кого я знаю, причём не все они разобрались и пишут ужаснейший говнокод на JS и по сей день.
Почему же, я тут вижу логическое несоответствие.
Что есть по сути функция?
Это именованный блок кода.
Так почему же именованный блок кода создают «область действия переменной», а обычные блоки кода нет?
Про это часть перевода автора топика, кстати, посвящена, хе-хе…
Что есть по сути функция?
Это именованный блок кода.
Так почему же именованный блок кода создают «область действия переменной», а обычные блоки кода нет?
Про это часть перевода автора топика, кстати, посвящена, хе-хе…
Несмотря на это в джаваскрипт есть переменные которые являются достоянием парадигмы императивного программирования и работают они не так как везде и внятного оправдание именно такого способа их работы я не вижу.
В том же эрланге отлично обходятся без переменных вообще (точнее там есть альясы, но изменять их значение нельзя), вот это ПРЕДСКАЗУЕМОЕ поведение функционального ЯП. А в джаваскрипте непойми что.
В том же Perl область видимости переменных ограничивается блоками и никакого дискомфорта от функционального подхода при программировании на Perl лично я не испытал.
P.S. Ещё раз выделю мысль: «вы так и не объяснили, почему так как сделали в JS — правильно и логично».
В том же эрланге отлично обходятся без переменных вообще (точнее там есть альясы, но изменять их значение нельзя), вот это ПРЕДСКАЗУЕМОЕ поведение функционального ЯП. А в джаваскрипте непойми что.
В том же Perl область видимости переменных ограничивается блоками и никакого дискомфорта от функционального подхода при программировании на Perl лично я не испытал.
P.S. Ещё раз выделю мысль: «вы так и не объяснили, почему так как сделали в JS — правильно и логично».
В cpp и ещё сотне языков блоки создают отдельный контекст, в питоне и ещё сотне не создают. какая разница, причём тут логично?
Логично что и именованный блок и анонимный по сути одно и тоже, потому разумно ожидать что и с переменными они работают одинаково.
P.S. кстати, а как в питоне дела обстоят с этим?
P.S. кстати, а как в питоне дела обстоят с этим?
но функция не просто именованный блок (к тому же она может и неименованной быть :) ).
функция объект, её можно куда-нибудь передавать, вызывать и т.д. простой блок нельзя. и контекст, соответственно, создаётся в момент вызова функции.
функция объект, её можно куда-нибудь передавать, вызывать и т.д. простой блок нельзя. и контекст, соответственно, создаётся в момент вызова функции.
Про объект согласен, это уже похоже на разумное объяснение такого поведения, но опять же могли бы сделать блоки кода анонимными функциями (и тоже объектами), тогда бы эта неоднозначность работала бы как в си подобных языках, разве нет?
Функция не просто именованный блок:
— у неё могут быть параметры
— она может быть быть вызвана
— она является объектом, с прототипом, со всеми вытекающими
— у неё могут быть параметры
— она может быть быть вызвана
— она является объектом, с прототипом, со всеми вытекающими
А в питоне с этим тоже не без приколов:
«чтение переменной» будет обращаться к внешней области видимости.
«присваивание переменной» («создание алиаса») формирует новую локальную переменную.
Из-за этого такие заморочки:
stackoverflow.com/questions/370357/python-variable-scope-question
«чтение переменной» будет обращаться к внешней области видимости.
«присваивание переменной» («создание алиаса») формирует новую локальную переменную.
Из-за этого такие заморочки:
stackoverflow.com/questions/370357/python-variable-scope-question
но этот язык изначально был расчитан на нубов, ещё больше чем PHP. Там даже точки с запятыми сделали необязательными, чтобы прогеры-верстальщики не перенапряглись.
Область видимости переменной — вся функция, а не блок? Такая идея в функциональных языках?
Ежики плакали, кололись...? Зачем форкать «старый херовый PHP»?
Нет, ну швейцарский нож классный инструмент, но молоток лучше гвозди забивает, а пила лучше дерево пилит. Я к тому, что как инструмент создания динамических веб сайтов, PHP вместе со всеми своими косяками на ура работает, и все эти ваши интернеты тому доказательство.
Ого, у кого-то серьезный баттхёрт. Ну и ладно, пойду дальше писать свои дэйтинги…
PHP плох тут, тут и тут. Не поверите, но разработчики PHP все это знают.
А решение проблемы где?
1) Перейти на другой язык? — Кто может себе это позволить — того не держут, кому важны плюсы PHP пока останутся на нем (сообщество/поддержка/«много из коробки»/фреймворки/рынок труда/...)
2) Исправить все сразу в PHP — моментальная потеря всех вышеперечисленных пунктов из-за полной потери обратной совместимости.
3) Постепенное пусть и медленное исправление недостатоков проектирования языка с разумными сроками «на обновление модулей и проектов»для сообщества и программистов.
Я выбираю третий вариант, а другие пусть разводят холивары.
А решение проблемы где?
1) Перейти на другой язык? — Кто может себе это позволить — того не держут, кому важны плюсы PHP пока останутся на нем (сообщество/поддержка/«много из коробки»/фреймворки/рынок труда/...)
2) Исправить все сразу в PHP — моментальная потеря всех вышеперечисленных пунктов из-за полной потери обратной совместимости.
3) Постепенное пусть и медленное исправление недостатоков проектирования языка с разумными сроками «на обновление модулей и проектов»для сообщества и программистов.
Я выбираю третий вариант, а другие пусть разводят холивары.
1) Сообщества и поддержка есть и в других языках, «много из коробки» невозможно использовать и в статье довольно точно написано почему.
Фреймворки у PHP по удобству не особо-то могут соревноваться (возьмите в других языках Sinatra подобные фреймворки, например, я когда людям показываю чуть в обморок не падают от того как рам роутинг сделан) из-за своей монстроидальности из-за проблем языка. Единственное чего много у PHP — это готовые CMS, и они смотряться достойнее чем у конкурентов, но лично мне CMSки готовые не очень удобны, очень много ограничений и получается код за который часто бывает очень стыдно. Рынок труда — тут спорный вопрос ибо хорошие вакансии есть почти для любых ЯП.
2) Согласен и это-то и придаёт оттенок безнадёжности к развитию PHP.
3) А вот тут всё очень сложно, ибо та куча непонятно чего что есть у PHP так и будет тянуться за ним. И в обозримое десятилетие не думаю что PHP как-то качественно сможет измениться из-за этого. Тем более PHP стал эволюционировать в сторону Java (который в моём понимании для метапрограммирования и расширения синтаксиса не особо подходит (поправьте меня, если я не прав)) что загоняет его в тупик.
Фреймворки у PHP по удобству не особо-то могут соревноваться (возьмите в других языках Sinatra подобные фреймворки, например, я когда людям показываю чуть в обморок не падают от того как рам роутинг сделан) из-за своей монстроидальности из-за проблем языка. Единственное чего много у PHP — это готовые CMS, и они смотряться достойнее чем у конкурентов, но лично мне CMSки готовые не очень удобны, очень много ограничений и получается код за который часто бывает очень стыдно. Рынок труда — тут спорный вопрос ибо хорошие вакансии есть почти для любых ЯП.
2) Согласен и это-то и придаёт оттенок безнадёжности к развитию PHP.
3) А вот тут всё очень сложно, ибо та куча непонятно чего что есть у PHP так и будет тянуться за ним. И в обозримое десятилетие не думаю что PHP как-то качественно сможет измениться из-за этого. Тем более PHP стал эволюционировать в сторону Java (который в моём понимании для метапрограммирования и расширения синтаксиса не особо подходит (поправьте меня, если я не прав)) что загоняет его в тупик.
>> Фреймворки у PHP по удобству не особо-то могут соревноваться.
Приведите примеры, пожалуйста? Пока выглядит очень голословно и субъективно.
Приведите примеры, пожалуйста? Пока выглядит очень голословно и субъективно.
ну я привёл пример — покажите мне достойный PHP фреймворк с синатра-подобным роутингом, ну или вообще «удобным роутингом»
Я первый попросил )
Допустим, роутинг ZF мне кажется не менее удобным, чем роутинг синатры (честно прочитал главу про него в туториале).
Допустим, роутинг 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, которая ещё и быстрее к тому же.
$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.
Имеете ввиду исполнение уже скомпилированного байткода? Так для пхп тоже есть тот же eaccelerator.
Благо в таком виде его и не принято использовать (если маршрут не один).
У меня, например, это yaml-файл примерно такого вида:
У меня, например, это yaml-файл примерно такого вида:
news:
type: *rroute
route: /news/:section
defaults:
controller: news
action: index
section: index*там были ямловские отступы, но съелись в процессе отправки
ну вот я про то и говорю — парсинг текстовых файлов + адское ООП и это программирование вашей мечты?
Опять же, для большого проекта куда ни шло, а вот для небольшого или средней паршивости сайта(какой-нибудь веб сайт с несложным каталогом и прайсом) эти десятки файлов конфигов и куча лишнего кода — совсем никак не оправданы.
Для меня, кстати, ваш выбор не очень понятен, я посмотрел как пишут на Zend — это ужасно, есть же Yii и Symfony, там хотя бы бутстрап и всё отстроено из коробки, записал маршруты и создал контроллеры — вуаля.
Так вот кроме роутинга внутри приходится писать кучу кода, который в других языках либо как-то автоматизируется (намного меньшим количеством кода опять же), либо его просто меньше.
А уж всякие неработающие new Object->method() с ничего не значащими ошибками это вообще за гранью добра и зла…
Опять же, для большого проекта куда ни шло, а вот для небольшого или средней паршивости сайта(какой-нибудь веб сайт с несложным каталогом и прайсом) эти десятки файлов конфигов и куча лишнего кода — совсем никак не оправданы.
Для меня, кстати, ваш выбор не очень понятен, я посмотрел как пишут на 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!
Вполне удобно, но только для маленьких проектов на мой взгляд, ибо чтобы изменить роутинг надо будет файлы переименовывать, это на мой взгляд менее удобно чем один файлик поправить, а как там динамические маршруты строятся (где вместо какого-либо уровня может быть выбор из нескольких вариантов)?
Опять же, вы показали что проблема удобности в PHP решилась не какими то синтаксическими возможностями языка, а олдскульным способом с файлами которым можно хоть в ассемблере решить таким же способом.
Покажите пожалуйста, чем силён PHP именно как язык программирования, как он помогает решать проблемы?
Да как платформа он сейчас силён как никогда, но как ЯП он ужасен и улучшить его не превращая его в другой ЯП не видно как.
Также Вы утверждали, что «в PHP это особенно неуклюже выглядит по сравнению с другими ЯП», а в ЯП это на самом деле вообще никак не выглядит — это вопрос фреймворка. CGI-программа на чистом питоне выглядит гораздо более неуклюже, чем любой PHP-скрипт.
Тут вы не совсем правы, ибо, возможности и удобство работы с фреймворком зависит также и от возможностей языка. Если для того чтобы выбрать из массива элементы большие 5, например, мне приходиться писать 3-5 строк кода — это проблема, в том же Perl (из которого PHP вырос) это делалось в малюсенькую строчку
grep $_ > 5, @arr
, в Ruby и Python это делается не сложнее. И ответьте пожалуйста ещё на один вопрос: «это просто поправить в PHP, без изменения его концепции?»
Покажите пожалуйста, чем силён PHP именно как язык программирования, как он помогает решать проблемы?
Да как платформа он сейчас силён как никогда, но как ЯП он ужасен и улучшить его не превращая его в другой ЯП не видно как.
Также Вы утверждали, что «в PHP это особенно неуклюже выглядит по сравнению с другими ЯП», а в ЯП это на самом деле вообще никак не выглядит — это вопрос фреймворка. CGI-программа на чистом питоне выглядит гораздо более неуклюже, чем любой PHP-скрипт.
Тут вы не совсем правы, ибо, возможности и удобство работы с фреймворком зависит также и от возможностей языка. Если для того чтобы выбрать из массива элементы большие 5, например, мне приходиться писать 3-5 строк кода — это проблема, в том же Perl (из которого PHP вырос) это делалось в малюсенькую строчку
grep $_ > 5, @arr
, в Ruby и Python это делается не сложнее. И ответьте пожалуйста ещё на один вопрос: «это просто поправить в PHP, без изменения его концепции?»
Подсказка HTML::Mason — тот же ПХП вид сбоку. Только очень шустрый, перловый и со средствами организации проектов.
Минусы не прост в настройке — по крайней мере ветка 1.x. Ставился так бы легко как ПХП… на нём было бы море говнокода.
Минусы не прост в настройке — по крайней мере ветка 1.x. Ставился так бы легко как ПХП… на нём было бы море говнокода.
Ну это неудивительно — если язык считает, что вы всегда сами знаете, что делаете, то… эту ответственность надо оправдывать, а не злоупотреблять. А злоупотреблять проще. Оно же работает… как-то…
Питон, кстати, после перла бесил неимоверно. Он то как раз считает. что вы не знаете что делаете, поэтому надо постоянно кричать «сюда нэ хади, снег бошка упадёт...» (с)
Блин, да не хочу я чтобы исчезал PHP и код написанный на нём. Это невозможно и нецелесообразно.
Я хочу чтобы люди задумались о том, что на данный момент PHP уже не так актуален и не так удобен для разработки и я считаю что путь который выбрали для эволюции PHP не перспективен (хотя и вполне логичен). Потому людям полезно знать его слабости и развиваться вширь (т.е. изучить другие ЯП хотя бы для ознакомления)).
И автор оригинала, да и перевода, да и я в том числе не злодеи которые захотели смерти PHP, а просто энтузиасты, которым хочется чтобы люди хоть чуть-чуть задумались о том что программировать можно (и НУЖНО) с удовольствием. И на данный момент это вполне возможно.
P.S. мне вообще не нравиться Python по некоторым соображениям, я за Perl. Но в ближайший год изучу и Python тоже, чтобы знать что я теряю (а может и не теряю =) )
P.P.S. Perl-CGI — откровенно неудачный способ делать веб-сайты, неудивительно что он тогда проиграл PHP, но из-за своей гибкости как ЯП Perl опять получил очень качественный синатра подобный фреймворк Mojolicious, по простоте и изяществу которого лично я у PHP конкурентов не вижу.
P.P.P.S. И писать на чистом PHP сайты сейчас вовсем не удобно (и небезопасно).
Я хочу чтобы люди задумались о том, что на данный момент PHP уже не так актуален и не так удобен для разработки и я считаю что путь который выбрали для эволюции PHP не перспективен (хотя и вполне логичен). Потому людям полезно знать его слабости и развиваться вширь (т.е. изучить другие ЯП хотя бы для ознакомления)).
И автор оригинала, да и перевода, да и я в том числе не злодеи которые захотели смерти PHP, а просто энтузиасты, которым хочется чтобы люди хоть чуть-чуть задумались о том что программировать можно (и НУЖНО) с удовольствием. И на данный момент это вполне возможно.
P.S. мне вообще не нравиться Python по некоторым соображениям, я за Perl. Но в ближайший год изучу и Python тоже, чтобы знать что я теряю (а может и не теряю =) )
P.P.S. Perl-CGI — откровенно неудачный способ делать веб-сайты, неудивительно что он тогда проиграл PHP, но из-за своей гибкости как ЯП Perl опять получил очень качественный синатра подобный фреймворк Mojolicious, по простоте и изяществу которого лично я у PHP конкурентов не вижу.
P.P.P.S. И писать на чистом PHP сайты сейчас вовсем не удобно (и небезопасно).
И писать на чистом PHP сайты сейчас вовсем не удобно (и небезопасно).
После второго приложения хочешь, не хочешь, а получаешь свой фреймворк (при соблюдении некоторых простых условий, типа тестируемого кода и соблюдения DRY). И писать сайты на чистом Python/Ruby/… я б не сказал, что удобнее чем на PHP, как минимум без «прокладки» типа WSGI/Rack.
После второго приложения хочешь, не хочешь, а получаешь свой фреймворк (при соблюдении некоторых простых условий, типа тестируемого кода и соблюдения DRY). И писать сайты на чистом Python/Ruby/… я б не сказал, что удобнее чем на PHP, как минимум без «прокладки» типа WSGI/Rack.
P.S. мне вообще не нравиться Python по некоторым соображениям, я за Perl. Но в ближайший год изучу и Python тоже, чтобы знать что я теряю (а может и не теряю =) )
Ну что, изучили питон?
Вот это вы вспомнили =)
Да, с тех пор я и с Python познакомился (даже поддерживал несколько проектов на нём на фрилансе и несколько плагинов написал). А также с Erlang/Elixir, сейчас Haskell и Rust изучаю.
Про Perl могу сказать вот что: как только разработка становится командной все эти документированные багофичи парализуют прогресс (и к PHP это относиться в том числе). Его я больше не использую, ни для чего.
Python — очень неплохой и понятный язык программирования, в некоторых областях он монополист (ML и BigData). Так или иначе с ним приходиться сталкиваться и опыт в основном положительный.
Мне всё же больше нравится Ruby для веб разработки и написания инструментов, он более консистентный + разработчики на нём любят удобные интерфейсы использовать, ну и в целом им не чуждо прекрасное + лучшая поддержка unicode среди всех языков (японцы жеж) =)
Самый чемпион по сложности веб фреймворков для меня — Haskell, причём, сам синтаксис и основополагающие концепции оказались проще чем предполагалось, а вот простейшее API сделать за вечер мне далось невероятной болью и страданиями (там надо что-то принципиально новое придумать), для сравнения на Elixir + Phoenix за полчаса с нуля написал приложение, что меня очень сильно удивило.
Да, с тех пор я и с Python познакомился (даже поддерживал несколько проектов на нём на фрилансе и несколько плагинов написал). А также с Erlang/Elixir, сейчас Haskell и Rust изучаю.
Про Perl могу сказать вот что: как только разработка становится командной все эти документированные багофичи парализуют прогресс (и к PHP это относиться в том числе). Его я больше не использую, ни для чего.
Python — очень неплохой и понятный язык программирования, в некоторых областях он монополист (ML и BigData). Так или иначе с ним приходиться сталкиваться и опыт в основном положительный.
Мне всё же больше нравится Ruby для веб разработки и написания инструментов, он более консистентный + разработчики на нём любят удобные интерфейсы использовать, ну и в целом им не чуждо прекрасное + лучшая поддержка unicode среди всех языков (японцы жеж) =)
Самый чемпион по сложности веб фреймворков для меня — Haskell, причём, сам синтаксис и основополагающие концепции оказались проще чем предполагалось, а вот простейшее API сделать за вечер мне далось невероятной болью и страданиями (там надо что-то принципиально новое придумать), для сравнения на Elixir + Phoenix за полчаса с нуля написал приложение, что меня очень сильно удивило.
Спасибо за развернутый ответ.
Про Perl могу сказать вот что: как только разработка становится командной все эти документированные багофичи парализуют прогресс (и к PHP это относиться в том числе). Его я больше не использую, ни для чего.
Как именно? Работал в разных перловых командах, не замечал.
Ну значит мне не везло с командами или вам везло чуть больше. К Perl у меня всё же тёплые воспоминания, из него вынес ощущение свободы, что можно писать одно и тоже разными способами, умение всё что угодно сделать регулярками и понимание скалярного и списочного контекста данных, но код на нём так и не пишу.
Покажите пожалуйста, чем силён PHP именно как язык программирования, как он помогает решать проблемы?
А он всегда был силён именно как платформа. Глубокой интеграцией из коробки с веб-серверами прежде всего, ну и embeded синтаксисом (хотя теперь это стараются обходить зачастую). По сути, PHP уже представляет собой низкоуровневый веб-фреймворк.
Ещё плюс по сравнению с python/ruby: Си/«Си с классами»-подобный синтаксис (сам его выбрал именно за это вместо Perl, о серверном JS речи не было тогда).
А он всегда был силён именно как платформа. Глубокой интеграцией из коробки с веб-серверами прежде всего, ну и embeded синтаксисом (хотя теперь это стараются обходить зачастую). По сути, PHP уже представляет собой низкоуровневый веб-фреймворк.
Ещё плюс по сравнению с python/ruby: Си/«Си с классами»-подобный синтаксис (сам его выбрал именно за это вместо Perl, о серверном JS речи не было тогда).
Дык большинство проектов как раз маленькие. Просто ай-тишники этого незамечают, так как занимаются в основном проктами от среднего. А всякие чебуречные, продавцы сигарет поштучно и прочая «мелочь»… которых миллионы.
Спасибо большое за перевод. Сам на питоне пишу, но было очень интересно почитать.
Готов подписаться под каждым словом
Почти все факты в статье верно изложены. Но:
1. Php развивался эволюционно и почти с нуля. Таким образом, большинство нелогичных вещей — это плата за совместимость с прошлыми версиями (и с прошлыми архитектурными ошибками, которые пустили корни). Благодаря этой совместимости php во многом и обрел свою популярность. Тут можно сравнить с microsoft (быги статьи тут про то, какие им приходится расставлять костыли иаде совместимостью с какой-нибудь windows 95 до сих пор).
2. К счастью, на реальной практике приходится сталкиваться менее чем с половиной из указанных несуразностей (т.е. больше половины вещей — хоть и кривы, но очень редко применяются).
3. Подробная документация и большое комьюнити многое компенсируют. По-моему, в этой части php наголову выше большинства других языков.
4. Массовая аудитория программистов имеет тот язык, который заслуживает. Увы, но со статистикой не поспоришь. (Сейчас я за это минусов огребу, знаю.)
5. Где бы сейчас была отрасль веб-программирования, если бы не php? Далеко и глубоко. Ваш 90-летний дед тоже может сейчас противно шамкать и плеваться за столом, но это не умаляет того, что он брал Берлин во время ВОВ.
5. Многие из оставшихся вещей хоть и звучат в теории страшно, но на практике почему-то оказываются почти безобидными (например, фатал ерроры, локальные переменные, инклюды). Сам удивляюсь, почему практика так далеко отстоит от теории здесь.
Но, безусловно, безобразных вещей все равно хватает. Человек, который изучает php в первый раз, а не рос вместе с ним, с самых ранних версий, ну никак не сможет для себя это оправдать. В этом автор совершенно прав. Если выбирать, учить китайский или учить английский, то лучше учить английский — хотя китайцев и больше. Но если вы — с рождения китаец, то это правило, очевидно, не работает.
1. Php развивался эволюционно и почти с нуля. Таким образом, большинство нелогичных вещей — это плата за совместимость с прошлыми версиями (и с прошлыми архитектурными ошибками, которые пустили корни). Благодаря этой совместимости php во многом и обрел свою популярность. Тут можно сравнить с microsoft (быги статьи тут про то, какие им приходится расставлять костыли иаде совместимостью с какой-нибудь windows 95 до сих пор).
2. К счастью, на реальной практике приходится сталкиваться менее чем с половиной из указанных несуразностей (т.е. больше половины вещей — хоть и кривы, но очень редко применяются).
3. Подробная документация и большое комьюнити многое компенсируют. По-моему, в этой части php наголову выше большинства других языков.
4. Массовая аудитория программистов имеет тот язык, который заслуживает. Увы, но со статистикой не поспоришь. (Сейчас я за это минусов огребу, знаю.)
5. Где бы сейчас была отрасль веб-программирования, если бы не php? Далеко и глубоко. Ваш 90-летний дед тоже может сейчас противно шамкать и плеваться за столом, но это не умаляет того, что он брал Берлин во время ВОВ.
5. Многие из оставшихся вещей хоть и звучат в теории страшно, но на практике почему-то оказываются почти безобидными (например, фатал ерроры, локальные переменные, инклюды). Сам удивляюсь, почему практика так далеко отстоит от теории здесь.
Но, безусловно, безобразных вещей все равно хватает. Человек, который изучает php в первый раз, а не рос вместе с ним, с самых ранних версий, ну никак не сможет для себя это оправдать. В этом автор совершенно прав. Если выбирать, учить китайский или учить английский, то лучше учить английский — хотя китайцев и больше. Но если вы — с рождения китаец, то это правило, очевидно, не работает.
Увы, но со статистикой не поспоришь.Какую вы статистику подразумеваете? Скилла кодинга среди программистов?
Массовая аудитория программистов имеет тот язык, который заслуживает.Раскройте это утверждение подробнее. Не вижу в нём логики.
Где бы сейчас была отрасль веб-программирования, если бы не php? Далеко и глубоко.Если бы у бабушки был...
Еще один очень важный момент, касающийся эволюции языка: у PHP в отличие от C++ нет Страуструпа, который бы объяснил, что всё так и должно быть, и по-другому быть не может :)
И Гвидо, который единолично определял вектор развития
Или хотябы Стивенсона, который написал бы книжку о ПХП.
С его фантастически научным и экспериментальным подходом. Когда разработчики железа (вроде как даже из cisco) потом говорили «В стандарте было написано неопределенно, но у Стивенсона написано было так. Мы так и сделали.»
С его фантастически научным и экспериментальным подходом. Когда разработчики железа (вроде как даже из cisco) потом говорили «В стандарте было написано неопределенно, но у Стивенсона написано было так. Мы так и сделали.»
PHP-программисты убили родителей автора?
Почему, вместо того, чтобы программировать на своём любимом языке и получать от этого удовольствие нужно писать такую гневную простыню?
Почему, вместо того, чтобы программировать на своём любимом языке и получать от этого удовольствие нужно писать такую гневную простыню?
Первая часть, переведена неплохо, но подробности нуждаются в улучшении (ПРОМТ?)
После:
читать дальше не смог…
После:
Отдельные операторы для каждого типа делают язык гораздо более сложным, например вы не можете использовать '==' для строк(что?), вы теперь будете использвать 'eq'. Я не вижу никакого смысла, особенно в таком языка как PHP, где большинство скриптов будут достаточно простыми и в большинстве случаев написаны непрограммистами, которым нужен язык с простейшим логическим синтаксисом и у которого низкий порог вхождения.
читать дальше не смог…
В PHP-DEV рассылке данный пост уже обсосали, назвали автора капитаном очевидность, а так же пожеланием автора пропиарится за счёт блогпоста для набивания себе цены.
Всё что думает сообщество разработчиков об этом посте можно почитать в первоисточнике вот тут: marc.info/?t=133418943700005&r=1&w=1 и отделившуюся ветку тут marc.info/?t=133407516900003&r=1&w=1
Всё что думает сообщество разработчиков об этом посте можно почитать в первоисточнике вот тут: marc.info/?t=133418943700005&r=1&w=1 и отделившуюся ветку тут marc.info/?t=133407516900003&r=1&w=1
Сложилось впечатление, что автора статьи (именно статьи, а не перевода), php чем-то обидел…
Да, есть неровности, но где можно увидеть идеальность?
Желаете совершенного языка? Тогда создайте свой — неповторимый и идеальный.
Я тоже могу написать, что чб телевизор «Березка» — говно, хоть сам смотрел его двадцать лет назад.
В «Березке» всякие ручки громкости, контрастности и яркости + здоровенный переключатель каналов, вечно горящие лампы.
Сколько неудобст? Уйма!
Но ведь пользовались…
Да, есть неровности, но где можно увидеть идеальность?
Желаете совершенного языка? Тогда создайте свой — неповторимый и идеальный.
Я тоже могу написать, что чб телевизор «Березка» — говно, хоть сам смотрел его двадцать лет назад.
В «Березке» всякие ручки громкости, контрастности и яркости + здоровенный переключатель каналов, вечно горящие лампы.
Сколько неудобст? Уйма!
Но ведь пользовались…
Хорошая статья!
Много того что я давно хотел сказать вслух про PHP но никак не мог оформить в слова :)))…
Много того что я давно хотел сказать вслух про PHP но никак не мог оформить в слова :)))…
История про проверку переполнения целого числа путём условия x > INT_MAX — просто шедевр.
Очень интересная статья. По долгу службы приходится иногда писать на PHP (а скоро придется еще больше), некоторые подводные камни полезно было узнать.
Не принимайте близко к сердцу выпады насчет качества перевода. Просто пройдитесь по статье, переписывая корявые предложения на русский, не глядя в оригинал. Это не тот случай, когда перевод должен быть дословным.
холииивааааар!!!
Возможно как ЯП говно, но как средство разработки простых сайтов… отличный инструмент.
А с какими инструментами вы сравниваете? Предлагаю на Sinatra посмотреть и реализацию чего-нибудь подобного на любом из языков Python, Perl или Ruby. Предлагаю сравнить качество и количество кода, да и вообще к своим ощущениям прислушаться, нравиться это или нет.
Ну я может не достаточно хорошо но знаю Ruby (RoR в частности), но простые решения как «сайты визитки» сложно развернуть на RoR, PHP за 2-3$/м. кучи удвольтворяющих требованиям хостингов. Это же касается и NodeJS/Python.
Но конечно для себя или для проекта средней сложности и выше я 10 раз из 10 выберу RoR.
По этому, как средство создания простых/дешевых решений php в порядке.
Но конечно для себя или для проекта средней сложности и выше я 10 раз из 10 выберу RoR.
По этому, как средство создания простых/дешевых решений php в порядке.
а я считаю. что java говно.
а разве кто-то спорит?
не удержался?)
Аргументированно.
а вот вы возмите и напишите на java без крутых либ загрузку веб-страницы и вывод ее stdout.
утоните в буфферах… хотя большие буфера это круто!!!
утоните в буфферах… хотя большие буфера это круто!!!
Справедливо.
Да и вообще компьютеры тоже говно.
Автор прекрасный писатель. Надо выпускаться, через пару лет обгонит Донцову.
По теме статьи:
Кривонаписанный код в любом языке кривонаписанный код.
Да php позволяет кривить больше чем многие другие языки, но все зависит от программиста. Он сам выбирает какие конструкции использовать, а какие нет.
По теме статьи:
Кривонаписанный код в любом языке кривонаписанный код.
Да php позволяет кривить больше чем многие другие языки, но все зависит от программиста. Он сам выбирает какие конструкции использовать, а какие нет.
Классная статья! Освежил в голове данные о PHP :) Спасибо :)
А вообще, никто ведь не заставляет человека писать на том или ином языке. Не нравится — так не пиши. Или уж не жалуйся :)
А вообще, никто ведь не заставляет человека писать на том или ином языке. Не нравится — так не пиши. Или уж не жалуйся :)
Никто не спорит, что для своих задач РНР отлично спраляется.
Осталось только понять какие это задачи ) То есть, нужно определить где граница того, что можно сделать на РНР, а что уже дешевле делать на чем-то другом. Как-то так.
Если вы выпускаете продукт, который должен устанавливаться на сервере клиента, как Magento, Drupal, Joomla, etc, то это однозначно РНР. А вот если пишите ентерпрас-решение или стартап, то хз.
Осталось только понять какие это задачи ) То есть, нужно определить где граница того, что можно сделать на РНР, а что уже дешевле делать на чем-то другом. Как-то так.
Если вы выпускаете продукт, который должен устанавливаться на сервере клиента, как Magento, Drupal, Joomla, etc, то это однозначно РНР. А вот если пишите ентерпрас-решение или стартап, то хз.
Возможно ли создать для PHP библиотеку, которая будет минимизировать описанные проблемы? Например, сделать отдельные удобные классы для чисел, юникодовых строк, массивов, реализовать все необходимые методы в виде красивого API, добавить несколько обратно совместимых патчей в код PHP, чтобы работали нормальные сравнения и так далее. Такого до сих пор нет? Это слишком сложно? Или просто не нужно?
Многие пункты статьи спорные (например, можно без проблем реализовать роутинг на PHP и настроить в nginx одну точку входа для всех адресов), но в ней также перечислено огромное количество реальных проблем, с которыми я согласен. Теперь, когда меня спросят, почему я не люблю PHP, я могу просто дать ссылку на эту статью.
Многие пункты статьи спорные (например, можно без проблем реализовать роутинг на PHP и настроить в nginx одну точку входа для всех адресов), но в ней также перечислено огромное количество реальных проблем, с которыми я согласен. Теперь, когда меня спросят, почему я не люблю PHP, я могу просто дать ссылку на эту статью.
>> Такого до сих пор нет?
Частично есть в различных фрейворках, расширениях. Но всё фрагментировано.
>> Это слишком сложно? Или просто не нужно?
Да!
Частично есть в различных фрейворках, расширениях. Но всё фрагментировано.
>> Это слишком сложно? Или просто не нужно?
Да!
На PHP можно писать по-разному: плохо/хорошо, объектно/функционально, использовать или нет исключения. На нем можно писать, по факту, как угодно.
В моем понимании это скорее минус чем плюс, потому как он при своей гибкости, имеет очень низкий порог вхождения, а это значит что количество дерьмо-кода на php гораздо больше чем на других языках либо с меньшей гибкостью, либо с более высоким уровнем вхождения.
Я пишу на PHP и, если будет возможность, я постараюсь от него избавиться. Но законы рынка есть законы рынка, и к программированию они мало относятся, так что я сильно сомневаюсь, что в текущем проекте куда-то можно будет съехать.
В моем понимании это скорее минус чем плюс, потому как он при своей гибкости, имеет очень низкий порог вхождения, а это значит что количество дерьмо-кода на php гораздо больше чем на других языках либо с меньшей гибкостью, либо с более высоким уровнем вхождения.
Я пишу на PHP и, если будет возможность, я постараюсь от него избавиться. Но законы рынка есть законы рынка, и к программированию они мало относятся, так что я сильно сомневаюсь, что в текущем проекте куда-то можно будет съехать.
Я знаю много языков. И красивые: lisp, haskell, D; и простые: C, python, lua; и сложные: JAVA, C++; и еще много какие, вроде C#, которые не знаю куда определить :)
Недавно решил заняться вебом и в процессе пришлось попрогать на PHP. Знаете что? Я больше этого делать не буду, одного раза хватило. И несмотря на то, что я нашел (столкнулся) с гораздо меньшим числом косяков, чем автор, я полностью согласен с его мнением.
И еще, не в порядке хейтерства, просто реально очень любопытно: зачем, ну зачем в PHP $ в начале имен переменных? Даже в лиспе с фортраном, которые в 60х были не было никаких ухищрений для детектирования имен переменных в коде, а сейчас-то технологии куда как лучше развиты в этом плане!
Просветите пожалуйста, кто-нибудь из знающих.
Недавно решил заняться вебом и в процессе пришлось попрогать на PHP. Знаете что? Я больше этого делать не буду, одного раза хватило. И несмотря на то, что я нашел (столкнулся) с гораздо меньшим числом косяков, чем автор, я полностью согласен с его мнением.
И еще, не в порядке хейтерства, просто реально очень любопытно: зачем, ну зачем в PHP $ в начале имен переменных? Даже в лиспе с фортраном, которые в 60х были не было никаких ухищрений для детектирования имен переменных в коде, а сейчас-то технологии куда как лучше развиты в этом плане!
Просветите пожалуйста, кто-нибудь из знающих.
Соглашусь с аргументами сообщества по поводу этой статьи:
What exactly valid points? == is a converting operator, === is a strict
operator. OK, in his favorite language it is not. Where exactly the
valid point is? Author goes at great lengths to refuse to make even a
slight mental effort to understand how it works (really, it's not that
hard) and then complains it's «useless». Well, a lot of things would be
useless if you don't want to know how to use them.
И ещё:
This blog brings zero thing new, got many wrong facts and only
repeats what have been said for over a decade about parameters order.
Not sure how one can have so much free time in his hand to write such
useless things.
И про «Пофикшено в PHP 5.3.» и т.п. — ну пофикшено и пофикшено, зачем воду мутить :)
What exactly valid points? == is a converting operator, === is a strict
operator. OK, in his favorite language it is not. Where exactly the
valid point is? Author goes at great lengths to refuse to make even a
slight mental effort to understand how it works (really, it's not that
hard) and then complains it's «useless». Well, a lot of things would be
useless if you don't want to know how to use them.
И ещё:
This blog brings zero thing new, got many wrong facts and only
repeats what have been said for over a decade about parameters order.
Not sure how one can have so much free time in his hand to write such
useless things.
И про «Пофикшено в PHP 5.3.» и т.п. — ну пофикшено и пофикшено, зачем воду мутить :)
Как будто кто-то сделал ружье, из которого можно оправданно стралять по PHP'шникам
Тут нужно не ружье. Тут нужен асфальтоукладчик.
На самом деле такие статьи были очень давно, особенно много я видел про Perl vs PHP, просто в данном случае очень серьёзно автор постарался и аккумулировал множество проблем.
Интересно бы увидеть такой подход к другим холиварам «java vs c#», «microsoft vs. linux», «Путин vs. Жириновский»
Забавно, но с тех пор Perl ОЧЕНЬ сильно изменился, а PHP как-то нет… и не собирается…
Мне кажется, что ru.wikipedia.org/wiki/Кока трудно сравнивать с Пепси…
очередной сектантский троллинг :) теперь и от пайтониста :)
Ну сказано же было — сделан не программистами для не программистов.
не убедило!
Я думаю PHP просто писали в более креативном состоянии, и после небольшого допинга во всех странностях PHP станет понятен особый смысл :)
По поводу качества перевода и гнобления переводчика — та же ситуация, собственно, что и с самим PHP.
Результат несовершенен, но помог (в данном случае) нескольким сотням человек узнать хоть что-то новое (из перевода) вместо того, чтобы просто пропустить материал. Но комментарии в основном недовольные. Дело не в PHP и не в переводе, а в отношении к чужому бесплатному труду.
Результат несовершенен, но помог (в данном случае) нескольким сотням человек узнать хоть что-то новое (из перевода) вместо того, чтобы просто пропустить материал. Но комментарии в основном недовольные. Дело не в PHP и не в переводе, а в отношении к чужому бесплатному труду.
это именно то что я пытался сказать своей статьей «пхп не любит деструкторы». спасибо вам!
Эпичная статья. Буду кидать ссылку всем наивно вопрошающим «а чем плох пэхапэ?» O.O
Автор, не вздумай удалять сей труд!
Автор, не вздумай удалять сей труд!
Отличная статья, даже я что-то «новенькое» нашел, хотя есть одно НО — в реальной работе сталкиваться приходиться с 10% приведенных «фишечек».
Было бы жутко круто, если бы все эти замечания или хотя бы половина были учтены в php 6. Пусть половина существующего кода поломается и перестанет работать. Наплевать. Зато это будет движение в правильном направлении.
Меня лично жутко раздражает это поведение, когда неопределённая константа воспринимается как строка. С удовольствием бы включил какой-нибудь триггер, чтобы оно просто помирало на таких моментах с Parse error.
Меня лично жутко раздражает это поведение, когда неопределённая константа воспринимается как строка. С удовольствием бы включил какой-нибудь триггер, чтобы оно просто помирало на таких моментах с Parse error.
Круто чего, только вот Питон тоже не сахар, тормозной, кушает память, по миру носится зоопарк несовместимых версий и реализаций. Многопоточности по факту не существует ибо из за GIL она по факту тормознее, чем выполнение в однопоточном режиме.
habrahabr.ru/post/84629/
Одним словом автор статьи вместо одного квадратного колеса предлагает другое, шестигранное.
Лучше уж erlang или node.js хотя бы.
habrahabr.ru/post/84629/
Одним словом автор статьи вместо одного квадратного колеса предлагает другое, шестигранное.
Лучше уж erlang или node.js хотя бы.
erlang — вещь, он заставил меня взглянуть на программирование по новому!
Питон тоже не сахар, тормозной
Ложь. Если срванивать с Java/C#/C — тормозной, если с пхп — быстрый.
кушает память
Ложь. Или вы опять с Си сравниваете?
по миру носится зоопарк несовместимых версий и реализаций
Ложь. Несовместимых версии всего две: cpython2 и cpython3. А все остальные реализации решают задачи, которые в других языках (аналогах) либо не решаются вообще, либо решаются таким же зоопарком реализаций. А все библиотеки пишутся под одну (или обе) из вышеупомянутых версий.
Многопоточности по факту не существует
Ложь. GIL влияет только на IO, а многопоточные вычисления прекрасно, очень просто и равномерно распиливаются на ядра потоками (хоть и не идеально эффективно). А если вам нужно распараллелить IO, с этим превосходно справляется стандартный богатый возможностями модуль multiprocessing, где есть все необходимые инструменты для безопасного параллельного IO (блокировки, пулы, процессы, разделяемая память и т. д.). Этим модулем можно даже распараллеливать на кластер, хотя и не так удобно, как это делает из коробки тот же Erlang. Но последний для этого изначально и разрабатывался, поэтому неудивительно.
Не говорю, что питон — лучшее решение для многопоточных вычислений, но в целом, там все в порядке.
А раз уж вы привели статью, советую вам ее прочитать, а также полезные комменты
Одним словом автор статьи...
Диагнозы оставьте профессионалам. Не позорьтесь.
P. S.: сорян за некропост, не мог оставить эту ложь для будущих читателей.
ЗЫ
А что вы вообще хотите от препроцессора для домашних страничек?
А что вы вообще хотите от препроцессора для домашних страничек?
Спасибо большое за статью/перевод. Она расставила точки над i в моей голове. До этого было какое-то смутное отвращение и непонимание «почему все так плохо».
Забавно, что защитники PHP, в общем, не возражают, что это куча говна. Они лишь утверждают, что, грубо говоря, используя множество ароматизаторов, можно почти отбить запах.
Еще один защитный аргумент можно сформулировать так — «широкая распространенность плохой практики ее оправдывает». Но так ли это?
Не закрыл ли дешевый и тупой PHP вход на рынок другим технологиям — более продвинутым и технологичным, но и более дорогим и сложным для вхождения?
Забавно, что защитники PHP, в общем, не возражают, что это куча говна. Они лишь утверждают, что, грубо говоря, используя множество ароматизаторов, можно почти отбить запах.
Еще один защитный аргумент можно сформулировать так — «широкая распространенность плохой практики ее оправдывает». Но так ли это?
Не закрыл ли дешевый и тупой PHP вход на рынок другим технологиям — более продвинутым и технологичным, но и более дорогим и сложным для вхождения?
Почему сразу Бентли?
Предположим Рено Логан (небезопасный, вредный для экологии, дешевый) резко уменьшил сбыт авто следующего класса — Форд Фокус (безопасный, экологичный).
Больше людей сели в авто, но они гибнут чаще и воздух стал хуже. Чем если бы авто был подороже, но и получше.
Это и есть пресловутое «развитие индустрии»?
Предположим Рено Логан (небезопасный, вредный для экологии, дешевый) резко уменьшил сбыт авто следующего класса — Форд Фокус (безопасный, экологичный).
Больше людей сели в авто, но они гибнут чаще и воздух стал хуже. Чем если бы авто был подороже, но и получше.
Это и есть пресловутое «развитие индустрии»?
Я как бы даже не спорю с Вами :) Мое видение вот в чем.
С PHP случилось тоже, что и с Windows. В какой-то момент возник огромный спрос на сайты-приложения (в случае Windows — на персональные компьютеры). И любое решение было лучше, чем ничего (вспомните «танцующего медведя», чудо которого в том, что он вообще танцует, хотя делает это ужасно). Возникла пресловутая «платформа», на которой можно было быстро клепать веб (Апач + ПХП + MySQL).
Но дальше-то что происходит? На свет являются java, руби, питон, node.js и пр. Однако, другой «платформой» никто из них не стал. Не появилось, скажем так, массовой и доступной технологии создания веб-сайтов следующего поколения, на которую с радостью перейдет PHP-программист. «Следующего поколения» в вопросе безопасности, системности, быстродействия, простоты и пр.
И вопрос, которым я задаюсь, не связано ли это именно с популярностью и распространенностью PHP, который забрал на себя огромный ресурс разработчиков и одновременно лишил воли других делать что-то получше, поскольку все равно «никто не перейдет, всем и так неплохо»? Никто не спорит, что PHP плох, но ничего лучше нету и — парадокс — никто и не собирается создавать серьезную замену.
С PHP случилось тоже, что и с Windows. В какой-то момент возник огромный спрос на сайты-приложения (в случае Windows — на персональные компьютеры). И любое решение было лучше, чем ничего (вспомните «танцующего медведя», чудо которого в том, что он вообще танцует, хотя делает это ужасно). Возникла пресловутая «платформа», на которой можно было быстро клепать веб (Апач + ПХП + MySQL).
Но дальше-то что происходит? На свет являются java, руби, питон, node.js и пр. Однако, другой «платформой» никто из них не стал. Не появилось, скажем так, массовой и доступной технологии создания веб-сайтов следующего поколения, на которую с радостью перейдет PHP-программист. «Следующего поколения» в вопросе безопасности, системности, быстродействия, простоты и пр.
И вопрос, которым я задаюсь, не связано ли это именно с популярностью и распространенностью PHP, который забрал на себя огромный ресурс разработчиков и одновременно лишил воли других делать что-то получше, поскольку все равно «никто не перейдет, всем и так неплохо»? Никто не спорит, что PHP плох, но ничего лучше нету и — парадокс — никто и не собирается создавать серьезную замену.
Они лишь утверждают, что, грубо говоря, используя множество ароматизаторов, можно почти отбить запах.
Если заказчики просят говно, то приходится использовать ароматизаторы, чтобы при работе не воняло…
Если заказчики просят говно, то приходится использовать ароматизаторы, чтобы при работе не воняло…
Не программист, не программирую, и понял не больше 2% текста (текст зачетный. чего стоят хотя бы «половинные сравнения» хешей"). Сейчас все мои поделки изготавливаются на питоне. Очень его люблю. Но…
… с нежностью вспоминаю документацию PHP. Доступ к описанию любого метода, поля и т.д. за 2 секунды.
… ничего кроме мата документация по питону не вызывает. Ад адский, хер найдешь что-то. Вот знаешь, что где-то видел — а где, хер его знает. То ли в доках, то ли в пепах, то ли на хабре, то ли на ньюсру прочитал. Второй раз к одной и той же строке вернуться НЕВОЗМОЖНО.
А теперь учитесь просирать карму: «А еще эти уроды, которые продолжают писать на питоне 2.7!!!!!!!»
извините, пока писал, опять разозлился на питоновскую документацию.
… с нежностью вспоминаю документацию PHP. Доступ к описанию любого метода, поля и т.д. за 2 секунды.
… ничего кроме мата документация по питону не вызывает. Ад адский, хер найдешь что-то. Вот знаешь, что где-то видел — а где, хер его знает. То ли в доках, то ли в пепах, то ли на хабре, то ли на ньюсру прочитал. Второй раз к одной и той же строке вернуться НЕВОЗМОЖНО.
А теперь учитесь просирать карму: «А еще эти уроды, которые продолжают писать на питоне 2.7!!!!!!!»
извините, пока писал, опять разозлился на питоновскую документацию.
Мне помагает поиск
site:docs.python.org %s.
А что там плохо-то?
Всё, что касается стандартной библиотеки, в т.ч. встроенные функции и методы стандартных типов — docs.python.org/library/
Всё, что касается реализации самого языка, полное описание синтаксиса, модели данных и т.п. — docs.python.org/reference/
2 вышеперечисленные вещи в кратком и конспективном виде, полезно иногда обратиться чтобы освежить в памяти (даже самые простые вещи могут забыться) — docs.python.org/tutorial/
По мне — всё понятно, логично и удобно организовано. В процессе написания кода в 98% случаев хватает этих разделов.
В процессе работы лазить в пепы… ну я хз, разве что в восьмой, но его надо вызубрить так, чтобы правильное форматирование кода выполнялось на уровне бессознательного.
А особенно странным выглядит ваша реплика про
>на ньюсру прочитал
… безусловный недостаток документации питона.
Вот документация по PHP, с неудобной левой менюшкой показывающей только путь к текущей странице, неудобным поиском (категории), неудобной навигацией (сколько пройти надо страниц из корня Function reference к описанию одной конкретной функции?) её кучей всего в одной глобальной мешанине длиннющего содержания (прям как сам язык) без чёткого визуального разделения в содержании — за то время, что приходилось работать с PHP, оставила самое негативное впечатление.
Мораль: всё субъективно.
Всё, что касается стандартной библиотеки, в т.ч. встроенные функции и методы стандартных типов — docs.python.org/library/
Всё, что касается реализации самого языка, полное описание синтаксиса, модели данных и т.п. — docs.python.org/reference/
2 вышеперечисленные вещи в кратком и конспективном виде, полезно иногда обратиться чтобы освежить в памяти (даже самые простые вещи могут забыться) — docs.python.org/tutorial/
По мне — всё понятно, логично и удобно организовано. В процессе написания кода в 98% случаев хватает этих разделов.
В процессе работы лазить в пепы… ну я хз, разве что в восьмой, но его надо вызубрить так, чтобы правильное форматирование кода выполнялось на уровне бессознательного.
А особенно странным выглядит ваша реплика про
>на ньюсру прочитал
… безусловный недостаток документации питона.
Вот документация по PHP, с неудобной левой менюшкой показывающей только путь к текущей странице, неудобным поиском (категории), неудобной навигацией (сколько пройти надо страниц из корня Function reference к описанию одной конкретной функции?) её кучей всего в одной глобальной мешанине длиннющего содержания (прям как сам язык) без чёткого визуального разделения в содержании — за то время, что приходилось работать с PHP, оставила самое негативное впечатление.
Мораль: всё субъективно.
з.ы.
>с неудобной левой менюшкой показывающей только путь к текущей странице
Немного неверно выразил мысль.
Зачастую описание функций и разделов в документации структурировано _неудачно_.
Например, на сколько страниц разбито в документации PHP то, что примерно эквивалентно этому? Тут всё в рамках одной страницы + визуальная навигация по «уровням» и разделам, с отступами — легче просматривать, легче находить нужную информацию.
>с неудобной левой менюшкой показывающей только путь к текущей странице
Немного неверно выразил мысль.
Зачастую описание функций и разделов в документации структурировано _неудачно_.
Например, на сколько страниц разбито в документации PHP то, что примерно эквивалентно этому? Тут всё в рамках одной страницы + визуальная навигация по «уровням» и разделам, с отступами — легче просматривать, легче находить нужную информацию.
ссылка потерялась — docs.python.org/library/stdtypes.html *
Вот что там плохо: есть доки по питону (docs.python.org). Есть я — человек, который три дня назад сделал первый подход к питону. Пытаюсь разобраться, например, с lists и что с ними можно сделать. Для этого я ввожу слово list в поиске и ожидаю увидеть референс класса list с методами и параметрами (сорри, если адски путаю термины — хоббист-самоучка, университетов не кончал).
Что я получаю в документации питона (проверьте самостоятельно). Допустим я терпеливый и стал скролить эту выдачу и нашел функцию list (built-in python types). Заходим. Видим описание функции, во втором абзаце list-ссылка (может оно? — хрена с два, это ссылка на предыдущий абзац). Можно тыкнуть в ссылку «Sequence types» (http://docs.python.org/library/stdtypes.html#typesseq) Не проканало, возвращаемся в выдачу поиска. Хотя зря вернулся, потому что уже 10 минут ищу, но так и не нашел.
Та же хрень с функциями почти со всеми. Что там параметрами передавать — х его з. Надо _знать_. Если ты не знаешь, ты эту информацию никогда не найдешь.
Что я получаю в документации питона (проверьте самостоятельно). Допустим я терпеливый и стал скролить эту выдачу и нашел функцию list (built-in python types). Заходим. Видим описание функции, во втором абзаце list-ссылка (может оно? — хрена с два, это ссылка на предыдущий абзац). Можно тыкнуть в ссылку «Sequence types» (http://docs.python.org/library/stdtypes.html#typesseq) Не проканало, возвращаемся в выдачу поиска. Хотя зря вернулся, потому что уже 10 минут ищу, но так и не нашел.
Та же хрень с функциями почти со всеми. Что там параметрами передавать — х его з. Надо _знать_. Если ты не знаешь, ты эту информацию никогда не найдешь.
>Пытаюсь разобраться, например, с lists и что с ними можно сделать.
Если я хочу узнать, что это такое вообще, то определение list дано в описании модели данных языка. docs.python.org/reference/datamodel.html#the-standard-type-hierarchy — Sequences — Mutable sequences — Lists.
Если хочется узнать, что умеет list — какие методы есть у объектов этого типа и какие синтаксические возможности и операторы используемы с ним — вам в Library Reference — Built in types (http://docs.python.org/library/stdtypes.html; конкретные ссылки уже привёл выше ). Вполне логично, что методы, общие как для всех sequence, так и mutable sequence типов, объединены. Там же есть полезная ссылка на конструктор list() из встроенных функций языка — docs.python.org/library/functions.html#list.
Стоит упомянуть, что изучение языка обычно начинается с туториала; официальный туториал же Python (который я считаю лучшим из официальных пособий для начинающих по ЯП, которые я читал вообще), очень доходчиво и подробно объясняет все основные концепты использования List в docs.python.org/tutorial/introduction.html#lists и docs.python.org/tutorial/datastructures.html#more-on-lists.
Попрошу заметить, что если захочется узнать, какие функции существуют у Array в PHP и вы откроете php.net/manual/en/language.types.array.php, то увидите что там упоминается Useful functions и далее стоит посыл «See the array functions section.». Вообще, что больше всего мучало в документации PHP — огромное количество переходов по страницам, переходов на страницы с оглавлениями, которые ведут на страницы со следующими оглавлениями и так далее; docs.python.org/library/stdtypes.html — на одной странице описано 90% полезной информации по использованию всех стандартных типов, и с неё же есть ссылки на ещё 9% таковой информации. По-моему, такой подход к организации структуры документации гораздо удобнее.
И опять к слову, если в документации PHP выбрать поиск по «online documentation» и вбить Array, то всё равно окажешься на странице выдачи с функциями.
>Можно тыкнуть в ссылку «Sequence types» (http://docs.python.org/library/stdtypes.html#typesseq) Не проканало, возвращаемся в выдачу поиска.
Всё проканало — там вполне понятно описана информация по sequence types и есть ссылка «Additional methods are provided for Mutable Sequence Types.». Чего вы ожидали увидеть? Как я говорил выше, информация организована компактно и то что применимо для всех sequence types там же и приводится.
>Та же хрень с функциями почти со всеми. Что там параметрами передавать — х его з. Надо _знать_.
Как это? Везде и всегда описываются как параметры, так и возвращаемое значение (единственное что — они не выносятся визуально в отдельные блоки как в документации по функциям PHP, но это можно понять — если всё находится на минимуме насыщенных страниц, то важна лаконичность подачи информации). Тот же конструктор list() docs.python.org/library/functions.html#list:
>list([iterable])
>Return a list whose items are the same and in the same order as iterable‘s items.
>Iterable may be either a sequence, a container that supports iteration, or an iterator object.
>If iterable is already a list, a copy is made and returned, similar to iterable[:].
… и так далее. Здесь есть вся нужная информация.
>Вот попробуй найти поиском какие кодировки бывают (ну типа UTF-8). Я вот ввел слово encoding в строку поиска и три минуты уже смотрю на выдачу в полном офигении. Отличный поиск по документации!
Я не понял такую постановку вопроса :)
Интересовало «какие кодировки поддерживаются в языке»? Или «какие средства есть для работы с ними»? Или что-то ещё?
В любом случае, ссылка на туториал (крайне рекомендую его пройти) docs.python.org/tutorial/introduction.html#unicode-strings, а так же есть HowTo docs.python.org/howto/unicode.html.
К слову, если вбить такой же запрос «unicode» в документацию PHP: php.net/results.php?q=encoding&p=manual&l=en — возвращается мешанина из референсов по функциям и классам.
Так что опять таки,
>Мораль: всё субъективно.
:) Для меня документация Python вполне исчерпывающа, удобна и информативна, чего я не мог сказать про документацию PHP, когда её использовал (особенно в плане стиля подачи информации и её организации).
Если я хочу узнать, что это такое вообще, то определение list дано в описании модели данных языка. docs.python.org/reference/datamodel.html#the-standard-type-hierarchy — Sequences — Mutable sequences — Lists.
Если хочется узнать, что умеет list — какие методы есть у объектов этого типа и какие синтаксические возможности и операторы используемы с ним — вам в Library Reference — Built in types (http://docs.python.org/library/stdtypes.html; конкретные ссылки уже привёл выше ). Вполне логично, что методы, общие как для всех sequence, так и mutable sequence типов, объединены. Там же есть полезная ссылка на конструктор list() из встроенных функций языка — docs.python.org/library/functions.html#list.
Стоит упомянуть, что изучение языка обычно начинается с туториала; официальный туториал же Python (который я считаю лучшим из официальных пособий для начинающих по ЯП, которые я читал вообще), очень доходчиво и подробно объясняет все основные концепты использования List в docs.python.org/tutorial/introduction.html#lists и docs.python.org/tutorial/datastructures.html#more-on-lists.
Попрошу заметить, что если захочется узнать, какие функции существуют у Array в PHP и вы откроете php.net/manual/en/language.types.array.php, то увидите что там упоминается Useful functions и далее стоит посыл «See the array functions section.». Вообще, что больше всего мучало в документации PHP — огромное количество переходов по страницам, переходов на страницы с оглавлениями, которые ведут на страницы со следующими оглавлениями и так далее; docs.python.org/library/stdtypes.html — на одной странице описано 90% полезной информации по использованию всех стандартных типов, и с неё же есть ссылки на ещё 9% таковой информации. По-моему, такой подход к организации структуры документации гораздо удобнее.
И опять к слову, если в документации PHP выбрать поиск по «online documentation» и вбить Array, то всё равно окажешься на странице выдачи с функциями.
>Можно тыкнуть в ссылку «Sequence types» (http://docs.python.org/library/stdtypes.html#typesseq) Не проканало, возвращаемся в выдачу поиска.
Всё проканало — там вполне понятно описана информация по sequence types и есть ссылка «Additional methods are provided for Mutable Sequence Types.». Чего вы ожидали увидеть? Как я говорил выше, информация организована компактно и то что применимо для всех sequence types там же и приводится.
>Та же хрень с функциями почти со всеми. Что там параметрами передавать — х его з. Надо _знать_.
Как это? Везде и всегда описываются как параметры, так и возвращаемое значение (единственное что — они не выносятся визуально в отдельные блоки как в документации по функциям PHP, но это можно понять — если всё находится на минимуме насыщенных страниц, то важна лаконичность подачи информации). Тот же конструктор list() docs.python.org/library/functions.html#list:
>list([iterable])
>Return a list whose items are the same and in the same order as iterable‘s items.
>Iterable may be either a sequence, a container that supports iteration, or an iterator object.
>If iterable is already a list, a copy is made and returned, similar to iterable[:].
… и так далее. Здесь есть вся нужная информация.
>Вот попробуй найти поиском какие кодировки бывают (ну типа UTF-8). Я вот ввел слово encoding в строку поиска и три минуты уже смотрю на выдачу в полном офигении. Отличный поиск по документации!
Я не понял такую постановку вопроса :)
Интересовало «какие кодировки поддерживаются в языке»? Или «какие средства есть для работы с ними»? Или что-то ещё?
В любом случае, ссылка на туториал (крайне рекомендую его пройти) docs.python.org/tutorial/introduction.html#unicode-strings, а так же есть HowTo docs.python.org/howto/unicode.html.
К слову, если вбить такой же запрос «unicode» в документацию PHP: php.net/results.php?q=encoding&p=manual&l=en — возвращается мешанина из референсов по функциям и классам.
Так что опять таки,
>Мораль: всё субъективно.
:) Для меня документация Python вполне исчерпывающа, удобна и информативна, чего я не мог сказать про документацию PHP, когда её использовал (особенно в плане стиля подачи информации и её организации).
>уже привёл выше
..MikhailEdoshin — у хабра какие-то проблемы с парсингом тегов.
..MikhailEdoshin — у хабра какие-то проблемы с парсингом тегов.
я же не говорю «информации нет». Я говорю, что структурирована она (естественно ИМХО, естественно) ужасно!
Я читал не только туториал, я еще и два раза просмотрел гугловый курс по питону с решением задач. Память только у меня короткая, мне нужно под руками всегда иметь референс. Имея под рукой доки по питону, я всегда обнаруживаю себя тупо глядящим в монитор и тихо матерящемся через 10 минут. Возможно это другой подход, возможно он всем-всем кроме меня удобен. Мне — нет.
Я читал не только туториал, я еще и два раза просмотрел гугловый курс по питону с решением задач. Память только у меня короткая, мне нужно под руками всегда иметь референс. Имея под рукой доки по питону, я всегда обнаруживаю себя тупо глядящим в монитор и тихо матерящемся через 10 минут. Возможно это другой подход, возможно он всем-всем кроме меня удобен. Мне — нет.
запускаете python, набираете help(list)
Вот попробуй найти поиском какие кодировки бывают (ну типа UTF-8). Я вот ввел слово encoding в строку поиска и три минуты уже смотрю на выдачу в полном офигении. Отличный поиск по документации!
Хм… По-поводу документации: всегда всё находилось в Python Manuals .chm-ке, поставляемой в комплекте с дистрибом (правда, под Win). Там же и поиск есть — можно сразу найти нужную функцию.
Статью прочитал с интересом. Спасибо.
Комментарии не осилил…
Комментарии не осилил…
Наверное лучший сборник всех, мягко говоря, неочевидностей PHP в одном месте. Жаль только, что заказчиков эти проблемы не волнуют. Да и с хостингами под конкурентов не всё так хорошо как хотелось бы (хотя и много лучше чем пару лет назад).
Я за то, чтобы разработчики PHP бросили практически все текущие дела, и обратили внимание на то, что здесь любезно собрано вместе.
Мне нравится язык, но эти мелочи (и не совсем мелочи) изрядно достают, приходится делать свои обертки для встроенных функций, и это усложняет дальнейшую поддержку кода другими людьми.
Ну забили бы на совместимость, поменяли названия функций и порядок аргументов к нормальному виду, могли бы небольшую софтину сделать для конвертации существующих приложений, и, в конце концов, не перелетят же все сразу на новую версию, текущие ветки были бы для совместимости, а новые — на будущее, да и IDE'шки помогли бы привыкнуть к новшествам.
Пишу под PHP 5.4, ибо поставил его на рабочей машине, и в какой-то момент решил проверить под PHP 5.3, и понял, что запустить его там уже не удастся.
Хороший язык, хоть и весьма специфический.
Как по мне — так нужно всё-таки начать ветку PHP 6, в котором большинство указанных проблем будет решено, хоть и без сохранения совместимости.
Мне нравится язык, но эти мелочи (и не совсем мелочи) изрядно достают, приходится делать свои обертки для встроенных функций, и это усложняет дальнейшую поддержку кода другими людьми.
Ну забили бы на совместимость, поменяли названия функций и порядок аргументов к нормальному виду, могли бы небольшую софтину сделать для конвертации существующих приложений, и, в конце концов, не перелетят же все сразу на новую версию, текущие ветки были бы для совместимости, а новые — на будущее, да и IDE'шки помогли бы привыкнуть к новшествам.
Пишу под PHP 5.4, ибо поставил его на рабочей машине, и в какой-то момент решил проверить под PHP 5.3, и понял, что запустить его там уже не удастся.
Хороший язык, хоть и весьма специфический.
Как по мне — так нужно всё-таки начать ветку PHP 6, в котором большинство указанных проблем будет решено, хоть и без сохранения совместимости.
С функциями ещё проще поступить можно. Объявить всю (почти) библиотеку depricated и сделать нормальные, а главное стандартные ООП-обёртки для них (и, возможно, стандартных типов), раскидать их по неймспейсам и т. п. По хорошему это надо было сделать с введение нэймспэйсов, чтобы код их использующий (то есть с более ранними версиями не совместимый и так) использовал их и для доступа к стандартной библиотеке. Если делать это, скажем, в 5.5 или 6.0, то получим код, по которому с первого взгляда сложно сказать совместим он с 5.3/5.4 или нет.
С самим языком, да, сложнее без потери BC не обойтись, причём главная проблема, что старый код не будет работать на новых версиях.
С самим языком, да, сложнее без потери BC не обойтись, причём главная проблема, что старый код не будет работать на новых версиях.
Но ведь ещё не один год будет поддерживаться PHP 5.3 и 5.4 — кто не может/хочет переписать свой код — его не заставляют.
А сдерживать развитие языка из-за проектов написанных 5-7 лет назад как по мне — глупо.
P.S. Сколько раз заказчик долбил, что код не работает после переноса на новый хостинг, где уже выключен register_globals, объяснить почему не работает, и каких усилий стоит это поправить невозможно — в итоге решает одна строчка, которая имитирует register_globals, но как же тяжело носить за спиной этот грех…
А сдерживать развитие языка из-за проектов написанных 5-7 лет назад как по мне — глупо.
P.S. Сколько раз заказчик долбил, что код не работает после переноса на новый хостинг, где уже выключен register_globals, объяснить почему не работает, и каких усилий стоит это поправить невозможно — в итоге решает одна строчка, которая имитирует register_globals, но как же тяжело носить за спиной этот грех…
Думаю большое значение имеет специфика языка, его рыночная ниша. Наверное не сильно отойду от истины, если скажу, что подавляющее большинство инсталляций PHP-проектов являются инсталляциями CMS/CMF, то есть проектов с небольшой (относительно) командой разработчиков, но большой армией потребителей, причём потребителей именно кода (веб-мастеров), зачастую не сильно квалифицированных как разработчики или системные администраторы, да и крутятся они обычно на шаред-хостингах. Возьмём, скажем, Joomla и представим, что завтра выходит PHP6, лишенный большинства недостатков ценой потери обратной совместимости, причём мощной такой потери, изменениях в ядре (операторах, конструкциях, типах и т. п.). Сообществу разработчиков нужно или будет забить на поддержку версий <6 и бросить все ресурсы на портирование (непростое), или тащить две версии, но в любом случае существенно заморозить развитие проекта на время портирования. Кому это нужно?
Завтра шестая версия не выйдет, как минимум, будет несколько лет (судя по прошлым выпускам) тестовых билдов, прежде, чем дело дойдёт до релиза, который хостеры начнут устанавливать.
А на счёт потребителей — они смогут продолжить использовать совместимые версии, пусть и немного устаревшие. А если шибко захотят обновится — пусть подумают и о новом хостинге, их ведь никто не заставляет обновляться и прямо сейчас.
А на счёт потребителей — они смогут продолжить использовать совместимые версии, пусть и немного устаревшие. А если шибко захотят обновится — пусть подумают и о новом хостинге, их ведь никто не заставляет обновляться и прямо сейчас.
«Немного устаревшие» в случае CMS может весьма чревато для очень многих, не только пользователей самих продуктов (веб-мастеров), их посетителей, но даже для тех, кто про эти сайты и не слышал, но под атаку ботнета попал.
Поддержку обеспечить обновления безопасности для устаревших версий на определённый период, как это обычно делается, но не вводить новый функционал.
Было бы только желание.
Было бы только желание.
Ночь, что-то я слова местами путаю…
Ладно в случае всяких Битриксов, а как быть с open source проектами? Вполне могут быть две крайности — никто не захочет переписывать всю кодовую базу или никто не захочет поддерживать старую.
Так оно и будет.
Надо же чем-то жертвовать во имя светлого будущего.
Надо же чем-то жертвовать во имя светлого будущего.
Так PHP может потерять один из главных своих плюсов — огромную кодовую базу. Начиная разработку практически с нуля нужны будут веские причины для выбора PHP (а за несколько лет и python/ruby/js/… на месте стоять не будут, обзаведутся, скажем, механизмами простого разворачивания, да и количество разработчиков увеличится)
Не надо! Не надо! Так как есть имхо очень удобно. А вот неймспейсы в пхп — это как раз полный кошмар и отстой.
Ага. Но это уже будет вообще не ПХП :-)
Видать автор долго копил злобу. Но мы то понимаем, что проблема на стороне волшебника, а не в волшебной палочке. Плохой(не желающий развиваться) разработчик на любом языке напишет плохо, хороший сделает хорошо на всём что программируется.
Так или иначе, по сути все языки одинаковые, только с разными вкусами. Есть различия, способные повлиять на скорость начала работ, но это только мелочи по сравнению с реальными делами — построением и архитектурой систем имеющий более высокой уровень.
Так или иначе, по сути все языки одинаковые, только с разными вкусами. Есть различия, способные повлиять на скорость начала работ, но это только мелочи по сравнению с реальными делами — построением и архитектурой систем имеющий более высокой уровень.
Это уж не говоря о том, сколько ошибок, несоответствий и неоднозначных мест в статье. Проблемы есть, как и в других языках, но автор столько притянул за уши и столько раз приписал чужие проблемы, что слепо верить всему что написано не умно.
Могу только, как всегда, посоветовать думать своей головой, а не прогибаться под конъюнктуру.
Могу только, как всегда, посоветовать думать своей головой, а не прогибаться под конъюнктуру.
«По сути все языки одинаковые» — на мой взгляд это не совсем так. С некоторой натяжкой можно сказать что все языки с алголоподобным синтаксисом похожи друг на друга, но стоит только взглянуть на лисп, хаскель, смолтолк как окажется что языки довольно таки разные.
Пролог нервничает за шкафом (=
Имеется в виду не внешний вид, а суть: условное ветвление, циклы, переменные, константы и.т.п. Даже ассемблер и брайнфак подходят.
Могут различаться парадигмы программирование — вот что делает программирование действительно разным. Но практически все парадигмы можно реализовать на любом языке. На «Си», например, с помощью структур, префиксов функций и доступу по соглашению можно организовать ООП.
Могут различаться парадигмы программирование — вот что делает программирование действительно разным. Но практически все парадигмы можно реализовать на любом языке. На «Си», например, с помощью структур, префиксов функций и доступу по соглашению можно организовать ООП.
я просто положу здесь ссылку на оригинал статьи:
me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
Прямо срыв покровов. Смешно. То же самое пишут про Яву, про C++, про Objective C — в общем, про все языки, постоянно применяемые на практике уже многие годы. Они такие не потому, что их плохо спроектировали. Всё точно так же, как с крупными приложениями: в процессе разработки новые требования не вписываются в изначальную архиектуру, код обрастает костылями. Если в социальной сети надо реализовать живое обновление ленты с помощью long-polling, ни в коем случае ничего не поломав даже на минуту, полный рефакторинг ради удовлетворения чувства прекрасного никто проводить не будет. Вот и с языками так: внедрение новых возможностей делает их некрасивыми. Девственно чистыми и синтаксически прекрасными останутся лишь те, на которых никто ничего серьёзного не пишет.
Я не согласен с вами.
>Вот и с языками так: внедрение новых возможностей делает их некрасивыми. Девственно чистыми и синтаксически прекрасными останутся лишь те, на которых никто ничего серьёзного не пишет.
Python на 5 лет старше как Java, так и PHP.
Я не утверждаю что он «синтаксически прекрасен», но он не некрасив, и определённо — с течением времени не становится некрасивым.
Не говоря о том, что он ощутимо лучше организован, последователен и интуитивно понятен, нежели PHP.
И с течением времени и изменений он не приносит каких-то новых костылей, но наоборот, проводится работа по его разумному улучшению.
И если уж на то пошло, в этом году C исполняется 40 лет. Я считаю C красивым языком, самим по себе свободным от критичных недостатков планирования или несогласованностей такого уровня, как PHP. При этом он тоже прошёл определённый путь развития и не стагнирует.
>Вот и с языками так: внедрение новых возможностей делает их некрасивыми. Девственно чистыми и синтаксически прекрасными останутся лишь те, на которых никто ничего серьёзного не пишет.
Python на 5 лет старше как Java, так и PHP.
Я не утверждаю что он «синтаксически прекрасен», но он не некрасив, и определённо — с течением времени не становится некрасивым.
Не говоря о том, что он ощутимо лучше организован, последователен и интуитивно понятен, нежели PHP.
И с течением времени и изменений он не приносит каких-то новых костылей, но наоборот, проводится работа по его разумному улучшению.
И если уж на то пошло, в этом году C исполняется 40 лет. Я считаю C красивым языком, самим по себе свободным от критичных недостатков планирования или несогласованностей такого уровня, как PHP. При этом он тоже прошёл определённый путь развития и не стагнирует.
За годы там много нелогичностей и бреда выловили, но до сих пор остались штуки типа
foo()
и
foo(void)
foo()
и
foo(void)
Лиспу уже пятьдесят, и я все никак не могу найти похожую статью про него. Одно время это был промышленный язык, на нем писали даже операционные системы, так что это не тот случай, когда на языке ничего серьезного не делают. Но что бы вы сказали, если бы в пхп кодер мог бы взять и поменять все что изложено в этой статье, не дожидаясь шестой версии? А в лиспе это возможно. И несложно.
> Но что бы вы сказали, если бы в пхп кодер мог бы взять и поменять все что изложено в этой статье, не дожидаясь шестой версии? А в лиспе это возможно. И несложно.
Во-первых, я писал на Лиспе и знаю его особенности/возможности, во-вторых — я не могу сказать что меня волнуют недостатки PHP или способы их решения :)
Я о том, что большой возраст и история развития языка не означают, что он должен обрасти несуразностями, косяками и костылями (это является признаком плохого подхода при процессе его развития и неважной организацией самого такого процесса). И да, Лисп с его богатейшей историей, кучей диалектов, но сохранённой исходной идеологией, простотой и эффективностью это тоже хорошо отражает.
Во-первых, я писал на Лиспе и знаю его особенности/возможности, во-вторых — я не могу сказать что меня волнуют недостатки PHP или способы их решения :)
Я о том, что большой возраст и история развития языка не означают, что он должен обрасти несуразностями, косяками и костылями (это является признаком плохого подхода при процессе его развития и неважной организацией самого такого процесса). И да, Лисп с его богатейшей историей, кучей диалектов, но сохранённой исходной идеологией, простотой и эффективностью это тоже хорошо отражает.
Кстати, весьма неплохой язык для веба, даже сказал бы, что очень хороший!
Ну хе-хе, это лично вам питон нравится. А меня например он дико бесит многими вещами, начиная с форматирования блоков кода отступами. С моей точки зрения ужасно, когда логика работы программы определяется whitespace'ом.
Не смотря на все проблемы, свою роль он выполняет
большинство скриптов будут достаточно простыми и в большинстве случаев, написаны непрограммистами, которым нужен язык с простейшим логическим синтаксисом и низким порогом вхождения.
большинство скриптов будут достаточно простыми и в большинстве случаев, написаны непрограммистами, которым нужен язык с простейшим логическим синтаксисом и низким порогом вхождения.
Вообще забавные люди вы, фанаты пхп. Плюете критикам в карму по-тихому, но никто из вас так и не сказал, почему PHP хотя бы не хуже чем Python. Звучит только стандартное «ну и что, я привык» и «хостинг за 2 бакса».
А он не хуже (а лучше, судя по рынку) не своими качествами как ЯП общего назначения, а инфраструктурой (включая «хостинги за пару баксов», которые тоже в общем-то результат идеологии языка) и состоянием рынка. Может задачи заказчиков можно решить с помощью других языков легче и быстрее (квалифицированным разработчиком в компании с не менее квалифицированным администратором), но на PHP зачастую это будет дешевле — больше хостингов, больше разработчиков, больше готового кода. Значит больше конкуренция, значит цены меньше, значит у заказчика будут меньше первоначальные затраты на «вхождение» в веб.
Просто пишите на C!
Хороший совет.
Про любой язык можно написать много нехорошего.
Просто у людей есть баг в мышлении. Все эти усложнения в словах и фразах-определениях, вроде «фрактал плохого дизайна» — это наследники от базовых суперклассов «Плохо» и «хорошо» (или «черное» и «белое»).
В то же время, все обладает спектральными характеристика. Как звезды :)
И нужно соизмерять спектры.
А если писать только негатив, да еще и если не знаешь, что зачем сделано и как писать «с использованием языка» (С) Макконнел — будет звучать бредово.
Возьмем для примера самые популярные языки.
1. Java
— как это, язык без прямой работы с памятью? и вообще, он не компилируется, он… эээ… интерпретируется? да нет. он компилируется под специальную виртуальную машину, которая запущена как интепретатор… в общем, черт ногу сломит. поэтому и тормоза такие
— written once, runs everywhere. хороший миф. запустите мобильное приложение под j2ee и поржем вместе
— суперсложность. никогда не искали ошибку в megaPooP полдня? — вас еще ждут эти приятные часы.
2. C++
— утечка памяти. прямая работа с памятью не важна — вот, на яве пишут же миллионы мух, которые не могут ошибаться.
— совместимость с сями. не, ребята, это серьезно? и кто-то там еще пишет, что в пхп сохранились анахронизмы
— очень легкий порог вхождения, три тома книжек спецификации.
— указатели. 1001 способ выстрелить себе в ногу, в помощь программисту, что называется
— для более-менее нормальной работы нужно знать кучу либ, over9000 способов сделать одно и то же (зато в php много функций на каждый чих — это плохо)
— все прелести компиляции, сборки больших приложений
3. питон
— вы серьезно? ооп в языке, где нет приватных методов. ну тогда и си — это объектно-ориентированных язык, за счет Code conventions я могу писать на нем в ООП стиле, хаха
— отступы. форматирование кода отступами это насилие.
4. javascript
— три варианта реализации наследования. дальше можно не продолжать.
5. руби.
смотрим презентацию
www.destroyallsoftware.com/talks/wat
6. Lisp,Hascell
— что это? покажите мне Amazon.com работающий на них
Просто у людей есть баг в мышлении. Все эти усложнения в словах и фразах-определениях, вроде «фрактал плохого дизайна» — это наследники от базовых суперклассов «Плохо» и «хорошо» (или «черное» и «белое»).
В то же время, все обладает спектральными характеристика. Как звезды :)
И нужно соизмерять спектры.
А если писать только негатив, да еще и если не знаешь, что зачем сделано и как писать «с использованием языка» (С) Макконнел — будет звучать бредово.
Возьмем для примера самые популярные языки.
1. Java
— как это, язык без прямой работы с памятью? и вообще, он не компилируется, он… эээ… интерпретируется? да нет. он компилируется под специальную виртуальную машину, которая запущена как интепретатор… в общем, черт ногу сломит. поэтому и тормоза такие
— written once, runs everywhere. хороший миф. запустите мобильное приложение под j2ee и поржем вместе
— суперсложность. никогда не искали ошибку в megaPooP полдня? — вас еще ждут эти приятные часы.
2. C++
— утечка памяти. прямая работа с памятью не важна — вот, на яве пишут же миллионы мух, которые не могут ошибаться.
— совместимость с сями. не, ребята, это серьезно? и кто-то там еще пишет, что в пхп сохранились анахронизмы
— очень легкий порог вхождения, три тома книжек спецификации.
— указатели. 1001 способ выстрелить себе в ногу, в помощь программисту, что называется
— для более-менее нормальной работы нужно знать кучу либ, over9000 способов сделать одно и то же (зато в php много функций на каждый чих — это плохо)
— все прелести компиляции, сборки больших приложений
3. питон
— вы серьезно? ооп в языке, где нет приватных методов. ну тогда и си — это объектно-ориентированных язык, за счет Code conventions я могу писать на нем в ООП стиле, хаха
— отступы. форматирование кода отступами это насилие.
4. javascript
— три варианта реализации наследования. дальше можно не продолжать.
5. руби.
смотрим презентацию
www.destroyallsoftware.com/talks/wat
6. Lisp,Hascell
— что это? покажите мне Amazon.com работающий на них
Конструкция => базируется на Perl, который позвляет foo => 1 без квотирования(вот почему конструкция существует Perl; иначе вы можете просто использовать запятую.) В PHP вы не можете так сделать не получив предупреждение; PHP — единственный язык в своей нише, в котором нет проверенного способа создать хэш без квотирования строковых ключей.
А что, в Питоне есть проверенный способ для этого?
А что, в Питоне есть проверенный способ для этого?
Белки истерички.
Хорошо, что статья не затрагивает ООП аспекты этого чудесного языка pastebin.com/qS1TmreR :)
Хорошо, что статья не затрагивает ООП аспекты этого чудесного языка pastebin.com/qS1TmreR :)
Прикольно Оо
А в чём шутка? :) Что не выглядит очевидным поведением?
Никаких шуток. Тут показано, что не смотря на то, что в PHP ввели кучу всяких фишек вроде наследования, интерфейсов и тому подобного «ООП» толку от них мало, если тот, кто работает с твоим кодом без понятия о чем идет речь. Это хорошо подходит под пункт "PHP построен, чтобы продолжать фурычить при любых обстоятельствах." Я несколько раз сталкивался с подобным поведением в больших проектах — заменяем реализацию интерфейса и получаем полную лажу. Не знаю, как повлияет введение traits в 5.4, но мне думается, что это приведет к еще большему хаосу. Как идея traits хороши, но это сильно похоже на жесткий батхерт по поводу множественного наследования. А от того, как эту фичу станут использовать «домохозяйки» в будущем у меня на жопе волосы шевелятся… :)
Ну вообще на любом языке можно выстрелить себе в ногу :)
Если на PHP встречается много плохого кода это не значит, что иного быть не может.
И также не значит, что код на других языках всегда идеален.
Если уметь готовить трейтс, то типичные операции можно растащить по логическим блокам.
Хорошо это выглядит в mixins у Sencha ExtJS 4. Я думаю и в php можно использовать с умом :)
Если на PHP встречается много плохого кода это не значит, что иного быть не может.
И также не значит, что код на других языках всегда идеален.
Если уметь готовить трейтс, то типичные операции можно растащить по логическим блокам.
Хорошо это выглядит в mixins у Sencha ExtJS 4. Я думаю и в php можно использовать с умом :)
Я один прочитал на одном дыхании и только из комментариев узнал про «плохой перевод»?
Статья вдохновила программиста Wikimedia на создание того самого молотка: http://www.flickr.com/photos/raindrift/sets/72157629492908038/
подписываюсь под каждым словом.
3 года профессионально программировал на этом чудо-языке, зная C++ и параллельно интересуясь Java.
в итоге с большим облегчением пересел на Java (и частично Groovy), хотя из-за этого несколько потерял в карьере в тот момент.
3 года профессионально программировал на этом чудо-языке, зная C++ и параллельно интересуясь Java.
в итоге с большим облегчением пересел на Java (и частично Groovy), хотя из-за этого несколько потерял в карьере в тот момент.
Если allow_url_fopen выключен в php.ini, он тоже не будет работать.
ну а что тут такого, по-моему, это довольно логично.
ну а что тут такого, по-моему, это довольно логично.
статья классная, жгите! но выстелить себе в ногу можно на любом языке
Не знаю, не знаю.
Написали задорно, но по факту — по-моему большая часть этих нападок — мелочи.
Наоборот приятно же, когда язык не кидает исключение по любому поводу, а спокойно выбирает средне-логичное поведение (в питоне например str и long захотел сконкатенировать! ах негодяй!)
Да, я согласен, что и противоположная точка зрения вполне имеет право на жизнь. Но она называется строгая типизация. И если вы её приверженец, нефиг писать на скриптовых языках — пишите себе на java и не имейте проблем.
Написали задорно, но по факту — по-моему большая часть этих нападок — мелочи.
Наоборот приятно же, когда язык не кидает исключение по любому поводу, а спокойно выбирает средне-логичное поведение (в питоне например str и long захотел сконкатенировать! ах негодяй!)
Да, я согласен, что и противоположная точка зрения вполне имеет право на жизнь. Но она называется строгая типизация. И если вы её приверженец, нефиг писать на скриптовых языках — пишите себе на java и не имейте проблем.
Лучше пусть упадёт и даст мне знать, что с кодом что-то не так, чем выдаст «непонятно что».
Весь вопрос в той границе, где начинается «непонятно что» и «что-то не так». В статически типизированных языках она ближе, в динамических — она дальше. В некоторых динамических она дальше, чем в других, и это достаточно удобно (иначе бы не существовало). А хочешь, чтобы тебе язык падал при попытке сравнить «11» и 11 — пиши на яве / скале какой-нибудь, и не будет проблем.
Что это была за хипстерская обвм-ная хуета ???
Я капризный. Я жалуюсь о многих вещах. Многое в мире технологий мне не нравится и это предсказуемо: программирование — шумная молодая дисциплина, и никто из нас не имеет ни малейшего представления, что он делает. Учитывая закон Старджона, у нас достаточно вещей для постижения на всю жизнь.
Вот что это ухаха?
Я капризный. Я жалуюсь о многих вещах. Многое в мире технологий мне не нравится и это предсказуемо: программирование — шумная молодая дисциплина, и никто из нас не имеет ни малейшего представления, что он делает. Учитывая закон Старджона, у нас достаточно вещей для постижения на всю жизнь.
Вот что это ухаха?
Даю студентам при прохождении у нас практики или стажировки этот текст на конспектирование в качестве первой контрольной работы.
Прошу прощения за никропостинг, но решил проверить эту конструкцию:
Вполне разумно, что вернул horse. Потому, что если упростить написанное, то это равно:
А конструкцию которую указал автор, в PHP правильно написать так:
$arg = 'T';
$vehicle = ( ( $arg == 'B' ) ? 'bus' :
( $arg == 'A' ) ? 'airplane' :
( $arg == 'T' ) ? 'train' :
( $arg == 'C' ) ? 'car' :
( $arg == 'H' ) ? 'horse' :
'feet' );
echo $vehicle;
Вполне разумно, что вернул horse. Потому, что если упростить написанное, то это равно:
$test = 1 == 2 ? false : true ? 'Потому, что результат выражения (1 == 2 ? false : true) равен true': 'Будет если вместо true указать false';
А конструкцию которую указал автор, в PHP правильно написать так:
$arg = 'T';
$vehicle = $arg == 'B' ? 'bus' : (
$arg == 'A' ? 'airplane' : (
$arg == 'T' ? 'train' : (
$arg == 'C' ? 'car' : (
$arg == 'H' ? 'horse' : 'feet'
)
)
)
);
echo $vehicle;
Потому что в любых других языках, начиная с Си, скобки для этого результата добавлять не нужно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PHP: фрактал плохого дизайна