В защиту PHP

[IntenT]

Чего еще ожидать от интепретируемого языка, который начинался как шаблонизатор для Perl? (-:
Один очень большой плюс PHP — низкий порог входа.
Отсюда и его популярность.

Но откуда планктону знать, что хорошо, а что плохо, если хорошего они не видели, а если и видели — то не поняли? (-:

[nwalker]

Низкий порог входа — плюс?..

[khim]

Низкий порог входа плюс для тех, кого интересует «здесь и сейчас». В 90е годы языком, на котором работало большинство программистов был VisualBasic. Потому что на нём можно было что-то сваять не зная о программировании практически ничего. Сейчас одного такого языка нет, но PHP — одна из вещей, которая его заменила.

[nwalker]

Простите, а зачем нужны такие языки?

[khim]

Ну нужно же на чём-то делать сайты за $100?

[Pokoinik]

да, собстно, сайты за 100 000$ тоже на чем-то делать нужно..)))

[Bygaga]

Ага а вы заказчику раскажите что ваш сайт стоит 10 000$ вместо 1 000$ потому что он написан на языке высокого уровня, и ничем больше не отличается, и поддержка его ему будет обходится на 500 баксов/мес дороже по этойже причине… + сотрудника если захотите взять ему нужно будет платить 5000, а не 3000…

Но боже у вас же сайт будет на таком прекрасном языке!

Вот только половина сайтов на АСП лаганутые на столько насколько это можно…

PHP будет рулить пока скорость разработки и стоимость поддержки будет низкой.

А если у вас кривые руки то вам что грабли что лопата…

[Pokoinik]

я вообще-то имел ввиду, что на php можно решать задачи разного уровня сложности… от говносайта за 100$ до проекта который разрабатывается год и более…

[mlurker]

Согласен с последним высказыванием. Если руки кривые — любое будет лагать и работать через одно место.

Разница в цене разработки редко обуславливается используемым языком программирования. Судя по буржуйской статистике (http://www.indeed.com/), программисты Java получают в среднем 88к$ в год, .net — 82к$, php — 77к$. Думаю, у нас статистика похожая (по соотношению зарплат).

В бОльшей степени всё зависит от количества и качества реализованного функционала и качестве технических решений. Можно сделать говносайт за 100$ на asp.net, или трёхслойку с отличной расширяемостью и сопровождением за 10 000$ на php.

[IntenT]

мда, исправляюсь…
Для PHP — несомненно это плюс (-:

[nerezus]

Минус, т.к. поощряет «И так сойдет», что губительно для повторного использования, и в итоге как раз не сэкономит времени.

[romy4]

тогда интернет был бы другим и скорость его развития была бы намного меньше. Оно нам надо? надо поблагодарить PHP хотя бы за то, что мы сейчас имеем. И несомненно низкий порог входа в таком случае — это большой плюс.

[ExcimeR]

проблема быдлокода рождается от быдлокодеров а не от того что пхп такой плохой, на нём тоже можно красиво и грамотно писать.

[developer]

хорошо сказал

[Aux]

Выражается всё в том, что PHP развивается с помощью костылей. Сначала в четвёрке или около того появился костыль под названием «ООП». Ужасный костыль. За него надо было разрабов кастрировать и сжечь на костре. Потом этот костыль обрастили ещё кучей костылей и мы получили пятёрку с кучей глюков и вся эта костыльная структура была весьма шаткой. Сейчас её залепляют соплями и придумывают новый костыль — namespaces. Понимаете в чём дело, это не неймспейсы, а реально костыль. После Java, Delphi и ActionScript 3 все эти костыли от PHP вызывают лишь недоумение.

А потом будут ещё и ещё костыли. Нравится? Пользуйтесь! А для меня PHP навсегда останется шаблонизатором и ничем более.

[taliban]

1 — php5 использует ядро zend engine 2 в то время как php4 и ниже zend engine 1, ядро подверглось серьезным изменениям, а не подпоркам
2 — namespaces — не костыль, в паскале тоже их не было и в action script…

Вы говорите о тех вещах, о которых совершенно ничего не понимаете, или Вы — инженер-разработчик?

я тоже могу наговорить на С# много чего, допустим что только в .net 4 появились параметры поумолчанию, вот, это костыль? нет, это улучшение, такое же как и namespace в php

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

[Aux]

Во-первых, я не говорю глупости. Во-вторых, очень даже основательно.

В паскале есть более удобная альтернатива привычным неймспейсам — юниты. Они позволяют однозначно определить идентификатор. Улучшениям эта система подверглась как раз в ActionScript и Java, где появились пекеджи. По сути эти гибкая надстройка над юнитами.

Неймспейсы в PHP в данный момент весьма странны.

А насчёт нового движка Zend — его возможности в области ООП сейчас на уровне Turbo Pascal 7.0…

[Aux]

Абстракты и виртуалы были, файнал в той реализации не нужен был принципиально.

[bat]

static method?
Interface?
Exception?

[Aux]

Исключения не являются фишкой ООП. И собственно ООП реализация исключений самая кривая, так как не позволяет управлять выполнением кода.

Вместо интерфейсов были абстрактные и виртуальные обьекты.

Статичные методы в привычном нам виде в той реализации нужны не были. К тому же юниты можно было рассматривать как статичные классы со статикой внутри. Синглтоны тобишь.

Дело не в возможностях конкретной реализации, а в самой реализации. ООП в PHP до сих пор костыль. Возможно, в Zend Engine v9 это поправят, но, боюсь, мы не доживём до этого славного события.

[developer]

Troll detected

[taliban]

а в какой версии появились юниты Вы вкурсе? а до 7 версии их не было, можно ли в таком случае считать что в 7 версии сделали костыль в виде неймспейсов? а в action script тоже ведь небыло пакетов изначально, можно ли их считать костылями? думайте что говорите, не все так просто как кажется на первый взгляд… создатели пхп проделывают грандиозные меры для улучшения ядра и у них это получается, не стоит плевать на них только потому что Вам этот язык не нравится… мне вот Java не нравится, но я никогда не скажу что она ужасна, хотя и у нее есть свои недостатки

[Aux]

Дело не в том, когда что появилось, а в том, в каком виде что-то появилось. Первое появление ООП в PHP — это ужасный и кривой костыль над массивами. Чтобы двинуть ООП дальше ребятам пришлось переписать весь интерпретатор. Ниже уже написали, что это полный идиотизм от и до. И, самое главное, ООП всё-равно местами живёт на костылях! Хаха!

Неймспейсы посторяют этот опыт от и до.

У нерусских есть слово — consistency (целостность). Так вот, в PHP нифига нет целостности. Он весь выглядит сделанным из соплей и соплями склееным. Есть языки сложные, есть простые, есть удобные, а есть неочень. И только PHP — инвалид.

[Fortop]

А вам не стыдно издеваться над инвалидами?

Дайте им жить и умереть спокойно, не тыкайте в них пальцами на улице…

Или это у вас норма поведения? :)

[taliban]

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

[Aux]

Это не метод проб и ошибок, а отсутствие такой стадии разработки как проектирование. Если вы не хотите это понять, то мне вас жаль.

[Fortop]

И все же посмотрите на

CP/M -> DOS -> Windows

:) вам поподробнее с этого момомента? :)

[Aux]

Я не вижу связи между DOS и Windows. А CP/M -> DOS — это переименование.

[Fortop]

жаль что не видите :)
Учите историю.

[Aux]

сами поучите, чтоб глупостей не писать, оок?

[nileriver]

Не видите? Повтыкайте на real mode и костыльность WinME. Другой вопрос что NT разрабатывался тогда паралельно. Но и PHP5 разрабатывался параллельно добавлению костылей PHP4. И дай боже в 6ой версии костыльность неймспейсов и прочего будет переписана на новом уровне. Это и есть case. Вы просто видимо пеняя на отсутствие «стадии проектирования», не сталкивались с проектами со сроками поддержки от 10 лет. Я признаюсь тоже не сталкивался.

[Aux]

Учите историю, винда в инкарнации Win9x/NT происходит от OS/2, более ранние версии как и Win9x операционными системами не являются, это оболочки для DOS, такие же как Norton Commander, только более навороченные. По вашей логике NC тоже произошёл от DOS, но это бред. То что винда до NT костыль никто не спорит, но это не костыль для DOS. Да и что сравнивать костыли? Возьмите в пример нормальную ОСь изначально грамотно спроектированную, например, UNIX.

[nileriver]

Историю мне учить не надо я ее и так не плохо знаю. То что Win происходит от OS/2 — бред. Интерфейсные заимствования и многое многое было взято из OS/2 но, ядро — нет. А ОС это в первую очередь ядро.

Далее.

Win до 9X это костыль для DOS. Линейка Win9X это ОС. Но функциональна она заставляла затачиваться под DOS. Потмоу костыль. Как и в случае с PHP4.

Далее.

На тему грамотности и не грамотности проектирования прошу аргументы. POSIX от WinAPI отличается. И ядра отличаются. Но вы видели исходники ядер Win? %) Так как тогда судите от проектировании?

[Aux]

Win9x только Microsoft называет ОСью, на самом деле это оболочка с частично реализованным WinAPI, не более того. И это не костыль для DOS, это костыль имени Windows.

Знаете, я и исходников интерпретатора PHP не видел, а сужу по результату.

И ещё раз повторюсь — не надо сравнивать костыли, надо сравнивать костыль и грамотно спроектированное приложение.

[nileriver]

Закончен разговор… %)

[s5656]

Простите, но вы тупой.

Windows 9x — это ОС с ядром основаном на MS DOS, на сколько мне известно.
А вот Windows NT, XP итп — это ОС с ядром NT и от MS DOS там ничего нет (хотя есть некоторые сведения, что там до сих пор есть код, который работает с очень давних времен)

Оболочка для MS DOS — это Windows 3.11, например.

[majesty]

Кто мешает на Java накодить всё в main(), соорудив исходник на пару (сотен) мегабайт? :) Видимо lead developer, который за такое оторвёт йайтса? :) Потому что сам язык вполне себе позволяет использовать откровенно процедурный стиль или не использовать вообще никакого.

[Stormbringer]

Да сама Java не позволит. Согласно JVM Spec — 4.10 Limitations of the Java Virtual Machine, объём байт-кода в одном методе ограничен 65536 байтами и на этапе компиляции вылезет ошибка наподобие «The code of method main(String[]) is exceeding the 65535 bytes limit».
Кстати, соответсвующий баг-репорт датируется 1999 годом: bugs.sun.com/bugdatabase/view_bug.do?bug_id=4262078 :)

[chiaroscuro]

Довольно странно слышать утверждения, что Zend Engine «подвергся серьезным изменениям, а не подпоркам».

Все эти «серьезные изменения» говорят только о том, что авторы чего-то недосмотрели.

Взгляните на OCaml или GHC: и там, и там принцип работы компилятора не изменялся со времени создания (в одном случае — категориальная машина, в другом — STG). Для OCaml это около 15 лет, а для GHC больше 20-ти.

Если же смотреть на языковые фичи, то и тут все уныло: язык развивается медленно, и такие важные штуковины, как замыкания, добавляются в виде пришлепок сбоку.

Таким образом, товарищи из Zend просто несерьезные красноглазики. Простите, но это так.

[taliban]

да, я соглашусь что разработчики недосмотрели изначально (не предусматривали) реализацию ооп, но это ведь не значит что они его «подперли»! подперли они его в 4 версии, посмотрели что вышло говно и переписали все что пытались «накостылить»… и я уверенно могу сказать что реализация ооп в пхп5 соответствует стандартам (не другим языкам, а именно стандартам) я не буду меряться пиписькой с .net, java и python, да, я знаю что пхп их догоняет а не ставит стандарты, но это не значит что:
1 — «PHP развивается с помощью костылей»
2 — «костыль обрастили ещё кучей костылей и мы получили пятёрку с кучей глюков»
3 — «Сейчас её залепляют соплями и придумывают новый костыль — namespaces»

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

[chiaroscuro]

Вы немного не поняли то, что я хотел сказать.

Я говорил не о фишках языка, а о реализации интерпретатора.

Заметьте, что с каждой мажорной версией интерпретатор PHP подвергается переписыванию практически с нуля. Это говорит о том, что его авторы не умеют писать интерпретаторы, а точнее, плюют с высокой колокольни на опыт других людей.

Фишки языка, ООП и его необходимость — это немного другой разговор. Если хотите, можно поспорить и на эту тему, в PHP и дизайн языка хромает на обе ноги. ^_^

[taliban]

вообще-то я тоже о фишках языка не говорил… и я опровергну немного Ваши высказывания: «Заметьте, что с каждой мажорной версией интерпретатор PHP подвергается переписыванию практически с нуля» — это в корне не так, пхп «практически с нуля» переписывался только один раз — с 4 на 5 версии, и если вдруг Вы не в курсе, то пхп изначально разрабаывался как интерпритатор который может делать некоторые вставки в html код… такая вешь не может жить и разрабатываться вечно, трудно переделать визитку в портал… быть может 4 => 5 был именно этим шагом, отказаться от костылей, ради коструирования архитектуры…

и все таки интересно чем конкретно дизайн языка пхп хромает на обе ноги кроме как нестабильные параметры функций?

[chiaroscuro]

> это в корне не так, пхп «практически с нуля» переписывался только один раз — с 4 на 5 версии

Ага, а еще с 3-ей на 4-ую версии, также, как и с 5-й на 6-ую :)

> то пхп изначально разрабаывался как интерпритатор который может делать некоторые вставки в html код…

То есть, Вы хотели сказать, что PHP разрабатывался как продвинутый HTML-embedded DSL, который, при этом, совсем ничего не знает об HTML, кроме, пожалуй, его текстового синтаксиса. :)

Подумайте сами: язык для генерации HTML, который понятия не имеет о модели данных HTML (атрибутах, элементах), о правилах вложения элементов, и т.п.

> такая вешь не может жить и разрабатываться вечно, трудно переделать визитку в портал…

По-моему, Вы путаете понятия «интерпретатор PHP» и «программа, написанная на PHP».

> ради коструирования архитектуры…

Это гораздо проще делается: берутся умные книжки по дискретной математике, теории автоматов и вычислений, потом берутся еще книги, в этот раз по компиляторам и интерпретаторам. Все это внимательно вкуривается и пишется нормальный код, который потом не надо будет переписывать с нуля.

> чем конкретно дизайн языка пхп хромает на обе ноги

Всем. Это станет очевидно, если Вы посмотрите на другие языки программирования (например, Ruby, Scheme, Haskell).

Вы будете смеятся, но все языковые фичи PHP были доступны в Лиспе 40 еще лет назад. :)

[taliban]

«Ага, а еще с 3-ей на 4-ую версии, также, как и с 5-й на 6-ую :)» — это не правда :)
«язык для генерации HTML, который понятия не имеет о модели данных HTML» — вставка и изменение текущей странички html 2 разные вещи :)
«Это гораздо проще делается: берутся умные книжки по дискретной математике, теории автоматов и вычислений, потом берутся еще книги, в этот раз по компиляторам и интерпретаторам. Все это внимательно вкуривается и пишется нормальный код, который потом не надо будет переписывать с нуля.» — вы умный да?:) (считайте шуткой)
«Всем. Это станет очевидно, если Вы посмотрите на другие языки программирования (например, Ruby, Scheme, Haskell).» — я видел некоторые из этих языков, но не вижу в чем же конкретно дизайн языка пхп «хромает на обе ноги»

[chiaroscuro]

> вставка и изменение текущей странички html 2 разные вещи :)

(Мне кажется, что я со стенкой разговариваю.)

Генерация страницы имеет вид функции, которая принимает параметры (полученные из URI), и возвращает ответ (тут разное может быть: от plaintext, image/jpeg и заканчивая HTML) — по сути, последовательность байтов.

