Pull to refresh

Comments 667

Сломал глаза пока прочитал. Разбивайте на абзацы в следующий раз — читать проще будет.
я именно из-за этого больше 2 строк не осилил. Пост, возможно, интересен, но читать в таком виде невозможно.
А вам эти 2 строки на несколько абзацев надо было разбить? :D
UFO just landed and posted this here
В топике от силы 2-3 агрессивных фаната php, да и обороняться у них получается довольно вяло.
Ничего, зато мне уже наобъясняли, что лично я — типичный неосилятор. :)
Сложно спорить о языке, когда в качестве аргументов приводят библиотеки в язык не входящие.
Эти библиотеки рождаются благодаря качествам языка.
В PHP тоже есть библиотеки :) И ещё неизвестно где их больше
Явно, вы не пробовали действительно работать с ними на языках помимо php(если говорить о вебе).
С библиотеками на PHP работать из других языков? Вы правы, не пробовал даже в учебных целях.
Тот же phpclasses.org и pear/pecl не сравнятся с rubygems. До руби я много и писал на php, и мне есть с чем сравнивать.
Чёрт, не обновил страницу, теперь понял что вы имеете в виду. Не думаю, что если я начну писать на ruby, то я стану активно пользоваться rubygems, как не пользуюсь активно pear/pecl (только для зависимостей интересных проектов, типа phpdaemon, то есть если в install guide такого проекта содержится pear something). Есть задача — я её решаю, а не ищу путей как её не решать.
Ну и не правильно. Это просто пхпшная привычка, от которой лучше избавиться как можно скорее. PEAR/PECL тоже не использовал. Но в руби и питоне с распространением пакетов все настолько лучше, чем в php, что даже сравнивать сложно. Совершенно не представляю, как можно писать на том же питоне без pypi, это мазохизм какой-то получится.
Привычка далеко не пхпшная, а basic/asm. :) Тогда в России (вернее СССР) и интернета-то не было O_o
Конечно в похапе. Судя по всему каждый студент считает обязательным написать свою библиотеку вместо того, чтобы взять готовую. Правда большинство этих библиотек не доступно публики, но от этого только лучше.
>Судя по всему каждый студент считает обязательным написать свою библиотеку вместо того, чтобы взять готовую.

Ещё каждый «студент» считает обязательным написать свою 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?
Если пишет библиотеку, это уже не говнокод, соблюдает «межпроектный» DYI :)

По-моему, часто встречаются жалобы на то, что «асиляторы» не знают языка, не представляют как работает то, что они «асилили», искренне удивляются, когда в другой CMS не работает, например, какая-то «магия» типа использования шаблона с именем, совпадающим с именем контроллера/модуля.

Нет и, видимо, не будет. Да и проблему он бы не решил
Чтобы написать библиотеку для ruby надо как миниум понять суть gem'ов и то как на реализовать это на ruby. Банально сразу и с места говнокод писать не получится. :D да и то, что код будут видеть другие дает о себе знать.

>часто встречаются жалобы на то, что «асиляторы» не знают языка,

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

Про switch это печально. Хотя если бы его реализовали тупо так же как if — в нем нет смысла.
так а зачем он в языке?

processedRequest = { 
	'GET': getFunc, 
	'POST': postFunc, 
	'PUT': putFunc,
	'DELETE' : delFunc 
}.get(requestMethod,defaultFunc)(request)

на мой взгляд вполне себе switch ))
Затем, что в нормальных языках (си например) switch разворачивается в низкоуровневое сравнение которое быстрее if'a. Алсо, этого примера у меня кровоточат глаза, как я понимаю тут используется словарь и аноанимные функции, это как бы совсем не оптимально. Я конечно понимаю, что сейчас можно не экономить на памяти и процессоре, но не до такой же степени!

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 приложения писать. Я теперь не могу когда десктопные приложения жрут памяти больше чем надо.

В вашем примере конечно и эта конструкция нормально смотрится(хоть и трудночитаемая), но не все же этим примером ограничивается. Например мой пример если написать со словарем — будет очень по-наркомански и не читаемое.
Ну в примере без свитча будет лучше. Словарик с данными и готово, раза в полтора меньше печатать (и читать). Плюс код будет говорить за себя — структура инициализируетя разными данными в зависимости от значения переменной, данные отдельно, код отдельно. Банальность скажу, но свитч — один из косвенных признаков дурно пахнущего кода по Фаулеру. А про процессор — там же и правда такие копейки, о которых и говорить не стоит.
Не оптимально же. Словарик с данными медленнее jump table и больше памяти тратит. Код не говорит за себя, код вызывает кровотечение из глаз.

>А про процессор — там же и правда такие копейки, о которых и говорить не стоит.

А теперь представьте побольше вероятных исходов. И сделайте вот это: gist.github.com/759692
Да ладно, необходимо? С таким же успехом можно сказать, что чтобы написать библиотеку на php нужно понять суть pecl/pear. Говнокод выкладывать на гуглкод, гитхаб и т. п. никто не запретит (на rubygems есть премодерация проектов?).

