[PHP] а какие реальные пролемы появлялись у Вас при работе с PHP ?

Ну я думаю для больших проектов благоразумнее будет использовать perl(хоть и с костылями) в плане производительности.

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

Хотя бренчи тоже можно провести...

Мутота с массивами была несколько раз, из-за индексов.

Некоторые проблемы с возвращаемыми значениями и преобразованием типов.

Отсутствие удобной работы с функциями как объектами первого класса.

1) Юникод

2) Многопоточность

3) Никакущее управление памятью

вот тебе пример:

Лет пять назад что-то писали для чегото. Сейчас купили новый сервер и стали всё переносить на новую систему. это что-то вывалило кучу deprecated например на функцию split(), которая много где в этом чёмто использовалась. Спрашивается зачем было деприкейтить split?????

> Мутота с массивами была несколько раз, из-за индексов.

Неразделённость hash'ей и array'ев? Хз не вижу чем оно может грозить. Хотя, если использовать $ary[] = $some_value может интересное получится.

Некоторые проблемы с возвращаемыми значениями и преобразованием типов.

Уже пройдено. Когда начинал - тоже путался.

Отсутствие удобной работы с функциями как объектами первого класса.

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

проблемы были в PHP4 и в ранней пятерке. сейчас их для меня нет.

нет пхп - нет проблем? :)

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

Вот это реальная проблема.

А ещё:

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

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

Неинициализированные переменные. Ворнинги всплывают не всегда.

Юникод, ага.

Фреймворки говно, программисты придурки.

>а какие реальные пролемы появлялись у Вас при работе с PHP ?

стал плохо спать

http://nuclight.livejournal.com/107170.html

Нет нормальной IDE. Нет неймспейсов. Синтаксис как у перла, хрен что поймеш. Подключение модулей и повторное использование кода через *опу. Корявое ООП. И вообще php потеряла свой козирь языка-шаблонизатора после прихода в веб MVC.

Классная статья, спасибо. Много ржал, много думал.

+500

Нет нормальной IDE

А надо ли + у них вроде phpedit (или как-то так есть)

Синтаксис как у перла

ненене. У перла скаляры, массивы, хеши не идут с одним префиксом. Да и back-функций нет...

Корявое ООП

хз, я съел

MVC

Первую часть(M) почему-то не удаётся использовать. Предрассудки?

> http://nuclight.livejournal.com/107170.html

2006-02-05 03:36:00

Вообще да, первые версии крылись матом. А вот с 5.2 (на мой взгляд) - уже брезентом.

>Нет нормальной IDE.

Netbeans

Нет неймспейсов.

Выходите из холодильника

Синтаксис как у перла, хрен что поймеш.

Синтаксис как у С(Java, Python, Ruby, ...), хрен что поймешь.

Подключение модулей и повторное использование кода через *опу.

Это вы о чем?

Корявое ООП.

Точно, пора выйти из холодильника.

И вообще php потеряла свой козирь языка-шаблонизатора после прихода в веб MVC.

Удивительное - рядом.

>Неразделённость hash'ей и array'ев? Хз не вижу чем оно может грозить.

Неудобно, местами очень. Например нельзя массив в общем случае обойти по индексам через for, только через foreach. Соответственно и получить доступ к элементу массива по индексу тоже не всегда возможно. Вопрос не в том, что это баг или что-то другое, вопрос в том, что правда бывает неудобно.

$ary[] = $some_value

Такое часто приходится использовать.

Уже пройдено. Когда начинал - тоже путался.

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

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

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

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

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

Это всё я говорю в условиях «правильного» программиста, про пхп-быдлокод, я думаю, говорить даже не стоит.

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

>> http://nuclight.livejournal.com/107170.html

2006-02-05 03:36:00

Четыре с половиной года прошло, а почти ничего не исправлено.

>>Корявое ООП.

Точно, пора выйти из холодильника.

нет полиморфизма по методам классов, т.к. неизвестны типы параметров

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