Ну так эту последовательность (если мы имеем дело с динамической генерацией, а не раздачей файлов) для начала неплохо было бы представить в виде, скажем, объектов (чтобы с ними было удобно работать). А потом уже как угодно сериализовать и тп.

«Вставка» (aka code embedding, я правильно понял?) и «изменение» (destructive update, Вы об этом?) это безусловно разные вещи, но я не об этом, перечитайте пост, пожалуйста.

Еще раз повторю: в PHP отсутствуют необходимые абстракции БД и HTML на уровне языка. Значит, он ничем не лучше, скажем, Педона. Фейл, следовательно. ^_^

> не вижу в чем же конкретно дизайн языка пхп «хромает на обе ноги»

Тогда посмотрите на них еще раз. :) (И не ждите от меня «конкретных примеров».)

[runcore]

по поводу БД вы ошибаетесь, мне кажется.
в Пхп5 же есть PDO (Php Data Objects), высокий уровень абстракции, биндинг и плейсхолдеры, поддержка кучи БД…

для HTML разметки, действительно похоже нет ничего нативного, но честно говоря оно и не нужно. так как Пхп все же работает на другом уровне, и ему нет необходимости знать чтото о Представлении. Он готовит данные а как смешать их пусть думает программер, напрямую или используя шаблонизатор, ведь это может быть не только Html, а как вы писали выше и xml, plaintext и даже binary data…
к томуже, за Html по хорошему отвечает отдельный человек -кодер. и Пхп-программисту вообще не нужно лезть в шаблоны )

[chiaroscuro]

> в Пхп5 же есть PDO (Php Data Objects), высокий уровень абстракции

А почему при таком «высоком уровне абстракции» программисты все еще пишут SQL-запросы в стиле «а я знаю, чо такое 'конкатенацыя строк!!!1'»?

В PHP надо было бы встроить возможность писать SQL-запросы прямо в язык (да-да, взял, и написал $rows = SELECT * FROM mytab WHERE myfield = 256). Где это?

> Он готовит данные а как смешать их пусть думает программер, напрямую или используя шаблонизатор

А Вы не замечали, что почти все шаблонизаторы, доступные для PHP, повторяют сам PHP? Этим они убивают свою полезность. Шаблон это не программа.

(Если хотите нормальный шаблонизатор, смотрите StringTemplate.)

[runcore]

>А почему при таком «высоком уровне абстракции» программисты все еще пишут SQL-запросы в стиле «а я знаю, чо такое 'конкатенацыя строк!!!1'»?
это проблемы тех программистов ) но не языка

>В PHP надо было бы встроить возможность писать SQL-запросы прямо в язык (да-да, взял, и написал $rows = SELECT * FROM mytab WHERE myfield = 256). Где это?
Одному захочется встроить в Пхп нативную работу с SQL, второй скажет Встройте туда еще работу со всем подмножеством SGML и т.д… Что это за монстр получится? и кому он будет нужен после этого… такой язык изначально выроет себе могилу.
Все нужно в меру. и модули в Пхп(да и в других языках) вполне нормальное решение.

[chiaroscuro]

> это проблемы тех программистов ) но не языка

Других способов-то и нету. Так что это проблема языка.

ORM не трогаем, это бесполезная абстракция.

> Одному захочется встроить в Пхп нативную работу с SQL, второй скажет Встройте туда еще работу со всем подмножеством SGML и т.д…

Ну-ка, быстренько раскуривать понятие «domain-specific language»! ^_^ PHP, чтобы стать нормальным, нужно одно из:

— embedded DSL'ы по работе с СУБД и шаблонами
— способы создать EDSL (для этого понадобятся кое-какие языковые фичи: замыкания, продолжения, каррирование, и т.п. Замыкания уже есть, ждем остального.)

Ни того, ни другого в PHP нету и не будет.

> Что это за монстр получится?

Все будет ништяком, если подключить мозг. :) PHP, кстати, уже монстр: у него есть смутная семантика, смутные авторы, и даже смутный синтаксис!

Смутная семантика — отсутствие какой-либо формальной модели, которая бы указывала, как и что должно работать (делается с помощью operational semantics, denotational semantics, etc).

Смутные авторы — это из-за их национальности :) (троллю, не удерживаюсь)

[runcore]

нужно? только Пхп?
Хотите сказать, у всех соседних языков множество ...DSL уже прекрасно реализовано?

насчет смутности местами — согласен. но подобные проблемы есть и у других языков. Та же Java, python, perl… мажорные версии теряют совместимость с предыдущими как раз потому что исправляются проблемы в архитектуре.

[chiaroscuro]

> Хотите сказать, у всех соседних языков множество ...DSL уже прекрасно реализовано?

Хаскель, как ни странно, подает надежды.

Из того, что смотрел, и что не понравилось:
— PHP (зоопарк инопланетных животных)
— Python (повальное ООП головного мозга)
— Scheme (полнейший разброд в связи с 50+ реализаций :))
— Ruby (рельсы как-то не впечатлили)

Есть еще Ur/Web (impredicative.com), довольно интересен.

> насчет смутности местами — согласен.

Ну, это еще мягко сказано. Например, любая программа, написанная в Standard ML, пройдя проверку типов, не уронит комп и не сожжет дом. :)

А все потому, что у SML есть формальная семантика. Три реализации, которые я смотрел (MLKit, SML/NJ, MLton) как-то не сильно различаются в поведении :) (исключая расширения языка)

[taliban]

> Из того, что смотрел, и что не понравилось:

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

=) бывает, просто непошло

[chiaroscuro]

Приведенная аналогия неверна.

И кстати да, бодибилдинг отстой, каратэ всех спасет! ^_^

[nileriver]

О.О абстракция? О.о надо бы вставить? В какой версии Java появились аннотации? О.о

[chiaroscuro]

Вообще ничего не понял.

Причем тут аннотации? Вы сходите по ссылке, почитайте. Не будьте ъ. %)

[nileriver]

Поскольку вы сначала говорили не о DSL а о наитивность работы с SQL. Наитивность например в J2ee максимальная это аннотации разве нет? =) И если говорить о DSL то с какого перпуга версия PHP4 должна была наитивно работать с SQL если в то время(старт разработки — 98) работа с SQL не была стандартом де факто для низкого ценового сегмента web-разработки.

[chiaroscuro]

> Наитивность например в J2ee максимальная это аннотации разве нет?

Я вообще не в курсе насчет J2EE. Мне оно не нравится, я в этом ковыряться не буду.

> И если говорить о DSL то с какого перпуга версия PHP4 должна была наитивно работать с SQL если в то время(старт разработки — 98) работа с SQL не была стандартом де факто для низкого ценового сегмента web-разработки.

А где пруфлинк? Даже если и не должна была, то это можно было бы пофиксить в следующей версии, но нет, не пофиксили. %)

И это, PHP это таки DSL, кривенький только, с претенизиями на «нечто большее», но он таки применяется только в вебе.

[nileriver]

EE — не малая часть web технологий java. Потому и приведен тут пример что «наитивная» работа с sql была реализована совсем недавно… а ваш пример?

DSL ли PHP на данный момент все таки спорный вопрос. =) И нужна ли наитивная работа с SQL или ORM средствами самого языка в PHP… Вопрос. Опять же. Если DSL — нужна. Если нет — нет. Для зыка общего назначения PHP медленн и слаб. И слишком не строг. Тут не поспорю… А выводы… Посмотрим. История покажет. Разработчики стремятся все таки не к DSL и это видно. И MVC фреймворки с ORM хорошего уровня на PHP уже написаны… Хоть и без аннотаций. %))

[chiaroscuro]

> а ваш пример?

Takusen. HDBC и HaskellDB.

Ur/Web (уже в третий раз в этом треде привожу, у PHPщиков слепота? :)) — impredicative.com

> И нужна ли наитивная работа с SQL или ORM средствами самого языка в PHP…

Матчасть. Ну почему же Вы ее так не любите?

Нативная работа с SQL нужна, да только у PHP-программистов ну очень слабое воображение, что они этого еще не осознали.

ORM это пустая трата времени, ибо потеря соответствия. Даже не обсуждается.

В PHP нет и не будет достаточных и необходимых условий для реализации DSEL. Точка.

> Для зыка общего назначения PHP медленн и слаб.

Не в этом дело. PHP ничем не лучше других, уже вовсю использующихся ЯП (тот же Педон с Руби).

> И MVC фреймворки с ORM хорошего уровня на PHP уже написаны…

Видывал эти фреймворки. Они жалкие и раздутые, но работают сравнительно неплохо.

[nileriver]

Ну во первых я не PHPщик… =) Я Явист. Потому мне достаточно сложно понять с э… «высоты» языка общего назначения, такую страсть к реализации нативного SQL в рамках языка. Но это так для контекста беседы.

Если говорить конкретно по приведенному.
HDBC — не наитивность. Ur/Web — боле интересно. Насколько я понимаю это что-то типа ORM(не обязательно «O» но маппинг) средствами встроенными в язык?

Теперь по поводу ORM и нужности. Безусловно для превращения PHP в чистый DSL ему нужна наитивная поддержка SQL и знания о представлениях. Но PHP развивается к вашему судя по всему сожалению не как DSL. Это факт. Тут тоже стоит точка.

Ну наличие фреймворков и даже то что они работают вы подтверждаете так? =) Соответственно в PHP плохо то что поддержка шаблонизации высокого уровня и наитивности работы с БД? Вообще я с этим согласен. Если бы разработчики PHP не хотели сделать язык общего назначения… %)

[chiaroscuro]

Ваша общительность просто бьет через край. :)

Сходите по ссылкам, почитайте, может, даже когда-нибудь придете к тем же выводам, что и я.

[nileriver]

Чем ближе пятница тем больше. %) А по ссылкам я ходил… Может быть мое мнение будет спорно, но изучать такие языки и технологии сродни тому что бы изучать embeded linux, или там ME для симбиана. Полезно. Интересно. Но узко. ) Хотя повторюсь это спорно.

[nileriver]

М… Вы тут правы. Но может вы согласитесь с тем что только с 5ой версии PHP можно вообще считать языком? =) Потому и переписывался с нуля собственно. Абстракция объектов была не нужна для шаблонизатора-темплейтора которым PHP по стуи долгое время являлся. Он сам по себе представлял эту функцию(точнее каждый .php Файл — отдельная функция).

[chiaroscuro]

> Абстракция объектов была не нужна для шаблонизатора-темплейтора которым PHP по стуи долгое время являлся.

Да, так оно и есть. Но это был кривой шаблонизатор. :)

Кстати, не вижу, как ООП помогает в вебе. Интерфейсы бы помогли, но наследование классов — это плохая идея.

[nileriver]

Наследование… Сложный вопрос. Наследование нужно тогда когда реализуется система имеющая большое количество объектов из реального мира со сложной структурой взаимодействия. А интернет вообще всю жизнь упрощал схемы взаимодействия и количество объектов. В этом плане вы конечно правы. Но.
1. PHP все таки язык не только для веба. В надеждах разработчиков как минимум.
2. Сложные системы будут появляться все чаще. Это факт. Тут языки подгоняют развитие веба и наоборот.

[chiaroscuro]

> PHP все таки язык не только для веба. В надеждах разработчиков как минимум.

Я надеюсь, что он никогда не вылезет из своей ниши. В нашей кунсткамере и так хватает разных уродцев. :)

[nileriver]

Уже вылезает потихоньку. И разработчики этого явно хотят. Во всяком случае GTK-поделки на PHP пишутся причем успешно. =) А уродцев… Unix-way. Я уже иногда и не понимаю какими мотивами руководствуются люди для выбора языка реализации какой либо gui-шной приблуды для опенсорса. По моему чисто программистскими предпочтениями. =) Тогда и пхп будет там… в том же пантеоне уродцев. %)

[chiaroscuro]

Умельцы GTK-шники уже смонстрячили свой йезыг, использующий «парадигму GObject»: Vala, кажись.

Так что поздно. Все пропало! %)

[nileriver]

Неа. Пропадет все когда пхп будет встраиваться как скриптовый язык в софт для windows. Вот тогда — пропадет. %)

[ExcimeR]

думаю любой язык разрешает написание «хренового кода». Kогда процент свех сайтов написанных на php будет существенно мал, я соглашусь что пхп умирает, а пока он цветёт и здравствует, взять тот же zend_framework который активно развиваеться.

[sgzmd]

Я не PHP кодер :-)

Но Flickr написан на PHP :) и работает, и вы знаете — неплохо ведь работает!

[kai]

Перл тоже умирает. А толку? =)

[DorBer]

Вот тут, например, govnokod.ru/ не только PHP, хотя его там и больше, но скорее всего это стоит отнести к популярности языка.

[easterism]

А чего ты так за минусы переживаешь? Не боись, мы тебя трогать не будем.

[taliban]

интересно, и чем же он приветствует написание кода? что можно в нем накодить такого ужасного чего нельзя накодить в других языках? приведите пример и я Вам постараюсь привести подбный код на .net или python…

[gaki]

Чё-та я не знаю, а у чего «высокий порог входа»? Lisp, Haskell & APL? :)

[kelvin]

Brainfuck =)

[MaksimMukharev]

assembler :-)

[MaksimMukharev]

Во всяком случае я точно не вошел… :)

[Aux]

А вы не в тот входили. Попробуйте асм для RISC16 — всё очень просто и понятно.

[Varnak]

Любой язык создается, что бы решать задачи, с какими то задачами справляется лучше с какими то хуже. Используй для нужной задачи нужный язык.
5 лет занимаюсь пхп, до и парллельно приходилось писать на плюсах, делфи, шарпее и асме…
Практически всегда приходилось сопровождать чужую разработку, открою страшный сикрет судя по всему планктон не весь в пхп, потому как говна и не умения работы с языком прослеживались практически везде.

[khizhaster]

Замечательный подход! Просто отличный!
«Я плотно работал с ним в течение 8 лет и пользовался рекурсией от силы 4 или 5 раз»
«тогда я не думаю, что это важно для меня»
и т.д.

То есть, вы на основании своих личных убеждений судите о качестве языка! Супер ;) «Мне не нада, значит никому не нада и написан бред» :)

P.S. Простите, но тема на хабре разжевана и обсуждена в куче топиков, а по большей части в комментариях к темам. Даже знатные холиварщики только лениво дергаются по этой теме ;)

[IntenT]

Поддерживаю, кстати. Аргументации защиты просто беспомощна.

[Angerslave]

Думаю, тут просто столкнулись теоретик и практик.

[IntenT]

в таком случае теоретик тот, кто говорит — «Я плотно работал с ним в течение 8 лет и пользовался рекурсией от силы 4 или 5 раз»

[khim]

Он практик. Много вы видели «программистов», рисовавших 10 лет формочки в Visual Basic'е и пользовавшихся при этом рекурсией? Вот. А сейчас этот контингент программирует на PHP.

[Fortop]

А встроенными функциями сортировки? Религия не позволяет пользоваться? :)

[Sannis]

Сортировку нельзя написать без рекурсии? Ни разу не слышал :)

[chiaroscuro]

Быстрая сортировка неотъемлемо рекурсивна.

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

Если даже убрать использование стека вызовов, все равно придется написать свой, лисапедный. Рекурсию тут не уберешь, и точка.

[no_smoking]

У меня не один из проектов не обошёлся без рекурсивных алгоритмов. Так что говоря что рекурсия не так уж и важна он либо теоретик либо не умеет ее готовить :)

[serega011]

Если ни один ваш проект не обошелся без рекурсии — это говорит лишь о вас как о неопытном программисте либо программисте упертом на рекурсии, т.к. рекурсия — зло(пользя одна — повышается скорость разрабортки) и если бы вы учились на программиста вам бы еще во время учебыб ы вдолюили что любой рекурсии можно избежать.