Сколько в этой (да и других темах) не общаюсь по поводу «говнокода» никто мне не назвал язык, который его запрещает синтаксисом. Язык, в котором как ты не извращайся, конечное приложение будет идеальным для любых условий. Идеология, %xxx% way, coding styles guide и т. п. дают лишь рекомендации, следовать им или нет выбор программиста.
Необходимо.
Для руби библиотеки в 90% случаев поставляются в виде rubygems. В противном случае вас просто не найдут(через тот же gem search -r %keyword%)
Не путаете «написать библиотеку» и «предоставить доступ к ней как можно большему числу людей, потенциально в ней заинтересованных»? Не знаю как кто, но я пишу библиотеки для своих нужд, если захочу выложить, то буду выкладывать там, где мне удобно выложить и куда удобно дать прямой линк.
Ну, опять же, в руби не принято «скачивать» библиотеки. Они могут быть, например, в закрытом репозитории, но в виде rails-плагина или gem'a, чтобы в проекты подключать их одной строчкой, управлять версиями, зависимостями.
зато у вас — нападать получается вообще никак ) без улыбки ваши комменты не прочитаешь
Извиняюсь за оффтоп, но:
все-таки, не помешало бы отформатировать текст, даже если в вашем блоге он нормально смотрится.
Тут-то этот текст даже начинать читать не хочется…
Ага, сделал. Правда, Хабр мне при этом сказал, что у меня кармы для публикации в блог уже недостаточно. :)
Так уже лучше…
Сейчас вроде 5 единиц кармы нужно для всего этого. Хотя этот пост и так в блоге PHP =)
Ключевое слово «уже». :)
И, кстати, с прискорбием отмечаю, что ещё лучше сделать не смогу. Иллюстраций не будет. ;)
Скопировал, отформатировал и прочитать в редакторе :)
Странно: уже давно разбил на абзацы, а Вас всё плюсуют и плюсуют. :)
Плохо разбито, нужна пустая строка между абзацами
Запоминать имена функций и порядок следования аргументов нужно было во времена консольных компиляторов и убогих текстовых редакторов, а сейчас это давно уже не нужно — умная IDE подскажет и то и другое, а если даже примерно не помнишь названия функции, то Гугл поможет.
пхп привлекает людей зарабатывающего деньги типа, не надо философии разводить. да, пхп кривоват, но такого уж особого множества фактов, которые необходимо помнить в нем нет.
Ложь. Очень много свободных проектов с открытым кодом пишется на PHP.
ну и что? посыл статьи — пхп привлекает запоминателей, а не аналитиков. мой ответ — это деление тут не при чем, потому что программирование — это в первую очередь бизнес, а не разгадывание шарад. то есть независимо от типа мышления человек будет на нём программировать и аналитику будет легче, чем запоминателю. как, впрочем, и при программировании на любом другом языке.
Вот PHP с разгадыванием шарад сопряжён гораздо сильнее, нежели тот же python. Его я, к слову, привожу в качестве совершенно абстрактного языка, который не php; а то тут ещё джихад на тему PHP vs Python начнётся.
Вон, пример, который я привёл в 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.

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

Пробовал не раз читать (Шекли), но от понимания не приходит умение выражаться. Хотя может просто не набрал критической массы. Недавно вот набрал её для слепого набора с 100500-й попытки.
Оффтопим. Предлагаю продолжить в личке, я уже написал.
продолжайте оффтопить, самая интересная ветка в комментах )))
Т что буквами написано я и так понимаю, только вот «сказать»(написать ничего не могу)
Как бы мечтаю о заказе «нужен чат» где-нить на фрилансру, который мне попадётся на глаза и сумею убедить заказчика, что Эрланг это круто. Правда нормальный заказчик вряд ли согласится, где он потом найдёт «суппортера» за 5$/час. чистая «подсадка на иглу» :)
У вас был отличный пример в статье — Windows. Да, она кривая и нелогичная. Но это ей не мешает быть абсолютным лидером. По вашей логике выходит что среди пользователей винды — тоже жрецы без логики. Однако, как сказал ваш оппонент — профессионалы вынуждены работать с Windows, потому что это огромный рынок. Статья в целом интересная, и с большинством я согласен. Кроме одного — в кривых руках, и язык кривой. Лично я давно не пытаюсь что-то запоминать в ПХП: есть хорошие CHM с моментальным поиском :)
один препод в универе нас учил: «не надо всё запоминать, заучивать, зубрить… всё запомнить невозможно и не нужно. важно уметь пользоваться справочниками, пособиями и знать где нужную информацию можно найти» (не дословно)… и разрешал на зачетах и экзаменах пользоваться «справочной литературой» (конспектами и учебником).
причем, предмет преподавания с IT не свзян.
Какой у вас диалог интересный вышел, и никто никого не тролит и оба оратора рубят факты.
Рынку вообще до лампочки на чем оно написано всё, хоть на ассемблере.
рынку потребителей все равно, а рынку труда — вовсе нет
И что интересно лучше, быть в меньшинстве, но которое таки востребовано, или влачить жалкое существование в общем потоке только потому, что мол рынок больше?
что же не все варианты рассмотрены? еще можно быть в меньшинстве, которое не востребовано и влачить хорошее существование в общем потоке.
в сухом остатке — хорошо, там где ты востребован, неважно общий поток это или нет. но в общем шансы выше
>но в общем шансы выше

Ничего такого из того, что поток общий, не вытекает. С одной стороны конечно предложений больше, но с другой стороны и конкурентов больше.
Вне общего потока можно найти свою нишу, свое призвание и жить спокойно.
Ну, как видим, от человека зависит. Мой оппонент работает на том, что востребовано. Я ищу работодателей, которые дают мне работать на том, что нравится мне.
поддерживаю, работаю над тем (выбираю из того, что предлагают), что мне больше по душе/интересно и это, имхо, самый значительный плюс фриланса.
Так, вот вы говорите что запоминателям в пхп проще потому что там успешность программиста зависит от умения запомниать.
Но постойте, я вот сейчас открою код своего проекта. И сделаю в нем grep -R 'str_'.

Да ладно уж, просто поищу упоминание стандартных функций по работе с массивами/строками.

Ой, нашло один strstr()

Вы не думайте, проект не на 100 строчек кода.

А знаете почему? Потому что гладиолус абстракция. (все сейчас представили что у меня врапперы написаны на все функции :) но нет).
Откройте проект на любом высокоуровневом фреймворке типа Zend/Symfony/Doctrine. Если не заглядывать в код фреймворка — 99% кода выполняют бизнесс задачи не требующие использования стандартных функций.

А теперь возьмем рядового программиста на пхп который в деле уже 3-5 лет. Вы думаете он до сих пор пишет на коленке? (а велосипедах долго не продержишся в отрасли).
Выходит что «запоминатели» они только в начале пути. Но пройдет время, дополучается необходимый опыт и человек из запоминателя превращается в аналитика.

А теперь подумаете — подходит ли ето к другим языкам. Разве когда вы начинаете писать на Python вы сразу можете использовать встроенные функции без мануала?
Не можете. В начале пути — мы все жрецы. И только потом становимся настоящими джедаями.
> Откройте проект на любом высокоуровневом фреймворке типа Zend/Symfony/Doctrine.
А где ж мне его взять? У меня щас под руками только 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

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 только пофиксили
вы еще в php4 найдите глюки, и напишите пост о ущербности ))
Как классно общаться с людьми, которые не умеют читать и не хотят понимать.
Я сказал, плюс-минус лапоть, следующее: в PHP многие вещи нужно помнить. Как пример, такое серьёзное изменение логики прошло практически недокументированно. Люди не знают о том, когда ущербное поведение заменили на логичное и правильное. Как следствие (см. текст поста, людям «запоминательного» типа с PHP общаться проще.)
Вы мне отвечаете, что я пишу об ущербности PHP.
Да, я согласен, что PHP ущербен, так как наблюдаю это поделие с 98-го, с «тройки». У меня по нему нет ZCE, но их пробные онлайновые я сдал на эксперта, так что говорю я это не просто так. Однако в данном случае речь не шла о том, что ущербен PHP, а о том, что людям, которым проще запомнить, чем понять, он легче даётся. Потому что понять местами нельзя.
Я понятно объяснил?
подобных багов можно нарыть кучу в реализации любого языка.
удивительно что вы общаясь с php еще с «тройки» этого не поняли.
это никого кроме вас не наталкивает на такие странный выводы, и желание написать об этом не менее странную статью.
Подобных? Ну, если это для Вас незначительный баг, то таки да, конечно.
баг значительный.
другое дело что я никогда не передавал напрямик в конструктор функцию, тем более которая в кидает эксепшн.
я както больше по старинке, сначала формирую параметры а потом передаю их в функции и методы.
видимо поэтому подобные глюки мне не портят нервы в работе.
А зачем забивать пространство имён? Ну вот какой в этом сакральный смысл? Если этот параметр вообще нигде не будет использован дальше? Это вкусовщина. А то, что «Вы никогда» — так это сугубо Ваше дело.
смысл в том чтобы не городить такие многоэтажные конструкции, к томуже перед рождением важных объектов можно провалидировать полученные данные, прежде чем передавать их дальше…
сами же писали о наследии говнокода который оставляют php кодеры. вот ваши пример как раз из той кучи.
Э… Понимаю, что Вы говорили не об этом, но всё-таки: в Ваших программах много неважных объектов?
да много. это например классы работы с типовыми формами, валидация, генерация картинок, плагины к социальным сетям… если чтото пойдет не так то юзер просто не увидит страницу или блок.

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

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

Что «пост ни о чем», не один я сказал. Собственно как и ваш ответ не по теме комментария. Насчет русского языка я уже ниже писал: если для вас запомнить несколько «словоформ» языка php такая проблема, то как же вы с русским-то справлялись?

А последнее ваше высказывание — бред в чистом виде. Может и еще как.

Засим откланиваюсь, желаю натренировать память в новом году.
Надеюсь, что Вы так и поступите: будете читать больше литературы. Обороты, используемые Вами, спокойно можно патентовать: так говорите только Вы. Ну, возможно, ещё Ваши коллеги из числа наименее образованных. У «технарей» такое бывает.

И да, с наступающим праздником Вас.
У мок-экзаменов от phparchitect (а именно они были «официальными» пробными) нет оценки «эксперт», уж извините за занудство :)
А вот если __construct написан неправильно, то действительно конструктор не вызывается, и, по всей видимости, функция throwEx() тоже :), и вот это уже действительно косяк.
эксепшн возник еще ДО выполнения конструктора, и логично что пхп прервал его выполнение и вызвал деструктор.
а что ДОЛЖНО БЫЛО произойти? чтоб выполнение продолжилось и эксепшн был проигнорирован? тогда бы вы еще больше начали кричать о нелогичности поведения )))
Ой-ей-ей!
Проблема в том, что деструктор не должен вызываться, если не вызван конструктор.
Но это ладно, хуже другое:

try{
$a = new A(throwEx());
} catch (Exception $e) {
echo 'catched!';
}

