Comments 537
в 30 раз меньше готовых фреймворков
Количество — не значит качество. Не хочу обидеть PHP-фреймворки, сам с ними работаю. Но наличие некого мейнстрима не повредило бы
Посмотреть на те же плагины для фреймворков, какой PHP-фреймворк сравниться по количеству гемами для рельсов?
+32
Толку от этих гемов для рельсов, если нет нормальных готовых продуктов на них, или хостинг фиг найдешь. Если бы Ruby/Python был бы таким белым и пушистым он бы уже давно вытеснил PHP. А все эти рассуждения о красивости, мейнстримовости, для всяких языкодрочеров.
Возьмем тот же упомянутый Битрикс, даже среди PHP программеров он считается сборником говнокода. И это как бы не мешает ему быть самой продаваемой коммерческой CMS в рунете…
Возьмем тот же упомянутый Битрикс, даже среди PHP программеров он считается сборником говнокода. И это как бы не мешает ему быть самой продаваемой коммерческой CMS в рунете…
+19
во всем виноваты маркетологи :/
+5
Скорее в этом виноваты программеры, которые вместо того, чтобы делать классный софт — пишут статьи о плохом php.
+64
Самый разумный комментарий за последнюю неделю
+5
Жаль, что голосовать не могу, но полностью поддерживаю!
Хочу только добавить, мне кажется что, проблемы языка в первую очередь в его популярности. Будет питон или руби таким же популярным, и у них найдутся проблемы и ни чуть не лучше, чем у PHP.
Хочу только добавить, мне кажется что, проблемы языка в первую очередь в его популярности. Будет питон или руби таким же популярным, и у них найдутся проблемы и ни чуть не лучше, чем у PHP.
-3
И господство 1С в сфере учета. С Битриксом проще всего хоть как-то настроить интеграцию — не через ручной обмен в XML или CSV, а автоматизированный, по оригинальному и крайне изящному протоколу 1С.
0
хостингом для php можно считать любой сервер с настроенным apache + mod_php только потому, что у большинства php apps/frameworks нет другой стратегии деплоя кроме как «закачайте файлы на сервер по ftp»
0
Думаю мейнстрима, как во всех нормальных языках, не будет еще долго. Хотя, да, что-то начинает вырисовываться (сектор сайтов-визиток, я думаю, эта тенденция не затронет никогда).
Но php-комьюнити есть какая-то мания, я бы даже сказал, религия велосипедостроения: «Зачем разбиваться в чужом коде, если я это могу написать и сам?! Свой код и лучше и ближе». В итоге имеем кривую, 100500-ю по счету реализацию своей cms, orm, mvc; но зато свою, родную. Которую через полтора-два года выкинут и перепишут заново. Или новая команда разработчиков (а чо, мы разбираться в этом говнокоде будем?), либо текущая, которая поняла, что их идеальное решение не такое уж и идеальное.
Поэтому долгое время комьюнити (могу сейчас сказать по времени с 2007 по 2011й, сейчас не знаю что там и как) по большей части топталось на месте — потому что каждый пишет одно и тоже и примерно на одном уровне, миллионы человеко часов тратятся на то, что бы понять как же правильно написать обработку запросов на уровне «вон как у соседа, только трубу покрасим в синий цвет». Все.
Возьмем к примеру тот же symfony, как наиболее продвинутый фреймворк и посмотрим как в 2012м году программисты на php обрабатывают формы: опять работаем на уровне вычленяем данные из запроса, сами вставляем, сами валидируем. На два шага ушли от $_GET['someshit']. В том же java мире эту проблему давно уже решили, для примера отправляю в мануал по spring-framework.
И если когда-то очень давно ничего кроме помойки в виде phpclasses не было, и такой подход был применим, то последние несколько лет эта практика не применима и ведет к тому, что более-мение адекватные специалисты понимают что они ошиблись с выбором языка. Не многим нравится по несколько раз писать одно и тоже
Но php-комьюнити есть какая-то мания, я бы даже сказал, религия велосипедостроения: «Зачем разбиваться в чужом коде, если я это могу написать и сам?! Свой код и лучше и ближе». В итоге имеем кривую, 100500-ю по счету реализацию своей cms, orm, mvc; но зато свою, родную. Которую через полтора-два года выкинут и перепишут заново. Или новая команда разработчиков (а чо, мы разбираться в этом говнокоде будем?), либо текущая, которая поняла, что их идеальное решение не такое уж и идеальное.
Поэтому долгое время комьюнити (могу сейчас сказать по времени с 2007 по 2011й, сейчас не знаю что там и как) по большей части топталось на месте — потому что каждый пишет одно и тоже и примерно на одном уровне, миллионы человеко часов тратятся на то, что бы понять как же правильно написать обработку запросов на уровне «вон как у соседа, только трубу покрасим в синий цвет». Все.
Возьмем к примеру тот же symfony, как наиболее продвинутый фреймворк и посмотрим как в 2012м году программисты на php обрабатывают формы: опять работаем на уровне вычленяем данные из запроса, сами вставляем, сами валидируем. На два шага ушли от $_GET['someshit']. В том же java мире эту проблему давно уже решили, для примера отправляю в мануал по spring-framework.
И если когда-то очень давно ничего кроме помойки в виде phpclasses не было, и такой подход был применим, то последние несколько лет эта практика не применима и ведет к тому, что более-мение адекватные специалисты понимают что они ошиблись с выбором языка. Не многим нравится по несколько раз писать одно и тоже
+3
а вы symfony 2 смотрели и пробовали?
+2
Возьмем к примеру тот же symfony, как наиболее продвинутый фреймворк
Обычно свое мнение как-то выделяют, чтобы другим не казалось, что это аксиома.
0
А выложите пожалуйста пример какой-либо несложной формы с валидацией, чтобы было с чем сравнивать?
0
UFO just landed and posted this here
Symfony2 вродь попопулярнее будет сейчас, некий драйвер комьюнити.
+1
UFO just landed and posted this here
по статистике существующих библиотек/компонентом, которые безшовно вписываються в систему на базе конкретного фреймворка. вродь их еще называют «батарейки».
как один из источников — knpbundles (1131 модуль). можно еще добавить packagist (около 1000 взаимозависимых компонентов) — инициативу единого инсталятора для php composer, некоего аналога ruby gems или python pip.
как один из источников — knpbundles (1131 модуль). можно еще добавить packagist (около 1000 взаимозависимых компонентов) — инициативу единого инсталятора для php composer, некоего аналога ruby gems или python pip.
0
какой PHP-фреймворк сравниться по количеству гемами для рельсов?
rubygems.org/ — 37 483 гема для Руби (сколько из них для подходят/используются для рельсов? не знаю)
drupal.org/ — 15 583 модуля.
Это, как минимум, «сравнимо». Количество гемов для языка общего назначения всего лишь вдвое больше количества модулей под одну CMS/CMF.
0
Мне интересен именно фреймворк, а не CMS. Как бы Drupal не был похож на обычный фреймворк, это все равно другое.
0
В данном случае — не другое. Потому что многие модули, такие как Views, CCK, Image являются именно «плагинами к фрэймворку». Иначе, я бы говорил о 20 000 дополнений к Вордпрессу ;).
0
UFO just landed and posted this here
Общего больше, чем различий.
0
По сути все более-менее популярные CMS являются фреймворками с набором модулей, включая админку, заточенную на этот набор. Собственно потому они и популярны, что стандартное поведение можно изменить не лазя в код CMS, а перехватывая управление — чем не фреймворки?
0
UFO just landed and posted this here
Ну вы же сами понимаете, что друпал — это не самая лучшая система со стороны программиста, там даже ооп нету, причем я хочу заметить — я не фанат ооп, просто я видел как можно делать красиво расширения, и я видел как делают расширения на друпал — игнорирую какие-либо правила и шаблонизаторы ;)
0
Друпал — одна из лучших систем со стороны программиста. Если, конечно, правила, заложенные в саму систему не игнорировать.
-2
Лучшая, это потому что поддерживает совместимость с php4? :)
+3
Это вы на пару лет с этим вопросом опоздали. 5.2 — минимум.
+1
ого, теперь осталось подождать лет 5 и друпал сможет поддерживать замыкания и неймспейсы? ;)
+1
Drupal 8 требует 5.3, наверное что-то из этого использует. Правда, неизвестно еще, когда он выйдет.
+1
8-й использует Symfony Components, а значит использует нэймспэйсы, да и замыкания никто не запрещает использовать, как и ООП в 6-м.
0
Это в ней авторы принципиально пишут без ООП в 21 веке?
+2
UFO just landed and posted this here
Вот это хороший комментарий :) Кстате говоря — я лично наблюдал работу самого высоконагруженного друпала в России ;) Который потом был переписан нами на рельсы. Со стороны юзера все очень удобно, поставил модули (через ssh, а не какой-то там удобный интерфейс, lol) и работай себе на здоровье :)
Со стороны программиста это полный п. В стандартной поставке нет даже пакетного менеджера, я уж молчу про обновления :)
Со стороны программиста это полный п. В стандартной поставке нет даже пакетного менеджера, я уж молчу про обновления :)
0
Я программист, мне нравится.
А медленновато — это да. Правда, до ZF 2 далековато по тормознутости, но неправильной разработкой можно это исправить!
А медленновато — это да. Правда, до ZF 2 далековато по тормознутости, но неправильной разработкой можно это исправить!
0
Автоваз — очень популярен, много запчастей, еще больше специалистов. Опять же — дешевле и ездит.
+63
Согласен с вами. Будучи студентом, подрабатывал делая «сайты на заказ». Большинству заказчиков важным фактором была стоимость, получалось в пределах 200-300 долларов. Им все равно было что будет внутри, главное результат и удобный интерфейс. С моей же стороны нужно было вкладывать в это как можно меньше усилий. PHP с его огромным количеством готовых CMS и просто морем плагинов для них, прекрасно подходит. Лишь тем заказчикам, которым действительно нужно было что то хитрое, масштабируемое и с заделом на будущее, делалось на более серьезных штуках.
+1
Будучи человеком знакомым с такими студентами, часто приходилось как-то модифицировать плагины для популярных cms под нужды заказчика, тк студенты были не в состоянии сами что-то сделать, но отлично находили клиентов. Так вот, на решение проблем заказчика используя рельсу/джангу и написание небольших сайтов уходило значительно меньше времени, чем сидеть и разбираться в говнокоде этих плагинов.
+7
UFO just landed and posted this here
ИМХО все эти допиливания CMS до нужного состояния — это костыль говнокодович.
+1
UFO just landed and posted this here
Если нужен постоянный допил, то я бы вообще никогда не делал ставку на готовую CMS. У любого решения есть предел расширяемости, и если у фреймворков он почти бесконечен (мы говорим о хороших фреймворках), то у CMS крайне ограничен. Конечно, в тех случаях, когда нужно только добавить пользователю новое поле и разместить на сайдбаре няшную штучку, смысла изобретать велосипед и переписывать вордпресс с нуля нет. Но когда из того же вордпресса пытаются сделать магазин, я хватаюсь за пистолет… Как было сказано выше и ниже, если появляется нужда в допиливании, задайтесь вопросом: а не быстрее ли написать нужный функционал на %frameworkname%?
+2
О том и речь, 99% заказчиков не требовали написать ещё один фэйсбук, либо новый хабр. Сайты были достаточно примитивными, магазины не требовали функционал, который предоставляет магента итп.
На написание с нуля используя джангу уходило меньше времени, чем на использование цмски, плагин и попытки модификации плагина, которые превращались в кучу костылей.
Но конечно же не надо забывать что примерно в половине случаев заказчика всё полностью устраивало после установки цмски и настройки пары плагинов, что даже не приходилось прикасаться к коду.
Да, это всё из разряда создания «говно»-сайтов, но ведь речь ведь сейчас как раз про них, где нужно экономить на всём :)
На написание с нуля используя джангу уходило меньше времени, чем на использование цмски, плагин и попытки модификации плагина, которые превращались в кучу костылей.
Но конечно же не надо забывать что примерно в половине случаев заказчика всё полностью устраивало после установки цмски и настройки пары плагинов, что даже не приходилось прикасаться к коду.
Да, это всё из разряда создания «говно»-сайтов, но ведь речь ведь сейчас как раз про них, где нужно экономить на всём :)
+1
UFO just landed and posted this here
Ну тут больше суть не в технологиях, а в том что большинство этих сайтов делалось ради того чтобы он просто был. В случае с магазинами заказчики ожидали что вдруг откуда-то появится поток новых клиентов, не вкладывая никаких усилий в раскрутку. Если это была какая-то информационая площадка, то на контент и периодическое его обновление с таким же успехом забивалось. Вот что я имею в виду под говносайтами :)
0
Не поверите, но ГАЗели. Аккурат выбор небольшого бизнеса.
0
Глупо делать выводы на основе количества результатов в поисковой системе. По остальным пунктам вы назвали плюсы PHP, но не оценили его в сравнении с другими языками. Разумеется, у PHP есть плюсы, но какие-то плюсы есть у любого реального языка. Ничто не стало очевидным, вы ничего не доказали, вы просто постулируете свою точку зрения.
0
Почему люди выбирали PHP?
Возможно потому, что он понятнее, чем Perl, и потому, что писать на нем сайты проще, чем на C++.
Все остальные языки 10 лет назад не имели достаточной аудитории, чтобы рассматривать их в качестве кандидатов для изучения с последующим применением к веб-разработке.
А сейчас его выбирают, скорее всего, из-за того, что он доминирует на рынке.
Возможно потому, что он понятнее, чем Perl, и потому, что писать на нем сайты проще, чем на C++.
Все остальные языки 10 лет назад не имели достаточной аудитории, чтобы рассматривать их в качестве кандидатов для изучения с последующим применением к веб-разработке.
А сейчас его выбирают, скорее всего, из-за того, что он доминирует на рынке.
+15
Ну если Руби с гемами, или Питон с Джангой в 10 раз круче, и существуют в расцвете уже года три минимум (для широкой общественности), почему они не откусили рынок?
Банальный пример. Был браузер, глючный, но лидер — IE. Потом его долю откусил ФФ.
У ФФ была проблема (вроде починили — летает теперь) — утечка памяти, и с плугинами тупил.
Вышел мегабыстрый Хром — и откусил долю ФФ.
То есть хорошие вещи откусывают рынок быстро.
А как это не печально, RoR и Python по совокупности ответов на вопросы -смотри пост — не откусили пока рынок.
Но все возможно… Когда-то правила Альтависта, Яха, Лайкос и Хотбот, рулил Нетскейп, а Гуглеры были студентами-ботанами, работающими над диссером… А потом они запатентовали алгоритм со свистелками и перделками, и все заверте.
Банальный пример. Был браузер, глючный, но лидер — IE. Потом его долю откусил ФФ.
У ФФ была проблема (вроде починили — летает теперь) — утечка памяти, и с плугинами тупил.
Вышел мегабыстрый Хром — и откусил долю ФФ.
То есть хорошие вещи откусывают рынок быстро.
А как это не печально, RoR и Python по совокупности ответов на вопросы -смотри пост — не откусили пока рынок.
Но все возможно… Когда-то правила Альтависта, Яха, Лайкос и Хотбот, рулил Нетскейп, а Гуглеры были студентами-ботанами, работающими над диссером… А потом они запатентовали алгоритм со свистелками и перделками, и все заверте.
+8
инстаграмм — миллиард. работает на джанге.
пинтерест — хз сколько. на ней же. уверен, можно еще не один десяток примеров найти. видимо, мы по разному на этот рынок смотрим.
пинтерест — хз сколько. на ней же. уверен, можно еще не один десяток примеров найти. видимо, мы по разному на этот рынок смотрим.
+1
хром откусил рынок своей огромной рекламой.
-1
Руби — сложный язык. Намного сложнее питона и пхп. РоР — сложный фреймворк. За последние пару лет он стал очень newbie-unfriendly.
Большинство книг по руби подразумевают что читатель знаком с программированием. А если не подразумевают, то все равно написанны программистами и воспринимаются тяжело.
У пхп по-прежнему самый низкий порог вхождения, что обеспеивает им постоянный приток студентов, делающих визитки за 300 долларов, а потом продолжающих писать на пхп, потому что «а что, нормальный язык, все работает вон».
Большинство книг по руби подразумевают что читатель знаком с программированием. А если не подразумевают, то все равно написанны программистами и воспринимаются тяжело.
У пхп по-прежнему самый низкий порог вхождения, что обеспеивает им постоянный приток студентов, делающих визитки за 300 долларов, а потом продолжающих писать на пхп, потому что «а что, нормальный язык, все работает вон».
+3
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
А если будут делать качественные сайты за 6000 рублей — это плохо? Если человек более опытен стал, овладел профессиональными инструментами и методиками, то производительность его труда должна возрасти и за тоже время он сделает больше. Почему вдруг за то, что «студент» делает за две недели и 6000, а профи за неделю нужно платить 12 000?
Под качественным сайтом я имею в виду качественный код сайта, потому как дизайн и прочее юзабилити к компетенции php/python/ruby/… программиста не относится.
Под качественным сайтом я имею в виду качественный код сайта, потому как дизайн и прочее юзабилити к компетенции php/python/ruby/… программиста не относится.
+1
UFO just landed and posted this here
Я как-то делаю один, умудряясь не выступать в роли дизайнера и юзабилиста. Бывает верстаю по макету, а чаще предлагаю на выбор из разных коллекций (в т.ч.платных). Хотя какие-то знания по веб-дизайну есть, но так, для общего развития. И вообще с трудом человека представляю, который сможет и качественный дизайн сделать, и качественный код написать — по-моему совершенно разные способы мышления нужны.
0
Руби никак нельзя назвать сложным языком. Приведите, пожалуйста, пример, в чем конткретно он «сложнее» как язык, чем пхп?
RoR сложный фреймворк? Думаю, он попроще аналогичных фреймворков на пхп. У него отличная документация, есть масса статей и бесплатных скринкастов в интернете. Не знаю, что там unfriendly.
Или вы сравниваете применение RoR с созданием пары тестовых php-страниц и запуском на денвере?
RoR сложный фреймворк? Думаю, он попроще аналогичных фреймворков на пхп. У него отличная документация, есть масса статей и бесплатных скринкастов в интернете. Не знаю, что там unfriendly.
Или вы сравниваете применение RoR с созданием пары тестовых php-страниц и запуском на денвере?
+1
Куда чаще используется функциональная парадигма — проще от этого язык уж точно не становится.
0
Документация у RoR — говно. Об этом все коммьюнити ноет последние года полтора как. Райан Бигг вяло пытается ее как-то дописывать, но ему последнее время сильно не до этого, он занят книгой своей. Плюс, она написанна так, как хочет ДХХ, а кроме ДХХ так никто все равно не делает. Пример – Test::Unit. Я давненько не встречал проекта, тесты которого написанны на Test::Unit. В 99% случаев он сразу выкидывается и заменяется на RSspec.
За примерами «сложности» языка далеко ходить не надо. Практически любой пример из середины и дальше книги Metaprogramming Ruby поставит в тупик среднестатистического разработчика. Мне самому потребовалось олоко двух лет чтобы по-настоящему разобраться и понять все тонкости, описанные в книге и реально начать ими пользоваться. И я по-прежнему иногда путаю instance_eval с class_eval.
Да просто можно посмотреть внутрь того же RSpec. Врядли после этого повернется язык назвать руби простым.
За примерами «сложности» языка далеко ходить не надо. Практически любой пример из середины и дальше книги Metaprogramming Ruby поставит в тупик среднестатистического разработчика. Мне самому потребовалось олоко двух лет чтобы по-настоящему разобраться и понять все тонкости, описанные в книге и реально начать ими пользоваться. И я по-прежнему иногда путаю instance_eval с class_eval.
Да просто можно посмотреть внутрь того же RSpec. Врядли после этого повернется язык назвать руби простым.
+4
Ну и плюс из коробки текущие рельсы ставят sass, coffeescript и asset_pipeline. Человек, который только что прочитал «Ruby для чайников», увидев все это, скорее всего крепко задумается и пойдет делать блог на вордпрессе.
Я очень люблю sass, coffeescript и asset_pipeline. Они реально чудесные и повышают производительность программиста на отличненько. Но я уже много лет во всем этом варюсь и у меня была куча времени вникнуть в эти фичи. А новичок со знанием css/html/javascript/ruby скорее всего обломится.
Я очень люблю sass, coffeescript и asset_pipeline. Они реально чудесные и повышают производительность программиста на отличненько. Но я уже много лет во всем этом варюсь и у меня была куча времени вникнуть в эти фичи. А новичок со знанием css/html/javascript/ruby скорее всего обломится.
+1
Не знаю, чем так плоха документация рельсов. Документация по API отлично оформлена, есть очень удобный аякс-поиск. Еще есть отличные guides.rubyonrails.org/… Сообщество руби слишком любит поныть имхо.
> А новичок со знанием css/html/javascript/ruby скорее всего обломится.
Так никто же не запрещает использовать голые js/css в asset pipeline или вовсе забить на него и кидать файлы в public директорию.
По поводу ваших аргументов про метапрограммирование — ну да, там все непросто, но это advanced фичи языка, и ими совершенно необязательно уметь пользоваться, чтобы писать веб-проекты. Я плохо знаю пхп, но подозреваю, что там большинство подобных вещей вообще сделать нельзя. Делает ли это пхп более простым языком? Возможно, но только в смысле количества функционала. Это не делает его более простым в изучении или применении.
> А новичок со знанием css/html/javascript/ruby скорее всего обломится.
Так никто же не запрещает использовать голые js/css в asset pipeline или вовсе забить на него и кидать файлы в public директорию.
По поводу ваших аргументов про метапрограммирование — ну да, там все непросто, но это advanced фичи языка, и ими совершенно необязательно уметь пользоваться, чтобы писать веб-проекты. Я плохо знаю пхп, но подозреваю, что там большинство подобных вещей вообще сделать нельзя. Делает ли это пхп более простым языком? Возможно, но только в смысле количества функционала. Это не делает его более простым в изучении или применении.
+1
Не такой уж сложный. Думаю сложнее настроить сервер под него. А для PHP под Windows есть Denwer и т.д. Скачал установил и начинай писать
echo "Hello world";
0
Пример в корне неверен. ФФ и хром активно продвигаются в массы, Руби и Питон продвигать нафиг никому не сдалось. Да и как долго ФФ с Хромом что-то там себе отхватили? Еще несколько лет назад IE безраздельно властвовал на рынке, несмотря на давнее существование ФФ и Оперы. Пока, собственно, альтернативные браузеры не начали продвигать.
Вот вам другой «банальный пример»: в мире существует Windows, Mac OS X и Ubuntu. И не смотря на то, что третья неплоха, а вторая прекрасна, с отрывом лидирует первая.
Вот вам другой «банальный пример»: в мире существует Windows, Mac OS X и Ubuntu. И не смотря на то, что третья неплоха, а вторая прекрасна, с отрывом лидирует первая.
0
некому продвигать Руби и Питон?
да я уже немогу без головной боли на хабр зайти, чтоб не наткнутся на какого нибудь «евангелиста»
а год работы на роре у меня отбил все желание пересекаться с руби сообществом
потому что такого агрессивного продвигания своих «правильных идей» надо поискать
аллергию чес слово заработал
да я уже немогу без головной боли на хабр зайти, чтоб не наткнутся на какого нибудь «евангелиста»
а год работы на роре у меня отбил все желание пересекаться с руби сообществом
потому что такого агрессивного продвигания своих «правильных идей» надо поискать
аллергию чес слово заработал
+1
На то они и правильные идеи, чтобы их продвигали. В противном случае получим ситуацию, сложившуюся в PHP-сообществе, когда вставка html-кода в модель или контроллер является вполне обыденным явлением.
0
Покажите хоть один MVC фрэймворк, где такое происходит.
+1
| В противном случае получим ситуацию, сложившуюся в PHP-сообществе, когда вставка html-кода в модель или контроллер является вполне обыденным явлением.
где такое сложилось, я с такими не знаком :) а на основании кода видимого мной на роре я могу сделать такие же глобальные выводы :)
| На то они и правильные идеи, чтобы их продвигали
я не случайно поставил кавычки «правильные идеи» — потому что эти сообщества колеблятся с линией партии и то что превозносится ими как гениальное и единственно верное решение через пару лет ими же порицается а на пьедестал возносится что либо другое
и я не люблю секты, но это личное :)
где такое сложилось, я с такими не знаком :) а на основании кода видимого мной на роре я могу сделать такие же глобальные выводы :)
| На то они и правильные идеи, чтобы их продвигали
я не случайно поставил кавычки «правильные идеи» — потому что эти сообщества колеблятся с линией партии и то что превозносится ими как гениальное и единственно верное решение через пару лет ими же порицается а на пьедестал возносится что либо другое
и я не люблю секты, но это личное :)
0
> где такое сложилось, я с такими не знаком :)
Да вы счастливый человек!
>я не случайно поставил кавычки «правильные идеи» — потому что эти сообщества колеблятся >с линией партии и то что превозносится ими как гениальное и единственно верное решение >через пару лет ими же порицается а на пьедестал возносится что либо другое
Ммм… пример?
Да вы счастливый человек!
>я не случайно поставил кавычки «правильные идеи» — потому что эти сообщества колеблятся >с линией партии и то что превозносится ими как гениальное и единственно верное решение >через пару лет ими же порицается а на пьедестал возносится что либо другое
Ммм… пример?
0
> Да вы счастливый человек!
к сожалению не настолько, я видел такое в рор проекте :)
> Ммм… пример?
rjs -> cofeescript
erb -> haml
«а сейчас вышла новая версия рора которая встотыщь раз лучше всего остального, да кстати и предыдущей версии тоже, так что то что вы написали до этого можете выкинуть на помойку»
повальное использования орм
как то так
к сожалению не настолько, я видел такое в рор проекте :)
> Ммм… пример?
rjs -> cofeescript
erb -> haml
«а сейчас вышла новая версия рора которая встотыщь раз лучше всего остального, да кстати и предыдущей версии тоже, так что то что вы написали до этого можете выкинуть на помойку»
повальное использования орм
как то так
+2
Пардон, но это бред)
> rjs -> cofeescript
Абсолютно разные вещи для разных нужд.
> erb -> haml
Официальный шаблонизатор рельсов все еще erb. Haml использую те, кому он нравится, так же как и scss, coffeescript, итд.
> «а сейчас вышла новая версия рора которая встотыщь раз лучше всего остального, да кстати и предыдущей версии тоже
Это настолько неестественно для PHP-сообщества, что новая версия лучше предыдущей? оО
> так что то что вы написали до этого можете выкинуть на помойку
Эмм… а вы точно с рельсами работали? Рельсы — это гем, который, как и все прочие, спокойно обновляется до последней версии. Более того — разработчики всегда выпускают инструкцию по переводу проекта на новые рельсы.
Сам имею проект, начавшийся на RC 3х рельсов и работающий сейчас на 3.2.
> повальное использования орм
Если вы хотите писать модели без использования AR — пишите. Но зачем?
Вы выглядите как слепой фанатик php, уж простите…
> rjs -> cofeescript
Абсолютно разные вещи для разных нужд.
> erb -> haml
Официальный шаблонизатор рельсов все еще erb. Haml использую те, кому он нравится, так же как и scss, coffeescript, итд.
> «а сейчас вышла новая версия рора которая встотыщь раз лучше всего остального, да кстати и предыдущей версии тоже
Это настолько неестественно для PHP-сообщества, что новая версия лучше предыдущей? оО
> так что то что вы написали до этого можете выкинуть на помойку
Эмм… а вы точно с рельсами работали? Рельсы — это гем, который, как и все прочие, спокойно обновляется до последней версии. Более того — разработчики всегда выпускают инструкцию по переводу проекта на новые рельсы.
Сам имею проект, начавшийся на RC 3х рельсов и работающий сейчас на 3.2.
> повальное использования орм
Если вы хотите писать модели без использования AR — пишите. Но зачем?
Вы выглядите как слепой фанатик php, уж простите…
0
> Это настолько неестественно для PHP-сообщества, что новая версия лучше предыдущей? оО
неестественно что не поддерживается старая :)
> Эмм… а вы точно с рельсами работали? Рельсы — это гем, который, как и все прочие, спокойно обновляется до последней версии. Более того — разработчики всегда выпускают инструкцию по переводу проекта на новые рельсы.
работал на 1.2 четыре года назад :) и насколько знаю пару лет назад проект продолжал бежать на том же, кажется они не смогли перейти :) расскажите мне что 1.2 отстой недостойный упоминания :)
> Если вы хотите писать модели без использования AR — пишите. Но зачем?
я использую актив рекорд :)
разница в терминологии, актив рекорд да, а повальное использование связей чтобы по аттрибуту конструктор сам сабирал джойны было тогда оч популярно
> Вы выглядите как слепой фанатик php, уж простите…
ну конешо давайте уже поговорим обо мне :) а почему вы решили что если я против навязывания руби/рор сообществ своих «идеалов» я фанатик php? :)
я антифанатик руби :)
а питоны, сишарпы, нод джи эсы да сколько угодно, раньше и руби но теперь аллергия :)
неестественно что не поддерживается старая :)
> Эмм… а вы точно с рельсами работали? Рельсы — это гем, который, как и все прочие, спокойно обновляется до последней версии. Более того — разработчики всегда выпускают инструкцию по переводу проекта на новые рельсы.
работал на 1.2 четыре года назад :) и насколько знаю пару лет назад проект продолжал бежать на том же, кажется они не смогли перейти :) расскажите мне что 1.2 отстой недостойный упоминания :)
> Если вы хотите писать модели без использования AR — пишите. Но зачем?
я использую актив рекорд :)
разница в терминологии, актив рекорд да, а повальное использование связей чтобы по аттрибуту конструктор сам сабирал джойны было тогда оч популярно
> Вы выглядите как слепой фанатик php, уж простите…
ну конешо давайте уже поговорим обо мне :) а почему вы решили что если я против навязывания руби/рор сообществ своих «идеалов» я фанатик php? :)
я антифанатик руби :)
а питоны, сишарпы, нод джи эсы да сколько угодно, раньше и руби но теперь аллергия :)
+1
>неестественно что не поддерживается старая :)
К 3.0 и 3.1 выходят обновления. 2я версия да, устарела и не поддерживается. У всего есть свой период поддержки.
> работал на 1.2 четыре года назад :) и насколько знаю пару лет назад проект
> продолжал бежать на том же, кажется они не смогли перейти :)
Я, к сожалению, не застал времена первых рельс и не могу с точностью сказать, что же помешало им обновиться. Но подозреваю, что руки и нежелание.
> разница в терминологии, актив рекорд да, а повальное использование связей
> чтобы по аттрибуту конструктор сам сабирал джойны было тогда оч популярно
И сейчас популярно. Это плохо — писать меньше кода?
К 3.0 и 3.1 выходят обновления. 2я версия да, устарела и не поддерживается. У всего есть свой период поддержки.
> работал на 1.2 четыре года назад :) и насколько знаю пару лет назад проект
> продолжал бежать на том же, кажется они не смогли перейти :)
Я, к сожалению, не застал времена первых рельс и не могу с точностью сказать, что же помешало им обновиться. Но подозреваю, что руки и нежелание.
> разница в терминологии, актив рекорд да, а повальное использование связей
> чтобы по аттрибуту конструктор сам сабирал джойны было тогда оч популярно
И сейчас популярно. Это плохо — писать меньше кода?
0
> К 3.0 и 3.1 выходят обновления. 2я версия да, устарела и не поддерживается. У всего есть свой период поддержки.
я имел ввиду что переход на новую версию настолько труден что выходом чаще остается только переписывание по новой. И насколько я понимаю 2 не поддерживает 1.2 а 3 не поддерживает 2? И каждая следущая настолько другая и лучше предыдущей что становится не понятно кому предыдущая нужна была в принципе :)
> Но подозреваю, что руки и нежелание.
полностью с вами согласен :) что плохие программисты есть везде
> И сейчас популярно. Это плохо — писать меньше кода?
к сожалению путаница в терминологии с моей стороны.
я предпочитаю использовать только конструктор запросов без связи один в один объекта с таблицей и связей с другими таблицами.
:) попробую на примере того самого большого рор проекта: были связаны все таблицы через модели. и указание аттрибута через точку влекло за собой выборку через три джойна этого аттрибута из четвертой таблицы без того что программист понимал что нагибает весь проект
опять же моя претензия к конкретным людям очень любящих слово «мэджик» :)
хорошо писать понятный код :)
я имел ввиду что переход на новую версию настолько труден что выходом чаще остается только переписывание по новой. И насколько я понимаю 2 не поддерживает 1.2 а 3 не поддерживает 2? И каждая следущая настолько другая и лучше предыдущей что становится не понятно кому предыдущая нужна была в принципе :)
> Но подозреваю, что руки и нежелание.
полностью с вами согласен :) что плохие программисты есть везде
> И сейчас популярно. Это плохо — писать меньше кода?
к сожалению путаница в терминологии с моей стороны.
я предпочитаю использовать только конструктор запросов без связи один в один объекта с таблицей и связей с другими таблицами.
:) попробую на примере того самого большого рор проекта: были связаны все таблицы через модели. и указание аттрибута через точку влекло за собой выборку через три джойна этого аттрибута из четвертой таблицы без того что программист понимал что нагибает весь проект
опять же моя претензия к конкретным людям очень любящих слово «мэджик» :)
хорошо писать понятный код :)
0
> я имел ввиду что переход на новую версию настолько труден что выходом чаще остается только переписывание по новой.
Это, мягко говор, неправда.
> И насколько я понимаю 2 не поддерживает 1.2 а 3 не поддерживает 2?
Вот эту фразу я не понял вообще.
> И каждая следущая настолько другая и лучше предыдущей что
> становится не понятно кому предыдущая нужна была в принципе :)
Тут дела обстоят как с любым софтом. Выходит новая улучшенная версия. Хочешь — пользуйся старой. Хочешь новых плюшек — обновляйся.
> попробую на примере того самого большого рор проекта: были связаны
> все таблицы через модели. и указание аттрибута через точку влекло за
> собой выборку через три джойна этого аттрибута из четвертой таблицы
Бездумное использование предоставленных возможностей — беда не языка или фреймворка, а человека, использующего из.
А если конкретно по примеру, то для каждой ассоциации можно указывать свои SQL-запросы, коль уж не нравятся сгенерированные автоматом. И выглядеть будет красиво, и работать оптимально.
Это, мягко говор, неправда.
> И насколько я понимаю 2 не поддерживает 1.2 а 3 не поддерживает 2?
Вот эту фразу я не понял вообще.
> И каждая следущая настолько другая и лучше предыдущей что
> становится не понятно кому предыдущая нужна была в принципе :)
Тут дела обстоят как с любым софтом. Выходит новая улучшенная версия. Хочешь — пользуйся старой. Хочешь новых плюшек — обновляйся.
> попробую на примере того самого большого рор проекта: были связаны
> все таблицы через модели. и указание аттрибута через точку влекло за
> собой выборку через три джойна этого аттрибута из четвертой таблицы
Бездумное использование предоставленных возможностей — беда не языка или фреймворка, а человека, использующего из.
А если конкретно по примеру, то для каждой ассоциации можно указывать свои SQL-запросы, коль уж не нравятся сгенерированные автоматом. И выглядеть будет красиво, и работать оптимально.
0
> Это настолько неестественно для PHP-сообщества, что новая версия лучше предыдущей?
«why switching from Ruby»
groups.google.com/forum/?fromgroups#!topic/urug/UZ8fDVcNiOA
1) Ruby version hell
2) Rails 3 also seems to be imploding on version — it requires at least 1.8.7 but wait, it crashes on the last few p releases
«why switching from Ruby»
groups.google.com/forum/?fromgroups#!topic/urug/UZ8fDVcNiOA
1) Ruby version hell
2) Rails 3 also seems to be imploding on version — it requires at least 1.8.7 but wait, it crashes on the last few p releases
0
Вы хотите сказать, что в RoR нельзя вставить html в модель или контроллер?
+1
Ну, одно дело — поменять браузер, другое — язык, на котором пишешь.
0
Вопросы которые вы привели — типичные для быдла, которое хочет тупо заработать бабла на чужой идее. Да — это работает, но только первый после *бога* получает такую возможность.
Так вот, а что насчет новых, революционных проектов?
Я к веб программированию не имею никакого отношения, просто мимопроходил.
Так вот, а что насчет новых, революционных проектов?
Я к веб программированию не имею никакого отношения, просто мимопроходил.
-27
Думаете человека который хочет сделать себе интернет-магазин волнует красота языка? Его интересуют в первую очередь сроки и цена разработки и поддержки, а какие там гемы бывают у руби ему пофиг.
+19
Я вааще не об этом спрашивал. Может вы ошиблись веткой?
-8
Ну это я к вопросам для быдла. Или вы своих заказчиков быдлом считаете, ну тогда ладно.
+4
А где вы увидели, что я своих заказчиков быдлом считаю? Я спросил у вас — как обстоят дела у пхп с нестандартными проектами, но вы видимо не хотите отвечать на этот вопрос и уходите от ответа.
-6
точно так же обстоят как у любых других языков.
на пхп при должном умении можно реализовывать любые нестандартные проекты. так же как на руби, питоне, перле, си.
на пхп при должном умении можно реализовывать любые нестандартные проекты. так же как на руби, питоне, перле, си.
+12
напишите простенький аналог erlyvideo или flumotion на php.
0
PHP это язык для разработки веб-сайтов (PHP: hypertext preprocessor)
вполне очевидно, что на нем легко и удобно реализовывать любые стандартные (визитка, блог, форум) и нестандартные проекты, из области создания веб-сайтов
но предлагать на пхп реализовать сервер для стриминга видео это все равно что предложить на vbscript написать сервер для мморпг.
вполне очевидно, что на нем легко и удобно реализовывать любые стандартные (визитка, блог, форум) и нестандартные проекты, из области создания веб-сайтов
но предлагать на пхп реализовать сервер для стриминга видео это все равно что предложить на vbscript написать сервер для мморпг.
0
на пхп при должном умении можно реализовывать любые нестандартные проекты. так же как на руби, питоне, перле, си.
т.е. вы сначала ставите php в один ряд с языками общего назначения, а после моего комментария он вдруг становится исключительно языком для веба.
либо крестик снимите, либо трусы наденьте.
т.е. вы сначала ставите php в один ряд с языками общего назначения, а после моего комментария он вдруг становится исключительно языком для веба.
либо крестик снимите, либо трусы наденьте.
+1
я думаю любому здравомыслящему человеку понятно что языки можно сравнивать только в разрезе их предназначения, и в контексте этой ветки обсуждения обсуждаются нестандартные проекты именно из сферы веб-программирования.
автор первого комментария написал, что на пхп хорошо решаются типовые проекты, и уточнил, можно ли на нем сделать что-то нетиповое.
ответ: да, на нем можно делать нетиповые проекты, так же как на любрм другом языке. но не нужно пытаться домкратом накачать колесо
автор первого комментария написал, что на пхп хорошо решаются типовые проекты, и уточнил, можно ли на нем сделать что-то нетиповое.
ответ: да, на нем можно делать нетиповые проекты, так же как на любрм другом языке. но не нужно пытаться домкратом накачать колесо
0
а в чём сложность с онлайн-трансляцией на сайте?
почему на erlang/python/java это можно сделать, а на php — «домкратом накачать колесов».
вообще, php — уникальный проект. хотя бы потому, что это один из немногих проектов, в котором security officer отчаялся и устроил террор, публикуя по критической уязвимости в неделю.
почему на erlang/python/java это можно сделать, а на php — «домкратом накачать колесов».
вообще, php — уникальный проект. хотя бы потому, что это один из немногих проектов, в котором security officer отчаялся и устроил террор, публикуя по критической уязвимости в неделю.
0
я же один раз уже вам ответил:
PHP: hypertext preprocessor.
это официальное название этого языка. еще раз: hypertext preprocessor.
в пхп нет сложности с онлайн-трансляцией на сайте, просто пхп будет генерировать хтмл-код сайта, отображать видео на клиенте будет флеш или сильверлайт или сам браузер в случае хтмл5, а отдавать контент с сервера будет апач или nginx или какое нибудь специализированное решение.
я тоже могу сказать «реализуйте видео-плеер для браузера на эрланге. почему на яве, экшнскрипте и сильверлайте это сделать можно, а на эрланге и питоне нельзя?».
PHP: hypertext preprocessor.
это официальное название этого языка. еще раз: hypertext preprocessor.
в пхп нет сложности с онлайн-трансляцией на сайте, просто пхп будет генерировать хтмл-код сайта, отображать видео на клиенте будет флеш или сильверлайт или сам браузер в случае хтмл5, а отдавать контент с сервера будет апач или nginx или какое нибудь специализированное решение.
я тоже могу сказать «реализуйте видео-плеер для браузера на эрланге. почему на яве, экшнскрипте и сильверлайте это сделать можно, а на эрланге и питоне нельзя?».
0
>а отдавать контент с сервера будет апач или nginx или какое нибудь специализированное решение.
так почему эти «специализированные решения» на erlang/java/python пишут, а на php — нет?
вариантов относительно немного:
1)язык для этого не подходит(неудобен/противоречив/etc)
2)язык для этого не предназначен
3)сообщество программистов вокруг данного языка не в состоянии написать
Пытаясь защититься пунктом N2, вы сужаете пространство для поиска ответов на пункты N1 & N3.
>я тоже могу сказать «реализуйте видео-плеер для браузера на эрланге. почему на яве, экшнскрипте и сильверлайте это сделать можно, а на эрланге и питоне нельзя?».
и это будет неверная аналогия. на серверной стороне может быть что угодно, хоть brainfuck.
так почему эти «специализированные решения» на erlang/java/python пишут, а на php — нет?
вариантов относительно немного:
1)язык для этого не подходит(неудобен/противоречив/etc)
2)язык для этого не предназначен
3)сообщество программистов вокруг данного языка не в состоянии написать
Пытаясь защититься пунктом N2, вы сужаете пространство для поиска ответов на пункты N1 & N3.
>я тоже могу сказать «реализуйте видео-плеер для браузера на эрланге. почему на яве, экшнскрипте и сильверлайте это сделать можно, а на эрланге и питоне нельзя?».
и это будет неверная аналогия. на серверной стороне может быть что угодно, хоть brainfuck.
0
ну это уже слишком толстый троллинг.
почему люди не накачивают колеса домкратом?
вариантов немного:
1. им неудобно качать колеса
2. он для этого не предназначен
3. сообщество пользователей домкратов слишком слабо чтобы накачать им колесо.
прикрываясь пунктом 2 я пытаюсь закрыть глаза на пункты 1 и 3.
почему люди не накачивают колеса домкратом?
вариантов немного:
1. им неудобно качать колеса
2. он для этого не предназначен
3. сообщество пользователей домкратов слишком слабо чтобы накачать им колесо.
прикрываясь пунктом 2 я пытаюсь закрыть глаза на пункты 1 и 3.
0
спасибо, поржалъ! 8))))
Но аналогия не верна, т.к вы путаете «не применим вообще» и «ограниченная область применения».
Если уж сравнивать компрессоры, то это:
«компрессор с питанием от электросети автомобиля или 220V с универсальным набором насадок и опций» vs «компрессор для автомобиля».
автомобильным, конечно, можно накачивать что-то отличное от колёс, да только не предназначен он.
Но аналогия не верна, т.к вы путаете «не применим вообще» и «ограниченная область применения».
Если уж сравнивать компрессоры, то это:
«компрессор с питанием от электросети автомобиля или 220V с универсальным набором насадок и опций» vs «компрессор для автомобиля».
автомобильным, конечно, можно накачивать что-то отличное от колёс, да только не предназначен он.
+1
4) написать можно, но плюсов по сравнению с существующими реализациями на других языках не будет.
У php в подобных случаях нет сильных сторон, из-за которых стоило бы использовать именного его. И одна откровенно слабая — нет многопоточности. Реализовать вроде можно, но сложно. А главное зачем?
У php в подобных случаях нет сильных сторон, из-за которых стоило бы использовать именного его. И одна откровенно слабая — нет многопоточности. Реализовать вроде можно, но сложно. А главное зачем?
0
легко — есть такое. Пример: mark.koli.ch/2009/02/07/streamer.phps
+1
Пишу последние годы на ПХП одни нестандартные проекты. Проблем нет вообще никаких. Полностью всего хватает с головой
+18
А есть с чем сравнивать?
0
Главный вопрос зачем? Лично мне производительность PHP вполне хватает. И я не думаю что другой интерпретируемый язык тут что-то поменял бы в корне. Если уж реально надо получить прирост скорости (5-10 раз) — тогда на джаву смотреть надо. Обычно так и делаем — самые нагруженные демоны выносим на джаву, все остальное — ПХП.
+2
Преимущество других языков вовсе не в скорости. Математические расчеты на сайтах вы в больших количествах врядли проводите, а запросы к БД по большому счету безразлично на каком языке составлять.
Преимущество в удобстве разработки и поддержки.
Преимущество в удобстве разработки и поддержки.
0
Ну и в чем проблема. Я использую набор классов из Symfony2 для роутинга и валидации основанной на аннотациях, Twig шаблонизатор, Doctrine для ORM. Почему бытует такое мнение, что раз PHP то это сразу неудобно и говнокод сплошной?
+6
В других языках может быть больше возможностей для сохранения результатов своей работы в виде библиотек за счет унификации понятий языка. В результате функций и классов больше область применения — не надо дублировать код.
Это играет тем большую роль, чем больше у вас своего кода.
Это играет тем большую роль, чем больше у вас своего кода.
0
UFO just landed and posted this here
Напишите на php такую функцию:
Функция берет то, что можно перечислять, элементов чего является строка (может быть список, строка и т.д) и возвращает строку c элементами исходного объекта, обрамленными тегами li.
Пример:
def make_list(xs):
return ''.join('<li>'+x+'</li>' for x in xs)
Функция берет то, что можно перечислять, элементов чего является строка (может быть список, строка и т.д) и возвращает строку c элементами исходного объекта, обрамленными тегами li.
Пример:
print make_list('abc')
print make_list(['1', '2', '4'])
Output:
<li>a</li><li>b</li><li>c</li>
<li>1</li><li>2</li><li>4</li>
-6
UFO just landed and posted this here
return '<li>'.implode('</li><li>',$array).'</li>';
Не?
+6
cработает ли implode со строкой?
с множеством?
со множетсвом ключей dictionry?
со можеством его жлементов?
с множеством?
со множетсвом ключей dictionry?
со можеством его жлементов?
0
Если вы подразумеваете, что нужно «проимплодить» каждый символ строки — нет. И, думаю, это не очевидное поведение.
В PHP, как уже было сказано, нет отдельного типа для массивов, хешей, словарей и т.д. Есть просто массивы. Для них всё сработает предсказуемо.
Если вы хотите какую-то более сложную структуру, можно создать класс-имплементацию итератора, который будет итерировать хоть по значениям, хоть по ключам, хоть по их сумме — всё зависит от того, что вы хотите сделать.
В PHP, как уже было сказано, нет отдельного типа для массивов, хешей, словарей и т.д. Есть просто массивы. Для них всё сработает предсказуемо.
Если вы хотите какую-то более сложную структуру, можно создать класс-имплементацию итератора, который будет итерировать хоть по значениям, хоть по ключам, хоть по их сумме — всё зависит от того, что вы хотите сделать.
+1
не является ли естественным, что строка — это массив символов?
implode с этим итератором будет работать?
implode с этим итератором будет работать?
0
Является. Не очевидно, что при передачи строки «abc» в такую функцию в результате будет список из трёх элементов. Да, вы можете такое сделать, но поддерживать такое неочевидное поведение может потом оказаться накладно. в этом плане подход PHP мне больше импонирует — нужно сделать такую итерацию — лучше явно передать массив символов. если это часто используется — можно сделать класс, который умеет делать .toString() к той же самой строке, но за счёт имлементации итератора его можно использовать как аргумент подобной функции.
+1
>>>Не очевидно, что при передачи строки «abc» в такую функцию в результате будет список из трёх элементов.
Почему? Если вы согласились, что строка концептуально — массив символов, то почму передача такого массива в функцию, которая представляет последовательность в виде списка, не должна преставить эту конкретну последовательность в виде html списка? По-моему это логично, абстрактно и мощно
Почему? Если вы согласились, что строка концептуально — массив символов, то почму передача такого массива в функцию, которая представляет последовательность в виде списка, не должна преставить эту конкретну последовательность в виде html списка? По-моему это логично, абстрактно и мощно
0
Это, конечно, мощно… Но часто ли используется, особенно в применении к Web? Так что не думаю что это хороший пример того, почему питон сильно лучше.
0
Я думаю, вы просто не смотрели пока на код с этой точки зрения — представьте себе что практически все функции, которые работают с массивами работают и со строками и с последовательностями сгенерированными ORM и другими вещами, которые можно представить как последовательность — и этих функций много (например см. модуль itertools)
+1
Для PHP не является. Это скалярный тип прежде всего, который в некоторых ситуациях может работать как массив. Но не во всех. Далеко не во всех, прежде всего приведение (array)$str (как и любого другого скалярного типа) вернёт массив с одним элементом. Отсюда и пляшем при использовании.
+1
> cработает ли implode со строкой?
Конкретно для вашего примера ваша функция получилась компактнее.
А теперь представьте, что строку не нужно бить по символам.
Как изменится код вашей функции?
Конкретно для вашего примера ваша функция получилась компактнее.
А теперь представьте, что строку не нужно бить по символам.
Как изменится код вашей функции?
0
Не.
С пустым array() будет
С пустым array() будет
<li></li>
0
Не. Ответ не верен, если массив пуст.
0
function make_list($obj){
for($res = ''; $i=each($obj); $res.= "$i[1]");
return $res;
}
for($res = ''; $i=each($obj); $res.= "$i[1]");
return $res;
}
0
А зачем вообще в коде генерировать html?
+1
во-первых, это просто пример. Можно привести в пример itertools и functools как часть того, что можно сделать еще.
во-вторых, можно, например, генерировать интерфейс на основе общих правил, типа «html представление списка объектов — это html представление оъектов, заключенные в li». Чтобы не хардкодить каждую страничу по своему, грубо говоря (ну там придется не зардкодить это li, а обратиться к микрошаблону)
во-вторых, можно, например, генерировать интерфейс на основе общих правил, типа «html представление списка объектов — это html представление оъектов, заключенные в li». Чтобы не хардкодить каждую страничу по своему, грубо говоря (ну там придется не зардкодить это li, а обратиться к микрошаблону)
0
В лоб:
Работает с тем, что можно перечислять: массивы, простые объекты (перечисление свойств) и объекты, реализующие интерфейс Iterator (коллекции, списки и т. п., включая стандартные вроде FilesystemIterator). Строки, увы, скалярный тип в PHP, неперечисляемый, хотя можно добавить
чтобы получить аналогичную функциональность.
Можно написать и в функциональном стиле, но для PHP это скорее извращение будет в данном случае.
function make_list($xs) {
$result = '';
foreach ($xs as $x) {
$result .= '<li>' . $x . '</li>';
}
return $result;
}
Работает с тем, что можно перечислять: массивы, простые объекты (перечисление свойств) и объекты, реализующие интерфейс Iterator (коллекции, списки и т. п., включая стандартные вроде FilesystemIterator). Строки, увы, скалярный тип в PHP, неперечисляемый, хотя можно добавить
if (is_string($xs)) {
$xs = explode('', $xs);
}
чтобы получить аналогичную функциональность.
Можно написать и в функциональном стиле, но для PHP это скорее извращение будет в данном случае.
+2
Насколько я знаю, вы смотрели в сторону python и можете сами сравнить, насколько обобщенный код можно написать там и там — я php смотрел несколько лет назад и то, что я увидел, мне сильно не понравилось.
0
Угу, смотрел, как и в сторону Ruby. Ни один из этих трёх языков не могу назвать идеальным для веба. Вот смешать бы их :)
0
А что вам нравится php как в языке (про дешевый хостинг и большую кодовую базу понятно)
0
Не совсем в языке — простота разворачивания и администрирования среды выполнения для типовых задач (под пакетными дистрами) прежде всего. Хотя, вроде, стало получше с этим у python и ruby в последнее время. Но пока для меня это главный плюс.
Чисто как в языке — тесная интеграция с HTTP, включая сессии. По сути PHP является микрофреймворком для веба.
Чисто как в языке — тесная интеграция с HTTP, включая сессии. По сути PHP является микрофреймворком для веба.
0
>>>Чисто как в языке — тесная интеграция с HTTP, включая сессии
Нужно ли это прям в языке?
Нужно ли это прям в языке?
0
Не мешает при использовании не в вебе, помогает в вебе. Почему нет?
0
Помогает на одну конструкцию import или больше?
-2
Больше, и даже несколько import аналогичной функциональности не дадут.
+1
конечно не дадут аналогичной, ибо дадут БОЛЬШЕ и более качественной функциональности чем в PHP =)
-1
Хорошо, я поясню на примере Perl:
И мы имеем мощнейший шаблонизатор позволяющий хранить шаблоны и в коде (отдельно от кода) и отдельными файлами, поддерживающий наследование, блоки, хелперы и.т.п.
Имеем очень лаконичный sinatra-подобный ДЕКЛАРАТИВНЫЙ роутер (этого в PHP из коробки нет), который поддерживает группы маршрутов, пре- пост- обработчики и.т.п., пример:
Имеем объектно ориентированный способ работать с запросами и ответами, причём тоже очень краткие и лаконичные, например:
И обладает целым пакетом утилит для работы с web проектом и для работы с кодировками, даже есть полноценный клиент и парсер веб страниц (парсер позволяет парсить кусок html css-селекторами).
Поддерживает работу с вебсокетами.
Можно обрабатывать события разнообразные.
Есть поддержка для интернационализации.
Есть поддержка логгирования.
И имеет встроенный веб сервер.
Этот модуль не имеет внешних зависимостей и написан pure-Perl, то есть его можно переносить копированием папочки.
Чем стандартный PHP лучше? Какой ещё модуль надо подключить чтобы получить эту невероятную интеграцию с HTTP?
P.S. по сути это микрофреймворк, только его не надо настраивать и както определённым образом устанавливать — установил модуль, подключил одной строчкой и небольшой или средний сайт напишешь в очень короткие сроки.
use Mojolicious::Lite
И мы имеем мощнейший шаблонизатор позволяющий хранить шаблоны и в коде (отдельно от кода) и отдельными файлами, поддерживающий наследование, блоки, хелперы и.т.п.
Имеем очень лаконичный sinatra-подобный ДЕКЛАРАТИВНЫЙ роутер (этого в PHP из коробки нет), который поддерживает группы маршрутов, пре- пост- обработчики и.т.п., пример:
get '/hello/:name' => {name => 'Sebastian'} => sub {
my $self = shift;
$self->render('groovy', format => 'txt');
};
Имеем объектно ориентированный способ работать с запросами и ответами, причём тоже очень краткие и лаконичные, например:
my $user_agent = $self->req->headers->user_agent;
И обладает целым пакетом утилит для работы с web проектом и для работы с кодировками, даже есть полноценный клиент и парсер веб страниц (парсер позволяет парсить кусок html css-селекторами).
Поддерживает работу с вебсокетами.
Можно обрабатывать события разнообразные.
Есть поддержка для интернационализации.
Есть поддержка логгирования.
И имеет встроенный веб сервер.
Этот модуль не имеет внешних зависимостей и написан pure-Perl, то есть его можно переносить копированием папочки.
Чем стандартный PHP лучше? Какой ещё модуль надо подключить чтобы получить эту невероятную интеграцию с HTTP?
P.S. по сути это микрофреймворк, только его не надо настраивать и както определённым образом устанавливать — установил модуль, подключил одной строчкой и небольшой или средний сайт напишешь в очень короткие сроки.
0
use Mojolicious::Lite и всё? То есть это стандартная библиотека? Может и зря 10+ лет назад, выбирая между Perl и PHP, выбрал последний.
0
Нет это не стандартный модуль, но он легко устанавливается на любой системе с Perl (либо его можно тупо скопировать).
И да, 10 лет назад его не было и да, тогда PHP выглядел намного проще в использовании. Но я про то и говорю, что PHP устарел и развивается не в направлении упрощения кода. При всём при том что Perl старее он из-за своей гибкости постоянно улучшается и это не зависит так сильно от модернизации интерпретатора как у PHP, хотя интерпретатор тоже постоянно модернизируют.
Да и речь шла о том: «можно ли одним модулем в других языках сделать лучше чем в PHP». Да, можно! У руби, я тоже думаю без проблем, а уж питонисты сами расскажут.
И о том: «и является ли интерграция PHP и HTTP конкурентным преимуществом на сегодняшний день?». Нет и из-за того что это встроено в язык, это ещё и отягчающим неудобством можно назвать.
И да, 10 лет назад его не было и да, тогда PHP выглядел намного проще в использовании. Но я про то и говорю, что PHP устарел и развивается не в направлении упрощения кода. При всём при том что Perl старее он из-за своей гибкости постоянно улучшается и это не зависит так сильно от модернизации интерпретатора как у PHP, хотя интерпретатор тоже постоянно модернизируют.
Да и речь шла о том: «можно ли одним модулем в других языках сделать лучше чем в PHP». Да, можно! У руби, я тоже думаю без проблем, а уж питонисты сами расскажут.
И о том: «и является ли интерграция PHP и HTTP конкурентным преимуществом на сегодняшний день?». Нет и из-за того что это встроено в язык, это ещё и отягчающим неудобством можно назвать.
0
В том-то и дело, что это не стандартный модуль. Нет, если его файлы можно скопировать куда-то в /var/www вместе с использующим его проектом, то часть проблем снимается. А если нужны права доступа вне /var/www, то это означает резкий уход с рынка веб-мастеров, не являющихся толком ни администраторами, ни программистами, и инструкция типа «этот каталог из архива разместите в ~/www, а этот — в /usr/local/lib или в другом на выбор и пропишите его в PATH» для них будет неподъёмна.
А в PHP взаимодействие с HTTP-запросами, взаимодействие с веб-сервером — это ядро языка (частично, а частично в либах в функциях вроде header()). Причём, на мой взгляд, это взаимодействие более функционально, чем в стандартных либах python и ruby.
А синатроподобные фреймворки с декларативным роутингом на PHP есть, даже в одном файле (правда phar):
И объектные обвязки для HTTP тоже есть там.
PS А сейчас perl-приложения деплоятся также как 10+лет назад — копируются в /var/www/cgi-bin и работают по cgi, или есть модули типа mod_php, или запускаются как демон?
А в PHP взаимодействие с HTTP-запросами, взаимодействие с веб-сервером — это ядро языка (частично, а частично в либах в функциях вроде header()). Причём, на мой взгляд, это взаимодействие более функционально, чем в стандартных либах python и ruby.
А синатроподобные фреймворки с декларативным роутингом на PHP есть, даже в одном файле (правда phar):
require_once 'silex.phar';
$app = new Silex\Application();
$app->get('/hello/{name}', function($name) {
return "Hello $name";
});
$app->run();
И объектные обвязки для HTTP тоже есть там.
PS А сейчас perl-приложения деплоятся также как 10+лет назад — копируются в /var/www/cgi-bin и работают по cgi, или есть модули типа mod_php, или запускаются как демон?
0
Его можно скопировать в папку с проектом и всё будет работать.
Про «ядро языка», я не вижу никакого смысла в интеграции в язык, ни в плане производительности, ни в плане удобства. Ибо там идёт работа только со строками, потому про какую то супероптимизацию сложно говорить. В любых фреймворках на любых языках идёт логичное и удобное разделение понятий запроса и ответа и на мой взгляд это удобнее и понятнее чем набор разношёрстных функций в комментариях к которым выложена куча «велосипедов» и комментариев почему надо пользоваться именно этими велосипедами. Да и интерфейсы и способы работы с запросами в модулях оптимизируют для удобства постоянно, а вот встроенные в язык ОЧЕНЬ сложно упрощать и улучшать.
Про silex я знаю, но пока не смотрел подробнее. Я не говорю что их нет, я говорю про то что сделано не очень удобно из-за недостаточной гибкости PHP.
Сайты на Perl (да и для PHP) у меня работают через FastCGI. Деплою и то и другое я тупо git'ом, ибо это удобно. Так что здесь какого-то преимущества у PHP я не вижу.
Про «ядро языка», я не вижу никакого смысла в интеграции в язык, ни в плане производительности, ни в плане удобства. Ибо там идёт работа только со строками, потому про какую то супероптимизацию сложно говорить. В любых фреймворках на любых языках идёт логичное и удобное разделение понятий запроса и ответа и на мой взгляд это удобнее и понятнее чем набор разношёрстных функций в комментариях к которым выложена куча «велосипедов» и комментариев почему надо пользоваться именно этими велосипедами. Да и интерфейсы и способы работы с запросами в модулях оптимизируют для удобства постоянно, а вот встроенные в язык ОЧЕНЬ сложно упрощать и улучшать.
Про silex я знаю, но пока не смотрел подробнее. Я не говорю что их нет, я говорю про то что сделано не очень удобно из-за недостаточной гибкости PHP.
Сайты на Perl (да и для PHP) у меня работают через FastCGI. Деплою и то и другое я тупо git'ом, ибо это удобно. Так что здесь какого-то преимущества у PHP я не вижу.
0
Так для PHP тоже куча фреймворков, которые инкапсулируют запросы и ответы с постоянно модернизируемыми интерфейсами. Но если возникает желание или необходимость писать без фреймворков и сторонних либ, то в PHP они есть в ядре, а в других языках нет, в лучшем случае надо стандартные либы подключать, в худших — сокеты слушать. Грубо говоря, есть встроенный в ядро уровень абстракции выше чем raw http, пользоваться им или использовать более высокоуровневые (свои или чужие) — выбор исполнителя и заказчика.
К слову, работу с HTTP и сессиями я обернул в классы как только стал доступен широко на хостингах PHP4 (мой мозг безнадежно, наверное, испорчен «Си с классами», ещё Фортом немного, но это не мэйнстрим и проявляется редко). Почему-то ждал, что в сначала 5.0, а потом в 6.0 это сделают разработчики PHP. Но у них другие приоритеты, видимо :( Восторга от PHP не испытываю давно (после выхода из эйфории по поводу появления ООП в PHP4), просто рабочий инструмент, который изменяется, не всегда однозначно хорошо, вернее почти всегда в духе php — говорят «а», но не говорят «б», например:
— вводят ООП, но подавляющее большинство библиотеки — процедурные, про «всё — объект» вообще молчу
— вводя нэймспэйсы, но стандартные библиотеки по ним не распихивают
— вводят type hinting, но не для скалярных типов и возвращаемых результатов вообще.
— вводят анонимные функции и замыкания, но опять как-то не полноценно
Я понимаю, что BC и т. п. и, наверное, очень сложно сделать, например,
К слову, работу с HTTP и сессиями я обернул в классы как только стал доступен широко на хостингах PHP4 (мой мозг безнадежно, наверное, испорчен «Си с классами», ещё Фортом немного, но это не мэйнстрим и проявляется редко). Почему-то ждал, что в сначала 5.0, а потом в 6.0 это сделают разработчики PHP. Но у них другие приоритеты, видимо :( Восторга от PHP не испытываю давно (после выхода из эйфории по поводу появления ООП в PHP4), просто рабочий инструмент, который изменяется, не всегда однозначно хорошо, вернее почти всегда в духе php — говорят «а», но не говорят «б», например:
— вводят ООП, но подавляющее большинство библиотеки — процедурные, про «всё — объект» вообще молчу
— вводя нэймспэйсы, но стандартные библиотеки по ним не распихивают
— вводят type hinting, но не для скалярных типов и возвращаемых результатов вообще.
— вводят анонимные функции и замыкания, но опять как-то не полноценно
Я понимаю, что BC и т. п. и, наверное, очень сложно сделать, например,
[1,2,3].walk |$item| { ... }
вместо array_walk(array(1,2,3), function($item) { ... })
, но восторгов это не добавляет.0
А можете на примере — я прочитал введения и не обнарузил ничего что нельзя было бы сделать средствами языка типа питона — что я проглядел?
0
Может я проглядел встроенный в питон механизм сессий с возможностью в конфиге задавать способ хранения (из зарегистрированных в расширениях, как минимум в файлах и sql)?
0
Я не про наличие стандартной библиотеки, про решение включить это в сам язык — то есть вы имели ввиду поддержку сессий из коробки или поддержку сессий в синтаксисе и семантике-именно языка (в отличие от стандартной библиотеки или внешних библиотек)?
0
Библиотеки, функции, классы, «недублирование кода» — это скилл разработчика, а не фича языка.
+1
в языке должны быть механизмы для запасания кода.
0
Что это за термин такой новый? Раскройте что это за механизм такой есть в одном языке и нет в другом?
+2
Это образное выражение. Предствьте себе, что у вас язык где нету функций — как не дублировать код, например на брейнфаке?
По поводу питона и пхп, попробуйте посмотреть на комментарий habrahabr.ru/post/142342/#comment_4764012 и написать такую же функцию, но на PHP. Если захочется поииследовать как работает — можно сходить на www.trypython.org/#
По поводу питона и пхп, попробуйте посмотреть на комментарий habrahabr.ru/post/142342/#comment_4764012 и написать такую же функцию, но на PHP. Если захочется поииследовать как работает — можно сходить на www.trypython.org/#
-5
Представьте, что в PHP есть функции, и я написал ту функцию, о которой Вы говорите. Дальше что, кроме того, что мы получим две бесполезные функции на разных языках?
+3
Написал, что дальше? Вас пугает что она на пару строк длиннее?
А меня больше пугает что вы такой код пишите на чистом Питоне, вместо того чтобы в шаблоне его писать. И не нужно говорить, что это просто пример :)
А меня больше пугает что вы такой код пишите на чистом Питоне, вместо того чтобы в шаблоне его писать. И не нужно говорить, что это просто пример :)
+1
>Если уж реально надо получить прирост скорости (5-10 раз) — тогда на джаву смотреть надо.
если надо ускориться — берем профайлер, ищем горячие точки и переписываем в виде модуля наC/C++
если надо ускориться — берем профайлер, ищем горячие точки и переписываем в виде модуля наC/C++
0
Отлично обстоят, сам делал систему для банкострахования, заказчики в восторге так как с ней оборот вырос на порядок.
+4
а этого человека волнуют дыры в его интернет-магазине? когда его сломают через дыру в жумле/её плагине и уведут персональные данные клиентов. 152 ФЗ не дремлет.
0
А что, использование python/ruby/perl/js/… даёт автоматические гарантии отсутствия дыр? Особенно если писать в «cgi режиме» или свой сервер с ноля, а не пользоваться наработками сообщества?
0
ммм… свой сервер «с ноля»? ок. покажете веб-сервер на php, отдающий статику через sendfile() и обрабатывающий события через epoll()?
Насчёт безопасности я уже писал: php — единственный проект, в котором офицер безопасности отчаялся исправлять дыры и устроил террор, публикуя каждую неделю по новой критической уязвимости.
Посмотрим, что говорит secunia:
ruby 1.8
python 2.5
python 2.6
php 5.0
php 5.1
php 5.2
php 5.3
joomla 1.x
drupal 6.x
drupal 7.x
Насчёт безопасности я уже писал: php — единственный проект, в котором офицер безопасности отчаялся исправлять дыры и устроил террор, публикуя каждую неделю по новой критической уязвимости.
Посмотрим, что говорит secunia:
ruby 1.8
python 2.5
python 2.6
php 5.0
php 5.1
php 5.2
php 5.3
joomla 1.x
drupal 6.x
drupal 7.x
0
А зачем мне его писать если есть mod_php и fpm из коробки? Пускай будет приложение python+wsgi или ruby+rack (хотя и не совсем корректно такое сравнение, вроде. Сильно безопаснее оно будет, если я его начну писать? Будет автоматически экранировать вывод и SQL-запросы, вставлять токены в формы и анализировать их наличие и корректность в обработчиках?
И что мне это «говорение» должно сказать без цифр и пояснений? Тем более, что, афаик, подавляющее большинство взломов сайтов происходит путем эксплуатаций уязвимостей кода, а не самого ЯП.
И что мне это «говорение» должно сказать без цифр и пояснений? Тем более, что, афаик, подавляющее большинство взломов сайтов происходит путем эксплуатаций уязвимостей кода, а не самого ЯП.
0
простите, а какие sql запросы? где ORM?
>Тем более, что, афаик, подавляющее большинство взломов сайтов происходит путем эксплуатаций уязвимостей кода, а не самого ЯП.
это цена за «интегрированность HTTP в php».
php 5.0:
SA24505 — PHP Session Handling Double Free Vulnerabilities(
SA22653 — PHP «htmlentities()» and «htmlspecialchars()» Buffer Overflows ( Highly critical)
полный список secunia.com/advisories/product/3919/?task=advisories
php 5.1:
secunia.com/advisories/product/6796/?task=advisories
php 5.2:
secunia.com/advisories/product/13446/?task=advisories
php 5.3:
secunia.com/advisories/product/27504/?task=advisories
SA47806 — PHP «php_register_variable_ex()» Code Execution Vulnerability
вообще няшно: Highly critical, System access, From remote
Джумлу, друпал, вордпресс, джангу, руби и питон найти там легко.
>Тем более, что, афаик, подавляющее большинство взломов сайтов происходит путем эксплуатаций уязвимостей кода, а не самого ЯП.
это цена за «интегрированность HTTP в php».
php 5.0:
SA24505 — PHP Session Handling Double Free Vulnerabilities(
SA22653 — PHP «htmlentities()» and «htmlspecialchars()» Buffer Overflows ( Highly critical)
полный список secunia.com/advisories/product/3919/?task=advisories
php 5.1:
secunia.com/advisories/product/6796/?task=advisories
php 5.2:
secunia.com/advisories/product/13446/?task=advisories
php 5.3:
secunia.com/advisories/product/27504/?task=advisories
SA47806 — PHP «php_register_variable_ex()» Code Execution Vulnerability
вообще няшно: Highly critical, System access, From remote
Джумлу, друпал, вордпресс, джангу, руби и питон найти там легко.
0
Какая ORM? Я же пишу с нуля, не пользуясь сторонними разработками, только стандартными биндингами к MySQL API. Не, я конечно, напишу свою ORM (уж больно нравится мне ООП), но, почему-то кажется, что оставлю я или нет возможность sqlinj от языка на котором писать буду никак не зависит.
Уязвимости есть везде где не глянул, в PHP 5.3.x и Drupal 7 не нашёл Extremely, а php_register_variable_ex() на хабре уже обсуждали — довольно сложная атака должна быть, рабочего эксплоита вроде нет
Уязвимости есть везде где не глянул, в PHP 5.3.x и Drupal 7 не нашёл Extremely, а php_register_variable_ex() на хабре уже обсуждали — довольно сложная атака должна быть, рабочего эксплоита вроде нет
0
>>>что оставлю я или нет возможность sqlinj от языка на котором писать буду никак не зависит.
если система типов позволяет, то можно сильно себе облегчить защиту от SQL injection.
если система типов позволяет, то можно сильно себе облегчить защиту от SQL injection.
0
PHP более популярен, поэтому в нем больше находят уязвимостей.
Вы с этим комментом про секюрити вообще не в тему вылезли.
Вспомним недавний взлом Github'а (коммит в RoR) — там была дыра, которую им просто лень было закрывать, пока их не поломали.
«В личном блоге Егор написал, что обнаруженная им уязвимость позволяет делать pull/commit/push в любом репозитории на Github. Свой поступок он объяснил раздражением от того, что мейнтейнеры Rails игнорировали баг, о котором он сообщил, и поэтому Егор теперь решил протестировать его на первом попавшемся проекте.»
Вы с этим комментом про секюрити вообще не в тему вылезли.
Вспомним недавний взлом Github'а (коммит в RoR) — там была дыра, которую им просто лень было закрывать, пока их не поломали.
«В личном блоге Егор написал, что обнаруженная им уязвимость позволяет делать pull/commit/push в любом репозитории на Github. Свой поступок он объяснил раздражением от того, что мейнтейнеры Rails игнорировали баг, о котором он сообщил, и поэтому Егор теперь решил протестировать его на первом попавшемся проекте.»
0
Викимедиа подходит? Или, например, Фейсбук?
Цукеберг передает привет с собственного острова за пару десятков миллионов.
Цукеберг передает привет с собственного острова за пару десятков миллионов.
+1
Уж очень субъективные у Вас ответы. Вы анализировали количество фреймворков в ruby\python? Да и количество программистов не говорит об их качестве. Придет к вам 28 миллионов программистов пхп, но на деле лишь пару процентов окажется действительно программистами, а остальные лишь кодерами, которые «фейсбук» вам не сделают. Python\ruby — более высокий порог вхождения и потому программистов меньше, но их качество выше, а значит выбирать легче. Правда с выводом статьи я согласен. Делал высоконагруженные проекты как на php, так и на python (на ruby не довелось). Мой выбор — php. Да и узкие места при высоких нагрузках вовсе не в написанном на php\python\ruby коде возникают, а в запросах к базам данных.
+7
Почему php? Действительно ведь в плане нагрузки разница минимальная должна быть между языками, т.к. узкое место это I\O к БД.
0
Это чисто субъективное мнение. Боюсь его здесь высказывать, дабы не навлечь на себя гнев python'истов, но раз вы спросили. Python радует простотой и элегантностью синтаксиса… но только до определенного периода. Django мне показался набором каких-то неведомых костылей, а сам фреймворк держит в жестких рамках, предоставляя довольно низкий уровень абстракции по сравнению с yii, например. У php же фреймворки более обобщенные. yii и zf просто дают набор классов и рекомендации, а разработчик делает с ними что хочет. Да и сиподобный синтаксис мне ближе. За 2 года использования питона мне все также кажется нелепым контролировать отступы (хотя все меня убеждали, что это невероятно крутая фишка). Опять же я не могу говорить за все фреймворки и нюансы языка, так как я их просто не знаю (ни php, ни python), но те задачи, с которыми я сталкивался мне было проще решить на php, а, как вы заметили, разница в производительности на продакшене между ними минимальна.
+10
Тоже никак не могу понять «крутости» отступов. Зачем вообще к этому привязываться в языке…
+10
Ничего, со временем догонишь какую роль имеет читаемость кода.
-3
ИМХО Читаемость кода не должна быть завязана в синтаксисе языка.
+9
Почему?
+1
А кто вам сказал, что делая такие отступы код становится читаем? Мне удобнее читать, когда кроме отступов я вижу начало { и конец } блока.
+5
Унификация физульаного языка делает код читаемее. О том, что отступы более наглядны чем скобочки свидетельствует то, что
— в тех языках где можно обойтись скобочками все равно делают отступы
— периодически сталкиваюсь с тем, что если по ошибке отступ сделан неправильно, я читаю его а не скобочки, не смотря на то, что у меня большая привычка к и подобному синтаксису.
Человек читает прежде всего отступы (иначе бы их не делали). Скобочки дублируют отступы и надо проверять, что скобочки правильно их дублируют.
Как-то раз на 1 апреля Гвидо ван Россум написал, что со следующей версии языка в компиляторе будет забит отступ 4 пробела и при его несоблюдении будет ошибка компиляции.
С моей точки зрения такая штука должна быть, так как заставляет соблюдать единый стандарт по всему языку — в нормальных командах поверх языка еще есть нечто вроде StyleCop который не дает зачекинить код, не отвечающий принятому в команде стилю. В данном случае, я был бы не против, если бы StypeCop был бы в самом языке.
— в тех языках где можно обойтись скобочками все равно делают отступы
— периодически сталкиваюсь с тем, что если по ошибке отступ сделан неправильно, я читаю его а не скобочки, не смотря на то, что у меня большая привычка к и подобному синтаксису.
Человек читает прежде всего отступы (иначе бы их не делали). Скобочки дублируют отступы и надо проверять, что скобочки правильно их дублируют.
Как-то раз на 1 апреля Гвидо ван Россум написал, что со следующей версии языка в компиляторе будет забит отступ 4 пробела и при его несоблюдении будет ошибка компиляции.
С моей точки зрения такая штука должна быть, так как заставляет соблюдать единый стандарт по всему языку — в нормальных командах поверх языка еще есть нечто вроде StyleCop который не дает зачекинить код, не отвечающий принятому в команде стилю. В данном случае, я был бы не против, если бы StypeCop был бы в самом языке.
+6
Ладно, если вам трудно понять идею из текста, то скажу прямым текстом: мне не нравится, что разработчики за меня решили какой код будет читаем, а какой нет. Мне трудно беглым взглядом найти конец блока например если идет:
А теперь представьте, что это все еще смещено на пару вложенностей. Мне уже даже сейчас не хочется воспринимать последний if вне функции. А будь там конец блока } или end, мне было бы удобно. Но питонисты утверждают, что нужно просто всех переделать под себя.
def asd():
blablabla
blablabla2
if True:
blablabla3
if True:
blablabla4
if False:
blablabla5
А теперь представьте, что это все еще смещено на пару вложенностей. Мне уже даже сейчас не хочется воспринимать последний if вне функции. А будь там конец блока } или end, мне было бы удобно. Но питонисты утверждают, что нужно просто всех переделать под себя.
+10
Не нужно никого переделывать, но использование отступов — крайне желаемая и общепринятая конвенция во всех языках.
Что касается структур begin->end, с ними не без плюсов в виде чуть более явной вложенности и не без минусов — вертикальное, (т.е. самое ценное) место место сильнее расходуется.
И без конвенций скобки можно перепутать, сносить и размещать так, что у любого мозг вывихнет (привет js и lisp). Плюс есть стандартная ошибка отсутствия выделения begin-end одной строки, потом к ней дописывается еще одна, не попадающая в тело вызова и мы получаем ошибку, которую хрен найдешь.
Условный пример кода не очень показателен и действительно меня смутил, хотя реальный код меня ни разу не смущал подобным образом, немного визуальные паттерны другие. Ну и после метода/функции ему второй пустой строки не хватает, в пепах это прописано.
Что касается структур begin->end, с ними не без плюсов в виде чуть более явной вложенности и не без минусов — вертикальное, (т.е. самое ценное) место место сильнее расходуется.
И без конвенций скобки можно перепутать, сносить и размещать так, что у любого мозг вывихнет (привет js и lisp). Плюс есть стандартная ошибка отсутствия выделения begin-end одной строки, потом к ней дописывается еще одна, не попадающая в тело вызова и мы получаем ошибку, которую хрен найдешь.
Условный пример кода не очень показателен и действительно меня смутил, хотя реальный код меня ни разу не смущал подобным образом, немного визуальные паттерны другие. Ну и после метода/функции ему второй пустой строки не хватает, в пепах это прописано.
0
Вы не забывайте, что пустые строки я могу расставлять и в теле функции, например для отделения смысловых действий. Т.е. мне нужно будет делать 1 отступ в теле и 2 после функции. Где здесь экономия места по сравнению с begin\end? На отступы никто не посягает ) Просто как видно в данном примере без них хуже, чем с ними. И я реально видел такой код. Почему кстати он не очень показательный? Я определил функцию и потом начался основной код (кстати, я не могу вынести функцию в конец файла, что было бы опять же удобней.)
0
Всё познаётся в сравнении:
Лучше не стало.
И, кстати, вот такую ошибку в PHP визуально сложно отловить:
Только вбивание в голову привычки ставить скобки всегда. А после питона их обилие раздражает.
def asd(){
blablabla
blablabla2
if True{
blablabla3
if True{
blablabla4
}
}
}
Лучше не стало.
И, кстати, вот такую ошибку в PHP визуально сложно отловить:
<?php
function my(){
if (true)
do_something();
do_another();
}
?>
Только вбивание в голову привычки ставить скобки всегда. А после питона их обилие раздражает.
0
Для меня стало лучше. Теперь если за блоком пойдет другой код я сразу по скобке увижу, что он не в теле функции.
А ошибка в пхп… А вам не кажется, что нотификация zend не зря рекомендует так не делать? Если бы Вы здесь поставили скобки, то код читался бы прекрасно. А вот в питоне:
Мне кажется хуже
А ошибка в пхп… А вам не кажется, что нотификация zend не зря рекомендует так не делать? Если бы Вы здесь поставили скобки, то код читался бы прекрасно. А вот в питоне:
def my():
if True:
do_something()
do_another()
Мне кажется хуже
+3
И не только в zend. Меня больше удивляет, что скобки не являются обязательными для IF, аналогично FUNCTION.
Ну а по-поводу скобки vs отступы — у нас просто разные вкусы/взгляды. А спорить о вкусах — дело пустое.
Ну а по-поводу скобки vs отступы — у нас просто разные вкусы/взгляды. А спорить о вкусах — дело пустое.
0
Ничего не хочу сказать против Вас, но мне легко найти. Возможно это просто опыт/привычка?
0
Я видел как на питоне умудряются написать такое ничитаемое г, что хотелось выколоть себе глаза. Поэтому при определенной «квалификации» и энтузиазме можно наговнокодить и в питоне с его супер крутым читаемым синтаксисом )
+5
Меня вот больше бесит отсутствие некоего 'end'а для оформления окончания блока, чтобы текстовые редакторы могли понимать где и сколько отступов надо вставить. Прям выносит мозг при рефакторинге долбить в таб, переключая уровни отступа в емаксе. В руби как раз end был добавлен только по причине что автор языка использовал емакс и понимал насколько это удобно.
+7
Не могли бы вы пока зать на примере? Почему редактор, грубо, говоря не может сам держать в уме все эти begin и end — они же однозначно выводятся из отступов?
-2
а какое должно быть поведение у редактора при нажатии кнопки «сделать правильный отступ для этой строки», если с помощью отступов определяются блоки. Поэтому при нажатии на эту кнопку, редактор начинает переключаться по всевозможным блокам и предлагать различные варианты. А в случае когда блок определяется явными begin/end, то у редактора не возникает никаких проблем выставить нужный отступ при первом же нажатии.
0
//«сделать правильный отступ для этой строки», если с помощью отступов определяются блоки
сделать такой же отступ как и у предыдущей строки.
сделать такой же отступ как и у предыдущей строки.
0
Емакс при первом нажатии предлагает использовать предыдущий блок, при последующих нажатиях начинает прыгать по блокам. И это наиболее разумное решение, которое можно сделать в такой ситуации.
Но вот так сложилось, что я часто занимаюсь рефакторингом и тут сразу проявляется проблема с тем как редактор выставляет отступы, тк например очень часто приходится перемещать строки кода не в конец текущего блока, а за его пределами, но редактор не может этого знать, тк нет явных границ блоков.
Вобщем это тяжело описать словами, очень хорошо это чувствуется в редакторах с умным индентом и после нескольких лет работы с языками, в которых были явные отступы и неявные. Да, спустя много времени это не доставляет какого-то дискомфорта, но я понимаю что еслиб были явные границы, то работать с кодом было бы удобнее.
Но вот так сложилось, что я часто занимаюсь рефакторингом и тут сразу проявляется проблема с тем как редактор выставляет отступы, тк например очень часто приходится перемещать строки кода не в конец текущего блока, а за его пределами, но редактор не может этого знать, тк нет явных границ блоков.
Вобщем это тяжело описать словами, очень хорошо это чувствуется в редакторах с умным индентом и после нескольких лет работы с языками, в которых были явные отступы и неявные. Да, спустя много времени это не доставляет какого-то дискомфорта, но я понимаю что еслиб были явные границы, то работать с кодом было бы удобнее.
0
> но редактор не может этого знать, тк нет явных границ блоков.
Редактор может определять необходимую вложенность для следующей строки по формальным признакам выхода из блока — return, except, raise, else, eleif.
Редактор может определять необходимую вложенность для следующей строки по формальным признакам выхода из блока — return, except, raise, else, eleif.
0
except, raise, else, eleif — это всё как бы начало блока ;)
А после return'а емакс определяет конец блока и не прыгает дальше чем нужно.
А после return'а емакс определяет конец блока и не прыгает дальше чем нужно.
0
return и raise конечно же :)
0
Это не только индикаторы начала блока, но и индикаторы окончания вложенности предыдущего блока.
Когда внутри try вы пишите except — редактор может понять, что необходимо выйти за границы блока try. То же самое с else и elif.
raise — индикатор завершения либо всей функции, либо блока, в котором определен ближайший except, ловящий текущий raise.
Когда внутри try вы пишите except — редактор может понять, что необходимо выйти за границы блока try. То же самое с else и elif.
raise — индикатор завершения либо всей функции, либо блока, в котором определен ближайший except, ловящий текущий raise.
0
Попробуйте PyCharm. Он с отступами в Питоне нормально работает.
+3
но на деле лишь пару процентов окажется действительно программистами
А чего Вы решили что среди программеров Руби/Питона прям все сплошные гении? :) Как будто если человек пишет на ООП, то он типа не может написать говнокод :)
+14
Я, почему-то, не вижу сильного различия в пороге вхождения php и python. Уж если бы я отдал питону 3 года своей жизни, не думаю что я бы знал его хуже чем php за тот же период.
+2
Я говорю о другой величине. К примеру через сколько вы сможете начать писать что-то адекватное на php и на python. Не знаю как у вас, но втянуться в php с нуля у меня получилось за 3 месяца где-то написания своего велосепеда. С python у меня было все менее успешно, хотя к тому моменту я уже имел опыт программирования. Да и каждый человек индивидуален. Я ведь указал, что это относится только ко мне, так же как и то, что написал автор относится только к нему.
+1
Адекватность программ зависит ои мозгов программиста. Если у человека есть талант он будет на любом языке нормально писать. А нет, так будет на любую элементарную ошибку бежать в форумы
+1
Ну ведь здесь речь было немного о другом. Посмотрите сколько сейчас открылось студий веб-дизайна. Я успел поработать в 3 таких. Большинство «программистов» там — студенты, написавшие «форум с нуля на php» и считающие себя крутыми спецами. А потом они приходят в «фейбук» и говорят: «я крут, давайте мне з\п побольше». Несомненно и на php есть выдающиеся специалисты. Просто процент кодеров на php выше, мне кажется.
+1
Не могли бы вы проанализировать какие особенности питона вам помешали?
+5
Ну тут уже почти все это упоминалось, но повторю:
1. Неудобное использование ООП. Таскать за собой self по всем методам (не знаю больше ни одного языка. где сделан такой же маразм. Что помешало в питоне сделать по-человечески — не понимаю).
2. Неудобочитаемость кода, когда я вижу кучу отступов, но не вижу четкого конца блока. Кто-то от этого приходит в восторг, но меня такой код угнетает.
3. Нет возможности внести изменения и сразу их увидеть. Приходится постоянно делать лишние операции.
4. Нет адекватного фреймворка. Вернее даже не так. Из тех популярных решений, которые я пытался использовать меня ни одно не устроило.
Возможно покажется, что какие-то слабые недостатки, но так как на продакшене скорость ЯП не имеет огромного значения, я выбираю чуть более высокий уровень удобства.
1. Неудобное использование ООП. Таскать за собой self по всем методам (не знаю больше ни одного языка. где сделан такой же маразм. Что помешало в питоне сделать по-человечески — не понимаю).
2. Неудобочитаемость кода, когда я вижу кучу отступов, но не вижу четкого конца блока. Кто-то от этого приходит в восторг, но меня такой код угнетает.
3. Нет возможности внести изменения и сразу их увидеть. Приходится постоянно делать лишние операции.
4. Нет адекватного фреймворка. Вернее даже не так. Из тех популярных решений, которые я пытался использовать меня ни одно не устроило.
Возможно покажется, что какие-то слабые недостатки, но так как на продакшене скорость ЯП не имеет огромного значения, я выбираю чуть более высокий уровень удобства.
+4
1. Кроме использования self ничего не напрягло? Не увидели ли вы в питоне что все является объектом, что интерфейсы объектов унифицированны и вы можете у себя воспроизвести полностью интерфейс строки и большая часть кода работающая со строками будет работать и с вашим объектом?
2. Я даже в обычных языках вижу прежде всего переход отступа, а потом мне приходится проверять себя выискивая скобочки.
>>>Возможно покажется, что какие-то слабые недостатки, но так как на продакшене скорость ЯП не имеет огромного значения, я выбираю чуть более высокий уровень удобства.
Не могло ли так получиться, что вы стали жертой блаб-парадокса: те возможности которые есть в вашем любимом языке — это и так понятно; tо, что неудобнее чем в вашем любимом языке — это недостаток; то чего нет в вашем любимом языке — просто невидимо/непонятно зачем?
2. Я даже в обычных языках вижу прежде всего переход отступа, а потом мне приходится проверять себя выискивая скобочки.
>>>Возможно покажется, что какие-то слабые недостатки, но так как на продакшене скорость ЯП не имеет огромного значения, я выбираю чуть более высокий уровень удобства.
Не могло ли так получиться, что вы стали жертой блаб-парадокса: те возможности которые есть в вашем любимом языке — это и так понятно; tо, что неудобнее чем в вашем любимом языке — это недостаток; то чего нет в вашем любимом языке — просто невидимо/непонятно зачем?
0
1. И часто в ваших проектах Вам это пригождалось? ) Мне нет, поэтому и не обратил внимание, хотя сам факт существования возможности знаю
2. Вы. Ключевое слово Вы. Почему никто не видет, что каждый человек индивидуален? Вы выискиваете отступы. Я если честно тоже, но без скобочек отступы мне трудно воспринимать. Я в php тоже делаю всегда отступы, но скобочки меня не напрягает ставить. Потому что так мне понятней.
Кто сказал что php мой любимый язык? Просто мы рассматриваем веб. Для веба — пхп мне кажется наиболее разумным. Питонисты любят приводить в достоинства питона всякие фичи (типа как вы с объектами), но согласитесь, что эти возможности очень редко используются в реальных проектах. А фича ради фичи мне не нужна. (приведите пример реального проекта, где python сделал бы что-то такое, чего не смог бы php)
И не пытайтесь переделать всех под себя. Не стали ли вы жертвой этого вашего блаб-парадокса? (первый раз услышал такое понятие)
2. Вы. Ключевое слово Вы. Почему никто не видет, что каждый человек индивидуален? Вы выискиваете отступы. Я если честно тоже, но без скобочек отступы мне трудно воспринимать. Я в php тоже делаю всегда отступы, но скобочки меня не напрягает ставить. Потому что так мне понятней.
Кто сказал что php мой любимый язык? Просто мы рассматриваем веб. Для веба — пхп мне кажется наиболее разумным. Питонисты любят приводить в достоинства питона всякие фичи (типа как вы с объектами), но согласитесь, что эти возможности очень редко используются в реальных проектах. А фича ради фичи мне не нужна. (приведите пример реального проекта, где python сделал бы что-то такое, чего не смог бы php)
И не пытайтесь переделать всех под себя. Не стали ли вы жертвой этого вашего блаб-парадокса? (первый раз услышал такое понятие)
+4
>(приведите пример реального проекта, где python сделал бы что-то такое, чего не смог бы php)
Ну тут важно насколько элегантно сделано. Наглядный пример — это убогие ОРМки в php.
Ну тут важно насколько элегантно сделано. Наглядный пример — это убогие ОРМки в php.
-2
Обогие ОРМ? Чем же они убоги? ) Вы все ОРМ на php перепробовали? А на питоне? Думаете там меньше убогости? И Вы не привели пример. Скорее всего, потому что его нет. А убогость кода связана не с языком, а программистом )
+3
Ну возьмём наиболее популярные решения Doctrine/Propel(php), SQLAlchemy(python).
и вспоминаем то что вам ненравится :)
>Нет возможности внести изменения и сразу их увидеть.
и вспоминаем то что вам ненравится :)
>Нет возможности внести изменения и сразу их увидеть.
+1
По сути между ними разница минимальна в плане возможностей. Ну Вы не поверите: я не использую Doctrine. А знаете почему? Мне кажется он неудобным. Я не могу многого рассказать про него, так как попробовав раз я понял, что это монстр, который на продакшене пускать не стоит. Да и любая ОРМ — лишние запросы в БД. Хотя бы тот же describe. Я предпочитаю Pdo + обыкновенный sql
-4
Ну мы же не обсуждаем ваши предпочтения.
А про использование/создание инструментов, которые часто используются в веб деве. Для создания dsl'ей тут как бы и питон всосёт, если начинать демонстрировать RSpec, сделаный на руби. Но ОРМки с компиляторами на пхп — это вообще из разряда какого-то геморроя. Ладно там на Java/C++ я плачу удобством за высокую производительность, но php/ruby/python — это все тормозные язычки, где я в последнюю очередь думаю о производительности, а в первую — это удобство использования.
А про использование/создание инструментов, которые часто используются в веб деве. Для создания dsl'ей тут как бы и питон всосёт, если начинать демонстрировать RSpec, сделаный на руби. Но ОРМки с компиляторами на пхп — это вообще из разряда какого-то геморроя. Ладно там на Java/C++ я плачу удобством за высокую производительность, но php/ruby/python — это все тормозные язычки, где я в последнюю очередь думаю о производительности, а в первую — это удобство использования.
0
Разве? А по-моему я уже не раз писал, что выбор языка — сугубо личное и так как между ними нет особой разницы, то каждый выбирает то, что удобно именно ему. Я конечно понимаю, что холивар разжигает огонь в душах, но неужели так трудно понять, что питон ни чем не лучше и не хуже пхп (можете взять другие интерпретируемые языки). Тут дело в том, что мне удобней. Так почему вы пытаетесь меня убедить, что питон мне удобней, если я попробовал и это оказалось не так.
0
Когда у вас появляется нагрузка, которую нужно оптимизировать — любая ORM/AR становится убогой. Потому что оно не способно сгенерировать запрос, который может написать человек руками.
К примеру довольно не редко на сложных выборках эффективно использовать derived queries для отфильтровывания лишнего и только потом джойнить данные. Покажите мне хоть одну ORM которая это сделает за меня? Ниодной, потому что это уже не ООП — раз, а два — имея конкретную базу данных я могу использовать её особенности и дополнительный функционал: это может сократить время запроса на порядок, а то и 2-3 порядка; в спечефичных случаях иногда и в сотни раз.
Так что вы уж извините, но тут всё сильно зависит от конкретной задачи и рабочего окружения. Все эти ваши ORM работают пока у вас шаблонный функционал.
К примеру довольно не редко на сложных выборках эффективно использовать derived queries для отфильтровывания лишнего и только потом джойнить данные. Покажите мне хоть одну ORM которая это сделает за меня? Ниодной, потому что это уже не ООП — раз, а два — имея конкретную базу данных я могу использовать её особенности и дополнительный функционал: это может сократить время запроса на порядок, а то и 2-3 порядка; в спечефичных случаях иногда и в сотни раз.
Так что вы уж извините, но тут всё сильно зависит от конкретной задачи и рабочего окружения. Все эти ваши ORM работают пока у вас шаблонный функционал.
0
А если использовать ORM без функциональности DBAL? Запросы писать ручками, а средствами ORM только приводить их результаты/аргументы к модели?
0
Когда у вас появляется нагрузка, которую нужно оптимизировать — php/ruby/python становятся убогими. Потому что они не способны отработать риквест с такой же скоростью, с которой сможет Си.
Вобщем я это к чему, речь у нас про удобство и простые сайты, а не про очередной фэйсбук или гугл.
Вобщем я это к чему, речь у нас про удобство и простые сайты, а не про очередной фэйсбук или гугл.
0
Когда у вас появляется нагрузка, то узким местом практически всегда является БД, а не php/ruby/python.
На фанатов обрушивается ведро холодной воды, и… упс, ORM из объекта поклонения превращается в обузу.
На фанатов обрушивается ведро холодной воды, и… упс, ORM из объекта поклонения превращается в обузу.
0
Слушайте, вот давайте предметно. 300 rps — это нагрузка?
Причем на обычный http 1.0, а не websocket какой-нибудь.
Причем на обычный http 1.0, а не websocket какой-нибудь.
0
С чем конкретно вы не согласны?
0
Тут как бы намёк на то что 300rps — это нагрузка у одного из популярных проектов в рунете ;) И они не испытывают проблем с базой данных из-за ОРМа.
Тк либо архитектура самого приложения — гавно, либо людей занимающихся проетками, в которых ОРМ будет обузой можно встретить достаточно редко и в большинстве случаев они понимают почему они отказываются от ОРМа. А для всех остальных ОРМ отлично справляется с задачей и уж лучше пусть будет всё сделано по-тупому, вместо умников, которые думают что могут что-то отоптимизировать, что в итоге выливается во всякий геморрой с кэшами итд.
Тк либо архитектура самого приложения — гавно, либо людей занимающихся проетками, в которых ОРМ будет обузой можно встретить достаточно редко и в большинстве случаев они понимают почему они отказываются от ОРМа. А для всех остальных ОРМ отлично справляется с задачей и уж лучше пусть будет всё сделано по-тупому, вместо умников, которые думают что могут что-то отоптимизировать, что в итоге выливается во всякий геморрой с кэшами итд.
0
Когда появляется нагрузка перед нами есть множество различных вариантов решения проблемы, которая не ограничивается вертикальным масштабированием какого-нибудь Postgre. И Взяв в руки Си++ можно будет решить те же проблемы на порядки эффективнее(например так как в гугле) вместо того чтобы использовать архитектуру в виде php бэка, суть которого делать sql запросы и рисовать хтмльки.
Я не понимаю что вы хотите сказать, что ОРМ — гавно? ОРМ вполне хороший инструмент для своих задач. В 99% случаев разработки вебсайтов он отлично справится с задачей и человек, который вдруг придёт на смену вам будет только рад тому что тут не гора sql'ой аптемезации.
Я не понимаю что вы хотите сказать, что ОРМ — гавно? ОРМ вполне хороший инструмент для своих задач. В 99% случаев разработки вебсайтов он отлично справится с задачей и человек, который вдруг придёт на смену вам будет только рад тому что тут не гора sql'ой аптемезации.
0
sqlalchemy может всё
0
1. функциями типа map пользовался постоянно, когда писал на питоне. Имхо достаточно взять любую достаточно навороченную библиотеку типа BeautifulSoup и там можно найти кучу примеров.
2…
>>>(приведите пример реального проекта, где python сделал бы что-то такое, чего не смог бы php)
Знакомо ли вам понятие тьюринг-эквивалентность?
2…
>>>(приведите пример реального проекта, где python сделал бы что-то такое, чего не смог бы php)
Знакомо ли вам понятие тьюринг-эквивалентность?
0
Неужели! )) Вы меня понял? ) От языка ничего кроме удобства не зависит. Все современные языки умеют делать одно и тоже ) И это я пытался донести с самого начала. Но вы меня убеждали, что python может больше и лучше. Так теперь я хочу задать Вам вопрос: Знакомо ли вам понятие тьюринг-эквивалентность? )
+2
Дык он может больше и лучше, только это больше и лучше не значит принципиальную невозможность сделать то же самое на брейнфаке.
Язык он для человека а не для компа — это ж давно известно.
Он может больше и лучше в плане того самого удобства для человека. Он же язык.
В питоне больше мезанизмов для запасания знаний и для того, чтобы одинаковый по сути код работал с большим числом разных объектов.
Язык он для человека а не для компа — это ж давно известно.
Он может больше и лучше в плане того самого удобства для человека. Он же язык.
В питоне больше мезанизмов для запасания знаний и для того, чтобы одинаковый по сути код работал с большим числом разных объектов.
-1
Пример. Что может такого питон, чего не может php? Вы опять вернулись к тому, с чего начали. Больше механизмов? Это например список и словарь? А в пхп только массив. Но зато в пхп я не заморачиваюсь и всегда пишу array, не думая нужны ли мне ассоциации или нет.
0
Это например то, что все объект, включая строки числа и прочее. Можно абстрагировать например алгоритмы над последовательностями и оно будет работать везде (см модуль itertools).
>>>Но зато в пхп я не заморачиваюсь и всегда пишу array, не думая нужны ли мне ассоциации или нет
Вот это интересно — вы заводите объект, не зная для чего он вам нужен? Можно пример?
>>>Но зато в пхп я не заморачиваюсь и всегда пишу array, не думая нужны ли мне ассоциации или нет
Вот это интересно — вы заводите объект, не зная для чего он вам нужен? Можно пример?
0
В PHP тоже есть итераторы, если что.
0
Какой объект? Вы про что? ) Из каких моих комментариев вы вынесли эту мысль? Я говорю, что если мне нужно 'asd' => 2, то я пишу array('asd' => 2), а если мне нужно просто 2, то я пишу array(2). А про «все объект»… И что? Вы мне реальную необходимость этого приведите?
0
и какова алгоритмическая сложность вставки/удаления/получения? вы в курсе, что массивы и ассоциативные массивы это разные структуры данных?
0
Да, в курсе. А как это реализовано в php Вы в курсе? Я, например нет. Может там все не так плохо как вам кажется. И вы опять говорите не о том.
1. ЯП — в исключительных ситуациях является узким местом в реальных проектах
2. Если не заморачиваться по поводу 20 мс выигрыша в скорости работы, то я выберу то, что мне удобней.
3. Если ваш код делает что-то тяжелое и разница в работе python\php существенна, то может стоит подумать о том, чтобы такой код перенести на что-то действительно производительно? Например Си.
Примерно таких пунктов я придерживаюсь. пхп — фронтенд, С++ — критичный по скорости бекэнд. На питоне я обычно пишу прототипы скриптов. Действительно быстро и удобно. Но для увеличения производительности я выберу C++.
1. ЯП — в исключительных ситуациях является узким местом в реальных проектах
2. Если не заморачиваться по поводу 20 мс выигрыша в скорости работы, то я выберу то, что мне удобней.
3. Если ваш код делает что-то тяжелое и разница в работе python\php существенна, то может стоит подумать о том, чтобы такой код перенести на что-то действительно производительно? Например Си.
Примерно таких пунктов я придерживаюсь. пхп — фронтенд, С++ — критичный по скорости бекэнд. На питоне я обычно пишу прототипы скриптов. Действительно быстро и удобно. Но для увеличения производительности я выберу C++.
0
1. Вы знаете, а многие ли любители пхп знают это?
2. 20 мс например в моем случае очень даже неплохо так.
3. Если мой код будет заниматься числодробилками, то я возьму к примеру numpy. но когда кто-то например вместо ассоциативного массива использует обычный массив и каждый раз ищет объект полным перебором, то меня это коробит. как впрочем и когда наоборот, массив объектов пихает в ассоциативный массив, когда заранее понятно, что по ключу они дергаться не будут.
4. Я считаю, что если написано array, то это должен быть именно массив, а не ассоциативный массив, пока я этого явно не напишу. вот вы подразумевали обычный массив и писали по индексу, а в другом месте другой программист этого не знал и стал писать по строковым ключам и у него это прокатит.
2. 20 мс например в моем случае очень даже неплохо так.
3. Если мой код будет заниматься числодробилками, то я возьму к примеру numpy. но когда кто-то например вместо ассоциативного массива использует обычный массив и каждый раз ищет объект полным перебором, то меня это коробит. как впрочем и когда наоборот, массив объектов пихает в ассоциативный массив, когда заранее понятно, что по ключу они дергаться не будут.
4. Я считаю, что если написано array, то это должен быть именно массив, а не ассоциативный массив, пока я этого явно не напишу. вот вы подразумевали обычный массив и писали по индексу, а в другом месте другой программист этого не знал и стал писать по строковым ключам и у него это прокатит.
0
А «ваш случай» в чем заключается. Для числодробилок я бы все таки выбрал С++ )
0
просто достаточно нагруженное приложение. только и всего. я лучше те же 20 мс пожертвую в местах, которые мне добавят понятности, чем просто потому, что мне лень нужную структуру данных использовать.
0
Кто сказал что мне лень? Просто мне лень использовать все «нужные» структуры питона вместо использования «нужных» структур пхп. Тем более приобретя эти нужные структуры я потеряю удобство и понятность. Достаточно нагруженный это какой? У кого-то нагруженный — 10000 посетителей в день, а у других — 500000 )
0
пару тысяч в секунду, так устроит? сразу скажу, не веб в чистом виде
0
Ну не слабо. Просто стоит разделять: основная нагрузка на запросы к бд идет или при обработке данных. Вы хотите сказать, что пхп не справлялся бы с такой нагрузкой? А если критична скорость работы прямо до миллисекунд, то я вообще не считаю интерпретируемые языки разумным выбором. Быстрее С пока еще ничего не придумали на высоком уровне. А если все совсем печально и вы боретесь за доли милисекунд, то пишите на асме ) Но не стоит говорить, что пхп медленно, я буду писать на питоне. он быстрее. Я участвовал в таком проекте ) Мне было смешно, но мое мнение никто не спрашивал ) В итоге сейчас этот проект все также загибается от нагрузок, а потрачено 2 месяца на переписывание.
0
пхп и справляется. сейчас именно он используется. новый проект пишем на питоне, не потому что он быстрее (хотя простенькие показали прирост где-то в полтора раза), а потому что на нем банально удобнее писать и потому что текущий пхп проект представляет из себя огромную свалку, хотя писали люди неглупые далеко. Интерпретируемый язык выбран осознанно ввиду простоты написания и простоты деплоя в частности.
основная работа — проверить бизнес-логику и получить-сохранить данные из бд. куда тут впихивать модули на С? но будет запрос идти 60 миллисекунд или 30 все же важно. надо будет в 2 раза меньше серверов.
я к тому, что везде нужен компромисс, здесь компромисс между удобством написания и производительностью. пхп ни скоростью, ни удобством не обладает, плюсы не обладают достаточным удобством. только и всего.
основная работа — проверить бизнес-логику и получить-сохранить данные из бд. куда тут впихивать модули на С? но будет запрос идти 60 миллисекунд или 30 все же важно. надо будет в 2 раза меньше серверов.
я к тому, что везде нужен компромисс, здесь компромисс между удобством написания и производительностью. пхп ни скоростью, ни удобством не обладает, плюсы не обладают достаточным удобством. только и всего.
0
Насчёт неудобства пхп по сравнению с питоном спорно, особенно если рассматривать «коробочные» продукты, предназначенные для установки неквалифицированным пользователем.
0
«получить\сохранить данные в бд» вы сталкнетесь с тем, что при увеличении кол-ва данных вам понадобиться увеличение количества серверов с бд. А это не просто скопировал и запустил еще один. Это шардинги, рапределение нагрузки и т.п. И поверьте увеличение производительности в полтора раза (15 мс для вашего пример) вам покажется никчемным. Я, например разницу в 15 миллисекунд не замечу на глаз. А по поводу кол-ва серверов — сомнительно утверждение ) Задача, которая выполняется на одном сервере 30 мс на двух тоже будет выполнятся 30 мс, но параллельно смогут работать 2.
0
само собой нужен шардинг и прочее, все это уже заложено и предусмотрено. по поводу времени обработки надо пойти с другой стороны. есть приемлемый интервал допустим 30-40 миллисекунд. питон обеспечит это на одном сервере, пхп понадобится два. вот и вся математика.
0
Как время выполнения одного запроса у вас уменьшается при увеличении количества серверов? Вы как-то распараллеливаете выполнение каждого запроса? В вакууме один и тот же алгоритм всегда будет выполняться с одной и той же скоростью. И он не станет работать быстрее, осознавая, что рядом с ним трудится над такой же задачей еще один сервер. Или я вас не понял? Получается если пхп изначально не вписывается в ваши временные рамки, то сейчас ваш проект не работает? Или все таки сейчас вы рапараллелили задачу каким-то образом?
0
может я неправильно выразился. простой бенчмарк показал, что за секунду пхп успевает обработать где-то в полтора раза меньше запросов(точно не помню, давно было), чем питон при полной загрузке проца (с учетом xcache). если учесть, что время выборки из базы фиксировано как для питона, так и для пхп, то получается, что питону надо меньше процессорного времени, чем пхп. то есть 2 сервера на питоне обработают столько же запросов, что и 3 на пхп.
0
>вы в курсе, что массивы и ассоциативные массивы это разные структуры данных?
немного не в тему, но просто тут на днях пришлось на питоне делать такой изврат, который на Си делается элементарно. Суть была в том что нужно было каждой ноде в даг графе присвоить битовый вектор для определения принадлежностей нодов к разным группам. Так пришлось брать листы, состоящие из True,False вместо какого-нибудь обычного BitArray'а, с которым элементарно работать на Си. Попытки оптимизировать различными способами, и даже прикручивание Сишного кода на моей задаче не давали особого прироста производительности, только уменьшали потребление памяти, что пришлось оставить так как есть :) Пришлось дописать комментарием что понимаю что код убог, но не вижу варианта как сделать лучше.
немного не в тему, но просто тут на днях пришлось на питоне делать такой изврат, который на Си делается элементарно. Суть была в том что нужно было каждой ноде в даг графе присвоить битовый вектор для определения принадлежностей нодов к разным группам. Так пришлось брать листы, состоящие из True,False вместо какого-нибудь обычного BitArray'а, с которым элементарно работать на Си. Попытки оптимизировать различными способами, и даже прикручивание Сишного кода на моей задаче не давали особого прироста производительности, только уменьшали потребление памяти, что пришлось оставить так как есть :) Пришлось дописать комментарием что понимаю что код убог, но не вижу варианта как сделать лучше.
+1
ну то есть вы явно создаете ассоциатиынй массив только указываете, что это ассоциативный массив другим образом?
Реальная необходимость — вон например код из моего примера работает только с последовательностями строк. Сделаем чтоб оно работало со всем, что можно представить как строку:
codepad.org/dRTXxV1U
Теперь оно работает вообще со всеми объектами, у которых есть метод __str__ включая встроенные
Реальная необходимость — вон например код из моего примера работает только с последовательностями строк. Сделаем чтоб оно работало со всем, что можно представить как строку:
def make_list(xs):
return ''.join('<li>'+str(x)+'</li>' for x in xs)
print make_list(xrange(0, 10))
codepad.org/dRTXxV1U
Теперь оно работает вообще со всеми объектами, у которых есть метод __str__ включая встроенные
0
Каким другим? Не понимаю Вас.
А по поводу примера… А зачем? Вы реально работаете с другими объектами кроме строк в проекте? Максимум с числами, но на пхп это еще проще реализовано. Мне трудно представить реальную необходимость работы с другими типами данных. Как фишка языка — очень даже интересно.
А по поводу примера… А зачем? Вы реально работаете с другими объектами кроме строк в проекте? Максимум с числами, но на пхп это еще проще реализовано. Мне трудно представить реальную необходимость работы с другими типами данных. Как фишка языка — очень даже интересно.
+1
А бизнесобъектов вы не делаете? Типа там Заказ, Пользователь прочее?
0
Во-первых, комментарий ниже ) А во-вторых: делаю, но с трудом могу себе представить ситуацию, когда мне понадобится обработать Заказы и Пользователей в одной куче ) Я напишу 2 различных обработчика для этого случая.
0
То есть у списка заказов и у списка пользователей нет ничего общего?
0
А что у них общего? ) Это две разные сущности. Можно найти сходство, но чтобы им воспользоваться — не знаю какой должен быть случай )
0
В php есть magic function __toString() и это очень полезная вещь.
0
Глупый пример, я пишу и на пхп и на питоне.
То-что Вы показали как __str__ в пхп есть метод toString().
То-что Вы показали как __str__ в пхп есть метод toString().
Почему многие выбирают PHP