[no_smoking]

А я не спорю что ее нельзя избежать. Просто некоторые некоторые задачи лучше решить быстрее дешевле будет. А вот если важна скорость тогда да нужно разворачивать в цикл. Кстате если вы такой опытный программист скажыти как в xslt построить дерево(не ограниченое) не используя рекурсию буду вам признателен, да если вы не в курсе там переменные не могут менять свое значение :).

[FatalErr]

Не все рекурсивные алгоритмы можно развернуть в цикл :) (в основном так называемую «хвостовую рекурсию»). Однако, как некоторые здесь замечали, от любой рекурсии можно избавиться, заменив автоматическое использование стека явным (например, самописным на массиве).

[FatalErr]

Опять-таки, большой вопрос, повысит ли это производительность (зависит и от задачи, и от программиста, да и от языка программирования).

[no_smoking]

вот пример генерации json в зависимости от типа объекта nacmnogo.ru/jsonview.txt посмотрел бы я как вы бы тоже самое повторили бы без рекурсии при этом сохранилась понятность и структурированность кода

[pdev]

По приведённой вами ссылке вместо header('Content-Type: text/plane') вероятно должно было бы быть text/plain :)

[w0lf]

Приведите решение задачи обхода дерева без рекурсии, ну дерева каталогов к примеру.
p.s. меня учили на программиста 5 лет, я надеюсь у меня были не самые плохие преподаватели, и нам никто никогда не говорил что рекурсия — зло. Да она кушает ресурсы, да в некоторых случаях рекурсивные алгоритмы могут зацикливаться. Но замены им в ряде задач увы нет.

[kvf77]

Ряд задач не есть глобальная потребность.

[w0lf]

Никто и не говорит про глобальную потребность. Это всего лишь инструмент, плохой ли, хороший ли — но он есть, и грех им не воспользоваться, когда он упрощает решение задачи.

[kvf77]

Так я и не спорил, тут просто ставится вопрос, что прямо скорость рекурсий в PHP создает глобальную проблему. я же говорю, что потребность в рекурсии незначительна, чтобы биться с оптимизацией ее скорости.

[FloppyFormator]

Дерево можно обойти без рекурсии. Достаточно использовать стек и хранить в нём необходимые данные (указатель на текущий узел etc). Собственно, то же самое происходит при рекурсивном обходе, но при этом совершается ещё много лишних действий.

[chiaroscuro]

Можно, но зачем?

Давайте будем выполнять свою работу. А интерпретатор будет выполнять свою.

И кстати, дерево можно уложить в массив, юзать skip pointers, бороться за каждый бит… Но это даст ощутимый результат, только если вы пишете, скажем, риал-тайм рейтрейсер.

[Aivean]

Примерно вот так:

function rec($el)
{
   process($el);
   foreach($el->childs as $child)
     rec($child);
}

function non_rec($root)
{
   $stack = new Stack();
   $stack->push($root);
   while(!$stack->empty())
   {
      $el = $stack->pop();
      process($el);
      foreach ($el->childs as $child)
        $stack->push($child);
   }
}

Длиннее чуть-чуть выходит, но в некоторых задачах (при наличии дополнительных условий обхода) подобная реализация может оказаться и короче и очевиднее и лучше.

[chiaroscuro]

Очевиднее? Не смешите мои тапочки. :)

Вы заменили функцию из трех строк на функцию из семи.

Пишите лучше сразу на брейнфаке, раз такой аскетизьм исповедуете.

[no_smoking]

А чем простите здесь лучше при рекурсии также создается стек хранятся предыдущии значения но делается на более низком уровне те быстрее. Вы счас реализовали подобие рекурсии.

[bat]

DirectoryIterator — без рекурсии на PHP

[bat]

поправлюсь — RecursiveDirectoryIterator

[yuretsz]

Recursive в названии не наталкивает на мысль?

[bat]

Обсуждалась проблема производительности рекурсии на PHP… А SPL — это расширение, написанное на C.

[runcore]

без рекурсии такое прекрасно решается с помощью Итераторов.
вот ПРИМЕРНО накидал.
общий принцип думаю станет понятен.

function getAllFiles( $dir_start ){
	$dirs = $files = array();
	$dirs[] = $dir_start;
	while (sizeof($dirs)>0) {
		$k=array_keys($dirs);
		$dir = new DirectoryIterator( $dirs[$k[0]] );
		foreach( $dir as $f ) {
			$fn = $f->getFilename();
			if (!in_array($fn, array('.','..'))) {
				if (is_dir($fn)) $dirs[] = $dir_start.'/'.$fn;
				else $files[] = $fn;
			}
		}
		unset($dirs[$k[0]]);
	}
	return $files;
}
$files = getAllFiles("C:/");

[chiaroscuro]

Берегите пальцы, они еще пригодятся. :) Если я сейчас напишу решение на Хаскеле, вам станет стыдно за свою многословность (меньше кода = меньше багов, к тому же).

Это, кстати, еще называется преждевременной оптимизацией.

Корень всех зол, как-никак.

[tenshi]

lurkmore.ru/Haskell

[chiaroscuro]

А что я там должен прочитать? Пример факториала на комбинаторах? :)

[FloppyFormator]

Эта оптимизация уже вполне себе своевременная. Задачу обхода дерева решали миллион раз.

[chiaroscuro]

Пинайте разработчиков PHP. Если они не могут даже написать нормальный интерпретатор, то…

Еще раз спрашиваю: СКОЛЬКО данных у вас там? Триллионы записей? Может, вы рейтрейсер на ПХП пишете?

Что за «аптимизацыя»??? Если уж совсем тормозит — пользуйте Си и не парьте свою голову.

[runcore]

причем здесь Хаскел? был вопрос о том что без рекурсии нельзя обойти дерево каталогов. я привел принцип одного из решений. о оптимизации речи небыло. на Питоне тоже можно написать компактнее ) но это уже холивар начинается…

[runcore]

а при желании и на пхп можно меньше пальцы нагружать)

function getFilelist( $dir0 ) {
	$f = $d = array();
	$d[] = $dir0;
	while (sizeof($d)>0) {
		$l = glob( array_shift($d).'*' );
		foreach( $l as $n ) is_dir($n) ? $d[]=$n.'/' : $f[]=$n;
	}
	return $f;
}

[chiaroscuro]

Мысль в том, что обходить дерево каталогов без рекурсии есть извращение, раз, и преждевременная оптимизация, два.

«Можно», «можно». Все можно. Можно, например, замутить интерпретатор лямбда-исчисления, используя систему типов Хиндли-Милнера с некоторыми расширениями.

Можно, но нафига?

[runcore]

как это нафига?
Чтобы был выбор! ЧТоб решая задачу делать не «как все», а как необходимо для решения каждой конкретной задачи. Если заранее известно что вложенность будет небольшая то рекурсия отличный выход, а если алгоритм будет оперировать с неизвестной глубиной дерева да еще и есть основания предположить что глубина все же будет Очень большой, то есть смысл обезопасить себя от Stack overflow и написать без рекурсии.
Разминка для ума опять-же)
Так что это совсем не извращение) а один из способов развития мышления)

Давайте обещанный обход дерева директорий на Хаскеле, без рекурсии или с ней!
тоже хотел бы взглянуть, так как с Хаскелом еще не работал толком.

[chiaroscuro]

> если алгоритм будет оперировать с неизвестной глубиной дерева да еще и есть основания предположить что глубина все же будет Очень большой, то есть смысл обезопасить себя от Stack overflow и написать без рекурсии.

Так это, без рекурсии его не сделаешь. А если заменить стек вызовов на самописный то это только отодвигает агонию. %)

> Давайте обещанный обход дерева директорий на Хаскеле, без рекурсии или с ней!

Только что запостил, чуть ниже :)

[runcore]

>Так это, без рекурсии его не сделаешь. А если заменить стек вызовов на самописный то это только отодвигает агонию. %)

Исчерпать Стек и исчерпать оперативку — разные вещи, и Агония при этом отодвигается ОЧЕНЬ далеко )

[chiaroscuro]

> Исчерпать Стек и исчерпать оперативку — разные вещи, и Агония при этом отодвигается ОЧЕНЬ далеко )

Проверьте сами, что уж тут. Все не так страшно, как кажется.

[chiaroscuro]

Принимайте:

import Control.Monad (forM)
import System.Directory (doesDirectoryExist, getDirectoryContents)
import System.FilePath ((</>))

listFiles :: FilePath -> IO [FilePath]
listFiles top = getDirectoryContents top >>=
return. map (top </>). filter (`notElem` [".",".."]) >>=
mapM (\x -> doesDirectoryExist x >>=
\dir -> if dir then listFiles x else return [x]) >>=
return. concat

Собственно, это оно. Причем в обычной записи, чтобы было видно, что же такое «императив». :) (Наверное, сейчас «хабропарсер» съест отступ, эх.)

PS эта задача, кстати, не очень хорошо решается на Хаскеле (IO слишком «ленивый» там), но тем не менее, в интересах науки… ^_^

[runcore]

прикольно.
Хотя я ждал более лаконичный код)

[chiaroscuro]

О да, IO это не самое лучшее в Хацкеле (а тут этого IO чуть больше, чем полностью). :)

[runcore]

а что чаще всего на нем пишут?
а то у меня складывается впечатление что во многом он схож с Питоном.

[chiaroscuro]

Интерпретаторы, компиляторы, ИИ, обработку естественных языков, а также совсем гикнутые вещи («Haskell is a playground for advanced type trickery.»)

На Hackage [1] можно посмотреть доступные библиотеки и приложения (это что-то типа PEAR/CPAN), и станет понятно, для чего используют (кроме разных исследований).

[1] hackage.haskell.org/packages/archive/pkg-list.html

[runcore]

сенкс. почитаю

[cloud]

$info= `ls -R $dirName`;

[runcore]

а если код будет работать не в *nix?

[cloud]

if (PHP_OS=='WINNT') throw new mustDieException();

Если мы исходим из того, что нам надо все люто оптимизировать, то можно пожертвовать частью совместимостью, или сделать версию с рекурсией для windows, вообще, я не видел серьезных проектов на php, которые крутились бы под windows => если у нас не nix, значит это denwer и на оптимизацию этого случая можно и забить

[runcore]

я просто о том, что по возможности, если мы пишем код на языке А, то и оперировать мы должны сущностями и возможностями языка А.
тогда у нас будет совместимость и работоспособность кода на всех поддерживаемых им платформах.

> if (PHP_OS=='WINNT') throw new mustDieException();
Если заказчик хочет, то его проект будет крутится и на винде и на любой платформе которую он только придумает. Он платит деньги и «Хочет» — а разработчик должен сделать чтобы код работал )

[gaki]

Да почти всего можно избежать: например, функций, циклов, например lurkmore.ru/%D0%98%D0%BD%D0%B4%D1%83%D1%81
(см. про «китайский код») :)

[okopok]

нука, накидайте мне тут десяток примеров на живом сайте, где используется рекурсия =)

[ainu]

Моя домашняя страничка, вот пример. Шаблонизатор шаблонизирует шаблон, получает подстранички (например, список чего-либо, шаблонизирует их, вызывая функцию шаблонизирования в самой себе). Это позволяет засовывать отдельные странички (например, сформированный список новостей, с вою очередь, сформировный из подробной новости, сшаблонизированной для каждой строки) в другие страницы. Рекурсия.

[okopok]

отлично! :) Здесь у нас конечно главным тормозом является рекурсия, а не бесконечные реквайры :) И это уже целых 4 рекусрии…
шаблоны
поиск
директории
хмл
=)

[bat]

Хотя бы с десяток рекурсивных вызовов шаблонизатора наберется?
Шаблонизатор не та задача и не тот масштаб, где скорость рекурсивных вызовов играет роль.

[FloppyFormator]

Шаблонизатор шаблонизирует шаблон

Шаблонизаторы шаблонизировали-шаблонизировали шаблоны, да не вышаблонизировали :)

[y0ga]

Шесть шустреньких шепелявеньких шаблонизатора шаблонизировали шаблонизаторами шаблон

[no_smoking]

Вам прям нужен десяток :). Например меню, карта сайта, иерархический каталог, а вы пробывали реализовывать волновой алгоритм поиска пути без рекурсии еще тот гемор, а иногда так хочется чтобы mysql поддерживал рекурсию а так приходится делать много запросов место одного.

[okopok]

то что мускул не поддерживает рекурсии — это проблема мускула
волновой алгоритм поиска — красиво, но на реальных проектах встречается как медведь в московском лесу. И рекурсия без рекурсии — нет так уж и сложно сделать

[no_smoking]

У нас на Урале медведей больше значит :)
> И рекурсия без рекурсии — нет так уж и сложно сделать
можно, а нужно? Скорость веб приложение в больше всего зависит от структуры базы и качественных запросов а от рекурсии не такое уж и падение производительности. А то что написание рекурсивного кода сэкономит х отябы 15 минут уже хорошо.

[okopok]

Вы сами написали «алгоритм поиска пути без рекурсии еще тот гемор», на что я и ответил, что не шибко большой гемор ;-)

[no_smoking]

Но все таки гемор но для этого процесса все таки лучше помучатся и сделать без рекурсии, а то уж очень ресурсоемкий процесс :)

[DorBer]

Nested sets вам помогут. Тут им самое место: обновлений мало, а считываний много.

[no_smoking]

А каким местом рекурсия и структура базы к друг другу относятся. Всему свое место. Но насчет Nested sets я у себя в голове заметочку сделал :)

[DorBer]

Дело в том, что при использовании nestes sets выбирается полный путь страницы одним запросом. Ну и вообще любые ветви любых деревьев. Doctrine, например, уже имеет поддержку nested sets и позволяет прозрачно работать с деревьями.

[no_smoking]

Ну есть ведь и другии задачи которые проще решить рекурсии а иногда вставка куда важнее выборки а представьте как отсортировать такую структуру. В общем вы меня не убедили что рекурсия это зло.

[DorBer]

Так я и не доказывал :D Ничего против рекурсии не имею
Решил просто инфой поделиться. Для хорошего человека не жалко ;)

[Aivean]

Волновой алгоритм основывается на поиске в ширину, который, в свою очередь основывается на очереди, а не на стеке, как рекурсия! Так что то, что вы писали, было каким-то другим алгоритмом и вполне могло быть гемором.
И ещё я чуть выше написал, как можно обойти дерево без рекурсии, со стеком. Если два вас это гемор, то какие вы вообще задачи привыкли решать?

[chiaroscuro]

(Немного матана не помешает, ящитаю.)

Дерево — это структура рекурсивная.

Функции, определенные над деревьями, таким образом, повторяют его структуру (определяются с помощью структурной индукции).

Таким образом, даже если алгоритм основывается на очереди, а не на стеке, он все равно рекурсивен. ЧТД.

[no_smoking]

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

[ainu]

Хлебные крошки.
Функция ВывестиРодительскийкаталог (ТекущийКаталог)
{
Если есть(Родительский каталог(ТекущийКаталог))
ВывестиРодительскийкаталог((Родительский каталог(ТекущийКаталог));
Вывести ТекущийКаталог;
}
P.S. Я понимаю, что это довольно долгий алгоритм.

[okopok]

обход директорий… об этом автор ещё говорил

[ainu]

Не директории. Каталоги (родительские страницы)
Например:
Форум программистов -> Новости -> Обновления -> Новогодняя 2.0 -> Комментарии.

[okopok]

рекурсивная выборка данных из базы… опять же… сортировка по мускулу и проход одним циклом

[no_smoking]

интересно как вы так от сортируете записи если они относятся как родитель и ребенок через поле parent_id

[okopok]

order by parent_id asc, id asc
а далее ассоциативный массив собрать дело двух милисекунд :)

[no_smoking]

а если дочерний элемент был добавлен после родительского?

