перечислите недостатки PHP

Лисп рулет!

PHP не энтерпрайз.

> PHP не энтерпрайз.

зато "глобально и надежно" :)

[deadly serious mode on] он слишком сложен для пионеров. слишком много надо держать в голове, что бы не сделать сильно дырявый и глючный код. еще больше надо держать в голове что бы сделать год, который в последствии можно будет переделать. [deadly serious mode off]

Нельзя грабить коров Анны.

>> Нельзя грабить коров Анны.

А с самой Анной что делать? Не оставлять же девушку без внимания :)

До 5-го поддержка ООП была сильно ограничена. Сейчас проблемы с константами классов и наследованием, и ещё с несколькими вещами...

> Сейчас проблемы с константами классов и наследованием, и ещё с несколькими вещами...

..в том числе -- тормозит код на классах как змеиная задница.

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

поехали:

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

2) недооп: нету virtual table, все статик методы биндятся к имени класса, в котором они определены.

3) php пытается стать универсальным языком, отходя от web и поддерживая gtk,qt,windows api. но это, в принципе, опять же никому не нужно и делает говноязык более рамоздким, отводя его от веба.

4) хранить get/post queries в *global* массивах - это вершина идиотизма

5) где нативный супор юникода?

6) где чёртовы неймспейсы? как избежать конфлакта переменных в огромном проекте без чёртовых нейм спейсов?

7) где ссылки, хотя бы жалкое подобие ссылок?

8) сама семантика языка крайне ужасна, объектная система - полное говно, язык развивается пухлыми коррозионными наростами, делаясь всё тяжелее и тяжелее.

Нет поддержки Unicode - я рассматриваю это как самый главный недостаток, делающий PHP практически неуместным в современном мире.

Также: - Пёстрая библиотека - Недостаточно строгая типизация - Отсутствие кроссплатформенных библиотек для создания консольных (ну там позиционирование курсора и т.п.) и оконных приложений

> 4) хранить get/post queries в *global* массивах - это вершина идиотизма

а в чем проблема?

> 7) где ссылки, хотя бы жалкое подобие ссылок?

language.references.html

Ссылки в PHP дают возможность двум переменным ссылаться на одно содержимое. Например:

<?php $a =& $b; ?>

PS. на что мне посмотреть для web-dev'а ?

> где нативный супор юникода?

mbstring спасёт отца русской демократии. Нативная поддержка будет в PHP6.

> как избежать конфлакта переменных

Используя нормальную модульную структуру.

> а в чем проблема?

а вы вспомните, сколько security holes было найдено именно благодаря таким вот мега smart массивам.

ну и, к слову, http://www.sitepoint.com/print/php-security-blunders

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

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

> на что мне посмотреть для web-dev'а ?

я уже года 3 или больше серьёзно не занимался вебом, но тем не менее могу посоветовать вот что:
1) php нужно знать. знать его нужно потому, что он всегда обеспечит кратковременной не пыльной удалёнкой.
2) jsp нужно знать. потому что он всегда обеспечит даже долговременной более высокооплачиваемой удалёнко + найти более высокооплачиваемую работу, нежели на пыхе, зная jsp проще, благо ынтырпрайз.
3) имхо, наиболее вкусные для ковыряния по фану вещи - ror & python for web. имхо, в скором времени они пых задавят.

> mbstring спасёт отца русской демократии. Нативная поддержка будет в PHP6.

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

> Используя нормальную модульную структуру.

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

> ror

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

> Ссылки в PHP дают возможность двум переменным ссылаться на одно содержимое. Например:

это саавсем не то. если есть задача разобраться с php и чего-то на нем написать -- ты с этим еще намучаешься.

> PS. на что мне посмотреть для web-dev'а ?

пиши на php5, не заморачивайся с php4.

error_reporting(E_ALL); // с самого начала ini_set('display_errors', true); if(ini_get('register_globals')) die('too bad to be true);

и дофига разного рода прочих тонкостей, про которые надо помнить.

