Меня больше всего бесит остутствие "проверки во время компиляции" (т.е. я не могу написать код и сразу узнать что там явная ошибка, это всплывет только в рантайме, причем зачастую приведет не к явному показу ошибки а просто к некорректной работе) и отсутствие средств рефакторинга.
Здравствуйте, kmmbvnr, Вы писали:
K>История PHP как языка — это история неудач. И нет никакой гарантии что они не продолжаться в будущем.
Будет. Создатели PHP — так фантазёры! В качестве разделителя namespace'ов для следующего PHP они выбрали символ '\'
Здравствуйте, kmmbvnr, Вы писали:
CS>>Ага, ты еще встань у священного камня Каабы и спроси какая самая лучшая религия будет.
K>Тем немение остается непонятным, почему у PHP, при таком обилии проектов, на порядок меньше библиотек, в репозитарии??
Потому что на Питоне пишут библиотеки а на PHP полезные вещи.
$a or $b --- TRUE if either $a or $b is TRUE.
$a || $b --- TRUE if either $a or $b is TRUE.
Ну то есть понятно, что or по описанию — это аналог ||. Ага. Угу. Там же:
// У "||" приоритет выше, чем у "or"
$e = false || true; // $e будет присвоено значение (false || true), которое равно true
$f = false or true; // $f будет присвоено значение false
Здравствуйте, neFormal, Вы писали:
F>Собственно, сабж.. F>Какие есть объективные причины?.
Для меня главной минус это провал основной PHP идеи. А ведь, казалось, так здорово писать код прямо внутри html странички. Широкое распространение шаблонных движков под PHP (а зачем они вобще нужны в php?), демонстрирует что не так все оно просто.
Создатели PHP ошиблись. Они еще много где ошибались, благородно пытаясь создать язык для чайников. Например, первая реализация ооп, глупые антипаттерны с request переменными, защишенный режим в попытке избежать многих косяков.
История PHP как языка — это история неудач. И нет никакой гарантии что они не продолжаться в будущем.
-- Главное про деструктор копирования не забыть --
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, Roman Odaisky, Вы писали:
[cut] RO>>и недостаток грамотного дизайна в самом языке.
F>вот, блин.. все так говорят.. иногда непонятно, кто это придумал первый, и почему за ним повторяют.. F>поскольку я в php не углублялся, то можно примеров?.
Здравствуйте, neFormal, Вы писали:
F>Собственно, сабж..
F>Какие есть объективные причины?. кроме туевой хучи кода сайтов, написанных новичками.. F>Давайте сравним, например, с Python-ом, который хвалят почем зря.. F>в чем php проигрывает?. F>- скорость работы, производительность?. F>- простота использования?. F>- отсутствие каких либо нужных библиотек?. F>- ошибки дизайна, нехватка средств языка?. F>- отсутствие хороших средств разработки?.
F>последнее время складывается ощущение, что у php просто плохая репутация и все его боятся
1. PHP — динамически типизируемый (что само по себе неплохо), но при этом — слаботипизируемый. А вот эти два компонента вместе дают гремучее сочетание, которое попытались обмануть костылем ===
switch ("a") {
case 0:
echo"0";
break;
case"a": // никогда сюда не дойдет, потому что "a" уже заматчилось с 0echo"a";
break;
}
Как????
2. Плохой дизайн стандартной библиотеки. Вернее — его отсутствие. Об этом писали выше.
Это и чехарда с названиями функций:
— вырваные напрямую из юникса: link
— вырваные напрямую из C: sprintf
— вырваные напрямую из перла: trim
— придуманые от балды: nl2br
— любой стиль наименований:
-- htmlentities
-- html_entities_decode (существительное->глагол)
-- mysql_select_db (глагол->существительное)
— попытка эмулировать пространства имен префиксом к имени функции... но не везде (можно сравнить mysql_* и строковые функции)
Эа функция вернет False, если символ не найден, а также может вернуть значение, которое может стать false, например 0. Потому необходимо использовать костыль ===. И так — почти везде. Зачем нжен оператор == — неизвестно
3. Отсутствие нормального достаточно общего драйвера к базам данных наподбие JDBC/ADO. PDO должно было появиться, как стандартное расширение в PHP5.0. Оно до сих пор не является стандартным, и не знаю, насколько доработанным
4. Unicode. Казалось бы, прилинкуйся к ICU и не имей проблем. Нет, Юникод пояится только в PHP 6
5. Непонятное развитие языка. То есть, непонятно, что в язык собираются добавлять, а что — нет. И что из того, что собираются добавлять, действительно войдет в язык (как с PDO)
Здравствуйте, neFormal, Вы писали:
RO>>и недостаток грамотного дизайна в самом языке.
F>вот, блин.. все так говорят.. иногда непонятно, кто это придумал первый, и почему за ним повторяют.. F>поскольку я в php не углублялся, то можно примеров?.
Анахронизмы: <?php ... ?>, $переменные_с_долларами, бестолковые правила видимости переменных, ориентированность на веб без фреймворков. И т. д.
Нарушение собственных правил: «$f = return_some_function(); $f()» — можно, «return_some_function()()» — нельзя. $_GET и компания — superglobals, но свои создавать нельзя. И т. д.
Здравствуйте, neFormal, Вы писали:
Г>>кроме того, в API стандартной библиотеки внутренняя логика и последовательный подход отсутствуют начисто F>можно примеров?
Имена содержат str где попало: parse_str, str_replace, strtoupper.
Вообще именование крайне непоследовательное: операция, обратная htmlentities, называется html_entity_decode.
Указание нечувствительности к регистру — то i, то case: strstr/stristr, strnatcmp/strnatcasecmp.
Псевдонимы: strchr = strstr, а strichr не существует. Да и вообще strstr — ненужное в динамическом языке наследие C.
Порядок аргументов: strstr(где, что), str_replace(что, чем, где).
Какие есть объективные причины?. кроме туевой хучи кода сайтов, написанных новичками..
Давайте сравним, например, с Python-ом, который хвалят почем зря..
в чем php проигрывает?.
— скорость работы, производительность?.
— простота использования?.
— отсутствие каких либо нужных библиотек?.
— ошибки дизайна, нехватка средств языка?.
— отсутствие хороших средств разработки?.
последнее время складывается ощущение, что у php просто плохая репутация и все его боятся
>>> Отсутствие строгой типизациии приводит к жутким граблям: .>>Это вообще тут не причём. Это прелести динамического программирования.
E>Это не динамическое программирование это dynamic typing или, как это называют в PHP, type jungling. Именно об этом (об отсутствии строгой типизациии) я и говорю.
Не надо путать динамическую типизацию со слабой, а статическую — о строгой. РНР — динамически типизируемый язык со слабой типизацией.
>>>> Во всех динамических языках будут те же проблемы. E>Вот поэтому я терпеть не могу динамическую типизацию, в том числе в PHP.
Erlang вон тоже динамически типизируем, но такие же "фишки" в нем не пройдут, потому что он строго типизирован
Всем спасибо, тред завершился логично и даже без флейма
На основе сообщений была собрана статья в вики: http://wk.rsdn.ru/php-defects.ashx
Просмотрите, проверьте и дополните по желанию
Здравствуйте, Курилка, Вы писали:
К>Из соображений скорости? Гвидо пишет:
Let's get rid of unbound methods. When class C defines a method f, C.f
should just return the function object, not an unbound method that
behaves almost, but not quite, the same as that function object. The
extra type checking on the first argument that unbound methods are
supposed to provide is not useful in practice (I can't remember that
it ever caught a bug in my code) and sometimes you have to work around
it; it complicates function attribute access; and the overloading of
unbound and bound methods on the same object type is confusing. Also,
the type checking offered is wrong, because it checks for subclassing
rather than for duck typing.
В принципе, разумно. Мне лично эти проверки никогда ещё не помогли, а наоборот даже мешали пару раз, приходилось воркэраундить.
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, Гест, Вы писали:
Г>>кроме того, в API стандартной библиотеки внутренняя логика и последовательный подход отсутствуют начисто".
F>можно примеров?.
Да возьмите хотя бы строковые функции. Часть имен позаимствована из C (strcmp), часть — собрана по тому же принципу, но более человечны (str_replace), часть вроде перловые (trim), str_split делает не то, что делает split во всех языках (в PHP это делает explode), а превращает в массив символов, и т.п. В Руби, например, если я знаю несколько строковых функций — я могу просто угадать имена других (потому что все единообразно), в php — тупо "пересмотреть все функции с похожими именами", что, учитывая три десятка функций с именами типа strнрзбр, удовольствие крайне сомнительное. И это я еще молчу про порядок передачи аргументов (привычное "сказуемое(подлежащее, [дополнения])" нарушено как минимум в explode, где СНАЧАЛА надо передать разделитель, а потом уж — "что делить").
Здравствуйте, MozgC, Вы писали:
F>>какой проверки?. на что?. F>>имхо в питоне то же самое..
MC>Я не сравниваю с Питоном. Можно сравнить с ASP .NET.
Своей гребёнкой
остутствие "проверки во время компиляции"
ты указал на "недостаток" (в кавычках, потому что это ещё вопрос, а недостаток ли?) большинства динамических языков (обращаем внимание на текущий форум). По той причине, что они не являются компилируемыми. ИМХО, это всё-одно что сказать "Мне не нравится жареная картошка, потому что ей не интересно закусывать коньяк" Мнение само по себе конечно заслуживающее внимание, но только не в разговоре о достоинствах жареной картошки.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, bGust, Вы писали:
G>Здравствуйте, Курилка, Вы писали:
К>>Из недавнего — microtime
G>Позвольте заметить несостоятельность примера
G>1. по данному URL написано "microtime() возвращает структуру, а число возвращает microtime(true)" G>что не есть верно, т.к. microtime() возвращает не структуру, а строку соответственно от этой "неточности" и дальнешнее следствие.
Суть в нарушении Principle of least astonishment, строка там или структура — это непринципиально с этой точки зрения, принципиально продемонстрированное неправильное понимание работы функции (а за правильным надо или лезть каждый раз в доки, или "зубрить").
Ты же "докапываешься" до не совсем точных деталей, выкинув из рассмотрения "слона", так что замечание считаю несостоятельным
Здравствуйте, neFormal, Вы писали:
F>Собственно, сабж..
Не разобрался как править статью в вики, так что:
class A
{
function hello()
{
print'Hello I\'m A.';
}
function Foo()
{
$this->hello();
}
}
class B
{
function hello()
{
print'Hello I\'m B.';
}
function Foo()
{
return A::Foo();
}
}
$b = new B();
$b->Foo(); // печатает Hello I'm B :)
Здравствуйте, neFormal, Вы писали:
F>Собственно, сабж..
F>Какие есть объективные причины?. кроме туевой хучи кода сайтов, написанных новичками.. F>Давайте сравним, например, с Python-ом, который хвалят почем зря.. F>в чем php проигрывает?. F>- скорость работы, производительность?. F>- простота использования?. F>- отсутствие каких либо нужных библиотек?. F>- ошибки дизайна, нехватка средств языка?. F>- отсутствие хороших средств разработки?.
Внутренняя логика и последовательность дизайна языка.
Здравствуйте, уважаемые вовлеченные в обсуждение, хочу кинуть свои три гроша в очередную Священную Войну. Только, плиз, не надо в духе незабвенной Евгении Альбац сучить ножками и кричать: "ВОН! ВОН ИЗ ПРОФЕССИИ!!!!", как это делал один мой коллега во время подобного обсуждения.
Итак.... Вполне себе успешных языков с пережитками прошлого — навалом.
Страус писал C++ так, чтобы он был полностью совместим с C (и, соответственно, со всеми его "кулхацкерскими" прибамбасами типа "оператор запятая", префиксная и постфиксная форма инкремента). Про C-строки Спольски целый опус написал, про то, чем они хуже Pascal-строк. Ну хорошо, это его частное мнение нестандартного программиста. Но гуру C++ вроде бы тоже рекомендуют в программах поменьше использовать C-строки и C-массивы, а побольше — std::string и std::vector.
Perl: та самая $переменная, которую тут ругали, а еще %переменная и @переменная, переменная $_, которая используется там, где переменная должна быть, но её нет, передача аргументов в подпрограмму через список с предопределенным именем @_, ну ит.п., список агромадный.
Со временем при развитии вышеупомянутых языков в них добавлялось еще много всякого разного не совсем логичного: vector <bool>, mem_fun, знаменитая конкатенация строк, когда
std::string s,d;
d="%опа";
s=d+"есть";
работает, а вот
std::string s;
s="%опа"+"есть"+"а"+"слова"+"нет";
не работает.
Вообще же, как известно, в стандарте C++ наворотов столько, что ни один компилятор не выполняет требования стандарта полностью.(Хотя, возможно, у меня устаревшие сведения, и такой чудо-компилятор появился).
Модель "почти-объекта" построенная на package в Perl — это же застрелиться можно.
Как Perl, так и С++ позволяют неопытному программисту писать очень небезопасные программы с дырами, глюками и багами. Та же Ada бьёт программера по рукам за любой огрех (один из гуру C++ откровенно написал: если вы нуждаетесь в ремнях безопасности при программировании — программируйте на Ada). Что-то я не вижу вокруг себя толпы Ada-программистов.
Ни Perl, ни C++ не умерли, они вполне себе живут и используются, несмотря на эклектичность, нелогичность, пережитки прошлого, опасность в неумелых руках и прочее, за что тут ругали PHP. Почему? Честно говоря, хз. Есть в них преимущества, которые перевешивают упомянутые недостатки. И есть у других "красивых" языков отсутствие этих самых преимуществ. Ну, типа, речь окончена.
Entropy wrote:
> Отсутствие строгой типизациии приводит к жутким граблям:
Это вообще тут не причём. Это прелести динамического программирования. Во всех динамических языках будут те же проблемы. Это дело решается юнит-тестами.
Кстати, с компилируемыми языками нередко возникают подобные проблемы, особенно в web-программировании. Всё равно не всё можно проверить компилятором. Всегда остаётся HTML, SQL и прочие нетипизируемые штуки.
> return mysql_query("SELECT * FROM MyTable WHERE Id = " . (int)$integer);
А так писать нельзя. Нужно писать: query("SELECT * FROM MyTable WHERE Id = ?").bind($integer).execute();
А вот недостаток PHP можно упомянуть лишь то, что он поощряет такой стиль и во многих учебниках именно учат так писать, да ещё отстутствует нормальный фреймворк для работы с субд, да ещё и автоматическое квотирование запроса символом "\".
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Mamut, Вы писали:
M>1. PHP — динамически типизируемый (что само по себе неплохо), но при этом — слаботипизируемый. А вот эти два компонента вместе дают гремучее сочетание, которое попытались обмануть костылем ===
M>Гениальное из документации, http://php.net/manual/en/language.operators.comparison.php: M>
M>switch ("a") {
M>case 0:
M> echo"0";
M> break;
M>case"a": // никогда сюда не дойдет, потому что "a" уже заматчилось с 0
M> echo"a";
M> break;
M>}
M>
M>Как????
Из сишного наследия (хотя тут, можно сказать, всё логично ):
Здравствуйте, neFormal, Вы писали:
RO>>и недостаток грамотного дизайна в самом языке. F>вот, блин.. все так говорят.. иногда непонятно, кто это придумал первый, и почему за ним повторяют.. F>поскольку я в php не углублялся, то можно примеров?.
Дизайн — это вопрос наличия ума и/или вкуса. Одни видят тонкости, другие видят только сильные контрасты, третьи не видят существенной разницы между паскалем и C#. Если вкус есть, то и сам без примеров видишь, а если его нет, то не увидишь между примерами существенной разницы. Такая вот эзотерическая штука.
Здравствуйте, Гест, Вы писали:
Г>нарушено как минимум в explode, где СНАЧАЛА надо передать разделитель, а потом уж — "что делить").
Это взято из перла. И в перле на то были веские причины.
Вообще в PHP много торчит перловских ушей, только они там как-то бездумно торчат — не понимал разработчик зачем так было сделано в perl.
dmz>Вот рассказали бы о преимуществах, что ли. Очень интресно, есть ли в PHP хоть одно.
Ну например в споре ASP vs PHP выигрывал PHP, потому что у него была хоть какая-то стандартная библиотека — и для закачки файла на сервере там не надо было писать скрипт на 2 страницы кода, а достаточно было вызвать одну функцию...
Здравствуйте, c-smile, Вы писали:
K>>Тем немение остается непонятным, почему у PHP, при таком обилии проектов, на порядок меньше библиотек, в репозитарии?? CS>Потому что на Питоне пишут библиотеки а на PHP полезные вещи. CS>(сам напросился)
На самом деле, примерно так и получилось. На PHP (который ещё был Personal HomePage) начали писать много мелких проектов, так как PHP достаточно легко осваивается новичками.
Некоторые проекты потом постепенно выросли до мощных продуктов. Это было с Drupal, PHPNuke и прочими. Вокруг них сформировалось community. Вот так и получилось.
Здравствуйте, neFormal, Вы писали:
Г>>Внутренняя логика и последовательность дизайна языка.
F>ничего не сказало.. F>раскройте тему
Эхма. "История создания и использования PHP является следствием того, что этот язык практически лишен внутренней логики и последовательного подхода к созданию ментальной модели программиста; преимущественный стиль кодирования на этом языке отличается специфической многословностью (даже в рамках достаточно профессиональных проектов); кроме того, в API стандартной библиотеки внутренняя логика и последовательный подход отсутствуют начисто".
Здравствуйте, Roman Odaisky, Вы писали:
F>>Собственно, сабж.. F>>Какие есть объективные причины? RO>Причина: PHP — это Personal Home Page. RO>Следствия: большое количество спагетти-кода,
RO>и недостаток грамотного дизайна в самом языке.
вот, блин.. все так говорят.. иногда непонятно, кто это придумал первый, и почему за ним повторяют..
поскольку я в php не углублялся, то можно примеров?.
Здравствуйте, MozgC, Вы писали:
MC>Меня больше всего бесит остутствие "проверки во время компиляции" (т.е. я не могу написать код и сразу узнать что там явная ошибка, это всплывет только в рантайме, причем зачастую приведет не к явному показу ошибки а просто к некорректной работе) и отсутствие средств рефакторинга.
какой проверки?. на что?.
имхо в питоне то же самое..
Здравствуйте, Mr.Cat, Вы писали:
MC>А можно и с питоном. Все-таки мы говорим о недостатках PHP, а не системы типов.
Я не знаю что вы относите к недостаткам PHP, я отношу то, о чем я написал выше.
Здравствуйте, Mr.Cat, Вы писали:
F>>Собственно, сабж.. MC>Мне вот тоже интересно. Было бы здорово, если бы кто-нибудь сведующий написал статью в вики (ну или тут, а я бы ее вики загнал).
Здравствуйте, neFormal, Вы писали:
F>- скорость работы, производительность?.
я так понял, что php в скорости работы не уступает питону.. бенчмарки тоже ничего конкретного не говорят..
кто может рассказать какие нибудь личные наблюдения?.
Здравствуйте, Daevaorn, Вы писали:
F>>я так понял, что php в скорости работы не уступает питону.. F>>бенчмарки тоже ничего конкретного не говорят.. D>Извините, но куда уж конкретнее?
знаешь, я сомневаюсь в идеальности тестов в принципе..
здесь питон рвет пхп, но как то не сильно.. я ожидал большего..
да еще тут небось 2я версия, а 3я еще не такая шустрая.. поэтому для меня результат не такой очевидный..
Здравствуйте, Аноним, Вы писали:
А>Perl: та самая $переменная, которую тут ругали, а еще %переменная и @переменная, переменная $_, которая используется там, где переменная должна быть, но её нет, передача аргументов в подпрограмму через список с предопределенным именем @_, ну ит.п., список агромадный.
В перле-то как раз все сделано логично и даже очень, а в PHP, такое ощущение, что пытались скопировать внешний вид не понимая сути...
Здравствуйте, DOOM, Вы писали:
А>>Perl: та самая $переменная, которую тут ругали, а еще %переменная и @переменная, переменная $_, которая используется там, где переменная должна быть, но её нет, передача аргументов в подпрограмму через список с предопределенным именем @_, ну ит.п., список агромадный. DOO>В перле-то как раз все сделано логично и даже очень, а в PHP, такое ощущение, что пытались скопировать внешний вид не понимая сути...
можно примеров что было в перле сделано логично и правильно, а потом бездумно скопировано в php?.
...coding for chaos...
Re[3]: Почему так ругают PHP?.
От:
Аноним
Дата:
12.01.09 08:25
Оценка:
Здравствуйте, DOOM, Вы писали:
DOO>В перле-то как раз все сделано логично и даже очень, а в PHP, такое ощущение, что пытались скопировать внешний вид не понимая сути...
Может быть, может быть. В Python ничего этого нет, в Tcl $ используется при разыменовании, т.е.:
#присвоить x значение 22
set x 22
#присвоить y значение, содержащееся в x
set y $x
, а что касается контекста, то он в Tcl определяется без перловых @ $ %. И ничего, никто не жалуется.
Сам пафос (ха-ха) поста — о том, что не всегда успешность==(красота+логичность) (Кстати, оператор сравнения в С++ — еще один пережиток славного прошлого. Кто ни разу не нажигался на "if(x=1)" — поднимите руку )
Здравствуйте, Аноним, Вы писали:
А>а что касается контекста, то он в Tcl определяется без перловых @ $ %. И ничего, никто не жалуется.
Вопрос гибкости. Tcl не знаю, правда. Но в перле легко придумать множество ситуаций, когда невозможно определить контекст.
А>Сам пафос (ха-ха) поста — о том, что не всегда успешность==(красота+логичность)
Очень жаль. Потому что в перле красота есть, а в PHP ее нет.
В питоне тоже есть своя красота, но уже немного другая.
Re[5]: Почему так ругают PHP?.
От:
Аноним
Дата:
12.01.09 08:46
Оценка:
Здравствуйте, DOOM, Вы писали:
DOO>Очень жаль. Потому что в перле красота есть, а в PHP ее нет. DOO>В питоне тоже есть своя красота, но уже немного другая.
Про Python — согласен, он прост и логичен, и я его освоил очень быстро, а вот Perl.....
Логичности в нем гораздо меньше, возможностей для неопытного программера наделать глупостей — больше. Пресловутая концепция TIMTWDI — по моему скромному мнению, полный бред. И не только по моему мнению — в конце концов само сообщество Perl выработало ряд общепринятых идиом. А почему эти идиомы нельзя было с самого начала сделать встроенными в язык обязательными к исполнению правилами?
Здравствуйте, Аноним, Вы писали:
А>Про Python — согласен, он прост и логичен, и я его освоил очень быстро, а вот Perl..... А>Логичности в нем гораздо меньше, возможностей для неопытного программера наделать глупостей — больше.
Логичность там полная. В перле надо хорошо знать несколько концепций и все становится очень просто.
Да местами они перегнули палку, например с похожими операторами сравнения с разным приоритетом, но это в угоду красоте кода
Не забывай, что автор перла — лингвист.
А>А почему эти идиомы нельзя было с самого начала сделать встроенными в язык обязательными к исполнению правилами?
Потому что было бы нарушение свободы
Re[7]: Почему так ругают PHP?.
От:
Аноним
Дата:
12.01.09 09:23
Оценка:
Здравствуйте, DOOM, Вы писали:
DOO>Логичность там полная. В перле надо хорошо знать несколько концепций и все становится очень просто.
Да вообще, любой язык, вплоть до ассемблера для Z80, с которого я начинал, если им овладеешь — простой и понятный. ИМХО, логичность характеризуется скоростью овладевания языком. Объективно, по моему опыту, по опыту ряда коллег, скорость овладевания Perl ниже, чем у Python или Tcl. Опять же, куча "специальных" переменных типа @_,$_ ит.п. Или вот сравнил недавно самые распространенные инфраструктуры тестирования: unittest в Python и Test в Perl. unittest при меньшем объеме самого модуля дает больше возможностей, чем Test.
Но это не значит, что Perl плохой — плохих языков вообще не бывает, если на языке пишут, то он хорош в чем-то, а уж если он распространен так, как Perl — то плюсы просто обязаны быть. ИМХО, эти плюсы — развитая библиотека (сейчас большая часть работы программиста сводится с сборке из готовых кирпичиков), сообщество, вт.ч. инфраструктура CPAN.
DOO>Не забывай, что автор перла — лингвист.
То-то и оно.... Это совершенно другая профессия, другой образ мышления, нежели у программиста.
А>>А почему эти идиомы нельзя было с самого начала сделать встроенными в язык обязательными к исполнению правилами? DOO>Потому что было бы нарушение свободы
Детский вопрос: А зачем же их тогда придерживаются? Идиомы для того нужны, ИМХО, чтобы сказать как можно короче и как можно понятнее. А в Perl принцип TIMTWDI привел, например к знаменитому косвенному обращению к членам класса, про которое до сих пор некоторые отечественные авторы пишут, что так-де понятнее и лучше, хотя западэнцы уже трубят "ни в коем случае, ведет к неоднозначности" (см. Intermediate Perl 2-nd edition)
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, DOOM, Вы писали:
DOO>>Логичность там полная. В перле надо хорошо знать несколько концепций и все становится очень просто.
А>Опять же, куча "специальных" переменных типа @_,$_ ит.п.
Да, но какие они дают возможности!
А>ИМХО, эти плюсы — развитая библиотека (сейчас большая часть работы программиста сводится с сборке из готовых кирпичиков), сообщество, вт.ч. инфраструктура CPAN.
Кстати, никогда не использовал что-то с CPAN'а.
А>>>А почему эти идиомы нельзя было с самого начала сделать встроенными в язык обязательными к исполнению правилами? DOO>>Потому что было бы нарушение свободы
А>Детский вопрос: А зачем же их тогда придерживаются? Идиомы для того нужны, ИМХО, чтобы сказать как можно короче и как можно понятнее.
Идиомы нужны чтобы было понятнее. Если писать как можно короче на перле, то получается игра в гольф и через некоторое время программу невозможно прочитать.
А>А в Perl принцип TIMTWDI привел, например к знаменитому косвенному обращению к членам класса, про которое до сих пор некоторые отечественные авторы пишут, что так-де понятнее и лучше, хотя западэнцы уже трубят "ни в коем случае, ведет к неоднозначности" (см. Intermediate Perl 2-nd edition)
Красота языка и промышленная применимость все же очень разные вещи. Перл красив — но в промышленном применении не так уж и хорош. Единственный способ эффективно работать на перле команде разработчиков — это да. Введение ограничений, но тоже и про C++ можно сказать
Здравствуйте, DOOM, Вы писали:
F>>можно примеров что было в перле сделано логично и правильно, а потом бездумно скопировано в php?. DOO>Пожалуйста: DOO>
DOO>Variables in PHP are represented by a dollar sign followed by the name of the variable. The variable name is case-sensitive.
DOO>На кой ляд? DOO>В перле символ задает контекст — $ скалярный, @ — векторный, ну и псевдо-контекст хэша (%). А в PHP — зачем этот $?
например, чтобы вытащить имя из списка имен в данной области видимости..
DOO>Ну и т.д. и т.п. сейчас лень искать, а так листая мануал на каждом шагу видно такое бездумное копирование.
Г>>нарушено как минимум в explode, где СНАЧАЛА надо передать разделитель, а потом уж — "что делить").
DOO>Это взято из перла. И в перле на то были веские причины.
Г>>>нарушено как минимум в explode, где СНАЧАЛА надо передать разделитель, а потом уж — "что делить").
DOO>>Это взято из перла. И в перле на то были веские причины.
F>какие причины?.
Такие, что в перле есть параметр по умолчанию, который не обязательно писать ($_), соответственно он должен идти в конце.
Re[9]: Почему так ругают PHP?.
От:
Аноним
Дата:
12.01.09 09:42
Оценка:
Здравствуйте, DOOM, Вы писали:
....
Ладно, это уже у нас оффтоп пошел, еще раз повторю свою мысль: самые успешные (т.е. распространенные) языки, такие, как C++ и Perl имеют те же проблемы, которые ставятся в вину PHP:
легко написать нечитабельный код (то о чем вы писали выше), легко написать опасный код, особенно если программист неопытный, эклектичность (т.е. в языке сочетаются концепции не очень-то сочетаемые), куча пережитков прошлого..... Список можно продолжать.
И все же они, как дело Ленина, живут и побеждают.
А>Ладно, это уже у нас оффтоп пошел, еще раз повторю свою мысль: самые успешные (т.е. распространенные) языки, такие, как C++ и Perl имеют те же проблемы, которые ставятся в вину PHP: А>легко написать нечитабельный код (то о чем вы писали выше), легко написать опасный код, особенно если программист неопытный, эклектичность (т.е. в языке сочетаются концепции не очень-то сочетаемые), куча пережитков прошлого..... Список можно продолжать. А>И все же они, как дело Ленина, живут и побеждают.
Я о PHP и перле имею довольно смутные представления, но неплохо зная C++ могу предположить что кроме недостатков у перла и C++ есть немало и достоинств (например возможность писать краткий красивый и эффективный код), которых у PHP не видно
Здравствуйте, FR, Вы писали:
FR>Я о PHP и перле имею довольно смутные представления, но неплохо зная C++ могу предположить что кроме недостатков FR>у перла и C++ есть немало и достоинств (например возможность писать краткий красивый и эффективный код), которых у PHP не видно
как же ты, имея "довольно смутные представления" о php, можешь судить о его достоинствах?.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, neFormal, Вы писали: F>>Собственно, сабж..
MC>Мне вот тоже интересно. Было бы здорово, если бы кто-нибудь сведующий написал статью в вики (ну или тут, а я бы ее вики загнал).
Виви в тестовом режиме есть и на РСДН: http://wk.rsdn.ru/ Логин/пароль — от рсдна
Здравствуйте, D. Mon, Вы писали:
А>> Кто ни разу не нажигался на "if(x=1)" — поднимите руку DM>Поднимаю. ( Если что — имею 8-летний опыт коммерческого программирования на С++ )
Здравствуйте, c-smile, Вы писали:
CS>Количество ругани языка программирования прямо пропорционально объему проектов на нем. CS>http://www.hotscripts.com/
A>за что тут ругали PHP. Почему? Честно говоря, хз. Есть в них преимущества, которые перевешивают упомянутые недостатки. И есть у других "красивых" языков отсутствие этих самых преимуществ. Ну, типа, речь окончена.
Вот рассказали бы о преимуществах, что ли. Очень интресно, есть ли в PHP хоть одно.
Здравствуйте, kmmbvnr, Вы писали:
K>Здравствуйте, c-smile, Вы писали:
CS>>Количество ругани языка программирования прямо пропорционально объему проектов на нем. CS>>http://www.hotscripts.com/
K>Честно говоря первый раз слышу об этом сайте.
K>>Тем немение остается непонятным, почему у PHP, при таком обилии проектов, на порядок меньше библиотек, в репозитарии??
CS>Потому что на Питоне пишут библиотеки а на PHP полезные вещи.
А ну тогда понятна ситуация с perl'ом. Суровым сисадминам нечем заниматься целыми днями, вот они и в три раза больше чем питонисты и в 28(!) раз больше чем занятые судьбой мира php'шники, понаписали кода пригодного к повторному использованию.
-- Главное про деструктор копирования не забыть --
я не понял в чем прикол
почему логично?. )
php по-разному воспринимает последовательность цифр?. как число и как строку?. потому что 12389 выводит 12389
F>я не понял в чем прикол F>почему логично?. ) F>php по-разному воспринимает последовательность цифр?. как число и как строку?. потому что 12389 выводит 12389
Здравствуйте, Курилка, Вы писали:
F>>я не понял в чем прикол К>0 — префикс восьмеричной системы счисления
да, тут уже подсказали..
не юзал.. думал, что требуется добавлять постфикс "o".. типа как 0x123h
...coding for chaos...
Re[6]: Почему так ругают PHP?.
От:
Аноним
Дата:
15.01.09 12:57
Оценка:
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, D. Mon, Вы писали:
А>>> Кто ни разу не нажигался на "if(x=1)" — поднимите руку DM>>Поднимаю. ( Если что — имею 8-летний опыт коммерческого программирования на С++ )
F>я знаю, ты пишешь if(1 == x) ?.
Не верю! (c) Станиславский
Просто потому, что мода на "if (1==x)" пошла в нашей Раше года три-четыре назад, до того никто у нас так не писал (во всяком случае, ни в статьях, ни в проектах, ни в учебниках не встречалось ни разу). Ты конечно сейчас начнешь говорить, что сам, своим гениальным умом, дошел до этого..... Ну хорошо.... Кстати, а как быть с "if(x=y)"? Писать "if(y=x)"?
Здравствуйте, Аноним, Вы писали:
А>>>> Кто ни разу не нажигался на "if(x=1)" — поднимите руку DM>>>Поднимаю. ( Если что — имею 8-летний опыт коммерческого программирования на С++ )
F>>я знаю, ты пишешь if(1 == x) ?.
А>Не верю! (c) Станиславский
Кому не веришь? Там вопрос был, я на него еще не отвечал.
А>Просто потому, что мода на "if (1==x)" пошла в нашей Раше года три-четыре назад, до того никто у нас так не писал (во всяком случае, ни в статьях, ни в проектах, ни в учебниках не встречалось ни разу). Ты конечно сейчас начнешь говорить, что сам, своим гениальным умом, дошел до этого..... Ну хорошо.... Кстати, а как быть с "if(x=y)"? Писать "if(y=x)"?
Лично я не пишу везде (1==х). Видел такой прием, оценил, но на практике редко использую. Я просто банально не использую = в if'ax.
Здравствуйте, D. Mon, Вы писали:
DM>Лично я не пишу везде (1==х). Видел такой прием, оценил, но на практике редко использую. Я просто банально не использую = в if'ax.
M>// У "||" приоритет выше, чем у "or"
M>$e = false || true; // $e будет присвоено значение (false || true), которое равно true
M>$f = false or true; // $f будет присвоено значение false
M>Потому что в РНР есть вот такая великолепная таблица приоритета операторов: http://md.php.net/manual/en/language.operators.precedence.php
M>Да-да-да. Несмотря на то, что and и && — это одно и то же, и or и || — это одно и то же, у них разные приоритеты
Спасибо за напоминание — Кириллу за его вопрос в аське:
M>$a or $b --- TRUE if either $a or $b is TRUE.
M>$a || $b --- TRUE if either $a or $b is TRUE.
M>Ну то есть понятно, что or по описанию — это аналог ||. Ага. Угу. Там же:
M>
M>// У "||" приоритет выше, чем у "or"
M>$e = false || true; // $e будет присвоено значение (false || true), которое равно true
M>$f = false or true; // $f будет присвоено значение false
M>Потому что в РНР есть вот такая великолепная таблица приоритета операторов: http://md.php.net/manual/en/language.operators.precedence.php
M>Да-да-да. Несмотря на то, что and и && — это одно и то же, и or и || — это одно и то же, у них разные приоритеты
Здравствуйте, DOOM, Вы писали:
M>>Да-да-да. Несмотря на то, что and и && — это одно и то же, и or и || — это одно и то же, у них разные приоритеты
DOO>Вообще-то это заимствовано из перла
Здравствуйте, Гест, Вы писали:
M>>>Да-да-да. Несмотря на то, что and и && — это одно и то же, и or и || — это одно и то же, у них разные приоритеты DOO>>Вообще-то это заимствовано из перла Г>...и повторяется в Руби. Есть основания, кагбэ.
Здравствуйте, neFormal, Вы писали:
M>>>>Да-да-да. Несмотря на то, что and и && — это одно и то же, и or и || — это одно и то же, у них разные приоритеты DOO>>>Вообще-то это заимствовано из перла Г>>...и повторяется в Руби. Есть основания, кагбэ.
F>и какие же?.
По-бытовому говоря, &&, ||, ! обеспечивают логическую арифметику, а and, or, not — структурирование кода.
Например:
if(cond1 || cond2 && cond3 && !cond4) #первый вариантif(x = test1() and y = test2()) #второй вариант
Я буду говорить о PHP-не как о языке, а как о платформе.
Отсутствие строгой типизациии приводит к жутким граблям:
1.
function multiply($x)
{
$result = $x * $y;
// Здесь программист забыл вернуть результат из функции!
// Главное, что никаких warning'ов, а там и до пятницы недалеко.
}
2.
class MyClass
{
var $x;
public function myMethod($a) {
$x = $a; // Упс, здесь надо было написать $this->x = $a, но мы забыли про $this - ерунда
// транслятор молчит значит усё в порядке!
}
}
3.
function sum($integer1, $integer2)
{
return (int)$integer + (int)$integer2;
}
$sum = sum(1, array(1, 2, 3)); // Cколько будет целое плюс массив? Транслятору пофиг.
// Примечание: приводим тип потому что не доверяем входным данным от пользователя.
4.
function doSomething($x, $y, $z) // Какого типа $x, $y, $z? Угадай сам!
{
}
5.
function makeMeHapy() // Эта функция должна была называться makeMeHappy. Ошибка обнаружится в багрепорте на следующее утро.
{
}
6.
function putToDatabase($integer)
{
//Для того чтобы избежать sql-injection это надо постоянно кастить к ожидаемому типу
//Где же пресловутая краткость динамических языков?return mysql_query("SELECT * FROM MyTable WHERE Id = " . (int)$integer);
}
Достает, что использование $this-> обязательно — из-за этого трудно делать некоторые рефакторинги.
Нет перегрузки операторов.
Нет перегрузки методов.
Убогие по современным меркам IDE.
Более 40(!) фреймворков, большинство из которых не имеет ни документации ни поддержки и сделаны на коленке. Вот уж где понимаешь разницу между количеством и качеством.
Коммуния состоит из программистов низкого уровня. Я не фашист и верю в то, что где-то есть хорошие PHP-программисты, и я верю в инопланетян, но просто ни разу не встречал ни тех ни других.
В России PHP-коммуния довольно-таки хамская (я имею ввиду один популярный PHP-ресурс).
Поддержка Unicode появится только в версси 6 (в Java это было в 1995 году.)
Отсутствие неймспейсов явно не способствовало развитию грамотной экосистемы.
Раздрай в соглашениях: в PHP используется старый перловсий стиль с подчеркиваниями, а в PEAR — camel case.
Здравствуйте, ., Вы писали:
.>Entropy wrote:
>> Отсутствие строгой типизациии приводит к жутким граблям: .>Это вообще тут не причём. Это прелести динамического программирования.
Это не динамическое программирование это dynamic typing или, как это называют в PHP, type jungling. Именно об этом (об отсутствии строгой типизациии) я и говорю.
>>> Во всех динамических языках будут те же проблемы.
Вот поэтому я терпеть не могу динамическую типизацию, в том числе в PHP.
>>> Это дело решается юнит-тестами.
Ни черта это не решается юнит-тестами. Это только в сказках так. Во-первых в реальной жизни не так много PHP-программеров пользующихся юнит тестами. Вы видели плагины у Wordpress, многo среди них протестировано? Во-вторых, может попасться (я сказал "может попасться"? я имел ввиду "100% попадется") стороння библиотека без юнит-тестов, которую надо поддерживать. Или вам дадут стрый движок портала, разрабатываемый с 2001 года на PHP 4, программистами, которые давно уволились. Вы думаете мне легче от того, что "Во всех динамических языках будут те же проблемы", когда их можно было просто избежать? Реальный мир жесток.
.>>>Кстати, с компилируемыми языками нередко возникают подобные проблемы, особенно в web-программировании. Всё равно не всё можно проверить компилятором.
Нет уж, пардоньте, ошибиться в названии метода никак нельзя. Не все, но многое проверяется. Я уже не говорю о нормальном авторефаторинге, которого у динамически-типизируемых языков никогда не будет (тока не говорите про комментарии-подсказки — на это надеяться не стоит).
>>> Всегда остаётся HTML, SQL и прочие нетипизируемые штуки.
Это правда, на стыке языков всегда проблемы. Вы HTML-вывод тоже юнит-тестируете? Позвольте не поверить.
>> return mysql_query("SELECT * FROM MyTable WHERE Id = " . (int)$integer); .>А так писать нельзя. Нужно писать: query("SELECT * FROM MyTable WHERE Id = ?").bind($integer).execute();
И как мне это поможет? Инъекции не будет? Ну да, но это никак не запретит мне передать неверный тип данных в метод bind и никто ничего не заметит. Юнит-тесты? Да их ведь тоже надо отлаживать, как ни странно, и, в случае пойманной тестом ошибки, придется дольше бегать по коду, пытаясь отыскать место ее возникновения.
Здравствуйте, ., Вы писали: >> Отсутствие строгой типизациии приводит к жутким граблям: .>Это вообще тут не причём. Это прелести динамического программирования. Во всех динамических языках будут те же проблемы. Это дело решается юнит-тестами.
То, о чем Вы и Ваш собеседник говорите, совершенно ортогонально динамической/статической типизации. Правила, не позволяющие лишний раз прострелить себе ногу не обязательно связаны с типами. Просто в php нет ни того, ни другого.
function multiply($x)
{
$result = $x * $y;
// Здесь программист забыл вернуть результат из функции!
// Главное, что никаких warning'ов, а там и до пятницы недалеко.
}
Невозможно в scheme. Поскольку, грубо говоря все, что не биндит переменные — выражение, "забыть вернуть" что-то нельзя.
class MyClass
{
var $x;
public function myMethod($a) {
$x = $a; // Упс, здесь надо было написать $this->x = $a, но мы забыли про $this - ерунда
// транслятор молчит значит усё в порядке!
}
}
Практически невозможно в scheme. Нечаянно прибиндить что-то "не туда" можно разве что с помощью макроса, да и то сложно.
function sum($integer1, $integer2)
{
return (int)$integer + (int)$integer2;
}
$sum = sum(1, array(1, 2, 3)); // Cколько будет целое плюс массив? Транслятору пофиг.
// Примечание: приводим тип потому что не доверяем входным данным от пользователя.
В scheme подобная ситуация выльется в эксепшн в рантайме (т.е. соответствующий тест будет зафейлен).
function doSomething($x, $y, $z) // Какого типа $x, $y, $z? Угадай сам!
{
}
Вообще, при объявлении функций их стоит аннотировать типами аргументов. Очень полезная практика.
function makeMeHapy() // Эта функция должна была называться makeMeHappy. Ошибка обнаружится в багрепорте на следующее утро.
{
}
В scheme в принципе возможно, но компиляторы выдают варнинги, поскольку вероятность внезапного появления биндинга в лексической области видимости в рантайме — на уровне статистической погрешности.
Entropy wrote:
>> > Отсутствие строгой типизациии приводит к жутким граблям: > .>Это вообще тут не причём. Это прелести динамического программирования. > Это не динамическое программирование это dynamic typing или, как это > называют в PHP, type jungling. Именно об этом (об отсутствии строгой > типизациии) я и говорю.
Ну да, я это и имел в виду. А таких языков куча, яваскрипт, питон, руби, перл... И даже в С/С++ это вылазит в неком виде.
>> >> Во всех динамических языках будут те же проблемы. > Вот поэтому я терпеть не могу динамическую типизацию, в том числе в PHP.
Дело вкуса. С другой стороны есть приятные моменты — необходимость компиляции отстутствует.
>> >> Это дело решается юнит-тестами. > Ни черта это не решается юнит-тестами. Это только в сказках так. > Во-первых в реальной жизни не так много PHP-программеров пользующихся > юнит тестами.
В реальной жизни вообще мало квалифицированных программеров.
Просто отсутсвие хороших юнит-тестов сказывается на качестве кода сильнее, чем "неправильный" язык.
> Вы видели плагины у Wordpress, многo среди них протестировано? Во-вторых, может попасться (я сказал "может попасться"? > я имел ввиду "100% попадется") стороння библиотека без юнит-тестов, > которую надо поддерживать. Или вам дадут стрый движок портала, > разрабатываемый с 2001 года на PHP 4, программистами, которые давно > уволились. Вы думаете мне легче от того, что "Во всех динамических > языках будут те же проблемы", когда их можно было просто избежать? > Реальный мир жесток.
А если вам дадут движок портала, разрабатываемый с 2001 на С#? Или не дай боже на С? Точно будет легче?
> .>>>Кстати, с компилируемыми языками нередко возникают подобные > проблемы, особенно в web-программировании. Всё равно не всё можно > проверить компилятором. > Нет уж, пардоньте, ошибиться в названии метода никак нельзя. Не все, но > многое проверяется. Я уже не говорю о нормальном авторефаторинге, > которого у динамически-типизируемых языков никогда не будет (тока не > говорите про комментарии-подсказки — на это надеяться не стоит).
Ну да, с авторефакторингом проблемы. Хотя, насколько я знаю, нормальный рефакторинг есть только в яве, да в шарпе более менее.
>> >> Всегда остаётся HTML, SQL и прочие нетипизируемые штуки. > Это правда, на стыке языков всегда проблемы. Вы HTML-вывод тоже > юнит-тестируете? Позвольте не поверить.
Честно говоря, не пришлось. Но надеюсь займусь в ближайшем будущем, нет в этом ничего невозможного.
А вообще говоря, каждый уважающий себя фреймворк это должен позволять. Скажем, wicket.
>> > return mysql_query("SELECT * FROM MyTable WHERE Id = " . (int)$integer); > .>А так писать нельзя. Нужно писать: query("SELECT * FROM MyTable WHERE > Id = ?").bind($integer).execute(); > И как мне это поможет? Инъекции не будет? Ну да, но это никак не > запретит мне передать неверный тип данных в метод bind и никто ничего не > заметит. Юнит-тесты? Да их ведь тоже надо отлаживать, как ни странно, и, > в случае пойманной тестом ошибки, придется дольше бегать по коду, > пытаясь отыскать место ее возникновения.
Так ты же сказал, что оно из html-запроса приходит. Где-то да придётся эту проверку вставить. И в случае php никто тебя не заставляет проверять уже в уровне dao — проверь при разборе входных параметров.
> Да, вот еще вспомнил: нет перечислений.
мелочи жизни.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Mr.Cat wrote:
> Во всех динамических языках будут те же проблемы. Это дело решается > юнит-тестами. > То, о чем Вы и Ваш собеседник говорите, совершенно ортогонально > динамической/статической типизации. Правила, не позволяющие лишний раз > прострелить себе ногу не обязательно связаны с типами. Просто в php нет > ни того, ни другого.
Да просто прострелить ногу можно из всего. Не типы, так их приведение, не приведение, так downcasting...
Поэтому рассчитывать на то, что раз скомпилилось, значит работает, лучше не стоит. А важнее покрыть всё тестами.
> Невозможно в scheme. Поскольку, грубо говоря все, что не биндит > переменные — выражение,
Да там всё выражение. Или я что-то не помню?
Биндинг переменной может быть последним элеметом, но шанс такого имхо такой же, как и забыть "return".
>"забыть вернуть" что-то нельзя.
Зато можно вернуть не то.
> Практически невозможно в scheme. Нечаянно прибиндить что-то "не туда" > можно разве что с помощью макроса, да и то сложно.
Просто язык требует объявления переменных. Вот это да, имхо важно. Хотя, скажем, в питоне не так, но это ему не мешает быть "хорошим" языком.
> В scheme подобная ситуация выльется в эксепшн в рантайме (т.е. > соответствующий тест будет зафейлен).
Просто в языке нет автоматического приведения типов. Но я не уверен, что это всегда и везде правильная стратегия.
> В scheme в принципе возможно, но компиляторы выдают варнинги, поскольку > вероятность внезапного появления биндинга в лексической области > видимости в рантайме — на уровне статистической погрешности.
А '?
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали: .>Биндинг переменной может быть последним элеметом, но шанс такого имхо такой же, как и забыть "return".
Наверное, все-таки меньше. Вроде не все реализации это позволяют (mzscheme ругается, что нет выражения, chicken пропускает).
>>"забыть вернуть" что-то нельзя. .>Зато можно вернуть не то.
Увы. Вот тут уже пошли недостатки динамической типизации.
.>Просто язык требует объявления переменных. Вот это да, имхо важно. Хотя, скажем, в питоне не так, но это ему не мешает быть "хорошим" языком.
Ну, я уже слышал критику в адрес питона по этому поводу. Хотя в питоне-то еще ничего. Настоящая жесть с областями видимости — в матлабе.
.>А '?
Да, я че-то какой-то набор слов написал. Я имел в виду, что благодаря лексической области видимости, факт того, что переменная в рантайме будет не определена, можно выявить в компайл-тайм.
MC>То, о чем Вы и Ваш собеседник говорите, совершенно ортогонально динамической/статической типизации. Правила, не позволяющие лишний раз прострелить себе ногу не обязательно связаны с типами. Просто в php нет ни того, ни другого.
Ладно, согласен, правильнее было бы написать не "отсутствие строгой типизации", а "причуды PHP".
Здравствуйте, Mr.Cat, Вы писали:
MC>Вообще, при объявлении функций их стоит аннотировать типами аргументов. Очень полезная практика.
Эта практика была бы полезной, если бы комилятор насильно заставлял аннотировать типы аргументов. Это все равно что сказать: "Воообще детям полезно ходить в школу. Очень полезная практика." В рельной жизни в школу ходят только из-под палки. В PHP уже есть type hinting, когда можно явно указывать типы, но во-первых он не обязательный, во-вторых он не действует на примитивные типы. Вместо того, чтобы опускать тип аргумента, я думаю, лучше было бы вводить ключевое слово-тип, например, dynaimc.
Здравствуйте, Entropy, Вы писали:
E>Я буду говорить о PHP-не как о языке, а как о платформе. E>Отсутствие строгой типизациии приводит к жутким граблям:
Как уже сказали, это проблемы не конкретно отсутствия строгой типизации, а реализации системы типов PHP в целом.
E>Убогие по современным меркам IDE.
Для Eclipse есть PDT из которой выросла Zend Studio, в Netbeans также есть расширение для PHP, для Visual Studio есть VS.PHP. Чего еще не хватает-то?
E>Более 40(!) фреймворков, большинство из которых не имеет ни документации ни поддержки и сделаны на коленке. Вот уж где понимаешь разницу между количеством и качеством.
На хабре вон, Yii хвалят, вроде достаточно добротный и документированный FW. Zend документирован по самые уши + куча сторонних статей в т.ч. от серьезных дядей (например цикл туториалов на ibm.com)
E>Коммуния состоит из программистов низкого уровня. Я не фашист и верю в то, что где-то есть хорошие PHP-программисты, и я верю в инопланетян, но просто ни разу не встречал ни тех ни других.
Хороших PHP-программистов мало, потому как по мере своего профроста они уходят либо на Python, либо на Ruby, либо вообще в .NET
Здравствуйте, Entropy, Вы писали:
E>Я буду говорить о PHP-не как о языке, а как о платформе.
И раз уж мы заговорили о платформе, то качество кода в исполнении php-group оставляет желать лучшего, а выпуск патчей и реагирование на сообщения об обнаруженных уязвимостях, вообще "радует". Например, на сегодняший день:
1. Под виндой, дергая методы COM-объектов можно обойти ограничения safe-mode. Патч отсутствует.
2. Переполнения буфера и повреждения памяти в tidy_parse_string(), snmpget(), msql_connect(), win_browse_file(), в нескольких ntuser_*(), str_replace(), iptcembed(), mssql_connect() и iis_getservicestate(). Патчи отсутствуют.
3. race condition в crypt(), что делает небезопасным ее использование в многопоточной среде. Закрыта лишь частично.
4. DOS в gdPngReadData(). Закрыта лишь частично.
5. Повышение привилегий в ibase_connect(). Патч отсутствует.
Это при том, что некоторым из перечисленных уязвимостей уже больше года
А о культуре безопасного кода на PHP я вообще молчу, она просто отсутствует, как таковая. Яркий пример (чтоб далеко не ходить):
.>А так писать нельзя. Нужно писать: query("SELECT * FROM MyTable WHERE Id = ?").bind($integer).execute();
И как мне это поможет? Инъекции не будет? Ну да, но это никак не запретит мне передать неверный тип данных в метод bind и никто ничего не заметит.
Вот это натянутое "ну да", вкупе с продемонстрированным стремлением использовать конкатенацию строк в SQL-запросах очень настораживает, но не удивляет, поскольку в PHP-среде, дай бог чтобы 3 из 10 разработчиков вообще беспокоили подобные "мелочи"
KV>Для Eclipse есть PDT из которой выросла Zend Studio, в Netbeans также есть расширение для PHP, для Visual Studio есть VS.PHP. Чего еще не хватает-то?
Надо чтоб как у Resharper было, плюс визуальное редактирование собственных компонентов. А болокнотом с подсветкой, дебаггером и единственным рефакторингом типа "Rename" сейчас никого не удивишь.
KV>На хабре вон, Yii хвалят, вроде достаточно добротный и документированный FW. Zend документирован по самые уши + куча сторонних статей в т.ч. от серьезных дядей (например цикл туториалов на ibm.com)
Вот именно, что этиx фрейморков, которыx хвалят, до фига и больше, при этом неизвестно, кто из них будет перспективным, а кто завтра загнется. Я видел немало подающих надежды перспективных проектов, которые сейчас пылятся на Sourceforge. Плюс они плохо (если вообще) совместимы друг другом.
Но главное, в PHP нет компонентного программирования. Типа Java Beаns — нет универсальной спецификации, чтобы можно было сделать визуальные редакторы. Все компоненты заточены только под свой собственный фреймворк/CMS. При таком их количестве не представляется возможным хоть как-то стандартизировать создание визуальных компонентов (я не имею ввиду редактирование шаблонов — а ля Dreamweaver). В ASP.NET или Java есть мейнстрим, в PHP — кто в лес, по дрова.
Здравствуйте, Entropy, Вы писали:
KV>>Для Eclipse есть PDT из которой выросла Zend Studio, в Netbeans также есть расширение для PHP, для Visual Studio есть VS.PHP. Чего еще не хватает-то?
E>Надо чтоб как у Resharper было, плюс визуальное редактирование собственных компонентов.
Я правильно понимаю, что в контексте PHP под "собственным компонентом" здесь подразумеваются html-шаблоны? Да упаси боже, в wysiwyg что-то верстать И тем не менее, как минимум в Zend это есть.
E>А болокнотом с подсветкой, дебаггером и единственным рефакторингом типа "Rename" сейчас никого не удивишь.
Это Visual Studio блокнот с подсветкой?
KV>>На хабре вон, Yii хвалят, вроде достаточно добротный и документированный FW. Zend документирован по самые уши + куча сторонних статей в т.ч. от серьезных дядей (например цикл туториалов на ibm.com)
E>Вот именно, что этиx фрейморков, которыx хвалят, до фига и больше, при этом неизвестно, кто из них будет перспективным, а кто завтра загнется. Я видел немало подающих надежды перспективных проектов, которые сейчас пылятся на Sourceforge. Плюс они плохо (если вообще) совместимы друг другом.
Ну если выделенное, то тогда zend fw. Он загнется только если вместе с PHP.
E>Но главное, в PHP нет компонентного программирования. Типа Java Beаns — нет универсальной спецификации, чтобы можно было сделать визуальные редакторы. Все компоненты заточены только под свой собственный фреймворк/CMS. При таком их количестве не представляется возможным хоть как-то стандартизировать создание визуальных компонентов (я не имею ввиду редактирование шаблонов — а ля Dreamweaver). В ASP.NET или Java есть мейнстрим, в PHP — кто в лес, по дрова.
А что в чистом PHP помимо выделенного еще может быть / должно быть "визуальным компонентом"?
Здравствуйте, Курилка, Вы писали:
К>Из недавнего — microtime
Позвольте заметить несостоятельность примера
1. по данному URL написано "microtime() возвращает структуру, а число возвращает microtime(true)"
что не есть верно, т.к. microtime() возвращает не структуру, а строку соответственно от этой "неточности" и дальнешнее следствие.
2. из-за не раз упомянутой выше слабой динамической типизации PHP — Вы можете вычитать и строки, но
согласно правилам привидения типов (или как еще назвать операции подобные) в PHP, перед вычитанием вышеупомянутых строк они будут приведены к числам, соответственно ничего необычного и неправильного в упомянутом примере нет.
Все логично, первая строка преобразуется из (string)"0.20532600 1228884374" в (float)0.20532600 и вторая соответственно, посему при вычитании и получаем такой результат.
P.S.: это "замечание" не претендует на истину а лишь является моим мнением на основе известных мне фактов.
Кто ни разу не нажигался на "if(x=1)" — поднимите руку
Поднимаю. Имел счастье в дестве пересечься с гуру, показавшим if( 1 == x ) (Если что — имею 13-летний опыт коммерческого программирования на C++)
Re[4]: Почему так ругают PHP?.
От:
Аноним
Дата:
23.05.09 04:17
Оценка:
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, neFormal, Вы писали:
F>>я даже не знаю минус ли это.. F>>после других скриптов меня это даже как то не удивляет..
FR>В других super есть
А причем здесь super? Классы между сообой вообще никак не связаны...
Здравствуйте, Аноним, Вы писали:
А>А причем здесь super? Классы между сообой вообще никак не связаны...
У питона такое типизация не пропустит
class A:
def hello(self):
print'Hello I\'m A.'def Foo(self):
self.hello()
class B:
def hello(self):
print'Hello I\'m B.'def Foo(self):
A.Foo(self)
b = B()
b.Foo()
Traceback (most recent call last):
File "hghghg.py", line 49, in <module>
b.Foo()
File "hghghg.py", line 46, in Foo
A.Foo(self)
TypeError: unbound method Foo() must be called with A instance as first argument (got B instance instead)
FR>Traceback (most recent call last):
FR> File "hghghg.py", line 49, in <module>
FR> b.Foo()
FR> File "hghghg.py", line 46, in Foo
FR> A.Foo(self)
FR>TypeError: unbound method Foo() must be called with A instance as first argument (got B instance instead)
FR>
В 3.0 эти проверки убрали:
>>> class A:
def foo(self):
print("A")
def call_foo(self):
self.foo()
>>> class B:
def foo(self):
print("B")
>>> A.call_foo(B())
B
Здравствуйте, dmz, Вы писали:
A>>за что тут ругали PHP. Почему? Честно говоря, хз. Есть в них преимущества, которые перевешивают упомянутые недостатки. И есть у других "красивых" языков отсутствие этих самых преимуществ. Ну, типа, речь окончена.
dmz>Вот рассказали бы о преимуществах, что ли. Очень интресно, есть ли в PHP хоть одно.
Самое главное — он вездесущ.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Например, чтобы работало такое:
ВВ>
ВВ>$var = "Hello, $username! Today is $date";
ВВ>
В баше такое работает почему-то вот так:
var = "Hello, $username!"
И $ там можно по сути обозвать expand функцией, причем имеющей параметры (!).
Поэтому возможно написать что-то вроде: