Comments 667
Сломал глаза пока прочитал. Разбивайте на абзацы в следующий раз — читать проще будет.
я именно из-за этого больше 2 строк не осилил. Пост, возможно, интересен, но читать в таком виде невозможно.
А вам эти 2 строки на несколько абзацев надо было разбить? :D
UFO just landed and posted this here
Вот теперь понятно.
В топике от силы 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 приводит к (или вытекает из) необходимости выделения модели (бизнес-логики), уже какой-никакой каркас, а если ещё разделить остальное на представление и всё остальное :) (контроллер) то получается полноценный каркас. фронт-контроллеры, роутинг, формирование форм, их валидация и биндинг — это детали
UFO just landed and posted this here
Ну, может для вас это бизнес, а для меня это искусство!
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Ну тогда предложу вам попробовать пайтоновские листы, срезы. =) Если я не ошибаюсь, он их унаследовал аж от самого Фортрана.
Сорри, уже спать собираюсь, ничего умнее не придумал.
>>> 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]]
>>>
Сорри, уже спать собираюсь, ничего умнее не придумал.
Вообще дребедень написал. Вот на вики простенько и наглядно. Хотя далекооо на все.
UFO just landed and posted this here
свободные проекты тоже пишутся для привличения прибыли.
Как «привлИкает» прибыль 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] ?)
UFO just landed and posted this here
Да ну? В 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 тоже.
UFO just landed and posted this here
Прост? А как насчёт массивов-хешей? А может, его правила неявного преобразования типа просты и очевидно? Или поведение ссылок? Или банальный приоритет тернарного условного оператора? Или синтаксис интерполяции строк? Ну это только навскидку вспомнилось.
Переписать еще несколько раз и все будет тип топ.
ИМХО, для человека, хоть немного знающего С++, изучение PHP дается с легкостью: знакомый синтаксис, много знакомых функций, только работа с переменными сначала кажется немного непривычной.
Бредовый пост ни о чём… набор мыслей. Где идея?
Идея — давайте опусти пхпшников, и на их фоне будем казаться крутыми )
Неправда, я такого не писал и не имел в виду.
«А сам PHP — как инструмент, как средство, как тема общения, — привлекает к себе людей в первую очередь «запоминательного», а не аналитического типа.»
Я правильно понял, что вы подразумевали, что пхпшники не могут анализировать и размышлять?
Я правильно понял, что вы подразумевали, что пхпшники не могут анализировать и размышлять?
Нет, неправильно.
Ну ладно тогда.
Заебали руби-неофиты, которые не способны написать что-то серьезнее хелловорлда, но дико горды своим синтаксическим диабетом.
Заебали руби-неофиты, которые не способны написать что-то серьезнее хелловорлда, но дико горды своим синтаксическим диабетом.
А, ну тады ладно. Я не руби-неофит. :)
+1.5
любой пхпшник мечтает писать на руби или питоне
любой пхпшник мечтает писать на руби или питоне
Не любой.
Не могу сказать, что мечтаю. Мне практически всё равно писать на php или python для веба. Для «десктопных» приложений однозначно python, пока нет биндингов qt для php
>пока нет биндингов qt для php
есть все, и qt и gtk и тд. только это говно, сами понимаете
есть все, и qt и gtk и тд. только это говно, сами понимаете
Полностью поддерживает qt4 под линукс и виндовс? Если да надо будет посмотреть.
php-qt это даже хуже, чем гланды через жопу удалять.
Идея для тех, кто не умеет читать: «Дело не в том, что один из них умнее, а другой глупее, нет. Это просто другой тип мышления, ориентированный на запоминание, а не на стремление собрать данные и проанализировать ситуацию с разных сторон. А сам 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-карячках и т.п вещах… Надо ставить вопрос, когда же будет всё более «цивилизованней», на сколько и в какие сроки это возможно, на сколько это нужно и как это мешает или нет…
Думается, никогда. Вон, от первого анонса про нэймспейсы я просто слюной истёк. Очень понравилось. А реализация понравилась существенно меньше. PHP6 сколько уже обещают? Три года?
Что значит «мультиязычен»? Чтобы быть специалистом, например, по 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) или того хуже посимвольным (про байты они не в курсе) перебором.
UFO just landed and posted this here
UFO just landed and posted this here
Не знаю что у вас не работает, у меня все вышеприведенные примеры отработали нормально (с соответствующей предыдущей инициализацией переменных, конечно).
<?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.
UFO just landed and posted this here
А ведь и правда — и что? Пускай не будет никакой логики в именовании функций, пусть все разработчики пишут кто во что горазд. 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 плохой язык, что программируя на нем не надо думать, а только подставлять функции?
UFO just landed and posted this here
UFO just landed and posted this here
Работал на php пару месяцев. Пересел на руби и рельсы. Ну вы поняли.
UFO just landed and posted this here
Хм… либо один, либо один с половиной. Про один я знаю точно. А в мире PHP их столько, что все упомнить сложно. :)
а программистов криворуких в мире пхп ого-го сколько! вы знали? %)
Ага, успел навидаться.
отвечая нв ваш вопрос -> фреймворков на руби достаточно. начиная от моснтров вроде рельс, заканчивая минималистическими аля sinatrta.
Никто в руби-мире не пользуется «чистым» руби для написания сайтов (плюю в огород пхпешников).
Никто в руби-мире не пользуется «чистым» руби для написания сайтов (плюю в огород пхпешников).
А, да! Про синатру я забыл. Но, поскольку вхож в мир Руби довольно слабо, то это, скорее, то, что «Изя напел».
Справедливости ради замечу, что чистым PHP тоже мало кто пользуется. :)
Справедливости ради замечу, что чистым PHP тоже мало кто пользуется. :)
много, меньше чем для РНР, но много!
Rails
Merb
Ramaze
Padriano
Sinatra
Camping
и еще дофига… И это не говоря о специальных фреймворках для создания API и т.д.
Rails
Merb
Ramaze
Padriano
Sinatra
Camping
и еще дофига… И это не говоря о специальных фреймворках для создания API и т.д.
ну сравните. я заранее знаю, что победит :D
Аналогично. Но Ruby чуток сложнее в освоении, и народа там поменьше. И найти на проект десять человек за полдня нереально. :)
ну и что :) Я свой выбор сделал — целый год сидел и изучал руби и рельсы. Без проблем устроился на должность младшего рейлс-программиста, получаю хорошо (поболее пхпешников-новичков).
Язык сложнее, но гораздо более выразительнее. И да — писать на рельсах ХОРОШО и не понимать РУБИ — не получится. Придется вкурить объектную модель руби. А я знаю, как пхпешники любят объекты и классы %)
Язык сложнее, но гораздо более выразительнее. И да — писать на рельсах ХОРОШО и не понимать РУБИ — не получится. Придется вкурить объектную модель руби. А я знаю, как пхпешники любят объекты и классы %)
UFO just landed and posted this here
в чем плюс симфони перед рельсами?
И учат ли в симфони так же как в рельсах — писать максимально понятный код, соблюдать конвенцию, выносить логику представления не только в контроллер но и в 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'
#
Options +ExecCGI):
#!/usr/bin/ruby
puts «Content-Type: text/html»
puts
puts «Hello Douche!»
А можно еще так (cgi входить в стандартную библиотеку):
#!/usr/bin/ruby
require 'cgi'
#
Жрецы программирования