Исключение не было поймано!
Напишите слово __construct правильно — будет ловиться (и деструктор не будет вызываться).
переименуйте
function __constuct($a) {
в
function __construct($a) {
и оно чудесным образом будет поймано)
Переименовал, стало лучше, спасибо.
Угу. Именно это мне и пришлось в своё время объяснять коллеге.
Точнее, не это, а почему __destruct() отрабатывает вне зависимости от того, отработал ли конструктор. Там бизнес-логика была.
а почему деструктор не должен-то отрабатывать? ведь объект уничтожается после завершения обработки… не?
А потому что можно создать объект, а потом попытаться дёрнуть инициализирующий метод, словив исключение при получении аргументов, и оставив объект (объект при этом не знает, что он инвалид, и будет в __destruct() косячить). Самый простой пример — со статическим свойством, которое увеличивается на единицу в конструкторе и уменьшается на единицу в деструкторе. Из-за этого бага до PHP 5.3 это статическое свойство очень просто можно было загнать в глубокие минуса.
А можно сначала получить аргументы, создать объект и дёрнуть инициализирующий метод. По мне так логичнее второй подход, но раньше здесь работал первый.
Деструктор – это специальный метод класса с именем __destruct(), который будет гарантированно вызван при потере последней ссылки на объект в программе.

Вопрос — а была ли создана хоть одна ссылка, если исполнение прервалось еще на стадии вычисления аргументов (напомню, что в PHP нет отложенных вычислений).
Вы зря спорите, на самом то деле. Эта логика, как выше уже выяснилось — была убрана в PHP 5.3.
UFO just landed and posted this here
Так вот должна ли она быть создана? Нет, не должна была, нам нечего передать конструктору в качестве аргументов. Однако он вызывался.
Вы уж определитесь, «эксепшн возник ДО конструктора», или «пхп прервал выполнение конструктора»?
А зачем? :) Нам противостоит типичный «жрец». :)
тоесть вы себя относите к высшей касте программистов? )))
Вот опять. Это _разные_ типы мышления. Я не считаю людей, которым нравится чёрный, лучше людей, которым нравится красный. И левшей с правшами не разделяю по принципу «кто лучше».
Кстати, слово «каста» тоже какое-то… религиозное. :-P
я как и многие тут еще пишу на java например. и что? я все еще «жрец»?
Ну я тоже писал на Java. Работал с J2EE. В 2001-м. Там было всё логично. Да, доки тоже были открыты, но с javadoc конкретных вещей. Приколов типа процитированного с деструкторами без конструкторов там не было никогда.
тоесть если в java найти баг, то он автоматически станет «ЯП для жрецов»?)
То есть вот лично у Вас проблемы с вербализацией мыслей, о чём Вам в #comment_3527434 тактично намекнули. Как видно из продолжения дискуссии, Вы упорно не пытаетесь понять собеседника и продолжаете гнуть свою линию. Баги тут ни при чём., приведённый мной пример — не иллюстрация бага, а скорее «особенность реализации», которая, кстати, потихоньку была устранена. Молча.
Java же, к слову, очень логичен и отлично продуман. Писать на нём — одно удовольствие.
и у кого из нас проблемы после этого)) вы со мной вообще разговариваете?
я уже который раз задаю прямой вопрос, и не получают прямого ответа.
просто вы не можете ответить мне потому что это будет противоречить всей вашей теории о «персистентности типа ума» программистов.
потому что даже ёжику понятно что нормальный прогер может легко переключиться на другой язык, если есть необходимость или просто желание. так как:
— запоминать ничего не нужно, всю рутину давно переложили на IDE
— баги есть везде! и это не показатель принадлежности языка к тому или иному типу
Да, стараюсь разговаривать с Вами.

Объясняю по пунктам:
1) Вам задали вопрос: «Вы уж определитесь, «эксепшн возник ДО конструктора», или «пхп прервал выполнение конструктора»?» Вы не ответили. А это немножко разные вещи.
2) Вместо этого Вы начали что-то невнятное про «высшую касту». Ещё раз: я не считаю, что высшая каста — это люди, которые любят яблоки; равно как не считаю, что низшая — те, кто любит груши. Я вообще программистов на «касты» не делю.
3) Да, поскольку с логикой у Вас проблемы (см. пп. 1) и 2)), Вы очень похожи на «жреца» по моей терминологии. Разговор у нас, соответственно, складывается ни о чём: вот уже и Вы в нём смысла не видите.

Давайте закроем эту ветку, она заведомо непродуктивна.
Простите но мне кажется что это как раз «очередные тонны кода, которые будут приводить в ужас всех, пришедших следом». Мешанина функций и классов, что может быть хуже?
Это не тонны кода, а максимально сжатый по объёму пример, написанный за две минуты для того, чтобы проиллюстрировать конкретную проблему. Разницу видите?
А какую проблему демонстирует этот кусок кода? На сколько я понял в ранних версиях это могло привести к вызову деструктора без вызова конструктора. Ну так мне кажется что это кривизна кода а не проблема языка. mysql_query может к sql injection привести, но это же не проблема/недостаток языка а скорее проблема разработчика, который должен знать и понимать что и как он делает
Создание объекта происходит даже при исключительной ситуации при вызове конструктора. Это проблема, т.к. конструктор не отработал, а деструктор всё равно будет вызван.
Всё же я с вами не соглашусь, да тут есть косяк со стороны php но исключительную ситуацию должен отлавливать разработчик
Вот еще такой пример.

Кажется очевидной такая конструкция, но нет.
if ( empty($obj->foobar) ) {

}
empty это такая специальная конструкция языка, и
если переопределены __get, __set то нужно переопределить еще и __isset, который будет выполняться в этом случае.
Ну да, я в курсе. Но магия — это ещё одна тема для строительства багодромов.
функции работы с массивами тоже логичны и предсказуемы? :)
А ведь сам язык php вполне логичен и прост. Я имею в виду собственно управляющие конструкции.
А остальное — это уже стандартная библиотека, не сам язык. Да, есть нелогичные места. Но в других языках тоже надо запоминать, и немало.
ООП — это стандартная библиотека?
Нет. А в чем претензии к ООП? В php 5.х все вполне логично.
Тут как раз надо один раз понять, а не запоминать.
Он логичен как шаблонизатор. Для этого там есть специальный синтаксис записи операторов для вставки в 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
Прост? А как насчёт массивов-хешей? А может, его правила неявного преобразования типа просты и очевидно? Или поведение ссылок? Или банальный приоритет тернарного условного оператора? Или синтаксис интерполяции строк? Ну это только навскидку вспомнилось.
Когда переменные встраивают в строку вот так: «word word word $variable word».
Переписать еще несколько раз и все будет тип топ.
ИМХО, для человека, хоть немного знающего С++, изучение PHP дается с легкостью: знакомый синтаксис, много знакомых функций, только работа с переменными сначала кажется немного непривычной.
Бредовый пост ни о чём… набор мыслей. Где идея?
Идея — давайте опусти пхпшников, и на их фоне будем казаться крутыми )
Неправда, я такого не писал и не имел в виду.
«А сам PHP — как инструмент, как средство, как тема общения, — привлекает к себе людей в первую очередь «запоминательного», а не аналитического типа.»