[okopok]

я показал только начальную сортировку, дальше в ордер в можете запихнуть ещё много чего, плюс ещё данные могут сортироваться дополнительно при запихивании данных пхп и при выводе ;-)

[no_smoking]

И все это против пяти вложенных функций смешно.

[okopok]

в крайнем случае можно джоин таблицы самой на себя сделать

[no_smoking]

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

[okopok]

в большинстве случаев хватает сортировки и цикла… но я не говорю, что всегда это возможно ;-) Я не спорю, что рекурсия нужна, но это не «панацея» ;-)

[no_smoking]

А кто говорить, что панацея. Тут было сказана, что зачем оптимизировать выполнение рекурсии она ведь не так нужна. Хотя самые ресурсоёмкии операции как раз и делают с помощью рекурсии. Так почему бы ее не оптимизировать. Если она будет выполнятся не на много медленее чем без рекурсивные методы. Тогда рекурсия будет более востребована.

[okopok]

согласен

[ainu]

Объект | свойство | значение
-------+----------+-------------
Сыночек| Родитель | Папочка
Дочка | Родитель | Папочка
Папочка| Родитель | Дедушка


[tenshi]

www.codenet.ru/db/other/trees/index.php

[no_smoking]

Думал что-то новое предложите :( Ну все сходится к структуре базы данных а не к рекурсии. Есть структуры которые быстрее выводить, есть те что быстро модифицируется что применять зависит от задачи. Для комментариев например нужно чтобы они быстро редактировались выводятся они все равно разом. А вот для меню сайта быстрое редактирование не нужно хотя он и по размеру не такое, как правило, большое поэтому без разницы можно обойтись и более простой структурой.

[bat]

Для меню нет необходимости каждый раз лазить в БД

[Cellard]

Лучший способ избежать рекурсии при построении дерева из таблицы — это хранить дерево в упорядоченном виде.

Вот в такое же дерево комментариев, в которое мы сейчас пишем, я на своём проекте добавляю новую запись двумя запросами, извлекаю все дерево одним запросом и отображаю без дополнительных сортировок.

[no_smoking]

Я в принципе делаю похоже только вставляю одним запросом и делаю выборку одним запросом а вот строю дерево на xslt рекурсивно.

[kvf77]

Используйте Nested Sets и никаких рекурсий.

[no_smoking]

А вам не кажется что там проблемы со вставкой, удалением, переносом узлов. Да и для отображения дерева все рано нужно использовать какой то алгоритм оп хода дерева(рекурсию например).

[kvf77]

Nested Sets используйте — все давно придумано. Выводить большое дерево рекурсией — это извращение.

[no_smoking]

А как вы думает скоко займет времени вставить узел в центр таково дерева. Так что это зависит от целей. Да и сложность реализации таково дерева на порядок больше. Вот например для комментариев на хабре такая структура явно не подходит.

[kvf77]

А как часто вы вставляете узел в дерево относительно количества запросов на выборку и, соответственно, в вашем случае рекурсий на его вывод? Вы занимаетесь софистикой. И, раскрою вам большой секрет, если правильно хранить дерево Nested и правильно сделать индексы, то на дереве до 10000 узлов вы не заметите никаких отличий при вставке относительно вашего алгоритма.

[no_smoking]

Судя по текущему холевару несколько раз в минуту :)

[chiaroscuro]

«Вложенные множества» тоже рекурсивная структура ^_^

[kvf77]

Оно не требует рекурсии при выводе дерева — именно эта операция для деревьев является самой востребованной.

[chiaroscuro]

Мне интересно посмотреть, как можно работать с рекурсивной структурой, не используя рекурсию.

Объясните, пожалуйста.

[kvf77]

Объясните мне пожалуйста, где вы увидели рекурсию при выводе дерева, хранящегося в Nested Sets?

[chiaroscuro]

ПоRTFM'ил по вопросу. Извращенное, но неплохое моделирование дерева в RDBMS.

Засчитывайте слив :)

[kvf77]

Повторяю вопрос — где конретно рекурсия в PHP при выводе дерева из Nested Sets? Пример конретно кода.

[no_smoking]

ну получили вы таким запросом
SELECT id, name, level FROM my_tree WHERE left_key <= $left_key AND right_key >= $right_key AND level = $level + 1 ORDER BY left_key

поддерево но его еще ведь надо вывести на игран вот так
• Узел 1
• • Узел 3
• • • Узел 7
• • • • Узел 12
• • • • Узел 13
• • • • Узел 14

[no_smoking]

на *экран конечно

[tenshi]

level тебе в помощь

[no_smoking]

какой левый или правый? :) или нужно еще переменную добавить.

[kvf77]

Ты путаешь LEFT — RIGHT с LEVEL
во всех практический современных реализациях классов есть еще вспомогательное поле LEVEL в таблице. если судить по приведенному тобой запросу — в твоей таблице оно тоже есть

[no_smoking]

запрос не мой я его скопировал вот от сюда www.codenet.ru/db/other/trees/index.php както не посмотрел что возвращается. Ну все таки нарисовать точки в цикле это одно а вот построить html список это другое это в цикле прейдется добавлять лишнии условия я всеж предпочитаю рекурсию меньше путаницы

[tenshi]

и чем тебе тут поможет рекурсия? бд возвращает плоский список и чтобы воспользоваться рекурсией тебе нужно развернуть список в дерево. и какая тогда разница разворачивать список в дерево массивов или же сразу в дерево html-элементов?

[no_smoking]

Ну я мня то с этим проблем нет у меня шаблонизатор на xslt и на нем линейный список легко с помощью рекурсии превращается в древовидный список.

[tenshi]

и с не меньшей лёгкостью упирается в ограничение на глубину рекурсии и объём потребляемой памяти.

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

[no_smoking]

Ну это не повод отказываться от рекурсии вообще. А ограничение в рекурсии нужно для того чтобы не образовался бесконечный цикл. А если у вам не хватает то значит это вам не подходит. А на xslt некоторые вещи просто невозможно реализовать без рекурсии там нет переменных.

[tenshi]

это не достоинство рекурсии, а недостаток хслт. то, что в императивных языках решается просто и элегантно в нём реализуется через анус…

[kvf77]

У вас там еще много высосаных из пальца проблем? Вы пишите, пишите, мы разберемся.

[no_smoking]

Там это где. Улыбнуло.

[kvf77]

Level тебе для чего даден?

[chiaroscuro]

Рекурсия там все равно есть, просто немного скрыта за счет того, что вложенность выражается неявно (с помощью интервалов).

[kvf77]

Да, даже если ее там нет, мы найдем и внедрим!

[chiaroscuro]

Эх, Вы только подтверждаете стереотип о программистах PHP…

[ainu]

Я тот самый контингент, некоторое время назад программировавший на VB, да и сейчас он установлен, пользую, чтобы написать за 20 минут утилитку, которую не удалось найти.
И сейчас я программирую на PHP. И пользуюсь рекурсией, мой текущий проект весь основан на огромной рекурсии одной функции.
Да, я не занимаюсь производством высокопроизводительных систем. Но я знаю, что такое рекурсия, кеширование, и т.д.
И задумываться о том, что PHP может быть медленным, начал после активного чтения хабра. Но на практике этого почти не чувствовал. Медленно работает? Правлю код, делаю его проще.
Может, я неправильно понимаю этот мир, или чего-то недопонимаю, но мне хватает php c головой (пока хватает).
И вообще, в уусловиях локалки общежития я както делал сайт на Visual Basic, в виде CGI приложения, и работал он нормально. И там тоже была рекурсия.
Минусуйте.

[runcore]

читая ваши сообщение, складывается впечатление что вы любую задачу решаете через рекурсию )
я уже давно работаю с Php, и применял рекурсию только несколько раз: работа с поддиректориями, xml…
в остальных случаях прекрасно можно решать задачи без неё…

[okopok]

ну не всегда, но в целом верно, что рекурсия очень редко по делу применяется

[okopok]

в пхп

[ainu]

Чтото я тоже перечитал свои сообщения и подумал, что чтото я слишком часто упоминаю о ней.=)
Но в последних двух достаточно сложных проектах (тоесть include(«header.php»); не является сложным проектом) она использовалась.
А в целом вы правы. Чтото тут развязывается война. Надо быть проще.
На сайтах — визитках за 100$ (1000$) не нужна рекурсия. Там вообще ничего обычно не нужно.
Может, в самом деле я неправильно работаю?
Рекурсивно делаю крошки, делаю дерево сайта (список подстраниц, тамже список их подстраниц), страницу, на которой есть и крошки и дерево сайта, и список страниц (и то, и другое, и третье делается одной функцией).
Аналогично список форумов/разделов/топиков в развёрнутом виде.
Наверное я заработался.

[chiaroscuro]

Все нормально делаете.

Программы ведь для людей пишутся. :) Рекурсия и ФВП спасают жизни. Если будет тормозить — перепишете на явные циклы, делов-то.

[nerezus]

Какой он нахрен практик, если столько раз рекурсией пользовался?
Мне за последние 2 месяца она больше раз требовалась на 3 проектах.

[Angerslave]

Я сам «использовал рекурсию» в абсолютном понимании больше раз, но если функция сама себя вызывает пару раз, я не считаю это такой уж рекурсией. Вот когда весь алгоритм на этом построен, это да.

[Angerslave]

Он не говорит, что «значит никому не надо», он говорит, что это не так уж и важно, хотя его оппонент утверждает, что это чуть ли не первостепенной важности проблема.

[bat]

Все должно быть к месту.

P.S.
Оно таки в PHP осталось, но передавать по ссылке или нет решается при объявлении, а не при вызове. И это правильно.

[DYPA]

>Моя IDE с автоподстановкой и php.net всегда под рукой.
только еще в этой ide нужно знать бить str или str_

>Изменения в языке зачастую становятся известны за месяцы, а то и годы до их реализации. Для перехода от 4 к 5 существует migration guide в котором описаны все различия.
но при этом при введении namespace больше всего ора было про «простоту использования»
например мне понравился довод что \ просто нажимать на латинской раскладке
но больше всего мне нравиться цитата из оффициального фак на вики

Q: Why was “\” chosen given that it makes it impossible to write something like “spl_autoload_register(array(“myNamespace\theLoader”, “load”));” because the \t would be interpreted as a tab?

A: It is already impossible to write Windows paths in PHP in the same way, ergo at least half the PHP community is already familiar with the idea that they need to either use single quotation marks or escape the backslash (“\\”).

ps я боюсь что версия номер 6 является заветной для «веб языков», поживем увидим

ссылки
wiki.php.net/doc/scratchpad/namespacefaq
wiki.php.net/rfc/namespaceseparator

[developer]

я пропустил момент, но щас прочита — прикольно на самом деле. аргумент не маловажный. Кстати исторически именно поэтому одинарные ковычки не экранированы, чтоб проще было писать струкрутно

[developer]

переведите пожалуйста:

Q: C++ uses ”::” for namespaces, why did the PHP internals developers feel they needed to solve the ambiguity issues rather than leaving it to each developer to prevent ambiguity between namespace names and other identifiers?

A: Ambiguity is an edge case, meaning that developers wouldn't necessarily be aware of the potential for it through their own past experience, and debugging would be extremely difficult. Further, there was no way to provide a PHP error message on ambiguity without impacting performance in all cases. [Reference needed]

[Angerslave]

Мда, помимо того, что тут столкнулись теоретик и практик, тут скорее столкнулись пессимист и оптимист — один говорит, что не стоит юзать PHP из-за его недостатков, другой — что стоит юзать из-за его достоинств.

В любом случае, я с ними обоими согласен и несогласен поровну, PHP далеко не самый выдающийся, продуманный и всё такое, что не мешает ему занимать свою немаленькую нишу.

[nerezus]

Просто когда про недостатки пытаются сказать «это фичи» — то это ОЧЕНЬ подозрительно %)

[Angerslave]

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

[bat]

Как там у Макаревича

И двое сошлись не страх а на совесть…
…
И каждый пошел своею дорогой
А поезд пошел своей

[x0rHamster]

Убило «PHP поощряет (практически требует) смешивание логики и представления». PHP: Hypertext Preprocessor (а не Web-Based App Creator) был создан именно для вставки его частей в код. ИМХО, вывод из этого — раз язык позволяет выполнять то, для чего он изначально создан, то он отвратителен.

[dime]

Да, в общем-то, если именно про создание, то даже не PHP: Hypertext Preprocessor, а вовсе и Personal Home Page Form Interpreter. Собственно, в качестве интерпретатора форм домашних страничек он почти идеален :), но используется-то он сейчас не по назначению. И вот с точки зрения использования его не по назначению, эта «фича» — отвратительна. Как-то так :)

[khim]

Изменения в языке зачастую становятся известны за месяцы, а то и годы до их реализации.

Так должно быть. А как на практике? А вот как:
1. Выпускается изменение в bug-fix релизе, которое ломает кучу скриптов.
2. Никаких упоминаний об изменении в release notes нету.
3. Реакция разработчиков "Fix your scripts! We do not care, the fix on our part was needed!" — испытал лично на своей шкуре.
Извините, но это не называется существует migration guide в котором описаны все различия. Это называется «что хочу — то и ворочу». Я после этой перебранки отказался от PHP в новых проектах совсем, а в старых — настолько, насколько позволило время, но судя по многочисленным сообщения на различных сайтах ничего в позиции разработчиков не изменилось с тех пор…

[developer]

а вы пишите код не на хаках — все работать и будет замечательно. Я писал скрипты еще на 4-ке и на 5.1 и ничего, все работает до сих пор. При этом не могу сказать что у меня там все просто.
Ну вот стоит перед вами выбор писать наподобие:
preg_replace("/(<\/?)(\w+)([^>]*>)/e", "'\\1'.strtoupper('\\2').'\\3'", $html_body);
или использовать preg_replace_callback. так выберите второе — вас потомки добрым словом вспомнят.
таких примеров масса. Следуйте рекомендациям «хорошего» кода и 90% проблем изчезнет.
ну а то что PHP зависим от расширений, так это понятно, но не является минусом потому что в обновления и релизы включаются только стабильные версии, косяки очень редки и оперативно фиксятся

[khim]

А вы пишите код не на хаках — все работать и будет замечательно.

Перевод с русского на русский: язык — дерьмо, но и на нём можно сделать неплохую вещь. Да, можно, но зачем?

Есть такое понятие software regressions (характерно что русская Википедия его аналога не содержит). Любое неописанное изменение в работе языка относится именно сюда. Иногда изменения в язык вводят специально (скажем gcc 3.4 не принимает многих программ, которые принимал gcc 3.3 ибо более строго проверяет соответствие правилам языка, а python 3.0 и вообще изрядно непохож на python 2.x), но
1. Это должно быть описано в release notes.
2. Это ни в коем случае недопустимо в минорной версии, тем более включающей в себя security fix'ы и потому рекомендуемой к установке «немедленно».
3. Если Q&A просмотрел проблему из пункта 2, то должна быть немедленно выпущена следующая минорная версия, которая «возвращает всё как было».
Поведение разработчиков PHP можно оценить только как «100% неадекват» c лечением «не использовать PHP — никогда и ни для чего».

таких примеров масса. Следуйте рекомендациям «хорошего» кода и 90% проблем изчезнет.

Знаете — это напоминает примерно следующую рекламу:
Купите дом — с отличной лужайкой перед домом! Мягкая трава — вашим детям понравится! Правда в среднем через каждый метр там противотанковая мина закопана, но вы не беспокойтесь — у нас есть буклет и там нарисованы места, где мин точно нет. Ну а в других местах ходите осторожнее: мины противотанковые, срабатывают не каждый раз — может быть и пронесёт.
Кому нафиг нужна такая лужайка?

[developer]