>ну и, к слову, http://www.sitepoint.com/print/php-security-blunders

изучаю

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

умеют: functions.variable-functions.html

>3) имхо, наиболее вкусные для ковыряния по фану вещи - ror & python for web. имхо, в скором времени они пых задавят.

эх, я так и не определился с какого из них начинать =) пусть будет python.

> Ruby сырой сам по себе

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

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

http://www.martinicity.net/articles/2006/07/15/ruby-namespace-conflicts

>> Ссылки в PHP дают возможность двум переменным ссылаться на одно содержимое. Например:

> это саавсем не то.

поясните

> ну и, к слову, http://www.sitepoint.com/print/php-security-blunders

да, вот это вот все тоже надо понимать и учитывать.

> поясните

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

скажем:

function a(& $b = null) {}; // нельзя

function a(& $b) {};
a(other_func($c)); // нельзя

a("aaaaa"); // нельзя

и т.д. и т.п.

> mbstring спасёт отца русской демократии. Нативная поддержка будет в PHP6.

Зачем ждать в 6й версии тех чудес, что обещали в пятой? Нативная поддержка Юникода уже есть в Java и .Net, а пых по производительности ничем не лучше этих платформ.

Так что сегодня вопрос о том, чем плох Пых уже не стоит, скорее уже стоит вопрос - а нах нужен пых?

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

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

> а нах нужен пых?

он есть.

>это непохоже на указатели в C или любом [более]другом языке.

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

потому:

1й пример отваливается
2й пример:

function &returns_reference()
{
return $someref;
}
$newref =& returns_reference();

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

проблема пыхных ссылок вот в чём:

<<References in PHP are a means to access the same variable content by different names. They are not like C pointers; instead, they are symbol table aliases. Note that in PHP, variable name and variable content are different, so the same content can have different names. The most close analogy is with Unix filenames and files - variable names are directory entries, while variable contents is the file itself. References can be thought of as hardlinking in Unix filesystem.>>

http://ru2.php.net/references

т.е. построить нормальную ссылочную структуру данных a la дерево или, скажем, граф у меня, конечно, получится, но с жуткими ограничениями.

> ссылка - это ни разу не указатель..

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

>т.е. построить нормальную ссылочную структуру данных a la дерево или, скажем, граф у меня, конечно, получится, но с жуткими ограничениями.

хочется обсудить =)

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

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

вроде все

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

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

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

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

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

Вобщем правды нету:)

проблема в использовании ссылок в дереве. представьте себе, что item суть огромная структура данных, вам нужно записать его в item нового элемента. вы хотите записать его в кач-ве ссылки, чтобы структура целиком не была скопированна. но поскольку сслка всего лишь некоторая запись в *symbol table*, будет ли вам доступен *символ*, находящийся *вне* области видимости данного модуля? =)

> но готовься покупать хороший хостинг

root@localhost =)

> воевать с высокоуровневыми граблями

насколько трудно дебажатся?

> производительностью

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

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

o_O?

>но поскольку сслка всего лишь некоторая запись в *symbol table*, будет ли вам доступен *символ*, находящийся *вне* области видимости данного модуля?

"область видимости модуля"? если я не ошибаюсь, в пхп такого понятия нету. в language.variables.scope.html такого не написано.

>Область видимости переменной - это среда, в которой она определена. В большинстве случаев все переменные PHP имеют единую область видимости. Эта единая область видимости охватывает также включаемые (include) и требуемые (require) файлы.

верно, не так вырзился. дело в том, что symbol table - штука динамическая, и если у нас в ней есть некоторый симво variable, а также мы имеем по коду несколько имён variable, то *в один момент времени* может быть октивен *только один* символ для взаимооднозначного соответствия с *одной* переменной.

http://www.hudzilla.org/phpbook/read.php/3_6_0

> а нах нужен пых?

на нем написана туева хуча бесплатного и платного софта + PHP поддерживает подавляющее большинство хостеров.

> насколько трудно дебажатся?

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