Я правильно понял, что вы подразумевали, что пхпшники не могут анализировать и размышлять?
Ну ладно тогда.
Заебали руби-неофиты, которые не способны написать что-то серьезнее хелловорлда, но дико горды своим синтаксическим диабетом.
А, ну тады ладно. Я не руби-неофит. :)
+1.5
любой пхпшник мечтает писать на руби или питоне
Не могу сказать, что мечтаю. Мне практически всё равно писать на php или python для веба. Для «десктопных» приложений однозначно python, пока нет биндингов qt для php
>пока нет биндингов qt для php
есть все, и qt и gtk и тд. только это говно, сами понимаете
Полностью поддерживает qt4 под линукс и виндовс? Если да надо будет посмотреть.
Можете не смотреть, оно в любом случае уже года 2 как заброшено. К своему стыду, признаюсь, что у меня его даже не получилось собрать на современном дистрибутиве. Подробности не помню, но вроде ему позарес нужна была именно старая версия какой-то либы, которую уже достать у меня не получилось.
php-qt это даже хуже, чем гланды через жопу удалять.
Идея для тех, кто не умеет читать: «Дело не в том, что один из них умнее, а другой глупее, нет. Это просто другой тип мышления, ориентированный на запоминание, а не на стремление собрать данные и проанализировать ситуацию с разных сторон. А сам PHP — как инструмент, как средство, как тема общения, — привлекает к себе людей в первую очередь «запоминательного», а не аналитического типа».
тут на Хабре каждый второй мультиязычен. успешно кодят сразу на несколько языках, в зависимости от поставленной задачи и проекта.
как вы объясните этот феномен с точки зрения своего «запоминательного» и аналитического типа»?
Даже не собираюсь объяснять. Я тоже много на чём пишу. Но когда я пишу на PHP, мануал у меня открыт практически всегда.
тоесть когда человек кодит на PHP он «запоминательного» типа.
только открыл в IDE проект на Ruby — сразу стал «аналитического типа»?
что за неявное преобразование типов )
То есть человек с аналитическим мышлением сильно облажается, если будет строить предположения на базе уже имеющегося опыта. Впрочем, как справедливо заметили, человеку, который использует только IDE, не нужно строить предположений. Ему IDE подсовывает факты.
а вы что в Notepad-e кодите? что вам приходится ВСЕ ЭТО запоминать и постоянно обращаться к мануалу?
тем более и запоминать то там не так много…
А IDE за вас и код сама понимает? Уже написанный.
И мысли читает? Заранее угадывая какую функцию вы хотите написать.

Вот, например. Функция считающая md5 файла хотя бы с какой буквы начинается? С «m» или с «f»? =) А в каком разделе мануала она? Cryptography Extensions или File System Related Extensions? =)
никогда это не было для меня проблемой. когда писал на других языках тоже не пытался запомнить ВСЕ функции. По мере набора опыта они сами запоминались. а что забыл быстро находилось в доках или с пом. хинтов в IDE. в чем проблема то? тем более широко используя фреймворки, процесс кодинга преместился на более высокий уровень абстракции, и там уже совсем другие классы и методы. пожалуйтесь еще что их тоже оказывается надо знать, изучать и запоминать… ))
Операции с массивами, строками, изображениями, математика… разве эти задачи решают фреймворки? Каким образом они вдруг переместились в фреймворки? В php со всеми стандартными модулями несколько тысяч функций, и почти за каждой надо лезть в мануал, ибо знаешь, что от функции нужно, но порой даже не догадываешься, в каком разделе мануала ее вдруг обнаружишь и с какой буквы она может начинаться. Увидев в чужом коде незнакомую функции, также надо про нее читать. Догадаться что именно она делает со всеми ньюансами — практически не возможно. Вы к этому привыкли, и сейчас рьяно защищаете, а ничего хорошего то в этом нет. А код должны писать и понимать вы, а не IDE. У меня нет желания дальше с вами продолжать спор, это бессмысленно, пишите на своем php, мне то что, я же не к чему не призываю.

Функция считающая 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;

в топике еще никто не упомянул.
как спасают фреймворки? абстракцией батенька:
$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 это как-то так:
#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, более шести лет. О чем жалею. Крутясь постоянно внутри 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 меняется. не всегда быстро и правильно, но в целом тенденция хорошая.
Заказчик ведь свои требования не с потолка берет. Меня например совсем не устраивает, когда «для себя кодят на чем нравится, а для заказчика на чем нужно». Работа должна быть в радость. Я предпочитаю программировать исключительно на чем нравится, и благо такую возможность всегда нахожу. То, что нравится, надо нести в массы, и до заказчиков. Иначе, ситуация не поменяется.

PHP меняется, да как верно заметили, не то что не всегда быстро, а скорее даже очень медленно. А с учетом тормозов хостеров — и того медленнее. Когда там php6 ожидать? Вон неймспейсы из него портировали, но, как погляжу, не все от них в восторге. А когда с ними перепишут все фреймворки и пр. еще большой вопрос. Более менее вменяемый gc тоже вроде наконец сделали, но насколько вменяемый не знаю, вопрос. Настоящий fastcgi говорят теперь возможен, а на практике? Тоже вопрос.
>А когда с ними перепишут все фреймворки и пр. еще большой вопрос.

symfony2 и Zend Framework 2 находятся, имхо, уже в пригодном для продакшена состояния, хотя официально это отрицается :)
Подпишусь почти под каждым словом :) Но php3 (первый который я начал использовать после cgi скриптов на C — использование ООП C++ для веба мне тогда казалось ненужным оверхедом и, имхо, небезосновательно для тех задач и стоимости тех ресурсов) и php5.3 это небо и земля.

А вот насчёт «не учит хорошим манерам» — это, имхо, относится практически ко всем «динамическим» языкам. Они почти все прощают ошибки, которые в C бы не прошли.

Вот этот мануал плохому, по-моему, не учит, правда там не 10 минут, а 24 часа. Очень приятный, по-моему.
Ну хорошо, расскажу чему учит начинающих веб-разработчиков python, особенно по сравнению с php:
1) Отступы, правильное форматирование кода. Как не крути, а на пайтоне только так. Плюс упоминание docstrings лишний раз напомнят, что код надо правильно комментировать.