вы убежденный фанатик — отказываюсь в таком ключе с вами разговаривать.
если вы опустились до фраз: «язык — дерьмо», то очевидно что вы просто холиварщик.

[maximw]

Мне нравится ПХП, но с автором статьи во много не согласен.

Имхо:

1) С именованием функций у PHP плохо. Хотелось бы мигрировать на на более строгое именование функций, последовательность параметров и т.д. Впрочем, сторонние библиотеки лишены этого недостатка.

2) Отказ от передачи по ссылке, имхо, большое упущение. Разумеется, можно сделать все и без передачи по ссылке, но на кой черт обрабатывая рекурсивно большой многомерный массив я должен плодить в памяти его копии?
А новичек «ногу прострелит» и без этого — см след. пункт

3) Полный «фрилав и лигалайз» в отношении приведения типов. Из массива сделать инт — да запросто. Вот это действительно не «прострел ноги», а целая «противопехотная мина».

4) Функции не чувствительны к регистру — и слава богу. Может потому что я не люблю нотацию типа MyBestFunc, и потому что не люблю запоминать какие именно буквы там большие (это же парит в яваскрипте).

5) О смешении логики и представления в контексте языка вообще речи быть не может. Этот вопрос возникает в контексте конкретной среды где используется язык. PHP это же не только веб.

6) Да понятие «производительность языка» какое-то абсурдное. Производительность может быть у интерпретатора, у исполняемого файла, в зависимости от того что за компилятор его собирал. Так что производительность это не проблема языка, это проблема конкретной реализации его интерпретатора.

[alek_sys]

Я уже который раз слышу «РНР — это не только веб».
А можно пример — где еще активно используется РНР? В принципе, ничего толкового для standalone приложений там нет.

[okopok]

В моей конторе делали систему организации, обработки и хранинения музыки на PHP

[alek_sys]

Если не коммерческая тайна — можно чуть подробнее. Что из себя представляла система? Что значит организация и обработка? Что использовалось для создания GUI? Как решили проблему отсутствия нормальной работы с потоками? Я так понимаю, система была — клиент-сервер?

[okopok]

Система обработки музыки…
Например приезжал винчестер набитый музыкой с торрентов.
Нужно было выбрать только ту музыку, которая подходит по формату и которой не было в базе данных. Аккуратно рассортировать это всё по папочкам на сервере, обработать напильником теги и залить всю инфу о музыке в базу, для работы модераторов. Не спорю, что можно было много процессов написать на С, но всё, кроме конвертора было написано на чистой Пехе. Проект жив до сих пор

[okopok]

И кстати, очень успешен :)

[alek_sys]

Да, весомо :) Убедили

[sys]

Санек, не пали контору

[okopok]

О! И ты тут :)
Имён не называю :)

[maximw]

Применение языков программирования не ограничивается только веб- и десктопными (я думаю, Вы их имеете ввиду под standalone) приложениями.
У меня, например, много скриптов делающих те или иные функции (обрабока БД, резервное копирование и т.д.), запускаемые вручную или по крону. PHP это же в первую очередь скриптовый язык.

[alek_sys]

Я прекрасно понимаю, что не ограничивается.
Но одно дело — когда вы пишете скрипт, который облегчает лично вам жизнь. Другое — когда на языке ведется разработка какого-то продукта. Вот тут и начинается беда у РНР. Работает команда — а в языке ни модулей нормальных, ни пространств имен, а только мусор из функций.

А кроме веб-приложений и десктоп есть, разумеется, огромный сегмент Enterprise — различные ERP системы, CRM и иже с ними. Но уж к ним РНР на пушечный выстрел не подпускают.

Embedded-приложения? Ну интерпретатор Питона для Windows CE я видел — а РНР есть?

Различные высоконагруженные приложения по обработке данных? Тут тоже РНР делать нечего (как, впрочем, всем скриптовым языкам :) ).

Так что есть определенная ниша — веб-приложения. В ней РНР твердо стоит на двух ногах и вытолкать его оттуда еще долго не получится. Но и выглядывает он оттуда очень редко.

[okopok]

Лёха?

[maximw]

В написанном с Вами трудно не согласиться. Но Вы тут же сами говорите «PHP не только веб» :) Пхп хороший, добротный скриптовый язык.

[chiaroscuro]

А чем он лучше других скриптовых языков? Вот в чем вопрос!

ЗЫ конечно, имеется в виду его ниша не в области веба

[developer]

ну кстати модули вам может заменить грамотные внутренние соглашения именований, и в ближайшее время они будут введены.

[lasc]

для winCE есть hph

[developer]

я писал систему складского учета в интранет.
а так самый популярный пример PHP My ADMIN вы же не будете утверждать, что управление БД это чисто сетевая задача? Хотя эти примеры именно работают под интернет серверами.
Есть множественные примеры когда мой знакомый админ писал всякие скрипты настройки / управления / профилактики на PHP потому что как он говорит это понятнее чем ПЕрл

[yorick_kiev_ua]

Ага, только MyAdmin — это програмка, для «зайти по http(бо иначе никак не выходит) и по-быстрячку что-то поправить ручками или запустить скрипт».

Никогда не видел, что-бы для разработки БД исспользовали phpMyAdmin… Ну разве что в древности, бо у угрёбища по названию mySql был выбор: или с командной строки или этот самый МайАдмин.

В общем выдаёте нужду за добродетель.

[kurokikaze]

PHP одобрен эволюцией — значит, хорошего в нём таки больше чем плохого.

[khim]

PHP не одобрен эволюцией. Это подёнка. Такая же как Cobol и Visul Basic. Лет через 5-10 и он отомрёт тоже, а миллионы быдлокодеров найдут себе очередную игрушку, которая якобы позволяет программировать тому, кто ничего о CS не знает.

P.S. И как и в случае с другими подёнками останутся хорошо оплачиваемые рабочие места по поддержке всего этого безобразия… и даже небольшой количество приличных проектов, созданных на нём не благодаря, а вопреки свойствам этого убожества…

[kurokikaze]

Время покажет.

[bsdemon]

Не переубедили — совсем наоборот :) язык неважнецкий

[Pokoinik]

Очередно холивар, блин почему так сложно принять, что каждый пользуется тем, что больше нравится…
нравиться пхп пользуйтесь… не нравится… вбивайте статику через блокнот, пишите на асп, яве, да хоть на ассемблере… зачем раздувать религиозные войны????

[azizoid]

Польностью с Вами согласен. Если бы каждый занимался своим делом, то на написание такой бесполехной статьб времени не было бы…

[Pokoinik]

рор, это не язык программирования — это фреймворк, написанный на ruby…
на пхп тоже реализованна туева хуча фрейворков: Zend Framework, симфони и тп…
www.google.com/search?hl=ru&client=opera&rls=ru&hs=zpZ&sa=X&oi=spell&resnum=0&ct=result&cd=1&q=php+framework&spell=1

[Pokoinik]

гугл скетчап, qt-ruby, для десктопных приложений, скриптов коммандной строки, у него масса применений и рельсы это только малая часть…

[kronos]

Например у меня в курсовике: plasmon.rghost.ru/66976.image

[antage]

Я только сегодня написал на ruby нужный мне апплет для gnome.

[antage]

Вы спросили где используется руби без рельс — я ответил. Не понял вашего возражения. Вы хотите знать где используется руби без рельс в веб-разработке? Пожалуйста: Merb, Sinatra, Camping, Mack и т.п. + Capistrano, Starling, Puppet и куча других полезных инструментов на руби, очень нужных при веб разработке.

[tenshi]

1. ИДЕ упрощают написание кода, но не его чтение.
2. возможность написания «спагетти» — это самый главный недостаток языка. ибо кроме того кода, который пишешь ты, есть много больше когда, написанного друими, с которым тебе тоже рано или позно придётся иметь дело.
3. передачу по ссылке никто не отменял. более того — объекты теперь по умолчанию передаются именно по ней. всё как у взрослых! ;-)
4. рекурсия — зло. конечные автоматы рулят.

[khizhaster]

Про 4-й пункт это вы, например, функциональным языкам расскажите. :) Кроме того, есть множество задач, где рекурсия лучший выбор.

[tenshi]

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

[no_smoking]

Все завесит от того что больше нужно большая скорость выполнения или большая скорость разработки. За частую проще и быстрее сделать рекурсию но на вызов функций тратится лишнее время. Но вот как то нужно было на флеше as2 сделать одну задачу так с помощью рекурсии она делалась очень просто, но во флеше ограничение на глубину вложенности :(, пришлось делать сыклами так я блин целый день провозился.

[Stepanow]

Мне пришлось переписывать админку одного интернет-магазина потому, что разработчики пошли по лёгкому пути рекурсии. Когда ассортимент вырос и счёт пошёл на десятки тысяч, скрипт вывода дерева товаров банально упёрся во время выполнения. Переписал без рекурсии — скорость выросла в десятки раз. При этом данный програмный продукт продолжает успешно продаваться. Пихание рекурсии куда попало, чтобы ускорить разработку, не думая о последствиях — это и есть быдлокодинг.

[no_smoking]

Нет это называется оптимизация. С начало пишеш чтобы быстрее написать(не забывая о правильном и масштабируемом коде ) а потом оптемизируеш критические места. Не у всех ведь такой а сортимент по этому это частный случай. И вы уверены что дело было в рекурсии вызова функций а не в большом количестве запросов к базе в этих функциях.

[Mikeprosoft]

Это был OSC, не так ли? ;)

[tenshi]

пример, где рекурсия выглядит проще.

[chiaroscuro]

fact 0 = 1
fact x = x * fact (x-1)

Ваш черед. Напишите факториал, используя циклы и побочные эффекты.

[pandy]

хм… у вас в примере псевдокод. Если уж сравнивать решения — то уж и пишите тогда честно — на PHP (вроде о нем же речь). И тогда когда получите ответный код на том же PHP без рекурсии — будем смотреть, что проще :)

[chiaroscuro]

Я тут заметил наезды на рекурсию в веб-разработке, а не в PHP. Может, я ошибаюсь.

Кстати, приведенный «псеводокод» это Хаскель. И этот код можно запустить, он работает. :)

[pandy]

Вы считаете факториалы в веб-разработке? О_о Хотел бы я посмотреть на такие сайты, где это нужно :)

[chiaroscuro]

Ну это же всего лишь пример!

А в веб-разработке я пользую свертку списка (точнее, ее обобщение, используемое в Takusen). Эта штука невозбранно рулит.

[pandy]

Про пример понятно, это была шутка. Просто речь шла об очевидности. То что вы написали — да, вполне очевидно. Но как вы сами указали — на Хаскель (не знаю этого языка, хотя написанная вами конструкция вполне понятна, что и вызвало у меня аллюзию на псевдокод, сорри если оскорбил хаскелистов :) ). Мой спич был несколько о другом: обсуждается PHP и не факт, что рекурсия написанная на нем будет очевидней аналогичного кода на циклах. В случае рекурсии:

function fact($n)
{
return ($n==0)? 1: $n*fact($n-1);
}

и цикла

function fact($n)
{
for ($i=2,$fact=1;$i<=$n;$i++) $fact*=$i;
return $fact;
}

да, первый вариант может и очевидней. Но это в случае расчета факториала. Но в вебе то факториалы ни к чему. Если взять что то более сложное с несколькими условиями выхода — можно получить куда более нечитаемый и сложный для поддержки вариант. И именно поэтому я поднял вопрос про реализацию… Может хаскель вообще заточен исключительно под рекурсии, что они на нем так красиво и просто смотрятся :)

[chiaroscuro]

> Но в вебе то факториалы ни к чему.

Это, кстати, не так. Факториал нужен. :)

> Если взять что то более сложное с несколькими условиями выхода — можно получить куда более нечитаемый и сложный для поддержки вариант.

Рекурсия проще цикла, причем, используя замыкания + ФВП, ее можно спрятать и получить много профита. Если бы это было не так, скриптовые языки не прикручивали бы эти фичи :)

Пример с несколькими условиями выхода в студию!

[bat]

Этот как раз тот пример, где циклом проще.

[chiaroscuro]

Проще? Циклы завсегда сложнее рекурсии.

[tenshi]

( 1… x ).inject( 1 ){ | res, numb | res * numb }

или

reduce( lambda x, y: x * y, xrange( 1, x ) )

при этом мой код будет работать сколь угодно долго, а твой — довольно быстро упрётся в ограничение на глубину рекурсии в каком-нибудь xslt.

[no_smoking]

интересно как вы такое в xslt повторите

[tenshi]

будет много кода…

[chiaroscuro]

Ну тогда сразу вот так:

fact x = product [1..x]

> reduce( lambda x, y: x * y, xrange( 1, x ) )

Списку, порождаемому xrange() нужно куда-то влезать. Памяти много нуно, ибо xrange вычисляется сразу и полностью (за счет строгости Петона).

> а твой — довольно быстро упрётся в ограничение на глубину рекурсии в каком-нибудь xslt.

Это уже другой вопрос. Я хорошо показал, что рекурсия проще цикла в этом отдельно взятом случае, ящитаю.

[tenshi]

или вот так:
( 1… x ).product
=)

xrange порождает не список, а итератор

[chiaroscuro]

> xrange порождает не список, а итератор

ну да и фиг с ним, я не питонист, простите мое невежество :)

Главное ведь, что с помощью рекурсии проще. ^_^

[tenshi]

«факториал х — это произведение чисел от 1 до х»
«факториал х — это произведение x на факториал x-1, но факториал 0 равен 1»

какое из этих определений проще? а если вспомнить, например, числа фибоначчи?

человеку куда проще оперировать состоянием, чем вычислять функции.

[chiaroscuro]

> какое из этих определений проще?

Второе, потому что оно прямиком из учебника математики.

> а если вспомнить, например, числа фибоначчи?

Это второй классический пример рекурсии :)

> человеку куда проще оперировать состоянием, чем вычислять функции.

Математика показывает обратное (все-таки математике пара тыщщщ лет, а программированию всего с полсотни).

Это компу с фон-неймановской архитектурой проще оперировать состоянием, а мы говорим о людях. Не надо становиться живым компилятором. :)

Да и потом, чтобы вычислять математицкие функции, нужно уметь только подставлять, этому учат еще в школе. А чтобы считать как комп, нужно шаманить. :)

[tenshi]

рекурсивное определение? в школьном учебнике? ну-ну…

факториал вводится в виде списка (через многоточие). а рекурсивная формула рассматривается лишь как свойство факториала

аналогично и с числами фибоначчи — они вводятся в виде итеративного алгоритма (получение следующего числа по двум предыдущим), а не рекурсивного (получение числа n по числам n-1 и n-2 с ограничением, что первые два числа фибоначчи равны 1)

[chiaroscuro]

> рекурсивное определение? в школьном учебнике? ну-ну…

Я об этом не говорил, не фантазируй :)

Наверное, не те учебники читал…

[tenshi]

нет, просто не хочешь видеть дуализма определений — математически точные определения человек явно или неявно преобразует в свои «интуитивные», которые не используют рекурсию, ибо размер стэка у человека много меньше, чем у машин фон-неймана.

[chiaroscuro]

> математически точные определения человек явно или неявно преобразует в свои «интуитивные»

Ну а где пруф? Факториал все равно рекурсивен, явно или нет.

Или вот другой пример, с возведением в степень:

f(0,x) = 1
f(1,x) = x
f(n,x) = x*f(n-1,x)

ЗЫ от темы разговора что-то далеко ушли: засчитываю за слив.

[runcore]

ваши проекты без вычисления рекурсии не работают? ))

[chiaroscuro]

Текущие не работают. Вы меня поймали :)

[nikitad]

У всех известных мне языков с императивной семантикой проблемы с рекурсией. Поэтому если она так сильно нужна — следует подумать о каком-нибудь функциональном языке, Haskell например.
К которому, кстати, активно присматриваются разработчики Unreal Engine.