нет годной системы пакетов, и не спасут неймспейсы. анализ наследования - ад. Реурсивные скрипты!!11

юнит-тестирование быдлокода (который у PHP - стандарт) - жесть.

многопоточность для объектов не раскрыта

ООП? Где ООП?

//или мой морозильник простоял слишком долго?..

>>Синтаксис как у перла, хрен что поймеш.

Синтаксис как у С(Java, Python, Ruby, ...), хрен что поймешь.

А вот и нет, на самом деле синтаксис как у паскаля. даже элементарное foo(bar()['zagzag']) нельзя сделать.

Корявое ООП.

Точно, пора выйти из холодильника.

Ты ООП нормальное видел? Алсо, оверхед такой что мама не горюй.

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

Я выше описал недостатки. Пока сам пишешь - норм, но влезут ламера и привет.

> Netbeans

сам пользовался? уверен?

Нет неймспейсов.

Выходите из холодильника

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

Синтаксис как у С(Java, Python, Ruby, ...), хрен что поймешь.

сравнил синтаксис си и пайтона, вот шутник. синтаксис пхп содран с перла, это трудно не заметить.

Корявое ООП.

Точно, пора выйти из холодильника.

привезли свежие костыли, а я прозевал.

На тему массивов, с вышеуказанной ссылки. Не стоило таки смешивать hash и array.

php > $foo = array();

php > $foo[4] = 4;

php > $foo[2] = 2;

php > foreach ($foo as $var) { print $var; }

42

> Алсо, оверхед такой что мама не горюй.

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

Ну, у нас на лоре даже жаба с лиспом обгоняют си. Бенчмарки такие бенчмарки.

Функциями PHP нельзя правильно узнать размер файла.

PHP Manual

Замечание: Поскольку PHP использует знаковое представления для чисел целого типа, а многие платформы используют 32-битные целые числа, функция filesize() может возвращать неожиданные значения для файлов, чей размер превосходит 2 Гб. Если размер файла находится в пределах 2 - 4 Гб, корректное значение можно получить, используя конструкцию sprintf(«%u», filesize($file)).

overflow на 2Гб. Будем знать.

нету классов, которые дублируют типы данных встроенные, всё ООП идёт лесом...

>>1) Юникод

впилили вроде уже, в 5.3

> Четыре с половиной года прошло, а почти ничего не исправлено.

http://www.linux.org.ru/jump-message.jsp?msgid=5260740&cid=5263010

> назови авторитетные проекты где они используются.

ну, например - http://www.doctrine-project.org/ - т.е. все проекты которые юзают Doctrine.

>1. Бессистемное именование функций, нелогичные аргументы и возвращаемые значения

2. Чрезмерно большое количество глобально видимых функций

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

5. Недостатки языка

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

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

Ну ты одинок в этом.

6. Пригодность к разработке серьезных приложений [2, 3, 4, 5, 6, 8].

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

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

ну-ну. это проблемы не языка а быдлокодеров.

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

Я иногда просто охреневаю, зачем нужен этот PHP, если есть куча CFML-движков (Railo, BlueDragon), у которых многих его проблем нет, да и синтаксис попроще.

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

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

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

инструменты есть.

Какие? Например, switch может выдавать варнинги, если не перечислены все элементы enum'а? Ах да, енумов же нет.

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

Даже на ассемблере это проще.

У меня проблема номер один - невозможность запретить присваивание неописанным переменным. Типа, как use strict в Perl'е. Иногда из-за этого вылезают ошибки. Напишешь в одном месте «$vsr = ...» вместо «$var = ...» - и потом долго отлаживаешь, что к чему...

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

>Ну я думаю для больших проектов благоразумнее будет использовать perl(хоть и с костылями) в плане производительности.

Я в своё время с Perl на PHP слез именно из-за того, что DBI в Perl работал в 9(девять) раз медленнее, чем mysql_* функции в PHP :) Не смотря на то, что числодробильно тогда Perl был вдвое быстрее, это и решило выбор.

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

Проблема в отладке. Не знаю, как хорошо это организрвать. Как ни сделаешь - везде клин.