2) Как вы уже неоднократно заметили, для веб на пайтоне без фреймворков не пишут. И, как правило, все начинают стразу с django. А фреймворк научит паттернам и правильно структурировать код. И шаблонизация туда же.

3) Качественные, хорошо оформленные и структурированные библиотеки, модули, правильно именованные функции привьют хороший вкус. А так пользователи наглядевшись на php-шные функции, и о своих не задумываются.

4) У пайтона еще к тому же гораздо более качественный и точный анализатор кода, чем у php. Ошибки синтаксиса гораздо более информативны.

5) logging, pydoc и unittest модули уже из коробки. Хороший намек, всякий новичок об этих вещах узнает.
Хм. С такой точки зрения не смотрел, всё пытался понять чему (а главное как) учит python читая The Python Language Reference, думал учит сам синтаксис. Спасибо за разъяснение.

Правда я к всему этому пришёл на PHP, могу писать (и раньше даже писал) и по другому, но рука не поднимается :)
Тема сисек не раскрыта, все понимающие и так знают о количестве функций в глобальной области, их «особых» интерфейсах, php-карячках и т.п вещах… Надо ставить вопрос, когда же будет всё более «цивилизованней», на сколько и в какие сроки это возможно, на сколько это нужно и как это мешает или нет…
Думается, никогда. Вон, от первого анонса про нэймспейсы я просто слюной истёк. Очень понравилось. А реализация понравилась существенно меньше. PHP6 сколько уже обещают? Три года?
Да, реализация мне тоже не очень понравилась… Я и сам не раз подымал тему о медленном и кривоватом развитии языка, надоело ждать, перешел на c#
Что значит «мультиязычен»? Чтобы быть специалистом, например, по Java, нужно обладать тонной опыта, получаемой за немалое время. Я даже с C# на Java в своё время переполз полноценно где-то за полгода. И сейчас считаю себя Java-специалистом, и на вакансию «разработчик .NET» не пойду, ибо теперь годен только в джуниоры. Да, небольшой костыльчик на C# я напишу (как раньше, будучи дотнетчиком, мог на Java). И на Python, и на Ruby, а тем более на PHP я тоже что-то небольшое напишу. Но вот поддерживать крупный проект я бы не взялся. Потому что боюсь что в этом случае нагородил бы тонны говнокода. И, кстати, мне приходилось в жизни довольно много писать на PHP и не сказать, чтобы мне это сильно нравилось. Именно, что «приходилось».
Всё зависит от определений слов «программист», «специалист», «быдлокод» и т. п. Имхо, есть «программисты» на каком-то ЯП и есть программисты, специализирующиеся на таком-то ЯП. Почувствуйте разницу
ну вот как раз в этом и есть посыл «что один из них умнее, а другой глупее», только завуалированный. По крайней мере я так это понял.
Вы говорите, что мол мы такие клёвые, мы программируем анализируя(думая) и собирая информацию и бла бла бла, мы аналитики, а эти пхпшники просто тупо всё запомнили, и прогают не думая, обычные code monkey.
Такой же завуалированный посыл можно найти и в том, что кто-то из нас визуал, а кто-то кинестет. Или кто-то флегматик («ну медленно соображает, ну тупой!»), а кто-то сангвиник. Это как в анекдоте: «Граждане, он меня сукой обозвал!»
Когда-то PHP меня привлек своей легкостью написания скриптов для веба (да-да, спагетти-код, глобальное пространство имён для библиотечных функций и модуль апача — это сказка по сравнению с сайтами на чистом Си в CGI). Сейчас привлекает как самый востребованный (ИМХО) язык в «эникейном» сегменте российского рынка.
Согласен, но на «эникейном» рынке далеко не уедешь.
Но и вылезти с него трудно («Съест-то он съест, да кто ж ему даст»). Сменить основной язык разработки так, чтобы не писать на нём «быдлокод» (в понятиях нового языка) — нужно иметь какой-то фидбэк. Я вот тут случайно узнал, что нормальные люди не пишут веб-приложения на руби без рельс или синатры, на худой конец рэка, а я после написания хелловорда как cgi, чуть ли не весь протокол FastCGI начал реализовывать начиная со слушанья сокетов
UFO just landed and posted this here
PHP отличается от других легкостью изучения.
Поэтому так много говнокода на нем пишется.
Но есть и очевидные плюсы — скорость разработки (считай решения бизнес-задач)
Именно это и отталкивает многих от php в сторону ruby/python/etc. Из 1000 php кодеров по пальцам можно пересчитать тех, кто реально «кодит». Все остальные сравнивают файлы через file_get_contents($file1) != file_get_contents($file2) или того хуже посимвольным (про байты они не в курсе) перебором.
Про байты, говорите, не в курсе? Ну-ну, побайтовое сравнение Unicode (в частности utf8) строк недопустимо, а посимвольное ещё хоть как-то прокатит, хотя тоже не панацея.