[tenshi]

а у рекурсии проблемы с современной архитектурой компов. может ну её эту рекурсию вместе с тормозным анрилом?

[nikitad]

Не получиться. Как заставить среднестатистического быдлокодера разворачивать рекурсию в цикл?

[tenshi]

при первом же повторном входе (без выхода) в одну и ту же функцию — падать с ошибкой. мигом научатся ;-)

[nikitad]

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

[tenshi]

да ладно =) свёртки списков и деревьев вполне себе читаемы.

[nikitad]

Это частный случай. В общем случае удаляя рекурсию мы лишаемся мощного средства абстракции.

[chiaroscuro]

У современных компов нету проблем с рекурсией.

Все проблемы — они в головах людей.

[TimTowdy]

В то время когда создавался PHP, это был действительно хороший язык. Он позволял быстро и легко создавать динамические веб-странички, обладая минимальными познаниями в программировании, в отличие от того же перла. Именно это и обеспечило его популярность. Это же обеспечило и огромное количество быдлокодеров. Некоторые быдлокодеры почитали умные книжки, перестали писать говнокод, и подарили миру более-менее качественные PHP-фреймворки, которые позволяют создавать что-то более сложное чем домашние странички.
Но даже если использовать PHP-фреймворки, вы все равно будете писать на PHP. А все перечисленные в статье недостатки можно описать одним словом — этом дизайн языка. И у PHP он действительно ужасен. Сейчас не 1994 год — не хотите писать на перле, берите Python или ROR. Раньше сравнивая языки программирования люди сравнивали их функциональность, теперь же, когда функциональность современных динамических ЯП практически одинакова, имеет смысл сравнивать их дизайн. Посмотрите на import this в пайтоне — есть ли что-то подобное в PHP? PHP был создан для облегчения создания домашних страничек — Personal Home Page, этим и определяется его дизайн.
Умные люди не пишут кластеры на Visual Basic'e, GUI-приложения на Фортране, а сложные веб-приложения на PHP. Даже если язык и позволяет это сделать.
А то что разработчики PHP продают к нему акселератор — это полный маразм. Зачем пользоваться языком, разработчики которого заинтересованы в его тормознутости?

[pandy]

> Умные люди не пишут кластеры на Visual Basic'e, GUI-приложения на Фортране, а сложные веб-приложения на PHP
Это вы зря… Когда дело доходит до бизнеса, а в 99.9% всех случаев когда что то программируется — это — бизнес, бизнесмен решает — на что вложить деньги. И выбирает не то, что мегаправильно и красиво, а то, что позволит получить продукт быстро. Куча стартапов пишется на чем? На PHP! Потому что стоимость разработки — маленькая по сравнению с теми же Java или C#, Ruby и т.д, и есть масса специалистов, наработаны решения по устранению узких мест в виде кеширования и кластеризации. И все это почти даром. Да, когда идет речь о программировании Just for Fun — то да, там народ все делает от души и красиво. И не на PHP. Но рассматривать язык только как дизайн — это подход разработчика, но не бизнесмена.

[nikitad]

> Когда дело доходит до бизнеса, а в 99.9% всех случаев когда что то программируется — это — бизнес, бизнесмен решает — на что вложить деньги. И выбирает не то, что мегаправильно и красиво, а то, что позволит получить продукт быстро.

Это смотря что понимается под продуктом. Одно дело — относительно простенький сайтик, совсем другое — OLAP или экспертная система. Быстро написать подобное на PHP или Visual Basic не получиться — они слишком ограничены для этого. И PHP, и VB следует воспринимать как DSL, а не пихать их куда только можно, ибо они изначально не планировались как языки общего назначения.

> Потому что стоимость разработки — маленькая по сравнению с теми же Java или C#, Ruby и т.д,

Они хороши для своих задач.

> наработаны решения по устранению узких мест в виде кеширования и кластеризации.

Не представляю себе кластеризацию на PHP. Речь идет о веб-сервере?
Для параллельных вычислений есть специализированные языки, в сравнении с которыми PHP смотрится бледно.

> И не на PHP.

PHP — для относительно простеньких страничек, если задача серьезная — надо выбирать другие инструменты, иначе в конечном счете запаришься отстегивать купоны на поддержку разросшегося кода и покупку новых и новых серверов.

> Но рассматривать язык только как дизайн — это подход разработчика, но не бизнесмена.

Если язык в начале проекта выбран неправильно (т.е. его дизайн и возможности не в полной мере соответствуют задаче), накладные расходы по мере развития проекта будут увеличиваться, и рано и поздно настанет момент, когда все придется переписывать на другом языке.

[esc]

А как тогда объяснить существование больших проектов на пхп с огромным количеством задействованных узлов под колоссальной нагрузкой? facebook, vkontakte итд? Понятно, что быдлокода количество просто огромное. Но может дело все-же в неумении пользоваться инструментом?

[nikitad]

Фейсбук и вконтакте — это относительно простые странички: никаких замудреных алгоритмов там не используется, логика — примитивна. Все, что нужно — докупать сервера для кластера.

[esc]

>>Не представляю себе кластеризацию на PHP. Речь идет о веб-сервере?
вот на это скорее ответ.

По поводу простоты страниц, да, они простые. Когда ими пользуются 1000 человек. А когда миллион или десять миллионов в онлайне, то алгоритмы там несколько отличаются. Как минимум middleware для шардинга уже будет далеко не простым. Не говоря уже о многоуровневом кешировании и фишках типа «друзья в онлайне» для миллиона юзеров на сайте.
Как видите, при правильном подходе и правильных программистах, никаких проблем с кластеризацией и масштабируемостью и пхп нет.

[nikitad]

Речь не про то. Речь о выразительных способностях языка и области его применения. Могучие системы никто не пишет целиком на C. Критичные к производительности — не пишут на Джаве. Сложную логику в больших приложениях — на ПХП. Важно знать что требуется и выбирать инструмент(ы) исходя из задач.
Алгоритмы там принципиально отличаться не могут: те же «друзья в онлайне» есть выборка из отображения первого порядка, которое рассчитывается определенным образом. Тут нужно просто минимизировать запросы к базе данных: входит человек на сайт — надо где-нибудь сохранить (не в БД) этот факт, чтобы в последствии отобразить его друзьям этого человека с списке «онлайн». Если минимизировать запросы к БД и прикрутить систему кеширования, то ПХП спокойно будет генерить странички для миллионов людей, только оперативку и быстрые харды подноси. Ну и про канал не забыть.

[nikitad]

Каждой задаче — свой инструмент.

[Psih]

Жуткий быдлокод народ пишет даже на C/C++, Java и Delphi — не смотря на всю их строгость. Порой доходит до такого маразма, что PHP и не снилось. 90% — ошибка в ДНК, а не в том, что PHP плохой или хороший — он просто есть, он просто работает и, как было уже отмечено, в хороших руках практически не глючит и ничего не рушится от обновления (а глюки можно поиметь где угодго — чего стоят эпопеи с компилированием одного и того же кода на том же C++ под разными компиляторами и порой разной реализацией конкретных вещей, т.к. в спецификации написано «реализацию оставляем на совести разработчиков компиляторов», что приводит к глюкам)

[Psih]

Я о том, что правильная ДНК позволяет программисту писать код, который нормально скомпилируется на большинстве компиляторов (ну бывают случаи полной несовместимости) — хотя я считаю маразмом то, что под каждый компилятор приходится подстраиваться.

[Psih]

Потому что быстро и удобно. При прямых руках на PHP практически любой WEB проект делается быстрее всего.

[runcore]

Многие в комментариях называют пхп-кодеров = быдло-кодерами, и типа они незная ничего лучше и из-за низкого порога вхождения пишут именно на ПХП… на собственном примере знаю что это не так.
Программист должен эволюционировать!
Я начинал с Perl.
Когда познакомился с Php и оценил его плюсы и быстроту разработки, пересел на него.
Сейчас наслаждаюсь Java, Jsp…
Далее смотрю в сторону Python.

Все это я говорю к тому, что для решения задачи надо выбирать язык который решит её наиболее качественно и быстро. И у Php тут есть своя ниша и задачи которые он решает очень хорошо.
Перечисленные в статье минусы — конечно являются частью Php, но мне например они никогда особо не мешали. Тем более что пока язык развивается есть вероятность что проблем этих станет значительно меньше.

Идеального языка я пока не встретил. В любом языке можно найти места которые лучше реализованы у языка конкурента…

[merkator]

Интересный подход, сначала Perl, Php, потом наслаждаетесь Java, смотрите в сторону Python. Будто бы свободный художник. Можно позавидовать! :)

А что делать, если на работе основные проекты, которые приходится поддерживать и развитать — на Php, большинство хостингов тоже рассчитаны на php, да и количество пхп-вакансий гораздо больше, чем «не-быдло» Ruby и Python.

Возможно я был бы заинтересован в переходе к более совершенному и удобному языку, но как это осуществить? Создавая проекты для себя? Посоветуйте, пожалуйста.

[runcore]

Конечно по работе приходится поддерживать и дописывать проекты реализованные определенных языках и технологиях. Но когда начинаем новый проект, то иногда есть основания привести аргументы в пользу перехода на чтото другое. Если это будет эффективнее и быстрее или легче в поддержке или другие какието плюсы обнаруживаются.
Главное чтобы начальник или Team-лидер был адекватным и не был зациклен на одной технологии. Мне пока везло с такими людьми. А когда попадались консерваторы и фанатики — я с ними расставался ))

Ну а для своих проектов тем более, выбираю что душе угодно. Благо сейчас есть выбор — любую задачу можно решить кучей способов.

[merkator]

Если начинать проект на малознакомом на практике хоть и перспективном языке появляются риски по возможному увеличению срока разработки в связи с потенциальными проблемами в решении некоторых задач, которые могут оказаться специфичны для данного языка. Как вы решаете данную проблему?

Я таким образом, по своей инициативе, осваивал ASP.NET, создавая для компании интранет, в итоге, при освоении оказалось много подводных камней, обойти которые потребовалось гораздо больше времени, чем я рассчитывал. Хотя сама технология .NET мне нравится, она мне показалась более перспективной и продуманной, но пока Php для меня все еще легче и удобнее, то есть на нем я быстрее решу задачу.

[runcore]

Первый блин иногда бывает комом )
НО!
Во-первых, кардинальных отличий не так много. Принцип построения и работы веб-приложений очень схожи, какой бы язык вы не выбрали.
Во-вторых, решая появившиеся проблемы, значительно повышается скилл, который, опять же, помогает далее.
В-третьих, сейчас столько документации, примеров и успешных реализаций на любой технологии, что все проблемы достаточно быстро решаются.
В-четвертых, я говорил о том что решение использовать в проекте новую технологию, принимается не «от балды» а если есть потенциальные плюсы от этого, или если использование другой технологии вызовет необходимость в изобретении костылей и т.д.

Например, на Java пришлось делать первый проект, потому что у заказчика уже крутилось много чего на Java. И даже несмотря на то что на Php я бы сделал проект менее чем за месяц, я все же не стал навязывать заказчику использовать Php. А предупредил его, что делать буду на Java, но чуть дольше ). в Итоге заказчик согласился подождать подольше, и получил сайт на Java через 2 месяца )

[merkator]

Все понятно, спасибо. Хотел узнать как у других, вы мне дали чуть больше уверенности! :)

[khizhaster]

Что-то мне подсказывает, то все знакомство ваше очень поверхностно. Если бы не только начинали, а и хорошенько поработали с Perl, то пересели бы вы сразу на Python, если пересаживались бы, а от одного взгляда на пхп вас бы невыносимо тошнило.
Ну и подход тоже знатный. «Лучшие места у конкурента» :) Может быть стоит быть этим конкурентом? И не только знакомиться с языками, но и изучать их глубоко?

[Kirk]

Я начинал с Delphi, программировал на нем около 2х лет, и уже больше полугода программирую на Php. У меня есть опыт разработки скриптовых языков программирования и скажу Php не самый медленный язык среди интерпретируемых, я проводил тесты. Если сравнивать его с Lua (самым быстрым), то отношения скорости примерно такое: Lua — 6 сек :: Php — 9 сек.

А то что писали про чувствительность к регистру, говорите это разработчикам Си, они ввели такую моду, а потом подхватили Java и другие си подобные языки.

P.S. Да действительно, когда программируешь в Delphi язык тебя воспитывает, и когда программируешь на PHP ты как беспризорник, должен сам себя воспитывать, иначе станешь быдлокодером.

[developer]

вот не пойму за что минусуют человека? за то что он на PHP перешел? товарищи ПХПешники! давайте выравляем положение!

[Kirk]

наверно я что то не то сказал про Си :)

[MpaK999]

«Функции нечувствительны к регистру.»
это он о чем? Про именование функций, переменных и т.п. или же что функции работающие с параметрам нечувствительны к регистру? Второе это бред, preg_replace ключь i, а первое, так это лучше, так как нет подобия стандартов, кто-то любит как я писать в формате гну си get_this_gun, кто-то get_This_Gun (getThisGun), это была бы каша если пришлось бы придерживаться всех стилей, библиотеки которые ты используешь в проекте

[AxisPod]

PHP имеет противоречивое именование системных и библиотечных функций. Предсказуемые схемы именования имеют важное значение в любом языке.

В этом больша проблема, постоянно требует отвлечение на документацию, а полноценную IDE для мелких правок я не использую, да и часто именование параметров не дает информации о том, что требуется туда передать.

PHP разработчики постоянно отказываются от встроенных функций и низкоуровневой функциональности. Наглядным примером является отказ от возможности передачи в функцию параметров по ссылке.

Я не заметил ничего хорошего в отказе, новичок будет учиться и поймет, что да к чему. А вот возвращать результаты в стиле Объект или false, возвращать массивы и т.д., вот это действительно криво, потому-что переходя с других языков непонятки, а при переходе на другие проблемы, потому что это вносит неточности в описание функций.

Чрезмерное применение пребразования типов приводит к ошибкам. У меня нет проблем с преобразованием, скажем, float в int и обратно. Но PHP (когда я последний раз проверял) с радостью попробует преобразовать массив в целое.

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

Производительность PHP ужасна без кэширования. Скажите, кто-нибудь продаёт коммерческий продукт кэширования для PHP? Ах да, это делают сами разработчики PHP.

Конкретно про скорость ничего не скажу, тот же ASP.NET например умеет кэшировать сразу, для PHP есть и бесплатные продукты, для кэширование скомпилированного кода. Но как то давно, уже точно не вспомню, вроде как PHP 4, 5-й версии еще не было, в документации было сравнение производительности PHP с другими языками программирования, где разработчики как то пытались показать, что PHP шустее Perl, Pyton, C++ и т.д. Видимо просто мания величия вместе с самообманом.

И небольшой вывод ко всему. Ядро PHP разрабатывает компания Zend и делает более или менее качественно, библиотеки же разрабатывают уже непонятно кто, куда может попасть любой дилетант, который умеет цитировать умные книжки своими словами и непонятно зачем они лезут в ядро, считая, что они умнее профессионалов, вносят хаотичные исправления и т.д. из-за этого ругают компанию Zend, ругают авторов книг и т.д. На самом деле PHP может стать хорошим продуктом в том случае, если разрабатывать библиотеки, собирать его и т.д. определенная группа проверенных людей и будет какая-то стандартизация.

[kashey]

А мне реально нравиться PHP
Прихожу на работу, тама linux kernel, boost, tauSDL… поворачиваешься к ноуту, а тама пхп… ласковый, милый пхп :)

яб на руби пересел если бы ему синтаксис поменяли. Подсознательно ищу языки поближе к C. Пхп — близок. Руби — всю моторику придется перекручивать.
А спорить со спинным мозгом — сложно

[ulfurinn]

