Комментарии 667
Сломал глаза пока прочитал. Разбивайте на абзацы в следующий раз — читать проще будет.
я именно из-за этого больше 2 строк не осилил. Пост, возможно, интересен, но читать в таком виде невозможно.
А вам эти 2 строки на несколько абзацев надо было разбить? :D
НЛО прилетело и опубликовало эту надпись здесь
Вот теперь понятно.
В топике от силы 2-3 агрессивных фаната php, да и обороняться у них получается довольно вяло.
Ничего, зато мне уже наобъясняли, что лично я — типичный неосилятор. :)
Сложно спорить о языке, когда в качестве аргументов приводят библиотеки в язык не входящие.
Эти библиотеки рождаются благодаря качествам языка.
В PHP тоже есть библиотеки :) И ещё неизвестно где их больше
Явно, вы не пробовали действительно работать с ними на языках помимо php(если говорить о вебе).
Тот же phpclasses.org и pear/pecl не сравнятся с rubygems. До руби я много и писал на php, и мне есть с чем сравнивать.
Чёрт, не обновил страницу, теперь понял что вы имеете в виду. Не думаю, что если я начну писать на ruby, то я стану активно пользоваться rubygems, как не пользуюсь активно pear/pecl (только для зависимостей интересных проектов, типа phpdaemon, то есть если в install guide такого проекта содержится pear something). Есть задача — я её решаю, а не ищу путей как её не решать.
Ну и не правильно. Это просто пхпшная привычка, от которой лучше избавиться как можно скорее. PEAR/PECL тоже не использовал. Но в руби и питоне с распространением пакетов все настолько лучше, чем в php, что даже сравнивать сложно. Совершенно не представляю, как можно писать на том же питоне без pypi, это мазохизм какой-то получится.
Конечно в похапе. Судя по всему каждый студент считает обязательным написать свою библиотеку вместо того, чтобы взять готовую. Правда большинство этих библиотек не доступно публики, но от этого только лучше.
>Судя по всему каждый студент считает обязательным написать свою библиотеку вместо того, чтобы взять готовую.
Ещё каждый «студент» считает обязательным написать свою CMS, а с относительно недавних пор — фреймворк. И что в этом плохого? Я вот потихоньку пишу свой фреймворк на python для GAE. Пытался подключиться к одному open-source проекту, но моими идеями о том, каким должен быть роутинг (похожим на роутинг symfony/ror) не прониклись, например посчитали что описывать метод запроса в роутинге излишне, а ведь без этого неудобно реализовывать RESTful приложения — каждый метод превращается в цепочку if request.method == 'GET':… elif request.method == 'PUT'… elif request.method == 'POST'… elif request.method == 'DELETE'… else response = HTTPNotSupported()
Ещё каждый «студент» считает обязательным написать свою CMS, а с относительно недавних пор — фреймворк. И что в этом плохого? Я вот потихоньку пишу свой фреймворк на python для GAE. Пытался подключиться к одному open-source проекту, но моими идеями о том, каким должен быть роутинг (похожим на роутинг symfony/ror) не прониклись, например посчитали что описывать метод запроса в роутинге излишне, а ведь без этого неудобно реализовывать RESTful приложения — каждый метод превращается в цепочку if request.method == 'GET':… elif request.method == 'PUT'… elif request.method == 'POST'… elif request.method == 'DELETE'… else response = HTTPNotSupported()
В том, что студент еще не разобрался в языке нормально (пишет говнокод), не осилил готовую cms/framework(ниасилятор) и пишет свое унылое поделие.
Алсо, а что в писоне нет switch?
Алсо, а что в писоне нет switch?
Если пишет библиотеку, это уже не говнокод, соблюдает «межпроектный» DYI :)
По-моему, часто встречаются жалобы на то, что «асиляторы» не знают языка, не представляют как работает то, что они «асилили», искренне удивляются, когда в другой CMS не работает, например, какая-то «магия» типа использования шаблона с именем, совпадающим с именем контроллера/модуля.
Нет и, видимо, не будет. Да и проблему он бы не решил
По-моему, часто встречаются жалобы на то, что «асиляторы» не знают языка, не представляют как работает то, что они «асилили», искренне удивляются, когда в другой CMS не работает, например, какая-то «магия» типа использования шаблона с именем, совпадающим с именем контроллера/модуля.
Нет и, видимо, не будет. Да и проблему он бы не решил
*DRY
Чтобы написать библиотеку для ruby надо как миниум понять суть gem'ов и то как на реализовать это на ruby. Банально сразу и с места говнокод писать не получится. :D да и то, что код будут видеть другие дает о себе знать.
>часто встречаются жалобы на то, что «асиляторы» не знают языка,
Правильно, они не осилил язык, а начали сразу с фрэимворка. недоосилили фрэимворк и начали клепать говно-код.
Про switch это печально. Хотя если бы его реализовали тупо так же как if — в нем нет смысла.
>часто встречаются жалобы на то, что «асиляторы» не знают языка,
Правильно, они не осилил язык, а начали сразу с фрэимворка. недоосилили фрэимворк и начали клепать говно-код.
Про switch это печально. Хотя если бы его реализовали тупо так же как if — в нем нет смысла.
так а зачем он в языке?
на мой взгляд вполне себе switch ))
processedRequest = {
'GET': getFunc,
'POST': postFunc,
'PUT': putFunc,
'DELETE' : delFunc
}.get(requestMethod,defaultFunc)(request)
на мой взгляд вполне себе switch ))
Затем, что в нормальных языках (си например) switch разворачивается в низкоуровневое сравнение которое быстрее if'a. Алсо, этого примера у меня кровоточат глаза, как я понимаю тут используется словарь и аноанимные функции, это как бы совсем не оптимально. Я конечно понимаю, что сейчас можно не экономить на памяти и процессоре, но не до такой же степени!
p.s.
Так и представляю подобный код вашим методом:
gist.github.com/759642
p.s.
Так и представляю подобный код вашим методом:
gist.github.com/759642
пример однако вы подобрали ))
да словарь, единственное в данном примере функции не анонимные.
На самом деле подобные конструкции на практике используются довольно редко, что в общем вполне оправданно, но если вдруг надо, то возможность есть.
Примером я скорее хотел показать то, что нет никакой надобности все подряд встраивать в язык. Очень много вещей при необходимости можно очень быстро реализовать собственно средствами которые язык предоставляет.
Кстати, не оспаривая преемуществ Си — Пайтон вполне себе нормальный язык, подходящий для очень многих вещей.
да словарь, единственное в данном примере функции не анонимные.
На самом деле подобные конструкции на практике используются довольно редко, что в общем вполне оправданно, но если вдруг надо, то возможность есть.
Примером я скорее хотел показать то, что нет никакой надобности все подряд встраивать в язык. Очень много вещей при необходимости можно очень быстро реализовать собственно средствами которые язык предоставляет.
Кстати, не оспаривая преемуществ Си — Пайтон вполне себе нормальный язык, подходящий для очень многих вещей.
А что, живой пример из проекта :D Правда сейчас заменил этот кусок полностью.
Суть switch'a в том, что в языках типа C, C# switch компилируется в более быстрый код (опять же зависит от ситукции). Вот даже шютка к теме: www.rsdn.ru/forum/cpp/3957942.flat.aspx
В Python'e как и в Ruby есть столько не нужной хрени, а вы говорите, что switch не нужен. Ваш пример архи не читаемый и надо заниматься JumpToDefinition гимнастикой. Мой же код более читаемый (видели бы этот же кусок с if'ами вместо swich/case). И еще, мы же забываем, что на ruby и python можно не только web приложения писать. Я теперь не могу когда десктопные приложения жрут памяти больше чем надо.
В вашем примере конечно и эта конструкция нормально смотрится(хоть и трудночитаемая), но не все же этим примером ограничивается. Например мой пример если написать со словарем — будет очень по-наркомански и не читаемое.
Суть switch'a в том, что в языках типа C, C# switch компилируется в более быстрый код (опять же зависит от ситукции). Вот даже шютка к теме: www.rsdn.ru/forum/cpp/3957942.flat.aspx
В Python'e как и в Ruby есть столько не нужной хрени, а вы говорите, что switch не нужен. Ваш пример архи не читаемый и надо заниматься JumpToDefinition гимнастикой. Мой же код более читаемый (видели бы этот же кусок с if'ами вместо swich/case). И еще, мы же забываем, что на ruby и python можно не только web приложения писать. Я теперь не могу когда десктопные приложения жрут памяти больше чем надо.
В вашем примере конечно и эта конструкция нормально смотрится(хоть и трудночитаемая), но не все же этим примером ограничивается. Например мой пример если написать со словарем — будет очень по-наркомански и не читаемое.
Ну в примере без свитча будет лучше. Словарик с данными и готово, раза в полтора меньше печатать (и читать). Плюс код будет говорить за себя — структура инициализируетя разными данными в зависимости от значения переменной, данные отдельно, код отдельно. Банальность скажу, но свитч — один из косвенных признаков дурно пахнущего кода по Фаулеру. А про процессор — там же и правда такие копейки, о которых и говорить не стоит.
полностью согласен.
Не оптимально же. Словарик с данными медленнее jump table и больше памяти тратит. Код не говорит за себя, код вызывает кровотечение из глаз.
>А про процессор — там же и правда такие копейки, о которых и говорить не стоит.
А теперь представьте побольше вероятных исходов. И сделайте вот это: gist.github.com/759692
>А про процессор — там же и правда такие копейки, о которых и говорить не стоит.
А теперь представьте побольше вероятных исходов. И сделайте вот это: gist.github.com/759692
Да ладно, необходимо? С таким же успехом можно сказать, что чтобы написать библиотеку на php нужно понять суть pecl/pear. Говнокод выкладывать на гуглкод, гитхаб и т. п. никто не запретит (на rubygems есть премодерация проектов?).
Сколько в этой (да и других темах) не общаюсь по поводу «говнокода» никто мне не назвал язык, который его запрещает синтаксисом. Язык, в котором как ты не извращайся, конечное приложение будет идеальным для любых условий. Идеология, %xxx% way, coding styles guide и т. п. дают лишь рекомендации, следовать им или нет выбор программиста.
Сколько в этой (да и других темах) не общаюсь по поводу «говнокода» никто мне не назвал язык, который его запрещает синтаксисом. Язык, в котором как ты не извращайся, конечное приложение будет идеальным для любых условий. Идеология, %xxx% way, coding styles guide и т. п. дают лишь рекомендации, следовать им или нет выбор программиста.
Необходимо.
Для руби библиотеки в 90% случаев поставляются в виде rubygems. В противном случае вас просто не найдут(через тот же gem search -r %keyword%)
Для руби библиотеки в 90% случаев поставляются в виде rubygems. В противном случае вас просто не найдут(через тот же gem search -r %keyword%)
зато у вас — нападать получается вообще никак ) без улыбки ваши комменты не прочитаешь
Я накололся на том, что «автоматическое разбиение на абзацы» это «сохранение форматирования». На blog.dinexi.ru/2008-12-23/zhrecy-programmirovaniya/ всё нормально.
Скопировал, отформатировал и прочитать в редакторе :)
Странно: уже давно разбил на абзацы, а Вас всё плюсуют и плюсуют. :)
пхп привлекает людей зарабатывающего деньги типа, не надо философии разводить. да, пхп кривоват, но такого уж особого множества фактов, которые необходимо помнить в нем нет.
Ложь. Очень много свободных проектов с открытым кодом пишется на PHP.
ну и что? посыл статьи — пхп привлекает запоминателей, а не аналитиков. мой ответ — это деление тут не при чем, потому что программирование — это в первую очередь бизнес, а не разгадывание шарад. то есть независимо от типа мышления человек будет на нём программировать и аналитику будет легче, чем запоминателю. как, впрочем, и при программировании на любом другом языке.
Вот PHP с разгадыванием шарад сопряжён гораздо сильнее, нежели тот же python. Его я, к слову, привожу в качестве совершенно абстрактного языка, который не php; а то тут ещё джихад на тему PHP vs Python начнётся.
Вон, пример, который я привёл в habrahabr.ru/blogs/php/110767/#comment_3527319: шарада? Однозначно. Бизнес от этого пострадает? Пострадает, времени на эту багу убито было э… много.
Вон, пример, который я привёл в habrahabr.ru/blogs/php/110767/#comment_3527319: шарада? Однозначно. Бизнес от этого пострадает? Пострадает, времени на эту багу убито было э… много.
насчет багов кто бы спорил, однако этот аргумент с посылом статьи никак не связан
Так и про бизнес в статье нигде не говорилось. Это же не помешало Вам отмахнуться от моих слов коротким «Ну и что?» :-)
ну так мы не рассматриваем сферических разработчиков в вакууме, а реальные программисты пишут на том, на чем требует рынок и в вебе это пхп. и мотив у них вовсе не «ой какой чудо язык для моего аналитического ума с удивительно логичным именованием функций».
открытые проекты пишутся тоже не без профита (пусть это не деньги, а лишь всеобщий почет и уважение, что, впрочем, в конечном итоге тоже легко конвертируется).
открытые проекты пишутся тоже не без профита (пусть это не деньги, а лишь всеобщий почет и уважение, что, впрочем, в конечном итоге тоже легко конвертируется).
Сверхпопулярный ejabberd написан на Erlang. Широко известный xmonad — на haskell. Очень распространённый emacs — на Lisp. Рынок их требует крайне редко и в очень маленьких нишах. Сойдёт за контрпример?
не сойдет, что тут контрпримерного?
Рынок ни первого, ни второго, ни третьего нихрена не требует. А вот эти вещи написаны и очень востребованы.
вещи востребованы, а программисты — нет
Ну, Вы уже себе противоречите. Всеобщий почёт и уважение наличествуют? Весьма и весьма. «Легко конвертируется» — это не я сказал.
никакого противоречия, авторы вышеозначенных вещей востребованы, но это не значит, что существует огромный рынок труда для хаскелистов
Конечно. Достойные программисты, пишущие на любом языке, востребованы. А огромного количества хаскелистов я как-то и не наблюдаю. И людей, которые на Эрланг пишут, тоже не вижу. И лисперов гораздо меньше, нежели людей, способных освоить за неделю PHP и сотворить на нём недосайтик.
Зато я знаю хедхантершу из Штатов, которая деньги два года назад зарабатывала в основном поиском спецов по Эрланг. Была, значит, потребность на их рынке.
Зато я знаю хедхантершу из Штатов, которая деньги два года назад зарабатывала в основном поиском спецов по Эрланг. Была, значит, потребность на их рынке.
Есть, есть Эрлангеры и спрос на спецов по функциональным языкам в принципе. Я был на трех собеседованиях, два из которых — по Эрлангу, одно — по Хаскеллу. Все питерские.
Другое дело, что это не по хехантер.ру искалось, а по тусовкам специфичным, где еще засветиться надо.
Другое дело, что это не по хехантер.ру искалось, а по тусовкам специфичным, где еще засветиться надо.
Вот-вот. В одной знакомой фирме ближайшего разработчика на Эрланг нашли по erlsoap, который он разработал. Жаль, не получилось у них его на работу соблазнить.
А если не секрет, где найти и как попасть в эти тусовки?
Да все как обычно. Следите за русскоязычными аггрегаторами блогов, участвуйте в рассылках, публикуйте статьи на Хабре или тематических сайтах.
Идеальный расклад — когда есть один или несколько проектов на языке, опенсорсных желательно — будут демкой ваших скиллов.
В общем, создайте себе репутацию человека, активно интересующегося темой.
Идеальный расклад — когда есть один или несколько проектов на языке, опенсорсных желательно — будут демкой ваших скиллов.
В общем, создайте себе репутацию человека, активно интересующегося темой.
Написал чатик по приколу на Erlang (для внутренних нужд, ничем ограничен не был), сначала хотел на CommonLisp, но на хабре поставили на путь истинный :) Прикололся, заценил, что нагрузку держит на порядок большую (вернее повалить не смог), чем мое же творение на php (html/js код идентичен). Поискал вакансии в России типа «junior Erlang developer», не нашёл ничего… Оставил Erlang из разряда прикольных воспоминаний, типа FORTH (саморучно портированный на 8080 в 1990-м году), Fortran'а на лабах по информатике, «машины Кнута» или брэйнфака.
А почему именно в России? Из патриотизма?
По месту жительства :) Об эмиграции никогда серьезно не думал.
А удалённо — не вариант? Мне как раз дома работать удобнее.
Удаленно вариант, но с русскоговорящими. My English is very bad and I can't find a way to up it.
Странно слышать такое от опытного программиста, честно. Can't you try to improve it? You can read books, chat in English with your friends, watch movies and so on. I guess, it won't be a problem.
I understand books (technical without dictionary, other — with), some blogs and articles. But I can't speak and I haven't English speaking friends. I need not in «audio» English, only in «read-write» conversations.
Есть смутное подозрение, что вышеизложенное могут понять только русские (может быть ещё славяне), изучавшие англияский в школе
Есть смутное подозрение, что вышеизложенное могут понять только русские (может быть ещё славяне), изучавшие англияский в школе
Из советского лагеря. Нас специально учили так, чтобы понять не мог никто. Серьёзно. А взять книжечку, да на диван лечь, да прочесть пару рассказов перед сном, ну либо фильму посмотреть — оно и усвоится. :)
Как бы мечтаю о заказе «нужен чат» где-нить на фрилансру, который мне попадётся на глаза и сумею убедить заказчика, что Эрланг это круто. Правда нормальный заказчик вряд ли согласится, где он потом найдёт «суппортера» за 5$/час. чистая «подсадка на иглу» :)
Вот реальная вакансия на эрланг.
levgem.livejournal.com/326767.html
levgem.livejournal.com/326767.html
У вас был отличный пример в статье — Windows. Да, она кривая и нелогичная. Но это ей не мешает быть абсолютным лидером. По вашей логике выходит что среди пользователей винды — тоже жрецы без логики. Однако, как сказал ваш оппонент — профессионалы вынуждены работать с Windows, потому что это огромный рынок. Статья в целом интересная, и с большинством я согласен. Кроме одного — в кривых руках, и язык кривой. Лично я давно не пытаюсь что-то запоминать в ПХП: есть хорошие CHM с моментальным поиском :)
один препод в универе нас учил: «не надо всё запоминать, заучивать, зубрить… всё запомнить невозможно и не нужно. важно уметь пользоваться справочниками, пособиями и знать где нужную информацию можно найти» (не дословно)… и разрешал на зачетах и экзаменах пользоваться «справочной литературой» (конспектами и учебником).
причем, предмет преподавания с IT не свзян.
причем, предмет преподавания с IT не свзян.
Какой у вас диалог интересный вышел, и никто никого не тролит и оба оратора рубят факты.
Рынку вообще до лампочки на чем оно написано всё, хоть на ассемблере.
рынку потребителей все равно, а рынку труда — вовсе нет
И что интересно лучше, быть в меньшинстве, но которое таки востребовано, или влачить жалкое существование в общем потоке только потому, что мол рынок больше?
что же не все варианты рассмотрены? еще можно быть в меньшинстве, которое не востребовано и влачить хорошее существование в общем потоке.
в сухом остатке — хорошо, там где ты востребован, неважно общий поток это или нет. но в общем шансы выше
в сухом остатке — хорошо, там где ты востребован, неважно общий поток это или нет. но в общем шансы выше
Ну, как видим, от человека зависит. Мой оппонент работает на том, что востребовано. Я ищу работодателей, которые дают мне работать на том, что нравится мне.
Так, вот вы говорите что запоминателям в пхп проще потому что там успешность программиста зависит от умения запомниать.
Но постойте, я вот сейчас открою код своего проекта. И сделаю в нем grep -R 'str_'.
Да ладно уж, просто поищу упоминание стандартных функций по работе с массивами/строками.
Ой, нашло один strstr()
Вы не думайте, проект не на 100 строчек кода.
А знаете почему? Потому чтогладиолус абстракция. (все сейчас представили что у меня врапперы написаны на все функции :) но нет).
Откройте проект на любом высокоуровневом фреймворке типа Zend/Symfony/Doctrine. Если не заглядывать в код фреймворка — 99% кода выполняют бизнесс задачи не требующие использования стандартных функций.
А теперь возьмем рядового программиста на пхп который в деле уже 3-5 лет. Вы думаете он до сих пор пишет на коленке? (а велосипедах долго не продержишся в отрасли).
Выходит что «запоминатели» они только в начале пути. Но пройдет время, дополучается необходимый опыт и человек из запоминателя превращается в аналитика.
А теперь подумаете — подходит ли ето к другим языкам. Разве когда вы начинаете писать на Python вы сразу можете использовать встроенные функции без мануала?
Не можете. В начале пути — мы все жрецы. И только потом становимся настоящими джедаями.
Но постойте, я вот сейчас открою код своего проекта. И сделаю в нем grep -R 'str_'.
Да ладно уж, просто поищу упоминание стандартных функций по работе с массивами/строками.
Ой, нашло один strstr()
Вы не думайте, проект не на 100 строчек кода.
А знаете почему? Потому что
Откройте проект на любом высокоуровневом фреймворке типа Zend/Symfony/Doctrine. Если не заглядывать в код фреймворка — 99% кода выполняют бизнесс задачи не требующие использования стандартных функций.
А теперь возьмем рядового программиста на пхп который в деле уже 3-5 лет. Вы думаете он до сих пор пишет на коленке? (а велосипедах долго не продержишся в отрасли).
Выходит что «запоминатели» они только в начале пути. Но пройдет время, дополучается необходимый опыт и человек из запоминателя превращается в аналитика.
А теперь подумаете — подходит ли ето к другим языкам. Разве когда вы начинаете писать на Python вы сразу можете использовать встроенные функции без мануала?
Не можете. В начале пути — мы все жрецы. И только потом становимся настоящими джедаями.
> Откройте проект на любом высокоуровневом фреймворке типа Zend/Symfony/Doctrine.
А где ж мне его взять? У меня щас под руками только N проектов, которые совсем-совсем не я писал на самодельном фреймворке. Сейчас эти проекты постепенно переписываются на Yii. Кстати, разве ж Doctrine — веб-фреймворк? Это OR/M, насколько я помню. :)
А где ж мне его взять? У меня щас под руками только N проектов, которые совсем-совсем не я писал на самодельном фреймворке. Сейчас эти проекты постепенно переписываются на Yii. Кстати, разве ж Doctrine — веб-фреймворк? Это OR/M, насколько я помню. :)
>Кстати, разве ж Doctrine — веб-фреймворк? Это OR/M, насколько я помню. :)
Некоторым и его достаточно :)
Некоторым и его достаточно :)
По сути, сознательное использование Doctrine приводит к (или вытекает из) необходимости выделения модели (бизнес-логики), уже какой-никакой каркас, а если ещё разделить остальное на представление и всё остальное :) (контроллер) то получается полноценный каркас. фронт-контроллеры, роутинг, формирование форм, их валидация и биндинг — это детали
НЛО прилетело и опубликовало эту надпись здесь
Ну, может для вас это бизнес, а для меня это искусство!
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Ну тогда предложу вам попробовать пайтоновские листы, срезы. =) Если я не ошибаюсь, он их унаследовал аж от самого Фортрана.
Сорри, уже спать собираюсь, ничего умнее не придумал.
>>> S = [2*x for x in range(21) if x**2 > 3]
>>> S
[4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40]
>>> S[-1]
40
>>> S[2:6]
[8, 10, 12, 14]
>>> S[5::-2]
[14, 10, 6]
>>> import random
>>> [[chr(random.randint(ord('A'), ord('Z'))), i] for i in range(6)]
[['M', 0], ['S', 1], ['A', 2], ['W', 3], ['W', 4], ['S', 5]]
>>>Сорри, уже спать собираюсь, ничего умнее не придумал.
Вообще дребедень написал. Вот на вики простенько и наглядно. Хотя далекооо на все.
НЛО прилетело и опубликовало эту надпись здесь
свободные проекты тоже пишутся для привличения прибыли.
Как «привлИкает» прибыль emacs или ejabberd?
Коственно. Вы используете emacs в работе? а кто-то использует и получает профит. Думаю разработчики emacs и ejabberd на своих детищах заработали больше чем некоторые, кто не видит моделей получения прибыли с оупенсорц проектов. Тот самый ZF — оупенсорц, а сколько проектов каждый пыхопэ-программадор на нем заработал.
Чтобы забивать гвозди нужен молоток. А оупенсорцный он или нет — уже второй вопрос.
Чтобы забивать гвозди нужен молоток. А оупенсорцный он или нет — уже второй вопрос.
вы выковыряли несколько известных проблем php и на основании этого делаете далекоидущие выводы.
я с вами несоглашусь.
В php все достаточно логично и предсказуемо, просто есть свои особенности — которые нужно знать. но это касается любого языка.
я с вами несоглашусь.
В php все достаточно логично и предсказуемо, просто есть свои особенности — которые нужно знать. но это касается любого языка.
Отлично. Так, навскидку:
<?php
function throwEx() {
throw new Exception();
}
class A {
function __constuct($a) {
echo __METHOD__;
}
function __destruct() {
echo __METHOD__;
}
}
$a = new A(throwEx());
?>
Что произойдёт? И что должно бы произойти?
<?php
function throwEx() {
throw new Exception();
}
class A {
function __constuct($a) {
echo __METHOD__;
}
function __destruct() {
echo __METHOD__;
}
}
$a = new A(throwEx());
?>
Что произойдёт? И что должно бы произойти?
Всё правильно — конструктор не вызовется, и будет брошено исключение. Особенно, если ключевое слово __construct написано правильно ;)
Конструктор не вызовется, а деструктор вызовется. Очень прямая логика.
Деструктор тоже не вызовется, Вы главное напишите __construct правильно :))
Деструктор вызывается
yuriy.nasretdinov$ php
<?php
function throwEx() {
throw new Exception();
}
class A {
function __construct($a) {
echo __METHOD__;
}
function __destruct() {
echo __METHOD__;
}
}
$a = new A(throwEx());
^D
Fatal error: Uncaught exception 'Exception' in -:4
Stack trace:
#0 -(19): throwEx()
#1 {main}
thrown in - on line 4
yuriy.nasretdinov$ php -v
PHP 5.3.3 (cli) (built: Aug 22 2010 19:41:55)
Copyright © 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright © 1998-2010 Zend TechnologiesУ меня PHP 5.2 — значит в ветке 5.3 только пофиксили
Я это нашёл в 5.1.
вы еще в php4 найдите глюки, и напишите пост о ущербности ))
Как классно общаться с людьми, которые не умеют читать и не хотят понимать.
Я сказал, плюс-минус лапоть, следующее: в PHP многие вещи нужно помнить. Как пример, такое серьёзное изменение логики прошло практически недокументированно. Люди не знают о том, когда ущербное поведение заменили на логичное и правильное. Как следствие (см. текст поста, людям «запоминательного» типа с PHP общаться проще.)
Вы мне отвечаете, что я пишу об ущербности PHP.
Да, я согласен, что PHP ущербен, так как наблюдаю это поделие с 98-го, с «тройки». У меня по нему нет ZCE, но их пробные онлайновые я сдал на эксперта, так что говорю я это не просто так. Однако в данном случае речь не шла о том, что ущербен PHP, а о том, что людям, которым проще запомнить, чем понять, он легче даётся. Потому что понять местами нельзя.
Я понятно объяснил?
Я сказал, плюс-минус лапоть, следующее: в PHP многие вещи нужно помнить. Как пример, такое серьёзное изменение логики прошло практически недокументированно. Люди не знают о том, когда ущербное поведение заменили на логичное и правильное. Как следствие (см. текст поста, людям «запоминательного» типа с PHP общаться проще.)
Вы мне отвечаете, что я пишу об ущербности PHP.
Да, я согласен, что PHP ущербен, так как наблюдаю это поделие с 98-го, с «тройки». У меня по нему нет ZCE, но их пробные онлайновые я сдал на эксперта, так что говорю я это не просто так. Однако в данном случае речь не шла о том, что ущербен PHP, а о том, что людям, которым проще запомнить, чем понять, он легче даётся. Потому что понять местами нельзя.
Я понятно объяснил?
подобных багов можно нарыть кучу в реализации любого языка.
удивительно что вы общаясь с php еще с «тройки» этого не поняли.
это никого кроме вас не наталкивает на такие странный выводы, и желание написать об этом не менее странную статью.
удивительно что вы общаясь с php еще с «тройки» этого не поняли.
это никого кроме вас не наталкивает на такие странный выводы, и желание написать об этом не менее странную статью.
Подобных? Ну, если это для Вас незначительный баг, то таки да, конечно.
баг значительный.
другое дело что я никогда не передавал напрямик в конструктор функцию, тем более которая в кидает эксепшн.
я както больше по старинке, сначала формирую параметры а потом передаю их в функции и методы.
видимо поэтому подобные глюки мне не портят нервы в работе.
другое дело что я никогда не передавал напрямик в конструктор функцию, тем более которая в кидает эксепшн.
я както больше по старинке, сначала формирую параметры а потом передаю их в функции и методы.
видимо поэтому подобные глюки мне не портят нервы в работе.
А зачем забивать пространство имён? Ну вот какой в этом сакральный смысл? Если этот параметр вообще нигде не будет использован дальше? Это вкусовщина. А то, что «Вы никогда» — так это сугубо Ваше дело.
смысл в том чтобы не городить такие многоэтажные конструкции, к томуже перед рождением важных объектов можно провалидировать полученные данные, прежде чем передавать их дальше…
сами же писали о наследии говнокода который оставляют php кодеры. вот ваши пример как раз из той кучи.
сами же писали о наследии говнокода который оставляют php кодеры. вот ваши пример как раз из той кучи.
Э… Понимаю, что Вы говорили не об этом, но всё-таки: в Ваших программах много неважных объектов?
да много. это например классы работы с типовыми формами, валидация, генерация картинок, плагины к социальным сетям… если чтото пойдет не так то юзер просто не увидит страницу или блок.
а еще есть биллинг, транзакции, отчеты, импорт и экспорт данных — тут уже последствия могут быть хуже, ибо если написать их тяп-ляп то это чревато неправильными расчетами, несоответствием данных и косвенными глюками которые могут всплыть много позже…
а еще есть биллинг, транзакции, отчеты, импорт и экспорт данных — тут уже последствия могут быть хуже, ибо если написать их тяп-ляп то это чревато неправильными расчетами, несоответствием данных и косвенными глюками которые могут всплыть много позже…
лучше подумайте об ущербности программиста, который не в состоянии ничего запомнить…
не защищаю php, но если для вас даже это — проблема, то, извините, но лучше вам заняться чем-то другим, особенно чем писать посты ни о чем.
не защищаю php, но если для вас даже это — проблема, то, извините, но лучше вам заняться чем-то другим, особенно чем писать посты ни о чем.
Не стремясь защититься, предлагаю Вам хотя бы перечитывать свои сообщения перед отправкой. «То но лучше» — офигенно грамотно. «Особенно чем писать» — офигенно грамотно. Простите, как я могу принимать всерьёз мнение человека, который свои мысли даже на русском языке выразить не может? Может, он и читать не умеет. Ну не может пост «ни о чём» так бурно обсуждаться рядом умных людей, право.
Я не претендую на «офигенную грамотность», я не задрот. Это во-первых. Во-вторых, то, что вам показалось «офигенно грамотным» в «то, извините, но » (которое вы так искаженно процитировали) объясняется скорее всего бедностью вашего языкового запаса. Это не редкость среди «технарей», надо было больше читать литературы.
Что «пост ни о чем», не один я сказал. Собственно как и ваш ответ не по теме комментария. Насчет русского языка я уже ниже писал: если для вас запомнить несколько «словоформ» языка php такая проблема, то как же вы с русским-то справлялись?
А последнее ваше высказывание — бред в чистом виде. Может и еще как.
Засим откланиваюсь, желаю натренировать память в новом году.
Что «пост ни о чем», не один я сказал. Собственно как и ваш ответ не по теме комментария. Насчет русского языка я уже ниже писал: если для вас запомнить несколько «словоформ» языка php такая проблема, то как же вы с русским-то справлялись?
А последнее ваше высказывание — бред в чистом виде. Может и еще как.
Засим откланиваюсь, желаю натренировать память в новом году.
У мок-экзаменов от phparchitect (а именно они были «официальными» пробными) нет оценки «эксперт», уж извините за занудство :)
А вот если __construct написан неправильно, то действительно конструктор не вызывается, и, по всей видимости, функция throwEx() тоже :), и вот это уже действительно косяк.
эксепшн возник еще ДО выполнения конструктора, и логично что пхп прервал его выполнение и вызвал деструктор.
а что ДОЛЖНО БЫЛО произойти? чтоб выполнение продолжилось и эксепшн был проигнорирован? тогда бы вы еще больше начали кричать о нелогичности поведения )))
а что ДОЛЖНО БЫЛО произойти? чтоб выполнение продолжилось и эксепшн был проигнорирован? тогда бы вы еще больше начали кричать о нелогичности поведения )))
Ой-ей-ей!
Проблема в том, что деструктор не должен вызываться, если не вызван конструктор.
Но это ладно, хуже другое:
try{
$a = new A(throwEx());
} catch (Exception $e) {
echo 'catched!';
}
Проблема в том, что деструктор не должен вызываться, если не вызван конструктор.
Но это ладно, хуже другое:
try{
$a = new A(throwEx());
} catch (Exception $e) {
echo 'catched!';
}
Исключение не было поймано!
Напишите слово __construct правильно — будет ловиться (и деструктор не будет вызываться).
переименуйте
function __constuct($a) {
в
function __construct($a) {
и оно чудесным образом будет поймано)
function __constuct($a) {
в
function __construct($a) {
и оно чудесным образом будет поймано)
Угу. Именно это мне и пришлось в своё время объяснять коллеге.
Точнее, не это, а почему __destruct() отрабатывает вне зависимости от того, отработал ли конструктор. Там бизнес-логика была.
а почему деструктор не должен-то отрабатывать? ведь объект уничтожается после завершения обработки… не?
А потому что можно создать объект, а потом попытаться дёрнуть инициализирующий метод, словив исключение при получении аргументов, и оставив объект (объект при этом не знает, что он инвалид, и будет в __destruct() косячить). Самый простой пример — со статическим свойством, которое увеличивается на единицу в конструкторе и уменьшается на единицу в деструкторе. Из-за этого бага до PHP 5.3 это статическое свойство очень просто можно было загнать в глубокие минуса.
А можно сначала получить аргументы, создать объект и дёрнуть инициализирующий метод. По мне так логичнее второй подход, но раньше здесь работал первый.
А можно сначала получить аргументы, создать объект и дёрнуть инициализирующий метод. По мне так логичнее второй подход, но раньше здесь работал первый.
Деструктор – это специальный метод класса с именем __destruct(), который будет гарантированно вызван при потере последней ссылки на объект в программе.
Вопрос — а была ли создана хоть одна ссылка, если исполнение прервалось еще на стадии вычисления аргументов (напомню, что в PHP нет отложенных вычислений).
Вы зря спорите, на самом то деле. Эта логика, как выше уже выяснилось — была убрана в PHP 5.3.
Вы зря спорите, на самом то деле. Эта логика, как выше уже выяснилось — была убрана в PHP 5.3.
Так вот должна ли она быть создана? Нет, не должна была, нам нечего передать конструктору в качестве аргументов. Однако он вызывался.
Вы уж определитесь, «эксепшн возник ДО конструктора», или «пхп прервал выполнение конструктора»?
А зачем? :) Нам противостоит типичный «жрец». :)
тоесть вы себя относите к высшей касте программистов? )))
Вот опять. Это _разные_ типы мышления. Я не считаю людей, которым нравится чёрный, лучше людей, которым нравится красный. И левшей с правшами не разделяю по принципу «кто лучше».
Кстати, слово «каста» тоже какое-то… религиозное. :-P
Кстати, слово «каста» тоже какое-то… религиозное. :-P
я как и многие тут еще пишу на java например. и что? я все еще «жрец»?
Ну я тоже писал на Java. Работал с J2EE. В 2001-м. Там было всё логично. Да, доки тоже были открыты, но с javadoc конкретных вещей. Приколов типа процитированного с деструкторами без конструкторов там не было никогда.
тоесть если в java найти баг, то он автоматически станет «ЯП для жрецов»?)
То есть вот лично у Вас проблемы с вербализацией мыслей, о чём Вам в #comment_3527434 тактично намекнули. Как видно из продолжения дискуссии, Вы упорно не пытаетесь понять собеседника и продолжаете гнуть свою линию. Баги тут ни при чём., приведённый мной пример — не иллюстрация бага, а скорее «особенность реализации», которая, кстати, потихоньку была устранена. Молча.
Java же, к слову, очень логичен и отлично продуман. Писать на нём — одно удовольствие.
Java же, к слову, очень логичен и отлично продуман. Писать на нём — одно удовольствие.
и у кого из нас проблемы после этого)) вы со мной вообще разговариваете?
я уже который раз задаю прямой вопрос, и не получают прямого ответа.
просто вы не можете ответить мне потому что это будет противоречить всей вашей теории о «персистентности типа ума» программистов.
потому что даже ёжику понятно что нормальный прогер может легко переключиться на другой язык, если есть необходимость или просто желание. так как:
— запоминать ничего не нужно, всю рутину давно переложили на IDE
— баги есть везде! и это не показатель принадлежности языка к тому или иному типу
я уже который раз задаю прямой вопрос, и не получают прямого ответа.
просто вы не можете ответить мне потому что это будет противоречить всей вашей теории о «персистентности типа ума» программистов.
потому что даже ёжику понятно что нормальный прогер может легко переключиться на другой язык, если есть необходимость или просто желание. так как:
— запоминать ничего не нужно, всю рутину давно переложили на IDE
— баги есть везде! и это не показатель принадлежности языка к тому или иному типу
Да, стараюсь разговаривать с Вами.
Объясняю по пунктам:
1) Вам задали вопрос: «Вы уж определитесь, «эксепшн возник ДО конструктора», или «пхп прервал выполнение конструктора»?» Вы не ответили. А это немножко разные вещи.
2) Вместо этого Вы начали что-то невнятное про «высшую касту». Ещё раз: я не считаю, что высшая каста — это люди, которые любят яблоки; равно как не считаю, что низшая — те, кто любит груши. Я вообще программистов на «касты» не делю.
3) Да, поскольку с логикой у Вас проблемы (см. пп. 1) и 2)), Вы очень похожи на «жреца» по моей терминологии. Разговор у нас, соответственно, складывается ни о чём: вот уже и Вы в нём смысла не видите.
Давайте закроем эту ветку, она заведомо непродуктивна.
Объясняю по пунктам:
1) Вам задали вопрос: «Вы уж определитесь, «эксепшн возник ДО конструктора», или «пхп прервал выполнение конструктора»?» Вы не ответили. А это немножко разные вещи.
2) Вместо этого Вы начали что-то невнятное про «высшую касту». Ещё раз: я не считаю, что высшая каста — это люди, которые любят яблоки; равно как не считаю, что низшая — те, кто любит груши. Я вообще программистов на «касты» не делю.
3) Да, поскольку с логикой у Вас проблемы (см. пп. 1) и 2)), Вы очень похожи на «жреца» по моей терминологии. Разговор у нас, соответственно, складывается ни о чём: вот уже и Вы в нём смысла не видите.
Давайте закроем эту ветку, она заведомо непродуктивна.
Простите но мне кажется что это как раз «очередные тонны кода, которые будут приводить в ужас всех, пришедших следом». Мешанина функций и классов, что может быть хуже?
Это не тонны кода, а максимально сжатый по объёму пример, написанный за две минуты для того, чтобы проиллюстрировать конкретную проблему. Разницу видите?
А какую проблему демонстирует этот кусок кода? На сколько я понял в ранних версиях это могло привести к вызову деструктора без вызова конструктора. Ну так мне кажется что это кривизна кода а не проблема языка. mysql_query может к sql injection привести, но это же не проблема/недостаток языка а скорее проблема разработчика, который должен знать и понимать что и как он делает
Создание объекта происходит даже при исключительной ситуации при вызове конструктора. Это проблема, т.к. конструктор не отработал, а деструктор всё равно будет вызван.
Всё же я с вами не соглашусь, да тут есть косяк со стороны php но исключительную ситуацию должен отлавливать разработчик
Достаточно специфичный пример у вас,
вот тут собрано достаточно: www.tnx.nl/php.html
ну и www.tnx.nl/php5.html
вот тут собрано достаточно: www.tnx.nl/php.html
ну и www.tnx.nl/php5.html
Вот еще такой пример.
Кажется очевидной такая конструкция, но нет.
if ( empty($obj->foobar) ) {
}
empty это такая специальная конструкция языка, и
если переопределены __get, __set то нужно переопределить еще и __isset, который будет выполняться в этом случае.
Кажется очевидной такая конструкция, но нет.
if ( empty($obj->foobar) ) {
}
empty это такая специальная конструкция языка, и
если переопределены __get, __set то нужно переопределить еще и __isset, который будет выполняться в этом случае.
функции работы с массивами тоже логичны и предсказуемы? :)
А ведь сам язык php вполне логичен и прост. Я имею в виду собственно управляющие конструкции.
А остальное — это уже стандартная библиотека, не сам язык. Да, есть нелогичные места. Но в других языках тоже надо запоминать, и немало.
А остальное — это уже стандартная библиотека, не сам язык. Да, есть нелогичные места. Но в других языках тоже надо запоминать, и немало.
ООП — это стандартная библиотека?
Он логичен как шаблонизатор. Для этого там есть специальный синтаксис записи операторов для вставки в html, и для этого там все переменные начинаются с $.
Кстати, а там уже сделали возможность сделать a()[3] ?)
НЛО прилетело и опубликовало эту надпись здесь
Да ну? В 5.3.3 — синтаксическая ошибка.
Когда успели? Я что то не наблюдаю ничего такого:
konstantin@konstantin-desktop:~$ php -r '$s="f,g,h";explode(",",$s)[0];' || php -v
PHP Parse error: syntax error, unexpected '[' in Command line code on line 1
PHP 5.3.2-1ubuntu4.5 with Suhosin-Patch (cli) (built: Sep 17 2010 13:41:55)
Copyright © 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright © 1998-2010 Zend Technologies
В транк закоммитили. Будет в следующей версии (5.3.4)
Прекрасно! Еще бы именнованые аргументы функций (чтобы вместо func1(array('x'=>10,'y'=>20)) писать func1(x:10,y:20)) и полнейшее ооп для того, чтобы можно было делать что-то типа «hello, world».substr(3,6) или на худой конец «hello world»->substr(3,6), потом дождаться, когда большинство хостеров примут версию РНР с этими вкусностями за базовую и можно наслаждаться жизнью до полной нирваны!
P.S. python и ruby не предлагать! Серверный JS тоже.
P.S. python и ruby не предлагать! Серверный JS тоже.
НЛО прилетело и опубликовало эту надпись здесь
Прост? А как насчёт массивов-хешей? А может, его правила неявного преобразования типа просты и очевидно? Или поведение ссылок? Или банальный приоритет тернарного условного оператора? Или синтаксис интерполяции строк? Ну это только навскидку вспомнилось.
Переписать еще несколько раз и все будет тип топ.
ИМХО, для человека, хоть немного знающего С++, изучение PHP дается с легкостью: знакомый синтаксис, много знакомых функций, только работа с переменными сначала кажется немного непривычной.
Бредовый пост ни о чём… набор мыслей. Где идея?
Идея — давайте опусти пхпшников, и на их фоне будем казаться крутыми )
Неправда, я такого не писал и не имел в виду.
«А сам PHP — как инструмент, как средство, как тема общения, — привлекает к себе людей в первую очередь «запоминательного», а не аналитического типа.»
Я правильно понял, что вы подразумевали, что пхпшники не могут анализировать и размышлять?
Я правильно понял, что вы подразумевали, что пхпшники не могут анализировать и размышлять?
Нет, неправильно.
Ну ладно тогда.
Заебали руби-неофиты, которые не способны написать что-то серьезнее хелловорлда, но дико горды своим синтаксическим диабетом.
Заебали руби-неофиты, которые не способны написать что-то серьезнее хелловорлда, но дико горды своим синтаксическим диабетом.
А, ну тады ладно. Я не руби-неофит. :)
+1.5
любой пхпшник мечтает писать на руби или питоне
любой пхпшник мечтает писать на руби или питоне
Не любой.
Не могу сказать, что мечтаю. Мне практически всё равно писать на php или python для веба. Для «десктопных» приложений однозначно python, пока нет биндингов qt для php
Идея для тех, кто не умеет читать: «Дело не в том, что один из них умнее, а другой глупее, нет. Это просто другой тип мышления, ориентированный на запоминание, а не на стремление собрать данные и проанализировать ситуацию с разных сторон. А сам PHP — как инструмент, как средство, как тема общения, — привлекает к себе людей в первую очередь «запоминательного», а не аналитического типа».
тут на Хабре каждый второй мультиязычен. успешно кодят сразу на несколько языках, в зависимости от поставленной задачи и проекта.
как вы объясните этот феномен с точки зрения своего «запоминательного» и аналитического типа»?
как вы объясните этот феномен с точки зрения своего «запоминательного» и аналитического типа»?
Даже не собираюсь объяснять. Я тоже много на чём пишу. Но когда я пишу на PHP, мануал у меня открыт практически всегда.
тоесть когда человек кодит на PHP он «запоминательного» типа.
только открыл в IDE проект на Ruby — сразу стал «аналитического типа»?
что за неявное преобразование типов )
только открыл в IDE проект на Ruby — сразу стал «аналитического типа»?
что за неявное преобразование типов )
То есть человек с аналитическим мышлением сильно облажается, если будет строить предположения на базе уже имеющегося опыта. Впрочем, как справедливо заметили, человеку, который использует только IDE, не нужно строить предположений. Ему IDE подсовывает факты.
а вы что в Notepad-e кодите? что вам приходится ВСЕ ЭТО запоминать и постоянно обращаться к мануалу?
тем более и запоминать то там не так много…
тем более и запоминать то там не так много…
А IDE за вас и код сама понимает? Уже написанный.
И мысли читает? Заранее угадывая какую функцию вы хотите написать.
Вот, например. Функция считающая md5 файла хотя бы с какой буквы начинается? С «m» или с «f»? =) А в каком разделе мануала она? Cryptography Extensions или File System Related Extensions? =)
И мысли читает? Заранее угадывая какую функцию вы хотите написать.
Вот, например. Функция считающая md5 файла хотя бы с какой буквы начинается? С «m» или с «f»? =) А в каком разделе мануала она? Cryptography Extensions или File System Related Extensions? =)
никогда это не было для меня проблемой. когда писал на других языках тоже не пытался запомнить ВСЕ функции. По мере набора опыта они сами запоминались. а что забыл быстро находилось в доках или с пом. хинтов в IDE. в чем проблема то? тем более широко используя фреймворки, процесс кодинга преместился на более высокий уровень абстракции, и там уже совсем другие классы и методы. пожалуйтесь еще что их тоже оказывается надо знать, изучать и запоминать… ))
Операции с массивами, строками, изображениями, математика… разве эти задачи решают фреймворки? Каким образом они вдруг переместились в фреймворки? В php со всеми стандартными модулями несколько тысяч функций, и почти за каждой надо лезть в мануал, ибо знаешь, что от функции нужно, но порой даже не догадываешься, в каком разделе мануала ее вдруг обнаружишь и с какой буквы она может начинаться. Увидев в чужом коде незнакомую функции, также надо про нее читать. Догадаться что именно она делает со всеми ньюансами — практически не возможно. Вы к этому привыкли, и сейчас рьяно защищаете, а ничего хорошего то в этом нет. А код должны писать и понимать вы, а не IDE. У меня нет желания дальше с вами продолжать спор, это бессмысленно, пишите на своем php, мне то что, я же не к чему не призываю.
Функция считающая md5 файла находится не в Cryptography Extensions или File System Related Extensions, а (sic!) в String Functions.
Странно, что пресловутое:
в топике еще никто не упомянул.
Функция считающая md5 файла находится не в Cryptography Extensions или File System Related Extensions, а (sic!) в String Functions.
Странно, что пресловутое:
if (false == 0) echo 1;
if ('false' == false) echo 2;
if ('false' == 0) echo 3;в топике еще никто не упомянул.
Ложь.
habrahabr.ru/blogs/php/110767/?reply_to=3532381#comment_3528300
Тут вроде как не урожай апельсинов в Хельсинки обсуждался, а именно эта особенность. :)
habrahabr.ru/blogs/php/110767/?reply_to=3532381#comment_3528300
Тут вроде как не урожай апельсинов в Хельсинки обсуждался, а именно эта особенность. :)
как спасают фреймворки? абстракцией батенька:
$image = new fwImage('/var/www/html/images/myfoto.jpg');
$image->resize(100,100)->save('/var/www/html/images/myfoto_th.jpg');
вот и все. и ненужно знать как там внутри это работает. странно что вы этого не знаете.
>пишите на своем php, мне то что, я же не к чему не призываю
хаха )) конечно буду писать. или вы думаете что вашы слабые аргументы тут когото убедили? никого. на самом деле ФАНАТИК тут как раз ВЫ, т.к. пытаетесь нам всем показать что мы ошибаемся, не на том кодим и вообще ограниченные — а вот вы настоящий дартаньян, вовремя осознавший ущербность php, и снизошедщий до нас чтобы указать истинный путь.
я и без вас знаю проблемные стороны php, они есть у любого ЯП. но плюсы у PHP перевешивают — это факт. потому и такая распространенность и востребованность, скорость разработки и т.д.
за что платят на том мы и кодим, и неважно что это php, java или c++…
$image = new fwImage('/var/www/html/images/myfoto.jpg');
$image->resize(100,100)->save('/var/www/html/images/myfoto_th.jpg');
вот и все. и ненужно знать как там внутри это работает. странно что вы этого не знаете.
>пишите на своем php, мне то что, я же не к чему не призываю
хаха )) конечно буду писать. или вы думаете что вашы слабые аргументы тут когото убедили? никого. на самом деле ФАНАТИК тут как раз ВЫ, т.к. пытаетесь нам всем показать что мы ошибаемся, не на том кодим и вообще ограниченные — а вот вы настоящий дартаньян, вовремя осознавший ущербность php, и снизошедщий до нас чтобы указать истинный путь.
я и без вас знаю проблемные стороны php, они есть у любого ЯП. но плюсы у PHP перевешивают — это факт. потому и такая распространенность и востребованность, скорость разработки и т.д.
за что платят на том мы и кодим, и неважно что это php, java или c++…
«вот и все. и ненужно знать как там внутри это работает. странно что вы этого не знаете»
Угу. php-шникам уже больше заняться нечем, кроме как оборачивать интерфейсы php-библиотек в новые интерфейсы на самом php. Шаблонизатор (smarty) на шаблонизаторе (php) уже написали, что дальше? Новый язык программирования на php напишете?
Впрочем это и нормально, на сэкономленные деньги, заказчик может купить больше серверов, чтобы оно хоть как-то потом работало.
Угу. php-шникам уже больше заняться нечем, кроме как оборачивать интерфейсы php-библиотек в новые интерфейсы на самом php. Шаблонизатор (smarty) на шаблонизаторе (php) уже написали, что дальше? Новый язык программирования на php напишете?
Впрочем это и нормально, на сэкономленные деньги, заказчик может купить больше серверов, чтобы оно хоть как-то потом работало.
конечно) уж вы бы данный ресайз картинки делали вручную на низкоуровневых функциях))))…
я в вас ни на минуту не сомневался, прекрасный подход.
я в вас ни на минуту не сомневался, прекрасный подход.
Низкоуровневый код для php это как-то так:
Называть функции стандартной библиотеки высокоуровневого скриптового языка «для веба» — низкоуровневыми, это нонсенс.
p.s. Особенно мне понравилось: «вы бы данный ресайз картинки делали вручную»
p.p.s. Ах да. Я вообще для ресайза картинок в одном проекте рассматриваю возможность применения CUDA.
#include "gd.h"
#include <stdio.h>
int main() {
gdImagePtr im = gdImageCreate(64, 64);
int black = gdImageColorAllocate(im, 0, 0, 0);
int white = gdImageColorAllocate(im, 255, 255, 255);
gdImageLine(im, 0, 0, 63, 63, white);
FILE *pngout = fopen("test.png", "wb");
gdImagePng(im, pngout);
fclose(pngout);
gdImageDestroy(im);
}Называть функции стандартной библиотеки высокоуровневого скриптового языка «для веба» — низкоуровневыми, это нонсенс.
p.s. Особенно мне понравилось: «вы бы данный ресайз картинки делали вручную»
p.p.s. Ах да. Я вообще для ресайза картинок в одном проекте рассматриваю возможность применения CUDA.
я очень рад за вас, правда. если есть возможность делать нестандартные вещи — это круто.
но мне очередной заказчик написал в требованиях что писать надо на php, в окружении стандартного хостинга. так как он все посчитал. и ему в будущем поддержка и доработка будет стоить в этом случае меньше всего.
и нет проблем. берем чтонить типа Yii fw и делаем уникальный сайт, быстро и добротно.
это рынок.
а ваши разговоры про то что там есть нелогично названные функции, или что в php нет в поставке своего веб сервера или чтото подобное — это совершенно никого не напрягает, кроме вас))) хотя вы на нем не кодите.
и это особенно странно, учитывая вашу активность в обсуждении
но мне очередной заказчик написал в требованиях что писать надо на php, в окружении стандартного хостинга. так как он все посчитал. и ему в будущем поддержка и доработка будет стоить в этом случае меньше всего.
и нет проблем. берем чтонить типа Yii fw и делаем уникальный сайт, быстро и добротно.
это рынок.
а ваши разговоры про то что там есть нелогично названные функции, или что в php нет в поставке своего веб сервера или чтото подобное — это совершенно никого не напрягает, кроме вас))) хотя вы на нем не кодите.
и это особенно странно, учитывая вашу активность в обсуждении
Объясню, почему я здесь. Я довольно долго сам писал на php, более шести лет. О чем жалею. Крутясь постоянно внутри php сообщества, кажется, что php единственный easy, fast, right и вообще only true way для веб-разработки. Уж каких только мифов среди php-шников ни ходит, и это печально на самом деле. А что массово среди разработчиков, то и влияет на заказчиков, а также и всю остальную инфраструктуру. Сейчас мне совсем не кажется, что php достоин всех этих почестей. Он был хорош в начале века, можно сказать в некотором роде совершил революцию. До этого все CGI-приложения писали, а php дал возможность добавлять очень легко и просто серверную динамику прямо в html-страницы. Тогда это было супер-круто. Но времена изменились, сложность этой самой динамики значительно возросла, это уже не набор отдельных «страничек», это целое приложение, а вот сознание разработчиков нет. Что еще печально, если я начинал свой путь в программирование с C++, который, в некотором роде, ошибок не прощает, и по большим толстым умным книжкам дядек в 10 раз умнее меня, то сейчас многие следуя моде начинают программировать с php, прочитав какой-нибудь мануал, аля apache+php+mysql и свой блог за 10 минут. А php один из тех языков, который не учит «хорошим манерам», как мне кажется. Все это очень неприятно.
почти все кого я знаю из разработчиков, имеют опыт программирования не только на php. зачастую это perl, java, python…
Все всё прекрасно понимают и плюсы и минусы каждого ЯП. Для себя кодят на чем нравится, а для заказчика на чем нужно исходя из требований. иногда удается переубедить — но не всегда.
можно и на c++ в билдере лабать проги не особо разбираясь в тонкостях языка. непуганных идиотов хватает везде. не нужно формировать свое мнение глядя только на них. мне приходилось работать с большими профессионалами своего дела, и на php создавать не только странички но и довольно сложные системы. да это можно было бы делать на множестве языков. но это не аргумент.
времена изменились но и php меняется. не всегда быстро и правильно, но в целом тенденция хорошая.
Все всё прекрасно понимают и плюсы и минусы каждого ЯП. Для себя кодят на чем нравится, а для заказчика на чем нужно исходя из требований. иногда удается переубедить — но не всегда.
можно и на c++ в билдере лабать проги не особо разбираясь в тонкостях языка. непуганных идиотов хватает везде. не нужно формировать свое мнение глядя только на них. мне приходилось работать с большими профессионалами своего дела, и на php создавать не только странички но и довольно сложные системы. да это можно было бы делать на множестве языков. но это не аргумент.
времена изменились но и php меняется. не всегда быстро и правильно, но в целом тенденция хорошая.
Заказчик ведь свои требования не с потолка берет. Меня например совсем не устраивает, когда «для себя кодят на чем нравится, а для заказчика на чем нужно». Работа должна быть в радость. Я предпочитаю программировать исключительно на чем нравится, и благо такую возможность всегда нахожу. То, что нравится, надо нести в массы, и до заказчиков. Иначе, ситуация не поменяется.
PHP меняется, да как верно заметили, не то что не всегда быстро, а скорее даже очень медленно. А с учетом тормозов хостеров — и того медленнее. Когда там php6 ожидать? Вон неймспейсы из него портировали, но, как погляжу, не все от них в восторге. А когда с ними перепишут все фреймворки и пр. еще большой вопрос. Более менее вменяемый gc тоже вроде наконец сделали, но насколько вменяемый не знаю, вопрос. Настоящий fastcgi говорят теперь возможен, а на практике? Тоже вопрос.
PHP меняется, да как верно заметили, не то что не всегда быстро, а скорее даже очень медленно. А с учетом тормозов хостеров — и того медленнее. Когда там php6 ожидать? Вон неймспейсы из него портировали, но, как погляжу, не все от них в восторге. А когда с ними перепишут все фреймворки и пр. еще большой вопрос. Более менее вменяемый gc тоже вроде наконец сделали, но насколько вменяемый не знаю, вопрос. Настоящий fastcgi говорят теперь возможен, а на практике? Тоже вопрос.
Подпишусь почти под каждым словом :) Но php3 (первый который я начал использовать после cgi скриптов на C — использование ООП C++ для веба мне тогда казалось ненужным оверхедом и, имхо, небезосновательно для тех задач и стоимости тех ресурсов) и php5.3 это небо и земля.
А вот насчёт «не учит хорошим манерам» — это, имхо, относится практически ко всем «динамическим» языкам. Они почти все прощают ошибки, которые в C бы не прошли.
Вот этот мануал плохому, по-моему, не учит, правда там не 10 минут, а 24 часа. Очень приятный, по-моему.
А вот насчёт «не учит хорошим манерам» — это, имхо, относится практически ко всем «динамическим» языкам. Они почти все прощают ошибки, которые в C бы не прошли.
Вот этот мануал плохому, по-моему, не учит, правда там не 10 минут, а 24 часа. Очень приятный, по-моему.
Ну хорошо, расскажу чему учит начинающих веб-разработчиков python, особенно по сравнению с php:
1) Отступы, правильное форматирование кода. Как не крути, а на пайтоне только так. Плюс упоминание docstrings лишний раз напомнят, что код надо правильно комментировать.
2) Как вы уже неоднократно заметили, для веб на пайтоне без фреймворков не пишут. И, как правило, все начинают стразу с django. А фреймворк научит паттернам и правильно структурировать код. И шаблонизация туда же.
3) Качественные, хорошо оформленные и структурированные библиотеки, модули, правильно именованные функции привьют хороший вкус. А так пользователи наглядевшись на php-шные функции, и о своих не задумываются.
4) У пайтона еще к тому же гораздо более качественный и точный анализатор кода, чем у php. Ошибки синтаксиса гораздо более информативны.
5) logging, pydoc и unittest модули уже из коробки. Хороший намек, всякий новичок об этих вещах узнает.
1) Отступы, правильное форматирование кода. Как не крути, а на пайтоне только так. Плюс упоминание docstrings лишний раз напомнят, что код надо правильно комментировать.
2) Как вы уже неоднократно заметили, для веб на пайтоне без фреймворков не пишут. И, как правило, все начинают стразу с django. А фреймворк научит паттернам и правильно структурировать код. И шаблонизация туда же.
3) Качественные, хорошо оформленные и структурированные библиотеки, модули, правильно именованные функции привьют хороший вкус. А так пользователи наглядевшись на php-шные функции, и о своих не задумываются.
4) У пайтона еще к тому же гораздо более качественный и точный анализатор кода, чем у php. Ошибки синтаксиса гораздо более информативны.
5) logging, pydoc и unittest модули уже из коробки. Хороший намек, всякий новичок об этих вещах узнает.
Тема сисек не раскрыта, все понимающие и так знают о количестве функций в глобальной области, их «особых» интерфейсах, php-карячках и т.п вещах… Надо ставить вопрос, когда же будет всё более «цивилизованней», на сколько и в какие сроки это возможно, на сколько это нужно и как это мешает или нет…
Что значит «мультиязычен»? Чтобы быть специалистом, например, по Java, нужно обладать тонной опыта, получаемой за немалое время. Я даже с C# на Java в своё время переполз полноценно где-то за полгода. И сейчас считаю себя Java-специалистом, и на вакансию «разработчик .NET» не пойду, ибо теперь годен только в джуниоры. Да, небольшой костыльчик на C# я напишу (как раньше, будучи дотнетчиком, мог на Java). И на Python, и на Ruby, а тем более на PHP я тоже что-то небольшое напишу. Но вот поддерживать крупный проект я бы не взялся. Потому что боюсь что в этом случае нагородил бы тонны говнокода. И, кстати, мне приходилось в жизни довольно много писать на PHP и не сказать, чтобы мне это сильно нравилось. Именно, что «приходилось».
ну вот как раз в этом и есть посыл «что один из них умнее, а другой глупее», только завуалированный. По крайней мере я так это понял.
Вы говорите, что мол мы такие клёвые, мы программируем анализируя(думая) и собирая информацию и бла бла бла, мы аналитики, а эти пхпшники просто тупо всё запомнили, и прогают не думая, обычные code monkey.
Вы говорите, что мол мы такие клёвые, мы программируем анализируя(думая) и собирая информацию и бла бла бла, мы аналитики, а эти пхпшники просто тупо всё запомнили, и прогают не думая, обычные code monkey.
Когда-то PHP меня привлек своей легкостью написания скриптов для веба (да-да, спагетти-код, глобальное пространство имён для библиотечных функций и модуль апача — это сказка по сравнению с сайтами на чистом Си в CGI). Сейчас привлекает как самый востребованный (ИМХО) язык в «эникейном» сегменте российского рынка.
Согласен, но на «эникейном» рынке далеко не уедешь.
Но и вылезти с него трудно («Съест-то он съест, да кто ж ему даст»). Сменить основной язык разработки так, чтобы не писать на нём «быдлокод» (в понятиях нового языка) — нужно иметь какой-то фидбэк. Я вот тут случайно узнал, что нормальные люди не пишут веб-приложения на руби без рельс или синатры, на худой конец рэка, а я после написания хелловорда как cgi, чуть ли не весь протокол FastCGI начал реализовывать начиная со слушанья сокетов
PHP отличается от других легкостью изучения.
Поэтому так много говнокода на нем пишется.
Но есть и очевидные плюсы — скорость разработки (считай решения бизнес-задач)
Поэтому так много говнокода на нем пишется.
Но есть и очевидные плюсы — скорость разработки (считай решения бизнес-задач)
Именно это и отталкивает многих от php в сторону ruby/python/etc. Из 1000 php кодеров по пальцам можно пересчитать тех, кто реально «кодит». Все остальные сравнивают файлы через file_get_contents($file1) != file_get_contents($file2) или того хуже посимвольным (про байты они не в курсе) перебором.
Про байты, говорите, не в курсе? Ну-ну, побайтовое сравнение Unicode (в частности utf8) строк недопустимо, а посимвольное ещё хоть как-то прокатит, хотя тоже не панацея.
А что отталкивает я не понял — легкость изучения или скорость разработки?
А что отталкивает я не понял — легкость изучения или скорость разработки?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Не знаю что у вас не работает, у меня все вышеприведенные примеры отработали нормально (с соответствующей предыдущей инициализацией переменных, конечно).
<?php
$property = 'property';
$object->property = 'property';
$object->dataproperty = 'dataproperty';
$properties = array('property');
$property_obj = new stdClass(); $property_obj->name = 'property';
var_dump($object->$property);
var_dump($object->{'property'});
var_dump($object->{$property});
var_dump($object->{'data'.$property});
var_dump($object->{$properties[0]});
var_dump($object->{$property_obj->name});
echo PHP_EOL, phpversion();
у меня выводит
string(8) «property»
string(8) «property»
string(8) «property»
string(12) «dataproperty»
string(8) «property»
string(8) «property»
5.3.3-1ubuntu9.1
<?php
$property = 'property';
$object->property = 'property';
$object->dataproperty = 'dataproperty';
$properties = array('property');
$property_obj = new stdClass(); $property_obj->name = 'property';
var_dump($object->$property);
var_dump($object->{'property'});
var_dump($object->{$property});
var_dump($object->{'data'.$property});
var_dump($object->{$properties[0]});
var_dump($object->{$property_obj->name});
echo PHP_EOL, phpversion();
у меня выводит
string(8) «property»
string(8) «property»
string(8) «property»
string(12) «dataproperty»
string(8) «property»
string(8) «property»
5.3.3-1ubuntu9.1
И дороговизна поддержки после такой скорой разработки.
скорость решения бизнес-задач на том-же питоне уж точно не ниже, а поддерживаемость, внятность и вменяемость кода и библиотек в разы выше.
Зависит от класса задачи. Одно дело, когда это заведомо сложное приложение разрабатываемое с нуля, а совсем другое когда бизнес-задача состоит в добавлении формы обратной связи к статическому сайту. А поддерживаемость, внятность и вменяемость приложения на symfony или на django, имхо, сильно не отличается.
когда я пересел с БК-01 на ПК и начал изучать Паскаль, бытовало мнение, что программисты на Бейсике никогда не отучаться писать программы через goto, ничего, научился писать структурированный код. Потом плавно и на Дельфи с ООП подсел, не сказал бы, что где-то прям переламывать себя пришлось. Года 2-3 назад перешел на веб и PHP (я не учитываю мелкие опыты, только основные языки), от библиотеки функций, конечно, плеваться хочется, кстати, так и не выучил все параметры, благо в IDE есть подсказка параметров, но в остальном, довольно легко приспособился. Год назад изучил по книжкам Ruby и Rails, все мечтаю на них перелезть, пока не складывается.
Это я все к чему… Поменьше ярлыков на людей вешайте, лучше работать чем холивары разводить.
Это я все к чему… Поменьше ярлыков на людей вешайте, лучше работать чем холивары разводить.
Между прочим эту фразу сказал сам великий Дейкстра, впрочем я бы добавил, что фортрановский программист напишет фортрановскую программу на любом языке программирования.
Но в целом, если отвлечся от исключений, то тенденция весьма верно подхвачена, но мне хотелось бы увидеть от автора обобщение её и на другие языки программирования.
Но в целом, если отвлечся от исключений, то тенденция весьма верно подхвачена, но мне хотелось бы увидеть от автора обобщение её и на другие языки программирования.
Я в школе изучал Basic примерно в таком виде, каким он был на Спектрумах, БК и иже с ними, хотя мы использовали интерпретатор QBasic. Но однажды мне зачем-то захотелось почитать справку, и я узнал о прекрасных конструкциях DO… LOOP, SUB… END SUB, FUNCTION… END FUNCTION и подобных. Перейти к ним от прежних GOTO/GOSUB было не представляете как легко. Эти конструкции просто сами напрашивались, без них мало-мальски сложную программу написать было не под силу.
ЗЫ. Сейчас программирую на Perl, и меня уже никаким языком не испугать :)
ЗЫ. Сейчас программирую на Perl, и меня уже никаким языком не испугать :)
Слишком обобщенное мнение.
PHP развивается, Вы посмотрите хотя бы на развитие ООП в нем. Просто как и любой язык он имеет стадии, как Вы сами и указали в статье.
Запоминание в эру IDE и редакторов с подсказками вообще не нужно. Скорее надо понимать и разбираться в основных конструкциях, идеях, паттернах.
И насчет того, что не убирают морально «устаревшие» функции из пхп:
php.net/manual/en/migration53.deprecated.php < — тут даже упомянутые Вами eregi
PHP развивается, Вы посмотрите хотя бы на развитие ООП в нем. Просто как и любой язык он имеет стадии, как Вы сами и указали в статье.
Запоминание в эру IDE и редакторов с подсказками вообще не нужно. Скорее надо понимать и разбираться в основных конструкциях, идеях, паттернах.
И насчет того, что не убирают морально «устаревшие» функции из пхп:
php.net/manual/en/migration53.deprecated.php < — тут даже упомянутые Вами eregi
Весь пост превращается в бред, если программист использует IDE с подсказками.
Неужели Вы действительно думаете, что PHP-программисты ЗАПОМИНАЮТ НАИЗУСТЬ все 3000 стандартных функций с параметрами?
То же самое можно написать про английский или китайский разговорные языки. Там тоже много слов надо запоминать.
Неужели Вы действительно думаете, что PHP-программисты ЗАПОМИНАЮТ НАИЗУСТЬ все 3000 стандартных функций с параметрами?
То же самое можно написать про английский или китайский разговорные языки. Там тоже много слов надо запоминать.
Ага, а тонны говнокода в этом самом IDE в тыкву превращаются ;)
Говнокодеров на php конечно много. Я ни в коем случае не пытался это опровергнуть. Но, «Запоминание ф-ций наизусть» — не является причиной говнокода.
более того «Запоминание ф-ций наизусть» не является признаком высшего проффесионализма или чего-то в этом духе, это просто приходит с опытом, причем временно помоему, если полгода заниматься парсингом или еще какой-нибудь узкой работой то можно что-то и забыть что юзали раньше… бывает я думаю.
Говнокодеров вообще много. FIXED.
В этом то и проблема PHP.
К сожалению, никакой логики в названиях функций для работы со строками и массивами — нету, их приходится запоминать.
Примеры::
Два слова в названии функции:
addslashes
count_chars
Сокращение предлогов:
bin2hex
hebrev
strtolower
И если с этим еще может справиться IDE, то вот с этим — нет:
Префиксы функций:
crc32
str_split
К сожалению, никакой логики в названиях функций для работы со строками и массивами — нету, их приходится запоминать.
Примеры::
Два слова в названии функции:
addslashes
count_chars
Сокращение предлогов:
bin2hex
hebrev
strtolower
И если с этим еще может справиться IDE, то вот с этим — нет:
Префиксы функций:
crc32
str_split
Упс, отправилось рано.
Префиксы функций:
crc32
str_spli
substr
strtoupper
Префиксы функций:
crc32
str_spli
substr
strtoupper
Может. Я просто набираю «str» и жму CTRL+Space и смотрю список ф-ций в котором есть strpos, str_replace, и strToUpper. С аргументами ещё проще.
Проблема в названиях действительно есть. Но она легко решается и она не является причиной говнокода. Говнокод появляется по другим причинам.
Проблема в названиях действительно есть. Но она легко решается и она не является причиной говнокода. Говнокод появляется по другим причинам.
Не во всех функциях есть str, например explode и implode.
НЛО прилетело и опубликовало эту надпись здесь
А ведь и правда — и что? Пускай не будет никакой логики в именовании функций, пусть все разработчики пишут кто во что горазд. Coding Style Guides — нафиг, Макконнелла — сжечь!
там из общей логики выбивается всего с десяток функций. что там запоминать то?
ну даже если вам так трудно их запомнить то напишите свои обертки-алиасы — и нет проблемы.
ну даже если вам так трудно их запомнить то напишите свои обертки-алиасы — и нет проблемы.
Я думаю, что из общей логики выбивается где-то половина.
Проблема в том, что если каждый начнет писать свои обертки, то код станет тяжелее для восприятия другими программистами.
Стоит отметить, что в некоторых фреймворках такие обертки написаны, и помимо прочего еще и работают с mb_string если нужно.
Проблема в том, что если каждый начнет писать свои обертки, то код станет тяжелее для восприятия другими программистами.
Стоит отметить, что в некоторых фреймворках такие обертки написаны, и помимо прочего еще и работают с mb_string если нужно.
Ну, если отвечать на поставленный вопрос, то да — в большинстве других языков (C#, Ruby, Java, JavaScript, Python) это называется split и join. А функции для работы со строкам собраны в специальных объектах/модулях, таким образом их легко можно найти без чтения документации. Explode и implode я встречал только в PHP.
в php Тоже есть split и join)
Не совсем :)
split: This function has been DEPRECATED as of PHP 5.3.0. Relying on this feature is highly discouraged.
split: This function has been DEPRECATED as of PHP 5.3.0. Relying on this feature is highly discouraged.
Не знал про join) При этом split — это разбиение строки по регулярке, и находится в модуле регулярных выражений, а join — напротив находится в строках, но это просто alias для implode.
С проблемами *str* я справился просто и давно (PHP5 ещё не вышел, а 3 уже был не особо актуален) — написал класс инкапсулирующий работу со строками (в т.ч. с разными кодировками, включая unicode). По мере необходимости дописываю недостающие функции, включая те, которых в стандартных библиотеках нет, например преобразование SomeText <-> some_text или some/text.
Перевести на php5.3-namespace и выложить в публичный доступ? =)
Хорошая мысля.
Думаете кому-то интересно? %-/
Ну, мои поделия ( www.phpclasses.org/browse/author/752928.html ) были же интересны некоторым. С чем-то из них я даже Komodo выиграл на ежемесячном конкурсе.
СЛУШАЙТЕ! Господа уважаемые аналитические интеллектуалы!
А вы как с русским языком-то вообще справляетесь? Не перенапряглись запоминать все слова?
Или каждое слово в словарике смотрите? Тьфу на вас, развели базар ни о чем!
А вы как с русским языком-то вообще справляетесь? Не перенапряглись запоминать все слова?
Или каждое слово в словарике смотрите? Тьфу на вас, развели базар ни о чем!
Наименование функций не самая большая проблема пхп.
С опытом все очень даже запоминается.
Темболее с использованием фреймворков.
С опытом все очень даже запоминается.
Темболее с использованием фреймворков.
как минимум надо знать, что есть такая-то функция, а для этого ИДЕ мало, надо и доку читать.
например, в похапе есть функция для форматирования числа, ИДЕ, не ИДЕ, но знать о функции надо. а я еще часто использую перл и мне проще написать регулярку.
например, в похапе есть функция для форматирования числа, ИДЕ, не ИДЕ, но знать о функции надо. а я еще часто использую перл и мне проще написать регулярку.
А может быть это совсем не плохо: хотя бы разок залезть в документацию?
И я не защищаю ф-ции php. То что они имеют дебильные названия — это неоспоримый факт. Но я придумал для себя решение и отношусь к этому с пониманием.
Но вот писать, что это главная причина говнокодерства пэхапэшников, потому что у них перестраивается мозг — бредово.
И я не защищаю ф-ции php. То что они имеют дебильные названия — это неоспоримый факт. Но я придумал для себя решение и отношусь к этому с пониманием.
Но вот писать, что это главная причина говнокодерства пэхапэшников, потому что у них перестраивается мозг — бредово.
Каждому своё. Есть люди, склад ума которых предрасположен к PHP, есть любители С++, есть адепты других языков. У каждого что-то получается лучше, что-то понимается легче, что-то запоминается быстрее. И это хорошо.
Благодарю Вас. Вы первый, кажется, поняли мысль про склад ума.
не соглашусь, мне кажется во многом у кого как сложилось, кому когда заработать захотелось и что подвернулось, кому-то просто может нравится веб, но это не предраположенность к PHP или к чему либо другому. Я знаю многих которые ушли из «большого» С++ в «проффесиональный» PHP, есть один случай и наоборот, чаще всего это просто потому что — «так сложилось»
причины это: зарплата, условия, интерес к конечному продукту на выходе.
причины это: зарплата, условия, интерес к конечному продукту на выходе.
Зря потратил время на прочтение поста, не о чем. Что вы хотели этим сказать? Что php плохой язык, что программируя на нем не надо думать, а только подставлять функции?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Работал на php пару месяцев. Пересел на руби и рельсы. Ну вы поняли.
НЛО прилетело и опубликовало эту надпись здесь
Хм… либо один, либо один с половиной. Про один я знаю точно. А в мире PHP их столько, что все упомнить сложно. :)
а программистов криворуких в мире пхп ого-го сколько! вы знали? %)
Ага, успел навидаться.
отвечая нв ваш вопрос -> фреймворков на руби достаточно. начиная от моснтров вроде рельс, заканчивая минималистическими аля sinatrta.
Никто в руби-мире не пользуется «чистым» руби для написания сайтов (плюю в огород пхпешников).
Никто в руби-мире не пользуется «чистым» руби для написания сайтов (плюю в огород пхпешников).
А, да! Про синатру я забыл. Но, поскольку вхож в мир Руби довольно слабо, то это, скорее, то, что «Изя напел».
Справедливости ради замечу, что чистым PHP тоже мало кто пользуется. :)
Справедливости ради замечу, что чистым PHP тоже мало кто пользуется. :)
много, меньше чем для РНР, но много!
Rails
Merb
Ramaze
Padriano
Sinatra
Camping
и еще дофига… И это не говоря о специальных фреймворках для создания API и т.д.
Rails
Merb
Ramaze
Padriano
Sinatra
Camping
и еще дофига… И это не говоря о специальных фреймворках для создания API и т.д.
ну сравните. я заранее знаю, что победит :D
Аналогично. Но Ruby чуток сложнее в освоении, и народа там поменьше. И найти на проект десять человек за полдня нереально. :)
ну и что :) Я свой выбор сделал — целый год сидел и изучал руби и рельсы. Без проблем устроился на должность младшего рейлс-программиста, получаю хорошо (поболее пхпешников-новичков).
Язык сложнее, но гораздо более выразительнее. И да — писать на рельсах ХОРОШО и не понимать РУБИ — не получится. Придется вкурить объектную модель руби. А я знаю, как пхпешники любят объекты и классы %)
Язык сложнее, но гораздо более выразительнее. И да — писать на рельсах ХОРОШО и не понимать РУБИ — не получится. Придется вкурить объектную модель руби. А я знаю, как пхпешники любят объекты и классы %)
НЛО прилетело и опубликовало эту надпись здесь
в чем плюс симфони перед рельсами?
И учат ли в симфони так же как в рельсах — писать максимально понятный код, соблюдать конвенцию, выносить логику представления не только в контроллер но и в cells'ы?
И учат ли в симфони так же как в рельсах — писать максимально понятный код, соблюдать конвенцию, выносить логику представления не только в контроллер но и в cells'ы?
Лично для меня два плюса (один субъективный, другой объективный):
— хорошо знакомый язык (пускай с закидонами, но знакомыми и привычными)
— большая востребованность php решений и большее распространение php хостингов (и админов, способных поднять php приложение с нуля например на vds) — что причина, а что следствие судить не берусь, хотя, похоже, самоподдерживающаяся система. И, имхо, для поднятия приложения на рельсах нужно знать больше, чем для поднятия такого же приложения на симфони. По крайней мере, я так и не нашёл как запустить ruby (равно как и python) приложение как fastcgi без использования дополнительного кода (чужого или своего — не суть). Для php приложения не нужно ничего кроме самого php в такой ситуации.
Минусов при беглом знакомстве с рельсами я у симфони не нашёл, что, в принципе, неудивительно — автор симфони хорошо знаком с рельсами и многое оттуда взял.
Как во фреймворке могут учить? Фреймворк предоставляет возможности, как разработчик их использует — его дело. Я почему-то уверен, что мое приложение на рельсах будет отличаться от такого же моего на симфони только синтаксисом ну, или «костылями» если я не найду в рельсах возможностей, которые мне были доступны в симфони. Например, логика представления в представлении :)
— хорошо знакомый язык (пускай с закидонами, но знакомыми и привычными)
— большая востребованность php решений и большее распространение php хостингов (и админов, способных поднять php приложение с нуля например на vds) — что причина, а что следствие судить не берусь, хотя, похоже, самоподдерживающаяся система. И, имхо, для поднятия приложения на рельсах нужно знать больше, чем для поднятия такого же приложения на симфони. По крайней мере, я так и не нашёл как запустить ruby (равно как и python) приложение как fastcgi без использования дополнительного кода (чужого или своего — не суть). Для php приложения не нужно ничего кроме самого php в такой ситуации.
Минусов при беглом знакомстве с рельсами я у симфони не нашёл, что, в принципе, неудивительно — автор симфони хорошо знаком с рельсами и многое оттуда взял.
Как во фреймворке могут учить? Фреймворк предоставляет возможности, как разработчик их использует — его дело. Я почему-то уверен, что мое приложение на рельсах будет отличаться от такого же моего на симфони только синтаксисом ну, или «костылями» если я не найду в рельсах возможностей, которые мне были доступны в симфони. Например, логика представления в представлении :)
мне два месяца хватило на то, чтобы понять, что с php-программистами я дел иметь не хочу.
RoR, Sinatra/Padrino, Grape, Rack, EventMachine (мы же не ограничиваемся вэбом?), MacRuby, впрочем много их, но они все ненужны ибо есть RoR и Sinatra. Это в похапе каждый студент считает необходимым создать свой говно-фрэимворк и на нем создать свою CMS, в руби такой херни нет.
Потому что ruby (и многие другие языки) гораздо менее дружелюбен к вебу по сравнению с php. Разработчик веб-приложения стоит перед выбором: или использовать чужой код, или с нуля полностью реализовать HTTP-сервер (утрирую, но не сильно). А задача, например, отправка содержимого формы на мыло… Формально PHP является языком для более высокого уровня модели OSI, чем ruby/python. На PHP можно опуститься по уровням, а на ruby нужно подниматься.
Как раз ruby(точнее, rails и прочие фреймворки) более чем дружелюбны к вебу.
Встроенная поддержка актуальных трендов(ajax, rest, etc...), встроенное управление серверным и клиентским кешированием(поведением которого можно управлять) и т.п.
Просто порог входа выше, нужно суметь понять и поместить в голову архитектуру прилжения(фреймворка).
Встроенная поддержка актуальных трендов(ajax, rest, etc...), встроенное управление серверным и клиентским кешированием(поведением которого можно управлять) и т.п.
Просто порог входа выше, нужно суметь понять и поместить в голову архитектуру прилжения(фреймворка).
Вот как раз в «точнее ...» и заключается недружелюбность. Ruby не знает не то, что o ajax, rest, ..., он не знает о HTTP вообще. PHP о нём знает, а ajax, rest и т. п. реализуются на нём такие же (условно, конечно) фреймворками, как и в ruby/python. Не знаю как вы, но я говорю о языке и, максимум, его стандартных библиотеках. Когда я пишу типичное веб-приложение с нуля, без использования повторно используемого кода (сорри, за тавтологию :) ), трудоемкость будет меньше на php
Когда я пишу типичное веб-приложение с нуля, без использования повторно используемого кода
Так зачем?
Не «зачем», а «почему». Лицензионные ограничения например. А чаще просто незнание о существовании чужого кода, который я могу использовать или большой трудоемкости оценки его применимости, особенно при большом количестве вариантов. Типичный пример — я прочитал книжку «PHP» и книжку «Ruby». После прочтения первой я могу написать «хелло юзер» для веба в одну строчку, а после второй не могу, строк 100 (условно) нужно
#!/usr/bin/env ruby
require 'rack'
class HelloWorld
def call(env)
return [200, {}, [«Hello world!»]]
end
end
Где тут 100 строк? Только вот ты после прочтения этой нижки по похапе так и будешь смешивать логику с шаблоном в одном файле, а я использую haml,erb. Просто у ruby разработчиков в отличии от похапешников есть культура кода (навязана тем, что нельзя просто сделать echo «Hello World» >> index.php, и они умеет тратить время с умом — они не будет делать велосипед если он уже изобретен и устраивает.
require 'rack'
class HelloWorld
def call(env)
return [200, {}, [«Hello world!»]]
end
end
Где тут 100 строк? Только вот ты после прочтения этой нижки по похапе так и будешь смешивать логику с шаблоном в одном файле, а я использую haml,erb. Просто у ruby разработчиков в отличии от похапешников есть культура кода (навязана тем, что нельзя просто сделать echo «Hello World» >> index.php, и они умеет тратить время с умом — они не будет делать велосипед если он уже изобретен и устраивает.
Посмотрел www.ruby-doc.org/stdlib/ не нашёл там rack, максимум подходящее по-моему TCPServer, может и меньше 100 строк выйдет простейший HTTP/fastcgi сервер на нём написать.
Что плохого в смешивании в одном файле, если принцип DRY выполняется, код представления отделён от кода бизнес-логики и логики приложения? Зачем плодить сущности без необходимости? Или вы представляете себе любой скрипт на php начинающимся с <html>… и кодом подключения к бд где-то в внутри <form>?
Что плохого в смешивании в одном файле, если принцип DRY выполняется, код представления отделён от кода бизнес-логики и логики приложения? Зачем плодить сущности без необходимости? Или вы представляете себе любой скрипт на php начинающимся с <html>… и кодом подключения к бд где-то в внутри <form>?
Правильно, что не нашли. Rack это фрэимворк для фрэимворков. И с одним только rack можно сделать много больше чем на голом php с одно и тоже время. Если вам конечно охото сделать нечно — index.rb post.rb ololo.rb — это ваше право, но это не ruby way. Вам конечно придется написать свой mod_ruby_via_ass, но это же не язык виноват, что там нет работы через жопу.
>Что плохого в смешивании в одном файле, если принцип DRY выполняется, код представления отделён от кода бизнес-логики и логики приложения? Зачем плодить сущности без необходимости? Или вы представляете себе любой скрипт на php начинающимся с … и кодом подключения к бд где-то в внутри?
Конечно нет! бд подключается инклюдом db.php в config.php который инлюдится в каждый фаил!
Кстати, в php такие появился настоящий fast-cgi?
>Что плохого в смешивании в одном файле, если принцип DRY выполняется, код представления отделён от кода бизнес-логики и логики приложения? Зачем плодить сущности без необходимости? Или вы представляете себе любой скрипт на php начинающимся с … и кодом подключения к бд где-то в внутри?
Конечно нет! бд подключается инклюдом db.php в config.php который инлюдится в каждый фаил!
Кстати, в php такие появился настоящий fast-cgi?
Давайте сравнивать или язык с языком, или фреймворки/библиотеки с фреймворками/библиотеками? Возможно (не интересовался готовыми решениями), с учетом последних, ruby и одержит убедительную победу по скорости разработки, но я сторонник «php way» хотя бы при изучении — сначала пишем с нуля, потом по мере роста кодовой базы выделяем, следуя принципу DRY, фактически свой фреймворк и только затем начинаем сравнить свой «велосипед» с готовыми решениями и выбираем то ли внести в свой хорошие идеи из готовых, то ли переводить свои приложения на готовые. Желательно, чтобы для первого варианта были объективные причины, а не только тщеславие или нежелание разбираться с чужими.
В случае одного файла инклуды не в тему. Модель от контроллера и контроллер от представления отбиваются пустыми строками :)
Таки появился, можно даже на хабре найти как-то типа «true fastcgi в php» была статья.
В случае одного файла инклуды не в тему. Модель от контроллера и контроллер от представления отбиваются пустыми строками :)
Таки появился, можно даже на хабре найти как-то типа «true fastcgi в php» была статья.
В руби, на сколько я знаю, отсутствует какая либо прослойка между вэбсевером и приложением кроме как rack. Если так охота php-way напишите свой mod_ruby, вы же мастер все с нуля писать. Не вижу в зависимости от rack ничего плохого — развитие от этого только быстрее. Однако, таки можно использовать ruby без каких либо гемов с апачем(AddHandler cgi-script .rb
Options +ExecCGI):
#!/usr/bin/ruby
puts «Content-Type: text/html»
puts
puts «Hello Douche!»
А можно еще так (cgi входить в стандартную библиотеку):
#!/usr/bin/ruby
require 'cgi'
# Create a cgi object, with HTML 4 generation methods.
cgi = CGI.new('html4')
# Ask the cgi object to send some text out to the browser.
cgi.out {
cgi.html {
cgi.body {
cgi.h1 { 'Hello douche!' }
}
}
}
Where is your god now?
>хотя бы при изучении — сначала пишем с нуля, потом по мере роста кодовой базы выделяем, следуя принципу DRY, фактически свой фреймворк
Иначе говоря, тратим в разы больше времени, на разработку, пишем свой код (а бывает и говнокод) вместо того, чтобы взять готовое? И часто ли свой адаптер для mysql пишете? У вас вероятно есть своя коллекция php расширений, вы же все с нуля пишете всегда.
>Таки появился, можно даже на хабре найти как-то типа «true fastcgi в php» была статья.
Читал, где в продакшене используется? И много ли людей пишут под true fastcgi?
Options +ExecCGI):
#!/usr/bin/ruby
puts «Content-Type: text/html»
puts
puts «Hello Douche!»
А можно еще так (cgi входить в стандартную библиотеку):
#!/usr/bin/ruby
require 'cgi'
# Create a cgi object, with HTML 4 generation methods.
cgi = CGI.new('html4')
# Ask the cgi object to send some text out to the browser.
cgi.out {
cgi.html {
cgi.body {
cgi.h1 { 'Hello douche!' }
}
}
}
Where is your god now?
>хотя бы при изучении — сначала пишем с нуля, потом по мере роста кодовой базы выделяем, следуя принципу DRY, фактически свой фреймворк
Иначе говоря, тратим в разы больше времени, на разработку, пишем свой код (а бывает и говнокод) вместо того, чтобы взять готовое? И часто ли свой адаптер для mysql пишете? У вас вероятно есть своя коллекция php расширений, вы же все с нуля пишете всегда.
>Таки появился, можно даже на хабре найти как-то типа «true fastcgi в php» была статья.
Читал, где в продакшене используется? И много ли людей пишут под true fastcgi?
Разработка своего mod_ruby другой уровень и другой язык.
Про CGI я знаю — запускал так приложения минимум на паре десятков языков за последние год-полтора, чтобы оценить целесообразность перехода на них с php. Увы, тормознуто получается. Другие трудности начинались при попытках использования fastcgi или обычного http-сервера (с nginx или lighttpd для статики). Встроенной поддержки таких «конфигов» практически ни в одном языке нет.
Про CGI я знаю — запускал так приложения минимум на паре десятков языков за последние год-полтора, чтобы оценить целесообразность перехода на них с php. Увы, тормознуто получается. Другие трудности начинались при попытках использования fastcgi или обычного http-сервера (с nginx или lighttpd для статики). Встроенной поддержки таких «конфигов» практически ни в одном языке нет.
Проблема — «После прочтения первой я могу написать «хелло юзер» для веба в одну строчку, а после второй не могу, строк 100 (условно) нужно»
Я написал при помощи rack helloworld короче, вам не понравилось наличие rack (ну ок, религия такая, надо уважать чужую религию), я вам написал helloworld для web'a без помощи внешних библиотек — теперь вам, что не нравится?
FYI: mod_php не входит в стандартную библиотеку php и уж точно не стандартный модуль apache. Любая книжка по rails скажет в качестве сервера использовать passenger + ree в продакшене и mogrel в девелопинге. WEBrick (web server) входит в стандартную библиотеку. WYGN?
Я написал при помощи rack helloworld короче, вам не понравилось наличие rack (ну ок, религия такая, надо уважать чужую религию), я вам написал helloworld для web'a без помощи внешних библиотек — теперь вам, что не нравится?
FYI: mod_php не входит в стандартную библиотеку php и уж точно не стандартный модуль apache. Любая книжка по rails скажет в качестве сервера использовать passenger + ree в продакшене и mogrel в девелопинге. WEBrick (web server) входит в стандартную библиотеку. WYGN?
Использование устаревших (?) медленных (!) интерфейсов :)
В том и дело, что это скажет книжка по rails, а не книжка по ruby. Книжка по php и книжка по symfony/zend/yii/kohana/… скажут насчёт развертывания приложения практически одно и то же (а скорее вторая сошлется на первую и опишет небольшой тюнинг настроек). Книжка по ruby приведёт пример CGI приложения и сошлётся на книжки по rails/sinatra/rack/… Для начала нормальной разработки нужно две книжки, а не одна.
В том и дело, что это скажет книжка по rails, а не книжка по ruby. Книжка по php и книжка по symfony/zend/yii/kohana/… скажут насчёт развертывания приложения практически одно и то же (а скорее вторая сошлется на первую и опишет небольшой тюнинг настроек). Книжка по ruby приведёт пример CGI приложения и сошлётся на книжки по rails/sinatra/rack/… Для начала нормальной разработки нужно две книжки, а не одна.
«Книжка по php и книжка по symfony/zend/yii/kohana/… скажут насчёт развертывания приложения практически одно и то же»
А что удивительного? На ruby/python пишут в том числе и десктопные приложения с графическим интерфейсом, много чего еще делают. А на php только сайты и клепают, потому в книжку по php запихивают все, а точнее любая книжка по php, это книжка по программированию на php для web (а нередко еще и справочник по настройке апача).
Хотите программировать для web на ruby/python, покупайте соответствующую книжку, аля «программирование на python/ruby для web».
А что удивительного? На ruby/python пишут в том числе и десктопные приложения с графическим интерфейсом, много чего еще делают. А на php только сайты и клепают, потому в книжку по php запихивают все, а точнее любая книжка по php, это книжка по программированию на php для web (а нередко еще и справочник по настройке апача).
Хотите программировать для web на ruby/python, покупайте соответствующую книжку, аля «программирование на python/ruby для web».
Знал что этот аргумент всплывёт, даже сам хотел его привести. Но тогда смысл коммента бы пропал :)
Те книжки, что попадались на глаза были, если не по названию, то по сути книжками по Django/RoR и ссылались на книжки по Python/Ruby для изучения синтаксиса (имея опыт программирования на других языках, по крайней мере императивных, можно разобраться и без них, но не зная что такое цикл или ветвление — имхо, бесполезно даже пытаться).
Те книжки, что попадались на глаза были, если не по названию, то по сути книжками по Django/RoR и ссылались на книжки по Python/Ruby для изучения синтаксиса (имея опыт программирования на других языках, по крайней мере императивных, можно разобраться и без них, но не зная что такое цикл или ветвление — имхо, бесполезно даже пытаться).
Ну вот специально полез на амазон поглазеть какие там книжки есть. Набрал python web, у первой вылезшей книги просто негде поглазеть оглавление, а вот у второй же найденной все пучком. Начинается с пайтоновского синтаксиса, затем запуск первого приложения на джанго, и далее уже идет речь о самом джанго.
Что говорит о более высоком пороге входа(всего на одну небольшую книжку!), но почему это должно становиться таким существенным аргуентом против данной технологии?
Да нет (почти) у меня серьезных аргументов против python или ruby. Но у меня нет аргументов за переход c php на них, раз уж так сложилось, что в начале 2000-х я выбирал между PHP и Perl и выбрал PHP. Профита не вижу ни для себя, ни для, тем более, заказчика, что ему есть за что переплачивать хотя бы за хостинг/администрирование vds.
Профита не вижу ни для себя, ни для, тем более, заказчика, что ему есть за что переплачивать хотя бы за хостинг/администрирование vds.
Скорость и качество разработки.
А хостинг, как уже сказали, можно сделать и бесплатный(GAE для Django или Heroku для Rails)
Скорость и качество разработки.
А хостинг, как уже сказали, можно сделать и бесплатный(GAE для Django или Heroku для Rails)
Не вижу я от чего они повысятся, django/ror примерно одного уровня с активно мною используемым symfony (он многое взял из первых ещё на начальных этапах разработки, при закладывании его архитектуры). A symfony2 (даже беты ещё правда нет), я бы сказал даже повыше.
Насчёт хостинга был неправ, давно не интересовался.
Насчёт хостинга был неправ, давно не интересовался.
Неделя, потраченная на эти книги, впоследствии окупится в разы.
>Использование устаревших (?) медленных (!) интерфейсов :)
Так не используйте CGI, используйется passenger/thin/mongrel/что-то еще + rack based framework.
Дело в том, что в отличии от php, ruby is not only for homepages. На ruby можно писать и демоны, и десктопные приложения, и клиенты разных сервисов, и вэб-приложения. Следовательно в книже по Ruby пойдет речь не о web приложении, а о языке в целом, а не о том как сделать «сайт визитка за 5 минут», там расскажут как работать с блоками, лямбдами, хэшами, циклами, гемами и прочими вещами.
Никому (кроме безмозглый свичеров с php) не стукнет в голову писать на голом ruby web приложение. Так, что да, надо 2 книжки — по Ruby и по рельсам. Можно обойтись одной книжкой и чтением документации к фрэимворку, но включить мозг придется.
Такие дела.
Так не используйте CGI, используйется passenger/thin/mongrel/что-то еще + rack based framework.
Дело в том, что в отличии от php, ruby is not only for homepages. На ruby можно писать и демоны, и десктопные приложения, и клиенты разных сервисов, и вэб-приложения. Следовательно в книже по Ruby пойдет речь не о web приложении, а о языке в целом, а не о том как сделать «сайт визитка за 5 минут», там расскажут как работать с блоками, лямбдами, хэшами, циклами, гемами и прочими вещами.
Никому (кроме безмозглый свичеров с php) не стукнет в голову писать на голом ruby web приложение. Так, что да, надо 2 книжки — по Ruby и по рельсам. Можно обойтись одной книжкой и чтением документации к фрэимворку, но включить мозг придется.
Такие дела.
Я это прекрасно понимаю, но вот оказался таким безмозглым свичером и стал писать веб-приложение на голом python (на ruby не стал — понял что будет тоже самое) — на голом PHP куда удобнее и быстрее пишется, даже если не учитывать время на уточнение синтаксиса и поиск нужных классов/функций в стандартных библиотеках. Банально нужно писать много инфраструктурного кода, PHP работает, имхо, на уровень (если не на два) выше в модели OSI и фреймворки для него дают лишь удобство работы на этом уровне., но сам уровень поднимать не нужно.
А знаете почему оказались? Потому, что совсем не знаете инструменты с которыми собирались работать. В комментариях не раз проскакивало то, что для стандартный функций тут писали свои обвертки и костыли. Ну и как далеко вы уйдете на голом php? Не дальше «сайта-визитки», ну максимум недо-блог. (незабываем, что ваша религия не позволяет вам использовать библиотеки которых нет из коробки)
Причем тут модель OSI мне не понятно, что ruby, что php там на одном уровне. Единственное я не знаю как у php с 4 уровнем OSI.
Причем тут модель OSI мне не понятно, что ruby, что php там на одном уровне. Единственное я не знаю как у php с 4 уровнем OSI.
Я прочитал книжку про язык :) Там было про работу с сокетами и работу CGI. Поизучал стандартные библиотеки — не нашёл то, что нужно (fastcgi). Начал реализовывать. Для PHP, кстати, тоже писал «обёртки», чтобы не держать в голове противоречивость именования и использования библиотечных функций и различий однобайтовых кодировок и utf8.
Моя религия мне не позволяет не использовать библиотеки не из коробки, а использовать библиотеки не из коробки, работу которых я не понимаю. Грубо говоря, писал свой ORM или фреймворк, узнал случайно об «аналогах», сравнил свой и чужой (не только возможности, но и реализацию), увидел, что мой хуже, стал использовать чужой, прекрасно понимая как он работает и почему именно так. Не увидел — не стал (возможно позаимствовал какие-то идеи).
PHP работает над HTTP/fast-cgi, ruby его реализует.
Слушать сокеты может
Моя религия мне не позволяет не использовать библиотеки не из коробки, а использовать библиотеки не из коробки, работу которых я не понимаю. Грубо говоря, писал свой ORM или фреймворк, узнал случайно об «аналогах», сравнил свой и чужой (не только возможности, но и реализацию), увидел, что мой хуже, стал использовать чужой, прекрасно понимая как он работает и почему именно так. Не увидел — не стал (возможно позаимствовал какие-то идеи).
PHP работает над HTTP/fast-cgi, ruby его реализует.
Слушать сокеты может
Вообщем как в статье и написано — анализировать вы не умеете. Покажите мне книжку по ruby, чтобы там не было написано о рельсах. Вы не разобравший доконца в инструменте начали городить свой велосипед. Кстати, fastcgi для руби находится, вы не поверите, по запросу fastcgi ruby.
>PHP работает над HTTP/fast-cgi, ruby его реализует.
Каким это образом? все тот же уровень. Или у вас разрыв мозга от того, что сервер и приложение написаны на однои и том же языке? Ruby может работать как в cgi, как и в fastcgi режиме (в отличии от похапе — нормальный fast cgi). Вы уже ушли далеко от темы и показали свои глубокие знания.
>PHP работает над HTTP/fast-cgi, ruby его реализует.
Каким это образом? все тот же уровень. Или у вас разрыв мозга от того, что сервер и приложение написаны на однои и том же языке? Ruby может работать как в cgi, как и в fastcgi режиме (в отличии от похапе — нормальный fast cgi). Вы уже ушли далеко от темы и показали свои глубокие знания.
Написано-то оно написано, как о «каркасе», по аналогии ;) с php каркас не обязателен, а для простейших «hello world» излишен.
Кстати, вы не поверите, но по запросу fastcgi ruby находятся какие-то сторонние проекты, а не как настроить fastcgi штатными средствами языка. В книжке, кстати, тоже какой-то сторонний проект был приведён.
Глубоких знаний ruby я демонстрировать даже не пытался, в виду явного их отсутствия. Они ограничены книгой «Программирование на языке Ruby» Фултона (перевод «The Ruby Way. Second Edition»)
Кстати, вы не поверите, но по запросу fastcgi ruby находятся какие-то сторонние проекты, а не как настроить fastcgi штатными средствами языка. В книжке, кстати, тоже какой-то сторонний проект был приведён.
Глубоких знаний ruby я демонстрировать даже не пытался, в виду явного их отсутствия. Они ограничены книгой «Программирование на языке Ruby» Фултона (перевод «The Ruby Way. Second Edition»)
Мы все же хотим написать приложение, а не helloworld. В любой книжке по рельсами пишут, что ruby это вам не для hello world'ов.
>Кстати, вы не поверите, но по запросу fastcgi ruby находятся какие-то сторонние проекты, а не как настроить fastcgi штатными средствами языка. В книжке, кстати, тоже какой-то сторонний проект был приведён.
Да. Это ruby way. Вероятно если вы посетити ruby-toolbox.com/ у вас просто разорвется мозг от того, сколько всего было написано до вас.
>Кстати, вы не поверите, но по запросу fastcgi ruby находятся какие-то сторонние проекты, а не как настроить fastcgi штатными средствами языка. В книжке, кстати, тоже какой-то сторонний проект был приведён.
Да. Это ruby way. Вероятно если вы посетити ruby-toolbox.com/ у вас просто разорвется мозг от того, сколько всего было написано до вас.
Да какая все-таки разница, кто реализовал fastcgi: авторы языка или его пользователи?
Увеличиваются риски, увеличивается количество кода за которым надо следить, увеличивается количество документации, которую надо читать.
Не увеличиваются.
Для этого кода все так же написаны тесты, у него много пользователей, и он так же активно развивается силами сообщества.
Для этого кода все так же написаны тесты, у него много пользователей, и он так же активно развивается силами сообщества.
А вот как раз у вас больше шансов где-то ошибиться, реализуя вручную, например, авторизацию вместо установки того же devise, которым пользуются и который тестируют тысячи пользователей.
… и при этом на настройку уходит не больше десяти минут, есть поддержка авторизации как минимум тремя методами(включается одной строчкой конфига), за считанные минуты можно прикрутить openid/oauth/fbconnect
На Python =)
Сохраняем как hello.py, запускаем, открываем в браузере: localhost:8080 — все работает. Даже не нужно настраивать никаких апачей.
- #!/usr/bin/env python
- import cherrypy
- class HelloWorld:
- @cherrypy.expose
- def index(self):
- return "Hello world!"
- cherrypy.quickstart(HelloWorld())
Сохраняем как hello.py, запускаем, открываем в браузере: localhost:8080 — все работает. Даже не нужно настраивать никаких апачей.
cherrypy часть стандартной бибилотеки?
Почему-то, как только начинается сравнение языков, любители python/ruby начинают приводить примеры с использованием стороннего кода, не входящего в стандартные библиотеки языка.
Почему-то, как только начинается сравнение языков, любители python/ruby начинают приводить примеры с использованием стороннего кода, не входящего в стандартные библиотеки языка.
Apache часть стандартной библиотеки php?
И какая в общем-то разница, cherrypy часть стандартной библиотеки или нет? Он от этого не хуже. Было бы странно, если бы в стандартную библиотеку включался такой высоуровневый фреймворк.
Apache часть типичной инфраструктуры, интеграция с ним часть «родного» руководства по установке. Была бы в руководстве python ссылка на cherrypy как на рекомендованный способ использования python в вебе вопросов бы не было, но её там нет.
Читал я это всё (а кое что пробовал даже на продакшене) — на тех страницах минимум половина ссылок прокликана. Но вот сложно мне эти «простыни» назвать рекомендованным способом запуска приложений, особенно учитывая «There have been numerous attempts to create the best possible interface» — раз было numerous attempts значит не всё так просто и у существующих решений есть существенные недостатки.
Вообще практически любое решение в нашем деле — компромисс. Вопрос лишь в том, какой компромисс наиболее приемлем под ваши конкретные задачи.
Выбирает между альтернативами часто заказчик, что он, по-вашему, выберет между вариантами:
— php/Drupal+неделя работы и хостинг за 300 руб/месяц
— php/symfony+две недели работы и хостинг за 150 руб/месяц
— php+три недели работы и хостинг за 100 руб/месяц
— python/django+три недели работы и хостинг за 500 руб/месяц
— python+шесть недель работы и хостинг за 500 руб/месяц
— php/Drupal+неделя работы и хостинг за 300 руб/месяц
— php/symfony+две недели работы и хостинг за 150 руб/месяц
— php+три недели работы и хостинг за 100 руб/месяц
— python/django+три недели работы и хостинг за 500 руб/месяц
— python+шесть недель работы и хостинг за 500 руб/месяц
Почему у вас вдруг на python/django сколько же работы, сколько на php без фреймворков? При том, что django один из тех фреймворков, что сами генерируют sql на основе классов модели и админку.
Где вы такой хостинг дорогой для Python нашли? Можно взять Google App Engine, 500Мб места и 5 миллионов запросов в месяц вашему заказчику будут обходится абсолютно бесплатно. Либо, вот первый попавшийся: www.1gb.ru/price.php (от 135руб/мес).
Сам я уже таким проектами (на пару недель) давно не занимаюсь.
Где вы такой хостинг дорогой для Python нашли? Можно взять Google App Engine, 500Мб места и 5 миллионов запросов в месяц вашему заказчику будут обходится абсолютно бесплатно. Либо, вот первый попавшийся: www.1gb.ru/price.php (от 135руб/мес).
Сам я уже таким проектами (на пару недель) давно не занимаюсь.
Потому что уровень моего знания и django, и python ниже чем symfony/php :) В теории и на учебных задачах вроде всё понятно, но на практике наверняка столкнусь с какими-то «подводными камнями», с которыми придётся разбираться.
symfony тоже генерирует SQL на основе описания модели (стандартный способ — в YAML файле, генерируется и php, и sql). Как и админку, но опыт показывает, что скаффолдинг заказчика не устраивает как правило и на админку уходит чуть ли не больше времени чем на «юзерспейс».
Как минимум летом у GAE и Django дружба была не совсем полноценная (джанго ориентирована на РСУБД, а GAE такой не предоставляет — связей many-to-many «из коробки» точно не было, тот же скафолдинг работал криво).
Насчёт хостинга беру свои слова назад, сильно подешевело с тех пор как интересовался.
symfony тоже генерирует SQL на основе описания модели (стандартный способ — в YAML файле, генерируется и php, и sql). Как и админку, но опыт показывает, что скаффолдинг заказчика не устраивает как правило и на админку уходит чуть ли не больше времени чем на «юзерспейс».
Как минимум летом у GAE и Django дружба была не совсем полноценная (джанго ориентирована на РСУБД, а GAE такой не предоставляет — связей many-to-many «из коробки» точно не было, тот же скафолдинг работал криво).
Насчёт хостинга беру свои слова назад, сильно подешевело с тех пор как интересовался.
У меня был опыт общения с рельсами. И если честно, то меня стошнило от самой идеи запихать всё в Руби. На мой взгляд, проще нормально разобраться с SQL, HTML и т.п., чем пользоваться тем извращением, которое сделано для работы с перечисленным в рельсах.
%) ну конечно же, AR-паттерн сакс, и Фаулер описывая его в своей знаменитой книги — круто ошибался.
Мне кажется вы впадаете в крайность. AR прекрасная штука что бы держать бизнес логику объекта в одном месте, а не размазывать ее по коду. Но пытаться все манипуляции с данным делать через AR это не есть разумно :) SQL это прекрасный инструмент и его нужно знать и использовать.
Люблю руби, но мне кажется изза того что на нем так просто делать DSL, рубисты пытаются делать прослойки для всего до чего руки дотянутся. CSS, HTML, SQL b nl. Иногда это не пользу, иногда — нет.
Люблю руби, но мне кажется изза того что на нем так просто делать DSL, рубисты пытаются делать прослойки для всего до чего руки дотянутся. CSS, HTML, SQL b nl. Иногда это не пользу, иногда — нет.
конечно, у меня на работе некоторая часть запросов отделена от AR.
Но что плохого в том, чтобы использовать Haml/sass для html/css?
Но что плохого в том, чтобы использовать Haml/sass для html/css?
Как раз с Haml/sass у меня опыта почти никакого. Думаю ни чего плохого в этом нет. Если помогает команде делать более качественный код, то я только за.
… кстати может расскажете _ваши_ ощущения от Haml/sass?
К подобным «прослойкам» у меня только два требования:
1) Человек должен четко понимать как оно внутри там работает. Видел не раз как на ORM/AR люди писали какие то жуткие и тормозные конструкции, там где на SQL это было бы пару строк.
2) Что бы «прослойка» не инкапсулировала, у меня всегда должен быть способ сделать чтото «вручную»
собственно я не спорю с вами. Руби, имхо, лучше PHP по многим показателям.
… кстати может расскажете _ваши_ ощущения от Haml/sass?
К подобным «прослойкам» у меня только два требования:
1) Человек должен четко понимать как оно внутри там работает. Видел не раз как на ORM/AR люди писали какие то жуткие и тормозные конструкции, там где на SQL это было бы пару строк.
2) Что бы «прослойка» не инкапсулировала, у меня всегда должен быть способ сделать чтото «вручную»
собственно я не спорю с вами. Руби, имхо, лучше PHP по многим показателям.
НЛО прилетело и опубликовало эту надпись здесь
Это крайне субъективные мысли…
1. Руби более OO язык. Все объект. PHP начинался как процедурный язык и это очень заметно и сейчас.
2. Более лаконичный и выразительный синтаксис. Это совсем субъективно :) но многие соглашаются с этим.
3. В руби есть логика в стандартной библиотеки. Мое _имхо_ что в php этой логики меньше. Сужу по времени которые я провожу в документации к языку. В руби это время меньше, хоть опыта у меня с ним и и меньше.
4. Удобная irb консоль. Я знаю про php -a но это не сравнимо
5. Обработка ошибок. Наверно я избалован другими языками, но я убей не могу понять почему какие то ф-ции генерят ошибки, а какието выкидывают исключения. В руби, только исключения. А собачка, это яркий пример плохого архитектурного решения.
6. Многопоточность. И не надо напоминать что в PHP есть различные костыли для этого. Они ужасны. :)
7. Monkey patch и прочие прелести мета программирования. Да, в PHP можно добиться чего то похоже при помощи расширений. Но это уже более похоже на грязный хакинг.
8. Сообщество. По моим ощущениям руби сообщество, менее численно, более активно и более качественно. Если совсем утрировать, то опенсорс на пхп это чаще конечный продукт (CMS, магазин или блогплатформа), а в руби чаще делают библиотеки. Жив дух хакерства :)
Я человек прагматичный. ЯП это не более чем инструмент. И у PHP и у Ruby есть свои минусы. Холиварить не хотелось бы. И в PHP и ruby можно писать и хороший и плохой код. Но писать хороший код в руби легче.
Например в ruby для меня не логично, что 0 не приводится к false. Это тоже надо просто запомнить :)
1. Руби более OO язык. Все объект. PHP начинался как процедурный язык и это очень заметно и сейчас.
2. Более лаконичный и выразительный синтаксис. Это совсем субъективно :) но многие соглашаются с этим.
3. В руби есть логика в стандартной библиотеки. Мое _имхо_ что в php этой логики меньше. Сужу по времени которые я провожу в документации к языку. В руби это время меньше, хоть опыта у меня с ним и и меньше.
4. Удобная irb консоль. Я знаю про php -a но это не сравнимо
5. Обработка ошибок. Наверно я избалован другими языками, но я убей не могу понять почему какие то ф-ции генерят ошибки, а какието выкидывают исключения. В руби, только исключения. А собачка, это яркий пример плохого архитектурного решения.
6. Многопоточность. И не надо напоминать что в PHP есть различные костыли для этого. Они ужасны. :)
7. Monkey patch и прочие прелести мета программирования. Да, в PHP можно добиться чего то похоже при помощи расширений. Но это уже более похоже на грязный хакинг.
8. Сообщество. По моим ощущениям руби сообщество, менее численно, более активно и более качественно. Если совсем утрировать, то опенсорс на пхп это чаще конечный продукт (CMS, магазин или блогплатформа), а в руби чаще делают библиотеки. Жив дух хакерства :)
Я человек прагматичный. ЯП это не более чем инструмент. И у PHP и у Ruby есть свои минусы. Холиварить не хотелось бы. И в PHP и ruby можно писать и хороший и плохой код. Но писать хороший код в руби легче.
Например в ruby для меня не логично, что 0 не приводится к false. Это тоже надо просто запомнить :)
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Как я понимаю, там сравнивается
ruby 1.9.2p0 (2010-08-18 revision 29036) [i686-linux]
с
PHP 5.3.2-1ubuntu4 with Suhosin-Patch (cli) (built: Apr 9 2010 08:23:39)
И по тестам, кстати, ruby сильно быстрее php в некоторых тестах, но в общей массе такой же медленный.
ruby 1.9.2p0 (2010-08-18 revision 29036) [i686-linux]
с
PHP 5.3.2-1ubuntu4 with Suhosin-Patch (cli) (built: Apr 9 2010 08:23:39)
И по тестам, кстати, ruby сильно быстрее php в некоторых тестах, но в общей массе такой же медленный.
JavaScript V8/Erlang к примеру выигрывают у них обоих, при этом в свою очередь проигрывают тому же C#. PHP по тем тестам практически самый медленный получается. Лишь ruby 1.8.7 медленне.
НЛО прилетело и опубликовало эту надпись здесь
ну какие они близнице, если у них даже синтаксис разный?
Я бы добавил ещё и python :) В принципе причина для перехода между ними должна быть, имхо, одна — ТЗ. Посредственный программист (типа меня) легко осовит и руби/рельсы, и питон/джанго, и пхп/симфони(зенд, кохана, ыии, ...) для решения задач, пускай и гуру конкретной платформы решат её эффективнее. А если ТЗ ЯП не ограничивает, то выбор дела вкуса и/или понимания (пускай и кажущегося) что именно для этого проекта именно эта платформа наиболее ярко покажет свои плюсы, а минусы будут незаметны.
Где-то наблюдал презентацию Ехуды Каца, там Ruby 1.9(2), если не ошибаюсь, уступал в скорости только python 2, обгоняя PHP, Python3, Perl и еще несколько популярных в веб языков. Конечно это обобщенный показатель, например в работе со строками Perl наверняка быстрее Ruby.
Наиболее объективным мне кажется: shootout.alioth.debian.org/
В конечном счете производительность будет зависеть от множества факторов. В частности:
1) Предсказуемость и легкость самого языка и степень кривизны рук тех, кто на нем пишет.
2) Возможности реализовать ту или иную логику (есть ли у ruby и php возможности асинхронной обработки запросов? реализации green threads?).
3) Качество кода используемых компонентов и библиотек. Легкость написания своих на С/C++, так у Python отличный API, удобно, и добротные библиотеки.
В конечном счете производительность будет зависеть от множества факторов. В частности:
1) Предсказуемость и легкость самого языка и степень кривизны рук тех, кто на нем пишет.
2) Возможности реализовать ту или иную логику (есть ли у ruby и php возможности асинхронной обработки запросов? реализации green threads?).
3) Качество кода используемых компонентов и библиотек. Легкость написания своих на С/C++, так у Python отличный API, удобно, и добротные библиотеки.
В сухом остатке, только многопоточность, которая для задач веба слабо важна и чуть более развитое оо, которого PHP достигнет.
Ну все же не совсем так. Действительно одного большого преимущества нет. вопрос общего комфорта.
Я долго считал что мобильный не может стоит дороже 4-5 тыс, ибо это штука просто для звонков. А
потом приобрел Nokia 5800. Я понял что нокия делает достаточно удобные в мелочах телефоны.
Так и тут — вроде нет ни чего принципиально нового, но в руби, для меня, комфорта больше.
мхо выбор между руби и пхп для веба — выбор чисто эмоциональный., ничего такого особенного нет.
Совершенно согласен. Как и во всем IT в целом. Кто то хорошо с линуксом управляется, а ктото делает
мощные кластеры на Windows Server. Главоне голову на плечах иметь.
Могу вам привести несколько доводов в пользу PHP и возразить на все ваши, но это будет ненужный холивар) Например PHP быстрее))
Да нет уж, приведите :) Будет интересно послушать. Для меня спор это инструмент для получеия новой информации, а не
для поднятия самооценки.
НЛО прилетело и опубликовало эту надпись здесь
да нет же. хорошо, если вы крутиться в среде с нормальными людьми и нормальным кодом. У меня вот, на моей нынешней работе начальник трахает меня за плохо-названный метод. И я очень рад этому, я сам постоянно прошу его — прорецензировать мой код и сказать какие места в нем откровенно слабые. Многие мои знакомые вертятся в каких-то непонятных конторах, получают копейки и пишут какой-то полный пе*ец. Но это проблема конечно же людей, а не языка.
(вствая на сторону пхп скажу, что сам язык вполне себе нормальный. Там и ооп, и неймспейсы и даже замыкания. Иногда не очень выразительно, но возможностей для создания абстракций там уж поболее чем в Си, хотя Си мало кто осмеливается обвинять в «херовасти»)
На счет нейминга методов в стандратной библиотеки пхп — ничего сказать не могу, ибо не работал.
(вствая на сторону пхп скажу, что сам язык вполне себе нормальный. Там и ооп, и неймспейсы и даже замыкания. Иногда не очень выразительно, но возможностей для создания абстракций там уж поболее чем в Си, хотя Си мало кто осмеливается обвинять в «херовасти»)
На счет нейминга методов в стандратной библиотеки пхп — ничего сказать не могу, ибо не работал.
НЛО прилетело и опубликовало эту надпись здесь
в целом — да
По Ruby нет такого огромного количества идиотских статей как по РНР для начинающих, что как-бы защищает начинающих программистов от плохого стиля. А еще на Ruby под веб не программируют, а программируют на Rails — это опять-таки защищает программиста от плохого кода, в PHP все еще остается огромное количество людей, которые в лучшем случае создают собственные фреймворки.
Это опять-таки не так преимущество языка, как организации сообщества, инфраструктуры, чтоли.
Это опять-таки не так преимущество языка, как организации сообщества, инфраструктуры, чтоли.
Даже я знаю, что программируют на руби под веб не только на рельсах, но вот принцип «программируем под веб — ищем подходящий под задачи фреймворк» меня не устраивает, а вопрос веб-программирования на руби без использования нестандартного кода практически не раскрыт — приходится писать свои фреймворки. Всё в лучших традициях PHP — сначала свой велосипед потом общепринятые решения
Я Си обвиняю в «хероватости» :) Имею право — в начале 2000-х перешёл с веб-разработки на Си на веб-разработку на ПХП
В ruby/python очень часто идут после нескольких лет работы с php. Соответственно и говорят, о чем наболело. После нескольких лет работы с ruby/python в php никто не идет, т.к. в php все просто хуже (начиная от самого языка и заканчивая коммьюнити и доступными библиотеками). Ruby и python давно уже мейнстрим, с хаскеллом их сравнивать совершенно неправильно. Это вроде все довольно очевидные вещи (ну за исключением «все хуже», которые очевидны людям, язык сменившим).
С php, впрочем, можно работать, и решать любые задачи можно, язык и язык, вполне понимаю людей, которые им довольны. Мол, я вот пишу на php и нормально же пишу, чего эти питонисты с рубистами пристают. Ну и действительно нормально писать можно.
С php, впрочем, можно работать, и решать любые задачи можно, язык и язык, вполне понимаю людей, которые им довольны. Мол, я вот пишу на php и нормально же пишу, чего эти питонисты с рубистами пристают. Ну и действительно нормально писать можно.
В прочем, в пайтоне тоже есть устаревшие API (в модулях os и sys, к примеру, или еще много где), написаные в разных стилях, но этого куда меньше.
НЛО прилетело и опубликовало эту надпись здесь
Знаю как минимум одного человека, который после нескольких лет работы и с php, и с ruby чётко разделил их области применения — frontend веб-приложений php only, всё остальное ruby. Он считает (как я его понял), что на ruby приходится слишком много писать/подключать кода, который напрямую с задачей не связан.
PHP sucks кричат в основном как раз бывшие опытные php-шники. ;) Тех кого php обошел стороной — плевать на него с высокой колокольни. У них и так все в шоколаде.
Подтверждаю. :)
НЛО прилетело и опубликовало эту надпись здесь
Как раз для клепания «гавносайтов» (визиток, хомяков и т. п.) php, имхо, подходит лучше всего. Говорю как человек склепавший их не один десяток и пытавшийся их клепать на python (а после этого изучивший возможность их клепания на ruby).
НЛО прилетело и опубликовало эту надпись здесь
Тут в точку.
НЛО прилетело и опубликовало эту надпись здесь
Так я и считаю, что в целом php не хуже (но и не лучше) «одноклассников» для веб-разработки. Есть минусы, есть плюсы у каждого, есть просто особенности, которые надо знать для эффективного использования. Есть возможность выбирать платформу — выбираем хоть объективно, хоть субъективно, нет — пишем на чём дают. Дают чаще на PHP, имхо.
А вы это о ком? VolCh, как раз, вроде не разочаровался. =)
Месяца 2 — это повезло человеку. Тем, кто начинал программировать для веба в самом начале 2000х (как я) повезло гораздо меньше.
phpBB можно считать успешным крупным проектом?
А Zend Framework двухлетней давности?
И с тем и с другим, довелось работать не мало. PHP sucks совершенно объективно, этого может не замечать только, либо совсем новичок в веб-разработке, а то в программировании вовсе, либо, уж не знаю кто… видимо те, о ком в автор в топике пишет.
phpBB можно считать успешным крупным проектом?
А Zend Framework двухлетней давности?
И с тем и с другим, довелось работать не мало. PHP sucks совершенно объективно, этого может не замечать только, либо совсем новичок в веб-разработке, а то в программировании вовсе, либо, уж не знаю кто… видимо те, о ком в автор в топике пишет.
Что самое смешное, phpBB можно считать «успешным крупным проектом». Он популярен, там много кода. Кто там притащил ощипанного петуха и сказал: «Вот твой человек!»? Формально подходит под определение, да. Но phpBB вплоть до версии 3.0 (тройку я уже не смотрел) был весьма дерьмист по качеству кода.
Да, именно. Потому тройку и так долго ждали, откладывалась она несколько лет. Ее фактически переписывали полностью с нуля. Не ручаюсь сказать, что получилось гораздо лучше. Так ведь какой «крупный успешный проект» на php ни возьми, почти везде, говна лопату да найдешь. Взять вон тот же Wordpress…
Ну а если взять, некий хороший-хороший фреймворк на php и сравнить с неким похожим фреймворком на python, то в лучшем случае, php-шный будет примерно наравне. А если так, нафига писать на php?
Ну а если взять, некий хороший-хороший фреймворк на php и сравнить с неким похожим фреймворком на python, то в лучшем случае, php-шный будет примерно наравне. А если так, нафига писать на php?
Золотые слова. Поэтому на старте PHP всё реже выбирают.
Если примерно наравне, то зачем писать на python/ruby/...? PHP-хостинги являются самыми распространёнными и, как следствие, самыми дешевыми. Специалистов по поддержке найти проще, их больше и они тоже дешевле (правда нужно суметь отделить специалистов от «специалистов»).
Вот не могу найти ни одного аргумента, кроме личных предпочтений, почему я должен рекомендовать заказчику выбрать python/django или ruby/ror вместо php/symfony, особенно если моя скорость разработки много выше на php. А если одно из требований заказчика является написание кода с нуля, без использования нестандартных библиотек, то аргументы в пользу php по-моему очевидны.
Вот не могу найти ни одного аргумента, кроме личных предпочтений, почему я должен рекомендовать заказчику выбрать python/django или ruby/ror вместо php/symfony, особенно если моя скорость разработки много выше на php. А если одно из требований заказчика является написание кода с нуля, без использования нестандартных библиотек, то аргументы в пользу php по-моему очевидны.
С этими «самыми дешёвыми» дочерта проблем. То нет нужного экстеншна, то вообще php старой версии, а админ не хочет апгрейдить. Видимо, от излишне высокой зарплаты. :)
НЛО прилетело и опубликовало эту надпись здесь
Отличный пример! Как же я забыл их упомянуть! Угу, это те парни, которые написали транслятор php (особо подготовленный) в С++. Это пять! Оно так безумно тормозило и ничего нельзя было с этим сделать, что пошли на беспрецедентные меры.
НЛО прилетело и опубликовало эту надпись здесь
FaceBook сами признали, что php они выбрали зря. Если хотите, кину пруф на конференцию.
НЛО прилетело и опубликовало эту надпись здесь
Ну конечно желательно сначала разобраться с AR, прежде чем пользоваться им во всю :D
@user = User.find(1)
и затем во view:
@user.posts.each do |post|
вызовет eager logging, или грубо говоря — «херовый sql» запрос.
Вместо этого лучше делать User.find(1, :include => :posts)
чтобы не выбирать лишние данные из sql лучше писать: User.find(:1, :select => «id,name») и так далее.
Нужно хорошо понимать уровень абстракции, тогда работа будет максимально эффективна.
На счет Haml/Sass:
Haml жжот во все поля %) С ним жизнь упростилась в разы. Между тем, советую вам пользоваться плагинами аля simple_form ля генерации форм. В рельсах и так все просто, а с haml&&simple_form(или formstatic) жизнь вообще становиться сахаром.
С sass дел не имел.
@user = User.find(1)
и затем во view:
@user.posts.each do |post|
вызовет eager logging, или грубо говоря — «херовый sql» запрос.
Вместо этого лучше делать User.find(1, :include => :posts)
чтобы не выбирать лишние данные из sql лучше писать: User.find(:1, :select => «id,name») и так далее.
Нужно хорошо понимать уровень абстракции, тогда работа будет максимально эффективна.
На счет Haml/Sass:
Haml жжот во все поля %) С ним жизнь упростилась в разы. Между тем, советую вам пользоваться плагинами аля simple_form ля генерации форм. В рельсах и так все просто, а с haml&&simple_form(или formstatic) жизнь вообще становиться сахаром.
С sass дел не имел.
Небольшая поправочка — «formtastic» плагин называется. Как «fantastic»
github.com/justinfrench/formtastic
github.com/justinfrench/formtastic
Еще мало работал с AR. Спасибо большое за примеры, был уверен что это возможно, теперь знаю как :)
Совершенно с вами согласен, без понимания как все работает, в RoR опасное количество магии.
Совершенно с вами согласен, без понимания как все работает, в RoR опасное количество магии.
AR смешивает бизнес-логику и логику хранения, DM их отделяет, в моделях DM ничего (в идеале) кроме бизнес-логики и не содержится, модель самодостаточна
конечно AR сакс, DM кул, Фаулер именно так и написал :) и именно DM я использую в php с недавних пор — сказка: Р
НЛО прилетело и опубликовало эту надпись здесь
Конечно хуже, зафига все эти абстракции, когда можно создавать сущности на лету а не пользоваться шаблоном?
Поработов с большим рейлс-проектом начинаешь понимать всю прелесть AR-абстрации, в частности всю прелесть AREL'а (появился в 3-их рельсах) и вещей вроде named_scope'ов :)
Поработов с большим рейлс-проектом начинаешь понимать всю прелесть AR-абстрации, в частности всю прелесть AREL'а (появился в 3-их рельсах) и вещей вроде named_scope'ов :)
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
ИМХО пост — просто холиварный вброс, независимо от изначальных замыслов автора. Начать хотя бы с названия, «жрецы программирования» — это уже сам по себе ярлык, клеймо. Все языковые войны начинаются и заканчиваются примерно одинаково, тут можно либо понять принцип (INT), либо просто мудро запомнить (WIS), но как итог — главное не начинать, а то всё скатится в срач того или иного радиуса кривизны.
Я соглашусь с топикастером. Использую несколько языков в повседневной жизни. В том же руби (который я знаю далеко не идеально), часто получается «угадывать» методы класса, просто потому что они логично названы. В пхп без мануала ни куда.
Доводилось делать на PHP достаточно сложные системы. Несколько раз в головоу приходила идея пройти Zend сертификацию, просто для поддержания тонуса. Качал мануалы читал, отказывался от этой глупой затеи. Очень много вещей нужно просто запоминать. WTF, какая польза от того что я буду на память помнить имена функций и их аргументы? Достаточно знать что такие функции есть. Бездумного заучивания мне на всю жизнь хватило в школе.
Доводилось делать на PHP достаточно сложные системы. Несколько раз в головоу приходила идея пройти Zend сертификацию, просто для поддержания тонуса. Качал мануалы читал, отказывался от этой глупой затеи. Очень много вещей нужно просто запоминать. WTF, какая польза от того что я буду на память помнить имена функций и их аргументы? Достаточно знать что такие функции есть. Бездумного заучивания мне на всю жизнь хватило в школе.
мир пхп — полная задница. здесь всегда будут писать «чистые» sql запросы и гордиться этим.
НЛО прилетело и опубликовало эту надпись здесь
так я знаю, что оно есть. я даже знаю, что на php есть отличный фреймворки. но я так же знаю, что в php есть вот такие персонажи: habrahabr.ru/blogs/php/110767/#comment_3527847 у которых «все запихали в руби»
Итого будем городить over9000 оберток над отлаженным десятилетиями интерфейсом доступа к бд в угоду «чистого» ООП. Я видел к какому кошмару это фанатичное увлечение ООП приводит на примере Zend Framework'а, нет уж спасибо.
ну я ж и говорю — пхп ваше полное говно, даже зенды не спасают :D у нас все в порядке с реализацией и использованием active-record'а.
НЛО прилетело и опубликовало эту надпись здесь
А почему криво-то? Ну правда?
Понятно что нужно понимать где и куда это сувать, но если какие-то конкретные примеры где это не к месту?
П.С. Я не говорю о том, чтобы юзать AR на 100%. В сложных проектах со сложными отношениями между моделями иногда приходится писать чистые SQL запросы, для отображения какой-нибудь примудрой статистики. Но в большинстве случаев, для блогов, сайтов или хабров -> никакие сложные sql запросы нафиг не нужны.
Понятно что нужно понимать где и куда это сувать, но если какие-то конкретные примеры где это не к месту?
П.С. Я не говорю о том, чтобы юзать AR на 100%. В сложных проектах со сложными отношениями между моделями иногда приходится писать чистые SQL запросы, для отображения какой-нибудь примудрой статистики. Но в большинстве случаев, для блогов, сайтов или хабров -> никакие сложные sql запросы нафиг не нужны.
НЛО прилетело и опубликовало эту надпись здесь
Не, вы не хотите чего-то со мной нормально поговорить %) Изначально я был груб, потом исправился и попытался понять вашу точку зрения.
Моя такова — AR-паттерн со всеми приблудами — очень крутая вещь, и реально спасает во всех проектах. Хотите пример?
Допустим у нас есть модель User:
class User < ActiveRecord::Base
# создадим scope:
named_scope :active, :conditions => «is_active = true»
end
теперь чтобы отобрать активных пользователей мы напишем:
User.active.all
Захотим добавить условие? Легко:
User.active.all(:conditions => «email ILIKE %gmail.com»)
В результате получим всех активных пользователей с почтой от гугла. Но зачем нам здесь sql? вынесем его в модель:
class User < ActiveRecord::Base
# создадим scope:
named_scope :active, :conditions => «is_active = true»
named_scope :respond_to_gmail, :conditions => «email ILIKE %gmail.com»
end
Теперь мы сможем комбинировать наши скоупы как хотим, вынося весь sql в модель (бизнес-леер).
С приходом Rails-3 и AREL появилась возможно создавать lazy-запросы (что очень удобно для создания фильтров, поисков и тп)
result_users = User.where(:active => true) # запрос еще не будет отправлен в sql
result_users.order(:id) # отсортируем по id, но запрос так еще не будет отправлен
result_users.first # а теперь запрос будет отправлен и в качестве результата мы получим первого активного пользователя
в общем тут очень много тонкостей и конечно же с этим надо работать, чтобы понять всю прелесть.
Моя такова — AR-паттерн со всеми приблудами — очень крутая вещь, и реально спасает во всех проектах. Хотите пример?
Допустим у нас есть модель User:
class User < ActiveRecord::Base
# создадим scope:
named_scope :active, :conditions => «is_active = true»
end
теперь чтобы отобрать активных пользователей мы напишем:
User.active.all
Захотим добавить условие? Легко:
User.active.all(:conditions => «email ILIKE %gmail.com»)
В результате получим всех активных пользователей с почтой от гугла. Но зачем нам здесь sql? вынесем его в модель:
class User < ActiveRecord::Base
# создадим scope:
named_scope :active, :conditions => «is_active = true»
named_scope :respond_to_gmail, :conditions => «email ILIKE %gmail.com»
end
Теперь мы сможем комбинировать наши скоупы как хотим, вынося весь sql в модель (бизнес-леер).
С приходом Rails-3 и AREL появилась возможно создавать lazy-запросы (что очень удобно для создания фильтров, поисков и тп)
result_users = User.where(:active => true) # запрос еще не будет отправлен в sql
result_users.order(:id) # отсортируем по id, но запрос так еще не будет отправлен
result_users.first # а теперь запрос будет отправлен и в качестве результата мы получим первого активного пользователя
в общем тут очень много тонкостей и конечно же с этим надо работать, чтобы понять всю прелесть.
НЛО прилетело и опубликовало эту надпись здесь
Перекладывая сравнения на магический лад, нужно уметь признать, что тут есть место магии, а заклинания, порой, бывают сложными и трудно объяснимыми, ну а с этим можно только смириться.
php говно :)
Если провести параллели, можно сказать, что человек разговаривающий на русском языке не «прокачал» аналитические навыки, так как русский пестрит разнородными правилами и исключениями из правил, которые необходимо запомнить (некоторые его из-за этого считают самым сложным для изучения), так как Ваша статья написана именно на великом и могучем, то Вы человек «запоминательного» а не аналитического типа.
Не кажется ли Вам, что подобный вывод похож на выводы из анекдота — без ног не слышит?
Не кажется ли Вам, что подобный вывод похож на выводы из анекдота — без ног не слышит?
В русском есть склонения, спряжения, масса исключений из правил и т.п. Русский объективно сложнее, чем, скажем, английский. Однако «аналитические» навыки тут ни при чём. Я готов биться об заклад, что, скажем, незнакомый с русским китаец дольше будет изучать великий и могучий, нежели незнакомый с английским китаец — язык туманного Альбиона.
Тем не менее, параллель проведена некорректно, потому что человеческие языки возникают стихийно, а изменения в них обусловлены массой факторов. Историческими событиями, например. Вот появились в России панталоны, фрак, жилет, — и вошли эти слова в русский, как милые. А вот запустили русские первый спутник. Слышали, наверное. А в англоязычных странах появилось под влиянием слова «sputnik» слово «beatnik».
Теперь смотрим на эсперанто — язык, созданный искусственно. Там всё по правилам. Исключений вроде бы и нет.
Не кажется ли Вам, что Вы поспешили проводить параллели между искусственными и естественными языками?
Тем не менее, параллель проведена некорректно, потому что человеческие языки возникают стихийно, а изменения в них обусловлены массой факторов. Историческими событиями, например. Вот появились в России панталоны, фрак, жилет, — и вошли эти слова в русский, как милые. А вот запустили русские первый спутник. Слышали, наверное. А в англоязычных странах появилось под влиянием слова «sputnik» слово «beatnik».
Теперь смотрим на эсперанто — язык, созданный искусственно. Там всё по правилам. Исключений вроде бы и нет.
Не кажется ли Вам, что Вы поспешили проводить параллели между искусственными и естественными языками?
> Тем не менее, параллель проведена некорректно, потому что человеческие языки возникают стихийно, а
> изменения в них обусловлены массой факторов.
Языки программирования(ЯП) тоже часто возникают не так уж запланировано, как это может казаться, особенно это характерно для ЯП с открытым исходным кодом и множеством разработчиков, где каждый разработчик вносит свой уникальный вклад в развитие языка.
>Не кажется ли Вам, что Вы поспешили проводить параллели между искусственными и естественными языками?
Нет, не кажется, так как при использовании естественного языка, человек досконально владеющий им не обращает внимания на правила и исключения языка при их использовании, так и программист использует уже знакомый ему ЯП не обращая внимания на особенности языка. И в первом и во втором случае лучший результат получается именно тогда, когда люди фокусируются на цели, а не на средствах. Думаю многие читали книги которые написаны по принципу «первая книга на русском языке по технологии ...» и видели проекты, которые написаны по принципу «я вот на хххх написал».
P.S. Мой предыдущий комментарий был о том, что выбор средств не является критерием, по которому можно судить о аналитичности ума.
> изменения в них обусловлены массой факторов.
Языки программирования(ЯП) тоже часто возникают не так уж запланировано, как это может казаться, особенно это характерно для ЯП с открытым исходным кодом и множеством разработчиков, где каждый разработчик вносит свой уникальный вклад в развитие языка.
>Не кажется ли Вам, что Вы поспешили проводить параллели между искусственными и естественными языками?
Нет, не кажется, так как при использовании естественного языка, человек досконально владеющий им не обращает внимания на правила и исключения языка при их использовании, так и программист использует уже знакомый ему ЯП не обращая внимания на особенности языка. И в первом и во втором случае лучший результат получается именно тогда, когда люди фокусируются на цели, а не на средствах. Думаю многие читали книги которые написаны по принципу «первая книга на русском языке по технологии ...» и видели проекты, которые написаны по принципу «я вот на хххх написал».
P.S. Мой предыдущий комментарий был о том, что выбор средств не является критерием, по которому можно судить о аналитичности ума.
Кстати, я, оказывается, не один такую бредовую мысль придумал. Вот ещё один: en.wikipedia.org/wiki/Programmer's_Stone
Почитайте лингвистику. Английский принадлежит к группе аналитических языков, а русский — к группе синтетических.
Эм. Что конкретно мне почитать по лингвистике? Или я, как Вы мне советуете, должен именно «почитать лингвистику»? :)
Что конкретно сказать не могу, ибо руководствуюсь институтским курсом лингвистики (вторая спецуха — переводчик), но в теории английского языка на это делается упор: у английского языка построение фраз строго аналитично, строгий порядок слов, малое количество форм слов и т.д. В русском же все наоборот.
В общем вкратце даже на википедии есть, но конечно не так развернуто как хотелось бы. Попробуйте погуглить эти термины.
В общем вкратце даже на википедии есть, но конечно не так развернуто как хотелось бы. Попробуйте погуглить эти термины.
В целом именно «сумбурное» развитие и виновато в сложившейся ситуации — изначально планировался простой язык для простых вещей, но популярность сделала своё дело в итоге на PHP пытаются писать большие и сложные приложения.
Но это не правда, что ситуация не меняется и с глобальным скоупом и пр. ничего не изменится. Уже давно на смену старым интерфейсам доступа к БД пришёл объектно-ориентированный PDO, также появился Standart PHP Library, тот же класс \DateTime, пространства имён, HttpRequest/Response в ОО-стиле и многое другое, и это всё постепенно вытесняет старые глобальные функции.
Достаточно взглянуть на новые PHP 5.3 фреймворки вроде Symfony2 и ZF2 — это совсем не то, что было раньше, так что тенденция радует.
Но это не правда, что ситуация не меняется и с глобальным скоупом и пр. ничего не изменится. Уже давно на смену старым интерфейсам доступа к БД пришёл объектно-ориентированный PDO, также появился Standart PHP Library, тот же класс \DateTime, пространства имён, HttpRequest/Response в ОО-стиле и многое другое, и это всё постепенно вытесняет старые глобальные функции.
Достаточно взглянуть на новые PHP 5.3 фреймворки вроде Symfony2 и ZF2 — это совсем не то, что было раньше, так что тенденция радует.
хоххо, Вождя уже цитируют:))
Выше написали абсолютную правду: использование подсказок по названиям и аргументам сводит вашу логику на нет.
Я, как человек программировавший на многих языках, могу сказать, что объём аналитической работы при разработке на ПХП равен у меня аналогичному объёму для Явы. Ну точнее, для Явы всё же больше, но если убрать оборачивание каждого пука в объект, то где-то столько же.
Я, как человек программировавший на многих языках, могу сказать, что объём аналитической работы при разработке на ПХП равен у меня аналогичному объёму для Явы. Ну точнее, для Явы всё же больше, но если убрать оборачивание каждого пука в объект, то где-то столько же.
Ахаха, годный вброс, давно такого не было.
особенно понравилось про strpos(). как будто искомая строка не может находиться в 0-й позиции. ну а про автоматическое приведение типов — так вообще…
НЛО прилетело и опубликовало эту надпись здесь
Вы так пишете, будто кому-то дают, скажем, Питон, Руби, ПХП и говорят: «Поиграйся, посмотри, что больше по душе, выбери, а потом иди с этим языком к нам работать». И человек пробует все и выбирает ПХП, так как он у нас «запоминательного типа». Вот тогда выводы статьи имели бы смысл.
А на деле ПХП выбирают, так как на него большой спрос, в него низкий порог вхождения, по нему море материалов, он стоит на всех хостингах и т. п. То есть все ваши рассуждения есть лишь приумножение сущностей.
Многие сидят в ICQ, а не в Джаббере, потому что в аське все их контакты. У многих почта на mail.ru, потому что привыкли. Многие слушают музыку на WMP, потому что в принципе все устраивает. И нет никаких причин выделять всех этих людей в какой-то особый тип.
А на деле ПХП выбирают, так как на него большой спрос, в него низкий порог вхождения, по нему море материалов, он стоит на всех хостингах и т. п. То есть все ваши рассуждения есть лишь приумножение сущностей.
Многие сидят в ICQ, а не в Джаббере, потому что в аське все их контакты. У многих почта на mail.ru, потому что привыкли. Многие слушают музыку на WMP, потому что в принципе все устраивает. И нет никаких причин выделять всех этих людей в какой-то особый тип.
Я видел много проектов, которые на старте писались быстро и дешево. Толпой кодеров. На PHP. С кучей глюков. Потом заказчик решал, что это были плохие кодеры, и менял команду. Становилось ещё хуже. Потом брал нормальных программистов, и они, как правило, не были стеснены в выборе средств. Хоть PHP, хоть Пайтон, хоть Perl, хоть что, лишь бы проект работал.
Не соглашусь с некоторыми пунктами.
>на него большой спрос
Который понижается. -2.26% за год. www.tiobe.com/index.php/content/paperinfo/tpci/index.html
>в него низкий порог вхождения
Как замерять порог вхождения и с чего вы взяли, что в том же питоне он выше?
>он стоит на всех хостингах
К слову, ВДСка сегодня стоит очень дешево, от 150 рублей за месяц.
> по нему море материалов
Лучше мануала по языку программирования, чем питонячьего я в жизни не видел. Который, к тому же, передевен даже на русский и доступен в ВикиКнигах свободно.
>на него большой спрос
Который понижается. -2.26% за год. www.tiobe.com/index.php/content/paperinfo/tpci/index.html
>в него низкий порог вхождения
Как замерять порог вхождения и с чего вы взяли, что в том же питоне он выше?
>он стоит на всех хостингах
К слову, ВДСка сегодня стоит очень дешево, от 150 рублей за месяц.
> по нему море материалов
Лучше мануала по языку программирования, чем питонячьего я в жизни не видел. Который, к тому же, передевен даже на русский и доступен в ВикиКнигах свободно.
>Вы так пишете, будто кому-то дают
чорт, завис
чорт, завис
Можно почитать и предложить идеи, советы по улучшению PHP, основным разработчикам языка.
С таким подходом ассемблер вам категорически противопоказан.
Диалог:
А: Это дерьмо, не ешь!
Б: Да не, нормально.
А: Не ешь, лучше купи себе нормальный торт.
Б: Нууу, я лучше сахаром сверху посыплю, приукрашу… нормально будет. К тому же, мне «В» сегодня за это заплатит. А вчера «Д» и «Е» платили. Кстати, неплохо так выходит.
В: Слышь ты, «А»! Ты что считаешь его говноедом, раз он дерьмо ест? А сам значит такой весь в белом?
А: Нуу, ммм, эээ… Я толерантен. И мне карма дорога. Поэтому не считаю… Прости если обидел, чувак!..
В: То-то же! Эй, «Б», оставь мне кусочек!
А: Это дерьмо, не ешь!
Б: Да не, нормально.
А: Не ешь, лучше купи себе нормальный торт.
Б: Нууу, я лучше сахаром сверху посыплю, приукрашу… нормально будет. К тому же, мне «В» сегодня за это заплатит. А вчера «Д» и «Е» платили. Кстати, неплохо так выходит.
В: Слышь ты, «А»! Ты что считаешь его говноедом, раз он дерьмо ест? А сам значит такой весь в белом?
А: Нуу, ммм, эээ… Я толерантен. И мне карма дорога. Поэтому не считаю… Прости если обидел, чувак!..
В: То-то же! Эй, «Б», оставь мне кусочек!
Станис, какие альтернативы для веб разработки? С такой же интеграцией в html поддержкой всеми хостингами и даже безплатными? Для маленьких сайтов, итд?.. Языков то много, но красивых, функциональных, новомодных решений — встретить очень тяжело.
Perl не пробовали? Без шуток. На нем можно писать очень красиво и элегентно.
Правда я сам так ничего для веб на перле до сих пор не рискнул сделать :). Но для шел-скриптинга самое то. И есть практически во всех юниксах.
Правда я сам так ничего для веб на перле до сих пор не рискнул сделать :). Но для шел-скриптинга самое то. И есть практически во всех юниксах.
Perl для скриптинга мне тоже нравился. А вот в плане веба я с него и утёк на PHP. Но это было давно, и тогда Catalyst'а вроде как не было. :)
Пробовал перл лет 10 назад, когда выбирал язык вместо Си для веба — перл и пхп были тогда для меня одинаково приемлемы, нужна была гостевая книга. То ли я не обнаружил, то ли тогда не было, то ли нет и сейчас и не предвидится, но простых средств внедрения кода в html страницу я не нашёл. Ну и похожесть пхп с си сыграла свою роль.
Сейчас всё очень даже радужно в этом плане: mojolicio.us
Вот @kaineer пишет на Ruby. Вроде доволен. На python есть django и pylons. Альтернативы есть. VDS-ку взять можно вполне задёшево и соорудить там себе счастье.
Кстати Рубины под win загнать реально? вот периодически хочу на него посмотреть, но unix-only останавливает.
Проблемы описанные в посте — достаточно критичны, но перебежать куда-то — никак не рискнусь.
Проблемы описанные в посте — достаточно критичны, но перебежать куда-то — никак не рискнусь.
www.ruby-lang.org/en/downloads/
Для Windows, как видим, есть.
Для Windows, как видим, есть.
НЛО прилетело и опубликовало эту надпись здесь
Сооружать под пхп проще, на личном опыте убедился. В пхп средства взаимодействия с веб-серверами (что как модуль, что как fastcgi) встроены в язык, в python/ruby нужны «прокладки» между логикой обработки http запроса и веб-сервером (писать их самому или использовать готовые типа rack — не суть)
Mongrel — из той же оперы, да? Ну и есть mod_ruby, mod_python для Apache. В чём кардинальное отличие от mod_php?
Я пытался прозрачно заменить Apache+mod_* на nginx+fastcgi на серваке где крутились «хелловорды» питона, руби и пару обычных приложений на пхп. php работают, на python/ruby забил, для питона есть gae, если приспичит питон или гае… руби? не знаю, редмайн нравится со стороны, но выделять под него отдельный сервак, да даже ставить только ради него Апач как-то не хочется.
У меня Redmine отлично вот уже больше года крутится на Nginx с помощью Phusion Passenger™
Согласитесь, что для человека, который видит приложение на ruby первый раз в жизни вариант не самый очевидный. Вообще Installation Guide Redmine явно не рассчитан на людей, которые не знают ничего о куче пакетов. Самая первая (утрируя) строчка «gem ...» уже нуждается в объяснениях.
heroku.com — лучшый друг новичка в RoR.
Человек, который видит приложение руби в первый раз в жизни, может быть только неоптным админом. Но даже любой неопытный админ, уже должен уметь курить мануалы и гуглить.
Вы какой-то странный, уж извините. По всем вашим постам сужу. Постоянно норовите построить новый велосипед, вместо того чтобы поискать уже готовые компоненты (а это первое правило хорошего программиста). Почему-то считаете, что человеку увидевшему в первый раз приложение на php сразу станет очевидно, что с этими php файлами делать.
Я не Ruby программист. И Redmine это первое и единственное Ruby приложение с которым мне довелось иметь дело. О gem я знаю не более, чем то, что это некая система пакетов для удобства управления и установки руби-компонентов и приложений. Но это мне никак не пригодилось, все что я сделал, когда мне нужно было поставить Ruby, это погуглил способы сопряжения его с nginx, выбрал самый удобный и быстрый, а затем поставил все необходимое (и Redmine и Passenger) и freeBSD портов, в одну строчку в консоли. Далее, пара настроек nginx и все работало.
Вы какой-то странный, уж извините. По всем вашим постам сужу. Постоянно норовите построить новый велосипед, вместо того чтобы поискать уже готовые компоненты (а это первое правило хорошего программиста). Почему-то считаете, что человеку увидевшему в первый раз приложение на php сразу станет очевидно, что с этими php файлами делать.
Я не Ruby программист. И Redmine это первое и единственное Ruby приложение с которым мне довелось иметь дело. О gem я знаю не более, чем то, что это некая система пакетов для удобства управления и установки руби-компонентов и приложений. Но это мне никак не пригодилось, все что я сделал, когда мне нужно было поставить Ruby, это погуглил способы сопряжения его с nginx, выбрал самый удобный и быстрый, а затем поставил все необходимое (и Redmine и Passenger) и freeBSD портов, в одну строчку в консоли. Далее, пара настроек nginx и все работало.
«когда мне нужно было поставить Ruby»
*Redmine
*Redmine
Не спорю, что странный, если считать использование чужих готовых компонентов первым правилом. Я первым правилом считаю решить задачу в согласованные с заказчиком сроки. Поиск чёрной кошки в тёмной комнате при отсутствии достоверной информации о её там наличии в это правило плохо вписывается, по-моему. Была бы такая информация во время согласования сроков — другое дело, если считать что поиск и дополивание займёт однозначно меньше времени, чем разработка с нуля.
Я не избегаю готовых решений, но на них не рассчитываю, если таких не знаю, а закладывать в сметы время на их поиски без гарантий, что найду, считаю неэтичным.
Я не избегаю готовых решений, но на них не рассчитываю, если таких не знаю, а закладывать в сметы время на их поиски без гарантий, что найду, считаю неэтичным.
Решение задачи != написание нового велосипеда.
Выбирать инструмент для решения задачи надо до согласования сроков, а не после.
Выбирать инструмент для решения задачи надо до согласования сроков, а не после.
Нерешение задачи == поиск несуществующего решения
Нерешение задачи в заданные сроки == поиск, находка, изучение и допиливание существующего решения не в заданные сроки.
Брать таймаут пару недель на изучение наличия готовых решений при понятной схеме ррешения с нуля за неделю как-то странно, имхо
Нерешение задачи в заданные сроки == поиск, находка, изучение и допиливание существующего решения не в заданные сроки.
Брать таймаут пару недель на изучение наличия готовых решений при понятной схеме ррешения с нуля за неделю как-то странно, имхо
«Брать таймаут пару недель на изучение наличия готовых решений при понятной схеме ррешения с нуля за неделю как-то странно, имхо»
Что за бред? Откуда вы такие сроки берете? Я готовые решения гуглю за пару минут. Отобрать и оценить их применимость обычно отнимает не более четверти часа. Эта процедура может сэкономить, от нескольких часов, до нескольких месяцев.
Что за бред? Откуда вы такие сроки берете? Я готовые решения гуглю за пару минут. Отобрать и оценить их применимость обычно отнимает не более четверти часа. Эта процедура может сэкономить, от нескольких часов, до нескольких месяцев.
Ну хотя бы по ссылке на бенчмарк из 10 способов запуска. Скачать каждый, установить, изучить доки, попробовать написать «хелловорд», потестить под нагрузкой, написать что-то более сложное (прототип проекта?) для оценки имеющихся возможностей и удобства их применения, потестить под нагрузкой… День, по-моему, как минимум. 10 способов — 10 рабочих дней — две календарных недели. И это только выбор способа запуска приложения, а ещё нужно выбрать (или принять решение о самостоятельной разработке) для типичного веб-приложения, навскидку: систему роутинга, средство парсинга заголовков запроса, шаблонизатор, обвязку для БД, систему валидации и биндинга форм, кэш… Причём в ситуации, когда ясно как это разработать самому ровно в необходимых для проекта рамках (без мёртвого кода в частности) и сколько времени эта разработка займёт. В php почти всё из этого списка встроенные средства языка или стандартных библиотек.
«Ну хотя бы по ссылке на бенчмарк из 10 способов запуска. Скачать каждый»
Зачем? Как минимум глядя на результат можно отсеять несколько. Из оставшихся 2/3 отпадет, как не подходящая по формальным требованиям. Например, вам нужен асинхронный режим, а данный фреймворк его не реализует, или наоборот, вы не собираетесь писать в асинхронном стиле. Обычно чтобы отобрать 1-2 кандидата достаточно ознакомиться со списком возможностей на странице проекта. Также чья-то схема работы и способ организации кода, вам может понравиться гораздо больше. Можно еще немного погуглить, почитать отзывы и информации об опыте применения в других проектах.
Почему-то у меня нет проблем с однозначным выбором одного единственного из того «десятка». При этом я не тестировал их все.
Зачем? Как минимум глядя на результат можно отсеять несколько. Из оставшихся 2/3 отпадет, как не подходящая по формальным требованиям. Например, вам нужен асинхронный режим, а данный фреймворк его не реализует, или наоборот, вы не собираетесь писать в асинхронном стиле. Обычно чтобы отобрать 1-2 кандидата достаточно ознакомиться со списком возможностей на странице проекта. Также чья-то схема работы и способ организации кода, вам может понравиться гораздо больше. Можно еще немного погуглить, почитать отзывы и информации об опыте применения в других проектах.
Почему-то у меня нет проблем с однозначным выбором одного единственного из того «десятка». При этом я не тестировал их все.
Эта черная кошка а) гуглится на раз б) для руби есть каталоги расширений(rubygems.org, ruby-toolbox.com). не знаю, как в питоне.
Не вижу ничего сложного в том, чтобы запустить локально Paste и использовать Nginx как реверс-прокси — это несколько строк в конфиге.
Да что вы говорите! То-то у php до недавнего времени практически не существовало нормального полноценного метода деплоймента, кроме поднятия громоздкого апача. Про веб-разработку я уж молчу, не даром, для хоть какого-то упрощения понавыдумвали всяких комплектов аля denver. То-то каждый самоучитель по php начинается с многостраничного руководства по установке и настройке апача и всяких там php.ini, в то время, как все что нужно для начала работы, например, с той же django — это набрать: ./manage.py runserver — и запускается встроенный сервер отлично подходящий для удобной разработки и отладки.
для начала разработки на php нужно набрать что-то вроде «sudo apt-get install apache2 mod_php5 php5» (проверять зависимости и имена пакето лень, но, думаю, суть ясна). И вы допускаете классическую ошибку — сравниваете фреймворк с языком. Как правило (личные наблюдения — всегда) для отображения в браузере «Hello {{username}}» на хосте в равной стпенеи пригодном для локальной разработки и продакшена меньше всего шагов требует php, близко к нему (по описаниям) asp. Если не рассматривать CGI — там все равны (кроме какого-нибудь VBA).
Т.е. настраивать апач не нужно? Он сам отчего-то обнаружит где у вас проект лежит?
А вы под языком почему-то понимаете интерпретатор и сложный веб-сервер в придачу.
Как раз php требует шагов больше. Вы почему-то считаете апач как само-собой разумеющуюся данность, и будто настраивается он автоматически.
А вы под языком почему-то понимаете интерпретатор и сложный веб-сервер в придачу.
Как раз php требует шагов больше. Вы почему-то считаете апач как само-собой разумеющуюся данность, и будто настраивается он автоматически.
В простейшем случае не надо, просто проект надо поместить в /var/www/ :)
Веб-сервер (простой или сложный — не важно), по-моему, подразумевается для веб-приложения в 99,99% случаев, хотя бы чтобы статику отдавать.
Веб-сервер (простой или сложный — не важно), по-моему, подразумевается для веб-приложения в 99,99% случаев, хотя бы чтобы статику отдавать.
Ну если подразумевается, то почему вы тогда для python не включаете его в сравнение\установку? А почти каждый Python-фреймворк имеет свой встроенный для отладки. Я же не сравниваю python+django и php+apache. Я сравниваю python+django test server и php+apache. Ну хорошо, не нравится django, возьмем отличный и весьма быстрый сервер из ChrerryPy.
«В простейшем случае не надо, просто проект надо поместить в /var/www/ :)»
Ага, только закинуть проект туда можно исключительно из под рута, и да, это если только мейнтернеры вашего дистрибутива позаботились и за вас настроили апач именно так.
«В простейшем случае не надо, просто проект надо поместить в /var/www/ :)»
Ага, только закинуть проект туда можно исключительно из под рута, и да, это если только мейнтернеры вашего дистрибутива позаботились и за вас настроили апач именно так.
Как это не включаю? «nginx+phpfpm+приложение» vs. «nginx+....+python+приложение» (пускай питон стоит сразу после энжина, но… остаются, и в комплект ни питона, ни приложения, они не входят). Да и сравнение отладочного сервера и полноценного продакшн несколько некорректно.
А в чём проблема кинуть из под рута (судо)? А не настроили так, то как-то же всё равно настроили или это очень плохие мейнтейнеры :)
А в чём проблема кинуть из под рута (судо)? А не настроили так, то как-то же всё равно настроили или это очень плохие мейнтейнеры :)
Ну а если говорить о продакшн, то тут вообще даже сравнивать глупо. Сколько у нас там полноценных вариантов запуска у php? 3?
Только в этом бенчмарке приняло участие более 10-ка конфигураций:
nichol.as/benchmark-of-python-web-servers
Только в этом бенчмарке приняло участие более 10-ка конфигураций:
nichol.as/benchmark-of-python-web-servers
Малое число вариантов говорит об ущербности? И, если я правильно понял, то все 10 вариантов являются аналогами 3 php-шных (обычный сервер/демон, модуль веб-сервера, fasctcgi/wsgi-сервер) и даже не все HTTP 1.1 реализуют.
Да, малое число вариантов говорит об ущербности. Это не позволяет развернуть php приложение строго так, как того хочется, сэкономить память и\или выжать из него максимум производительности, а в некоторых случаях обеспечить дополнительную безопасность.
Аналогов php шных там от силы 3-4 и есть.
У php нет ни одного способа запуска в асинхронном режиме (3 из того набора его используют, и еще один умеет). У php нет вариантов запуска, как standalone http-сервер.
«даже не все HTTP 1.1 реализуют.»
Я вам открою страшную тайну. nginx при работе с http-бэкэндами, такими, как например Apache с mod_php, также не поддерживает HTTP 1.1
Аналогов php шных там от силы 3-4 и есть.
У php нет ни одного способа запуска в асинхронном режиме (3 из того набора его используют, и еще один умеет). У php нет вариантов запуска, как standalone http-сервер.
«даже не все HTTP 1.1 реализуют.»
Я вам открою страшную тайну. nginx при работе с http-бэкэндами, такими, как например Apache с mod_php, также не поддерживает HTTP 1.1
Видать у меня очень поверхностный взгляд, если я не вижу качественных различий. ткните, пожалуйста, пальцем, просветите.
Про асинхронный не понял — биндинга к каким функциям ОС нет у php (пускай и не всегда по дефолту), которые есть у python? Лайт процессов, да, нет, признаю, а всё остальное вроде есть.
У python есть вариант запуска как сервера? man python об этом ничего не говорит. Написать приложение, которое будет слушать сокеты и рулить тредами/процессами можно и на php, и на python, и на asm, и на C — последний кажется оптимален
Открою ещё более страшную тайну — роль Apache в большинстве случаев в такой связке не понятна
Про асинхронный не понял — биндинга к каким функциям ОС нет у php (пускай и не всегда по дефолту), которые есть у python? Лайт процессов, да, нет, признаю, а всё остальное вроде есть.
У python есть вариант запуска как сервера? man python об этом ничего не говорит. Написать приложение, которое будет слушать сокеты и рулить тредами/процессами можно и на php, и на python, и на asm, и на C — последний кажется оптимален
Открою ещё более страшную тайну — роль Apache в большинстве случаев в такой связке не понятна
Причем здесь биндинги к ОС? Могут ваши php приложения обрабатывать запросы асинхронно? Обрабатывать следующий запрос, пока предыдущий ожидает ответа от базы данных? А что делать, если нужно запрашивать несколько баз данных? Если делать это последовательно, то общее время ответа неприлично увеличивается. Ну хорошо, раз про биндинги, то как дела с epool у php?
«У python есть вариант запуска как сервера? man python об этом ничего не говорит.»
man php мне говорит, что php можно использовать только как CLI.
Многие из тех, что там поддерживают HTTP 1.1 предполагается, что можно запускать в продакшене прямо так, без какого-либо фронтэнда в виде апаче или nginx.
«Написать приложение, которое будет слушать сокеты и рулить тредами/процессами можно и на php»
Вы мне это самим предлагаете делать? Где готовые фреймворки? Где готовые решения? Зачем мне писать велосипеды? Большой у вас опыт в рулении тредами на php?
«роль Apache в большинстве случаев в такой связке не понятна»
А до появления php-fpm, Apache с mod_php был фактически самым нормальным способом запуска php.
«У python есть вариант запуска как сервера? man python об этом ничего не говорит.»
man php мне говорит, что php можно использовать только как CLI.
Многие из тех, что там поддерживают HTTP 1.1 предполагается, что можно запускать в продакшене прямо так, без какого-либо фронтэнда в виде апаче или nginx.
«Написать приложение, которое будет слушать сокеты и рулить тредами/процессами можно и на php»
Вы мне это самим предлагаете делать? Где готовые фреймворки? Где готовые решения? Зачем мне писать велосипеды? Большой у вас опыт в рулении тредами на php?
«роль Apache в большинстве случаев в такой связке не понятна»
А до появления php-fpm, Apache с mod_php был фактически самым нормальным способом запуска php.
Если мне ещё раз (тьфу-тьфу-тьфу) понадобится асинхронные запросы/ответы теперь я возьму Erlang :), хотя один готовый точно на хабре постоянно освещается. У меня опыт руления есть, правда не серверными, а многопоточными клиентами (асинхронными кстати) — на обычном хостинге я бы реализовать его не смог без костылей, только имея рут доступ получилось — пришлось осваивать администрирование VDS.
Согласен, mod_php был чуть ли не единственным, но теперь не так, поддержка даже 5.2 прекращена, давайте говорить о настоящем.
Согласен, mod_php был чуть ли не единственным, но теперь не так, поддержка даже 5.2 прекращена, давайте говорить о настоящем.
Ну здорово, появился еще php-fpm. Но по-прежнему, это не настоящий fastcgi, по-прежнему нет асинхронного режима, по-прежнему нет возможности запуска как единственный http веб-сервер.
Если пойти по «NoPHP way», то такие возможности есть — неоднократно описываемый на хабре phpDaemon например.
phpDaemon — асинхронный модульный демон-фреймворк, который берёт на себя обработку I/O (libevent) и другие низкоуровневые задачи, присущие сетевым демонам. С его помощью легко писать правильные и очень быстрые сетевые приложения.
Из коробки идут сервера FastCGI, HTTP, CGI, FlashPolicy, Telnet, WebSocket, клиенты mysql, memcached, mongodb и многое другое. Работать с сетью действительно просто. Программист средней руки может написать, к примеру, IRC-бота за считанные часы.
Там ни слова про epoll или kqueue. Есть тесты производительности?
Упс, стормозил, если оно использует libevent, то поддержка epoll/kqueue там есть. Однако вопрос про бенчмарки остается открытым… Все-таки одна из основных целей с которой зачастую выбирают асинхронный режим работы для веб-приложений, это выжать максимум производительности и сэкономить память.
Он использует libevent:
Специальных бенчмарков phpDaemon vs… не встречал, кажется. Видел люди тестировали symfony приложение как «обычное» fastcgi и как «true» (минимальные переделки потребовались) — выигрыш в 1,5-2 раза. Остальные пропорции можно прикинуть.
Currently, libevent supports /dev/poll, kqueue(2), event ports, select(2), poll(2) and epoll(4)
Специальных бенчмарков phpDaemon vs… не встречал, кажется. Видел люди тестировали symfony приложение как «обычное» fastcgi и как «true» (минимальные переделки потребовались) — выигрыш в 1,5-2 раза. Остальные пропорции можно прикинуть.
Глядя сюда думается 1,5-2 раза symfony не спасут.
Что-то мне подсказывает, что тест не очень корректный, например опкэшеров не было.
Хм… таки да. Вот тут точно с опкэшером:
static.alrond.com/results_2test.gif
Но правда нет symfony. Но можно условно прикинуть, если умножить результат symfony на предыдущем графике в 6 раз.
static.alrond.com/results_2test.gif
Но правда нет symfony. Но можно условно прикинуть, если умножить результат symfony на предыдущем графике в 6 раз.
По личному опыту сравнения symfony 1.4 и django 1.2 что-то в этих тестированиях не так…
Учитывая ваше ярое отрицание всего
«стороннего» я боюсь спросить, как вы джанго для сравнения запускали? Уж, не с помощью ли встроенного сервера?
«стороннего» я боюсь спросить, как вы джанго для сравнения запускали? Уж, не с помощью ли встроенного сервера?
Deploying Django with Apache and mod_wsgi is the recommended way to get Django into production.
Сойдет, хотя далеко не самый эффективный и производительный способ.
Но я то уж испугался, что вы django на встроенном сервере для разработки сравнивали с symphony на апаче.
Но я то уж испугался, что вы django на встроенном сервере для разработки сравнивали с symphony на апаче.
Для корректности сравнивал symfony под Apache+mod_php (хотя обычно предпочитаю nginx+php-fpm).
Сравнивал бы с рельсами — возможно так и было бы :) Но в python получше разбираюсь.
Сравнивал бы с рельсами — возможно так и было бы :) Но в python получше разбираюсь.
Вот ведь парадокс, а меня уж засевший где-то в подсознании англоязычный орфограф заставил написать слово «симфония» правильно. Оно пишется через ph. Я раньше даже и не замечал, что название фреймворка через f.
Сравнили бы nginx+php-fpm+symfony
c nginx+uwsgi+django
Сравнили бы nginx+php-fpm+symfony
c nginx+uwsgi+django
Сам долго не мог понять, что раздражает при чтении доков или, хотя бы, взгляда на структуру каталогов :) Авторы фреймворка вранцузы, может у них так пишется… А может сознательная ошибка.
В наоборотую сторону было бы понятно: phorum и т.п. Как бы намекает на язык реализации. А наоборот — даже если и не специально, то всё равно хорошо. :)
Kommander, Kompare, Lokalize, Kolf, Kubric, DigiKam, Karbon14, Kolourpaint, Okular, Kuickshow, Akregator, Konqueror, Konversation, Kaffeine, Kontact, Konsole, Krusader, Ark, Komposé и т.д. — вот где настоящие раздолье. =)
Это старый прикол. Отбирал людей для одной конторы. Читал резюме трёх парней из одной конторы. Они хлестались, что эксперты в SymPHony. Обратил на это внимание менеджера. На собеседовании эксперты, конечно, тоже облажались.
>С такой же интеграцией в html
Отучаемся использовать «интеграцию в хтмл» напрямую из языка, приучаемся к мвц. Да, как мини-шаблонизатор, когда под рукой ничего больше нету — это неплохо, но все же. И да, существуют микрофреймворки, достаточно производительные.
>поддержкой всеми хостингами
Как я уже написал выше, VDS стоит 150 рублей — дешевле многих php-хостингов.
>безплатными
Google App Engine и похожие штуки позволяют без вложений запускать, скажем, python скрипты, если уложитесь в ограничения.
Отучаемся использовать «интеграцию в хтмл» напрямую из языка, приучаемся к мвц. Да, как мини-шаблонизатор, когда под рукой ничего больше нету — это неплохо, но все же. И да, существуют микрофреймворки, достаточно производительные.
>поддержкой всеми хостингами
Как я уже написал выше, VDS стоит 150 рублей — дешевле многих php-хостингов.
>безплатными
Google App Engine и похожие штуки позволяют без вложений запускать, скажем, python скрипты, если уложитесь в ограничения.
«такой же интеграцией в html»
Да-да, а самое забавное начинается, когда начинают использовать всякие там smarty, а также в корень веб-сервера кладут index.php содержащий лишь include другого *.php за пределами видимости веб-сервера…
Парадокс php-разработчиков. =)
Да-да, а самое забавное начинается, когда начинают использовать всякие там smarty, а также в корень веб-сервера кладут index.php содержащий лишь include другого *.php за пределами видимости веб-сервера…
Парадокс php-разработчиков. =)
Между мудростью и интеллектом есть связь. Первое — это уточнение модели, второе — использование модели для предсказания.
Мне кажется, что во многом преувеличенно и притянуто.
> Но так, чтобы список параметров сократился, или, скажем, функция пропала — такого не было на моей памяти (это с 1998-го года)
ua2.php.net/manual/en/function.array-rand.php
Pick one or more random entries out of an array
5.2.10 The resulting array of keys is no longer shuffled.
Вывод: функция изменила свой принцип работы — у Вас плохая память. Результат функции очень важный параметр
Так вот, я б на Вашем месте не говорил ты что ничего не менялось. Я очень долго в свое время не мог понять как вдруг 100 строчек перестали работать правильно, когда там никто ничего не поменял, оказалось пхп изменил функцию.
ua2.php.net/manual/en/function.array-rand.php
Pick one or more random entries out of an array
5.2.10 The resulting array of keys is no longer shuffled.
Вывод: функция изменила свой принцип работы — у Вас плохая память. Результат функции очень важный параметр
Так вот, я б на Вашем месте не говорил ты что ничего не менялось. Я очень долго в свое время не мог понять как вдруг 100 строчек перестали работать правильно, когда там никто ничего не поменял, оказалось пхп изменил функцию.
Вот видите: я не смог промониторить вообще все функции PHP. И не обязан был. Более того, именно поэтому я их и не запоминаю. :)
Я тут попытался собрать некий старый проект написанный на C++. О ужас, он не собрался современными компиляторами! Пришлось курить какие важные изменения в стандарте произошли с тех пор ;)
Очень важно знать изменения в языке, я это понял именно когда наткнулся на эти изменения, потому как тоже не запоминал как и Вы. И поверьте, я потратил на поиск ошибки неоправданно много времени.
приведите, пожалуйста, пример кода, который это изменение поломало
Скажем так этой функцией эмулировали shuffle, кусок кода не играет особой роли, факт в том что ждали случайных ключей, а их не было.
а ну то есть вы полагались на незадокументированный побочный эффект, а виноват пхп?
Я полагал что функция с названием array_rand, которая возвращает случайный ключ вернет мне таки случайный ключ, как и описано в документациии к этой функции, причем официальной документации а не «незадокументированный побочный эффект»
Pick one or more random entries out of an array — оф. описание функции
Pick one or more random entries out of an array — оф. описание функции
возможно это прозвучит странно, но array_rand именно так и поступает — возвращает случайный ключ или массив ключей.
что она делать перестала в 5.2.10 — так это перемешивать результат, но документация этого и не обещала. так что пхп на этот раз не при чем.
что она делать перестала в 5.2.10 — так это перемешивать результат, но документация этого и не обещала. так что пхп на этот раз не при чем.
я скажу одно слово, lift. ну ладно, два, rails.
первое займет место рельс(для хипстеров или маргиналов).
второе — потеснит пхп(ресурсы дешевле, многие прогеры сейчас учат руби, более того, в руби принятно работать за перспективу/еду первое время).
тем не менее непонятно почему ерланг в стороне — «let it fail» разделенее данных по потоку и функционализм — это же прям для веба.
первое займет место рельс(для хипстеров или маргиналов).
второе — потеснит пхп(ресурсы дешевле, многие прогеры сейчас учат руби, более того, в руби принятно работать за перспективу/еду первое время).
тем не менее непонятно почему ерланг в стороне — «let it fail» разделенее данных по потоку и функционализм — это же прям для веба.
Erlang, имхо, больше для RIA или высоконагруженных решений, для очень серьёзного общения client-side с сервером — веб-сокеты, или огромная куча AJAX'а. Мне кажется, что писать на нём «сайты» экономически не выгодно.
На нем банально некому писать «сайты», потому что порог вхождения слишком высок, по сравнению с тем же php. И вообще, скорее всего вместо php просто прийдет другой язык, который может будет лучше, стройнее и элегантнее в плане архитектуры, но с таким же порогом для новичков — рынок требует наличия такого простого инструмента -> большой рынок труда -> низкие цены. Ниша всегда будет, а будет ли это php или что-то еще — не важно.
По-моему не такой уж высокий порог вхождения у Erlang… Просто «не модный» видимо.
Не соглашусь. По сравнению с php (а именно об этом я и говорил) — высокий.
Не соглашусь с несогласием, если говорить о языке. Отдельный вопрос интеграция в веб-сервер и шаблонизация. Там высокий однозначно, но не выше чем в питоне/руби.
Erlang очень простой, но разработчику необходимо избавиться от шаблонов в мышлении. В php всё синхронно и последовательно, в erlange — наоборот, куча независимых процессов, не имеющих общих данных, которые параллельно могут выполнять какие-то операции. Это требует определенной перестройки, особенно если в школе/вузе учили только императивному программированию.
Для шаблонизации можно использовать порт Django шаблонов code.google.com/p/erlydtl/ а веб-сервер обычно сам на Erlang (опционально — за Nginx-прокси).
Или (пропиарю, пользуясь случаем) CT++ модуль для Nginx: www.ohloh.net/p/ngx-ctpp/ =)
Найдя — таки документацию к самому CT++ ctpp.havoc.ru/ так и не понял как мне этому Nginx модулю данные передать для шаблонизации.
Простите, полноценная документация и примеры будут в январе. =)
Данные передаете просто в json формате, путь к файлу с шаблоном передаете в http заголовке «X-Template» или в уазываете настройках nginx.
Модуль парсит json полученный от бэкэнда (в нашем случае от erlang-а) и шаблонизирует с помощью шаблона переданного через заголовок или указаного в настройках nginx для данного локэйшна.
Данные передаете просто в json формате, путь к файлу с шаблоном передаете в http заголовке «X-Template» или в уазываете настройках nginx.
Модуль парсит json полученный от бэкэнда (в нашем случае от erlang-а) и шаблонизирует с помощью шаблона переданного через заголовок или указаного в настройках nginx для данного локэйшна.
Это нужно знать и это нужно принять (последнее, имхо, даже главнее при переходе с php). Лично я сделал жалкое подобие шаблонизатора и сервера на сокетах за nginx (частично реализовал fastcgi)
В етом контексте победит node.js :)
Node.js нагрузку держит хуже, и с многопоточностью там всё печальнее, т.к. web worker'ы нативно ещё не реализовали, а то, что есть — тупо запуск инстансов самой ноды, ошибки нужно аккуратно хэндлить, но памяти жрёт меньше, это факт. Erlang сравнительно просто поддаётся горизонтальному масштабированию. Впрочем, я ещё не написал ничего достаточного серьезного, чтобы говорить так уверено, лишь несколько тестов, но если что — поправляйте.
Где-то тут статья была классная про Ноду.
Вот habrahabr.ru/blogs/javascript/104171/#habracut но ето не она :)
Нашел: habrahabr.ru/blogs/webdev/108241/
Насчет erlang — ничего сказать не могу — не работал. И в этом мой аргумент. Мало кто знает erlang, а JS знает очень много разработчиков.
Т.е если представить себе миграцию php ->? то по простоте этой самой миграции JS на первом месте.
Вот habrahabr.ru/blogs/javascript/104171/#habracut но ето не она :)
Нашел: habrahabr.ru/blogs/webdev/108241/
Насчет erlang — ничего сказать не могу — не работал. И в этом мой аргумент. Мало кто знает erlang, а JS знает очень много разработчиков.
Т.е если представить себе миграцию php ->? то по простоте этой самой миграции JS на первом месте.
НЛО прилетело и опубликовало эту надпись здесь
Я ничо не сравниваю, автор комментари «помечатал» о том что в буущем ерланг, рейлс или чтотодругое заменит пхп.
Я помечтал что ето будет нода, и дал ссылку на статью почему я так считаю. (Предпосылки то есть)
А то что течет, так ето лечится.
0.3.2 версия же только. Дождемся же 1.0 и тогда подискутируем :)
Я помечтал что ето будет нода, и дал ссылку на статью почему я так считаю. (Предпосылки то есть)
А то что течет, так ето лечится.
0.3.2 версия же только. Дождемся же 1.0 и тогда подискутируем :)
У меня pet-project на node.js. Пытаюсь красиво обыграть возможность использования общего кода на стороне клиента, и на стороне сервера. Node.js ещё сыр местами, но соглашусь, в силу количества JS разработчиков, он скорее всего станет популярным.
Я тут внезапно обнаружил:
V8-based Javascript VM for Erlang — github.com/beamjs/beamjs
V8-based Javascript VM for Erlang — github.com/beamjs/beamjs
А как же Django? Я зря, что ли, начал его учить?
НЛО прилетело и опубликовало эту надпись здесь
Я маг.
Народилось уже целое поколение программистов, которые просто тупо кодят. Они не умеют считать биты, байты, такты, они не восхищаются логикой программ и красотой языка. Им указывают на over 9000 функций захламляющих глобальное пространство имен, на отстутсвие логики в их названиях и параметрах — они отвечают «вы что, в блокноте пишете? У нас есть мощная IDE, она нам подсказывает!», а на самом деле это просто, как минимум, уродливо. Они не понимают, что у каждого средства (и ЯП, в частности) есть определенное предназначение и задачи, в рамках которых оно наиболее удобно и эффективно. Такое предназначение есть и у php, именно ради него все переменные именуются с $, именно для этого у конструкций есть альтернативный синтаксис (с двоеточием), поэтому php-код записывается между псевдо-тегами <?php… ?>, поэтому самый распространненый и основной метод выполнения php-скриптов — путем помещения их в область видимость веб-сервера и прямым обращением к ним, и как раз потому до недавнего времени у php вообще не было вменяемого gc.
Ужас начинается там, когда все это начинают использовать порой не то, что не по назначению, а даже в противовес. С момента становления основных концепций php сложность динамических веб-сайтов серьезно увеличилась, и продолжает увеличиваться, сейчас уже даже не говорят динамических веб-сайт, пишут — веб-приложение! Но, почему-то, вместо выбора другого, более подходящего к современным реалиям, средства разработки, некоторые усилинно с бараньей упертостью продолжают идти напролом. Они пишут шаблонизаторы на шаблонизаторе, они выносят все за область видимости, оставляя только бессмысленную заглушку, пишут всякие страшные реврайты, отделяют php от html — и все это вместо того, чтобы просто взять другое, более красивое, логичное, подходящее средство (не буду ничего рекламировать, есть даже выбор, а на вкус и цвет...). Да-да, я подведу итог: php на сегодняшний день — это самый неудобный инструмент разработки веб-приложений.
Ужас начинается там, когда все это начинают использовать порой не то, что не по назначению, а даже в противовес. С момента становления основных концепций php сложность динамических веб-сайтов серьезно увеличилась, и продолжает увеличиваться, сейчас уже даже не говорят динамических веб-сайт, пишут — веб-приложение! Но, почему-то, вместо выбора другого, более подходящего к современным реалиям, средства разработки, некоторые усилинно с бараньей упертостью продолжают идти напролом. Они пишут шаблонизаторы на шаблонизаторе, они выносят все за область видимости, оставляя только бессмысленную заглушку, пишут всякие страшные реврайты, отделяют php от html — и все это вместо того, чтобы просто взять другое, более красивое, логичное, подходящее средство (не буду ничего рекламировать, есть даже выбор, а на вкус и цвет...). Да-да, я подведу итог: php на сегодняшний день — это самый неудобный инструмент разработки веб-приложений.
О, наши собираются.
… а я дартаньян
Я когда-то считал биты и байты (сначала был ограничен 105-ю байтами только ОЗУ, потом 32 КБ ОЗУ и 2 КБ ПЗУ — были сменные микросхемы К573РФ2 если склероз не изменяет прошиваемые советскими тумблерами и резисторами на весу — фольгелированныйгетинакс дефицит, денег на взятки продавцам магазина «Юный Техник» не было). Но в начале века я реально обрадовался что можно перейти от побайтового выделения памяти и вывода в CGI через puts(...) и printf(...) к тупому встраиванию echo $i в html код, тем более что тогда «out of memory» можно было увидеть только при сильном желании.
С момента увеличения сложности динамических веб-сайтов php «немного» подрос и превратился из шаблонизатора с редства обработки форм в ЯП общего назначения. Может есть и более удобные для веб-программирования ЯП общего назначения, а может и болле удобные Я веб-П, но...:
— программист часто ограничен в выборе ЯП, по крайней мере в некоторых сегментах рынка (выполнение php приложений всреднем, имхо, дешевле (в расчёте на проект) альтернатив в плане стоимости хостинга и/или администрирования, равно как и программирования)
— объективно (по моему субъективному мнению :) ) спрос и предложение php веб-программистов превышает спрос и предложение на веб-программистов на всех других ЯП вместе взятых, хорошо если не на порядки
С момента увеличения сложности динамических веб-сайтов php «немного» подрос и превратился из шаблонизатора с редства обработки форм в ЯП общего назначения. Может есть и более удобные для веб-программирования ЯП общего назначения, а может и болле удобные Я веб-П, но...:
— программист часто ограничен в выборе ЯП, по крайней мере в некоторых сегментах рынка (выполнение php приложений всреднем, имхо, дешевле (в расчёте на проект) альтернатив в плане стоимости хостинга и/или администрирования, равно как и программирования)
— объективно (по моему субъективному мнению :) ) спрос и предложение php веб-программистов превышает спрос и предложение на веб-программистов на всех других ЯП вместе взятых, хорошо если не на порядки
«к тупому встраиванию echo $i в html код»
Да я ж только за. Я сам в начале века стал активно изучать и пользоваться php. Но ведь что твориться, php уже не встраивают в код, понаписали больших огромных фреймворков, некоторые даже используют smarty. Те концепции, которые изначально были в php заложены, чем он и был хорош, от них отходят, но продолжают его использовать.
«php «немного» подрос и превратился из шаблонизатора с редства обработки форм»
Концепции изменились? Нет, по прежнему те же $, смысла в которых без встраивания в строчки нет. Файлы php теперь сосятосят исключительно из php-кода, который, тем не менее, попрежнему надо заключать в <?php ?>. Попрежнему те же over 9000 функций с кривыми названиями в глобальном неймспейсе. Все это просто некрасиво и неудобно, нелогично.
«спрос и предложение php веб-программистов превышает спрос и предложение на веб-программистов на всех других ЯП вместе взятых, хорошо если не на порядки»
Как вы точно заметили «спрос и предложение». Это приемущество? Одним php-шником меньше, одним больше — никто и не заметит.
Но на эту тему предлагаю даже не дискутировать. Меня, например, ни разу не интересует, что думает заказчик\работодатель. Он часто вообще в программировании ничего не понимает. Для меня главное чтобы работа приносила удовольствие, все-таки я отдаю ей значительную часть своей жизни.
Да я ж только за. Я сам в начале века стал активно изучать и пользоваться php. Но ведь что твориться, php уже не встраивают в код, понаписали больших огромных фреймворков, некоторые даже используют smarty. Те концепции, которые изначально были в php заложены, чем он и был хорош, от них отходят, но продолжают его использовать.
«php «немного» подрос и превратился из шаблонизатора с редства обработки форм»
Концепции изменились? Нет, по прежнему те же $, смысла в которых без встраивания в строчки нет. Файлы php теперь сосятосят исключительно из php-кода, который, тем не менее, попрежнему надо заключать в <?php ?>. Попрежнему те же over 9000 функций с кривыми названиями в глобальном неймспейсе. Все это просто некрасиво и неудобно, нелогично.
«спрос и предложение php веб-программистов превышает спрос и предложение на веб-программистов на всех других ЯП вместе взятых, хорошо если не на порядки»
Как вы точно заметили «спрос и предложение». Это приемущество? Одним php-шником меньше, одним больше — никто и не заметит.
Но на эту тему предлагаю даже не дискутировать. Меня, например, ни разу не интересует, что думает заказчик\работодатель. Он часто вообще в программировании ничего не понимает. Для меня главное чтобы работа приносила удовольствие, все-таки я отдаю ей значительную часть своей жизни.
>Те концепции, которые изначально были в php заложены, чем он и был хорош, от них отходят, но продолжают его использовать.
От них не отходит, он их расширяет «в ногу со временем», исключает необходимость использования сторонних средств.
>Концепции изменились? Нет
Нет и да, расширились, но преимущества никуда не делись (тех, кто использует смарти или ещё что кроме XSLT не понимаю, если не ставится условие использование пользовательских шаблонов). Одни файлы состоят исключительно из php кода, другие из html с вкраплением php — как-то нужно соблюдать единнобразность, а по традициям выделяютс вставки php. Вот серьезно, не понимаю кртического значения over 9000 функций в глобальном неймспейсе (особенно учитывая возможность «прятать» свои функции в классы и «локальные» неймспейсы.
>Как вы точно заметили «спрос и предложение». Это приемущество? Одним php-шником меньше, одним больше — никто и не заметит.
Имхо, да, т. к. и одним заказчиком больше, другим меньше, никто и не заметит. :) А если серьезно, то много факторов…
От них не отходит, он их расширяет «в ногу со временем», исключает необходимость использования сторонних средств.
>Концепции изменились? Нет
Нет и да, расширились, но преимущества никуда не делись (тех, кто использует смарти или ещё что кроме XSLT не понимаю, если не ставится условие использование пользовательских шаблонов). Одни файлы состоят исключительно из php кода, другие из html с вкраплением php — как-то нужно соблюдать единнобразность, а по традициям выделяютс вставки php. Вот серьезно, не понимаю кртического значения over 9000 функций в глобальном неймспейсе (особенно учитывая возможность «прятать» свои функции в классы и «локальные» неймспейсы.
>Как вы точно заметили «спрос и предложение». Это приемущество? Одним php-шником меньше, одним больше — никто и не заметит.
Имхо, да, т. к. и одним заказчиком больше, другим меньше, никто и не заметит. :) А если серьезно, то много факторов…
НЛО прилетело и опубликовало эту надпись здесь
не пытаться обобщать накопленные знания
очень сильно! понимаю как человек, жравший пых 8 лет прежде чем взяться за питон :)
И ведь мысль-то, каки всё гениальное — на поверхности, но никто не объяснил бы лучше!
Позвольте и мне своих 2 копейки вставить в это обсуждение.
> Erlang лучше
Да, я посмотрел синтаксис, это же ад какой-то. Ну-ну, я посмотрю, ка вы будете писать всякие модельки и контроллеры на этом языке. Почему-то у меня ощущение, что язык с фишками типа паттерн-матчинга быстро работать по определению не может.
> Пример с вызывающимися не-вовремя конструкторами/деструкторами.
Деструкторы не нужны. Они нужны в языках типа C++, где бедный программист должен руками освобождать память (ага, ссылки то считать язык не умеет), а в PHP память освобождается сама, плюс есть register_shutdown_function для каких-то финальных операций. Я их не использую, а, там, где они используются, очень трудно отлаживать код (был случай, долго пришлось искать что не так и почему деструктор вызывался 2 раза).
Мне и конструкторы не нравятся, уродливо, лучше уж статические функции с нормальными именами для создания инстанса.
Преимущества языка: большое число встроенных функций (вплоть до всяких json_encode() и file_get_content(), есть на все случаи жизни), которые позволяют написать какой-нибудь скрипт на 10 строчек. Конечно, в языках типа Руби или Питона тоже есть стандартная библиотека с такими функциями, но там они написаны на самом языке, что очень медленно, памяте-неэффективно и у меня лишь вызывает отвращение и нежелание использовать, а в PHP все эти сотни стандартных функций написаны на Си, не ленились, в отличие от Рубиводов, разработчики. Плюс есть тот же curl_*, который позволяет скачивать файлы и отправлять http-запросы в несколько действий (а в каком-нибудь Руби максимум уродливая громоздкая библиотека на самом же Руби и написанная). Или функции типа array_diff_key(), которые в PHP нативные, а в других языках делаются уродливым костылем через цикл.
Плюс — автоматическое управление памятью, не надо вручную удалять объекты, а функцию free() можно забыть как страшный кошмар. Плюс — можно подставлять переменные в строки, типа «Hello {$world->getWord()}»
Плюс — относительно неплохая производительность среди интерпретируемых языков при умелом использовании. Плюс — внутрь встроены хорошие массивы-хеш-таблицы.
Минусы — уродливый синтаксис (не Руби ;-( ), никакого синтаксического сахара, нет нормальных замыканий (хны-хны, приходится лишние классы городить чтобы их имитировать), нет mixins, уродливо реализованы статические методы в ООП (static:: и new static() только в 5.3 появился, как я без них страдаю), дурацкие названия стандартных функций, неэффективность при работе с переменными/методами (в рантайме метод или переменная ищется в хеш-таблице, это слишком долго). Нет нормального fastCGI-цикла (написанного на Си, а не костылей, работающих с сокетами из PHP), нет event loop, чтобы все работало асинхронно, библитотеки типа PDO/curl все синхронные. Namespaces делали инвалиды.
А, еще в больших проектах напрягют длинные имена констант, типа App_Dao_Books_Main::BOOK_TYPE_UNREAD, неужели нельзя это проще как-то сделать?
Но у других языков минусов еще больше: Си — невозможно на нем писать, слишком много рутины, слишком низкоуровневый, нет ни динамических массивов, ни хеш-таблиц (костыли типа Boost не в счет), ни подсчета ссылок в самом языке. Перл — нечитаемый, не годится для веб-проектов и красивых архитектур с модельками и вьюхами, Питон/Руби — вроде как тормозят. Ява — слишком многословный, руки отвалятся на нем что-то написать, плюс опять же, нет встроенных списков/хешей/массивов. Яваскрипт — вроде не очень быстрый из-за своей динамичности, плюс мало встроенных функций например по работе с массивами или строками, нет всяких курлов и PDO, слаборазвитые регекспы.
Уф. И на чем еще спрашивается писать? Если важна не какая-то абстрактная красота кода, а важно совместить хороший результат и простой синтаксис, PHP тут лучший из худших. Я бы сам подумал о переходе на Питон/Руби, если бы они хотя бы 100 запросов всекунду на типичном веб-приложении с контроллерами и модельками держали и если бы там был удобный шаблонизатор и куча стандартных библиотек, написанных на быстром языке.
И рядом с недостатками других языков, нелогичные наименования/порядок аргументов функций — ерунда, не стоящая внимания мелочь, тем более что пару десятков часто используемых ф-й я знаю наизусть, и всегда под рукой php.net/manual (кстати, мануал в PHP самый удобный и понятный, и хорошо организованный, из всех что я вообще видел, лучше даже чем msdn какой-нибудь).
А, еще недостаток: поскольку программистов на PHP как мух, их никто за людей не считает, и платят копейки, и обращаются как с рабами, вот тут да, думаешь может ну ее производительность и качественный результат.
> Erlang лучше
Да, я посмотрел синтаксис, это же ад какой-то. Ну-ну, я посмотрю, ка вы будете писать всякие модельки и контроллеры на этом языке. Почему-то у меня ощущение, что язык с фишками типа паттерн-матчинга быстро работать по определению не может.
> Пример с вызывающимися не-вовремя конструкторами/деструкторами.
Деструкторы не нужны. Они нужны в языках типа C++, где бедный программист должен руками освобождать память (ага, ссылки то считать язык не умеет), а в PHP память освобождается сама, плюс есть register_shutdown_function для каких-то финальных операций. Я их не использую, а, там, где они используются, очень трудно отлаживать код (был случай, долго пришлось искать что не так и почему деструктор вызывался 2 раза).
Мне и конструкторы не нравятся, уродливо, лучше уж статические функции с нормальными именами для создания инстанса.
Преимущества языка: большое число встроенных функций (вплоть до всяких json_encode() и file_get_content(), есть на все случаи жизни), которые позволяют написать какой-нибудь скрипт на 10 строчек. Конечно, в языках типа Руби или Питона тоже есть стандартная библиотека с такими функциями, но там они написаны на самом языке, что очень медленно, памяте-неэффективно и у меня лишь вызывает отвращение и нежелание использовать, а в PHP все эти сотни стандартных функций написаны на Си, не ленились, в отличие от Рубиводов, разработчики. Плюс есть тот же curl_*, который позволяет скачивать файлы и отправлять http-запросы в несколько действий (а в каком-нибудь Руби максимум уродливая громоздкая библиотека на самом же Руби и написанная). Или функции типа array_diff_key(), которые в PHP нативные, а в других языках делаются уродливым костылем через цикл.
Плюс — автоматическое управление памятью, не надо вручную удалять объекты, а функцию free() можно забыть как страшный кошмар. Плюс — можно подставлять переменные в строки, типа «Hello {$world->getWord()}»
Плюс — относительно неплохая производительность среди интерпретируемых языков при умелом использовании. Плюс — внутрь встроены хорошие массивы-хеш-таблицы.
Минусы — уродливый синтаксис (не Руби ;-( ), никакого синтаксического сахара, нет нормальных замыканий (хны-хны, приходится лишние классы городить чтобы их имитировать), нет mixins, уродливо реализованы статические методы в ООП (static:: и new static() только в 5.3 появился, как я без них страдаю), дурацкие названия стандартных функций, неэффективность при работе с переменными/методами (в рантайме метод или переменная ищется в хеш-таблице, это слишком долго). Нет нормального fastCGI-цикла (написанного на Си, а не костылей, работающих с сокетами из PHP), нет event loop, чтобы все работало асинхронно, библитотеки типа PDO/curl все синхронные. Namespaces делали инвалиды.
А, еще в больших проектах напрягют длинные имена констант, типа App_Dao_Books_Main::BOOK_TYPE_UNREAD, неужели нельзя это проще как-то сделать?
Но у других языков минусов еще больше: Си — невозможно на нем писать, слишком много рутины, слишком низкоуровневый, нет ни динамических массивов, ни хеш-таблиц (костыли типа Boost не в счет), ни подсчета ссылок в самом языке. Перл — нечитаемый, не годится для веб-проектов и красивых архитектур с модельками и вьюхами, Питон/Руби — вроде как тормозят. Ява — слишком многословный, руки отвалятся на нем что-то написать, плюс опять же, нет встроенных списков/хешей/массивов. Яваскрипт — вроде не очень быстрый из-за своей динамичности, плюс мало встроенных функций например по работе с массивами или строками, нет всяких курлов и PDO, слаборазвитые регекспы.
Уф. И на чем еще спрашивается писать? Если важна не какая-то абстрактная красота кода, а важно совместить хороший результат и простой синтаксис, PHP тут лучший из худших. Я бы сам подумал о переходе на Питон/Руби, если бы они хотя бы 100 запросов всекунду на типичном веб-приложении с контроллерами и модельками держали и если бы там был удобный шаблонизатор и куча стандартных библиотек, написанных на быстром языке.
И рядом с недостатками других языков, нелогичные наименования/порядок аргументов функций — ерунда, не стоящая внимания мелочь, тем более что пару десятков часто используемых ф-й я знаю наизусть, и всегда под рукой php.net/manual (кстати, мануал в PHP самый удобный и понятный, и хорошо организованный, из всех что я вообще видел, лучше даже чем msdn какой-нибудь).
А, еще недостаток: поскольку программистов на PHP как мух, их никто за людей не считает, и платят копейки, и обращаются как с рабами, вот тут да, думаешь может ну ее производительность и качественный результат.
Если судить по
shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=all&lang2=php
то PHP — самый медленный, при этом JavaScript V8 как минимум вдвое быстрее. Субъективно, C# (но ASP.NET — срань господня, а реализация WCF порой сильно удивляет, если писать, то хотя бы на ASP.NET MVC) и Java (на ней я, к сожалению, писал не очень много) — самые быстрые, как по производительности, так и в разработке, и адекватные для большинства задач.
И с каких пор в Java нет встроенных списков/хешей/массивов? И в чём заключается многословие?
shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=all&lang2=php
то PHP — самый медленный, при этом JavaScript V8 как минимум вдвое быстрее. Субъективно, C# (но ASP.NET — срань господня, а реализация WCF порой сильно удивляет, если писать, то хотя бы на ASP.NET MVC) и Java (на ней я, к сожалению, писал не очень много) — самые быстрые, как по производительности, так и в разработке, и адекватные для большинства задач.
И с каких пор в Java нет встроенных списков/хешей/массивов? И в чём заключается многословие?
Там тесты странные какие-то:
> binary-trees benchmark: Allocate and deallocate many many binary trees
> generate DNA sequences, by copying from a given sequence
Это же маразм, делать бинарные деревья на PHP. Их надо делать на языках вроде Си, ибо в PHP вообще плохо работают программы с циклами, обходами и прочей ерундой, программа должна быть прямолинейной и однозначной :)
Там тесты хитрые, они все используют сложные циклы/ветвления и хорошо пойдут только на компилируемых статических языках (потому, что цикл в Си — несколько ассемблерных команд, а на высокоуровневых языках — подключется тяжелый интерпретатор байт-кода и CPU расходуется не по назначению), я плохо представляю что веб-фреймворк будет при каждом запросе генерировать последовательности ДНК и вставлять их в бинарные деревья :)
Там надо проще, выбрать что-нибудь из БД, или из кеша, отшаблонизировать или отдать в виде JSON, тогда разница по скорости будет не такая радикальная, а по удобству и простоте написания PHP вообще всех обскачет. Высокоуровневые языки сами не обходят массивы и деревья, они просто вызывают для этого Си-шные функции.
Для меня, по крайней мере, PHP — язык для веба, а не замена C/C++. И тесты на этом сайте имеют тут нулевую ценность.
> И с каких пор в Java нет встроенных списков/хешей/массивов? И в чём заключается многословие?
> Map map = new HashMap()
Это не встроенная в язык хеш-таблица, а отдельный класс со всеми вытекающими недостатками.
Многословие — в том, что у каждой переменно тип указывать и на каждый чих создавать по классу. надо писать import. Нет замыканий — как писать асинхронные приложения? Писать для каждого коллбека по отдельному классу? Как вообще например обрабатывать данные с 200 сокетов? Через уродливые тормозящие треды, требующие дорогих синхронизаций на каждый чих?
Еще Ява долго запускается, там есть уродливый rt.jar весом в десятки мегабайт, классы из которого адски медленно подключаются, и стандартная библиотека вроде написана не на Си и на самой Яве (фууу). Плохо организована работа с памятью — она тупо отжирает память до установленного фиксированного предела (даже если ей столько не надо, ей просто лень очищать), а потом периодически начинается медленный GC. Как вы понимаете, выставить заранее оптимальный предел памяти для программы, используемой в различных окружениях, на разных конфигурациях железа, нельзя, значит память почти всегда используется неэффективно. Это не решение проблемы управления памятью, а уход от нее.
Хотя при грамотном использовании Ява, конечно обгонит PHP, но всякие модельки/Dao там тяжелее, дольше пишутся и уродливее, чем в PHP, где для этого достаточно написать пару классов, работающих например с PDO, а в Яве — надо тащить какую-нибудь Hibernate весом в мегабайты.
А еще у Явы неизлечимая болезнь в виде необходимости поддерживать совместимость со старыми версиями.
> binary-trees benchmark: Allocate and deallocate many many binary trees
> generate DNA sequences, by copying from a given sequence
Это же маразм, делать бинарные деревья на PHP. Их надо делать на языках вроде Си, ибо в PHP вообще плохо работают программы с циклами, обходами и прочей ерундой, программа должна быть прямолинейной и однозначной :)
Там тесты хитрые, они все используют сложные циклы/ветвления и хорошо пойдут только на компилируемых статических языках (потому, что цикл в Си — несколько ассемблерных команд, а на высокоуровневых языках — подключется тяжелый интерпретатор байт-кода и CPU расходуется не по назначению), я плохо представляю что веб-фреймворк будет при каждом запросе генерировать последовательности ДНК и вставлять их в бинарные деревья :)
Там надо проще, выбрать что-нибудь из БД, или из кеша, отшаблонизировать или отдать в виде JSON, тогда разница по скорости будет не такая радикальная, а по удобству и простоте написания PHP вообще всех обскачет. Высокоуровневые языки сами не обходят массивы и деревья, они просто вызывают для этого Си-шные функции.
Для меня, по крайней мере, PHP — язык для веба, а не замена C/C++. И тесты на этом сайте имеют тут нулевую ценность.
> И с каких пор в Java нет встроенных списков/хешей/массивов? И в чём заключается многословие?
> Map map = new HashMap()
Это не встроенная в язык хеш-таблица, а отдельный класс со всеми вытекающими недостатками.
Многословие — в том, что у каждой переменно тип указывать и на каждый чих создавать по классу. надо писать import. Нет замыканий — как писать асинхронные приложения? Писать для каждого коллбека по отдельному классу? Как вообще например обрабатывать данные с 200 сокетов? Через уродливые тормозящие треды, требующие дорогих синхронизаций на каждый чих?
Еще Ява долго запускается, там есть уродливый rt.jar весом в десятки мегабайт, классы из которого адски медленно подключаются, и стандартная библиотека вроде написана не на Си и на самой Яве (фууу). Плохо организована работа с памятью — она тупо отжирает память до установленного фиксированного предела (даже если ей столько не надо, ей просто лень очищать), а потом периодически начинается медленный GC. Как вы понимаете, выставить заранее оптимальный предел памяти для программы, используемой в различных окружениях, на разных конфигурациях железа, нельзя, значит память почти всегда используется неэффективно. Это не решение проблемы управления памятью, а уход от нее.
Хотя при грамотном использовании Ява, конечно обгонит PHP, но всякие модельки/Dao там тяжелее, дольше пишутся и уродливее, чем в PHP, где для этого достаточно написать пару классов, работающих например с PDO, а в Яве — надо тащить какую-нибудь Hibernate весом в мегабайты.
А еще у Явы неизлечимая болезнь в виде необходимости поддерживать совместимость со старыми версиями.
> Там тесты хитрые, они все используют сложные циклы/ветвления и хорошо пойдут только на компилируемых статических языках (потому, что цикл в Си — несколько ассемблерных команд, а на высокоуровневых языках — подключется тяжелый интерпретатор байт-кода и CPU расходуется не по назначению), я плохо представляю что веб-фреймворк будет при каждом запросе генерировать последовательности ДНК и вставлять их в бинарные деревья :)
Да, но при этом множество динамических языков(а иногда даже более динамических, так как в JS можно творить жуткую магию) справляется с этими тестами лучше, чем PHP, а веб-приложение иногда может и 3д рендеринг производить через OpenGL, и обрабатывать огромную кипу данных, полученных из самых разнообразных мест — всё зависит от задачи. Да, если нужно собрать обёртку для базы данных, то PHP — отличный вариант, но веб — это нечто большее, чем просто обёртка над базой данных. Например, есть отличная библиотека для стриминга видео на Erlang'е. Писать что-то подобное на PHP — это самоубийство.
Да, но при этом множество динамических языков(а иногда даже более динамических, так как в JS можно творить жуткую магию) справляется с этими тестами лучше, чем PHP, а веб-приложение иногда может и 3д рендеринг производить через OpenGL, и обрабатывать огромную кипу данных, полученных из самых разнообразных мест — всё зависит от задачи. Да, если нужно собрать обёртку для базы данных, то PHP — отличный вариант, но веб — это нечто большее, чем просто обёртка над базой данных. Например, есть отличная библиотека для стриминга видео на Erlang'е. Писать что-то подобное на PHP — это самоубийство.
>Это не встроенная в язык хеш-таблица, а отдельный класс со всеми вытекающими недостатками.
Да, давайте все встраивать в язык. Нужны сокеты — сделаем языковые конструкции для сокетов. Нужно работать с бд — встраиваем конструкции дерганья бд. Замечательная штука получается. Как раз в стиле PHP =)
> Нет замыканий — как писать асинхронные приложения? Писать для каждого коллбека по отдельному классу?
Анонимные классы
> Как вообще например обрабатывать данные с 200 сокетов? Через уродливые тормозящие треды, требующие дорогих синхронизаций на каждый чих?
Осиливаем Non-blocking input-output. Да и в том же php разве не по треду на коннект выделяется?
>Плохо организована работа с памятью — она тупо отжирает память до установленного фиксированного предела (даже если ей столько не надо, ей просто лень очищать), а потом периодически начинается медленный GC
А зачем мне свободная память, когда у меня есть приложение, которое ее может использовать? Любоваться, на " какой классный у меня сервак — половина памяти неиспользуется"?
>Еще Ява долго запускается, там есть уродливый rt.jar весом в десятки мегабайт, классы из которого адски медленно подключаются, и стандартная библиотека вроде написана не на Си и на самой Яве (фууу)
Зато запускается только один раз. + не забываем про JIT.
> всякие модельки/Dao там тяжелее, дольше пишутся и уродливее, чем в PHP, где для этого достаточно написать пару классов, работающих например с PDO, а в Яве — надо тащить какую-нибудь Hibernate весом в мегабайты.
Кого волнует сколько мегабайт занимает приложение? PDO/Hibernate — разного уровня библиотеки -> сравнение некорретно.
В общем автор этого комментария то ли java видел очень издалека, то ли очень толстый троль.
Да, давайте все встраивать в язык. Нужны сокеты — сделаем языковые конструкции для сокетов. Нужно работать с бд — встраиваем конструкции дерганья бд. Замечательная штука получается. Как раз в стиле PHP =)
> Нет замыканий — как писать асинхронные приложения? Писать для каждого коллбека по отдельному классу?
Анонимные классы
> Как вообще например обрабатывать данные с 200 сокетов? Через уродливые тормозящие треды, требующие дорогих синхронизаций на каждый чих?
Осиливаем Non-blocking input-output. Да и в том же php разве не по треду на коннект выделяется?
>Плохо организована работа с памятью — она тупо отжирает память до установленного фиксированного предела (даже если ей столько не надо, ей просто лень очищать), а потом периодически начинается медленный GC
А зачем мне свободная память, когда у меня есть приложение, которое ее может использовать? Любоваться, на " какой классный у меня сервак — половина памяти неиспользуется"?
>Еще Ява долго запускается, там есть уродливый rt.jar весом в десятки мегабайт, классы из которого адски медленно подключаются, и стандартная библиотека вроде написана не на Си и на самой Яве (фууу)
Зато запускается только один раз. + не забываем про JIT.
> всякие модельки/Dao там тяжелее, дольше пишутся и уродливее, чем в PHP, где для этого достаточно написать пару классов, работающих например с PDO, а в Яве — надо тащить какую-нибудь Hibernate весом в мегабайты.
Кого волнует сколько мегабайт занимает приложение? PDO/Hibernate — разного уровня библиотеки -> сравнение некорретно.
В общем автор этого комментария то ли java видел очень издалека, то ли очень толстый троль.
Хэш-таблицы, имхо, всё же стоит встроить в язык в любом случае
А я думаю, что язык должен быть очень компактным и содержать минимальное число конструкций. Вот, например, в той же java есть имхо совершенно излишние специализированные конструкции для работы с массивами(фигурные/квадратные скобки), хотя массив это всего лишь разновидность коллекции. И зачем они нужны? Логичнее было бы работать с массивами как с объектами коллекци через методы установки/получения элемента по индексу.
Тогда, имхо, синтаксис языка должен быть расширяемым. Например, как в FORTH — каждому символу можно назначить свою последовательность команд. А доступ к элементу массива по someArray.getByIndex(someIndex) это, по-моему, ужас по сравнению с someArray[someIndex]. Пускай не ужас, но второй вариант явно «слаще»
"> Erlang лучше
Да, я посмотрел синтаксис, это же ад какой-то.… Почему-то у меня ощущение, что язык с фишками типа? паттерн-матчинга быстро работать по определению не может."
Да-да, скажите это, например, разработчикам ejabberd, couchdb, SimpleDB, SimpleDB и riak, а также и всем тем большим и маленьким, кто это использует, и вполне сознательно. Вы мягко говоря не в теме. Синтаксис, кстати, очень простой. Не понятно, что там можно было углядеть сложного.
«Деструкторы не нужны»
Да-да, освобождать ресурсы не нужно.
«Они нужны в языках типа C++, где бедный программист должен руками освобождать память»
Ага, ресурсов кроме памяти не бывает.
«Преимущества языка: большое число встроенных функций (вплоть до всяких json_encode() и file_get_content(), есть на все случаи жизни), которые позволяют написать какой-нибудь скрипт на 10 строчек.»
Ага. Поэтому, что скрипт на 10 строчек, что на 10 000, а грузятся все равно все модули собранные и указанные в php.ini, отъедая ресурсы, хоть и 95% в вашем 10-строчным скрипте их задействовано и не будет.
«Питона тоже есть стандартная библиотека с такими функциями, но там они написаны на самом языке, что очень медленно, памяте-неэффективно»
WTF?
«а в других языках делаются уродливым костылем через цикл»
WTF?
«Плюс — автоматическое управление памятью, не надо вручную удалять объекты, а функцию free() можно забыть как страшный кошмар.»
Да-да, в этом случая вся память просто идет в мусорку, а потом вся инициализация по-новой, и так каждый запрос.
«Нет нормального fastCGI-цикла (написанного на Си, а не костылей, работающих с сокетами из PHP), нет event loop, чтобы все работало асинхронно, библитотеки типа PDO/curl все синхронные»
Отгадайте с трех раз почему. С таким-то обращением с памятью…
«Си — невозможно на нем писать… Перл — нечитаемый… Питон/Руби — вроде как тормозят… Яваскрипт — вроде не очень быстрый из-за своей динамичности»
А мужики-то не знают! Прямо собрание бреда. Каждая фраза или заблуждение, или совсем заблуждение.
Большей концентрации бреда, чем у вас в одном посте, наверное собрать было трудно.
Да, я посмотрел синтаксис, это же ад какой-то.… Почему-то у меня ощущение, что язык с фишками типа? паттерн-матчинга быстро работать по определению не может."
Да-да, скажите это, например, разработчикам ejabberd, couchdb, SimpleDB, SimpleDB и riak, а также и всем тем большим и маленьким, кто это использует, и вполне сознательно. Вы мягко говоря не в теме. Синтаксис, кстати, очень простой. Не понятно, что там можно было углядеть сложного.
«Деструкторы не нужны»
Да-да, освобождать ресурсы не нужно.
«Они нужны в языках типа C++, где бедный программист должен руками освобождать память»
Ага, ресурсов кроме памяти не бывает.
«Преимущества языка: большое число встроенных функций (вплоть до всяких json_encode() и file_get_content(), есть на все случаи жизни), которые позволяют написать какой-нибудь скрипт на 10 строчек.»
Ага. Поэтому, что скрипт на 10 строчек, что на 10 000, а грузятся все равно все модули собранные и указанные в php.ini, отъедая ресурсы, хоть и 95% в вашем 10-строчным скрипте их задействовано и не будет.
«Питона тоже есть стандартная библиотека с такими функциями, но там они написаны на самом языке, что очень медленно, памяте-неэффективно»
WTF?
«а в других языках делаются уродливым костылем через цикл»
WTF?
«Плюс — автоматическое управление памятью, не надо вручную удалять объекты, а функцию free() можно забыть как страшный кошмар.»
Да-да, в этом случая вся память просто идет в мусорку, а потом вся инициализация по-новой, и так каждый запрос.
«Нет нормального fastCGI-цикла (написанного на Си, а не костылей, работающих с сокетами из PHP), нет event loop, чтобы все работало асинхронно, библитотеки типа PDO/curl все синхронные»
Отгадайте с трех раз почему. С таким-то обращением с памятью…
«Си — невозможно на нем писать… Перл — нечитаемый… Питон/Руби — вроде как тормозят… Яваскрипт — вроде не очень быстрый из-за своей динамичности»
А мужики-то не знают! Прямо собрание бреда. Каждая фраза или заблуждение, или совсем заблуждение.
Большей концентрации бреда, чем у вас в одном посте, наверное собрать было трудно.
Еще, еще в таком же стиле пожалуйста!
Так весело мне не было… давно не было :))
Так весело мне не было… давно не было :))
Кстати, более-менее вменяемый бенчмарк веб серверов на go, erlang'e, java и c:
timyang.net/programming/c-erlang-java-performance/
timyang.net/programming/c-erlang-java-performance/
BrainFuck – единственный язык программирования, асм, жава и ц++ – попытки решить утилитарные проблемы малой кровью)))
НЛО прилетело и опубликовало эту надпись здесь
Вброс.
У всех языков есть свои недостатки. Описывать их без конструктивной критики — типичный вброс говна на вентилятор.
У всех языков есть свои недостатки. Описывать их без конструктивной критики — типичный вброс говна на вентилятор.
Для каждой определенной цели необходимо выбирать наиболее подходящее средство разработки.
Я считаю абсолютным и 100% бредом, что для php, да и, я просто уверен в этом, для любого языка программирования нельзя найти ту предметную область, где он был бы непревзойденным лидером.
Иногда кажется что люди вообще забыли, что программирование не есть кодирование. И знание конкретного языка является необходимым, но не достаточным условием чтобы называть себя программистом.
Я уже как лет 10 слышу примерно одно и тоже, и все время выбирают нового «козла» отпущения.
P.S. А вообще согласитесь, что истинная красота — это снять осциллограмму и увидеть что именно в этом переходном процессе будет прерывание, тут идет запись в регистры, а та вот серия импульсов ни что иное как передача по сети «VASYA PRIVET».
Это вам не echo ;-)
Я считаю абсолютным и 100% бредом, что для php, да и, я просто уверен в этом, для любого языка программирования нельзя найти ту предметную область, где он был бы непревзойденным лидером.
Иногда кажется что люди вообще забыли, что программирование не есть кодирование. И знание конкретного языка является необходимым, но не достаточным условием чтобы называть себя программистом.
Я уже как лет 10 слышу примерно одно и тоже, и все время выбирают нового «козла» отпущения.
P.S. А вообще согласитесь, что истинная красота — это снять осциллограмму и увидеть что именно в этом переходном процессе будет прерывание, тут идет запись в регистры, а та вот серия импульсов ни что иное как передача по сети «VASYA PRIVET».
Это вам не echo ;-)
НЛО прилетело и опубликовало эту надпись здесь
Не согласен с тем, что сложно писать качественно. Мне ничто не мешает писать говнокод на python и ничто не мешает писать качественно (надеюсь) на php.
А что большинство статей и книжек, согласен, стимулируют написание говнокода. Статей (хотя бы) о применении паттернов Фаулера, GoF, принципов SOLID, рефакторинга и т. п., на примере PHP нет практически. Приходится «апроксимировать» Java, C# и т. п. на PHP. Вот только начинающие разработчики вряд ли будут гуглить «примеры хорошей архитектуры java приложений»
А что большинство статей и книжек, согласен, стимулируют написание говнокода. Статей (хотя бы) о применении паттернов Фаулера, GoF, принципов SOLID, рефакторинга и т. п., на примере PHP нет практически. Приходится «апроксимировать» Java, C# и т. п. на PHP. Вот только начинающие разработчики вряд ли будут гуглить «примеры хорошей архитектуры java приложений»
Есть www.phppatterns.com/, но он давно уже не торт. Раньше и информации было много больше, и сайт красивше.
НЛО прилетело и опубликовало эту надпись здесь
Жрецы программирования