А что отталкивает я не понял — легкость изучения или скорость разработки?

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
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
UFO just landed and posted this here
И дороговизна поддержки после такой скорой разработки.
В чём дороговизна поддержки приложения на php по сравнению с практически таким же (вплоть до структуры каталогов и простого копипаста конфигов) приложением на ruby?
скорость решения бизнес-задач на том-же питоне уж точно не ниже, а поддерживаемость, внятность и вменяемость кода и библиотек в разы выше.
Зависит от класса задачи. Одно дело, когда это заведомо сложное приложение разрабатываемое с нуля, а совсем другое когда бизнес-задача состоит в добавлении формы обратной связи к статическому сайту. А поддерживаемость, внятность и вменяемость приложения на symfony или на django, имхо, сильно не отличается.
когда я пересел с БК-01 на ПК и начал изучать Паскаль, бытовало мнение, что программисты на Бейсике никогда не отучаться писать программы через goto, ничего, научился писать структурированный код. Потом плавно и на Дельфи с ООП подсел, не сказал бы, что где-то прям переламывать себя пришлось. Года 2-3 назад перешел на веб и PHP (я не учитываю мелкие опыты, только основные языки), от библиотеки функций, конечно, плеваться хочется, кстати, так и не выучил все параметры, благо в IDE есть подсказка параметров, но в остальном, довольно легко приспособился. Год назад изучил по книжкам Ruby и Rails, все мечтаю на них перелезть, пока не складывается.
Это я все к чему… Поменьше ярлыков на людей вешайте, лучше работать чем холивары разводить.
Между прочим эту фразу сказал сам великий Дейкстра, впрочем я бы добавил, что фортрановский программист напишет фортрановскую программу на любом языке программирования.
Но в целом, если отвлечся от исключений, то тенденция весьма верно подхвачена, но мне хотелось бы увидеть от автора обобщение её и на другие языки программирования.
Я в школе изучал Basic примерно в таком виде, каким он был на Спектрумах, БК и иже с ними, хотя мы использовали интерпретатор QBasic. Но однажды мне зачем-то захотелось почитать справку, и я узнал о прекрасных конструкциях DO… LOOP, SUB… END SUB, FUNCTION… END FUNCTION и подобных. Перейти к ним от прежних GOTO/GOSUB было не представляете как легко. Эти конструкции просто сами напрашивались, без них мало-мальски сложную программу написать было не под силу.

ЗЫ. Сейчас программирую на Perl, и меня уже никаким языком не испугать :)
Слишком обобщенное мнение.
PHP развивается, Вы посмотрите хотя бы на развитие ООП в нем. Просто как и любой язык он имеет стадии, как Вы сами и указали в статье.
Запоминание в эру IDE и редакторов с подсказками вообще не нужно. Скорее надо понимать и разбираться в основных конструкциях, идеях, паттернах.
И насчет того, что не убирают морально «устаревшие» функции из пхп:
php.net/manual/en/migration53.deprecated.php < — тут даже упомянутые Вами eregi
Весь пост превращается в бред, если программист использует IDE с подсказками.
Неужели Вы действительно думаете, что PHP-программисты ЗАПОМИНАЮТ НАИЗУСТЬ все 3000 стандартных функций с параметрами?

То же самое можно написать про английский или китайский разговорные языки. Там тоже много слов надо запоминать.
Ага, а тонны говнокода в этом самом IDE в тыкву превращаются ;)
Говнокодеров на php конечно много. Я ни в коем случае не пытался это опровергнуть. Но, «Запоминание ф-ций наизусть» — не является причиной говнокода.
более того «Запоминание ф-ций наизусть» не является признаком высшего проффесионализма или чего-то в этом духе, это просто приходит с опытом, причем временно помоему, если полгода заниматься парсингом или еще какой-нибудь узкой работой то можно что-то и забыть что юзали раньше… бывает я думаю.
В этом то и проблема PHP.
К сожалению, никакой логики в названиях функций для работы со строками и массивами — нету, их приходится запоминать.
Примеры::
Два слова в названии функции:
addslashes
count_chars
Сокращение предлогов:
bin2hex
hebrev
strtolower

И если с этим еще может справиться IDE, то вот с этим — нет:
Префиксы функций:
crc32
str_split

Упс, отправилось рано.

Префиксы функций:
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 если нужно.
ну какая половина то? ) вы штук пять кое как набрали
Лезем в мануал и смотрим спиок функций работы со строками и массивами — разброд и шатание в тех пунктах, что я указал выше. Извиняйте, но сюда копировать не буду.
Ну, если отвечать на поставленный вопрос, то да — в большинстве других языков (C#, Ruby, Java, JavaScript, Python) это называется split и join. А функции для работы со строкам собраны в специальных объектах/модулях, таким образом их легко можно найти без чтения документации. Explode и implode я встречал только в PHP.
Не совсем :)
split: This function has been DEPRECATED as of PHP 5.3.0. Relying on this feature is highly discouraged.
ну в 5.3 и приведенный автором поста код с багом деструктора уже пофиксили.
так что нет худа без добра
Не знал про join) При этом split — это разбиение строки по регулярке, и находится в модуле регулярных выражений, а join — напротив находится в строках, но это просто alias для implode.
Although implode() can, for historical reasons, accept its parameters in either order, explode() cannot.
С проблемами *str* я справился просто и давно (PHP5 ещё не вышел, а 3 уже был не особо актуален) — написал класс инкапсулирующий работу со строками (в т.ч. с разными кодировками, включая unicode). По мере необходимости дописываю недостающие функции, включая те, которых в стандартных библиотеках нет, например преобразование SomeText <-> some_text или some/text.
Перевести на php5.3-namespace и выложить в публичный доступ? =)
Думаете кому-то интересно? %-/
СЛУШАЙТЕ! Господа уважаемые аналитические интеллектуалы!
А вы как с русским языком-то вообще справляетесь? Не перенапряглись запоминать все слова?
Или каждое слово в словарике смотрите? Тьфу на вас, развели базар ни о чем!
Наименование функций не самая большая проблема пхп.
С опытом все очень даже запоминается.
Темболее с использованием фреймворков.
Я и не говорю, что самая большая. Но, по-моему самая наглядная.
Опыт у меня есть, и почти все функции, и даже порядок их аргументов (который, сука, разнится от функции к функции) я помню. Но вот какие-нибудь 5%, которые я использую редко — меня расстраивают.
как минимум надо знать, что есть такая-то функция, а для этого ИДЕ мало, надо и доку читать.
например, в похапе есть функция для форматирования числа, ИДЕ, не ИДЕ, но знать о функции надо. а я еще часто использую перл и мне проще написать регулярку.
А может быть это совсем не плохо: хотя бы разок залезть в документацию?

