Пользователь
0,0
рейтинг
11 декабря 2008 в 22:57

Разработка → В защиту PHP перевод

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

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

Это то, что я люблю и ненавижу одновременно. Однако по своей сути это утверждение верно. Почему некоторые двухсловные функции разделяются подчеркиванием, а некоторые нет? Почему $needle и $haystack иногда меняются местами? Это смешно. Но в конце концов действительно ли это так важно? Моя IDE с автоподстановкой и php.net всегда под рукой. Так что возможно это и является негативным фактором для PHP как языка. Но не мешает мне быть эффективным программистом.

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

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

Отсутствие логики при редизайне. Вышеупомянутые «сокращения» сделали иногда невозможным указывать для функций значения по умолчанию. Этот баг пофиксен в PHP 5, но они же убрали передачу переменных по ссылке из PHP 4!

Я не думаю что есть какой-то недостаток логики. Я думаю, вас сильно задело данное конкретное изменение и «во рту остался неприятный привкус». Изменения в языке зачастую становятся известны за месяцы, а то и годы до их реализации. Для перехода от 4 к 5 существует migration guide в котором описаны все различия. Передача параметров по ссылке была ужасной чертой, которая не даёт разработчику каких-либо преимуществ, не достижимых другими способами.

Плохая реализация нэймспейсов (фактически из вообще нет). А сейчас, когда они появились, что будет использоваться в качестве разделителя? Бэкслэш! Символ, который повсеместно используется для экранирования, даже в PHP!

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

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

Я считаю нормальным не согласиться с тем, как PHP делает это, но я не согласен с тем, что это делает язык «плохим».

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

PHP это DSL для Интернета. Я плотно работал с ним в течение 8 лет и пользовался рекурсией от силы 4 или 5 раз, как правило, для обхода директорий или XML. Это не тот подход, который часто нужен для веб-разработок. Я не оправдываю низкой производительности, но это гораздо больше академический вопрос, чем вопрос продуктивности. Если вам действительно нужна быстрая рекурсия, PHP — не ваш выбор.

Функции нечувствительны к регистру. Я понятия не имею, о чём они думали в тот момент когда сделали это. Язык программирования это способ определить поведение как для компьютера, так для программиста, без двусмысленности. Нечувствительность к регистру вводит много неясностей.

Я на 100% согласен с этим.

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

Как замечательно — люди жалуются на язык, который позволяет им применять любые системы вывода (об этом красноречиво свидетельствует количество и стиль шаблонизаторов для PHP) — ИЛИ — пропустить всё и просто выводить напрямую. Это совсем не делает PHP плохим. Это часть того, что делает PHP хорошим.

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

Вы имеете в виду кэширование байткода (например, акселераторы), или кэширование вывода?

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

Если вы говорите о кэширования вывода то тут даже разговаривать не о чем. Любой веб-проект со значительными нагрузками нуждается в кэшировании. PHP здесь ни при чём.

В целом, я думаю, вы считаете PHP «плохим» языком в очень академическом понимании. А люди, использующие PHP, кодят на нём «to get things done».
Перевод: BaileyP
neudor @neudor
карма
18,8
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (446)

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

    Но откуда планктону знать, что хорошо, а что плохо, если хорошего они не видели, а если и видели — то не поняли? (-:
    • +1
      Низкий порог входа — плюс?..
      • +3
        Низкий порог входа плюс для тех, кого интересует «здесь и сейчас». В 90е годы языком, на котором работало большинство программистов был VisualBasic. Потому что на нём можно было что-то сваять не зная о программировании практически ничего. Сейчас одного такого языка нет, но PHP — одна из вещей, которая его заменила.
        • –1
          Простите, а зачем нужны такие языки?
          • +5
            Ну нужно же на чём-то делать сайты за $100?
            • +34
              да, собстно, сайты за 100 000$ тоже на чем-то делать нужно..)))
              • +10
                Ага а вы заказчику раскажите что ваш сайт стоит 10 000$ вместо 1 000$ потому что он написан на языке высокого уровня, и ничем больше не отличается, и поддержка его ему будет обходится на 500 баксов/мес дороже по этойже причине… + сотрудника если захотите взять ему нужно будет платить 5000, а не 3000…

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

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

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

                А если у вас кривые руки то вам что грабли что лопата…
                • +5
                  я вообще-то имел ввиду, что на php можно решать задачи разного уровня сложности… от говносайта за 100$ до проекта который разрабатывается год и более…
                • +2
                  Согласен с последним высказыванием. Если руки кривые — любое будет лагать и работать через одно место.

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

                  В бОльшей степени всё зависит от количества и качества реализованного функционала и качестве технических решений. Можно сделать говносайт за 100$ на asp.net, или трёхслойку с отличной расширяемостью и сопровождением за 10 000$ на php.
      • 0
        мда, исправляюсь…
        Для PHP — несомненно это плюс (-:
        • +1
          Минус, т.к. поощряет «И так сойдет», что губительно для повторного использования, и в итоге как раз не сэкономит времени.
          • 0
            тогда интернет был бы другим и скорость его развития была бы намного меньше. Оно нам надо? надо поблагодарить PHP хотя бы за то, что мы сейчас имеем. И несомненно низкий порог входа в таком случае — это большой плюс.
    • НЛО прилетело и опубликовало эту надпись здесь
      • +3
        проблема быдлокода рождается от быдлокодеров а не от того что пхп такой плохой, на нём тоже можно красиво и грамотно писать.
        • НЛО прилетело и опубликовало эту надпись здесь
          • +13
            Разрешает != приветствует. Я бы сказал, приравнивание этих понятий является применением одного из приёмов демагогии.
            Он уже изжил себя
            В чём это выражается?
            Что раньше было хорошо, сейчас уже плохо.
            Приведите примеры, что ли. Без них как-то голословненько звучит.
            php умирает, как язык
            абаснуйте, в общем
            • 0
              хорошо сказал
            • –4
              Выражается всё в том, что PHP развивается с помощью костылей. Сначала в четвёрке или около того появился костыль под названием «ООП». Ужасный костыль. За него надо было разрабов кастрировать и сжечь на костре. Потом этот костыль обрастили ещё кучей костылей и мы получили пятёрку с кучей глюков и вся эта костыльная структура была весьма шаткой. Сейчас её залепляют соплями и придумывают новый костыль — namespaces. Понимаете в чём дело, это не неймспейсы, а реально костыль. После Java, Delphi и ActionScript 3 все эти костыли от PHP вызывают лишь недоумение.

              А потом будут ещё и ещё костыли. Нравится? Пользуйтесь! А для меня PHP навсегда останется шаблонизатором и ничем более.
              • +8
                1 — php5 использует ядро zend engine 2 в то время как php4 и ниже zend engine 1, ядро подверглось серьезным изменениям, а не подпоркам
                2 — namespaces — не костыль, в паскале тоже их не было и в action script…

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

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

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

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

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

                  А насчёт нового движка Zend — его возможности в области ООП сейчас на уровне Turbo Pascal 7.0…
                  • +2
                    Во-первых, я не говорю глупости. Во-вторых, очень даже основательно.
                    А, ну это, конечно, аргумент, да. Бронебойный.

                    Найдите-ка в TP7.0 final и abstract.
                    • 0
                      Абстракты и виртуалы были, файнал в той реализации не нужен был принципиально.
                      • 0
                        static method?
                        Interface?
                        Exception?
                        • 0
                          Исключения не являются фишкой ООП. И собственно ООП реализация исключений самая кривая, так как не позволяет управлять выполнением кода.

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

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

                          Дело не в возможностях конкретной реализации, а в самой реализации. ООП в PHP до сих пор костыль. Возможно, в Zend Engine v9 это поправят, но, боюсь, мы не доживём до этого славного события.
                          • –2
                            Troll detected
                  • +4
                    а в какой версии появились юниты Вы вкурсе? а до 7 версии их не было, можно ли в таком случае считать что в 7 версии сделали костыль в виде неймспейсов? а в action script тоже ведь небыло пакетов изначально, можно ли их считать костылями? думайте что говорите, не все так просто как кажется на первый взгляд… создатели пхп проделывают грандиозные меры для улучшения ядра и у них это получается, не стоит плевать на них только потому что Вам этот язык не нравится… мне вот Java не нравится, но я никогда не скажу что она ужасна, хотя и у нее есть свои недостатки
                    • –1
                      Дело не в том, когда что появилось, а в том, в каком виде что-то появилось. Первое появление ООП в PHP — это ужасный и кривой костыль над массивами. Чтобы двинуть ООП дальше ребятам пришлось переписать весь интерпретатор. Ниже уже написали, что это полный идиотизм от и до. И, самое главное, ООП всё-равно местами живёт на костылях! Хаха!

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

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

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

                        Или это у вас норма поведения? :)
                      • +1
                        это в некоторой степени называется «метод проб и ошибок»… разработчики пхп тоже люди и им свойственно ошибаться… а может они просто посмотрели на реакцию разработчиков на появление пхп? типа «а вдруг забракуют?» не забраковали? давайте сделаем полноценную поддержку… я не знаю, и Вы не в курсе…
                        почему у Вас нет своего мнения? не стоит цитировать других и только, нужно и свое личное мнение иметь а не писать «ниже уже написали»
                        «Он весь выглядит сделанным из соплей и соплями склееным» — этого я не понял, Вы можете _как разработчик_ аргументировать это не «пустозвонством» а хотябы маленькими аргументами?
                        • +1
                          Это не метод проб и ошибок, а отсутствие такой стадии разработки как проектирование. Если вы не хотите это понять, то мне вас жаль.
                          • 0
                            И все же посмотрите на

                            CP/M -> DOS -> Windows

                            :) вам поподробнее с этого момомента? :)
                            • +1
                              Я не вижу связи между DOS и Windows. А CP/M -> DOS — это переименование.
                              • 0
                                жаль что не видите :)
                                Учите историю.
                                • 0
                                  сами поучите, чтоб глупостей не писать, оок?
                              • 0
                                Не видите? Повтыкайте на real mode и костыльность WinME. Другой вопрос что NT разрабатывался тогда паралельно. Но и PHP5 разрабатывался параллельно добавлению костылей PHP4. И дай боже в 6ой версии костыльность неймспейсов и прочего будет переписана на новом уровне. Это и есть case. Вы просто видимо пеняя на отсутствие «стадии проектирования», не сталкивались с проектами со сроками поддержки от 10 лет. Я признаюсь тоже не сталкивался.
                                • 0
                                  Учите историю, винда в инкарнации Win9x/NT происходит от OS/2, более ранние версии как и Win9x операционными системами не являются, это оболочки для DOS, такие же как Norton Commander, только более навороченные. По вашей логике NC тоже произошёл от DOS, но это бред. То что винда до NT костыль никто не спорит, но это не костыль для DOS. Да и что сравнивать костыли? Возьмите в пример нормальную ОСь изначально грамотно спроектированную, например, UNIX.
                                  • 0
                                    Историю мне учить не надо я ее и так не плохо знаю. То что Win происходит от OS/2 — бред. Интерфейсные заимствования и многое многое было взято из OS/2 но, ядро — нет. А ОС это в первую очередь ядро.

                                    Далее.

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

                                    Далее.

                                    На тему грамотности и не грамотности проектирования прошу аргументы. POSIX от WinAPI отличается. И ядра отличаются. Но вы видели исходники ядер Win? %) Так как тогда судите от проектировании?
                                    • 0
                                      Win9x только Microsoft называет ОСью, на самом деле это оболочка с частично реализованным WinAPI, не более того. И это не костыль для DOS, это костыль имени Windows.

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

                                      И ещё раз повторюсь — не надо сравнивать костыли, надо сравнивать костыль и грамотно спроектированное приложение.
                                      • 0
                                        Закончен разговор… %)
                                      • 0
                                        Простите, но вы тупой.

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

                                        Оболочка для MS DOS — это Windows 3.11, например.
                  • 0
                    Кто мешает на Java накодить всё в main(), соорудив исходник на пару (сотен) мегабайт? :) Видимо lead developer, который за такое оторвёт йайтса? :) Потому что сам язык вполне себе позволяет использовать откровенно процедурный стиль или не использовать вообще никакого.
                • +2
                  Довольно странно слышать утверждения, что Zend Engine «подвергся серьезным изменениям, а не подпоркам».

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

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

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

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

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

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

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

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

                        и все таки интересно чем конкретно дизайн языка пхп хромает на обе ноги кроме как нестабильные параметры функций?
                        • 0
                          > это в корне не так, пхп «практически с нуля» переписывался только один раз — с 4 на 5 версии

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                      Смутные авторы — это из-за их национальности :) (троллю, не удерживаюсь)
                                      • 0
                                        нужно? только Пхп?
                                        Хотите сказать, у всех соседних языков множество ...DSL уже прекрасно реализовано?

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

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

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

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

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

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

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

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

                                            =) бывает, просто непошло
                                            • 0
                                              Приведенная аналогия неверна.

                                              И кстати да, бодибилдинг отстой, каратэ всех спасет! ^_^
                                  • 0
                                    О.О абстракция? О.о надо бы вставить? В какой версии Java появились аннотации? О.о
                                    • 0
                                      Вообще ничего не понял.

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

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

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

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

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

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

                                              Takusen. HDBC и HaskellDB.

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

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

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

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

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

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

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

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

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

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

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

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

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

                                                  Сходите по ссылкам, почитайте, может, даже когда-нибудь придете к тем же выводам, что и я.
                                                  • 0
                                                    Чем ближе пятница тем больше. %) А по ссылкам я ходил… Может быть мое мнение будет спорно, но изучать такие языки и технологии сродни тому что бы изучать embeded linux, или там ME для симбиана. Полезно. Интересно. Но узко. ) Хотя повторюсь это спорно.
                              • 0
                                М… Вы тут правы. Но может вы согласитесь с тем что только с 5ой версии PHP можно вообще считать языком? =) Потому и переписывался с нуля собственно. Абстракция объектов была не нужна для шаблонизатора-темплейтора которым PHP по стуи долгое время являлся. Он сам по себе представлял эту функцию(точнее каждый .php Файл — отдельная функция).
                                • 0
                                  > Абстракция объектов была не нужна для шаблонизатора-темплейтора которым PHP по стуи долгое время являлся.

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

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

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

                                          Так что поздно. Все пропало! %)
                                          • 0
                                            Неа. Пропадет все когда пхп будет встраиваться как скриптовый язык в софт для windows. Вот тогда — пропадет. %)
          • +1
            думаю любой язык разрешает написание «хренового кода». Kогда процент свех сайтов написанных на php будет существенно мал, я соглашусь что пхп умирает, а пока он цветёт и здравствует, взять тот же zend_framework который активно развиваеться.
          • НЛО прилетело и опубликовало эту надпись здесь
          • +4
            Я не PHP кодер :-)

            Но Flickr написан на PHP :) и работает, и вы знаете — неплохо ведь работает!
          • +4
            Перл тоже умирает. А толку? =)
          • 0
            Вот тут, например, govnokod.ru/ не только PHP, хотя его там и больше, но скорее всего это стоит отнести к популярности языка.
          • –1
            А чего ты так за минусы переживаешь? Не боись, мы тебя трогать не будем.
            • НЛО прилетело и опубликовало эту надпись здесь
          • НЛО прилетело и опубликовало эту надпись здесь
            • 0
              интересно, и чем же он приветствует написание кода? что можно в нем накодить такого ужасного чего нельзя накодить в других языках? приведите пример и я Вам постараюсь привести подбный код на .net или python…
      • +1
        Чё-та я не знаю, а у чего «высокий порог входа»? Lisp, Haskell & APL? :)
        • +3
          Brainfuck =)
        • +1
          assembler :-)
          • +1
            Во всяком случае я точно не вошел… :)
            • +1
              А вы не в тот входили. Попробуйте асм для RISC16 — всё очень просто и понятно.
    • +12
      Любой язык создается, что бы решать задачи, с какими то задачами справляется лучше с какими то хуже. Используй для нужной задачи нужный язык.
      5 лет занимаюсь пхп, до и парллельно приходилось писать на плюсах, делфи, шарпее и асме…
      Практически всегда приходилось сопровождать чужую разработку, открою страшный сикрет судя по всему планктон не весь в пхп, потому как говна и не умения работы с языком прослеживались практически везде.
  • +19
    Замечательный подход! Просто отличный!
    «Я плотно работал с ним в течение 8 лет и пользовался рекурсией от силы 4 или 5 раз»
    «тогда я не думаю, что это важно для меня»
    и т.д.

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

    P.S. Простите, но тема на хабре разжевана и обсуждена в куче топиков, а по большей части в комментариях к темам. Даже знатные холиварщики только лениво дергаются по этой теме ;)
    • 0
      Поддерживаю, кстати. Аргументации защиты просто беспомощна.
      • +1
        Думаю, тут просто столкнулись теоретик и практик.
        • –2
          в таком случае теоретик тот, кто говорит — «Я плотно работал с ним в течение 8 лет и пользовался рекурсией от силы 4 или 5 раз»
          • +4
            Он практик. Много вы видели «программистов», рисовавших 10 лет формочки в Visual Basic'е и пользовавшихся при этом рекурсией? Вот. А сейчас этот контингент программирует на PHP.
            • НЛО прилетело и опубликовало эту надпись здесь
              • +1
                А встроенными функциями сортировки? Религия не позволяет пользоваться? :)
              • 0
                Сортировку нельзя написать без рекурсии? Ни разу не слышал :)
                • +1
                  Быстрая сортировка неотъемлемо рекурсивна.

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

                  Если даже убрать использование стека вызовов, все равно придется написать свой, лисапедный. Рекурсию тут не уберешь, и точка.
            • 0
              У меня не один из проектов не обошёлся без рекурсивных алгоритмов. Так что говоря что рекурсия не так уж и важна он либо теоретик либо не умеет ее готовить :)
              • +2
                Если ни один ваш проект не обошелся без рекурсии — это говорит лишь о вас как о неопытном программисте либо программисте упертом на рекурсии, т.к. рекурсия — зло(пользя одна — повышается скорость разрабортки) и если бы вы учились на программиста вам бы еще во время учебыб ы вдолюили что любой рекурсии можно избежать.
                • 0
                  А я не спорю что ее нельзя избежать. Просто некоторые некоторые задачи лучше решить быстрее дешевле будет. А вот если важна скорость тогда да нужно разворачивать в цикл. Кстате если вы такой опытный программист скажыти как в xslt построить дерево(не ограниченое) не используя рекурсию буду вам признателен, да если вы не в курсе там переменные не могут менять свое значение :).
                  • +1
                    Не все рекурсивные алгоритмы можно развернуть в цикл :) (в основном так называемую «хвостовую рекурсию»). Однако, как некоторые здесь замечали, от любой рекурсии можно избавиться, заменив автоматическое использование стека явным (например, самописным на массиве).
                    • 0
                      Опять-таки, большой вопрос, повысит ли это производительность (зависит и от задачи, и от программиста, да и от языка программирования).
                • 0
                  вот пример генерации json в зависимости от типа объекта nacmnogo.ru/jsonview.txt посмотрел бы я как вы бы тоже самое повторили бы без рекурсии при этом сохранилась понятность и структурированность кода
                  • 0
                    По приведённой вами ссылке вместо header('Content-Type: text/plane') вероятно должно было бы быть text/plain :)
                • +2
                  Приведите решение задачи обхода дерева без рекурсии, ну дерева каталогов к примеру.
                  p.s. меня учили на программиста 5 лет, я надеюсь у меня были не самые плохие преподаватели, и нам никто никогда не говорил что рекурсия — зло. Да она кушает ресурсы, да в некоторых случаях рекурсивные алгоритмы могут зацикливаться. Но замены им в ряде задач увы нет.
                  • 0
                    Ряд задач не есть глобальная потребность.
                    • +2
                      Никто и не говорит про глобальную потребность. Это всего лишь инструмент, плохой ли, хороший ли — но он есть, и грех им не воспользоваться, когда он упрощает решение задачи.
                      • 0
                        Так я и не спорил, тут просто ставится вопрос, что прямо скорость рекурсий в PHP создает глобальную проблему. я же говорю, что потребность в рекурсии незначительна, чтобы биться с оптимизацией ее скорости.
                  • 0
                    Дерево можно обойти без рекурсии. Достаточно использовать стек и хранить в нём необходимые данные (указатель на текущий узел etc). Собственно, то же самое происходит при рекурсивном обходе, но при этом совершается ещё много лишних действий.
                    • 0
                      Можно, но зачем?

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

                      И кстати, дерево можно уложить в массив, юзать skip pointers, бороться за каждый бит… Но это даст ощутимый результат, только если вы пишете, скажем, риал-тайм рейтрейсер.
                    • 0
                      Примерно вот так:
                      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);
                         }
                      }
                      

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

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

                        Пишите лучше сразу на брейнфаке, раз такой аскетизьм исповедуете.
                      • –2
                        А чем простите здесь лучше при рекурсии также создается стек хранятся предыдущии значения но делается на более низком уровне те быстрее. Вы счас реализовали подобие рекурсии.
                  • 0
                    DirectoryIterator — без рекурсии на PHP
                    • 0
                      поправлюсь — RecursiveDirectoryIterator
                      • 0
                        Recursive в названии не наталкивает на мысль?
                        • 0
                          Обсуждалась проблема производительности рекурсии на PHP… А SPL — это расширение, написанное на C.
                  • 0
                    без рекурсии такое прекрасно решается с помощью Итераторов.
                    вот ПРИМЕРНО накидал.
                    общий принцип думаю станет понятен.
                    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:/");
                    
                    • 0
                      Берегите пальцы, они еще пригодятся. :) Если я сейчас напишу решение на Хаскеле, вам станет стыдно за свою многословность (меньше кода = меньше багов, к тому же).

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

                      Корень всех зол, как-никак.
                      • 0
                        lurkmore.ru/Haskell
                        • 0
                          А что я там должен прочитать? Пример факториала на комбинаторах? :)
                      • 0
                        Эта оптимизация уже вполне себе своевременная. Задачу обхода дерева решали миллион раз.
                        • 0
                          Пинайте разработчиков PHP. Если они не могут даже написать нормальный интерпретатор, то…

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

                          Что за «аптимизацыя»??? Если уж совсем тормозит — пользуйте Си и не парьте свою голову.
                      • 0
                        причем здесь Хаскел? был вопрос о том что без рекурсии нельзя обойти дерево каталогов. я привел принцип одного из решений. о оптимизации речи небыло. на Питоне тоже можно написать компактнее ) но это уже холивар начинается…
                        • 0
                          а при желании и на пхп можно меньше пальцы нагружать)
                          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;
                          }
                          
                        • 0
                          Мысль в том, что обходить дерево каталогов без рекурсии есть извращение, раз, и преждевременная оптимизация, два.

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

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

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

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

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

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

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

                                  Проверьте сами, что уж тут. Все не так страшно, как кажется.
                      • НЛО прилетело и опубликовало эту надпись здесь
                        • 0
                          Принимайте:

                          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 слишком «ленивый» там), но тем не менее, в интересах науки… ^_^
                          • 0
                            прикольно.
                            Хотя я ждал более лаконичный код)
                            • 0
                              О да, IO это не самое лучшее в Хацкеле (а тут этого IO чуть больше, чем полностью). :)
                              • 0
                                а что чаще всего на нем пишут?
                                а то у меня складывается впечатление что во многом он схож с Питоном.
                                • 0
                                  Интерпретаторы, компиляторы, ИИ, обработку естественных языков, а также совсем гикнутые вещи («Haskell is a playground for advanced type trickery.»)

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

                                  [1] hackage.haskell.org/packages/archive/pkg-list.html
                                  • 0
                                    сенкс. почитаю
                  • 0
                    $info= `ls -R $dirName`;
                    • 0
                      а если код будет работать не в *nix?
                      • 0
                        if (PHP_OS=='WINNT') throw new mustDieException();

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

                          > if (PHP_OS=='WINNT') throw new mustDieException();
                          Если заказчик хочет, то его проект будет крутится и на винде и на любой платформе которую он только придумает. Он платит деньги и «Хочет» — а разработчик должен сделать чтобы код работал )
                • +2
                  Да почти всего можно избежать: например, функций, циклов, например lurkmore.ru/%D0%98%D0%BD%D0%B4%D1%83%D1%81
                  (см. про «китайский код») :)
              • +1
                нука, накидайте мне тут десяток примеров на живом сайте, где используется рекурсия =)
                • 0
                  Моя домашняя страничка, вот пример. Шаблонизатор шаблонизирует шаблон, получает подстранички (например, список чего-либо, шаблонизирует их, вызывая функцию шаблонизирования в самой себе). Это позволяет засовывать отдельные странички (например, сформированный список новостей, с вою очередь, сформировный из подробной новости, сшаблонизированной для каждой строки) в другие страницы. Рекурсия.
                  • 0
                    отлично! :) Здесь у нас конечно главным тормозом является рекурсия, а не бесконечные реквайры :) И это уже целых 4 рекусрии…
                    шаблоны
                    поиск
                    директории
                    хмл
                    =)
                  • +1
                    Хотя бы с десяток рекурсивных вызовов шаблонизатора наберется?
                    Шаблонизатор не та задача и не тот масштаб, где скорость рекурсивных вызовов играет роль.
                  • +12
                    Шаблонизатор шаблонизирует шаблон


                    Шаблонизаторы шаблонизировали-шаблонизировали шаблоны, да не вышаблонизировали :)
                    • +3
                      Шесть шустреньких шепелявеньких шаблонизатора шаблонизировали шаблонизаторами шаблон
                • 0
                  Вам прям нужен десяток :). Например меню, карта сайта, иерархический каталог, а вы пробывали реализовывать волновой алгоритм поиска пути без рекурсии еще тот гемор, а иногда так хочется чтобы mysql поддерживал рекурсию а так приходится делать много запросов место одного.
                  • 0
                    то что мускул не поддерживает рекурсии — это проблема мускула
                    волновой алгоритм поиска — красиво, но на реальных проектах встречается как медведь в московском лесу. И рекурсия без рекурсии — нет так уж и сложно сделать
                    • +1
                      У нас на Урале медведей больше значит :)
                      > И рекурсия без рекурсии — нет так уж и сложно сделать
                      можно, а нужно? Скорость веб приложение в больше всего зависит от структуры базы и качественных запросов а от рекурсии не такое уж и падение производительности. А то что написание рекурсивного кода сэкономит х отябы 15 минут уже хорошо.
                      • 0
                        Вы сами написали «алгоритм поиска пути без рекурсии еще тот гемор», на что я и ответил, что не шибко большой гемор ;-)
                        • 0
                          Но все таки гемор но для этого процесса все таки лучше помучатся и сделать без рекурсии, а то уж очень ресурсоемкий процесс :)
                  • 0
                    Nested sets вам помогут. Тут им самое место: обновлений мало, а считываний много.
                    • 0
                      А каким местом рекурсия и структура базы к друг другу относятся. Всему свое место. Но насчет Nested sets я у себя в голове заметочку сделал :)
                      • 0
                        Дело в том, что при использовании nestes sets выбирается полный путь страницы одним запросом. Ну и вообще любые ветви любых деревьев. Doctrine, например, уже имеет поддержку nested sets и позволяет прозрачно работать с деревьями.
                        • 0
                          Ну есть ведь и другии задачи которые проще решить рекурсии а иногда вставка куда важнее выборки а представьте как отсортировать такую структуру. В общем вы меня не убедили что рекурсия это зло.
                          • 0
                            Так я и не доказывал :D Ничего против рекурсии не имею
                            Решил просто инфой поделиться. Для хорошего человека не жалко ;)
                  • 0
                    Волновой алгоритм основывается на поиске в ширину, который, в свою очередь основывается на очереди, а не на стеке, как рекурсия! Так что то, что вы писали, было каким-то другим алгоритмом и вполне могло быть гемором.
                    И ещё я чуть выше написал, как можно обойти дерево без рекурсии, со стеком. Если два вас это гемор, то какие вы вообще задачи привыкли решать?
                    • 0
                      (Немного матана не помешает, ящитаю.)

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

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

                      Таким образом, даже если алгоритм основывается на очереди, а не на стеке, он все равно рекурсивен. ЧТД.
                    • 0
                      Алгоритм упрощенно по детски. Надо просмотреть соседний клетки на наличие прохода и перейти к свободной клетке повторить пока не найдем начальный пункт, при это при этом в клетку записываем вес(глубину вложенности), и наконец проходим по пути наименьшего веса. Если что не так я по памяти писал, давно это было 5 лет назад. И вы здесь не видите рекурсию.
                • 0
                  Хлебные крошки.
                  Функция ВывестиРодительскийкаталог (ТекущийКаталог)
                  {
                  Если есть(Родительский каталог(ТекущийКаталог))
                  ВывестиРодительскийкаталог((Родительский каталог(ТекущийКаталог));
                  Вывести ТекущийКаталог;
                  }
                  P.S. Я понимаю, что это довольно долгий алгоритм.
                  • 0
                    обход директорий… об этом автор ещё говорил
                    • 0
                      Не директории. Каталоги (родительские страницы)
                      Например:
                      Форум программистов -> Новости -> Обновления -> Новогодняя 2.0 -> Комментарии.
                      • 0
                        рекурсивная выборка данных из базы… опять же… сортировка по мускулу и проход одним циклом
                        • 0
                          интересно как вы так от сортируете записи если они относятся как родитель и ребенок через поле parent_id
                          • 0
                            order by parent_id asc, id asc
                            а далее ассоциативный массив собрать дело двух милисекунд :)
                            • 0
                              а если дочерний элемент был добавлен после родительского?
                              • 0
                                я показал только начальную сортировку, дальше в ордер в можете запихнуть ещё много чего, плюс ещё данные могут сортироваться дополнительно при запихивании данных пхп и при выводе ;-)
                                • 0
                                  И все это против пяти вложенных функций смешно.
                          • 0
                            в крайнем случае можно джоин таблицы самой на себя сделать
                            • 0
                              это конечно вариант если у ваз глубина ограничена например трем, а если хотите построить дерево так чтобы в один прекрасный день не пришлось лезть в код и добавлять еще join
                              • 0
                                в большинстве случаев хватает сортировки и цикла… но я не говорю, что всегда это возможно ;-) Я не спорю, что рекурсия нужна, но это не «панацея» ;-)
                                • 0
                                  А кто говорить, что панацея. Тут было сказана, что зачем оптимизировать выполнение рекурсии она ведь не так нужна. Хотя самые ресурсоёмкии операции как раз и делают с помощью рекурсии. Так почему бы ее не оптимизировать. Если она будет выполнятся не на много медленее чем без рекурсивные методы. Тогда рекурсия будет более востребована.
                                  • 0
                                    согласен
                          • 0
                            Объект | свойство | значение
                            -------+----------+-------------
                            Сыночек| Родитель | Папочка
                            Дочка | Родитель | Папочка
                            Папочка| Родитель | Дедушка
                          • 0
                            • 0
                              Думал что-то новое предложите :( Ну все сходится к структуре базы данных а не к рекурсии. Есть структуры которые быстрее выводить, есть те что быстро модифицируется что применять зависит от задачи. Для комментариев например нужно чтобы они быстро редактировались выводятся они все равно разом. А вот для меню сайта быстрое редактирование не нужно хотя он и по размеру не такое, как правило, большое поэтому без разницы можно обойтись и более простой структурой.
                              • 0
                                Для меню нет необходимости каждый раз лазить в БД
                          • 0
                            Лучший способ избежать рекурсии при построении дерева из таблицы — это хранить дерево в упорядоченном виде.

                            Вот в такое же дерево комментариев, в которое мы сейчас пишем, я на своём проекте добавляю новую запись двумя запросами, извлекаю все дерево одним запросом и отображаю без дополнительных сортировок.
                            • 0
                              Я в принципе делаю похоже только вставляю одним запросом и делаю выборку одним запросом а вот строю дерево на xslt рекурсивно.
                  • +3
                    Используйте Nested Sets и никаких рекурсий.
                    • 0
                      А вам не кажется что там проблемы со вставкой, удалением, переносом узлов. Да и для отображения дерева все рано нужно использовать какой то алгоритм оп хода дерева(рекурсию например).
                      • 0
                        Nested Sets используйте — все давно придумано. Выводить большое дерево рекурсией — это извращение.
                        • 0
                          А как вы думает скоко займет времени вставить узел в центр таково дерева. Так что это зависит от целей. Да и сложность реализации таково дерева на порядок больше. Вот например для комментариев на хабре такая структура явно не подходит.
                          • 0
                            А как часто вы вставляете узел в дерево относительно количества запросов на выборку и, соответственно, в вашем случае рекурсий на его вывод? Вы занимаетесь софистикой. И, раскрою вам большой секрет, если правильно хранить дерево Nested и правильно сделать индексы, то на дереве до 10000 узлов вы не заметите никаких отличий при вставке относительно вашего алгоритма.
                            • +3
                              Судя по текущему холевару несколько раз в минуту :)
                    • +2
                      «Вложенные множества» тоже рекурсивная структура ^_^
                      • 0
                        Оно не требует рекурсии при выводе дерева — именно эта операция для деревьев является самой востребованной.
                        • 0
                          Мне интересно посмотреть, как можно работать с рекурсивной структурой, не используя рекурсию.

                          Объясните, пожалуйста.
                          • 0
                            Объясните мне пожалуйста, где вы увидели рекурсию при выводе дерева, хранящегося в Nested Sets?
                            • 0
                              ПоRTFM'ил по вопросу. Извращенное, но неплохое моделирование дерева в RDBMS.

                              Засчитывайте слив :)
                              • 0
                                Повторяю вопрос — где конретно рекурсия в PHP при выводе дерева из Nested Sets? Пример конретно кода.
                                • 0
                                  ну получили вы таким запросом
                                  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
                                  • +1
                                    на *экран конечно
                                  • 0
                                    level тебе в помощь
                                    • 0
                                      какой левый или правый? :) или нужно еще переменную добавить.
                                      • 0
                                        Ты путаешь LEFT — RIGHT с LEVEL
                                        во всех практический современных реализациях классов есть еще вспомогательное поле LEVEL в таблице. если судить по приведенному тобой запросу — в твоей таблице оно тоже есть
                                        • 0
                                          запрос не мой я его скопировал вот от сюда www.codenet.ru/db/other/trees/index.php както не посмотрел что возвращается. Ну все таки нарисовать точки в цикле это одно а вот построить html список это другое это в цикле прейдется добавлять лишнии условия я всеж предпочитаю рекурсию меньше путаницы
                                          • 0
                                            и чем тебе тут поможет рекурсия? бд возвращает плоский список и чтобы воспользоваться рекурсией тебе нужно развернуть список в дерево. и какая тогда разница разворачивать список в дерево массивов или же сразу в дерево html-элементов?
                                            • 0
                                              Ну я мня то с этим проблем нет у меня шаблонизатор на xslt и на нем линейный список легко с помощью рекурсии превращается в древовидный список.
                                              • 0
                                                и с не меньшей лёгкостью упирается в ограничение на глубину рекурсии и объём потребляемой памяти.

                                                а код шаблона для итератора будет даже проще, чем для рекурсии, ибо в последнем случае тебе приходится вручную выбирать детей из списка.
                                                • 0
                                                  Ну это не повод отказываться от рекурсии вообще. А ограничение в рекурсии нужно для того чтобы не образовался бесконечный цикл. А если у вам не хватает то значит это вам не подходит. А на xslt некоторые вещи просто невозможно реализовать без рекурсии там нет переменных.
                                                  • 0
                                                    это не достоинство рекурсии, а недостаток хслт. то, что в императивных языках решается просто и элегантно в нём реализуется через анус…
                                          • 0
                                            У вас там еще много высосаных из пальца проблем? Вы пишите, пишите, мы разберемся.
                                            • 0
                                              Там это где. Улыбнуло.
                                  • 0
                                    Level тебе для чего даден?
                                • 0
                                  Рекурсия там все равно есть, просто немного скрыта за счет того, что вложенность выражается неявно (с помощью интервалов).
                                  • 0
                                    Да, даже если ее там нет, мы найдем и внедрим!
                                    • 0
                                      Эх, Вы только подтверждаете стереотип о программистах PHP…
            • +1
              Я тот самый контингент, некоторое время назад программировавший на VB, да и сейчас он установлен, пользую, чтобы написать за 20 минут утилитку, которую не удалось найти.
              И сейчас я программирую на PHP. И пользуюсь рекурсией, мой текущий проект весь основан на огромной рекурсии одной функции.
              Да, я не занимаюсь производством высокопроизводительных систем. Но я знаю, что такое рекурсия, кеширование, и т.д.
              И задумываться о том, что PHP может быть медленным, начал после активного чтения хабра. Но на практике этого почти не чувствовал. Медленно работает? Правлю код, делаю его проще.
              Может, я неправильно понимаю этот мир, или чего-то недопонимаю, но мне хватает php c головой (пока хватает).
              И вообще, в уусловиях локалки общежития я както делал сайт на Visual Basic, в виде CGI приложения, и работал он нормально. И там тоже была рекурсия.
              Минусуйте.
              • +1
                читая ваши сообщение, складывается впечатление что вы любую задачу решаете через рекурсию )
                я уже давно работаю с Php, и применял рекурсию только несколько раз: работа с поддиректориями, xml…
                в остальных случаях прекрасно можно решать задачи без неё…
                • 0
                  ну не всегда, но в целом верно, что рекурсия очень редко по делу применяется
                  • 0
                    в пхп
                • 0
                  Чтото я тоже перечитал свои сообщения и подумал, что чтото я слишком часто упоминаю о ней.=)
                  Но в последних двух достаточно сложных проектах (тоесть include(«header.php»); не является сложным проектом) она использовалась.
                  А в целом вы правы. Чтото тут развязывается война. Надо быть проще.
                  На сайтах — визитках за 100$ (1000$) не нужна рекурсия. Там вообще ничего обычно не нужно.
                  Может, в самом деле я неправильно работаю?
                  Рекурсивно делаю крошки, делаю дерево сайта (список подстраниц, тамже список их подстраниц), страницу, на которой есть и крошки и дерево сайта, и список страниц (и то, и другое, и третье делается одной функцией).
                  Аналогично список форумов/разделов/топиков в развёрнутом виде.
                  Наверное я заработался.
                  • +2
                    Все нормально делаете.

                    Программы ведь для людей пишутся. :) Рекурсия и ФВП спасают жизни. Если будет тормозить — перепишете на явные циклы, делов-то.
        • 0
          Какой он нахрен практик, если столько раз рекурсией пользовался?
          Мне за последние 2 месяца она больше раз требовалась на 3 проектах.
          • –2
            Я сам «использовал рекурсию» в абсолютном понимании больше раз, но если функция сама себя вызывает пару раз, я не считаю это такой уж рекурсией. Вот когда весь алгоритм на этом построен, это да.
    • +7
      Он не говорит, что «значит никому не надо», он говорит, что это не так уж и важно, хотя его оппонент утверждает, что это чуть ли не первостепенной важности проблема.
    • 0
      Ну, если бы мне нужно было обходить дерево в пару млн узлов, я бы писал траверсер на чём-нить функциональном (Erlang, к примеру — он мне нравится). Другими словами — выбрал бы более подходящий инструмент.
  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      Все должно быть к месту.

      P.S.
      Оно таки в PHP осталось, но передавать по ссылке или нет решается при объявлении, а не при вызове. И это правильно.
  • +1
    >Моя 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
    • +1
      я пропустил момент, но щас прочита — прикольно на самом деле. аргумент не маловажный. Кстати исторически именно поэтому одинарные ковычки не экранированы, чтоб проще было писать струкрутно
    • 0
      переведите пожалуйста:

      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]
  • +1
    Мда, помимо того, что тут столкнулись теоретик и практик, тут скорее столкнулись пессимист и оптимист — один говорит, что не стоит юзать PHP из-за его недостатков, другой — что стоит юзать из-за его достоинств.

    В любом случае, я с ними обоими согласен и несогласен поровну, PHP далеко не самый выдающийся, продуманный и всё такое, что не мешает ему занимать свою немаленькую нишу.
    • 0
      Просто когда про недостатки пытаются сказать «это фичи» — то это ОЧЕНЬ подозрительно %)
      • –1
        А недостатки это и есть фичи. Просто эти фичи кому-то жить мешают, а кому-то помогают. Я так на любой язык могу нагнать, напридумывая его «недостатков», хотя это понятие весьма относительное.
    • +2
      Как там у Макаревича

      И двое сошлись не страх а на совесть…

      И каждый пошел своею дорогой
      А поезд пошел своей
  • +5
    Убило «PHP поощряет (практически требует) смешивание логики и представления». PHP: Hypertext Preprocessor (а не Web-Based App Creator) был создан именно для вставки его частей в код. ИМХО, вывод из этого — раз язык позволяет выполнять то, для чего он изначально создан, то он отвратителен.
    • +3
      Да, в общем-то, если именно про создание, то даже не PHP: Hypertext Preprocessor, а вовсе и Personal Home Page Form Interpreter. Собственно, в качестве интерпретатора форм домашних страничек он почти идеален :), но используется-то он сейчас не по назначению. И вот с точки зрения использования его не по назначению, эта «фича» — отвратительна. Как-то так :)
  • +6
    Изменения в языке зачастую становятся известны за месяцы, а то и годы до их реализации.
    Так должно быть. А как на практике? А вот как:
    1. Выпускается изменение в bug-fix релизе, которое ломает кучу скриптов.
    2. Никаких упоминаний об изменении в release notes нету.
    3. Реакция разработчиков "Fix your scripts! We do not care, the fix on our part was needed!" — испытал лично на своей шкуре.
    Извините, но это не называется существует migration guide в котором описаны все различия. Это называется «что хочу — то и ворочу». Я после этой перебранки отказался от PHP в новых проектах совсем, а в старых — настолько, насколько позволило время, но судя по многочисленным сообщения на различных сайтах ничего в позиции разработчиков не изменилось с тех пор…
    • +2
      а вы пишите код не на хаках — все работать и будет замечательно. Я писал скрипты еще на 4-ке и на 5.1 и ничего, все работает до сих пор. При этом не могу сказать что у меня там все просто.
      Ну вот стоит перед вами выбор писать наподобие:
      preg_replace("/(<\/?)(\w+)([^>]*>)/e", "'\\1'.strtoupper('\\2').'\\3'", $html_body);
      или использовать preg_replace_callback. так выберите второе — вас потомки добрым словом вспомнят.
      таких примеров масса. Следуйте рекомендациям «хорошего» кода и 90% проблем изчезнет.
      ну а то что PHP зависим от расширений, так это понятно, но не является минусом потому что в обновления и релизы включаются только стабильные версии, косяки очень редки и оперативно фиксятся
      • +8
        А вы пишите код не на хаках — все работать и будет замечательно.
        Перевод с русского на русский: язык — дерьмо, но и на нём можно сделать неплохую вещь. Да, можно, но зачем?

        Есть такое понятие 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% проблем изчезнет.
        Знаете — это напоминает примерно следующую рекламу:
        Купите дом — с отличной лужайкой перед домом! Мягкая трава — вашим детям понравится! Правда в среднем через каждый метр там противотанковая мина закопана, но вы не беспокойтесь — у нас есть буклет и там нарисованы места, где мин точно нет. Ну а в других местах ходите осторожнее: мины противотанковые, срабатывают не каждый раз — может быть и пронесёт.
        Кому нафиг нужна такая лужайка?
        • 0
          вы убежденный фанатик — отказываюсь в таком ключе с вами разговаривать.
          если вы опустились до фраз: «язык — дерьмо», то очевидно что вы просто холиварщик.
  • +1
    Мне нравится ПХП, но с автором статьи во много не согласен.

    Имхо:

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

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

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

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

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

    6) Да понятие «производительность языка» какое-то абсурдное. Производительность может быть у интерпретатора, у исполняемого файла, в зависимости от того что за компилятор его собирал. Так что производительность это не проблема языка, это проблема конкретной реализации его интерпретатора.
    • +4
      Я уже который раз слышу «РНР — это не только веб».
      А можно пример — где еще активно используется РНР? В принципе, ничего толкового для standalone приложений там нет.
      • 0
        В моей конторе делали систему организации, обработки и хранинения музыки на PHP
        • 0
          Если не коммерческая тайна — можно чуть подробнее. Что из себя представляла система? Что значит организация и обработка? Что использовалось для создания GUI? Как решили проблему отсутствия нормальной работы с потоками? Я так понимаю, система была — клиент-сервер?
          • +1
            Система обработки музыки…
            Например приезжал винчестер набитый музыкой с торрентов.
            Нужно было выбрать только ту музыку, которая подходит по формату и которой не было в базе данных. Аккуратно рассортировать это всё по папочкам на сервере, обработать напильником теги и залить всю инфу о музыке в базу, для работы модераторов. Не спорю, что можно было много процессов написать на С, но всё, кроме конвертора было написано на чистой Пехе. Проект жив до сих пор
            • 0
              И кстати, очень успешен :)
              • 0
                Да, весомо :) Убедили
              • 0
                Санек, не пали контору
                • 0
                  О! И ты тут :)
                  Имён не называю :)
      • 0
        Применение языков программирования не ограничивается только веб- и десктопными (я думаю, Вы их имеете ввиду под standalone) приложениями.
        У меня, например, много скриптов делающих те или иные функции (обрабока БД, резервное копирование и т.д.), запускаемые вручную или по крону. PHP это же в первую очередь скриптовый язык.
        • +1
          Я прекрасно понимаю, что не ограничивается.
          Но одно дело — когда вы пишете скрипт, который облегчает лично вам жизнь. Другое — когда на языке ведется разработка какого-то продукта. Вот тут и начинается беда у РНР. Работает команда — а в языке ни модулей нормальных, ни пространств имен, а только мусор из функций.

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

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

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

          Так что есть определенная ниша — веб-приложения. В ней РНР твердо стоит на двух ногах и вытолкать его оттуда еще долго не получится. Но и выглядывает он оттуда очень редко.
          • 0
            Лёха?
          • 0
            В написанном с Вами трудно не согласиться. Но Вы тут же сами говорите «PHP не только веб» :) Пхп хороший, добротный скриптовый язык.
            • 0
              А чем он лучше других скриптовых языков? Вот в чем вопрос!

              ЗЫ конечно, имеется в виду его ниша не в области веба
              • НЛО прилетело и опубликовало эту надпись здесь
          • +1
            ну кстати модули вам может заменить грамотные внутренние соглашения именований, и в ближайшее время они будут введены.
          • 0
            для winCE есть hph
      • –1
        я писал систему складского учета в интранет.
        а так самый популярный пример PHP My ADMIN вы же не будете утверждать, что управление БД это чисто сетевая задача? Хотя эти примеры именно работают под интернет серверами.
        Есть множественные примеры когда мой знакомый админ писал всякие скрипты настройки / управления / профилактики на PHP потому что как он говорит это понятнее чем ПЕрл
        • 0
          Ага, только MyAdmin — это програмка, для «зайти по http(бо иначе никак не выходит) и по-быстрячку что-то поправить ручками или запустить скрипт».

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

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

      P.S. И как и в случае с другими подёнками останутся хорошо оплачиваемые рабочие места по поддержке всего этого безобразия… и даже небольшой количество приличных проектов, созданных на нём не благодаря, а вопреки свойствам этого убожества…
      • +7
        Время покажет.
  • +3
    Не переубедили — совсем наоборот :) язык неважнецкий
  • –1
    Очередно холивар, блин почему так сложно принять, что каждый пользуется тем, что больше нравится…
    нравиться пхп пользуйтесь… не нравится… вбивайте статику через блокнот, пишите на асп, яве, да хоть на ассемблере… зачем раздувать религиозные войны????
    • +2
      Польностью с Вами согласен. Если бы каждый занимался своим делом, то на написание такой бесполехной статьб времени не было бы…
  • НЛО прилетело и опубликовало эту надпись здесь
    • +3
      рор, это не язык программирования — это фреймворк, написанный на 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
      • НЛО прилетело и опубликовало эту надпись здесь
        • +7
          гугл скетчап, qt-ruby, для десктопных приложений, скриптов коммандной строки, у него масса применений и рельсы это только малая часть…
          • НЛО прилетело и опубликовало эту надпись здесь
        • +1
          Например у меня в курсовике: plasmon.rghost.ru/66976.image
        • 0
          Я только сегодня написал на ruby нужный мне апплет для gnome.
          • НЛО прилетело и опубликовало эту надпись здесь
            • +2
              Вы спросили где используется руби без рельс — я ответил. Не понял вашего возражения. Вы хотите знать где используется руби без рельс в веб-разработке? Пожалуйста: Merb, Sinatra, Camping, Mack и т.п. + Capistrano, Starling, Puppet и куча других полезных инструментов на руби, очень нужных при веб разработке.
              • НЛО прилетело и опубликовало эту надпись здесь
  • +5
    1. ИДЕ упрощают написание кода, но не его чтение.
    2. возможность написания «спагетти» — это самый главный недостаток языка. ибо кроме того кода, который пишешь ты, есть много больше когда, написанного друими, с которым тебе тоже рано или позно придётся иметь дело.
    3. передачу по ссылке никто не отменял. более того — объекты теперь по умолчанию передаются именно по ней. всё как у взрослых! ;-)
    4. рекурсия — зло. конечные автоматы рулят.
    • 0
      Про 4-й пункт это вы, например, функциональным языкам расскажите. :) Кроме того, есть множество задач, где рекурсия лучший выбор.
      • +3
        машина тьюринга, афайк, не функциональна чуть менее чем полностью. и первоочередная задача компилятора любого функционального языка — впихнуть невпихуемое — рекурсию в конечный стэк. в ряде случаев от рекурсии избавиться удаётся — это называется «хвостовая оптимизация».
        • 0
          Все завесит от того что больше нужно большая скорость выполнения или большая скорость разработки. За частую проще и быстрее сделать рекурсию но на вызов функций тратится лишнее время. Но вот как то нужно было на флеше as2 сделать одну задачу так с помощью рекурсии она делалась очень просто, но во флеше ограничение на глубину вложенности :(, пришлось делать сыклами так я блин целый день провозился.
          • 0
            Мне пришлось переписывать админку одного интернет-магазина потому, что разработчики пошли по лёгкому пути рекурсии. Когда ассортимент вырос и счёт пошёл на десятки тысяч, скрипт вывода дерева товаров банально упёрся во время выполнения. Переписал без рекурсии — скорость выросла в десятки раз. При этом данный програмный продукт продолжает успешно продаваться. Пихание рекурсии куда попало, чтобы ускорить разработку, не думая о последствиях — это и есть быдлокодинг.
            • +1
              Нет это называется оптимизация. С начало пишеш чтобы быстрее написать(не забывая о правильном и масштабируемом коде ) а потом оптемизируеш критические места. Не у всех ведь такой а сортимент по этому это частный случай. И вы уверены что дело было в рекурсии вызова функций а не в большом количестве запросов к базе в этих функциях.
            • 0
              Это был OSC, не так ли? ;)
          • 0
            пример, где рекурсия выглядит проще.
            • +2
              fact 0 = 1
              fact x = x * fact (x-1)

              Ваш черед. Напишите факториал, используя циклы и побочные эффекты.
              • –2
                хм… у вас в примере псевдокод. Если уж сравнивать решения — то уж и пишите тогда честно — на PHP (вроде о нем же речь). И тогда когда получите ответный код на том же PHP без рекурсии — будем смотреть, что проще :)
                • +3
                  Я тут заметил наезды на рекурсию в веб-разработке, а не в PHP. Может, я ошибаюсь.

                  Кстати, приведенный «псеводокод» это Хаскель. И этот код можно запустить, он работает. :)
                  • –2
                    Вы считаете факториалы в веб-разработке? О_о Хотел бы я посмотреть на такие сайты, где это нужно :)
                    • +2
                      Ну это же всего лишь пример!

                      А в веб-разработке я пользую свертку списка (точнее, ее обобщение, используемое в Takusen). Эта штука невозбранно рулит.
                      • +1
                        Про пример понятно, это была шутка. Просто речь шла об очевидности. То что вы написали — да, вполне очевидно. Но как вы сами указали — на Хаскель (не знаю этого языка, хотя написанная вами конструкция вполне понятна, что и вызвало у меня аллюзию на псевдокод, сорри если оскорбил хаскелистов :) ). Мой спич был несколько о другом: обсуждается 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;
                        }

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

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

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

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

                          Пример с несколькими условиями выхода в студию!
              • +1
                Этот как раз тот пример, где циклом проще.
                • +1
                  Проще? Циклы завсегда сложнее рекурсии.
              • +2
                ( 1… x ).inject( 1 ){ | res, numb | res * numb }

                или

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

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

                  fact x = product [1..x]

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

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

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

                  Это уже другой вопрос. Я хорошо показал, что рекурсия проще цикла в этом отдельно взятом случае, ящитаю.
                  • +1
                    или вот так:
                    ( 1… x ).product
                    =)

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

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

                      Главное ведь, что с помощью рекурсии проще. ^_^
                      • 0
                        «факториал х — это произведение чисел от 1 до х»
                        «факториал х — это произведение x на факториал x-1, но факториал 0 равен 1»

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

                        человеку куда проще оперировать состоянием, чем вычислять функции.
                        • +1
                          > какое из этих определений проще?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                  ЗЫ от темы разговора что-то далеко ушли: засчитываю за слив.
              • 0
                ваши проекты без вычисления рекурсии не работают? ))
                • 0
                  Текущие не работают. Вы меня поймали :)
        • 0
          У всех известных мне языков с императивной семантикой проблемы с рекурсией. Поэтому если она так сильно нужна — следует подумать о каком-нибудь функциональном языке, Haskell например.
          К которому, кстати, активно присматриваются разработчики Unreal Engine.
          • –1
            а у рекурсии проблемы с современной архитектурой компов. может ну её эту рекурсию вместе с тормозным анрилом?
            • 0
              Не получиться. Как заставить среднестатистического быдлокодера разворачивать рекурсию в цикл?
              • 0
                при первом же повторном входе (без выхода) в одну и ту же функцию — падать с ошибкой. мигом научатся ;-)
                • 0
                  В таком случае — этот язык будет мертв для серьезных задач, когда лезть на более низкий уровень (цикл for, переменная-индексатор массива) не только не хочется, но и отрицательно сказывается на читабельности кода и производительности программмиста (быдлокодеров до серьезных задач не допускают).
                  Лучше, хотя и сложнее, написать компилятор, который это делает автоматически.
                  • 0
                    да ладно =) свёртки списков и деревьев вполне себе читаемы.
                    • +2
                      Это частный случай. В общем случае удаляя рекурсию мы лишаемся мощного средства абстракции.
            • +2
              У современных компов нету проблем с рекурсией.

              Все проблемы — они в головах людей.
  • +15
    В то время когда создавался PHP, это был действительно хороший язык. Он позволял быстро и легко создавать динамические веб-странички, обладая минимальными познаниями в программировании, в отличие от того же перла. Именно это и обеспечило его популярность. Это же обеспечило и огромное количество быдлокодеров. Некоторые быдлокодеры почитали умные книжки, перестали писать говнокод, и подарили миру более-менее качественные PHP-фреймворки, которые позволяют создавать что-то более сложное чем домашние странички.
    Но даже если использовать PHP-фреймворки, вы все равно будете писать на PHP. А все перечисленные в статье недостатки можно описать одним словом — этом дизайн языка. И у PHP он действительно ужасен. Сейчас не 1994 год — не хотите писать на перле, берите Python или ROR. Раньше сравнивая языки программирования люди сравнивали их функциональность, теперь же, когда функциональность современных динамических ЯП практически одинакова, имеет смысл сравнивать их дизайн. Посмотрите на import this в пайтоне — есть ли что-то подобное в PHP? PHP был создан для облегчения создания домашних страничек — Personal Home Page, этим и определяется его дизайн.
    Умные люди не пишут кластеры на Visual Basic'e, GUI-приложения на Фортране, а сложные веб-приложения на PHP. Даже если язык и позволяет это сделать.
    А то что разработчики PHP продают к нему акселератор — это полный маразм. Зачем пользоваться языком, разработчики которого заинтересованы в его тормознутости?
    • НЛО прилетело и опубликовало эту надпись здесь
    • +2
      > Умные люди не пишут кластеры на Visual Basic'e, GUI-приложения на Фортране, а сложные веб-приложения на PHP
      Это вы зря… Когда дело доходит до бизнеса, а в 99.9% всех случаев когда что то программируется — это — бизнес, бизнесмен решает — на что вложить деньги. И выбирает не то, что мегаправильно и красиво, а то, что позволит получить продукт быстро. Куча стартапов пишется на чем? На PHP! Потому что стоимость разработки — маленькая по сравнению с теми же Java или C#, Ruby и т.д, и есть масса специалистов, наработаны решения по устранению узких мест в виде кеширования и кластеризации. И все это почти даром. Да, когда идет речь о программировании Just for Fun — то да, там народ все делает от души и красиво. И не на PHP. Но рассматривать язык только как дизайн — это подход разработчика, но не бизнесмена.
      • 0
        > Когда дело доходит до бизнеса, а в 99.9% всех случаев когда что то программируется — это — бизнес, бизнесмен решает — на что вложить деньги. И выбирает не то, что мегаправильно и красиво, а то, что позволит получить продукт быстро.

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

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

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

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

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

        > И не на PHP.

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

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

        Если язык в начале проекта выбран неправильно (т.е. его дизайн и возможности не в полной мере соответствуют задаче), накладные расходы по мере развития проекта будут увеличиваться, и рано и поздно настанет момент, когда все придется переписывать на другом языке.
        • +1
          А как тогда объяснить существование больших проектов на пхп с огромным количеством задействованных узлов под колоссальной нагрузкой? facebook, vkontakte итд? Понятно, что быдлокода количество просто огромное. Но может дело все-же в неумении пользоваться инструментом?
          • 0
            Фейсбук и вконтакте — это относительно простые странички: никаких замудреных алгоритмов там не используется, логика — примитивна. Все, что нужно — докупать сервера для кластера.
            • +1
              >>Не представляю себе кластеризацию на PHP. Речь идет о веб-сервере?
              вот на это скорее ответ.

              По поводу простоты страниц, да, они простые. Когда ими пользуются 1000 человек. А когда миллион или десять миллионов в онлайне, то алгоритмы там несколько отличаются. Как минимум middleware для шардинга уже будет далеко не простым. Не говоря уже о многоуровневом кешировании и фишках типа «друзья в онлайне» для миллиона юзеров на сайте.
              Как видите, при правильном подходе и правильных программистах, никаких проблем с кластеризацией и масштабируемостью и пхп нет.
              • 0
                Речь не про то. Речь о выразительных способностях языка и области его применения. Могучие системы никто не пишет целиком на C. Критичные к производительности — не пишут на Джаве. Сложную логику в больших приложениях — на ПХП. Важно знать что требуется и выбирать инструмент(ы) исходя из задач.
                Алгоритмы там принципиально отличаться не могут: те же «друзья в онлайне» есть выборка из отображения первого порядка, которое рассчитывается определенным образом. Тут нужно просто минимизировать запросы к базе данных: входит человек на сайт — надо где-нибудь сохранить (не в БД) этот факт, чтобы в последствии отобразить его друзьям этого человека с списке «онлайн». Если минимизировать запросы к БД и прикрутить систему кеширования, то ПХП спокойно будет генерить странички для миллионов людей, только оперативку и быстрые харды подноси. Ну и про канал не забыть.
    • 0
      Каждой задаче — свой инструмент.
  • +8
    Жуткий быдлокод народ пишет даже на C/C++, Java и Delphi — не смотря на всю их строгость. Порой доходит до такого маразма, что PHP и не снилось. 90% — ошибка в ДНК, а не в том, что PHP плохой или хороший — он просто есть, он просто работает и, как было уже отмечено, в хороших руках практически не глючит и ничего не рушится от обновления (а глюки можно поиметь где угодго — чего стоят эпопеи с компилированием одного и того же кода на том же C++ под разными компиляторами и порой разной реализацией конкретных вещей, т.к. в спецификации написано «реализацию оставляем на совести разработчиков компиляторов», что приводит к глюкам)
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Я о том, что правильная ДНК позволяет программисту писать код, который нормально скомпилируется на большинстве компиляторов (ну бывают случаи полной несовместимости) — хотя я считаю маразмом то, что под каждый компилятор приходится подстраиваться.
    • –1
      А если руки хорошие, то зачем программировать на PHP? :)
      • +1
        Потому что быстро и удобно. При прямых руках на PHP практически любой WEB проект делается быстрее всего.
        • 0
          В принципе быстрее всего делается на том, на чем больше всего навыков. Но вот з/п у php программистов ниже будет. Да и с удобностью я бы поспорил, но это какой-то холивар получится.
  • +4
    Многие в комментариях называют пхп-кодеров = быдло-кодерами, и типа они незная ничего лучше и из-за низкого порога вхождения пишут именно на ПХП… на собственном примере знаю что это не так.
    Программист должен эволюционировать!
    Я начинал с Perl.
    Когда познакомился с Php и оценил его плюсы и быстроту разработки, пересел на него.
    Сейчас наслаждаюсь Java, Jsp…
    Далее смотрю в сторону Python.

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

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

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

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

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

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