Руби — всю моторику придется перекручивать. А спорить со спинным мозгом — сложно

Зато полезно ;)

[kashey]

xx: Привет моск!
yy: Натс?
xx: Нет! Спинной моск! Ща будем руби учить!

[dime]

пхп близок к си??? С уродскими долларами, стрелками вместо точек, точками вместо плюсиков, нечувствительностью к регистру в функциях, а сейчас ещё и бэкслэшами?.. Что вы называете «поближе к С»? Неужели фигурные скобки? По-моему, руби куда ближе к сям, чем пхп.

[kashey]

руби мне больше asp напоминает если честно.
пхп — реально С подобный, баксы и «левые» операторы вылезает из проблем типизации переменных.

самый страшный язык который я когда либо видел( правда при этом успешно использовал) был Lua, с его конкатенацией через… бегинами ендами и, что и есть самое страшное, «обратной» видимостью переменных…

[dime]

Баксы и уродские операторы — из-за перлового наследства и из-за того, что автор, видимо, ниасилил в своё время синтаксический анализ в должной мере и пошёл по лёгкому пути :). Потом наслоились другие дурости и сделать нормально стало уже совсем невозможно.

[propovednik]

точка вместо плюса — вполне обоснована, вспомните о приведении типов

[kronos]

Ага, в php настолько тупое приведение типов, что поднадобилось вводить точку для контеканации строк.

[propovednik]

напротив, очень и очень удобно (главное комментировать не забывать)

[dime]

Да я знаю. Точка вместо плюса обоснована кривым приведением типов, стрелка вместо точки обоснована тем, что точка уже занята, обратный слэш обоснован тем, что два двоеточия поставят быдлокодера в тупик :). Отсутствие дизайна породило кривости, которые привели к превращению удобного инструмента для лёгкой шаблонизации в уродливого ублюдка :).

[fr0st]

В защиту — Мне нравиться пхп :-) И это не кто не отнимет!

[Apocalepse]

Мать вашу, не могу удержаться. Вы — неграмотны, защитник.

[ainu]

В ряды защитников php принимаются всё!

[RVK]

PHP очень хорошоший язык. Особенно понимаешь это сейчас, когда приходится писать на Java
Но и знакомства с перлом или питоном убеждают — PHP очень хороший язык для той области применения в которой он обычно используется.

[Apocalepse]

Опять пошли сплошные эмоции.

2fr0st
Обалденная защита. А мне нравится Гитлер.

[Novikov]

Achtung?

[Apocalepse]

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

[okopok]

И ещё… быдло-кодеры — это не PHPшники, а те кто пишут быдло код!

[Apocalepse]

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

[okopok]

«что маловероятно попадание быдло-кода в хоть сколько нибудь серьезные проекты» — не согласен… представьте, что у вас штат программистов в хотя бы 100 человек… быдло код всё равно пролезет.
И даже если его заметят, то время на переписываение его может просто не быть и он либо провисит в проекте достаточно долго или зависнет на всегда.

Проходили, знаем

[jeje]

А если ввести гибрид парного программирования, написал код, показал другому сотруднику, я так постоянно стараюсь делать.

[okopok]

ну хорошо, другой сотрудник скажет, что ты не прав и лучше так не делать, и лучше бы переделать, потому что так не желательно и не красиво, но работает и работает нормально. А проект надо было сдать месяц назад

[jeje]

У нас общая политика по отношению к коду, есть четкие правила — Zend Coding Standarts, если я нахожу код, который написал сотрудник не по стандарту, то с помощью начальника или без, он ему придает нужный вид, если логика кода слишком запутана, а по опыту есть проще решение, код модернизируется. Это Единственный верный путь к качественному коду. Но это всего лишь путь, я и сам могу писать что-то не так и всегда прислушиваюсь к советам. Но я не желаю потом копаться в коде другого программера, который мало того что в стилистике другой, так еще и закручен через Жо.

Мои слова описывают ситуацию, когда проекты, которые пишутся владеет и поддерживает наша компания и в этом вся прелесть.

[okopok]

Вам повезло, не везде так чётко поставлена работа ;-)

[mihailt]

а вы исходники популярных опенсорс продуктов на пхп давно смотрели?

[levide]

Бессмысленный спор. Важен ведь результат. Если результат удовлетворяет всем требованиям, какая разница на чем писать. Если не удовлетворяет, выбери другой язык, их вон сколько развелось.

[kashey]

ПХП написан на C, также как и линукс где этот ПХП работает — тоже написан на С
С — лучший язык?
Зачем же тогда на этом С написали ПХП и радостно начали его использовать?
Кто знает ответ, тот не говорит «Ай ПХП говно, АЙ Жаба тормозит»
Каждой твари по паре :)… WWW это еще та тварь. Точнее паразит
Если вы читаете это — значит тварь рода Habrahabreus Sapiens( в днк которой вроде как замечен пхп код) паразитирует и на вас

[nikitad]

> С — лучший язык?

Си следует воспринимать как «высокоуровневый ассемблер».

> Зачем же тогда на этом С написали ПХП и радостно начали его использовать?

Это переход на более высокий уровень абстракции: когда пишешь на PHP и тебе нужно вывести Hello world в браузер ты просто пишешь print «Hello world», а отправляешь содержимое буфера размером n байт на определенный сокет. Специализация в чистом виде, разработка языка под конкретную предметную область, в которой не надо знать системное программирование.

[satas]

Мой препод по программированию как то заявил, что ученики не обязаны проходить путь своих учителей, совершать те же ошибки и т.п.

Так же и с PHP. Он хоть и далек от идеального языка, но для веба лучше не найти.

[viv81ster]

Слон и моська.
Можно сколько угодно критиковать, а он все идет и идет, на нем написана большая часть сайтов, под него написано немеряно сторонних библиотек, тот же PEAR. И от того что PHP кому-то не нравится погоды не меняет. Для разработки можно быстро обучать людей программированию на PHP и включать их в работу, не ища по полгода JAVA или ASP.NET разработчиков на рынке труда, PHPшник не привередлив, мало ест, мало спит. Если начнет рычать на хозяина, можно взять его за шкирку и показать как много «бездомных» таких как он PHPшников, он сразу подожмет хвост и начнет лащится к вам.

Я не в полном восторге от PHP, но этот разговор напоминает беседу африканцев на плантации которые обсуждают конструкции мотыг которые им выдали и сколь долго они не обсуждали те или иные плюсы и минусы, работы от этого не убавится.

Извините если кого-то обидел. не хотел.

[satas]

Не совсем удачная аналогия. Для сельскохозяйственных работах эффективнее использовать технику, а не мотыги.
Никто же не будет на ассемблере сайты писать.

[hudvin]

библиотеки пхп по сравнению с аналогичными на яве — как раз мотыга

[satas]

Это оттого, что они преимущественно для четверки писались.
В пятерке уже в этом плане получше, взять хотя бы SPL.

[hudvin]

да по боку.
что есть в пхп для работы(нормальной) с соап? В яве одних только крупных библиотек штук пять-десять. И они покрывают любые требования, которые только могут взбрести в голову програмиисту или заказчику.
есль ли нормальный фреймверк для авторизации и аутентификации, аналогичный acegi
как обстоят дела с аоп?

[satas]

Пожалуй, тут нечего возразить. Лучше обстоит ситуация в таких фреймворках, как Zend Framework. Но я предпочитаю использовать велосипеды на своем этапе развития.

[viv81ster]

Что вы можете в программировании назвать ТРАКТОРОМ?

Как ни крути это мотыги. Некоторые просто с рукоядью из слоновой кости, другие монолитные деревянные, третьи с железным наконечником.

Как только программы начнут писаться сами, а человек будет лишь указывать что ему нужно в итоге за программа, тогда можно сказать что африканцам дали трактор.

[satas]

Фреймворк с хорошей объектной моделью и документацией можно назвать трактором.

[viv81ster]

По сути фреймворк это не трактор, это складная мотыга. Типа для рыхлой земли или сухой, которая легко превращается… легко превращается, в летние шорты, извините товарищи, по техническим проблемам.

[no_smoking]

Главное чтобы программа не стала указывать что делать человеку :)))

[Alexion]

>>PHP поощряет (практически требует) смешивание логики и представления. Да, вы можете написать код так, чтобы этого не было, но он действительно упрощает написание неправильного (с точки зрения проектирования) кода.

На Платформе 2009 был вопрос про MVC на ASP.NET, что как же так, ведь в представлении код тоже присутствует. Ответ: это логика представления. PHP позволяет полностью разделить код и HTML-разметку, мильен шаблонизаторов. И не ясно чем такой код неправильный с точки зрения проектирования, если считать, что view это html.

[irishrover]

> Для новичка нет проще способа прострелить себе ногу, чем использовать эту «функцию».

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

[Skyneon]

Настоящий php программист, работает эффективно без интернета, а тот кто ходит каждые пол часа на php.net уважения мне лично не прибавляет… чесслово, это тоже самое что говорить я сдаю экзамен по математике у меня есть пару шпаргалок и википедия…

[okopok]

Есть зенд фреймворк — большего для жизни и не нужно :)

[Skyneon]

Настоящих программистов сейчас мало, в большенстве своем, это гавно кодеры (люди которые не умееют грамотно и понятно писать и структурировать код, да еще к тому же полдня проводят на php.net)

Зенд фреймворк и что? Ты без фреймворка напиши что нибудь…

[okopok]

я опечатался, не фреймворк, а студио конечно, но вы меня правильно поняли…
очень долго писал всё в notepad++
в зенд убедили посто силой перейти… дело не в том, что без зенда никак, а в том, что с ним намного проще и быстрее писать. Например вызовы твоих же классов и методов классов, которых в проекте уже больше 100. Постоянно лазить туда сюда и сверяться с названиями методов и порядком аргументов… не Айс

[Rimsan]

:)))
Настоящий программист имхо — тот, который постоянно учиться, а не сидит и думает будто все знает.

[Skyneon]

Имхо не имхо, у нормального программера есть книжка.

[Rimsan]

Какая разница, в каком виде информация. Это уже дело вкуса.

[bat]

У информации в книжках есть свойство быстро устаревать.

[mx2000]

Кнуту об этом расскажите, да? ;-)

[jeje]

Искренне прошу всех заинтересовавшихся. Давайте займёмся обсуждением точек зрения

Здесь нечего отстаивать, здесь НЕЧЕГО обсуждать. Мог бы автору минус поставил за такой бред.

[khizhaster]

Да-да-да, продолжайте еще ;-) Хочу еще умильных комментариев «Для веба лучше нету», «лучший язык», вот порадовало тоже «Настоящий php программист, работает эффективно без интернета,», истинные аскеты! Топором на коленке :)
«Но и знакомства с перлом или питоном убеждают — PHP очень хороший язык» — это нечто! Там еще про яву есть! А уж про делфи как начнут вспоминать, да С порицать за case-sensitive, хы-хы.

Супер, это просто супер пост! Такой концентрации бездарных, глупых и наивных комментариев на квадратный метр страницы еще не встречалось :) Ржал от души!

Интересно, сколько еще будет таких вот холиварных постов? Вроде и кажется, что уже все обсудили, обговорили, ан нет, ты погляди ж. И каждый раз всем есть что сказать, даже если и сам топик неважнецкий :)

[Lestat]

хм… подскажите плизз, сейчас хочу начать заниматься веб-программированием, что же выбрать? python?

[no_smoking]

я бы посоветовал сразу браться за .net языки лучше С#. Кстати и на python можно под net програмить :)

[tenshi]

руби

[Bers]

python + django

[Lestat]

долго выбирал, начал изучать python :)

[valeraorg]

Спор ни о чем. Есть самый справедливый судья — рынок. Рынок приказал PHP жыть долго. PHP — хороший инструмент для своих целей. Не более
Сравнивать его с Java, C++, Python — большая глупость, это разные вещи. Сдесь совершенно неважно что каждый из нас думает, выбор сделал рынок.

[khizhaster]

Вы уж простите, но вы не рынок :) А рынок — механизм ситуативный и отталкивается от предложений. Сейчас их много на пхп, значит рынок торгует пхп. Но это не значит, что «рынок приказал» или «рынок сделал». Вбросьте множество других предложений и рынок переориентируется.

Да и вообще, причем тут рынок? Вы посмотрите выше, там школьники соревнуются в ораторстве, при том, что ничего другого, кроме пхп и не знают. Зато какие высокопарные фразы, а? «Лучший», «Самый» и так далее. Это все говорит только о том, что народ в общей массе не понимает о чем говорит.

И вас можно так же словить. Вот ваша фраза «PHP — хороший инструмент для своих целей». Готов спорить на что угодно, эта фраза вами где-то услышана/подсмотрена/..., и вы ее просто повторяете. А разобраться то достаточно просто. PHP создавался, как шаблонизатор на Perl. Со временем перерос, но цели остались те же, что заложено в аббревиатуре «Hypertext Processor». Далее, что такое гипертекст? Это самый обыкновенный текст, приправленный форматированием. Но для обработки текста ничего лучше sed/awk/perl еще не придумали. И действительно, у perl (как у языка) больше и мощнее средства для работы с текстом.
Какие еще цели? Качественно создание WEB-приложений? Дык здесь Python уделывает с большим отрывом. Окей, можно рассмотреть академические аспекты, такие как стилизация, понятность, легкость, элегантность, модульность и прочее. Дык здесь даже Perl имеет свои преимущества, а уж Python и подавно. Для программиста на perl tr// или s// всегда значит одно и то же, в отличии от пхп, где пруд пруди всяких preg_ str_ и прочих, которые делают одно и то же, но отличаются семантикой.
Правильно, у пхп низкий порог вхождения. В этом его единственный плюс, как у делфи или VB. Но делфи и ВБ никто и не ставит выше. А пхп раздули до неимоверных размеров, но, как известно, все дутое когда-нибудь да лопается.
Но, опять же, все эти доводы просто разбиваются об стенку людей, которые ни на чем другом писать не умеют.
Я сознательно не вспоминал Ruby, так как мало его знаю, но думаю, что пока его еще рано сравнивать, язык не стабилен и тормознут, он только развивается.
Так же не упоминал Java/C#, так как это совсем другие языки. Но суть то та же. Выучите хорошенько парочку других языков, глубоко и широко, а потом вернитесь к этому (и другим) топикам и почитайте.

[chiaroscuro]

ППКС почти что :)

> Далее, что такое гипертекст? Это самый обыкновенный текст, приправленный форматированием.

Мне вот кажется, что это дерево (в виде DOM, XDM и тп). А для обработки деревьев хорошо подходит ФП. :)

[khizhaster]

для DOM — да, но кто работает с гипертекстом на уровне DOM в скриптовых языках на сервере? Как по мне, так много проще работать с ним, как с текстом и регулярками. Хотя это чисто субъективно, скорость работы не сравнивал. Хотя, если честно, не сталкивался с массивными задачами по обработке дерева DOM в веб-проектах, как-то все было стандартно данные-шаблон. Буду признателен, если покажете пример, мне на будущее :)
Кстати, ФП то конечно хорошо, деревья и все такое, но, я думаю, в остальных аспектах для веба оно пока черезчур :)

[chiaroscuro]

> для DOM — да, но кто работает с гипертекстом на уровне DOM в скриптовых языках на сервере

Вот именно, что никто. Потому и имеем tagsoup и неправильный HTML, увы. Вообще, вебу не хватает проверки типов :)

> Буду признателен, если покажете пример, мне на будущее :)

Ur/Web (impredicative.com) — оно и мне на будущее. Вдруг из этого получится второй PHP.

Ай, я опять не в той Вселенной оказался.

> Кстати, ФП то конечно хорошо, деревья и все такое, но, я думаю, в остальных аспектах для веба оно пока черезчур :)

Когда у меня включается режим «лисапедист», я использую Хаскель, и он проще для меня.