И я не защищаю ф-ции php. То что они имеют дебильные названия — это неоспоримый факт. Но я придумал для себя решение и отношусь к этому с пониманием.

Но вот писать, что это главная причина говнокодерства пэхапэшников, потому что у них перестраивается мозг — бредово.
Перестраивается мозг? :-[ ]

Офигеть. Вона что я написал, оказывается.
Каждому своё. Есть люди, склад ума которых предрасположен к PHP, есть любители С++, есть адепты других языков. У каждого что-то получается лучше, что-то понимается легче, что-то запоминается быстрее. И это хорошо.
Благодарю Вас. Вы первый, кажется, поняли мысль про склад ума.
не соглашусь, мне кажется во многом у кого как сложилось, кому когда заработать захотелось и что подвернулось, кому-то просто может нравится веб, но это не предраположенность к PHP или к чему либо другому. Я знаю многих которые ушли из «большого» С++ в «проффесиональный» PHP, есть один случай и наоборот, чаще всего это просто потому что — «так сложилось»
причины это: зарплата, условия, интерес к конечному продукту на выходе.
Зря потратил время на прочтение поста, не о чем. Что вы хотели этим сказать? Что php плохой язык, что программируя на нем не надо думать, а только подставлять функции?
полностью согласен, очередной холивар ИМХО
UFO just landed and posted this here
Я пользуюсь онлайновым, не суть. Вот знать, что в версии 5.2 new создаст объект, а потом кинет эксепшн, не вызвав __construct(), а потом вызовет __desctruct(), надо. И это не написано в хелпе. И что починили эту радость в 5.3, тоже не написано.
UFO just landed and posted this here
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 и т.д.
ну сравните. я заранее знаю, что победит :D
Аналогично. Но Ruby чуток сложнее в освоении, и народа там поменьше. И найти на проект десять человек за полдня нереально. :)
ну и что :) Я свой выбор сделал — целый год сидел и изучал руби и рельсы. Без проблем устроился на должность младшего рейлс-программиста, получаю хорошо (поболее пхпешников-новичков).
Язык сложнее, но гораздо более выразительнее. И да — писать на рельсах ХОРОШО и не понимать РУБИ — не получится. Придется вкурить объектную модель руби. А я знаю, как пхпешники любят объекты и классы %)
UFO just landed and posted this here
в чем плюс симфони перед рельсами?

И учат ли в симфони так же как в рельсах — писать максимально понятный код, соблюдать конвенцию, выносить логику представления не только в контроллер но и в cells'ы?
Лично для меня два плюса (один субъективный, другой объективный):
— хорошо знакомый язык (пускай с закидонами, но знакомыми и привычными)
— большая востребованность php решений и большее распространение php хостингов (и админов, способных поднять php приложение с нуля например на vds) — что причина, а что следствие судить не берусь, хотя, похоже, самоподдерживающаяся система. И, имхо, для поднятия приложения на рельсах нужно знать больше, чем для поднятия такого же приложения на симфони. По крайней мере, я так и не нашёл как запустить ruby (равно как и python) приложение как fastcgi без использования дополнительного кода (чужого или своего — не суть). Для php приложения не нужно ничего кроме самого php в такой ситуации.

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

Как во фреймворке могут учить? Фреймворк предоставляет возможности, как разработчик их использует — его дело. Я почему-то уверен, что мое приложение на рельсах будет отличаться от такого же моего на симфони только синтаксисом ну, или «костылями» если я не найду в рельсах возможностей, которые мне были доступны в симфони. Например, логика представления в представлении :)

мне два месяца хватило на то, чтобы понять, что с php-программистами я дел иметь не хочу.
UFO just landed and posted this here
ничо, в отличии от некоторых я руби и изнутри изучаю ;) (смотри мой профиль)
UFO just landed and posted this here
UFO just landed and posted this here
RoR, Sinatra/Padrino, Grape, Rack, EventMachine (мы же не ограничиваемся вэбом?), MacRuby, впрочем много их, но они все ненужны ибо есть RoR и Sinatra. Это в похапе каждый студент считает необходимым создать свой говно-фрэимворк и на нем создать свою CMS, в руби такой херни нет.
Потому что ruby (и многие другие языки) гораздо менее дружелюбен к вебу по сравнению с php. Разработчик веб-приложения стоит перед выбором: или использовать чужой код, или с нуля полностью реализовать HTTP-сервер (утрирую, но не сильно). А задача, например, отправка содержимого формы на мыло… Формально PHP является языком для более высокого уровня модели OSI, чем ruby/python. На PHP можно опуститься по уровням, а на ruby нужно подниматься.
Как раз ruby(точнее, rails и прочие фреймворки) более чем дружелюбны к вебу.
Встроенная поддержка актуальных трендов(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, и они умеет тратить время с умом — они не будет делать велосипед если он уже изобретен и устраивает.
Посмотрел www.ruby-doc.org/stdlib/ не нашёл там rack, максимум подходящее по-моему TCPServer, может и меньше 100 строк выйдет простейший HTTP/fastcgi сервер на нём написать.

Что плохого в смешивании в одном файле, если принцип 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?
Давайте сравнивать или язык с языком, или фреймворки/библиотеки с фреймворками/библиотеками? Возможно (не интересовался готовыми решениями), с учетом последних, ruby и одержит убедительную победу по скорости разработки, но я сторонник «php way» хотя бы при изучении — сначала пишем с нуля, потом по мере роста кодовой базы выделяем, следуя принципу DRY, фактически свой фреймворк и только затем начинаем сравнить свой «велосипед» с готовыми решениями и выбираем то ли внести в свой хорошие идеи из готовых, то ли переводить свои приложения на готовые. Желательно, чтобы для первого варианта были объективные причины, а не только тщеславие или нежелание разбираться с чужими.

В случае одного файла инклуды не в тему. Модель от контроллера и контроллер от представления отбиваются пустыми строками :)

Таки появился, можно даже на хабре найти как-то типа «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'

#