Comments 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 несколько лет и в сыром подвале. Потом его спасла полиция и вся эта статья — исповедь перед журналистами. Для чего потрачено столько времени?
Вы знаете. Не промтом. Вручную. Над процитированным предложением долго бился, а вот с родом и правда промахнулся. Ща поправим.
Не обижайтесь, но по-моему, здесь тот случай, когда проще «сделать заново», нежели исправить.
Забейте на всех этих умников — они просто завидуют, что Вы смогли сделать такой здоровенный кусок работы, а они нет. Я прочитал с удовольствием, спасибо за перевод.
Да бросьте вы.
Сделать много работы и сделать много работы хорошо — разные вещи. Не понимаю, чего все так переводчика защищают. Или вам плевать, что вам предлагают к прочтению? Как можно «с удовольствием читать» несогласованные предложения, где смысл не всегда понятен?
Сделать много работы и сделать много работы хорошо — разные вещи. Не понимаю, чего все так переводчика защищают. Или вам плевать, что вам предлагают к прочтению? Как можно «с удовольствием читать» несогласованные предложения, где смысл не всегда понятен?
Нам не плевать. Вот мы вместо того, чтобы судачить об этом скидываем в личку переводчику багованые места. И по-тиху статья становится лучше.
Мне не наплевать на то, что я читаю. Если взялся переводить, то делай это хорошо. Лично я не вижу никаких подов исправлять чужой перевод. По-моему, в наше время, можно любой текст перевести без проблем, при этом владея только тем языком, на который осуществляется перевод.
В общем ладно, продолжайте хвалить другу друга и заниматься обоюдным вытиранием соплей. В нашей стране так принято — человека стоит хвалить за одно только желание что-то делать. Качество результата второстепенно. Толерантность и кармодрочество хабра возводят все это в степень.
В общем ладно, продолжайте хвалить другу друга и заниматься обоюдным вытиранием соплей. В нашей стране так принято — человека стоит хвалить за одно только желание что-то делать. Качество результата второстепенно. Толерантность и кармодрочество хабра возводят все это в степень.
У нас тут вообще-то сообщество. Если нашел ошибку или неточность — сообщи автору в лс. Никто никому ничего не обязан. Ишь ты, не нравится ему перевод.
Да, простите. Я забыл, что быть нем-то недовольным запрещено. Нужно всем широко улыбаться и говорить спасибо даже за то, что в принципе внимания не достойно.
Есть такой принцип в мире opensource: «Открывать рот может только тот, кто что-то сделал». Если бы у Вас в профиле висел десяток грамотных переводов и значок «Переводчика» — Ваши замечания были бы приняты и имели бы смысл. Заявления «Надо делать хорошо! Я вот ничего не сделал, но если бы сделал — это было бы сделано ужасно круто» — Вы сами слышите как звучат.
Перевод статьи из разряда «Язык программирования @name@ — говно» — это opensource? Выходить, всем известное слово из трех букв, написанное на заборе — тоже 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, на работу не берут, ибо диагноз)
PHP тоже выдаст два предупреждения (Notice) в этом случае (в логи или прямо на странице, смотря как настроено). Исключение не выбросит, но в случае PHP его и не должно быть, я считаю.
я пишу use strict четвертой строчкой. пора увольняться? :)
#!/usr/bin/perl
use warnings;
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 фрилансеры нанятые человеком не разбирающимся в вопросе.
Ну клиент будет сравнивать именно 2 предложения. И первое выглядит заманчивее. А что бы второе стало интереснее вам пришлось написать 6 абзацев текста.
Все ваши плюсы не относятся к языку программирования, а к сложившейся на рынке ситуации. И, как мне кажется, автор оригинальной статьи исходит гневом именно по той причине, что наибольшее инфраструктурное преимущество имеет язык с одним из худших дизайнов. Это… огорчает.
Однако авторы подобных статей — не конструктивны. На тему того, что 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ку практически за старые заслуги.
Я просто не мог понять, как это работает. А нужно было не пытаться понять, а просто потыкать мышкой. И написать пару строчек кода в в месте обозначенном на лекциях (на которые я, ессно, не ходил). Потом, уже после интститута мне приходилось чинить чужие аксесовские прилады… Практически методом тыка.
Так что пхп на этом фоне логичен, в конце концов не всё заимствованное с перла (который, как не удивительно, весьма логичен) «упрощено для лучшего понимания».
А наличие готовых конструкторов, которые не надо понимать, а надо только поставить и немного настроить, равно как и громадное количество хостингов заточенных под пхп — это то что делает пхп непотопляемым.
Если уж брать что-то что ты непонимаешь, как работает (к чему зачастую приходят вполне логичные и понятные проекты, начинающиеся с легкого фреймворка вне зависимости от языка), то лучше брать то у чего болшеекомьюнити… И менее заносчивое комьюнити, кстати.
Я просто не мог понять, как это работает. А нужно было не пытаться понять, а просто потыкать мышкой. И написать пару строчек кода в в месте обозначенном на лекциях (на которые я, ессно, не ходил). Потом, уже после интститута мне приходилось чинить чужие аксесовские прилады… Практически методом тыка.
Так что пхп на этом фоне логичен, в конце концов не всё заимствованное с перла (который, как не удивительно, весьма логичен) «упрощено для лучшего понимания».
А наличие готовых конструкторов, которые не надо понимать, а надо только поставить и немного настроить, равно как и громадное количество хостингов заточенных под пхп — это то что делает пхп непотопляемым.
Если уж брать что-то что ты непонимаешь, как работает (к чему зачастую приходят вполне логичные и понятные проекты, начинающиеся с легкого фреймворка вне зависимости от языка), то лучше брать то у чего болшеекомьюнити… И менее заносчивое комьюнити, кстати.
UFO just landed and posted this here
Вот это и удивительно — как майрософт ухитрился сделать среду разработки, интуитивно понятную новичкам и «убивающую» спецов, привыкших «копать глубже».
Формы, кстати фигня, — вот система функций там отдельная песня. Как их можно так назвать и организовать, что поиск нужного выливался в квест? Наверно шаманы работали.
Формы, кстати фигня, — вот система функций там отдельная песня. Как их можно так назвать и организовать, что поиск нужного выливался в квест? Наверно шаманы работали.
Хнык. Хнык.
*ушел дальше заниматься говенной работой*…
А где я тут в долбаном захолустье найду вакансию 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, а в том что он умалчивает о возможности его эффективного применения там, где это уместно.
О том, чем PHP хорош и так кричат на каждом углу.
Возможно автора, как и многих, задолбало именно засилье евангелистов-недоучек, которые выучили 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 со всеми вытекающими, такова правда жизни. В таком контексте статья выглядит абсолютно бестолково.
Потому что вордпресс или друпал можно просто залить на шаред-хостинг за пару баксов, да и на вдске не проблема поднять, не говоря о денвере? И можно «хелловорд» во «все интернеты» выложить без проблем?
Лол, по питону обычно рекомендуют не «питон за шесть часов», а «Dive in the python» и PEP-ы.
А за 6 часов лучше действительно PHP изучить для галочки и забыть.
А за 6 часов лучше действительно PHP изучить для галочки и забыть.
По-моему как раз наоборот, везде пишут, что НЕ надо разрабатывать на PHP, что Python/Ruby/NodeJS это модно и круто, но дешёвый хостинг и огромное количество готового кода берёт своё.
UFO just landed and posted this here
как зачем? зависть =) и жадность =)
Мне кажется, это просто страдание человека, не безразличного к вопросу дизайна языков о том, что ЭТО смогло стать лидером рынка.
Это же как надо ненавидеть PHP, чтобы столько написать :-D
Я гналась за вами три километра, чтобы сказать, как вы мне безразличны! © не знаю откуда
Принцесса
Три дня я гналась за вами. Только в бурю потеряла ваш след, встретила охотника и пошла к нему в ученики.
Медведь
Вы три дня гнались за мной?
Принцесса
Да! Чтобы сказать, как вы мне безразличны.
Шварц, «Обыкновенное чудо»
Три дня я гналась за вами. Только в бурю потеряла ваш след, встретила охотника и пошла к нему в ученики.
Медведь
Вы три дня гнались за мной?
Принцесса
Да! Чтобы сказать, как вы мне безразличны.
Шварц, «Обыкновенное чудо»
«Обыкновенное чудо».
«Я бежала за вами три дня и три ночи, чтобы сказать вам как вы мне безразличны». Цитата на память, могу чуть исказить.
«Я бежала за вами три дня и три ночи, чтобы сказать вам как вы мне безразличны». Цитата на память, могу чуть исказить.
А мне ссылочки понравились, полистаю на досуге: )
Пришла мысль, она может быть не в тему, но выскажу.
Наверняка, можно написать такую же статью про русский язык.
Наверняка, можно написать такую же статью про русский язык.
- множество заимствований из других языков (бордюр, компьютер ...);
- множество исключений (оловянный, деревянный и т.п.);
- множество слов, в которых нельзя проверить согласные ударением;
- существуют слова, которые нельзя поставить в определённую форму(победю, пылесосу ...);
- … ;
а чем «пылесошу» плохо?
Понимаете ли, естественные языки развиваются эволюционно. И только по этой причине имеют столько исключений. В то время как искусственный язык проектируется. Хотя мне иногда, что в случае PHP это не совсем верно :)
* мне иногда кажется
Я думаю, что тут можно с уверенностью сказать, что PHP изначально не проектировался вообще.
UFO just landed and posted this here
Не стоит рассматривать естественные языки как нечто совершенное.
Почитайте хотя бы юридические тексты — имхо, неплохая аналогия «программированию» на естественном языке.
Почитайте хотя бы юридические тексты — имхо, неплохая аналогия «программированию» на естественном языке.
И ещё, многие любят русский язык за его исключительность…: )
Это можно написать про любой естественный язык. Во всех есть странности, несогласованности и различные недостатки…
Да уж, это вам не эсперанто, но почему-то мало желающих его изучать, парадокс человеческой психики.
Автор маньяк. Да и переводчик
Кто может объяснить заголовок статьи? Хотел перевести эту статью просто так, для себя. Но сдался на заголовке. Дословно переводить не хотелось.
Фрактал — самоподобная фигура, то есть PHP — плох по дизайну весь так же, как плоха по дизайну каждая его составляющая?
Фрактал — самоподобная фигура, то есть PHP — плох по дизайну весь так же, как плоха по дизайну каждая его составляющая?
UFO just landed and posted this here
Нет, он имел в виду, что чем глубже закапываешься, тем больше ошибок вылазит
тут больше имеется ввиду такого рода фракталы:
Намек на то, что весь дизайн языка — одна сплошная дырка.
Намек на то, что весь дизайн языка — одна сплошная дырка.
Берем статью, делаем выдержки, и… задаем вопросы на собеседовании ;)
даже на таких граблях
сколько раз падали. Вопросы мот по круче патернов программирования будут, и многая специфика языка открывается.
даже на таких граблях
"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.
Ну двойная вложенность-то может быть? И проблема имеет место быть. А пример выполнен как гипербола, но смысл проблемы он не искажает.
UFO just landed and posted this here
т.е. использование старого нерекомендуемого модуля (mysql) или неверное использование новых инструментов (mysqli, pdo etc) новичками — это вина языка?
UFO just landed and posted this here
Хорошо так говорить, когда другие языки могут учиться на чужих ошибках. Данный модуль создавался давно и расчитан был на старый функционал и защиту скриптов самим программистом.
В данном случае модулем до сих пор пользуются огромное количество программистов, либо новичков, либо тех, кто ведет старые проекты. PHP не может взять и выкинуть модуль. Разработчики плавно отучают пользователей от него (первый этап — только обновления безопасности и обновление документации, дальше — больше).
Поэтому 1) вина в появлении — может быть, но такое есть во всех языках — программист может выстрелить в ногу тысячами способов.
2) PHP не поддерживает больше данный модуль, только обновления безопасности
Поэтому в целом я все равно считаю, что подобные вопросы от новичков — не вина языка.
В данном случае модулем до сих пор пользуются огромное количество программистов, либо новичков, либо тех, кто ведет старые проекты. PHP не может взять и выкинуть модуль. Разработчики плавно отучают пользователей от него (первый этап — только обновления безопасности и обновление документации, дальше — больше).
Поэтому 1) вина в появлении — может быть, но такое есть во всех языках — программист может выстрелить в ногу тысячами способов.
2) PHP не поддерживает больше данный модуль, только обновления безопасности
Поэтому в целом я все равно считаю, что подобные вопросы от новичков — не вина языка.
UFO just landed and posted this here
Хорошо так говорить, когда другие языки могут учиться на чужих ошибках.Я ни с кем ни о чём не спорю, однако отмечу, что Пайтон появился в 1991, Руби и PHP в 1995.
>>Хорошо так говорить, когда другие языки могут учиться на чужих ошибках.
… а некоторые — не могут
… а некоторые — не могут
Если быть точным, истоки Python Гвидо создал на новогодних каникулах '89 :)
Автор указывает, что документация тоже не сахар :)
Ну это спорный вопрос, если человек даже не задумывается над безопасностью своего кода… Такое можно написать на любом языке, вот вам на руби:
@user = User.find_by_username("#{params[:username]}")
UFO just landed and posted this here
Да, правильней написать можно например так:
Тогда переменная не летит напрямую в БД, как в первом варианте. Говнокод — всегда говнокод.
User.where("username = ?", params[:username])
Тогда переменная не летит напрямую в БД, как в первом варианте. Говнокод — всегда говнокод.
UFO just landed and posted this here
Не могу судить про новичков в руби, сам такой) Но по личному впечатлению, само комьюнити как-то подталкивает искать верные и красивые решения, покрывать код тестами.
в творениях на Руби говнокода ещё побольше будет. Но не потому, что язык плохой, а потому, что есть 100500 способов сделать одно и то же действие. И новичку нужно время, чтобы попробовать их все и придти к своему стилю.
UFO just landed and posted this here
Собирайтесь, и не верьте про «говнокода еще побольше будет». Такого как во внутренностях джумлы вы там не встретите никогда :)
Если вы кодите на Python, то непонятно зачем вам вообще Руби.
Частично соглашусь, увлёкшись метапрограммированием можно страшного наворотить :)
А вот обилие вариантов делания одного и того же на самом деле огромнейший плюс, позволяющий писать 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/ — вот целая куча всякого, типа того, что описано в этом топике про ПХП
UFO just landed and posted this here
UFO just landed and posted this here
В JS ярчайшие проблемы с архитектурой.
Имеющие, кстати, теже самые корни, что и у PHP — делали изначально одно, а потом периодически поверх накручивали совершенно другое.
Имеющие, кстати, теже самые корни, что и у PHP — делали изначально одно, а потом периодически поверх накручивали совершенно другое.
Да ладно… взять ту же область видимости переменных ограничиваемой функциями — я потерял много часов жизни пока с этим не разобрался. Бредовая идея вообще.
Неоднозначность strict синтаксиса, то есть он вроде бы есть, но им мало кто знает как пользоватся.
ООП непривычное, причём до такой степени что многие эмулируют привычное ООП создавая тормоза и путанницу.
Постоянные заботы об преждевременной оптимизации, что портит нас как программистов. Ибо в firefox — unshift невероятно медленный, а в других браузерах всё ок, вот и тратишь время на всякую чепуху…
Однопоточный интерпретатор, что не является таким уж и большим благом.
да можно ещё продолжать, просто время тратить неохота… не в тему распыляться…
Неоднозначность strict синтаксиса, то есть он вроде бы есть, но им мало кто знает как пользоватся.
ООП непривычное, причём до такой степени что многие эмулируют привычное ООП создавая тормоза и путанницу.
Постоянные заботы об преждевременной оптимизации, что портит нас как программистов. Ибо в firefox — unshift невероятно медленный, а в других браузерах всё ок, вот и тратишь время на всякую чепуху…
Однопоточный интерпретатор, что не является таким уж и большим благом.
да можно ещё продолжать, просто время тратить неохота… не в тему распыляться…
UFO just landed and posted this here
UFO just landed and posted this here
Я это понял и разобрался, просто спросили про типичные проблемы языка, я их частично озвучил. И с этой проблемой сталкивались все кого я знаю, причём не все они разобрались и пишут ужаснейший говнокод на JS и по сей день.
UFO just landed and posted this here
Почему же, я тут вижу логическое несоответствие.
Что есть по сути функция?
Это именованный блок кода.
Так почему же именованный блок кода создают «область действия переменной», а обычные блоки кода нет?
Про это часть перевода автора топика, кстати, посвящена, хе-хе…
Что есть по сути функция?
Это именованный блок кода.
Так почему же именованный блок кода создают «область действия переменной», а обычные блоки кода нет?
Про это часть перевода автора топика, кстати, посвящена, хе-хе…
UFO just landed and posted this here
Несмотря на это в джаваскрипт есть переменные которые являются достоянием парадигмы императивного программирования и работают они не так как везде и внятного оправдание именно такого способа их работы я не вижу.
В том же эрланге отлично обходятся без переменных вообще (точнее там есть альясы, но изменять их значение нельзя), вот это ПРЕДСКАЗУЕМОЕ поведение функционального ЯП. А в джаваскрипте непойми что.
В том же Perl область видимости переменных ограничивается блоками и никакого дискомфорта от функционального подхода при программировании на Perl лично я не испытал.
P.S. Ещё раз выделю мысль: «вы так и не объяснили, почему так как сделали в JS — правильно и логично».
В том же эрланге отлично обходятся без переменных вообще (точнее там есть альясы, но изменять их значение нельзя), вот это ПРЕДСКАЗУЕМОЕ поведение функционального ЯП. А в джаваскрипте непойми что.
В том же Perl область видимости переменных ограничивается блоками и никакого дискомфорта от функционального подхода при программировании на Perl лично я не испытал.
P.S. Ещё раз выделю мысль: «вы так и не объяснили, почему так как сделали в JS — правильно и логично».
В cpp и ещё сотне языков блоки создают отдельный контекст, в питоне и ещё сотне не создают. какая разница, причём тут логично?
Логично что и именованный блок и анонимный по сути одно и тоже, потому разумно ожидать что и с переменными они работают одинаково.
P.S. кстати, а как в питоне дела обстоят с этим?
P.S. кстати, а как в питоне дела обстоят с этим?
но функция не просто именованный блок (к тому же она может и неименованной быть :) ).
функция объект, её можно куда-нибудь передавать, вызывать и т.д. простой блок нельзя. и контекст, соответственно, создаётся в момент вызова функции.
функция объект, её можно куда-нибудь передавать, вызывать и т.д. простой блок нельзя. и контекст, соответственно, создаётся в момент вызова функции.
Про объект согласен, это уже похоже на разумное объяснение такого поведения, но опять же могли бы сделать блоки кода анонимными функциями (и тоже объектами), тогда бы эта неоднозначность работала бы как в си подобных языках, разве нет?
На каждый каждый блок плодить объекты, скоп и всё такое, а язык и так не быстрый. Ну и создавался изначально для простых вещей. Большинство «программистов» до сих пор не знают ни про «var» ни про то, что функция объект.
В ES5 по-моему можно будет в блоках объявлять переменные.
В ES5 по-моему можно будет в блоках объявлять переменные.
Функция не просто именованный блок:
— у неё могут быть параметры
— она может быть быть вызвана
— она является объектом, с прототипом, со всеми вытекающими
— у неё могут быть параметры
— она может быть быть вызвана
— она является объектом, с прототипом, со всеми вытекающими
А в питоне с этим тоже не без приколов:
«чтение переменной» будет обращаться к внешней области видимости.
«присваивание переменной» («создание алиаса») формирует новую локальную переменную.
Из-за этого такие заморочки:
stackoverflow.com/questions/370357/python-variable-scope-question
«чтение переменной» будет обращаться к внешней области видимости.
«присваивание переменной» («создание алиаса») формирует новую локальную переменную.
Из-за этого такие заморочки:
stackoverflow.com/questions/370357/python-variable-scope-question
но этот язык изначально был расчитан на нубов, ещё больше чем PHP. Там даже точки с запятыми сделали необязательными, чтобы прогеры-верстальщики не перенапряглись.
Область видимости переменной — вся функция, а не блок? Такая идея в функциональных языках?
UFO just landed and posted this here
Ежики плакали, кололись...? Зачем форкать «старый херовый PHP»?
Нет, ну швейцарский нож классный инструмент, но молоток лучше гвозди забивает, а пила лучше дерево пилит. Я к тому, что как инструмент создания динамических веб сайтов, PHP вместе со всеми своими косяками на ура работает, и все эти ваши интернеты тому доказательство.
UFO just landed and posted this here
Ого, у кого-то серьезный баттхёрт. Ну и ладно, пойду дальше писать свои дэйтинги…
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!
UFO just landed and posted this here
Вполне удобно, но только для маленьких проектов на мой взгляд, ибо чтобы изменить роутинг надо будет файлы переименовывать, это на мой взгляд менее удобно чем один файлик поправить, а как там динамические маршруты строятся (где вместо какого-либо уровня может быть выбор из нескольких вариантов)?
UFO just landed and posted this here
Опять же, вы показали что проблема удобности в 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, без изменения его концепции?»
UFO just landed and posted this here
Подсказка HTML::Mason — тот же ПХП вид сбоку. Только очень шустрый, перловый и со средствами организации проектов.
Минусы не прост в настройке — по крайней мере ветка 1.x. Ставился так бы легко как ПХП… на нём было бы море говнокода.
Минусы не прост в настройке — по крайней мере ветка 1.x. Ставился так бы легко как ПХП… на нём было бы море говнокода.
UFO just landed and posted this here
Ну это неудивительно — если язык считает, что вы всегда сами знаете, что делаете, то… эту ответственность надо оправдывать, а не злоупотреблять. А злоупотреблять проще. Оно же работает… как-то…
Питон, кстати, после перла бесил неимоверно. Он то как раз считает. что вы не знаете что делаете, поэтому надо постоянно кричать «сюда нэ хади, снег бошка упадёт...» (с)
Блин, да не хочу я чтобы исчезал 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 сайты сейчас вовсем не удобно (и небезопасно).
UFO just landed and posted this here
И писать на чистом 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 за полчаса с нуля написал приложение, что меня очень сильно удивило.
PHP: фрактал плохого дизайна