производительность нормальная (что тоже нетривиальным способом настраивается) а вот ресурсов будет потреблять совсем не по virtual hosting'овым меркам.

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

процесс установки опустим это отельная тема (я таки нашел несколько нестабильных репов и все почти поставилось). Сначала мне понадобилось поменять ORM, через несколько хаков разных конфигурационных файлов. Затем поставить шаблонный движок получше (т.к. его все рекомендовали вместо дефолтного мол в 10 раз быстрее) тоже что-то где-то крутил перелопачивая при этом гугл и все их предоставленные статьи. Почти каждый шаблонный движок замечу это совершенно уникальный язык разметки . Потом упомянутый мной редактор нужной версии совсем отказался ставиться даже после того как я плюнул и таки запустил изиинстал оно гдето в середине отказалось работать, в результате я (уже подуставший от бесконечного чтения туториалов, которые не всегда работают и разных поз сношения) встроил редактор на целиком html + js (очень хорошая весч кстати).

Ну конечно плюсов при этом тоже очень много, во первых искаропковый MVC (но для включения чего-либо как выясняется мы лезем сразу в несколько конфигов ставим какието модули и проч.), шаблоны (со всякми значками %смешными$ и отловом в каком же уровне наследования закралась ошибка). Роутинг (а он мне не ту страницу показывает потому что из кэша или надо поменять местами регекспы урлов ?). Орм (десяток классов фактически дублирующих в двух файлах, для адресной книги сотрудников "Рога и Копыта".

Но было интересно зато:)

> процесс установки опустим это отельная тема (я таки нашел несколько нестабильных репов и все почти поставилось). Сначала мне понадобилось поменять ORM, через несколько хаков разных конфигурационных файлов. Затем поставить шаблонный движок получше (т.к. его все рекомендовали вместо дефолтного мол в 10 раз быстрее) тоже что-то где-то крутил перелопачивая при этом гугл и все их предоставленные статьи. Почти каждый шаблонный движок замечу это совершенно уникальный язык разметки . Потом упомянутый мной редактор нужной версии совсем отказался ставиться даже после того как я плюнул и таки запустил изиинстал оно гдето в середине отказалось работать, в результате я (уже подуставший от бесконечного чтения туториалов, которые не всегда работают и разных поз сношения) встроил редактор на целиком html + js (очень хорошая весч кстати).

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

ну MVC наше все, ибо похапэ чистый дает уродливый код, а все, что пытается быть похожим на MVC - тормозное гавно ... Python + Pylons + Psyco наше все )))

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

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

>т.е. построить нормальную ссылочную структуру данных a la дерево или, скажем, граф у меня, конечно, получится, но с жуткими ограничениями.

Пипец. А то, что я несколько лет с деревьями работаю - это мне приснилось, что ли? :D

> Мне, вот, интересно, как можно начинать судить о языке, вообще его не зная?

я работал с ним три с чем-то года назад, когда пятёрки ещё и в помине не было.

>> а нах нужен пых? > на нем написана туева хуча бесплатного и платного софта

Чего не скажешь про джаву или про си[++] :-D

> + PHP поддерживает подавляющее большинство хостеров.

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

> Пипец. А то, что я несколько лет с деревьями работаю - это мне приснилось, что ли? :D

где я сказал, что на php не возможно реализовать дерево? цитату в студию.

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

Я вобщем и не говорил что пилонс не хороший. Просто везде есть свои "особенности":)

а python через mod_python или cgi не дает уродливого кода ?

> а python..

А python и вовсе непонятно для чего сделан.. Ради увеличения энтропии разве что.

> на нем написана туева хуча бесплатного и платного софта

> Чего не скажешь про джаву или про си[++] :-D

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

> а кто будет платить за переписывание существующего PHP софта на замечательную жабу или С или на что другое, более кошерное ? :)

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

> осознает, что настал момент, когда дешевле переписать всё на джаве или .Net

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

>я работал с ним три с чем-то года назад, когда пятёрки ещё и в помине не было.

PHP4 появился в 2000 году, кажется.