[valeraorg]

дык, я и не рынок. А то что код исполняеться на миллионах серверов для тебя не рынок?
Что ты вообще заладил? Пиши себе сайты для своих заказчиков на С++ и молчи. Только я вот не хотел бы тебе платить за такую работу. Или делай сайты до 2000$ на Python. Если ты будешь предлагать такие услуги, то ты скоро сдохнешь с голоду — вот что такое рынок.
ЗЫ Python and C++ and… для серъезных и дорогих проектов.

[VlK]

Сударь, право же, Питон гораздо проще и симпатичней php. Хотя бы даже просто потому, что никогда не тянул за собой угловатый синтаксис C/C++.

Питон часто именно поэтому используют в универах как калькулятор… Скажем, вместо Matlab.

[no_smoking]

> Питон часто именно поэтому используют в универах как калькулятор… Скажем, вместо Matlab.
А может все таки из за того, что он функциональный, а функциональный язык как не кто другой подходит для решения математических задач.

[VlK]

Да нет… Именно благодаря тому, что он простой и наглядный; в нем есть фишки для быстрого рисования графиков и построения расчетов.

Функциональность в нем очень примитивная; более того, сам Гвидо в свое время сопротивлялся включению в главную реализацию языка функциональных черт.

Язык мультипарадигменный; причем доминирует в нем, пожалуй, ООП.

[no_smoking]

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

[valeraorg]

Когда идет речь о какькуляторе, мне кажеться все равно о каком языке идет речь. Питон боллее низкоуровневый чем PHP. Если например писать сайт без django то нужно к примеру управлять выбрасыванием хидеров и так далее. Поэтому утверждение что Python проще считаю абсурдным.

[maserg]

т.е. вы думаете что пхп не умеет выбрасывать хидеры и поэтому питон более низкоуровневый?

вы про функцию header слышали?

[valeraorg]

при чем сдесь header. Когды вы пишите на PHP Hello Word! то вам ненужно думать о том чот вам нужно выслать хидеры браузеру Content-type: text/html, кодировки, параметры кеширования и другое, А на Pythone нужно.
Внимательночитаьть нужно! Шла речь не о возможности кправлениия хидеров, а о необходимости.

[qq6ka]

А какая проблема в создании сайта на Python до 2000$?

[valeraorg]

проблема в том — где хоститься будет такой сайт. Насколько я знаю c shared-хостингом для Python большие проблемы.

[qq6ka]

Но вы же не хотите сказать что проблема не решается в принципе?
Да, выбор меньше — но он есть.

[igorekk]

Никаких проблем не вижу.

[gorinich]

Я года три использовал PHP, и понял одну вещь.
PHP — это не язык программирования! Это супермегакрутой шаблонизатор со всеми мыслимыми и немыслимыми функциями и возможностями.
Можете соглашаться, можете спорить, дело ваше :)

[valeraorg]

Ты наверное о PHP3 говоришь. Попробуй PHP5 :)

[gorinich]

В основном я писал на PHP4. 5 версию до конца не вкурил, ушел в Perl.
На Perl я написал достаточно такого, что на PHP даже не представлю как написать )
Например мультиплексирующие веб-сервисы.
В общем PHP это больше шаблонизатор, чем полноценный ЯП.

[valeraorg]

perl умирающий язык. Его используют только старые админы и те кто на нем писал много лет а теперь просто не хочеть перехдить с него. Есть где-то статья perl vs Python почитай, там показано что у перла ниодного преимущества.

[gorinich]

Ну это не правда )
Перл живет. Просто не популярен.

Есть где-то статья perl vs Python почитай, там показано что у перла ниодного преимущества.

Ни одного преимущества — значит не хуже )))
Но Perl точно не менее гибкий и универсальный ) ООП в нем конечно жжот еще больше чем в PHP ))) Но это не делает язык умирающим. Он скорее элитный, чем умирающий )
Время конечно не стоит на месте и появляются новые языки и новые возможности. Но Perl не теряет своей актуальности. Сейчас его сложно заменить в определенных случаях.
Короче, у каждого свои плюсы )
Python и Perl скорее стоят на одном уровне. Python, конечно, современнее ) После выхода Perl6 проще судить будет )))
PHP — это совсем другое ) Если Вы знаете Perl или Python, то вряд ли станете с этим спорить )))

[gorinich]

Случайно не то нажал )))
Предлагаю не занимать холивором и говносрачем ) ни к чему это )
Каждый язык имеет свои плюсы и минусы. Сравнивать Python и Perl это как сравнивать C и Delphi (да не обидятся на меня C и Delphi программисты ))) )
Но с тем, что PHP в первую очередь шаблонизатор и только потом ЯП спорить сложно. Ибо это единственное «нечто», на котором можно смешивать программирование и верстку, а это задача парсера )

PS. Вот честно никого не хочу обидеть и понимаю, что на РНР можно писать очень серьезные проекты. Но назвать PHP полноценным языко программирования язык не поворачивается. Уж извините если кого задел.
Я свой выбор сделал. И каждый свой выбор делает сам. Это и есть свобода.

[skazkin]

Чушь какая-то=)
Перл — восхитительный язык, и уж правда умеет много того, чего не умеет пхп — ну или умеет, но криво)

[insaner]

Могу добавить к всему выше сказаному то что возможно мы сами виноваты в том что язык изначально предназначенный для «Personal Home Pages» начал мутировать в что то более функциональное в итоге получившись ПУЗЫРЕМ, с которым нам приходиться иметь дело на данный промежуток времени, виноваты в этом программисты, которые поддержали его в свое время и писали когда то кучу ГОВНОКОДА.

Скажите, неужто посте открытия документации и прочтения небольших мануалов Вы начали писать уже оптимизированный, защищенный и расчитанный на высокие нагрузки код? Сомневаюсь.

У каждого начинающего есть этап ГОВНОКОДЕРСТВА или велосипедоизобретательства, только длиться этот этап определенное количество времени и зависит напрямую от образования или как вы говорите ДНК человека. Со временем многое переосмысливается и прошлое воспринимается как ничтожно примитивное деяние.

[enemy_spb]

Мне кажется на любых, ну по крайней мере на многих, языках програмирования можно писать говнокод.
Сейчас большинство говнокода пишеться когда люди неосознавая как это работает использовуют готовые CMS типа битрикса и других…

В пользу PHP скажу, что главное что он уже вырос до тех высот, когда он позволяет писать правильный и грамотный код.

[valeraorg]

правильно

[dAllonE]

В защиту PHP

А зачем его от чего бы то ни было защищать?

Всегда кто-нибудь будет против PHP, IPhone, Mac, Windows, ООП, Linux, Intel, AMD и т.д. и т.п.
Просто игнорируйте их вот и все (:

[Tim_Andersson]

PHP для вэба то, что нужно. Это подтверждает статистика, 80% веб-ресурсов созданы на PHP и очередной холивар это всего — лишь холивар. Ну а если кто-то очень умный и сообразительный, у него много времени — программируйте сайты на ассемблере, тут уж точно все скажут «Вау».

[web4_0]

… вечно приводят в пример ассемблер. Хоть бы раз показали действующий пример сайта на ассемблере с исходным кодом, чтобы все посмотрели, и сделали выводы.

[CGS]

Вообще как мне кажется задача любого языка программирования выступать посредником между человеком и машиной.
Если PHP, либо любой другой язык помогает человеку легче объяснить машине что ему надо, это и есть тот оптимальный выбор.
А что это будет за язык это уже нюансы.

[web4_0]

Не знаю почему, но мне, смотря на всё это, вспомнилась песня:
«Все говорят, что пить нельзя,
Я говорю, что буду» (с) БГ

[qq6ka]

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

[nikitad]

> Откровенно говоря, я не понимаю зачем вообще нужны «однобокие» языки

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

> По мне лучше разобраться с тем же Питоном и писать как системные вещи, так и для веба, если нужно.

Некоторые маньяки PHP даже GUI-приложения пишут. Только нафига? PHP — специализированный скриптовый язык для веба. Пихать его куда-то еще — натягивание гондона на глобус.

[VlK]

Честно говоря, у меня есть такое субъективное понятие «красоты» языка. Это означает, что код в данном инструментарии смотрится хорошо либо плохо; это также значает, не перегружен ли язык чужеродными конструкциями; сюда же входит комфортность стандартной библиотеки.

Так вот, php выглядит уродливо, а, скажем, python — красиво. В общем-то, давно уже все равно, на чем именно писать, но если будет дАден выбор при всех прочих равных условия — то выбор однозначно падет на Питон. Ну красивый он сам по себе, куда от этого деваться?

[firstbyte]

Важно начать с серьёзных книжек (ну хорошо, небольшой крэш-курс в начале тоже полезен), а не с «глазами хакера» или «создаём сайт любой сложности».

[markshevchenko]

Я с PHP ушёл на C# в 2004-м году, проработав на нём 4 года.

По сравнению с перлом язык показался простым и удобным. Но для командной работы над серьёзными проектами подходил слабо. А несерьёзные проекты за 4 года просто надоели. :)

[Anarki]

Смотрю тут на число комментариев, и думаю, мой наверное, может затеряться среди них. Но все равно напишу.
>PHP имеет противоречивое именование системных и библиотечных функций…

Были высказаны слова об IDE, подставляющей нужные функции и подсказки. Но разномастное наименование как минимум с эстетической точки зрения ужасно. Видя, что и язык не придерживается строго правила наименования, программисты начинают писать разным стилем идентификаторы, что вносит сложности при последующем редактировании. Во вторых, при наборе функции, даже с автодополнением, порой приходится подумать, ставить ли подчеркивание, либо начинать слово с большой буквы, это если в списке дополнения функций очень много.

>PHP разработчики постоянно отказываются…
Насчет передачи по ссылке, это может быть актуальным, когда идет передача в функцию переменной(строки, объекта, etc) большого размера и важно поддерживать небольшой расход памяти при этом. А защитник что? Защищает новичков? Зато мы благодаря им лишаемся порой единственной работающей для данного вопроса технологии(по крайней мере без костылей всяких).

P.S. Сам люблю perl для задач без применения ООП ^_^
P.P.S И на php пишу и на других языках.

[bat]

Насчет передачи по ссылке, это может быть актуальным, когда идет передача в функцию переменной(строки, объекта, etc) большого размера и важно поддерживать небольшой расход памяти при этом.

Вы про отложенной копирование слышали? Объекты и так передаются по ссылке.
Передача имеет смысл, когда в методе необходимо изменить внешнюю переменную.

[Anarki]

Ок, нагуглил про отложенное копирование. В случае когда данные изменяются в функции, оно не сработает. Я уже нашел несколько способов передачи, используя $GLOBALS['имя переменной'] или же если эта функция — на самом деле метод, то достаточно хранить данные в свойствах объекта. Хотя я не вижу ничего зазорного в передаче по ссылке :)

[LoneCat]

А к чему вообще развернулась эта дискуссия насчет передачи по ссылке? Насколько мне известно интерпритатор ругаецца только на передачу по ссылке только если в функции не указано что она принимает этот параметр по ссылке, а-ля

Warning: call-time pass-by-reference has been deprecated…

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

[enemy_spb]

Недавно встретилось и мне это кажется совсем нелогичным.

$x = (bool) "false"; //возвратит true
$x = (bool) "0"; //возвратит false

[LoneCat]

Да это по-моему наследие предков :P Тем более что задокументировано

When converting to boolean, the following values are considered FALSE:

the boolean FALSE itself
the integer 0 (zero)
the float 0.0 (zero)
the empty string, and the string «0»
an array with zero elements
an object with zero member variables (PHP 4 only)
the special type NULL (including unset variables)
SimpleXML objects created from empty tags

Every other value is considered TRUE (including any resource).

Задокументированный баг — и не баг совсем :) а это вообще не баг, так что в задокументированном виде — это практически фича :)

[VolCh]

Язык может и неважнецкий по многим параметрам, включая «академичность», но по совокупности всех плюсов и минусов для создания «простых» сайтов PHP превосходит другие языки чуть ли не вместе взятые по крайней мере в России…

Пляшущие на костях PHP ответьте, пожалуйста, на один вопрос — к вам пришло ТЗ на CMS с фразой «разрабатываемая CMS должна работать на подавляющем большинстве виртуальных хостингов планов, включая бесплатные», какой язык вы выберите? Питон, Руби, С++? Еще о Perl можно подумать, но в свое время уходя с «прикладного» программирования в веб, я посмотрел на исходники пары гостевух и как думаете какой код мне был более понятен после Turbo C/C++ и TurboPascal — Perl или PHP? Я вот ни разу не пожалел, что тогда стал изучать PHP. Пробовал писать на С/С++, но уж очень долго да и требования к хостингу завышенные, и сейчас-то не каждый хостер дает доступ к консоли и возможность компилировать свои скрипты, а уж больше 10 лет назад и говорить нечего.

P.S. Почему-то мне кажется, что «противники» PHP большей частью работают над средне и крупнобюджетными проектами, где хотя бы VDS с root доступом само собой подразумевается, а про «обычный» хостинг за 3$ в месяц они забывали давно, если вообще знали когда-нибудь.

[second_pilot]

в универе начал учить программирование с паскаля, а потом долбил указатели на С++. На работе в универе использовал С# для ASP.NET, и прямо таки влюбился в этот язык. Настолько все продуманно с философской и психологической точки зрения. А если еще учитывать все вкусности вижуал студии, то программировать — одно удовольствие.
Вот только в городе есть работа только в php, поэтому пришлось его выучить. Долго плевался на отсутствие неймспейсов, полнейший беспредел в наименованиях, некатчабельные ерроры, и всякие приколы. Особо убило то, что если зааплоадить файл больше max_file_size, то ни апачи, ни пхп ниче не скажут, а тупо опустошат массивы $_POST и $_FILES.
Тем не менее это не помешало мне накатать свой велосипед, который повторяет большую часть логики ASP.NET MVC (автоматический роутинг, HTML методы, tempdata, RenderView, RenderPartial). И я жутко доволен своим велосипедом, который работает как часы.
Это мне позволяет делать вывод, что пхп несколько ущербен, но если кодить вдумчиво, то все решаемо. И все таки мне каждый раз страшно осваивать новые вещи в пхп, ибо, помимо описанного выше примера с постом, мне попадалось и выполнение кода после эксепшина, и выкидоны типа того, что нативная функция может вернуть 1, >1, 0, true и false в зависимости от черт знает чего

[duke_nu]

Наверно все со мной согласятся, что в сфере IT наша страна, я имею ввиду Россия, является догоняющей. есть в этом 1 плюс, мы можем посмотреть, что творится за рубежом и сделать некоторые выводы.
В первую очередь меня интересует актуальность инструмента, сужу я об этом о предложениях работы, вот что у меня получилось:

php-910 Jobs
perl-907 Jobs
ruby-175 Jobs
python- 322 Jobs
java- 2,138 Jobs
asp.net c#- 305 Jobs
(http://hotjobs.yahoo.com)
Это конечно большей частью относится к США.

Вот что у нас:
php-264 Jobs
perl-182 Jobs
ruby-13 Jobs
python- 40 Jobs
java- 393 Jobs
asp.net c#- 80 Jobs
(http://hh.ru)

конечно же это нельзя считать сверх точными данными, замер надо было бы проводить в течении некоторого времени (скажем месяц) и использовать данные с большего числа сайтов.

Я думаю все и так видно, это можно приплюсовать в защиту php и perl скорее жив, чем мертв.

Для себя я сделал выводы: пхп не так уж и плох, спрос на него есть и один из самых больших => работу найти легче, заметьте также популярны коммерческие платформы (java, asp.net c#) я бы на них тоже обратил внимание, как на перспективные, тем более все они имеют СИ подобный синтаксис. с их изучением не должно возникнуть проблем.