Спустя год и три месяца с момента выхода прошлой ветки PHP представлен (http://news.php.net/php.announce/97) новый значительный релиз языка программирования PHP 5.5.0 (http://php.net/). В версии PHP 5.5.0 добавлены новые языковые конструкции, обеспечена поддержка сопрограмм и генераторов, удалены устаревшие возможности и интегрирован Zend Optimizer+ (https://github.com/zend-dev/ZendOptimizerPlus/) (Zend OPcache).
Основные особенности (http://www.php.net/migration55) PHP 5.5.0:- В состав включена система кэширования и оптимизации байткода Zend Optimizer+ (https://github.com/zend-dev/ZendOptimizerPlus/), ранее поставляемая в составе проприетарного пакета Zend Server, но недавно переведённая (http://www.opennet.me/opennews/art.shtml?num=36115) компанией Zend Technologies в разряд свободных проектов. Zend Optimizer+ предоставляет средства для ускорения выполнения скриптов на языке PHP за счёт использования техники кэширования опкода и применения дополнительных оптимизаций. Предкомпилированный код скриптов кэшируется в разделяемой памяти, что позволяет избежать выполнения стадий чтения с диска, разбора и компиляции исходного кода скриптов при их повторном запуске.
Кроме того, Zend Optimizer+ включает дополнительные методы оптимизации при генерации байткода, что позволяет достичь ускорения и за счёт более быстрого выполнения байткода. По сравнению с конкурирующей системой APC, Zend Optimizer+ выигрывает по производительности в среднем на 5-20%, обеспечивает лучшую совместимость с различными ветками и возможностями языка PHP, а также содержит средства для выявления повреждения данных (например, из-за некорректно написанной PHP-функции на языке C).
- Добавлен (https://wiki.php.net/rfc/password_hash) новый API для хэширования паролей, предоставляющий застрахованные от ошибок разработчиков и более простые в использовании высокоуровневые функции для генерации и проверки валидности паролей по хэшам. Основное отличие нового API в том, что он берёт на себя генерацию надёжных хэшей, скрывая от разработчика операции ручного указания salt-а и выбора алгоритма хэширования (по умолчанию используется Bcrypt). Создание хэша сведено к выполнению "$hash = password_hash($password, PASSWORD_DEFAULT);", а проверка к вызову "password_verify($password, $hash)". В качестве причины внедрения нового API называется безалаберное отношение многих разработчиков к генерации salt-ов и повсеместный выбор нестойких к перебору алгоритмов хэширования;
- Поддержка сопрограмм (coroutine) и генераторов (https://wiki.php.net/rfc/generators) (generator), предоставляющих простой и не требующий создания шаблонов способ реализации итераторов;- Поддержка (https://wiki.php.net/rfc/finally) ключевого слова "finally", расширяющего возможности блоков исключений try/catch и выполняемого после завершения выполнения блока try, что гарантирует, что заданный в секции finally код будет выполнен в последнюю очередь после всех остальных обработчиков исключений;
- Поддержка (https://wiki.php.net/rfc/foreachlist) указания list() внутри блока foreach (), что позволяет организовать не требующий создания отдельных временных переменных перебор масивов;
- Возможность разыменования констант для строк и массивов;
- Улучшение модуля ext/intl со средствами интернационализации;
- Возможность (https://wiki.php.net/rfc/empty_isset_exprs) использования empty() и isset() над результатом работы функции и произвольными выражениями (например, empty(foo()));- Прекращение поддержки Windows XP и Windows 2003.
- Прекращение поддержки устаревших функций: php_logo_guid(), php_egg_logo_guid(), php_real_logo_guid(),
zend_logo_guid();- Добавлен метод Generator::throw();
- Реализована серия новых функций в расширении cURL;
- Добавлена поддержка атрибута Max-Age в setcookie();
- Поддержка системы трассировки Systemtap на платформе Linux;
- Оптимизация доступа к временным и компилированным переменным на уровне VM, что позволило сократить число обращений к памяти на 8%;
- Расширение ext/mysql объявлено устаревшим, вместо него следует использовать MySQLi или PDO_MySQL.
- Добавлена опция php.ini для изменения пути к временной директории PHP;
- Добавлены функции mysqli_begin_transaction()/mysqli::begin_transaction();
- Реализованы все опции mysqli_commit()/mysqli_rollback(), которые могут быть использованы с START TRANSACTION, COMMIT и ROLLBACK в MySQL 5.6;
- Добавлены функции-врапперы recvmsg() и sendmsg() для ext/sockets;
- Добавлена функций array_column (https://wiki.php.net/rfc/array_column), которая возвращает запрошенный столбец из многомерного массива;- Добавлена возможность (https://wiki.php.net/rfc/foreach-non-scalar-keys) использования нескалярных итераторов в качестве ключа в цикле foreach (например, "foreach ($iter as $k => $v)");
- Добавлена поддержка (https://wiki.php.net/rfc/cli_process_title) изменения названия процесса через CLI/CLI-Server SAPI функцию cli_set_process_title($title).
URL: http://news.php.net/php.announce/97
Новость: http://www.opennet.me/opennews/art.shtml?num=37239
>В качестве причины внедрения нового API называется безалаберное отношение многих разработчиков к генерации salt-ов и повсеместный выбор нестойких к перебору алгоритмов хэширования;Это проблема языка программирования?
При попадании в опу есть два варианта действий:
1. Направить все усилия, чтобы из опы выбраться.
2. Направить все усилия, чтобы найти виновных, продолжая оставаться в опе неограниченно долго.
Это проблема безалаберных разработчиков.
Если бы язык не поощрял дурость, он не стал бы массовым.
+100500винда тем же путём идёт
>>В качестве причины внедрения нового API называется безалаберное отношение многих разработчиков к генерации salt-ов и повсеместный выбор нестойких к перебору алгоритмов хэширования;
> Это проблема языка программирования?Безалаберность - это проблема языка программирования (точнее, среды исполнения).
Когда язык разрешает делать так: $b = $a + 5; без инициализации $a - это поощряет безалаберность. Вместо того, чтобы бить в тамтамы и сообщать об ошибке, система считает "а вдруг девчонки" и исполняет код. Возможность поделить строку на число и прибавить что-нибудь булевое - из той же пьесы "Безалаберность как норма жизни". Для чего это сделано? Чтобы не пугать явными ошибками в ситуации, когда это явные ошибки? У меня нет оправдания такому ...зму. И именно это - проблема языка программирования, плодящая в в людях совершенно дурные привычки.
И таких дизайн-решений в PHP хватает. Там даже есть несколько уровней предупреждений, когда очевидная проблема может показываться на одной системе и подавляться на другой. Удобно, что тут скажешь. Залил сайт, который у тебя работает, на хостинг, а там полэкрана ошибок. И это тоже проблема языка программирования, развивающая безалаберность.
Не один здравый человек не назовёт такое решение хоть немного вменяемым. Людей с ранних пор приучают к неряшливому программированию, к подавлению ошибок, к наплевательству на всё, к отсутствию стиля. И это - проблема языка программирования.
Не думал, что когда-нибудь буду готов подписаться под каждым словом буратины.
Эй модеры, походу Буратину кто-то хакнул.
> Не думал, что когда-нибудь буду готов подписаться под каждым словом буратины.Там в четвёртом абзаце должно быть "Ни" вместо "Не", так что и на этот раз вам повезло.
$b = $a + 5; без инициализации $a - полный бред. Язык не разрешает это делать.
Касательно прибавления булева числа - разберитесь сначала, что такое булево число.
PHP, конечно, не ангел. Но бросаться на него голословно - дурной тон.
> $b = $a + 5; без инициализации $a - полный бред.
> Язык не разрешает это делать.
> Касательно прибавления булева числа - разберитесь сначала, что такое булево число.
> PHP, конечно, не ангел. Но бросаться на него голословно - дурной тон.http://dev.on.51t.ru/svodka-1371200752.html
разрешает. ещё он разрешает при ошибке в include не падать полностью, а исполнять. вообще, при неверных данных он до конца пытается исполнять, иногда это приводит к выдаче данных, которые не стоило бы показывать.
по твоей же ссылке
PHP Notice: Undefined variable:Читай внимательнее в следующий раз на что ссылаешься.
> по твоей же ссылке
> PHP Notice: Undefined variable:
> Читай внимательнее в следующий раз на что ссылаешься.Ээээ. это мой тест. Оно ИСПОЛНИЛО его. К тому же, у многих в дефолте оно посылает свой stderr в какой-нибудь неведомый лог, и юзер этого нотийса просто не увидит.
Оно обязано тупо упасть, а не угадывать, что имел ввиду разработчик. Ибо чаще всего это банальная опечатка, и из-за этого можно получить трудноуловимую проблему. Должно быть два состояния - правильный код и неправильный, а не "ну, эта, а вдруг?".
Умные люди (как я, например) используют set_error_handler(), чтобы все нотисы/варнинги/etc. превращать в исключения. Так ни один нотис не ускользнёт вне зависимости от настроек в php.ini
> Умные люди (как я, например) используют set_error_handler(), чтобы все нотисы/варнинги/etc.
> превращать в исключения. Так ни один нотис не ускользнёт вне зависимости
> от настроек в php.iniДефолт от этого не изменится. И поэтому даже в этой теме кто-то считает это нормой, а кто-то снабжает код костылями, чтобы эту норму поменять. Именно об этом и шла речь.
няшечка, это не «костыли», это встроеная возможность языка. ты совсем-то херню уже не мели, а.
> Касательно прибавления булева числа - разберитесь сначала, что такое булево число."прибавить что-нибудь булевое - из той же пьесы" - где тут "число"?
>Не один здравый человек не назовёт...
>Ни один здравый человек не назовёт...
Эталонное воплощение понятия профан.
>проблема языка программированияЯзык программирования - это понятие абстрактное. У Я.П. нет,и не может быть проблем, как не может быть проблем у угла в 30 градусов.
>среды исполнения"Среда исполнения" - это переменные окружения и текущий рабочий каталог, вас же обидел "Интерпретатор"
>$b = $a + 5; без инициализации $aВы путаете "инициализацию" и "определение". Причем в данном случае $a как раз автоинициализовано пустой строкой. Это поведение решает проблему наличия глобальных переменных в отсутствии линкера.
>Вместо того, чтобы бить в тамтамы и сообщать об ошибкеНе надо обманывать система выдает предупреждение "Undefined variable".
>Для чего это сделаноУ интерпретируемых языков нет времени для многопроходного ковыряния в коде. Функция статического анализа возложена на сторонние инструменты и программистов. К слову, все не фатальные предупреждения которые выдает выдает g++, к языку с++ никакого отношения не имеют.
>И таких дизайн-решений в PHP хватает"Дизайн" решений в PHP довольно мало. Все изменения в языке направленны были на решение сугубо практических проблем. Как и в с++ и javascript.Это в отличии от языков разработанных теоретиками с чашкой кофе в руке.
>Не один здравый человек не назовёт такое решение хоть немного вменяемымНе один здравый человек не будет разбрасываться такими заявлениями.
>. Это поведение решает проблему наличия глобальных переменных в отсутствии линкера.Это поведение создаёт трудноуловимые ошибки на ровном месте.
>>Вместо того, чтобы бить в тамтамы и сообщать об ошибке
> Не надо обманывать система выдает предупреждение "Undefined variable".Система должна "не исполнять", а падать с ошибкой, чтобы не допускать возможных утечек. Впрочем, для среды "что вижу, то и пою", когда при обновлении сервера, php или чего-то связанного оно может вообще перестать исполнять и вместо этого отдавать сервером сырец приложения, исполнить что-то недостоверное - вообще мелочь. Ибо в php ужасно всё, от начала до конца, куда не ткни - попадёшь в потенциальную проблему, которая часто превращаяется в реальную. И культивирование безалаберности - это первый шаг к этому.
>>Для чего это сделано
> У интерпретируемых языков нет времени для многопроходного ковыряния в коде. Функция статического
> анализа возложена на сторонние инструменты и программистов. К слову, все не
> фатальные предупреждения которые выдает выдает g++, к языку с++ никакого отношения не имеют.Нет ни единой причины считать неинициализированную переменную нормой. Иначе первая же опечатка породит трудноуловимую проблему. А уж стремление и чуть ли не официальный modus operandi подавлять нотайсы на уровне сервера или через @, доводят эти проблемы до серьёзных уязвимостей в "серьёзных" (по меркам php) проектах. И это проблема языка, и это проблема культуры php.
>>И таких дизайн-решений в PHP хватает
> "Дизайн" решений в PHP довольно мало. Все изменения в языке направленны были
> на решение сугубо практических проблем.Да-да, вместо нормальной модульности - функции из 4-х строк, и все в ядре, все в едином пространстве. И почему-то на большинство этих изменений можно сказать "это было в python ещё n-лет назад".
>>Не один здравый человек не назовёт такое решение хоть немного вменяемым
> Не один здравый человек не будет разбрасываться такими заявлениями.Пусть не разбрасывается. Лишь бы php не пользовался.
> Пусть не разбрасывается. Лишь бы php не пользовался.Можно подумать в жабоскрипте что-то лучше
'2' + 2 === '22'; // true
2 + 2 === 4; // true
'3' * '5' === 15; // true
+'2' + 2 === 4; // trueНа чем веб программировать то?
Странный вопрос, конечно на lisp.
> Можно подумать в жабоскрипте что-то лучше
> '2' + 2 === '22'; // trueВот это кстати хуже всего. В PHP "+" (сложение) и "." (конкатенация), тьфу-тьфу, разделены.
> Можно подумать в жабоскрипте что-то лучшеhttp://www.youtube.com/watch?v=kXEgk1Hdze0
> На чем веб программировать то?
на берёзовых бруньках...
> На чем веб программировать то?ни на чём.
>> На чем веб программировать то?
> ни на чём.А на чём фидо программировать?
> А на чём фидо программировать?На бинке? :)
> А на чём фидо программировать?на коленке.
>и вместо этого отдавать сервером сырец приложенияБуратина, признайся уже, php вывалил твой отвратительно написанный сорец и тебя засмеяли коллеги.
>>и вместо этого отдавать сервером сырец приложения
> Буратина, признайся уже, php вывалил твой отвратительно написанный сорец и тебя засмеяли коллеги.мне не жалко, могу и признаться. только я не понял, в чём?
ps. у меня нет коллег :( я сирота :(
> Эталонное воплощение понятия профан.
>>проблема языка программирования
> Язык программирования — это понятие абстрактное. У Я.П. нет,и не может быть
> проблем, как не может быть проблем у угла в 30 градусов.ок. это проблема в мозгах авторов языка. боооольшая проблема. ах, если бы автор изначально спрятал свой пых и никому не показывал…
>>среды исполнения
> «Среда исполнения» — это переменные окружения и текущий рабочий каталог, вас же
> обидел «Интерпретатор»ВНИЗАПНА! интерпретатор является частью среды исполнения.
> Причем в данном случае $a как
> раз автоинициализовано пустой строкой. Это поведение решает проблему наличия глобальных
> переменных в отсутствии линкера.лолшито?
> У интерпретируемых языков нет времени для многопроходного ковыряния в коде.
причём опять ВНИЗАПНА! — это и не является необходимым. оттрейсить сгенерированый байткод (в пределах одной функции), чтобы увидеть, что где-то return забыли, где-то переменную использовали до инициализации и так далее — задача очень простая. делается один раз, ресурсов жрёт пренебрежимо мало.
>>И таких дизайн-решений в PHP хватает
> «Дизайн» решений в PHP довольно мало.угу. примерно одно: «а запилю-ка я язык!» всё остальное — каша, родившаяся из «о! какая фича смешная! щаз мы её тоже добавим!»
>Не один здравый человек не будет...Ни один здравый человек не будет...
Посмеёмся же над полным бредом:> Язык программирования - это понятие абстрактное. У Я.П. нет,и не может быть
> проблем, как не может быть проблем у угла в 30 градусов.Выходит, РНР - тоже что-то абстракное.
Хотя угол в 30 градусов - вещь вполне конкретная.
В общем, конечно, у угла и у ЯП не может быть проблем, они обычно бывают у людей, ими пользующихся.
>>среды исполнения
> "Среда исполнения" - это переменные окружения и текущий рабочий каталог, вас же
> обидел "Интерпретатор"Ну, при том, что переменные окружения и текущий рабочий каталог часто зависят от некоего интерпретатора (shell например), то да, она нас обидел.
А у РНР, насколько известно, интерпретатор (он же единственный) вполне себе работает так, как написано в описании ЯП. А уже из этого описания можно увидеть кучу проблем этого ЯП (точнее, пользователей этого ЯП).>>$b = $a + 5; без инициализации $a
> Вы путаете "инициализацию" и "определение". Причем в данном случае $a как
> раз автоинициализовано пустой строкой.Вы уверены? Странно, что такой ярый защитник РНР не знает его элементарных основ.
> Это поведение решает проблему наличия глобальных
> переменных в отсутствии линкера.Уж не знаю, какую проблему это решает, но наличие глобальных переменных - это в общем не проблема даже в отсутствии линкера, как показывает пример того же Python. А авторы РНР сами создали себе проблемы, устранившись от глобальных переменных.
>>Вместо того, чтобы бить в тамтамы и сообщать об ошибке
> Не надо обманывать система выдает предупреждение "Undefined variable".Вы уверены? Это предупреждение, во-первых, выдаётся в stderr, что уже само по себе бесполезно, во-вторых, обычно отключается с помощью error_reporting, а в-третьих, поясните, как на практике можно использовать механизм "перехвата" предупреждений в РНР - кроме вышеупомянутого stderr.
> У интерпретируемых языков нет времени для многопроходного ковыряния в коде.
> Язык программирования - это понятие абстрактноетаки у языков нет времени? таки РНР однопроходный? (Ну разве что заднепроходный, да.)
С чего вы вообще взяли, что время имеет значение для *интерпретируемых* языков? Почему у других ИЯП "есть время"?> Функция статического анализа возложена на сторонние инструменты и программистов.
С каких пор определение совместимости типов в операциях у динамически типизируемых ЯП является Функцией статического анализа?
> К слову, все не
> фатальные предупреждения которые выдает выдает g++, к языку с++ никакого отношения
> не имеют.Видимо, следовательно, и предупреждения в РНР к языку РНР тоже не имеют отношения. Ура!
> "Дизайн" решений в PHP довольно мало.
по сравнению с? Хотя, наверно, хорошо, что их мало. *Таких* решений лучше бы вообще не было.
> Все изменения в языке направленны были
> на решение сугубо практических проблем...возникших в этом языке из-за "Дизайн" решений
(Уж не говоря о том, что "изменения в языке" - это подразумевает наличие исходного "языка". PHP/FI, написанный на перле, языком явно не назовёшь.)> Как и в с++ и javascript.Это
> в отличии от языков разработанных теоретиками с чашкой кофе в руке.Наоборот, в отличие от с++ и javascript, разработанных теоретиками с чашкой кофе в руке, РНР был разработан непонятно кем с пивом в руке и баксами в уме.
У РНР есть ещё шанс остаться, если отбросить уродскую концепцию обратной совместимости, которая, впрочем, всё равно у него никогда не работала.
Делать язык на уровне Питон 0.9-альфа с Си-синтаксисом в нынешнее время не имеет никакой практической ценности. А с той скоростью релизов и с той процедурой принятия решения, что есть сейчас, даже уровня Питон 0.9-альфа ждать ещё лет *дцать.
> А у РНР, насколько известно, интерпретатор (он же единственный) вполне себе работает
> так, как написано в описании ЯП.Это гораздо лучше, чем если бы он работал не так, как в описании. Множество молодых интерпретаторов этим больны.
> Наоборот, в отличие от с++ и javascript, разработанных теоретиками с чашкой кофе
> в руке, РНР был разработан непонятно кем с пивом в руке
> и баксами в уме.И - ЧСХ - оно работает. И на нем работает реально фигова туча всего. В отличие от некоторых представителей непонятных видов.
Опять же - имеем жесткое такое столкновение академотеоретиков и инженеров-практиков. PHP - скорее инженерный язык (как и C), на нем удобно решать небольшие практические задачи, а не рисовать сферических коней в вакууме. Когда-то эту нишу занимал перл, но, увы, откинулся... в первую очередь из-за зубодробительного невменяемого синтаксиса.
>Когда язык разрешает делать так: $b = $a + 5; без инициализации $a - это поощряет безалаберность.не позволяет. Я пробовал. И если вы осуждаете какую-то сущность, потрудитесь ее хотя бы минимально узнать. Операции с неинницилиазированными объектами выдают эксепшн, как и в Си, например. Если же вы работаете, с блокировкой эксепшнов, то это именно low level или безалаберность. На "сях" тоже можно игнорировать вонинги компиляции и это может прокатить, а может и вылиться в серьезные проблемы. И что? Си, после этого, порождает бездарей? Поэтому, вместо того, чтобы писать тут холиварные глупости, идите подучите предметную область :)
>>Когда язык разрешает делать так: $b = $a + 5; без инициализации $a - это поощряет безалаберность.
> не позволяет. Я пробовал. И если вы осуждаете какую-то сущность, потрудитесь ее
> хотя бы минимально узнать. Операции с неинницилиазированными объектами выдают эксепшн,
> как и в Си, например.Я уже приводил ссылку. Я просто сделал apt-get install php5-cli (свят! свят! свят!), и всё. Если бы это было не так, то не было бы истерии с register_globals (мне всё в голову не приходило, что в нём плохого? а, оказывается, это язык ушибленный на всю голову, и пришлось, после того, как дали удобную вещь, забирать обратно, потому что количество суицидов возросло многократно).
<?php
print ('5'+5) . "\n";
print ('0'==0) . "\n";
$a=$a+5;
print $a . "\n";
print empty('0');
?>10
1
PHP Notice: Undefined variable: a in /tmp/test.php on line 4
5
1вот ещё (ну и язычок, сначала умаялся дописывать . '\n', а потом ещё кавычки менять на двойные, потому что без них оно не понимает). вот, летний хит:
<?php
print 1 + false . "\n";
print 'hello' + false . "\n";
print 1 + true . "\n";
print 'hello' + true . "\n";
print '5' * 20 . "\n";
print 'a' * 20;
?>1
0
2
1
100
0
>Я уже приводил ссылку. Я просто сделал apt-get install php5-cli (свят! свят! свят!), и всё.еще раз - не умеете пользоваться - не пользуйтесь. При включении соответствующего уровня отладки и перехвате исключений такие ошибки ловятся еще в процессе написания. Т.е. вы не осилили элементарные встроенные средства, но уже всех "посчитали"... круто, чо! Изобретателя указателей в "сях" по-вашему, хуже дьявола :)))
>>Я уже приводил ссылку. Я просто сделал apt-get install php5-cli (свят! свят! свят!), и всё.
> еще раз - не умеете пользоваться - не пользуйтесь. При включении соответствующего
> уровня отладки и перехвате исключенийМы говорим о том, что язык культивирует. Чтобы разобраться в подобных "сделать из дефолта что-то сравнимое", это тупо нужно знать. А я не могу представить ни одного новичка, который не пишет код, боясь получить вредные привычки, а неделями вдумчиво читает конфиги, исходники ядра, и тому подобное, чтобы собрать идеальную конфигурацию.
Когда к такой конфигурации приходишь, привычки уже давно сформированы, и идёт минимизация последствий. Но, если бы новичок сразу бы выбрал python, он бы и не имел подобных привычек, и сразу бы понимал, почему такое поведение по умолчанию - ЭТО ОЧЕНЬ ХРЕНОВО.
>Мы говорим о том, что язык культивирует. Чтобы разобраться в подобных "сделать из дефолта что-то сравнимое", это тупо нужно знатьэто называется профессионализм, бэби. Если ЖД шпалы будут укладывать люди, которым лень "тупо" узнать, как надо, у нас все поезда под откос уйдут)
[offtopic]странную тенденцию заметил: последние 5-6 лет, народ хочет тупо рубить бабло, но при это не то что не работать, даже думать не хочет)))[/offtopic]
> это называется профессионализм, бэби. Если ЖД шпалы будут укладывать люди, которым лень
> "тупо" узнать, как надо, у нас все поезда под откос уйдут)Откуда новичку обо всём этом узнать? Проблема именно в том, что он культивирует дурные привычки, а не в том, что обязательно им следовать. Можно и на php писать более нормально, чем остальные (если немного поскитаться по рубям и иже), но это изменит что-то для тебя, а не для языка. php.exe-то крив.
> [offtopic]странную тенденцию заметил: последние 5-6 лет, народ хочет тупо рубить бабло,
> но при это не то что не работать, даже думать не
> хочет)))[/offtopic]Не знаю, меня деньги не интересуют. Вообще, как класс.
>Я просто сделал apt-get install php5-cli (свят! свят! свят!), и всёт.е. если вендор вашей ОС не заботится о сторонних пакетах - это проблема пыха? ЛОЛ!
>...
>Откуда новичку обо всём этом узнать?От верблюда) И вообще, о таких буратинах надо на лурморе написать статью из серии "А-а-а, строители-плохиши! Сделали дом с окнами и не предупредили, что из окна выпасть можно! Вай-вай-вай, плохие")))
Ладно, хватит троллить, идите в сад, потом в школу! Лет через 10 вернетесь - обсудим!)
> Откуда новичку обо всём этом узнать?ты мне, конечно, не поверишь, но у нормальных людей принято сначала изучать язык, а только потом ваять на нём код.
>> Откуда новичку обо всём этом узнать?
> ты мне, конечно, не поверишь, но у нормальных людей принято сначала изучать
> язык, а только потом ваять на нём код.Дело не в языке. А в том, что в реальности новичка нет понятия "ушибленные разработчики php".
Когда код работает или не работает в зависимости от всех этих magic_quotes, register_globals и системы подавления ошибок. У Васи на сервере так, и оно работает. У Пети не так, и оно не работает. Пыхеры не могут договориться, как должно быть, и в итоге превращают это в настройку. А дефолт везде разный, и если помножить упрямство пыхеров на особенности реализации роутов (которых в пыхе нет, как класса), получается, что у каждого главного пыхера свой пых, со своими особенностями реализации.
Если это не πzдец, то что πzдец? Если это не лечить, то дурдома в нашем мире стоит вообще закрыть за ненадобностью.
ps. И это в то время, когда мой твитер можно запустить хоть на винде, хоть на haiku, где есть только стандартная библиотека python 2.7, и не нужно никаких серверов, и не нужно никаких огородов. Вот где красота для новичков, всё просто, понятно и предсказуемо. И никаких пыхеров, я отвечаю. :)
> Поддержка сопрограмм (coroutine) и генераторов (generator), предоставляющих простой и не требующий создания шаблонов способ реализации итераторов;Вот я никогда не понимал, зачем? Кому нужно писать на php, тем всё это добро не впилось, только мешает. А тем, кому всё это нужно, на php писать в здравом уме не будет. В итоге только переусложнение "для своих", и этим никак не привлечь "чужих", у кого подобная функциональность есть давным-давно (а то прям в окно выглядываю и вижу, что за массовый забег, куда бегут все эти люди? а это с эрланга перебегают на php).
Впрочем, раз надо, так надо. Чем бы дети не тешились. :) Дай им бог здоровья. Лет через 10 и php 5.5 до хостингов докатится. :)
Он практичен и удобен для скриптовых решений. Нет возни с предкомпиляцией, C-подобный синтаксис, огромное число встроенных функций прямо в языке, без подключения модулей. И так далее.
> огромное число встроенных функций прямо в языкеэто да. прямо в глобальном namespace. причём хоть бы имена в одном стиле выдерживали…
> Он практичен и удобен для скриптовых решений.в сравнении с чем? С Си? с шеллом?
> Нет возни с предкомпиляцией,
это не плюс именно РНР.
> C-подобный синтаксис,
это и плюс, и минус.
> огромное число встроенных функций прямо в языке, без подключения модулей.О да! при этом если модуль не подключен, то без root вы его вообще в принципе не подключите. Cool.
Не говоря о том, что всё равно никто не в состоянии запомнить не то что 50 000 функций в индексе руководства, но и банально их названия, порядок и типы аргументов str_replace vs strtr, strip_tags vs stripslashes, array_search(arg, array) vs array_filter(array, arg) и прочие array_shit vs (array_)fuck и str_shit vs strfuck, которые во всех нормальных ЯП являются методами Array и String.
> И так далее.
>> C-подобный синтаксис,
> это и плюс, и минус.Это плюс. Когда вы пишете только на 1С (питоне, руби, нужное вписать) - вы пишете только на одном языке, и привыкаете к его синтаксису до уровня прибивания гвоздями.
Когда вы универсал - вам будет удобнее C-шный синтаксис, ибо он и в C, и в плюсах, и в PHP, и даже в жабе с шарпами.
> О да! при этом если модуль не подключен, то без root вы
> его вообще в принципе не подключите. Cool.С чего бы это? На шаредах - вероятно, не разрешенные - да, тьфу-тьфу. На собственных площадках - почему нет? Если все либы доступны, и ini'шка на редактирование доступна.
> Не говоря о том, что всё равно никто не в состоянии запомнить
> не то что 50 000 функций в индексе руководстваМануал под рукой иметь не принято, угу. Настоящему кодеру^W камикадзе мануалы ни к чему.
> Мануал под рукой иметь не принято, угу. Настоящему кодеру^W камикадзе мануалы ни
> к чему.один из признаков хорошо сдизайненого языка — логичность. бесспорно, можно зазубрить 100500 разных названий функций и порядок их аргументов: пыхеры так и пытаются делать (и фэйлят). а можно иметь *консистентную* (пардон май френч) схему именования и логичный одинаковый порядок аргументов — и тогда в мануал надо лазить *гораздо* реже.
> один из признаков хорошо сдизайненого языка — логичность. бесспорно, можно зазубрить
> 100500 разных названий функций и порядок их аргументов: пыхеры так и
> пытаются делать (и фэйлят). а можно иметь *консистентную* (пардон май френч)
> схему именования и логичный одинаковый порядок аргументов — и тогда в
> мануал надо лазить *гораздо* реже.Все зависит от количества встроенных функций. В PHP их _слишком_ много. Но это - одно из удобств метаязыка, жертвовать которым не стоит. Все равно ведь придется лазить в мануал - только уже не по языку, а по нужным библиотекам. Разницы - никакой. Ну и да - между разными библиотеками *конзистентности* обычно тоже где-то в районе 0.00.
> Все равно ведь придется лазить в мануал - только уже не по
> языку, а по нужным библиотекам. Разницы - никакой.Разница большая. В полкилометра.
import bottle
dir(bottle)
['AppEngineServer', 'AppStack', 'AutoServer', 'BaseRequest', 'BaseResponse', 'BaseTemplate', 'BjoernServer', 'Bottle', 'BottleException', 'BytesIO', 'CGIServer', 'CheetahTemplate', 'CherryPyServer', 'ConfigDict', 'DEBUG', 'DictMixin', 'DictProperty', 'DieselServer', 'ERROR_PAGE_TEMPLATE', 'EventletServer', 'FapwsServer', 'FileCheckerThread', 'FileUpload', 'FlupFCGIServer', 'FormsDict', 'GeventServer', 'GunicornServer', 'HTTPError', 'HTTPResponse', 'HTTP_CODES', 'HeaderDict', 'HeaderProperty', 'HooksPlugin', 'JSONPlugin', 'Jinja2Template', 'LocalRequest', 'LocalResponse', 'MakoTemplate', 'MeinheldServer', 'MultiDict', 'NORUN', 'PasteServer', 'PluginError', 'Request', 'ResourceManager', 'Response', 'RocketServer', 'Route', 'RouteBuildError', 'RouteError', 'RouteReset', 'RouteSyntaxError', 'Router', 'RouterUnknownModeError', 'ServerAdapter', 'SimpleCookie', 'SimpleTemplate', 'TEMPLATES', 'TEMPLATE_PATH', 'TemplateError', 'TemplatePlugin', 'TemporaryFile', 'TornadoServer', 'TwistedServer', 'UrlSplitResult', 'WSGIFileWrapper', 'WSGIHeaderDict', 'WSGIRefServer', 'WaitressServer', '_HTTP_STATUS_LINES', '_ImportRedirect', '__author__', '__builtins__', '__doc__', '__file__', '__license__', '__name__', '__package__', '__version__', '_closeiter', '_debug', '_e', '_file_iter_range', '_hkey', '_lctx', '_lscmp', '_parse_qsl', '_raise', '_re_flatten', '_stderr', '_stdout', 'abort', 'app', 'auth_basic', 'base64', 'cached_property', 'cgi', 'cheetah_template', 'cheetah_view', 'cookie_decode', 'cookie_encode', 'cookie_is_encoded', 'datedate', 'datetime', 'debug', 'default_app', 'delete', 'depr', 'email', 'error', 'ext', 'format_exc', 'functools', 'get', 'hmac', 'hook', 'html_escape', 'html_quote', 'httplib', 'imap', 'imp', 'install', 'itertools', 'jinja2_template', 'jinja2_view', 'json_dumps', 'json_lds', 'json_loads', 'lazy_attribute', 'load', 'load_app', 'local', 'local_property', 'make_default_app_wrapper', 'makelist', 'mako_template', 'mako_view', 'mimetypes', 'mount', 'os', 'parse_auth', 'parse_date', 'parse_range_header', 'path_shift', 'pickle', 'post', 'print_exc', 'put', 'py', 'py25', 'py31', 'py3k', 're', 'redirect', 'request', 'response', 'route', 'run', 'server_names', 'static_file', 'subprocess', 'sys', 'tempfile', 'template', 'thread', 'threading', 'time', 'timedelta', 'tob', 'tonat', 'touni', 'uninstall', 'update_wrapper', 'url', 'urlencode', 'urljoin', 'urlquote', 'urlunquote', 'view', 'warnings', 'with_statement', 'yieldroutes']
help(bottle.route)Help on function route in module bottle:
route(*a, **ka)
A decorator to bind a function to a request URL. Example::
@app.route('/hello/:name')
def hello(name):
return 'Hello %s' % name
The ``:name`` part is a wildcard. See :class:`Router` for syntax
details.
:param path: Request path or a list of paths to listen to. If no
path is specified, it is automatically generated from the
signature of the function.
:param method: HTTP method (`GET`, `POST`, `PUT`, ...) or a list of
methods to listen to. (default: `GET`)
:param callback: An optional shortcut to avoid the decorator
syntax. ``route(..., callback=func)`` equals ``route(...)(func)``
:param name: The name for this route. (default: None)
:param apply: A decorator or plugin or a list of plugins. These are
applied to the route callback in addition to installed plugins.
:param skip: A list of plugins, plugin classes or names. Matching
plugins are not installed to this route. ``True`` skips all.
Any additional keyword arguments are stored as route-specific
configuration and passed to plugins (see :meth:`Plugin.apply`).
А если использовать не python, а ipython... Можно хоть "на месте" брякнуться в ipython и заисследовать всё, что под руку попадётся. с автокомплитом и всеми делами. из коробки, приделывается моментально.Плюс есть pydoc.
Ох лол, в качестве доказательств ущербности php приводить не менее ущербный гвидобейсик.
Лет через 10 надеюсь ты руби осилишь и поймешь что зря страдал всё это время.
> Ох лол, в качестве доказательств ущербности php приводить не менее ущербный гвидобейсик.
> Лет через 10 надеюсь ты руби осилишь и поймешь что зря страдал всё это время.Я на python с ruby перешёл. Впрочем, я не думаю, что я какой-то язык "осилил", я не разработчик и не имею мышление разработчика, я этот, как его... куманитарий, пестики-цветочки.
Python сам осилился.
тут уже приводили чудесные примеры консистентных наименований. и чудную единообразность в порядке аргументов.пойми: одно дело — это когда идёшь в мануал, чтобы узнать про API, предоставляемый некоторой библиотекой. и совсем другое — когда идёшь смотреть, есть ли в функции, имя которой ты примерно помнишь, подчёркивание, или нет. и какой у неё порядок аргументов — а то у разных функций в одном и том же куске API он разный.
понимаешь, strcpy(dest, src), strcat(dest, sct), strchr(str, char) — это консистентно. а вот strcpy(dest, src), concatenatestrings(src, dest), str_chr(str, char) — это ужасно неудобно. потому что помнить, что есть нужная функция — ты помнишь, а вот зазубривать, где там подчёркивание ставят, а где нет, и где dest в начале, а где в конце — утомительно.
Согласен. С конзистентностью строковых функций у PHP большие проблемы, конечно :(С другой стороны - малой кровью уже не переделать, потому что большая масса кода сразу скривится. Давать всем названиям функций новые алиасы... добавит неоднозначности. В общем дергаться достаточно поздно. Радует, что новые вносимые функции более-менее стандартизуются.
> Согласен. С конзистентностью строковых функций у PHP большие проблемы, конечно :(
> С другой стороны - малой кровью уже не переделать, потому что большая
> масса кода сразу скривится. Давать всем названиям функций новые алиасы... добавит
> неоднозначности. В общем дергаться достаточно поздно. Радует, что новые вносимые функции
> более-менее стандартизуются.Если девелоперы php найдут, как это сделано в python, то может быть и скопируют (как половину нынешнего ченчлога). Лет через 25. :)
> Если девелоперы php найдут, как это сделано в python, то может быть
> и скопируют (как половину нынешнего ченчлога). Лет через 25. :)Спасибо. Совместимость ГБ между 2.7 и 3 мы уже видели. Лучше пусть останутся слегка неконзистентные функции, чем перестанет работать половина кода.
>> Если девелоперы php найдут, как это сделано в python, то может быть
>> и скопируют (как половину нынешнего ченчлога). Лет через 25. :)
> Спасибо. Совместимость ГБ между 2.7 и 3 мы уже видели.Это разные ветки. И никто не заставляет пользоваться именно 2.7 или именно 3.3, какую хочешь, такую и выбирай и пользуйся. В чём проблема? Комплекс буриданова осла?
А мы видели и "совместимость" между 5.2 и 5.3, да и deprecated чего-нибудь часто используемого в php - это норма. :) Потому что как что-то начинают часто использовать, это что-то становится дырой в безопасности. :)
> А мы видели и "совместимость" между 5.2 и 5.3Между прочим - при нормальном коде прекрасно совместимы. Лично перевёз базу кода системы управления в 20+ Мб вообще без модификаций. И на 5.4 перейдём примерно так же.
>> А мы видели и "совместимость" между 5.2 и 5.3
> Между прочим - при нормальном коде прекрасно совместимы. Лично перевёз базу кода
> системы управления в 20+ Мб вообще без модификаций. И на 5.4 перейдём примерно так же.Ну так на python 2.2 тоже стабильность.
Причём здесь "нормальном коде" и "изъяты некоторые вещи, а некоторые стали другими". когда конструкция <? ?> то поддерживалась, то не поддерживалась. Откуда знать, что <? ?> это ненормальный код? Особенно, если это legacy с давних времён?
В python таких проблем нет. А уж псевдопроблема про выбор python 2.7 и 3.3 - это вообще дурость. Если исполнять - то просто берёшь соответствующую версию, и исполняешь. Если писать - то берёшь, и на чём нравится, пишешь - если писал на 2.x, то и пиши, код будет работать. Если нюбик - выбирай сразу 3.x, он прикольный. Если нужно портировать, то сначала 2to3, а потом проблемные места ручками, это не трагедия. Я в скором времени всё на python 3.x портирую.
А "при прекрасном коде нормально совместимы". Тому же файлу bottle.py вообще пофиг, каким python-ом его запустили, он прекрасно работает и на python 2 и на python 3. И некоторый мой код на bottle тоже работает на python 3 в лоб. Если вдруг завтра за использование python 2 начнут расстреливать, я не вижу проблем мигрировать. А сейчас - не вижу проблем, всё работает и так, и НИКАКИХ проблем нахождение в системе python2 и python3 вообще не приносит. Это как если бы в python2 добавили библиотеку future3, хошь используй, хошь не используй, ничего не поменяется. Или это действительно трагедия на почве того, что 20 мб жалко?
> Согласен. С конзистентностью строковых функций у PHP большие проблемы, конечно :(вот об этом я и говорил всё время, собственно. груз легаси плюс изначальное отсутствие дизайна.
и, ради всех святых и демонов, хоть кто-то пояснит мне, ЗАЧЕМ В PHP СИГИЛЫ?
> Это плюс. Когда вы пишете только на 1С (питоне, руби, нужное вписать)
> - вы пишете только на одном языке, и привыкаете к его
> синтаксису до уровня прибивания гвоздями.
> Когда вы универсал - вам будет удобнее C-шный синтаксис, ибо он и
> в C, и в плюсах, и в PHP, и даже в
> жабе с шарпами.Чепуха. Я и на ruby пишу и на c++/objective-c/java/perl/sh
> Вот я никогда не понимал, зачем? Кому нужно писать на php,Ну так не пиши. Тебя что по вечерам избивают, заставляя писать на php?
Я например не пишу, но и не истерю. А ты как всегда разводишь бодягу на тему какой ты дартаньян. Что заставляет подозревать в тебе обычного кодеришку.
А вообще, судя по ченчлогу, php плавно скатывается в python (разработчики явно с туториала python-а не вылазили), только с С-синтаксисом и набором legacy-ужаса.Но, опять же, зачем? Зачем нишевую вещь превращать в гибрид ужа и матрёшки? Кому это надо? Отпугнуть одних и не привлечь других.
Или это уже агония?
Тоже самое говорили такие же «аналитики» про 5.0 версию — «php скатился в java», «зачем это нужно». Агония затянулась, не находите?
> Тоже самое говорили такие же «аналитики» про 5.0 версию — «php скатился
> в java», «зачем это нужно». Агония затянулась, не находите?Раньше сравнимых альтернатив по сложности/стоимости не было, и php мог хоть каждые три дня менять функции, стерпели бы (живой пример - mswindowstm). А сейчас, когда особых причин выбирать php нет (кроме привычки), вместо того, чтобы сохранять тех, кто даёт языку ценность, они лезут туда, куда его пользователям не особо и надо...
Кто использует родные функции map/reduce/filter в php, поднимите руки?! Кто использует нововведения 5.3 и 5.4, много ли таких?
Ну а что половина ченчлога это python в чистом виде, вплоть до скобочек - это вообще смешно.
Пхп есть смысл выбирать хотя бы потому, что это сейчас единственный нормальный инструмент веб-разработки. Питон - поделка для лабораторных исследователей и админских утилит, с убогим ООП и отсутствием поддержки контрактного программирования "из коробки". Руби - тот же перл, где можно одно утверждение написать восемью способами, поэтому суппортить проекты на нем невозможно. Ява - микроскоп для забивания гвоздей.
выше мы можем прочитать поппеншмерц похаписта.
> Руби - тот же перл, где можно одно утверждение написать восемью
> способами, поэтому суппортить проекты на нем невозможно.Это зависит от стандартов на код, если их нет, то да, будут проблемы, но так в любом языке.
> Пхп есть смысл выбирать хотя бы потому, что это сейчас единственный нормальный инструмент веб-разработки.Похоже что пых это как раз самый ненормальный инструмент веб-разработки.
> Кто использует родные функции map/reduce/filter в php, поднимите руки?!Все используют, они написаны на C и более оптимальны, чем если писать руками интерпретируемый цикл.
> Кто использует нововведения 5.3 и 5.4, много ли таких?
Ну как только мигрировали на серверах, так сразу и стали использовать, $res = []; удобнее писать чем $res = array();
> Ну а что половина ченчлога это python в чистом виде, вплоть до
> скобочек - это вообще смешно.Смешно — это библиотеки python и их совместимость с python 2 и python 3 :)
> Ну как только мигрировали на серверах, так сразу и стали использовать, $res
> = []; удобнее писать чем $res = array();Надо же :)
Только в python, наоборот, как-то нагляднее получается, когда пишешь list(), dict(), set(), tuple(). Чтобы сохранить единообразие при заполнении и использовании. Чаще требуется не пустой, а заполненный dict (а я вообще всегда использую свой mydict).
Как-то проще и писать, и читать
a = dict(users=users,girls=girls,datas=datas)
чем
a = { "users": users, "girls": girls, "datas": datas }
да и вообще, с таким "диктованием", как в python, проще вообще всё в dict-ы заворачивать, и вместо:
def myfunc(hello,world,yet1,yet2,yet319,bss):
if something:
myfunc(hello,world,'','','','')
elif sky==14:
myfunc(hello,world,sky,sky1,sky319,bss)
else:
myfunc(hello,'no','no','no','no','no)использовать:
def mykw(**kw):
if 'sky' in kw:
print 'sky!'
if 'zzz' in kw:
print 'zzz!'r = dict(sky=14,hello=hello)
if something: r.update(zzz=something)
mykw(r)впрочем, и в первом случае можно использовать дефотлвалуи
def myfunc(hello='',world='no',bss='bss'):
if hello: print hello
if world: print world
if bss: print bssmyfunc(hello='15')
15
no
bssmyfunc(bss='')
noили
r = dict(hello='',world='')
myfunc(**r)
bss
поэтому все эти страшные myfunc(nado,nado,nado,ochennado) - в прошлом, и поэтому dict(), list() используется довольно часто. И лучше привыкать к ним везде, это не такая уж проблема, написать a = dict() вместо a = {}
> myfunc(**r)единообразие налицо, ага. {}, значит — это сложно, ради единообразия пишем dict(). а вот ** вместо какого-нибудь unpack() — это ничего, это нормально.
гвидофаны такие гвидофаны.
>> myfunc(**r)
> единообразие налицо, ага. {}, значит — это сложно, ради единообразия пишем dict().
> а вот ** вместо какого-нибудь unpack() — это ничего, это нормально.
> гвидофаны такие гвидофаны.Ковычки, скобочки, двоеточечки - отвлекают внимание, когда они перемешаны. Взгляд туда сюда тащится.
**r никак не отвлекает внимание, не усложняет лексический парсер глаз. myfunc(unpack(r)) однозначно усложнит парсинг глазами и увелчит нервную усталость (мозгу нужно о фигне думать) из-за двойных скобок. Терпеть не могу двойных (а уж как не могу терпеть тройных-четверных)))) скобочек, за ними всеми нужно следить, как за дитями маленькми. Хуже только } в условиях { :)
я не сомневался, что у тебя есть Обоснование. а вот я тебе скажу, что длинные слова вместо понятных знаков отвлекают намного больше. особенно если эти слова — часто встречающиеся конструкции. это как раз и есть мусор, на парзинг которого надо тратить лишнее время.
> я не сомневался, что у тебя есть Обоснование. а вот я тебе
> скажу, что длинные слова вместо понятных знаков отвлекают намного больше.Это вы о чём?
>> я не сомневался, что у тебя есть Обоснование. а вот я тебе
>> скажу, что длинные слова вместо понятных знаков отвлекают намного больше.
> Это вы о чём?myvar = {…} — шибко проще читается, чем myvar = dict(…).
>>> я не сомневался, что у тебя есть Обоснование. а вот я тебе
>>> скажу, что длинные слова вместо понятных знаков отвлекают намного больше.
>> Это вы о чём?
> myvar = {…} — шибко проще читается, чем myvar = dict(…).raz=raz,dva=dva,tri=tri
шибко проще читается, чем
{ "raz": raz, "dva": dva, "tri": tri }
(даже сейчас в наборе я на вторую строчку затратил в три раза больше времени и больше отвлекался)
вообще, в python, разумеется, можно использовать оба способа, но лично мне первый стал ближе, если раньше я использовал второй способ постоянно, то теперь - очень редко.
> raz=raz,dva=dva,tri=tri
> шибко проще читается, чем
> { "raz": raz, "dva": dva, "tri": tri }кроме того, это вводит единообразие с вызовом функций, везде всё одинаковое.
> raz=raz,dva=dva,tri=tri
> шибко проще читается, чем
> { "raz": raz, "dva": dva, "tri": tri }совершенно не факт. во второй форме я сразу вижу, где имена полей, а где значения. в первой это не так очевидно, не «бросается в глаза».
>> raz=raz,dva=dva,tri=tri
>> шибко проще читается, чем
>> { "raz": raz, "dva": dva, "tri": tri }
> совершенно не факт. во второй форме я сразу вижу, где имена полей,
> а где значения. в первой это не так очевидно, не «бросается в глаза».это не просто факт, это самый настоящий мазефакт!
впрочем, кто как хочет, тут пусть так и использует. можно оба варианта. так указывает и мануал python 1.4 1996 года. в отличие от php, где это появилось совсем недавно "яки чудо". Спросил, кто какие фишки из 5.3/5.4 использует, а в ответ - []; вместо array(). чюдо.
слушай, тебя действительно какой-то похапэшник обидел? ну вот зачем ты тащишь похапэ туда, где его вообще не упоминали?
> слушай, тебя действительно какой-то похапэшник обидел? ну вот зачем ты тащишь похапэ
> туда, где его вообще не упоминали?Вы за нитью дискуссии вообще следите? Это изначально был ответ на "в 5.3/5.4 где-то там появилось []".
PHP-шники меня не обидели. Это я их обижаю постоянно. Если бы не был бы христианином, заснял бы на камеру, как я их пинаю, и гордился бы этим. Но мне стыдно, поэтому не снимаю и не пинаю. Но, скорее всего, научу их любить python, если не сбегут раньше.
Но вообще, конечно, тот хаос, который плодят php-шники, не прошёл мимо меня незамеченным. Можно сказать, что mediawiki мне полжизни искалечила и лишила крупной суммы денег только из-за того, что я в неё поверил. Но можно и не говорить.
> Вы за нитью дискуссии вообще следите?а ничего, что с тех пор дискуссия ушла несколько в сторону? или в голове жёсткие рельсы, шаг влево или вправо невозможен?
> Но, скорее всего, научу их любить python
война была равна, сражались два…
>> Вы за нитью дискуссии вообще следите?
> а ничего, что с тех пор дискуссия ушла несколько в сторону?У меня всё записано.
> или в голове жёсткие рельсы, шаг влево или вправо невозможен?
В теме про пых упомянуть пых - это что-то невероятное? :)
>> Но, скорее всего, научу их любить python
> война была равна, сражались два…Дело было в вебе. Для веба python ахренительно хорош. Особенно, если прибирать за младоразработчиками. Пыхокод обычно используется один раз и после выкидывается, ни о каком развитии речи не идёт.
Меня не интересуют технологии, меня интересуют люди и социальные вопросы. Если бы я знал технологию вместо python, которая позволила бы решать эти задачи лучше - я бы уже сегодня побежал за ней. Но я её не знаю. Может быть, её просто нет?
> Дело было в вебе. Для веба python ахренительно хорош.Мы видим, угу.
http://w3techs.com/technologies/overview/programming_languag...
>> Дело было в вебе. Для веба python ахренительно хорош.
> Мы видим, угу.
> http://w3techs.com/technologies/overview/programming_languag...Есть такая вещь, называется "свой мозг".
Технологии понятного твитера за 2 часа и в 100 строк на php я так и не увидел. Когда на php 99% кода 'write once', который потом выкидывается, когда приходит следующий пыхер - это просто круговорот. На python тупо удобнее, что не возьми, на python оказывается удобнее и быстрее. И не надо молиться на новую версию, чего там ещё возьмут у конкурентов - даже python 2.7 практически идеал для быстрой веб-разработки от чего-то мизерного до крупного и модульного (а слова php и "модульность" вообще рядом лучше не ставить).
Даже если по каким-то левым графикам и по legacy-поддержке php будет 122.4523%, на python всё равно будет удобнее. Это доказывается и тем, что знающие python и php используют python, и тем, что даже прожжёные пыхеры радуются появлению в php функций, которые в python уже были двадцать лет назад (а скольких там ещё нет).
Просто тупо удобнее. И это знают пыхеры. И поэтому у них никогда не было аргументов на тысячи записей (включая мою, со знанием php с 2002 года), что python превосходит php по удобству, по красоте, по понятности в разы. Только лабуда всякая. По одной простой причине - их бесит, что их раскрасивый php, убог как тряпка. Что их крыша тупо тырит функции с python и других, чтобы превратить php в "язык программирования". И что их тупость никогда не позволит им научиться писать на python грамотно, а неграмотно на python писать очень больно.
Поэтому пыхеры и ведут свои священные войны, и на реальные неопровержимые аргументы привностят только то, что Петя и его друзья-недоумки пишут на php (классная компания, ребята, там и оставайтесь. отлично, что сами себя на такой уровень поставили). Но всё равно, несмотря на силу недоумков, для серьёзной разработки php не используют, никто не будет делать серьёзный проект на php, в google нет php, инстаграмы пишут на python, а не на php. На php пишут только недоумки. Пусть пишут. Только пусть не лезут со своим калашным рылом, которое они называют "мнением". php-кодеры - это самый низший уровень. и пыхеры это прекрасно знают, все до единого. все до единого при слове "быдлокодер" и "быдлоязык" представляют, АВТОМАТИЧЕСКИ представляют именно php. И натуру не обманешь. :)
А на python всё равно писать удобнее. И это классный язык. Как бы пыхеры не пыжились и не пытались статистикой обмануть здравый смысл и элементарную логику (как будто они не понимают, почему php массовый, и что это вообще слабо коррелирует с культурой и удобством).
Пойми. Я не говорю, что python плох. Он для веба ни хорош, ни плох. Его просто НЕТ. Возможно, это временное явление, возможно - нет. Тренды говорят о том, что и не будет - но... кто знает, PHP когда-то тоже всерьез особо не воспринимали.
>По одной простой причине - их беситПо моему бесит тут как раз пвас, остальные вроде спокойны.
>>По одной простой причине - их бесит
> По моему бесит тут как раз пвас, остальные вроде спокойны.Меня бесят все эти люди, которые ходят за мной и рассказывают, что php, оказывается, можно сравнивать с python. Бред полнейший, я на php писал, когда они ещё под стол ходили. И не один мне ещё не привёл примера, чтобы человек, много лет знающий и php и python, говорил бы, что ему больше нравится php. Обратных - полинтернета.
А пыхеров бесит то, что все, кроме пыхеров, читают их "быдлокодерами". И что пых нигде не воспринимают. Приди в google и скажи "я веб-разработчик на php", смеяться будут так, что здесь будет слышно. А на python там много чего делается.
> Меня бесят все эти люди, которые ходят за мной и рассказывают, что
> php, оказывается, можно сравнивать с python. Бред полнейший, я на php
> писал, когда они ещё под стол ходили.PHP нельзя сравнивать с Python - последний по сравнению с PHP достаточно куцый. С какой версии конкретно начинал?
> ещё не привёл примера, чтобы человек, много лет знающий и php
> и python, говорил бы, что ему больше нравится phpНу я универсал, допустим. Сам себе аналитик+алгоритмист+кодер. Много лет знаю PHP, C, Pascal (Delphi), ASM ARM (Thumb), ASM x86. Начинал с ASM Z80. Писал и на жабах с шарпами и одинэсами. О всяких жабоскриптах, шелах, SQL'ях и прочих мелочах подробно не буду. В целом могу писать на чём угодно, лишь бы было вменяемо по реализации.
На питон взглянул два раза, прослезился с индентационного flow control и переноса условий в конец выражения, выкинул - уровень невменяемости такого решения даже обсуждать смысла нет. С перлом в своё время было примерно то же самое (только из-за зубодробительного синтаксиса) - и меня так же пытались отдельные упёртые личности убеждать, что перл - это сила. Ну и где он сейчас?
>> Меня бесят все эти люди, которые ходят за мной и рассказывают, что
>> php, оказывается, можно сравнивать с python. Бред полнейший, я на php
>> писал, когда они ещё под стол ходили.
> PHP нельзя сравнивать с Python - последний по сравнению с PHP достаточно куцый.И это говорят про язык, ченчлог каждой версии которого вызывает кучу вопросов "И ЭТОГО ТОЖЕ НЕ БЫЛО"? И пользователи которого запись $a = [] В 20XX ГОДУ воспринимают, как откровение!
Где на python используется 1 строка в несколько символов, в php делается много. Да и начинается проект php с горожения воркэраундов. Которые следующий разработчик не поймёт, и сделает всё по-своему.
"как язычники, ибо они думают, что в многословии своем будут услышаны"
Можно, конечно, заниматься кучей скучной рутины, чтобы на примитивном php что-то написать, но лучше писать меньше, понятнее, без крайних случаев и без php.
> Где на python используется 1 строка в несколько символов, в php делается
> много.Пытаться впихнуть всё и вся в одну строку - очень плохой тон. Отчасти то, что перл ныне RIP - обусловлено тем же подходом. Код становится нечитабельным. Объем сокращать нужно, но не в ущерб читабельности за счёт усложнения конструкций. Принцип KISS действует и на языки.
> Где на python используется 1 строка в несколько символов, в php делается
> много.голубчик, в руби это реализовано намного красивей.
> Меня бесят все эти люди, которые ходят за мной и рассказывают, что
> php, оказывается, можно сравнивать с python.можно, можно. два примерно одинаковых по идиотизму языка. идиотизм, конечно, немного разный, но градус у обоих на уровне.
а бесишься ты от того, что сам знаешь: гвидобейсик и пых — братья навек. что на втором пишет крап огромное количество дятлов, что на первом.
> Дело было в вебе. Для веба python ахренительно хорош.такое же говно, как и любой язык, где нет first class continuations.
>> Дело было в вебе. Для веба python ахренительно хорош.
> такое же говно, как и любой язык, где нет first class continuations.юзкейс, где это РЕАЛЬНО ПРИМЕНИМО, можно?
я могу максимально возможно эмулировать такое поведение, но не могу понять, где бы это реально дало смысл?
веб - это выборка. по запросу сделать выборку, учитывая внешние и внутренние влияния. почти всегда - это всё. какой смысл в "состоянии", если МИР ИЗМЕНИЛСЯ?
>>> Дело было в вебе. Для веба python ахренительно хорош.
>> такое же говно, как и любой язык, где нет first class continuations.
> юзкейс, где это РЕАЛЬНО ПРИМЕНИМО, можно?в любой обработке любой формы. собственно, везде, где есть необходимость что-то у юзера спросить. мне лично намного удобней не размазывать вопрос и ответ, а просто писать обычную функцию, которая выводит форму, вызывает какой-нибудь wait-for-answer и продолжает работу, не теряя состояния локальных переменных и прочих ништяков. и я ожидаю, что мне для этого не надо будет извращаться, что язык это поддерживает без костылей.
> в любой обработке любой формы. собственно, везде, где есть необходимость что-то у
> юзера спросить. мне лично намного удобней не размазывать вопрос и ответ,
> а просто писать обычную функцию, которая выводит форму, вызывает какой-нибудь wait-for-answer
> и продолжает работу, не теряя состояния локальных переменных и прочих ништяков.Да, было бы удобно. Если бы не одно "но"...
В вебе нет никаких гарантий для "wait-for-answer". Ответа может не быть вообще. Или быть, но не туда и с другими данными. Или просто через пару часов. Потому что на удаленной стороне - человек, а не машина с гарантированным паттерном поведения. И держать запущенным процесс страницы со сложной логикой для каждого пользователя бог знает сколько времени - накладно.
> Да, было бы удобно. Если бы не одно «но»…
> В вебе нет никаких гарантий для «wait-for-answer». Ответа может не быть вообще.ну и фиг с ним. значит, continuation некоторое время полежит в сейфе, а потом его выкинут по истечению тайм-аута на сессию (или wait-for-answer вернёт какое-нибудь false, и функция отработает вариант «ниасилили»). с точки зрения функции это совершенно неважно.
> Или быть, но не туда и с другими данными.
не может. именно вот ситуации «что, куда и зачем» — разруливает фрэймворк. как именно — опять же неважно для функции, она ни о каких «сессиях» не знает и знать не хочет вообще.
>> Да, было бы удобно. Если бы не одно «но»…
>> В вебе нет никаких гарантий для «wait-for-answer». Ответа может не быть вообще.
> ну и фиг с ним. значит, continuation некоторое время полежит в сейфе,
> а потом его выкинут по истечению тайм-аута на сессию (или wait-for-answer
> вернёт какое-нибудь false, и функция отработает вариант «ниасилили»). с точки
> зрения функции это совершенно неважно.
>> Или быть, но не туда и с другими данными.
> не может. именно вот ситуации «что, куда и зачем» — разруливает фрэймворк.
> как именно — опять же неважно для функции, она ни о
> каких «сессиях» не знает и знать не хочет вообще.Вы объясните, эта штука может восстанавливать историю? То есть, там есть каждый шаг, который пройден, до которого можно откатиться? Или просто состояние в определённый момент времени?
не буду я ничего объяснять, это бессмысленно. про «эту штуку» можно в интернетах почитать. там же и узнать, сколько всего интересного с «этой штукой» можно наворотить, и не только для вебни.
> не буду я ничего объяснять, это бессмысленно. про «эту штуку» можно в
> интернетах почитать. там же и узнать, сколько всего интересного с «этой
> штукой» можно наворотить, и не только для вебни.Мы про эту штуку смотрели, в двух-трёх интернетах и одном интернате. Не особо поняли. Какой-то принципальной выгоды между спусканием контекстного локала сверху-вниз, хранения сериализованных данных в url или в глобале так и не поняли.
Поэтому считаем, что python для веба удобен и прост. Твитеры в сто строк только так пишутся. :)
> Твитеры в сто строк только так пишутся. :)вот это и есть «потолок» простоты гвидобейсика. когда задачи посложнее и строк побольше — начинается мегакостыляние. потому что невпихуемое, конечно, пихается в любую дырку, но с трудом.
>> Твитеры в сто строк только так пишутся. :)
> вот это и есть «потолок» простоты гвидобейсика. когда задачи посложнее и строк
> побольше — начинается мегакостыляние. потому что невпихуемое, конечно, пихается в любую дырку, но с трудом.А в чём проблема делать нормальную модульность? Нормальный обмен данными? Функции пофиг, что в неё пихают.
У меня есть проекты и посложнее, и намного посложнее. Эти примеры - прежде всего, учебные. Показывающие достоинства python и предоставляющие скелет.
> Эти примеры - прежде всего, учебные.'nuff said.
проблемы начинаются, когда с этой фигнёй надо взлетать.
> Поэтому считаем, что python для веба удобен и прост. Твитеры в сто
> строк только так пишутся. :)Проблема в том, что твитеры в сто строк никому не интересны. А за пределами оных начинаются грабли. Именно поэтому и имеем падающие 0.2% охвата.
>> Поэтому считаем, что python для веба удобен и прост. Твитеры в сто
>> строк только так пишутся. :)
> Проблема в том, что твитеры в сто строк никому не интересны. А
> за пределами оных начинаются грабли. Именно поэтому и имеем падающие 0.2% охвата.youtube не нравится, потому что слишком большой.
твитеры не нравятся, потому что слишком маленькие.
что там у кого падает - это его личное дело. а грабли - даже представить сложно. особенно, учитывая прекрасную неймспейсную модульность python и возможность легко писать компилируемые модули (в пыхе они прямо в пространство пыха вбиваются). наоборот, независимая разработка становится проще. а благодаря единой философии, код у всех примерно похож, и поддерживать его проще, чем на пыхе (пример - pypi).А пыхеры именно тем и занимаются, что переписывают, переделывают. Пыхеры требуются в больших количествах именно потому, что нужно поддерживать. А проекты на python требуют меньше внимания и заботы, потому что средний python-проект спроектирован гораздо лучше и нянек не требует. Потому что Дао.
> А пыхеры именно тем и занимаются, что переписывают, переделывают. Пыхеры требуются в
> больших количествах именно потому, что нужно поддерживать. А проекты на python
> требуют меньше внимания и заботы, потому что средний python-проект спроектирован гораздо
> лучше и нянек не требует. Потому что Дао.поэтому пока питонисты медитируют (денег-то на еду нет, проект работает), пыхеры едят хлеб с колбасой.
> поэтому пока питонисты медитируют (денег-то на еду нет, проект работает), пыхеры едят хлеб с колбасой.А нехер было в программисты идти. Но по факту получается наоборот - пыхеры работают, а проект нихрена не работает. А если разогнать программистов, и взять python, то проект работает. :) Для меня главное - чтобы проект работал, а не чтобы программы программировать. :) Я бы предпочёл ни строчки кода не писать, но, увы, с программистами работать - по волчьи выть.
а мне вообще на твой проект плевать, мне надо, чтобы колбаса регулярно поступала. вот так.
> А если разогнать программистов, и взять python, то проектвряд ли будет существовать вообще в разумные сроки, потому что теоретики такие теоретики.
>> А если разогнать программистов, и взять python, то проект
> вряд ли будет существовать вообще в разумные сроки, потому что теоретики такие теоретики.сроки стали раз в 10 меньше :)
> сроки стали раз в 10 меньше :)Все проблемы начинаются обычно не на самом взлете, а в первые дни после оного, на этапе отладки/стресс-тестирования. И вот тут теоретики сольют, потому что реальные жизненные условия порушат все стройные описания, а адаптироваться они не умеют :) Видел в своей жизни очень много вещей, красиво работающих в концепте, и никак - в реальности.
>> сроки стали раз в 10 меньше :)
> Все проблемы начинаются обычно не на самом взлете, а в первые дни
> после оного, на этапе отладки/стресс-тестирования. И вот тут теоретики сольют, потому
> что реальные жизненные условия порушат все стройные описания, а адаптироваться они
> не умеют :) Видел в своей жизни очень много вещей, красиво работающих в концепте, и никак - в реальности.А я видел много пыхеров. И вот это - про них. А заявленная вещь работает именно как надо. Потому что просто. А пыхеры "ниасилили".
ps. Смешно, что пыхер меня уверяет в том, что У МЕНЯ не работает.
Вся суть в том, что пыхеры используют php, потому что не знают или не понимают python, а python-щики используют python, потому что ОЧЕНЬ ХОРОШО ЗНАЮТ php (и пыхеров). То же самое, кстати, с виндой и linux/bsd, там тоже все уверены, что мне уже 8 лет в linux НЕУДОБНО и ВСЁ ПЛОХО. А то, что я решил 95% хронических проблем, и это реальное чудо, сэкономившее мешок времени - они просто не понимают.
Мы с тобой ниже беседуем про инкапсуляцию данных сессии в URL/cookie. Так вот: повторюсь - это всё красиво только в теории. Сферической и в вакууме, с неограниченным ресурсом и возможностями.А в реальности твой запрос с хистори обрежется где-то на 4-16K на большинстве веб-серверов. Ну или тебе засрут память твоего сервера запросами по несколько мегабайт хедеров в случае DoS.
Насчет Linux/BSD - тут скорее как раз PHP/Python. Вторые в парах одинаково уверены, что у них всё идеально, и вообще по феншую. Несмотря на 0.2% охвата и продолжающееся вымирание.
> Мы с тобой ниже беседуем про инкапсуляцию данных сессии в URL/cookie. Так
> вот: повторюсь - это всё красиво только в теории. Сферической и
> в вакууме, с неограниченным ресурсом и возможностями.
> А в реальности твой запрос с хистори обрежется где-то на 4-16K на
> большинстве веб-серверов. Ну или тебе засрут память твоего сервера запросами по
> несколько мегабайт хедеров в случае DoS.Поэтому планирование должно быть вперёд реализации. И не должно быть запросов по 4к, ибо это ненормально. А если должно - то должно обрабатываться, и сразу выбираться другие средства.
За досы, большие запросы и прочую ересь (как и за кеширование) будет отвечать nginx. А сервер в bottle.py по умолчанию однопоточный :), но при связке с nginx это не является проблемой, потому что все блокирующие запросы висят на фронтенде, и работа с ними - это уже искусство программирование nginx, и лучше оставаться теоретиком и не допускать крайних случаев в коде, чем завесить весь код крайними случаями, вместо того, чтобы отлавливать их на сервере или в middleware.
"Практики", которые решают задачи в лоб, как раз и превращают код в непрактичную кашу, которую никто не поддерживает, а следующий пыхер просто приходит, выкидывает, и заменяет своей (в одной достаточно крупной компании, которую я краем уха наблюдаю последние лет 5, такое произошло уже ни один раз).
Поддержка не менее важная вещь, чем функциональность. Ибо какой толк от функциональности, которую проще выкинуть, чем адаптировать под свои нужды?
> Поэтому планирование должно быть вперёд реализации. И не должно быть запросов по
> 4к, ибо это ненормально.Так у тебя они будут - ты же собрался всю историю в запросе держать.
Вот о том и речь - что лучше СРАЗУ выбрать другие средства. Инженерно оправданные.
А не писать "концептуальную" вещь, которую через месяц надо будет выкинуть, ибо заложенные красивые концепты оказались полностью несовместимы с реальностью.
> За досы, большие запросы и прочую ересь (как и за кеширование) будет
> отвечать nginx.Который как раз и обрежет тебе запрос теми самыми 4-16К. А если не обрежет - один фиг, nginx, не nginx, память всё равно не резиновая.
>> Поэтому планирование должно быть вперёд реализации. И не должно быть запросов по
>> 4к, ибо это ненормально.
> Так у тебя они будут - ты же собрался всю историю в
> запросе держать.Какую историю? Всё состояние. Обычный dict. Для корзинки магазина это список товаров (как минимум, для копирования). Если строка будет большой, значит, нельзя будет скопировать. Обидно. Но я в пыхерских проектах видел столько "нельзя" на ровном месте, что по сравнению с этим желание перекопировать весь магазин - это мелочи.
Но на текущий момент я не вижу причин отказываться от простого решения из-за заведомо неправильного действия.
> Вот о том и речь - что лучше СРАЗУ выбрать другие средства. Инженерно оправданные.Не знаю, как в ваших системах, а когда навешиваешь на before_hook контекстный локал, ему без разницы, откуда брать данные, и поэтому изменение источника получения - это одна строчка, которая сразу же скажется на всей программе. Нахрена выбирать заведомо более тяжёлое средство, особенно на этапе разработки, усложняя себе жизнь, когда это вообще не проблема? Планирование обычно помогает избегать проблем, а когда в лоб решаешь, всё усложняя и усложняя, потому что "а какие могут быть крайние случаи? сколько нужно резерву?" - привет, проблемы. Причём, усложнение - это и путь реальных ошибок, которые могут что-то серьёзное сотворить. А не запланированных ограничений, которые предсказуемы и могут быть оформлены в правила.
> А не писать "концептуальную" вещь, которую через месяц надо будет выкинуть, ибо
> заложенные красивые концепты оказались полностью несовместимы с реальностью.Пока это пыхеры свои мега-убер проекты всё время с нуля переписывают.
> Который как раз и обрежет тебе запрос теми самыми 4-16К.Пусть режет. Если это запланированное поведение.
> Всё состояние. Если строка будет большой, значитЕё обрежет Web-сервер. На входе.
>> Всё состояние. Если строка будет большой, значит
> Её обрежет Web-сервер. На входе.или браузер. на выходе.
> или браузер. на выходе.Вариант :)
>> или браузер. на выходе.
> Вариант :)Как браузер на выходе может обрезать url, который написан в ссылке на сайте "поделиться корзинкой"?
>> Всё состояние. Если строка будет большой, значит
> Её обрежет Web-сервер. На входе.Пусть режет. Но "нельзя будет скопировать" имеется ввиду, что ограничитель сработает, и плашку выведет. Это всё не имеет большого значения. Точно так же можно вбить в сообщение форума 32 гб, а потом плакать, почему иконки на форуме покосились.
> Поэтому планирование должно быть вперёд реализации. И не должно быть запросов по
> 4к, ибо это ненормально. А если должно — то должно обрабатываться,
> и сразу выбираться другие средства.итого: ты пишешь две реализации одного и того же вместо одной. передовой подход, да.
> итого: ты пишешь две реализации одного и того же вместо одной. передовой подход, да.нет. если я хочу использовать сериализацию в url, я знаю, зачем. если не хочу - то я знаю, почему.
реализация - это просто исполнение плана, по факту обнаружения проблем план обновляется, пока запланированное и сделанное не сойдутся в одном. нужно просто разбираться, что можно использовать, что нельзя. и да, если идея будет перспективной, но окажется неприменимой для жизни, лучше сделать две реализации. чем одну "потому что так заведено".
Для хорошей идеи и 38 реализаций не жалко, лишь бы исполняло задуманное и не создавало проблем юзеру. Это вообще не вопрос - цель произведения это создание целостного произведения, законченного. А не забор покрасить от оврага до обеда.
более того. при наличии first class continuations таких «обработчиков» у меня может быть вообще куча, каждый из них заведует своей частью страницы. и мне не надо размазывать эту логику, сохранять состояния между запросом и ответом и ты пы. поверь, таким образом строить какую-нибудь веб-апликуху намного удобней. и в итоге это получается сильно проще в поддержке и доработке/переработке.
> более того. при наличии first class continuations таких «обработчиков» у меня
> может быть вообще куча, каждый из них заведует своей частью страницы.
> и мне не надо размазывать эту логику, сохранять состояния между запросом
> и ответом и ты пы. поверь, таким образом строить какую-нибудь веб-апликуху
> намного удобней. и в итоге это получается сильно проще в поддержке
> и доработке/переработке.Может быть. Когда я такие вещи читаю, чувствую себя пыхером, смотрящим на python, и не понимающим, как эта шайтан-машина вообще летает.
Только я не особо понимаю, зачем мне может понадобиться сохранять состояние? Можно с примером?
Вот, например, у меня простейший модель магазина, который никому ничего нигде не сохраняет, а корзинку сериализует в сам url (можно и текущую страницу там же сериализовать), и юзер ходит, и может всегда восстановить любой ход, не зависящий от внешних данных (например, вот так вот сделано тут: http://nz.51t.ru/game1-new где вообще система ничего не сохраняет и нет никаких "состояний" на выдачу данных - всё "состояние" полностью сериализуется в url).
Но, при такой модели, если юзер кинет ссылку другому юзеру, у того отобразится чужая корзинка или что-то подобное. Для большей социальности и удобства юзера ссылка должна быть вида шоп.хрю/2 , чтобы легко было твитернуть, послать по sms, голубиной почтой, а главное - запомнить и вернуться. Чем мне тут может помочь это "повторение"?
> Вот, например, у меня простейший модель магазина, который никому ничего нигде не
> сохраняет, а корзинку сериализует в сам urlС ходу замечание по сути: а если юзер ходит с двух браузеров (или открытых страниц) сразу, а корзина должна быть одна?
Самый простой пример: я в ебее могу сразу 10-15 товаров открыть, но в корзину добавлю только 3-4 из них.
И второе: если в корзине пара тысяч разных единиц? URL такой длины может уже и не влезть.
>> Вот, например, у меня простейший модель магазина, который никому ничего нигде не
>> сохраняет, а корзинку сериализует в сам url
> С ходу замечание по сути: а если юзер ходит с двух браузеров
> (или открытых страниц) сразу, а корзина должна быть одна?Да там больше замечаний, на самом деле. :)
> Самый простой пример: я в ебее могу сразу 10-15 товаров открыть, но
> в корзину добавлю только 3-4 из них.
> И второе: если в корзине пара тысяч разных единиц? URL такой длины
> может уже и не влезть.Выдавать при запуске ID, а { хэш: [товар,товар,товар], таймлимит: xxx } хранить уже в памяти, и регулярно чистить. Но это уже не так чисто и не так красиво, как в url :) Проще повесить плашку "не выпендривайся, олигарх. итить"
А вариант с двумя браузерами, кроме авторизации, даже в голову не приходит. Можно узнать, как двум браузерам получить одну корзинку?
> А вариант с двумя браузерами, кроме авторизации, даже в голову не приходит.
> Можно узнать, как двум браузерам получить одну корзинку?Сессии, ID юзера + транзакционность :)
>> А вариант с двумя браузерами, кроме авторизации, даже в голову не приходит.
>> Можно узнать, как двум браузерам получить одну корзинку?
> Сессии, ID юзера + транзакционность :)Как получить сессию из одного браузера в другой?
> Как получить сессию из одного браузера в другой?Варианта реализации на самом деле два (больше, но остальные менее интересны):
1) разные ID сессий, один ID юзера внутри - наиболее распространенный вариант
Фактически при этом в сессии из неволатильных данных хранится как правило только ID юзера, так что можно считать эти сессии одной сущностью.
2) привязка одного и того же ID сессии к ID юзера в пределах сеанса авторизации - иногда встречается, менее безопасно, вызывает грабли при закрытии сессии в одном из браузеров
>> Как получить сессию из одного браузера в другой?
> Варианта реализации на самом деле два (больше, но остальные менее интересны):Я так и не понял одного - если зайти с двух браузеров, без авторизации, на главную страницу, то как понять, что это один юзер?
Если сериализовать всё состояние в url, то по url-у всегда можно сохранить и восстановить состояние, перекидывая ссылку туда-сюда.
"функция, которая ничего не знает о состояниях", достигается контекст-локалом (а для шаблона я просто спускаю дикт с этим локалом в шаблон). На каждый запрос создаётся свой конктекст-локал (в бутылке он даже из бутылки идёт, создавать не надо, там вообще несколько их идёт, request и прочие), который корми, чем хошь.
История, которую не нужно хранить, достигается только "хранением" её на клиенте, в url - один url = одно состояние, идентичный url = идентичное состояние. Всё остальное для меня - одни загадки.
> Я так и не понял одного - если зайти с двух браузеров,
> без авторизации, на главную страницу, то как понять, что это один
> юзер?Без авторизации - проблематично.
> Если сериализовать всё состояние в url, то по url-у всегда можно сохранить
> и восстановить состояние, перекидывая ссылку туда-сюда.Но вот имея ссылку в двух окнах - мы получим раздельный контекст для каждого из них. Для случая без авторизации это нормально (хотя - в случае одного браузера и это плохо). Для случая с авторизацией - полный швах, ибо юзер хочеть видеть актуальную корзинку и там, и там.
Таким образом мы так и приходим к тому, что на стороне юзера надо хранить только волатильные вещи, которые не жалко потерять между браузерами и т.д. А вот неволатильные - ID юзера, корзинку, etc. - надо хранить на сервере. И привязывать по возможности к ID юзера, а не к конкретному session ID.
ты сам всё и описал: отличный пример костыляния. с ходу, не думая: я делаю функцию «обработать-покупки», которая где-то там у себя вызывает функцию «дать-список-покупок». откуда этот список берётся — функции пофигу совершенно. хоть из файла, хоть из веб-сессии, хоть вообще из астрала. всё, что ей надо уметь — это обработать ситуацию «список ниасилили», что прекрасно укладывается хоть в проверку результата вызова, хоть в исключение.в свою очередь, «дать-список-покупок» тупо печатает какую-нибудь табличку и вызывает «ожидать-списка-от-юзера» или что-то типа того. и так далее.
видишь ли, в итоге программа получается обычной линейной, про логику «сессий» и прочую ерунду я вообще не думаю. я пишу «обычный код», так, как будто юзер сидит за терминалом и честно отвечает на заданые вопросы. вся хитрая вебовая механика меня вообще не волнует. если мне захочется — я вообще вебовую механику выкину и привинчу чтение из файла или гуй на каком-нибудь тулките: программа от этого никак не поменяется. то есть, *вообще* не поменяется. лично я считаю, что это удобно. например, для автотестов и fuzz-тестирования. никаких «отладочных заглушек», никакого спецкода для тестов *внутри программы*. лепота, красота, малиновый звон.
> в свою очередь, «дать-список-покупок» тупо печатает какую-нибудь табличку
> и вызывает «ожидать-списка-от-юзера» или что-то типа того. и так далее.А если у тебя вместо "ожидать-списка-от-юзера" (внезапно) снова пришло "дать-список-покупок"? F5 нажали :)
Или результат "ожидать-списка-от-юзера" пришел вместо "дать-список-покупок" без вызова первого (снова внезапно).
Механика Web как раз и хитра тем, что мы не можем 100% закладываться на строго определенную последовательность запросов. Соблюдать последовательность там, где это строго необходимо - да, можем. С оговорками. Поэтому механизм "оффлайновых" сессий и прижился так хорошо. Другие не влезают.
> А если у тебя вместо «ожидать-списка-от-юзера» (внезапно) снова пришло «дать-список-покупок»?
> F5 нажали :)да на здоровье. я ж сказал, это no-brainer. возвратить результат типа «перерисуй список (возможно, с некоторыми изменениями)». обычный цикл до пока не получим нужный ответ или отлуп. а если изменений не было, то и вообще фрэймворк может всё закэшировать, нафига каждый раз заставлять функцию рисовать одно и то же? причём кэшировать можно не целые страницы, а поблочно.
> Или результат «ожидать-списка-от-юзера» пришел вместо «дать-список-покупок» без вызова
> первого (снова внезапно).это как это? O_O
> Механика Web как раз и хитра тем, что мы не можем 100%
> закладываться на строго определенную последовательность запросов.и именно поэтому не закладываемся. наоборот, всем пофигу, в каком оно там порядке фигачит. на то у нас есть continuations и фрэймворк, который разрулит порядок вызовов
> да на здоровье. я ж сказал, это no-brainerЭто не no-brainer. Это нормальное поведение. Юзер может в соседней странице (и фиг ты определишь, что это другая сессия) спокойно уйти, посмотреть пару товаров, еще раз открыть тот же список (или не открыть), и спокойно далее кликнуть на него уже в первом окне (которое благополучно проспало свой шанс). Если такое поведение отстреливать - юзер просто сбежит.
>> Или результат «ожидать-списка-от-юзера» пришел вместо «дать-список-покупок» без вызова
>> первого (снова внезапно).
> это как это? O_OЛегко. См. пример выше. Пока юзер ходил по страницам, логика "забыла", что он запрашивал вывод списка. Или второй вариант - юзер оставил страничку со списком, процесс на сервере благополучно терминировался по таймауту через 10-15 минут (час, два), а юзер кликнул на кнопочку в открытой странице. Отстреливать? Опять же - сбежит.
Пример для всего вышеперечисленного банальный - любой инет-магазин.
> Легко. См. пример выше. Пока юзер ходил по страницам, логика "забыла", что
> он запрашивал вывод списка. Или второй вариант - юзер оставил страничку
> со списком, процесс на сервере благополучно терминировался по таймауту через 10-15
> минут (час, два), а юзер кликнул на кнопочку в открытой странице.
> Отстреливать?Не должно быть такого.
url, (за исключением секретных данных), должен однозначно инициализировать предмет. url должен быть такой вещью, которую можно копировать и вставить, сохранить в закладку, записать на бумажке.
И, по идее, когда заходишь в корзинку, лучше сериализовать всю корзинку в url (или давать ссылку на такую корзинку), именно для того, чтобы было легко передавать состояние корзинки с помощью обычной закладки.
> И, по идее, когда заходишь в корзинку, лучше сериализовать всю корзинку в
> url (или давать ссылку на такую корзинку), именно для того, чтобы
> было легко передавать состояние корзинки с помощью обычной закладки.Шпасибо. Я хочу корзинку, при которой я могу открыть сразу 10-15 окон с товарами, поглядеть, сравнить, и добавить любые 3-4 из них. Без сериализации похода по товарам.
Сгенерить же специальные URL для передачи корзинки - задача на самом деле микронная.
>> И, по идее, когда заходишь в корзинку, лучше сериализовать всю корзинку в
>> url (или давать ссылку на такую корзинку), именно для того, чтобы
>> было легко передавать состояние корзинки с помощью обычной закладки.
> Шпасибо. Я хочу корзинку, при которой я могу открыть сразу 10-15 окон
> с товарами, поглядеть, сравнить, и добавить любые 3-4 из них. Без
> сериализации похода по товарам.Сериализация не похода по товарам. url-ы у товаров обычные /2, /234, /244
Просто хранится list со списком (или со списком dict-ов, если нужно хранить что-то особое), чья сериализация (или ссылка на текущее состояние) хранятся в cookie. Добавляй, удаляй сколько хошь. Лучше, видимо, ссылку хранить, просто хранить список в памяти, а в cookie хранить его номер (можно и время жизни сессии, для убиения ненужных).
А в самой корзинке - хранить url. Когда мы заходим на товар - мы видим товар. И когда мы заходим по url корзинки - мы получаем идентичную корзинку, кто бы мы не были и откуда бы мы эту ссылку не взяли. Можно ею заменять текущую, а можно просто просматривать с возможностью замены по требованию или перекидки товаров туда-сюда.
А уж если позволять только авторизованным дёргать корзинку - это вообще не вопрос.
> Просто хранится list со списком (или со списком dict-ов, если нужно хранить
> что-то особое), чья сериализация (или ссылка на текущее состояние) хранятся в
> cookie.Так в URL или в cookie? Cookie - та же сессия, только с другого боку. Ну и да - не все данные желательно в сookie хранить. Есть данные, которые пользователю знать не обязательно.
И опять же - cookie не спасут от проблемы "а вот я дома вчера авторизовался, товары подобрал, а с работы сейчас свою корзину не вижу".
> Ну и да — не все данные желательно
> в сookie хранить. Есть данные, которые пользователю знать не обязательно.да ему вообще ничего знать не надо, кроме id сессии. меньше знаешь — крепче спишь. заодно и возможности что-то испортить значительно поменьше.
> да ему вообще ничего знать не надо, кроме id сессии. меньше знаешь
> — крепче спишь. заодно и возможности что-то испортить значительно поменьше.+100500
>> Ну и да — не все данные желательно
>> в сookie хранить. Есть данные, которые пользователю знать не обязательно.
> да ему вообще ничего знать не надо, кроме id сессии. меньше знаешь
> — крепче спишь. заодно и возможности что-то испортить значительно поменьше.Восстановление всей ситуации. URL однозначно идентифицирует всю историю. Если что-то сломали, забыли, убежали, а потом по history пробежались назад, то всё действительно вернётся "как было".
А хранить всю историю на сервере, а у юзера только id и "шаг" - жаба давит.
> Восстановление всей ситуации. URL однозначно идентифицирует всю историю. Если что-то сломалиСеанс/контекст на сервере однозначно идентифицирует всё состояние. И сломать его со стороны пользователя в принципе невозможно, если нет дыр.
А history в URL/Cookie - просто не влезет в запрос. Размер заголовка запроса _в реальности_ не так уж и неограничен :)
> А хранить всю историю на сервере, а у юзера только id и
> «шаг» — жаба давит.вот поэтому, например, тебя вообще нельзя допускать к разработке сколько-нибудь серьёзных больших проектов. не потому, что они совсем не будут работать, а потому, что они будут работать криво, нагружать каналы лишними данными и обламываться в самый неподходящий момент, потому что «голова в шапочку перестала помещаться».
>> А хранить всю историю на сервере, а у юзера только id и
>> «шаг» — жаба давит.
> вот поэтому, например, тебя вообще нельзя допускать к разработке сколько-нибудь серьёзных
> больших проектов. не потому, что они совсем не будут работать, а
> потому, что они будут работать криво, нагружать каналы лишними данными и
> обламываться в самый неподходящий момент, потому что «голова в шапочку перестала
> помещаться».Сейчас лучше, чем никогда.
Хотя никогда зачастую лучше, чем прямо сейчас.
Тот, кто думает, что техническая практичность важнее юзерской практичности, никогда не сделает ничего хорошего. Будет технически красивым, но юзерски бесполезным, юзеры будут плеваться от того, что не вписываются в идеальные случаи. Я - произвожу для юзеров, это прежде всего. На технологию есть программисты. Только толку от них, они всё равно не понимают, что надо людям, их интересует только то, что надо компьютерам.
Это лирика. А физика в том, что не вижу проблем с сериализацией там, где она уместна. А чтобы узнать, что она уместна, достаточно попробовать. А чтобы узнать, что она вызывает проблемы, достаточно встроенного профайлера. Абстрактные случаи могут доказать всё, что угодно, и спор "мало оптимизации" vs "много оптимизации" vs "просторы для расширения" - он бесполезен, важна практичность, а не оптимизация и просторы. Если решение практично - оно будет использоваться. Если вызывает проблемы - то не будет. Всё.
проблема в том, что у тебя нет ни технической практичности, ни юзерской. вот в чём беда-то.
> проблема в том, что у тебя нет ни технической практичности, ни юзерской. вот в чём беда-то.Мож и нет. Раньше я хиты делал, что каждая собака знала. а сейчас только 10 лет водку пил. пора слазить с печи, и восстанавливать практичность.
Хотя вроде есть, практичность, как и мастерство, не пропьёшь.
>> да на здоровье. я ж сказал, это no-brainer
> Это не no-brainer.я имел в виду свой пример. :3
>> это как это? O_O
> Легко. См. пример выше. Пока юзер ходил по страницам, логика «забыла», что
> он запрашивал вывод списка.как это «забыла»? это возможно только по истечению некоторого таймаута. что, в принципе говоря, совершенно логичное действие.
а новое окно — новый вызов функции, дел-то. это совсем недорого, а фрэймворк проследит, чтобы вызовами всё не засрали.
> Или второй вариант — юзер оставил страничку
> со списком, процесс на сервере благополучно терминировался по таймауту через 10–15
> минут (час, два), а юзер кликнул на кнопочку в открытой странице.
> Отстреливать? Опять же — сбежит.отстреливать. не сбежит. а если отстреливать не хочется — тут опять магия: фрэймворк может тупо сериализовать continuation в какое-нибудь хранилище, а потом оттуда достать. это опять ничем не отличается от делания того же самого руками — кроме того, что это делать руками совершенно не надо. сидишь себе и пишешь: «начало». «введите-два-числа()», «если-юзер-слепой-пойти-в-начало». «вывести-сумму()». а то, что ввод может прийти через 20 лет — софтине совершенно пофигу, её это никак не интересует. разве что можно поставить ловушку на ситуацию «ввод не придёт вообще никогда», чтобы что-нибудь за собой почистить.
помнишь, как писал первые программки такого типа? вот и не надо усложнять, можно так же и продолжать писать. без заморочек о том, что «это веб».
> как это «забыла»? это возможно только по истечению некоторого таймаута. что,
> в принципе говоря, совершенно логичное действие.В случае хранения сессии в виде данных - это нормально, потому что фреймворк восстановит весь контекст исполнения. В случае процесса на сервере - если он убился - всё, сессия потеряна. Держать же процессы с длинным таймаутом - ресурсов не хватит. Хранить весь контекст исполнения на сеанс, а не только конкретный небольшой блок юзерских данных - как-то накладно слегка.
У Web совершенно иная парадигма, нежели у консольных/гуевых аппликух. В Web понятия "вопрос-ответ" существуют только в пределах одного запроса. Когда запросы следуют друг за другом - вопросы и ответы на них могут чередоваться слегка произвольным образом.
> В случае хранения сессии в виде данных — это нормально, потому что
> фреймворк восстановит весь контекст исполнения.(вздыхает) continuation и есть такой контекст. в том-то и соль.
> У Web совершенно иная парадигма, нежели у консольных/гуевых аппликух.
да без разницы *в данном случае*. вообще.
> Когда запросы следуют друг за другом — вопросы и ответы на них могут
> чередоваться слегка произвольным образом.да по-фи-гу.
> (вздыхает) continuation и есть такой контекст. в том-то и соль.Не такой. Определить, что сохранять в этом контексте в каждом конкретном случае - невероятно сложно. Всё и сразу? Вот прямо-таки весь дамп области данных апликухи? Да, удобно. Но очень накладно, годится только для мелочевки. Лучше все-таки оставить контекст на откуп самому приложению.
> да без разницы *в данном случае*. вообще.
Огромная разница. В консольной аппликухе ты задал вопрос, и ждёшь на него ответа - и юзеру никуда не деться (кроме SIGKILL :) ). А в вебне он может спокойно сначала уйти на другую часть приложения, там что-то поделать, и только потом - ответить на твой вопрос.
>> (вздыхает) continuation и есть такой контекст. в том-то и соль.
> Не такой. Определить, что сохранять в этом контексте в каждом конкретном случае
> — невероятно сложно.очень просто. надо только отвыкнуть пихать везде глобальные переменные — и сразу становится просто.
> Всё и сразу? Вот прямо-таки весь дамп области данных апликухи?
зачем? O_O у нас есть замыкание, оно знает, что в нём сохранено. вот это и писать. простейшие объекты там умеет (де)сериализовать сам рантайм, юзерские объекты надо этому научить один раз.
> Лучше все-таки оставить контекст на откуп самому приложению.
оно так и есть. только не надо руками над этим плясать.
>> да без разницы *в данном случае*. вообще.
> Огромная разница. В консольной аппликухе ты задал вопрос, и ждёшь на него
> ответа — и юзеру никуда не деться (кроме SIGKILL :) ).
> А в вебне он может спокойно сначала уйти на другую часть
> приложения, там что-то поделать, и только потом — ответить на твой
> вопрос.(вздыхает). по-фи-гу. один запрос — одно действие — одна функция. страницу можно собрать из кучи функций, всем по-фи-гу. сверху у нас новостной блок — одна функция, в ней цикл вывода, пока не надоест (и вызов «чпок()», чтобы сообщить, что всё вывелось). снизу — рекламный: одна функция, в ней цикл вывода, пока не надоест. посередине корзинка: одна функция… ну, ты понял. из этих кубиков можно хоть одну страницу собрать, хоть сто страниц. в любом порядке. разных или одних и тех же. самим функциям — по-фи-гу. с их точки зрения — они выполняются линейно. единственное действие, которое им иногда надо повторять — «перерисоваться». и то нечасто, потому что фрэймворк в состоянии закэшировать всякую фигню.
> очень просто. надо только отвыкнуть пихать везде глобальные переменные — и сразу
> становится просто.Непросто. Контекст может включать в себя целую пачку объектов, а цепочка вызовов - быть достаточно длинной.
Но это не самое страшное. Самое страшное - это обеспечение конзистентности. К моменту получения от пользователя "ответа" ряд данных по цепочке вызовов вниз (да и просто) мог устареть, и эти данные всегда должны быть перезагружены из БД (например), а не из контекста. Или пересчитаны.
Модель "вопрос-ответ" с полным сохранением контекста никуда не годится в случае наличия хоть малейшей доли параллелизма.
>> Всё и сразу? Вот прямо-таки весь дамп области данных апликухи?
> зачем? O_O у нас есть замыкание, оно знает, что в нём сохранено.И никакой цепочки вызовов тоже не существует? Если нет - модель годится только для простейших аппликух, где нет никакой вложенности и/или зависимости контроллеров.
> Непросто. Контекст может включать в себя целую пачку объектов, а цепочка вызовов
> — быть достаточно длинной.и это не страшно. совсем. irl — совсем немного. одна функция — одно логическое действие, не забываем.
> Но это не самое страшное. Самое страшное — это обеспечение конзистентности. К
> моменту получения от пользователя «ответа» ряд данных по цепочке вызовов вниз
> (да и просто) мог устареть, и эти данные всегда должны быть
> перезагружены из БД (например), а не из контекста. Или пересчитаны.и это тоже не страшно. потому что о кэшировании данных мы не то, что не думаем — мы вообще забываем, что такое на свете существует. в нашем мире существует только объект со свойствами. и вот этот-то объект отлично знает, что и когда надо перечитывать. а мы просто обращаемся к его свойствам.
> Модель «вопрос-ответ» с полным сохранением контекста никуда не годится в случае наличия
> хоть малейшей доли параллелизма.вообще-то абсолютно все программы работают по модели «вопрос-ответ». вообще все. просто иногда это *настолько* неочевидно… и писать это неочевидно, и читать это неочевидно, и проектировать это неочевидно. а всё от того, что сохранять состояния-continuations кода-то было действительно дорого.
>>> Всё и сразу? Вот прямо-таки весь дамп области данных апликухи?
>> зачем? O_O у нас есть замыкание, оно знает, что в нём сохранено.
> И никакой цепочки вызовов тоже не существует? Если нет — модель годится
> только для простейших аппликух, где нет никакой вложенности и/или зависимости контроллеров.(вздыхает ещё раз) con-ti-nu-a-ti-on. наличие общей части с «continue» о чём-то говорит?
я тебе сейчас ещё более страшную штуку скажу: это самое continuation можно передать по сети другому исполнителю. и там продолжить (при условии, понятно, что на обоих одна и та же версия юзерского софта). load balancing? да пожалуйста. несколько серверов — да на здоровье. прозрачная миграция сессии пользователя с одного сервера на другой? да без проблем. а функции-обработчики об этом как не знали, так и не знают. им всё равно.
p.s. да, у меня есть такой фрэймворк. нет, я его не покажу: это «камерная» разработка, proof-of-concept. неоптимизированая и неотлаженая. нет, я не хочу выпускать это «в мир», мне неинтересно.
> и это тоже не страшно. потому что о кэшировании данных мы не
> то, что не думаем — мы вообще забываем, что такое на
> свете существует. в нашем мире существует только объект со свойствами. и
> вот этот-то объект отлично знает, что и когда надо перечитывать. а
> мы просто обращаемся к его свойствам.Вот так вот плавно мы и пришли к концепту фреймворка :) Всё равно всё в итоге превращается в банальный набор тех или иных костылей, позволяющих этот функционал реализовать.
> Вот так вот плавно мы и пришли к концепту фреймворка :) Всё
> равно всё в итоге превращается в банальный набор тех или иных
> костылей, позволяющих этот функционал реализовать.я, собственно, слово «фрэймворк» и употребил первый. и даже написал о том, что всё, мной описаное, можно сэмулировать с разной степенью костыльности. вся разница только в количестве костылей.
в моём случае — есть фрэймворк (который пишется один раз и потом используется где угодно) и поверх него язык, в котором прозрачно реализована поддержка continuations (вдобавок, они first-class citizens). это не серебряная пуля, но убирает кучу костылей. убирает настолько, что на этой фигне становится пофигу, для чего пишется софт: для веба, для терминала, для крутых гуёв…
софт можно «замораживать» и «размораживать», можно переносить замороженое тельце с машины на машину, можно на 100500 лет о софте вообще забыть, а потом снова его разморозить и доделать то, что делал. можно «заморозить» вебовый софт и «разморозить» его в гуях. а можно наоборот. а можно одновременно и в браузер показывать, и окошко гуёвое держать.
да, всё это возможно и с другими языками/фреймворками/платформами, я не спорю. но с моей это чуть менее костыльно, чуть менее трудоёмко, чуть менее надо заморачиваться тем, как работает хитрая механика внутри.
к счастью или сожалению — мне эта платформа совершенно бесполезна: я её делал просто для того, чтобы поиграться с концепциями. в общем-то, уже наигрался. допиливать, развивать и продвигать штучку у меня никакого желания нет. отдавать кому-либо или открывать тоже. алсо, как показывает данная дискуссия — люди не врубаются. а поясняю я очень хреново. поэтому люди и не врубятся.
>[оверквотинг удален]
> поддержка continuations (вдобавок, они first-class citizens). это не серебряная пуля,
> но убирает кучу костылей. убирает настолько, что на этой фигне становится
> пофигу, для чего пишется софт: для веба, для терминала, для крутых
> гуёв…
> софт можно «замораживать» и «размораживать», можно переносить замороженое
> тельце с машины на машину, можно на 100500 лет о софте
> вообще забыть, а потом снова его разморозить и доделать то, что
> делал. можно «заморозить» вебовый софт и «разморозить» его в гуях.
> а можно наоборот. а можно одновременно и в браузер показывать, и
> окошко гуёвое держать.и чо?
время на разработку - это раз
читаемость, поддерживаемость, групповоработовость и невыкидываемость кода - это два
где соль? концепция - это хорошо, это очень хорошо, но нет такой хорошей концепции, от которой нельзя было оставить ни камня с помощью не самой удачной реализации.
короче говоря - оно само уже может разрабатываться, или ждать нам другого?
> короче говоря — оно само уже может разрабатываться, или ждать нам другого?ждите. я же сказал, что мне оно неинтересно и бесполезно. а ещё менее интересно мне писать документации и туториалы. а сам народ не врубается, увы.
а соль в том, что потенциально код на этой штуке как раз лёгок в разработке и поддержке. но — мне оно не нужно.
> помнишь, как писал первые программки такого типа? вот и не надо усложнять,
> можно так же и продолжать писать. без заморочек о том, что «это веб».В програмках нельзя было залезть через спину с трёх сторон одновременно.
А в чём заморочка "это веб", я не пойму. Кроме того, что одни юзеры могут сидеть на url-е /a, а другие - на урле /b, и никогда не пересекатся.
Роутоориентированный интерфейс (а не как в php, эмуляция через хаки) - это самое лучшее, что может быть.
пошёл на url - получил действие. понятно и очевидно. зачем плодить неоднозначности? ладно в пыхе, где глобальный дикт - несбыточная мечта. но когда все данные под рукой по требованию, зачем?
> А в чём заморочка "это веб", я не пойму. Кроме того, что
> одни юзеры могут сидеть на url-е /a, а другие - на
> урле /b, и никогда не пересекатся.В том, что один и тот же юзер одновременно может сидеть на урлах /a, /b и /c. И нет строгого порядка, в котором он с них уйдёт на /d, /e и /f. И даже гарантий, что он с /a на /d уйдёт - нет. Может тупо уйти с /a на /b кнопкой "назад". Или вбить URL. Или F5 нажать.
а не может, не положено!
> а не может, не положено!Ну, увы, в реальности юзер хочет относительной свободы действий. Если скажете "не положено" - уйдёт к тем, у кого это всё допустимо. И делов.
>> а не может, не положено!
> Ну, увы, в реальности юзер хочет относительной свободы действий. Если скажете "не
> положено" - уйдёт к тем, у кого это всё допустимо. И
> делов.зато у питониста тогда сервер под нагрузкой не будет проседать. в виду отсутствия нагрузки.
>>> а не может, не положено!
>> Ну, увы, в реальности юзер хочет относительной свободы действий. Если скажете "не
>> положено" - уйдёт к тем, у кого это всё допустимо. И делов.
> зато у питониста тогда сервер под нагрузкой не будет проседать. в виду
> отсутствия нагрузки.Мы ещё раз пришли к тому, от чего ушли. Веб в подавляющем большинстве случаев это "получили нужную страничку, сделали выборку, отрисовали". Он не коддориентирован, он данно-ориентирован, там может быть вообще две функции фильтрации, а весь основной проект - это организация данных. Никаких "как в доме под одеялом на паскале" там быть не может. У юзера есть закладки, твитер и 50 вкладок. Юзер хочет простоты и свободы, и ему наплевать, как оно там работает.
может, может. в том-то и фикус спрятан. it's just you who can't wrap your mind around it.как я уже писал — *все* программы занимаются тем, что получают ввод, обрабатывают данные и выводят результат. вопрос только в том, насколько костыльно это делается.
> ты сам всё и описал: отличный пример костыляния. с ходу, не думая:
> я делаю функцию «обработать-покупки», которая где-то там у себя вызывает функцию
> «дать-список-покупок». откуда этот список берётся — функции пофигу совершенно.
> хоть из файла, хоть из веб-сессии, хоть вообще из астрала. всё,
> что ей надо уметь — это обработать ситуацию «список ниасилили», что
> прекрасно укладывается хоть в проверку результата вызова, хоть в исключение.Я не понимаю, что такое "список ниасилили"
У меня тоже список, который функции пофигу совершенно. Есть глобальный j = mydict(), есть функция dat_spisok_pokupok(l), но я могу её сделать и dat_spisok_pokupok(), и l передавать контекст-локалом - ничего вообще не изменится, она просто даёт dict из того, чем её кормят - нет никакой проблемы брать список из веб-сессии, я не понимаю, где загвоздка то? Я могу в mydict прописать вместо хранения - запись/чтение хоть в монго, хоть в астрал 2.0.3, никакой основной код не изменится.
Что касается (хоть в терминал) - я не знаю таких абстракций, всё, что меня волнует - это dict, который возвращает обработанный dict, и который я могу вывести хоть в json, хоть в шаблон для отрисовки, хоть в сессию, мой dict, что хочу, то и делаю.
И я думаю именно этими категориями. ПРИ ЭТОМ Я ЭТОТ DICT В ЛЮБОЙ МОМЕНТ МОГУ РУКАМИ ПОЩУПАТЬ. Я знаю, что у меня ходит, куда, и зачем. У меня предельно простая отладка - видно, что где потерялось. Функции гоняют dict, а шаблон рисует. Это очень просто и очень наглядно.
Я не вижу, что тут можно сделать лучше, сохранив понятность. Потому что из текста я мало что понял. :)
> видишь ли, в итоге программа получается обычной линейной, про логику «сессий»
> и прочую ерунду я вообще не думаю. я пишу «обычный код»,Что такое "логика сессий"? И что такое "обычный код"? И зачем об этом думать? auth отрабатывается один раз, при старте сессии, обрабатывает данные, сохраняет информацию об уровне доступа в тот же dict, который цепляется к контекст-локалу. Всё, когда функции нужно что-то отрисовать секретное, нужно в одном месте спросить "а какой уровень доступа у текущей сессии", и если не позволяется - не рисовать. Как работают сессии - это вообще дело десятое, я могу тупо импортировать модуль приложения, в консоли переопределять acl и дёргать те же самые функции, безо всякого веба, получая те же самые дикты.
> так, как будто юзер сидит за терминалом и честно отвечает на
> заданые вопросы. вся хитрая вебовая механика меня вообще не волнует. если
> мне захочется — я вообще вебовую механику выкину и привинчу чтение
> из файла или гуй на каком-нибудь тулките: программа от этого никак
> не поменяется. то есть, *вообще* не поменяется.А можно простейший пример?
> Я не понимаю, что такое «список ниасилили»перевожу: «истёк тайм-аут на сессию». или «иксы отвалились» в случае гуёв на X11, например.
> Есть глобальный
вот дальше читать уже неинтересно.
> Я не вижу, что тут можно сделать лучше, сохранив понятность. Потому что
> из текста я мало что понял. :)потому что вообще не въехал в концепцию.
> нужно в одном месте спросить «а какой уровень доступа у текущей сессии»
нахрена? что такое вообще эта ваша «сессия»? зачем мне об этом знать? не хочу. я хочу писать обычную линейную функцию, которой на вход параметром пришло «чо показывать», она *запросила у юзера ввод*, обработала и вышла. всё. какие такие сессии-шмессии? что это? зачем оно надо?
> А можно простейший пример?
куда проще-то?
function sum_two_numbers () {
int a, b;
for (;;) {
writeln("введите два числа");
if (readln(a, b) != USER_IS_BLIND) break;
}
writeln("the sum is ", a+b);
}всё. и вот это простейшее себе спокойно работает хоть для терминала, хоть для вебни с сотней окошек. без изменения кода.
оно простейшее, как ты просил — поэтому красивым выводом с удобным layout'ом я не заморачивался. синтаксис тоже отфонарный.
>> Есть глобальный
> вот дальше читать уже неинтересно.А в чём проблема? Если j это не коннектор к базе данных, а сама база данных? Кроме того, для того, чтобы это и была база данных, достаточно переписать класс mydict, не трогая ни строчки кода (все подобные вещи исполняются по требованию, а не по объявлению, им пофиг).
Люди придумывают мемкашеды и редисы, которые требуют огорода для коннекции и ограничены в данных, а тут ты можешь даром без доп.кода хранить данные (в контексте только отдельного модуля), хоть функции там храни. А из модуля его можно спускать по ссылке.
Проблем с синхронизацией тоже нет, насколько я понимаю. Неспециально влезть туда тоже нельзя. Кода требуется меньше. Суть трагедии?
> Суть трагедии?а вот это ты бы понял, если бы был программистом. каждый раз, когда ты используешь глобальную переменную, где-то страдает котёнок.
> а вот это ты бы понял, если бы был программистом. каждый раз,
> когда ты используешь глобальную переменную, где-то страдает котёнок.В чём принципиальная разница между той же глобальной переменной j, живущей в модуле ttt, и функцией f, возвращающей yield?
Вот мы сделали from ttt import j, f
что произошло в f, что спасло котёнка (именно принципиально?)
А также в чём разница между такой реализацией, и redis/memcache, которые получают ТЕ ЖЕ ДАННЫЕ, но нужно ещё делать коннекцию, разбор данных и т.п.?
p.s. я не спорю, что вышенаписаное можно *проэмулировать*. но это будет костыль.
> p.s. я не спорю, что вышенаписаное можно *проэмулировать*. но это будет костыль.Проблема в необходимости держать запущенным процесс на каждый сеанс. А если не держать - никакой разницы с обычным поднятием сессий во фреймворке как бы уже и нет. Просто костыль переносится в другое место.
> Проблема в необходимости держать запущенным процесс на каждый сеанс.или реализовать веб-сервер как часть фрэймворка. ну и да: тут ещё был бы полезен лёгкий и быстрый sandboxing.
> или реализовать веб-сервер как часть фрэймворка. ну и да: тут ещё был
> бы полезен лёгкий и быстрый sandboxing.Вполне. С другой стороны - это гвоздями приколотит язык/фреймворк к вебу, и использовать его для чего-то другого станет тяжко (вся эта обвязка будет висеть мертвым грузом).
А вот насчет сэндбоксинга - да. Интересно, как скоро появится плагин к апачам, запускающий каждый процесс в отдельном контейнере... Подвижки в эту сторону в виде mpm_itk (в который сие можно в принципе привернуть) уже есть.
>> или реализовать веб-сервер как часть фрэймворка. ну и да: тут ещё был
>> бы полезен лёгкий и быстрый sandboxing.
> Вполне. С другой стороны — это гвоздями приколотит язык/фреймворк к вебуда ни разу. в том-то и штука, что программы про этот фрэймворк знают мизер: фактически, вызовы типа «вывести сообщение, прочитать ответ от юзера». и если фрэймворк вдруг окажется не вебовым, а гуйнёй на тулките, например — программам совершенно пофигу. да хоть действительно на терминал плеваться и с терминала ответы читать.
>веб - это выборка. по запросу сделать выборку, учитывая внешние и внутренние влияния. почти всегда - это всё.вы в 90-х застряли.
>>веб - это выборка. по запросу сделать выборку, учитывая внешние и внутренние влияния. почти всегда - это всё.
> вы в 90-х застряли.А что ещё на php пишут? :)
ps. А куда такую высокоинтеллектуальную беседу дели? :)
> А что ещё на php пишут? :)Много чего пишут. У нас, например, анализатор аномалий объёма телефонного трафика на нём написан, прожевывающий миллионы записей в сутки.
В целом - пишут на том, на чем писать удобно и практично в энном конкретном случае.
> Много чего пишут. У нас, например, анализатор аномалий объёма телефонного трафика на
> нём написан, прожевывающий миллионы записей в сутки.НО ЗАЧЕМ?!
> НО ЗАЧЕМ?!Что значит ЗАЧЕМ? С помощью конкретного инструмента конкретную задачу поиска аномалий удалось решить очень просто и быстро. Прикинули время и сложность разработки на плюсах и PHP, и выбрали второе. Можно было как альтернативу взять жабу, но она в нашем случае эксплуатируется только под виндой.
В основном анализатор представляет из себя обработку текстовых и статистических данных + работу с БД, в PHP всё необходимое есть из коробки, и работает достаточно шустро. Конкретно для нашей задачи очень удобны нестрогая типизация и хеш-массивы.
собственно, у меня есть ничем не подкреплённое подозрение, что перл тут подошёл бы лучше.
> собственно, у меня есть ничем не подкреплённое подозрение, что перл тут подошёл
> бы лучше.Перл не подходит сразу в силу того, что этот код надо поддерживать несколько лет, и разным людям. Про читабельность перла я где-то тут уже писал.
читабельность перла, собственно, зависит от рук и мозга пишущего. и в перле сигилы таки имеют смысл, а от обилия долларовых знаков в похапэ лично у меня нервный тик.
кстати, никогда не мог запомнить:
$obj->field
или
$obj->$field
логическому выводу это не поддаётся, можно только зазубрить.
> кстати, никогда не мог запомнить:
> $obj->field
> или
> $obj->$field
> логическому выводу это не поддаётся, можно только зазубрить.Поддается.
$obj->field - это property field объекта obj. Как и во всех языках, не надо ничего придумывать.$obj->$field - это property объекта obj, определяемая переменной $field.
Если в $field положить 'xxx' - то будет эквивалентно $obj->xxx, если 'yyy' - то $obj->yyy. Тоже очень удобно, хотя и не очень производительно.
Можно например так же метод вызвать с не известным заранее именем, которое лежит в переменной.
не поддаётся. ибо конструкция '$var = value' тогда должна присваивать значение не переменной var, а переменной, имя которой хранится в var. вот эта фигня «на раз» сбивает логическую рассуждалку, и дальше на неё полагаться уже опасно.а всё потому, что авторы похапэ опять не поняли, что такое сигилы и реализовали это в меру своего непонимания.
в перле тоже не очень поняли, что обозначает оператор «$», но там хотя бы «$$» работает — то есть, хотя бы во взятии значения оператор «$» эмулируют логично.
> не поддаётся. ибо конструкция '$var = value' тогда должна присваивать значение не
> переменной var, а переменной, имя которой хранится в varНет. Такое присваивание, кстати, есть, и выглядит как $$var = value. Достаточно запомнить, что имена _переменных_ (не методов, не пропертей - именно переменных) всегда начинаются с $
> Достаточно запомнить, что имена _переменных_ (не методов, не пропертей — именно переменных)
> всегда начинаются с $а зачем? вот в sh с этим всё понятно: «$» там — оператор. а тут — авторы как-то не смогли понять, что это оператор, и сделали глупость.
p.s. я совершенно не понимаю, по какой марсианской логике имя поля должно отличаться от имени переменной наличием доллара.
> Можно сказать, что mediawiki мне полжизни искалечила и лишила крупной
> суммы денег только из-за того, что я в неё поверил. Но
> можно и не говорить.Ох, ёшкин код (sic!), а вот и источник детских комплексов вылез. Только, боюсь, это не MediaWiki, а руки...
> Ох, ёшкин код (sic!), а вот и источник детских комплексов вылез. Только, боюсь, это не MediaWiki, а руки...Нихрена ты, Вася, не понял.
Запомни, навсегда запомни. Чувство юмора - это умение смеяться над собой. Комплексы - это ваше поведение недотрог.
> Нихрена ты, Вася, не понял.
> Запомни, навсегда запомни. Чувство юмора - это умение смеяться над собой. Комплексы
> - это ваше поведение недотрог.Слив засчитан.
> Спросил, кто какие фишки из 5.3/5.4 использует, а в ответ - []; вместо array().Мне например от 5.3 нужны closures, от 5.4 - traits.
Кроме того - в языке настолько до фига всего, что от новых версий ждут в основном не изменений семантики, а улучшения производительности и расширения набора встроенных функций.
Опять же - goto в 5.3 - изменение спорное, но местами действительно удобное.
> Кроме того - в языке настолько до фига всегоВ языке настолько дофига всего нет, что его пытаются превратить в python со скобочками. Это моё, и не только моё, впечатление от ченчлога 5.3, 5.4 и особенно 5.5.
> Опять же - goto в 5.3 - изменение спорное, но местами действительно удобное.Через две версии опять объявят deprecated, потому что несколько дебилов порежутся.
Когда в python нет for, нет switch - пыхеры орут матом, а понимающие философию радуются такому единообразию и отсутствию РАЗНЫХ инструментов для ОДНОГО дела (меня в php умиляют функции array_, типа для массивов одна функция, для чего-нибудь ещё - другая, ЗАПОМНИ ИХ ВСЕ, будь пыхером). А goto, пыхерам... жалко дворняжек.
Ну... эээ... ты знаешь - радоваться отсутствию разных инструментов может только дебил. Потому что задача бывает одна (закрутить винт/болт), а калибр - разный (в корпус ПК или в стойку). Или закрутить полсотни болтов - тут уже лучше электроинструмент, чем обычная отвертка. Хотя задача всё та же - закручивание винтов/болтов. А где-то электроинструментом, да и отверткой, тупо не подлезть - и нужна гнущаяся отвертка.Или вторая задача: отрезать ветку. Для домашних цветов подойдут ножницы. А вот с дерева ветку ножницами отрезать уже может не получиться.
Ну, короче, чего дальше объяснять... забивать гвозди микроскопами - не лучшая затея.
p.s. и, кстати, вот это вот «**» — нифига не очевидная конструкция. фиг знает вообще, что она делает, и догадаться — никак. на что я и намекал весьма прозрачно. а если у человека есть опыт сей — он вообще от этой конструкции офигеет.
> p.s. и, кстати, вот это вот «**» — нифига не очевидная конструкция.
> фиг знает вообще, что она делает, и догадаться — никак.Чувак, я ни разу не читал про эту конструкцию ни в одном мануале. Я просто видел её использование, без объяснения, в том же мануале, и просто догадался, как оно работает. Оно работало именно так, как я и ожидал.
А перед использованием python мануал, хотя бы по диагонали, просмотреть следует.
> а если у человека есть опыт сей — он вообще от этой конструкции офигеет.
Я в детстве, когда нужно использовать *, когда **, когда & или что там, я уже забыл, собирал только перебором (в смысле - подставил один символ, скомпилировал-запустил-не-подошло-подставил другой). И только когда комбинаторика иссякала, просто сдавался. И даже не понимаю, как такие штуки можно в голове держать. Поэтому python для непрограммистов и им сочувствующих, а C для программистов и интересующихся тонкими материями, и пусть так дальше и остаётся. python д о с т а т о ч н о эффективен для своей ниши, а борцы за чистоту тактов и закат производительности вручную пусть борятся где-нибудь в другом месте - мы к ним не лезем, ядра на python не пишем.
> Чувак, я ни разу не читал про эту конструкцию ни в одном
> мануале. Я просто видел её использование, без объяснения, в том же
> мануале, и просто догадался, как оно работает. Оно работало именно так,
> как я и ожидал.а я ожидаю двойное разыменование указателя. а почему эта фигня заместо работы с указателями делает unpack, да ещё почему там нужны две звезды — для меня загадка.
> А перед использованием python мануал, хотя бы по диагонали, просмотреть следует.
я, к счастью, гвидобейсик не использую. а вот ты тут вещаешь, что гвидобейсик понятен даже без мануала.
> Я в детстве, когда нужно использовать *, когда **, когда & или
> что там, я уже забыл, собирал только перебороместь мнение, что это вовсе не от сложности и непонятности синтаксиса.
> Поэтому python для непрограммистов и им сочувствующих,
> а C для программистов и интересующихся тонкими материямиэти вот две звезды — это действительно можно только перебором угадать. потому что логики в них никакой. а в сях логика налицо, и спецсимволы не смотрятся там чужеродно. твоя двухзвёздочная конструкция же на фоне остального кода смотрится так же уместно, как грязный бомж посреди чистой комнаты.
>> Чувак, я ни разу не читал про эту конструкцию ни в одном
>> мануале. Я просто видел её использование, без объяснения, в том же
>> мануале, и просто догадался, как оно работает. Оно работало именно так,
>> как я и ожидал.
> а я ожидаю двойное разыменование указателя. а почему эта фигня заместо работы
> с указателями делает unpack, да ещё почему там нужны две звезды
> — для меня загадка.Потому что одна звезда для другого:
def keyz(raz,dva,tri):
print raz
print dva
print tria = ['one','two','three']
keyz (a)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: keyz() takes exactly 3 arguments (1 given)keyz (*a)
one
two
three
>> А перед использованием python мануал, хотя бы по диагонали, просмотреть следует.
> я, к счастью, гвидобейсик не использую. а вот ты тут вещаешь, что
> гвидобейсик понятен даже без мануала.для домохозяек. ** - это уже следующий шаг, ньюбик не будет использовать это. поэтому у меня, по-моему, в паблик-коде нигде не используется. когда ньюбик дорастёт, он уже узнает, что такое ** :)
>> Я в детстве, когда нужно использовать *, когда **, когда & или
>> что там, я уже забыл, собирал только перебором
> есть мнение, что это вовсе не от сложности и непонятности синтаксиса.разумеется. просто я от этого ничего не ожидал, просто понимал, что одна из этих фиговин должна подойти. это совсем другой уровень анализа. python-код проще в голове обрабатывать, потому что это набор простых блоков, и никакой из них не улетает в космос и не заставляет держать в памяти кучу объектов.
>> Поэтому python для непрограммистов и им сочувствующих,
>> а C для программистов и интересующихся тонкими материями
> эти вот две звезды — это действительно можно только перебором угадать. потому
> что логики в них никакой. а в сях логика налицо, и
> спецсимволы не смотрятся там чужеродно. твоя двухзвёздочная конструкция же на фоне
> остального кода смотрится так же уместно, как грязный бомж посреди чистой комнаты.две звезды - это двойное умножение :). одна звезда - это одинарное умножение. так же логично, как и
'a' * 20
'aaaaaaaaaaaaaaaaaaaa'вот когда знак умножения означает не умножение - вот это становится загадочным :)
> 'a' * 20
> 'aaaaaaaaaaaaaaaaaaaa'Именно. Ааааааааааааааааааааааааааааааааа!!! Уж лучше пыховый str_repeat - по крайней мере, найдя его, не придётся гадать, что получится при умножении строки на число.
>> 'a' * 20
>> 'aaaaaaaaaaaaaaaaaaaa'
> Именно. Ааааааааааааааааааааааааааааааааа!!! Уж лучше пыховый str_repeat - по крайней
> мере, найдя его, не придётся гадать, что получится при умножении строки на число.Это не умножение строки на число. Это помножение строки числом. :)
Это самое логчное, что ожидаешь увидеть, исходя из детсадовского курса арифметики. Если чего-то взять пять раз, то получится пять чеготов.
['a'] * 20
['a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a']ну в перле вроде x используется, есть принципиальная разница?
> Это не умножение строки на число. Это помножение строки числом. :)Ну так * - оператор умножения или "помножения"? :)
> Это самое логчное, что ожидаешь увидеть, исходя из детсадовского курса
Obvious fix. А когда вырастаешь из детсада - то узнаёшь про строгие и нестрогие типизации, приведение типов, и много чего еще.
> Если чего-то взять пять раз, то получится пять чеготов.
А объект на число в ГБ умножить можно? Что получится на выходе? А если массив умножить - будет 5 массивов, или весь массив, умноженный на 5? А если в массиве еще массивы? А если число на объект? Или число на строку? Oops.
> ну в перле вроде x используется, есть принципиальная разница?
Да нет. Но и будущее при этом тоже должно быть более-менее сходным.
>> Это не умножение строки на число. Это помножение строки числом. :)
> Ну так * - оператор умножения или "помножения"? :)
>> Если чего-то взять пять раз, то получится пять чеготов.
> А объект на число в ГБ умножить можно? Что получится на выходе?
> А если массив умножить - будет 5 массивов, или весь массив,
> умноженный на 5? А если в массиве еще массивы? А если
> число на объект? Или число на строку? Oops.f = lambda a: a
f(5)
5
f * 5
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for *: 'function' and 'int'd = {'a': 5, 'b': [0,4,{'a':99}]}
d * 5
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for *: 'dict' and 'int'l = list(d.items())
l
[('a', 5), ('b', [0, 4, {'a': 99}])]l * 5
[('a', 5), ('b', [0, 4, {'a': 99}]), ('a', 5), ('b', [0, 4, {'a': 99}]), ('a', 5), ('b', [0, 4, {'a': 99}]), ('a', 5), ('b', [0, 4, {'a': 99}]), ('a', 5), ('b', [0, 4, {'a': 99}])]
>> Это самое логчное, что ожидаешь увидеть, исходя из детсадовского курса
> Obvious fix. А когда вырастаешь из детсада - то узнаёшь про строгие
> и нестрогие типизации, приведение типов, и много чего еще.Красивое лучше, чем уродливое.
Явное лучше, чем неявное.
Простое лучше, чем сложное.
Сложное лучше, чем запутанное.
Плоское лучше, чем вложенное.
Разреженное лучше, чем плотное.
Читаемость имеет значение.
Особые случаи не настолько особые, чтобы нарушать правила.
При этом практичность важнее безупречности.
Ошибки никогда не должны замалчиваться.
Если не замалчиваются явно.
Встретив двусмысленность, отбрось искушение угадать.
Должен существовать один — и, желательно, только один — очевидный способ сделать это.
Хотя он поначалу может быть и не очевиден, если вы не голландец.
Сейчас лучше, чем никогда.
Хотя никогда зачастую лучше, чем прямо сейчас.
Если реализацию сложно объяснить — идея плоха.
Если реализацию легко объяснить — идея, возможно, хороша.
Пространства имён — отличная штука! Будем делать их побольше!
и летний хит:[f]
[<function <lambda> at 0x7f9a1d6bd578>][f] * 5
[<function <lambda> at 0x7f9a1d6bd578>, <function <lambda> at 0x7f9a1d6bd578>, <function <lambda> at 0x7f9a1d6bd578>, <function <lambda> at 0x7f9a1d6bd578>, <function <lambda> at 0x7f9a1d6bd578>]
Хорошее лучше, чем плохое.
Светлое светлее, чем яркое.
Красное краснее, чем зеленое...
> Хорошее лучше, чем плохое.
> Светлое светлее, чем яркое.
> Красное краснее, чем зеленое...Вообще-то, всё в python отвечает этой философии. И именно поэтому python настолько удобен и предсказуем. А тем, кто этого не понимает, этого и не понять.
Но есть очень хороший критерий - с php уходят куда угодно, на python, на ruby, на эрланг. Чтобы кто-то добровольно вернулся - я не слышал. Те, кто достаточно использовали и php и python, выбирают однозначно python. Потому что, почувствовав это УДОБСТВО, в неудобства уже не хочется.
Снаружи, в принципе, языки одинаковые, и этого не поймёшь. Но когда что-то реально экономит время и не отвлекает, позволяет проще поддерживать - это непередаваемое ощущение. Как будто спал и проснулся. :)
> Это самое логчное, что ожидаешь увидеть, исходя из детсадовского курса арифметики.а ещё из того же курса мы помним, что умножение — коммутативно. что должно получиться в результате (20 * 'a')? лично я никакого логичного пояснения придумать не могу. а если эта операция запрещена, то мы опять потеряли «логичность и привычность», и снова надо учить какие-то частные случаи.
>> Это самое логчное, что ожидаешь увидеть, исходя из детсадовского курса арифметики.
> а ещё из того же курса мы помним, что умножение — коммутативно.
> что должно получиться в результате (20 * 'a')?20 * 'a'
'aaaaaaaaaaaaaaaaaaaa'
>> что должно получиться в результате (20 * 'a')?
> 20 * 'a'
> 'aaaaaaaaaaaaaaaaaaaa'эту логику я постигнуть не способен. судя по твоему описанию, должно было получиться «'а' раз по 20», что бы это ни значило (я не знаю, что это должно значить).
>>> что должно получиться в результате (20 * 'a')?
>> 20 * 'a'
>> 'aaaaaaaaaaaaaaaaaaaa'
> эту логику я постигнуть не способен. судя по твоему описанию, должно было
> получиться «'а' раз по 20», что бы это ни значило (я
> не знаю, что это должно значить).'a' раз по 20 не может быть в принципе. а почему это работает, вы сами объяснили заметкой выше :)
единственная неоднозначность, которую я вижу - почему только итерируемые объекты? почему нельзя умножить функцию на 5. но тут самый главый вопрос - что должно получиться? список из 5 функций? но почему список, а не кортеж и не набор и не генератор? "не пытайся угадать", заворачиваешь функцию в список - получаешь список из 5 функций.
чтобы это выяснить, достаточно набрать python и проверить (у php консоль уже появилась, чтобы простые вещи проверить? я - не нашёл. неудобно в сравнении всё время файлы с закорючками писать)
> 'a' раз по 20 не может быть в принципе.вот именно. а должно. почему именно 20 раз по 'a', а не 'a' раз по 20? где логика? это напрочь уносит коммутативность умножения. и именно поэтому какой-нибудь repeat() или duplicate() был бы намного логичней.
> чтобы это выяснить, достаточно набрать python и проверить
вот именно: догадаться нельзя, можно только опытным путём выяснить. логика и рядом не лежала.
> вот именно: догадаться нельзя, можно только опытным путём выяснить. логика и рядом не лежала.Когда постоянно будешь натыкаться на **kw, обязательно захочешь попробовать. :)
А вообще, слуш, мож ты просто не голландец?
> А вообще, слуш, мож ты просто не голландец?Гурвіник (зніма з стіни гіпсового пірата). Жид? Шо мовчиш? Хрясь!
Пірат-жид пада на підлогу і розбивається. Карандаш стовпіє.
Гурвіник (до Карандаша). Шо, жалко жида? Може ти тоже жид?
Карандаш (злякавшись). Нє, я — украінєц.
Самодєлкін (танцює чочотку). Такий, як я китаєць.
> вот когда знак умножения означает не умножение — вот это становится загадочным
> :)вот мы и вернулись к тому, с чего начинали.
Да ладно, аналитики с ЛОРа они такие :)
> Тоже самое говорили такие же «аналитики» про 5.0 версию — «php скатился
> в java», «зачем это нужно». Агония затянулась, не находите?Да никто и не говорит, что php умрёт в одночасье - кто ж тогда ораву голодных пыхеров кормить будет, которые так ничего делать и не научились? Речь именно о тенденции, о движении, когда проект думает не о своей основной аудитории (быдлокодеры, пишушие небезопасный лапшеобразный код), а начинает вводить то, что этой аудитории непонятно. В результате и получится гибрид, который будет только терять "своих" пользователей.
чтобы умер php, надо убить много cms да фреймворков.
интернет, ессно, в одночасье не умрёт - не применило ещё сшп сиё оружие в полной мере. готовится только.
ну а как бабахнет - тут уж не волнуйтесь. неандертальцы им много выгоднее человеков, так что искоренят, будьте на этот счёт спокойны.
> чтобы умер php, надо убить много cms да фреймворков.
> интернет, ессно, в одночасье не умрёт - не применило ещё сшп сиё
> оружие в полной мере. готовится только.
> ну а как бабахнет - тут уж не волнуйтесь. неандертальцы им много
> выгоднее человеков, так что искоренят, будьте на этот счёт спокойны.Фреймворки на php - это вообще отдельная хохма. Пытаются эмулировать вещи, которых в php нет, но при этом при малейшем погружении вглубь оказывается, что их там и не появилось.
Ну хочешь ты писать "как на python или на ruby" - ну и пиши ты на python или на ruby, зачем цепляться за php? я вот этого дебилизма никогда понять не смогу. "хочу python/ruby, но на php"? почему, млять, на php-то? когда python/ruby гораздо удобнее, гораздо понятнее, гораздо логичнее, и их проще читать и проще поддерживать? Зачем за php держаться-то? Не вижу ни одной причины. php - это для убогого небезопасного лапшекода, нормальный стиль а-ля python/ruby (я уж не говорю про спецсредства) там просто чужд.
>> "хочу python/ruby, но на php"?Вот это и называется - быдлокодер. Надо отстреливать сразу. Если пишешь на языке - будь добр учитывать его особенности, а не "хочу другой язык" и лепить костыли.
> Пытаются эмулировать вещи, которых в php нет, но при этом при малейшем погружении вглубь оказывается, что их там и не появилось.Это ещё чё. Современные программеры - лишь жалкие подражатели извергов, эмулирующих машинными кодами функции ассемблерных компиляторов. Где это видано, чтобы процессор обладал функциями компиляции кода? А выполнять он тогда что будет? Он же перегреется от мнемокодов прежде, чем завершится считывание перфокарт.
Сколько лет с тех пор прошло, сколько ядер в процессорах домашних компов перерабатывают ютуб в тепло да пакуют сейвы скайрима, а ни одного эксцеля и ни единого фотошопа внутри архитектур не появилось.
Истинно, это -- закат нашей цивилизации. Помяните моё слово.
Потому что PHP как платформа для web разработки - лучше. А у ruby с python не получилось, не фортануло :)
> Потому что PHP как платформа для web разработки - лучше.Лучше. Для разгильдяев. Потому что поощряет разгильдяйство. Для нормальных людей - не лучше.
Лучше. Для виндузятников. Потому что если один виндузятник спросит другого виндузятника, что есть для веба, тот ему посоветует Пых_с_Апачем.exe. Не потому, что действительно сравнивал средства, а потому что других он просто не знает. А если вдруг запустит python и окажется, что сначала нужно было мануал прочитать - естественно, убежит в пых, где интерпретатор плачет, даваится, но ест его код.
> А у ruby с python не получилось, не фортануло :)
У кого не получилось? У меня всё, что пишется, пишется на python. И после 9 лет с php я вижу, насколько это удобнее и понятнее. Это у пыхеров не получилось, у них на одного разработчика по три уязвимости приходится, и никто не чешется исправлять.
Многие умные люди давно перешли на ruby/python. Чтобы умные люди переходили обратно, я не слышал. Наоборот, только и говорят о том, как всё стало удобно. В истории новых взлётах, во всех этих твитерах, шмитерах, гитхабах, стограммах и прочих новых ярких взлетающих проектах - или ruby, или python, или node, или даже эрланг там встретить реальнее, чем php. У php только одна ниша - низкокачественное безалаберное программирование, когда нанимаются самые дешёвые низкоквалифицированные, и "работу работают", причем часто аналог их двухмесячной работы я мог повторить на bottle, с большим качеством и понятностью для групповой разработки, часа за два. Потому что решение задачи в лоб при хоть сколько-нибудь серьёзной задаче, заставляет "закапываться в код" и плодить монстра, когда никому не понятно, как он работает.
На современном python и ruby так не пишут. И именно об этом речь. Что средний код на python/ruby гораздо качественнее, гораздо понятнее, и гораздо проще в поддержке. И виноваты тут и язык php, и культура, которую он создал. "Быдловелоперс! Быдловелоперс! Быдловелоперс! Если не знаешь вообще ничего, то пиши на php."
> А вообще, судя по ченчлогу, php плавно скатывается в python (разработчики явно
> с туториала python-а не вылазили), только с С-синтаксисом и набором legacy-ужаса.Не, когда php опуститься на дно окончательно, снизу постучит гвидобейсик. Это же надо было такого идиотизма наплодить что в системе приходиться держать 2.7 и 3.2 к примеру (это еще учитывая что я не ставлю софта работающего на гвидобейсике)
dev-lang/python
Available versions:
(2.5) 2.5.4-r4 2.5.4-r5
(2.6) 2.6.8 2.6.8-r1
(2.7) 2.7.3-r2 2.7.3-r3 ~2.7.4 ~2.7.5
(3.1) 3.1.5 3.1.5-r1
(3.2) 3.2.3 ~3.2.3-r1 3.2.3-r2 ~3.2.4 ~3.2.5
(3.3) **3.3.1 ~3.3.2
>> А вообще, судя по ченчлогу, php плавно скатывается в python (разработчики явно
>> с туториала python-а не вылазили), только с С-синтаксисом и набором legacy-ужаса.
> Не, когда php опуститься на дно окончательно, снизу постучит гвидобейсик. Это же
> надо было такого идиотизма наплодить что в системе приходиться держать 2.7
> и 3.2 к примеруЭто трагедия. Потеря целых 20 мб свободного пространства!
Какой-нибудь пых захочешь, а не сможешь держать несколько конкурентных веток (при использовании mod_php - уж точно). А в python хоть 5 штук изолированных используй, без проблем.
для тех кто будет переезжать:APC - более не поддерживается, в связи с внедрением zend opcache авторы на дальнейшее развитие расширения забили. Тем кому нужен кеш для переменных могут воспользоваться APCu (есть в PECL, версия 4.0.2), APCu создан на базе APC двумя авторами APC
eaccelerator - можно взять из master ветки github'a как и для 5.4, в eaccelerator.c убрать #include "php_logos.h" , можно пользоваться, хотя ZendOpcache отчасти лучше будет
Xcache - версия 3.1.0-dev доступна в trunk
личные впечатления от перехода на 5.5 - больше тормозит и с аппетитом кушает память
А ведь еще недавно ходили слухи, что именно АРС будет включен в штатную поставку пхп... А теперь его вообще погнали лесом.
его не погнали, просто амбиции авторов поумерили, вот xcache не претендовал на включение по умолчанию, или даже в pecl, а автор продолжает делать свое делоавторам apc никто не мешает и дальше делать то что делали, расширение по преждему в pecl, но текущая версия с php 5.5 несовместима, авторы сами решили спрыгнуть на поддержку apcu, но имхо поддержка только variable cache это тупиковый путь и конкуренция тут еще более жесткая, и не только xcache, но и memcache и редиска. может передумают еще.
cd /usr/ports/devel/pecl-APCu && make install cleanспасибо ;)
> Добавлена возможность использования нескалярных итераторов в качестве ключа в цикле foreach (например, "foreach ($iter as $k => $v)");А можно для деревенских, что это?
for i in iter: я понимаю, а вот это? кто кого харлал?
Вообще, тупо эти самые новомодные в 5.5 итераторы в foreach поддерживаются?
> Прекращение поддержки Windows XP и Windows 2003.
"ну теперь венде точно капец" (ц)
> Поддержка ключевого слова "finally"
> Релиз PHP 5.5.0лучше поздно, чем никогда.
До 5.5 разработчики даже не знали о существовании python. А тут открыли мануал, и узнали для себя много нового. Причём многое сделано прямо в лоб, один в один.
Новость в реалтайме меняется. Одно откомментируешь, другое появляется. Стесняются сразу всё показать, что ли?
> Возможность использования empty() и isset() над результатом работы функции и произвольными выражениями (например, empty(foo()));В смысле? А что, и этого не было? ЛЮДИ! КАК ВЫ ТАМ ЖИЛИ?
эк тебя bombanulo.
> эк тебя bombanulo.ась?
>> эк тебя bombanulo.
> ась?именно то. пыхеры сидят, улыбаются. перловщики сидят, улыбаются. гвидобейсиковцы сидят, улыбаются. буратино бегает и кричит «ужос-ужос-ужос!»
зато сколько уникального контенту.
зачем пхп, когда постинг?
> зато сколько уникального контенту.
> зачем пхп, когда постинг?буратино vs php
останется только один
максимум два
>добавлены новые языковые конструкцииЭто когда-нибудь закончится? ALGOL-68 получится.
>>добавлены новые языковые конструкции
> Это когда-нибудь закончится?когда умрёт последний пыхер.
Пых напоминает ту категорию людей, которую все знают, шпыняют и постоянно используют, как хотят. При этом сам человек прекрасно всё понимает, и не смотря на это продолжает двигаться вперёд. Такой вечно вкалывающий неунывающий пофигист.
Этим шпыняющим просто завидно, что они бизнесу нафиг не нужны со своими модными языками.
Это из разряда "собаки лают, караван идет"
Красота то какая, сколько мнений )) Я лично считаю знание сила, не важно какой язык программирования ты знаешь. Поэтому хаить пых и его программеров глупо, лучше взять мануал и работать над собой)) Всем удачи.
Где скачать порно, бесплатно и без регистрации ?
очевидно, на сайте, CMS которого написана на PHP.
кстати, господа пыхеры, помните конкурс по написанию простой, понятной и краткой реализации задания:
Пример: найти гласные буквы (латинские), которые встречаются во всех словах
ruby (простая):words = 'fuckthemall aeouy yeah'.split
result = ['a', 'e', 'i', 'o', 'u', 'y'].find_all{ |c| words.all?{ |word| word.index c } }python (простая):
words = 'fuckthemall aeouy yeah'.split()
result = [c for c in 'aeiouy') if all(c in word for word in words)]
там в теме есть и "нечто совершенно иное": http://www.opennet.me/openforum/vsluhforumID3/90334.html
покажите вариант на php?
А сможешь объяснить, зачем?
> А сможешь объяснить, зачем?Чтобы сравнить элегантность, удобство читать и удобство писать для языков.
> Чтобы сравнить элегантность, удобство читать и удобство писать для языков.Это можно сравнить, только взяв два аналогичных по функциям достаточно больших проекта. К сожалению, ничего на ум не приходит.
>> Чтобы сравнить элегантность, удобство читать и удобство писать для языков.
> Это можно сравнить, только взяв два аналогичных по функциям достаточно больших проекта.
> К сожалению, ничего на ум не приходит.Чтобы сравнить элегантность языков, достаточно подобного сравнения, и сразу будет видно - есть ли там простые средства для простых вещй или нужно городить огород на каждый чих.
Даже по этому сравнению видно, что python-конструкция проще и нагляднее, её легче понять даже тому, кто никогда python в глаза не видел.
ps. А зачем большой? Лучше меньше, да лучше. Можно попробовать написать сравнимо с http://hg.51t.ru/twi-json/ (на python он написан за 2 часа, включая идею и дизайн. затем, для паблика, он был чуть ли не начисто переписан минут за 20, и после этого были только небольшие правки, отражённые в hg). Сейчас я подобное (вот как это выглядит http://bug.51t.ru/ ) напишу на python без дизайна минут за 20. На php можно будет это написать и выпустить в люди минут за 20? И какой код будет? Насколько компактный, понятный и читаемый? И чтобы можно было сразу json получать (это очень удобно для отладки, чтобы ещё без шаблона видеть, правильные ли данные в шаблон уходят, не реализуя полную систему вывода и до реализации самого шаблона)?
> ps. А зачем большой?А затем, чтобы избежать предвзятости сферического сравнения в вакууме. На больших проектах обычно и вылезают все самые интересные моменты языков.
>> ps. А зачем большой?
> А затем, чтобы избежать предвзятости сферического сравнения в вакууме. На больших проектах
> обычно и вылезают все самые интересные моменты языков.Чтобы написать большой проект - нужно написать много-много маленьких модулей. И когда один язык отвлекает на реализацию, да ещё через полгода взгляд на эту функцию рождает вопрос "что это?", это плохой язык.
Поэтому хочется увидеть, как указанная задача по фильтрации букв будет решена на php - этого достаточно, чтобы определить базовое удобство именно самого языка. Если на языке нельзя сделать так, то большинство задач для веб-разработки будет решаться "в лоб", а не "правильно", и код будет представлять из себя ужасное слабоподдерживаемое зрелище. И это явная причина просто не пользоваться этим языком для веб-разработки.
Поэтому ждём реализацию этой функции на php, и сообщество уже оценит, какой язык проще и нагляднее.
> Поэтому ждём реализацию этой функции на php, и сообщество уже оценит, какой
> язык проще и нагляднее.См. пост ниже.
> Даже по этому сравнению видно, что python-конструкция проще и нагляднеечушь.
>> Даже по этому сравнению видно, что python-конструкция проще и нагляднее
> чушь.от абаснуя слышу
>>> Даже по этому сравнению видно, что python-конструкция проще и нагляднее
>> чушь.
> от абаснуя слышуобоснования точь-в-точь повторяют твои.
>>>> Даже по этому сравнению видно, что python-конструкция проще и нагляднее
>>> чушь.
>> от абаснуя слышу
> обоснования точь-в-точь повторяют твои.это я понял
$in = 'fuckthemall aeouy yeah'; $letters = array('a','e','i','j','o','u','y');
foreach (str_word_count($in, 1) as $word) $letters = array_intersect($letters, str_split(count_chars($word, 3), 1));Не знаю, кому как, а мне по читабельности этот код гораздо проще для понимания, чем примеры на Ruby и Python. В основном за счет простых и понятных названий функций и ключевых слов.
> $in = 'fuckthemall aeouy yeah'; $letters = array('a','e','i','j','o','u','y');
> foreach (str_word_count($in, 1) as $word) $letters = array_intersect($letters, str_split(count_chars($word,
> 3), 1));
> Не знаю, кому как, а мне по читабельности этот код гораздо проще
> для понимания, чем примеры на Ruby и Python. В основном за
> счет простых и понятных названий функций и ключевых слов.Мне эти слова не очень знакомы. В отличие от слов 'for', 'in', 'all' и 'if', которые я хорошо знаю года с 1987. И только из них состоит выражение на python.
Там есть и другие python-примеры:
reduce(lambda x,y:set(x)&set(y),words)&set(('a','e','i','o','u','y'))
words = 'fuckthemall aeouy yeah'.split()
result = reduce(set.intersection, words, set('aeiouy'))words = 'fuckthemall aeouy yeah'.split(' ')
print filter(lambda c: all(c in word for word in words), 'aeiouy')
Указанный в начале темы вариант мне нравится именно тем, что можно и в голове прокрутить этот код, и понять, что он делает, и объяснить его младоразработчикам и девушкам, чтобы им было понятно, как работает (оно состоит из очень простых для анализа вещей: простое лучше сложного):print [c for c in 'aeiouy']
['a', 'e', 'i', 'o', 'u', 'y']понятно, что тут перебираются буквы, а if ... ] - выводятся только буквы, когда соблюдается условие. дальше всё просто и понятно (возможно, для ещё большей наглядности, в исходном примере c in word следовало бы взять в скобки):
print [word for word in words]
['fuckthemall', 'aeouy', 'yeah']print [('o' in word) for word in words]
[False, True, False]print [('a' in word) for word in words]
[True, True, True]и, соответственно, all возвращает True, если всё есть True, и False, если не всё.
В зале есть младодевочки, которые не поняли, как это работает, после этой краткой лекции? Поднимите руки.
Суть не в этом. Когда я беру чужой код - я хочу наглядности. Потому что времени разбираться в мешанине из простейших слов, сдобренной спецсимволами, с литровой бутылкой водки - нет. Одна из проблем, которая убила perl.Ну и подытожим: указанная тобой задача выше в любом из предложенных языков решается элементарно, с несущественными различиями. Т.е. не является критерием для сравнения, о чём изначально тебе и говорилось.
> Суть не в этом. Когда я беру чужой код - я хочу
> наглядности. Потому что времени разбираться в мешанине из простейших слов, сдобренной
> спецсимволами, с литровой бутылкой водки - нет. Одна из причин, которая убила perl.как использовать in во всех случаях, я понял интуитивно, без справочников.
хоть в python К БОЛЬШОМУ СЧАСТЬЮ просто нет "традиционного" for, а тот for в других языках называется foreach, пользоваться им тоже можно выучиться с первого раза
суть скобочек поймёт всякий, кто хоть раз видел список. кто списка не видел - тот зайдёт в туториал, посидит с ним вечерок, и будет понимать большинство базовых вещей, а остальному научится.
в python всё строится на общих принципах, которые используются везде. а не на знании тысячи ключевых слов, каждое из которых делает только что-то определённое, и этот опыт в другой сфере уже не применишь. я вообще не помню, сколько раз я за последние пару месяцев заглядывал в справочник - может, раза 4, когда нужно было посмотреть функцию модуля (хотя иногда достаточно обычного dir() )
Когда разные вещи делаются примерно одинаково, разными людьми, есть уже интиутивное ожидание, как оно будет работать. И именно так оно чаще всего и работает, и не нужно отвлекаться от мысли чтобы следить за реализацией. Python - это прежде всего стиль и философия, и благодаря этому не-pythonic вещей там очень мало, и отвлекаться на фигню приходится редко.
> в python всё строится на общих принципах, которые используются везде.Общие принципы, которые ныне используются везде - это принципы C. Тчк.
> на знании тысячи ключевых слов, каждое из которых делает только что-то
> определённое, и этот опыт в другой сфере уже не применишь. яА знаешь, сколько всего надо знать в мало-мальски большом проекте архитекту?
> вообще не помню, сколько раз я за последние пару месяцев заглядывал в справочник
Это значит, что:
а) либо язык настолько примитивен по форме и фактуре, что все сложные функции приходится реализовывать самому
б) либо твой код настолько прост по существу, что в нем нет необходимости использовать большое число различного рода builtin-функций
И в том, и в другом - сомневаюсь. Но либо вышеуказанное верно, либо кто-то врёт.> Python - это прежде всего стиль и философия
Ну я и говорю - прежде всего академическая ценность.
>> в python всё строится на общих принципах, которые используются везде.
> Общие принципы, которые ныне используются везде - это принципы C. Тчк.В C есть такая диктоориентированность, позволяющая легко и просто делать трюки, показанные чуть выше? Такая ориентированность на итераторы и генераторы? (когда я вижу конструкцию for($a=0;$a<count(x);$a++) - мне хочется выть. и я её вижу. и я вою)
>> на знании тысячи ключевых слов, каждое из которых делает только что-то
>> определённое, и этот опыт в другой сфере уже не применишь. я
> А знаешь, сколько всего надо знать в мало-мальски большом проекте архитекту?ась? это вообще разные вещи и разные категории объектов.
> Это значит, что:
> а) либо язык настолько примитивен по форме и фактуре, что все сложные
> функции приходится реализовывать самомуу python отличная модульность. а pypi уступает только cpan по количеству модулей.
> б) либо твой код настолько прост по существу, что в нем нет
> необходимости использовать большое число различного рода builtin-функцийу python отличная модульность. и отличное единообразие, когда на одно и то же действие не нужные разные функции, а многое делается единым путём. а число builtin-функций в python можно посчитать на пальцах
> И в том, и в другом - сомневаюсь. Но либо вышеуказанное верно, либо кто-то врёт.
я даже знаю, кто.
>> Python - это прежде всего стиль и философия
> Ну я и говорю - прежде всего академическая ценность.Прежде всего лёгкая поддерживаемость и следование одной философии, благодаря которой legacy-код можно и понять, и переписать (а не выбрасывать, чтобы записать заново). Даже мои местные пыхеры понимают мой python-код. Где в php испольюзуются штук пять НОВЫХ функций, в python используются 4 знакомых ключевых слова. которые используются много где, и используются именно естественным образом (именно так, как ожидаешь).
Это не только академическая ценность. Это и студенческая, и пыхерская, и девочковая ценность.
> Ну и подытожим: указанная тобой задача выше в любом из предложенных языков
> решается элементарно, с несущественными различиями. Т.е. не является критерием для сравнения,
> о чём изначально тебе и говорилось.Осталось только провести опрос среди разных людей-итышек с просьбой наглядно оценить, ЧТО ДЕЛАЕТ ЭТОТ КОД.
> Осталось только провести опрос среди разных людей-итышек с просьбой наглядно оценить, ЧТО
> ДЕЛАЕТ ЭТОТ КОД.Причем желательно среди людей активно программирующих, но не сильно знакомых с конкретным языком. Это, кстати, будет очень интересный показатель.
>> Осталось только провести опрос среди разных людей-итышек с просьбой наглядно оценить, ЧТО
>> ДЕЛАЕТ ЭТОТ КОД.
> Причем желательно среди людей активно программирующих, но не сильно знакомых с конкретным
> языком. Это, кстати, будет очень интересный показатель.irc, jabber-конференции, жуики всякие. я в подобных вещах ничего не понимаю, поэтому подсказать не смогу, но тут наверное есть кто-то "с выходом".
бесполезные сигилы убивают.
Спасибо торагой, твой батхерт сделал мой день :)
Не очень знаком с синтаксисом Ruby/Python. Если речь о том, чтобы найти все гласные буквы, которые хотя бы раз присутствуют в слове, то, например,$sWords = 'fuckthemall aeouy yeah';
$rgResult = array_intersect(['a', 'e', 'i', 'o', 'u', 'y'],str_split($sWords));Если хочется через замыкание, то - пожалуйста
$sWords = 'fuckthemall aeouy yeah';
$rgResult = array_filter(['a', 'e', 'i', 'o', 'u', 'y'],function($sLetter) use ($sWords)
{
return strpos($sWords, $sLetter)!==false;
});Суть в том, что не стоит недооценивать инструмент, который не до конца знаете (или не знаете вовсе). В PHP начиная с версии 5.4 появилось много хороших вещей.
Лично я считаю PHP трудным языком - потому что на нём трудно писать "правильно" - язык действительно предоставляет слишком много возможностей, так что начинающему программисту легко запутаться и начать делать неверные решения. Не спорю так же и с тем, что очень много плохого "наследия" - в виде всевозможных side-effect функций наподобие sort/shuffle - тут, увы, ничего не поделаешь. Надеюсь только, что в будущих релизах волевым решением сделают всё единообразно и уберут этот процедурный подход PHP 4.
> В PHP начиная с версии 5.4 появилось много хороших вещей.например, «замыкания», которым надо *руками* указывать, что они захватывают. голуби от хохота с проводов падают.
Это можно считать как плюсом, так и минусом.С одной стороны - согласен, если нужно много сущностей того scope, в котором объявлено замыкание, а таковых сущностей порядка 10, то да, утомляет.
С другой стороны - если учесть, что параметры контекста могут быть именованы, а само замыкание - привязано к объекту (через bindTo) - то это хорошая возможность - поскольку предоставляет возможность использовать свойства объекта внутри замыкания. Я бы сказал, это компромисс - если мы хотим, чтобы было возможно второе, то придётся получить недостатки первого.
Наконец, если переменных настолько много, что перечисление их не представляется хорошей идеей, всегда есть get_defined_vars() - но, по правде, у меня никогда не возникало нужды передать замыканию контекст из более чем 3-4 переменных - в силу организации данных. Есть ведь массивы/объекты. Необязательно всё хранить в скалярах.
> Это можно считать как плюсом, так и минусом.это минус. потому что заставляет выполнять руками задачу, с которой отлично справляется компилятор. все переменные из outer scope, которые используются внутри функции, попадают в замыкание. всё. если надо кого-то исключить — «затеняем» его локальной декларацией. но у похапэ… ОПА! нет локальных деклараций.
впрочем, и это обходится элементарным анализом байткода: если переменная из outer scope не используется до первого присваивания ей значения, то захватывать её не надо. костыль, конечно, но в большинстве случаев будет работать и позволит не вводить новый синтаксис.
> это минус. потому что заставляет выполнять руками задачу, с которой отлично справляется
> компилятор. все переменные из outer scope, которые используются внутри функции, попадают
> в замыкание. всё. если надо кого-то исключить — «затеняем» его локальной
> декларацией. но у похапэ… ОПА! нет локальных деклараций.Это концепция языка - у него только принудительное наследование между scope'ами.
Где-то она неудобна, да. Но реально - в ряде случаев страхует от весьма трудноуловимых багов (переменная объявлена в глобальном контексте, не объявлена в локальном, но используется как локальная).
она везде неудобна, потому что заставляет делать за машину её работу. с таким же успехом я могу собрать всё, что мне надо, в массив/новый объект и передавать его, например.а если попроще — то это «мы не поняли, зачем нужны замыкания, поэтому сделали в меру своего непонимания». в итоге вместо облегчения жизни добавили костылей.
алсо, bintTo() не нужен. достаточно иметь нормальные nested functions, и тогда такие «биндеры» элементарно пишутся на самом языке. но у похапэ традиция костылестроения.
Не соглашусь. Использование переменных внутри тела замыкания неявно привязывает его к контексту. А с именованными параметрами мы получаем вполне себе переносимый код, одновременно корректно работающий с контекстом и не зависящий от него. Правда, думаю, это вопрос вкуса - ведь можно в принципе и новое замыкание объявить.Насчёт nested functions и bindTo - не уловил идеи. Можете подробнее?
> Не соглашусь. Использование переменных внутри тела замыкания неявно привязывает его к контексту.эм... это и есть суть замыканий: захватить с собой контекст.
> А с именованными параметрами мы получаем вполне себе переносимый код, одновременно
> корректно работающий с контекстом и не зависящий от него.это, пардон май фрэнч, фигня какая-то. странная помесь недозамыканий и dynamic scoping.
> Правда, думаю,
> это вопрос вкуса - ведь можно в принципе и новое замыкание
> объявить.и можно, и нужно. не надо превращать замыкания в непонятных монстров.
> Насчёт nested functions и bindTo - не уловил идеи. Можете подробнее?
если я верно понял, что делает bindTo, то оно пишется вот так:
function makeBind (obj)
function closure ()
print(obj.field);
end;
return closure;
end;obj0 = { field=42 };
cls0 = makeBind(obj0);
cls1 = makeBind{ field=666 };
cls0(); -- prints 42
cls1(); -- prints 666
ушёл.ноющим пыхерам на заметку:
Багзиллы намного больше.
Вы такие смешные, ребята. Кто-то в это время на пхп кодит и бабло зарабатывает, а вы тут бои по переписке устраиваете, видимо мамы перекормили вас.
> Вы такие смешные, ребята. Кто-то в это время на пхп кодит и
> бабло зарабатывает, а вы тут бои по переписке устраиваете, видимо мамы
> перекормили вас.а мы уже заработали, нам не надо с утра до вечера горбатиться.
portmaster -o lang/php55 lang/php5