> Какие?

зависит от конкретных задач. а так, в двух словах - механизмы аналогичные существующим в других языках. исключения, ООП и прочее.

Мутота с массивами была несколько раз, из-за индексов.

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

$s = "abc";
var_dump($s['test']);

>1) Юникод

А что с ним не так?

2) Многопоточность

3) Никакущее управление памятью

Это задачу берёт на себя web-сервер. И на практике она не всплывает. Кстати, в 5.3, вроде бы, с 3-м пунктом сильно переиграли. Но пока не щупал.

>Лет пять назад что-то писали для чегото.
[...]

это что-то вывалило кучу deprecated

Это ты про python? :) [как меня задрали массы depricated в последних версиях...]

Неразделённость hash'ей и array'ев?

Это, кстати, огромный бонус для меня. Позволяет задавать описания в духе:

function table_fields()
{
    return array(
        'id',
        'title',
        'create_time' => 'posted',
        'is_deleted' => array('name' => 'deleted', 'type' => 'checkbox'),
// ...
    );
}

Это задачу берёт на себя web-сервер.

т.е. чтобы делать конкурентные вещи нужно писать модули для веб-сервера? о_О

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

Пардон, но это уже задача шаблонизатора. Что за «Штатные средства создания шаблонов»? В каком языке есть такое? :)

Неинициализированные переменные. Ворнинги всплывают не всегда.

Всегда, кроме присванивания. Увы, но даже в python так же.

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

Ну и чем объект хуже структуры? Даже в Си++ это практически одно и то же.

Юникод, ага.

А точнее?

Фреймворки говно, программисты придурки.

Не стоит свои проблемы проецировать на весь мир :)

>Нет нормальной IDE

Да есть целый ряд :) Начиная от Zend Studio, кончая vim'ом.

Нет неймспейсов

Есть в 5.3 Но ублюдочный, да. Хотя меня эта проблема не беспокоит, я для себя давно сделал очень удобный workaround этой проблемы :)

Синтаксис как у перла, хрен что поймеш

Это ты про что-то другое, явно :D

Подключение модулей и повторное использование кода через *опу.

Тоже про какой-то другой язык.

Корявое ООП.

А точнее?

И вообще php потеряла свой козирь языка-шаблонизатора после прихода в веб MVC.

Не знаю. У меня всюду жёсткий MVC. Никаких проблем, одни ништяки :) Думаю, тут не в языке дело...

function table_fields() 
{ 
    return array( 
        'id', 
        'title', 
        'create_time' => 'posted', 
        'is_deleted' => array('name' => 'deleted', 'type' => 'checkbox'), 
// ... 
    ); 
} 

Что-то не разберусь, что это значит. Пояснишь?

>Например нельзя массив в общем случае обойти по индексам через for, только через foreach.

Ну, ты уж про себя разберись. Если это массив, то по for прекрасно проходится. Но зачем for, когда есть foreach? :) Ты в ruby тоже всё по for будешь проходить? Да и в python... :D

Соответственно и получить доступ к элементу массива по индексу тоже не всегда возможно.

Как это? Есть индекс - есть доступ.

$ary[] = $some_value

Такое часто приходится использовать.

Постоянно. И никаких проблем :D

Опять же, если всё знаешь, то всё ок, но сам подход нехорош - надо много запоминать того, что к программированию имеет косвенное отношение.

Это в _любом_ языке так.

Ну вот, опять же, ===. Костыль абсолютный, неужели нельзя было придумать что-нибудь получше.

Гы. Лучше такой костыль, чем полное его отсутствие, как в том же Си ;)

Просто лямбды являются отличным способом сэкономить кучу времени и кода

Ну так я, например, их часто использую :) create_function() замечательно работает, если нужно ехать, а не шашечки.

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

И я использую эту задачу постоянно и много лет.

В той же джанге

Ой, не надо... :D Django - это ужасно :D Там, где у меня всё делается одной строчкой, в Django часто требует пять, если не 10...