Comments 223
Скорость это не только скорость, но и максимальная нагрузка на сервис. 30 rps или 6000rps с ноды. А значит меньше серверов, меньше поддержки, меньше трат и немаловажная фича, которую бизнес хорошо понимает: возможность расширяться в N раз, не сталкиваясь с поблемами со стороны сервисов.
Да, автор на это тоже обращает внимание и приходит к выводу, что дешевле будет доставить ещё один сервер, чем тратить время программиста. Ну, по крайней мере там :) Я не думаю, что это можно и нужно делать бесконечно, но гораздо проще будет провести оптимизацию комплексно в спокойное время.
Все зависит от нагрузки, 1 сервер + 1 сервер может и не пробелма, а вот если количество растет, типа 10 серверов вместо 5, или когда объемы доходят до сотен. 50 серверов или 100 серверов, есть ведь разница.
А скорость разработки — это не язык, а года существования компании или года практики разработчика, у которых все уже готово и остаются только " частные случаи". Сегодня back-end совсем упростился, в компаниях на 5 front-end 1 back end, потому поднять базу данных и API для CRM — нужен 1 день, ну еще парочка на частные случае или если есть какие-то особенные вычесления, а вот на Front-end постоянно уходит огромное количество времени.
А скорость разработки — это не язык, а года существования компании или года практики разработчика, у которых все уже готово и остаются только " частные случаи". Сегодня back-end совсем упростился, в компаниях на 5 front-end 1 back end, потому поднять базу данных и API для CRM — нужен 1 день, ну еще парочка на частные случае или если есть какие-то особенные вычесления, а вот на Front-end постоянно уходит огромное количество времени.
UFO just landed and posted this here
сомневаюсь что бизнес любит капитализацию в ущерб прибыли
UFO just landed and posted this here
Он прав. Мне как-то объяснили этот момент тоже (речь идет о компании NetCracker). Я приходил каждый раз с рационализаторскими предложениями. Каждый раз мне объясняли, что на это нет времени. Это конечно же неправда — эти люди умеют считать деньги.
А правду мне объяснили потом в курилке: все рационализаторские предложения приводят к сокращению штата. А сокращение штата приводит к проигрышу тендеров у крупных корпораций, для которых маленькая компания == компания однодневка.
Другими словами, сокращение штата — потеря денег, если принять во внимание не только технические, а все особенности бизнеса.
NetCracker до сихпор собирает Java-код руками (даже есть целый отдел «релиз-инженеров»). Результат превзошел все ожидания. Сегодня это крупнейшая в своем рынке компания…
А правду мне объяснили потом в курилке: все рационализаторские предложения приводят к сокращению штата. А сокращение штата приводит к проигрышу тендеров у крупных корпораций, для которых маленькая компания == компания однодневка.
Другими словами, сокращение штата — потеря денег, если принять во внимание не только технические, а все особенности бизнеса.
NetCracker до сихпор собирает Java-код руками (даже есть целый отдел «релиз-инженеров»). Результат превзошел все ожидания. Сегодня это крупнейшая в своем рынке компания…
Еще ведь и от задачи зависит. Скажем на сервере крутится вычислительное ядро, которое реализует сверх сложную с алгоритмической точки зрения задачу. И запросто может так сложиться, что добавление любого количества серверов не даст результата.
Сказать «дешевле поставить еще один сервер» можно только тогда, когда мы сравним траты в обоих случаях, то есть данное утверждение надо подкрепить цифрами и показать, масштабируется ли оно, то есть справедливо ли по прежнему будет сказать «дешевле поставить еще 3000 серверов, чем иметь 200 и научить программистов один раз и навсегда писать более качественный и шустрый код». Мне не кажется, что ответ так однозначен, как преподносится в статье. Особенно с точки зрения бизнеса.
Как говорится «скорость — это тоже фича».
Как говорится «скорость — это тоже фича».
Да, кстати, цены можно обсудить. m3.medium (1xCPU, 4Gb) стоит $350 за год, то есть ~20 000 руб. Насколько я знаю, это месяц работы джуниора (вряд ли ему кто-то доверит такую задачу) или 4 дня мидла. А у него задачи могут быть расписаны на недели вперёд.
Смотрите на это как на технический долг — да, мы сейчас ставим более дорогое железо, но в будущем эту ситуацию обязательно исправим.
Смотрите на это как на технический долг — да, мы сейчас ставим более дорогое железо, но в будущем эту ситуацию обязательно исправим.
А когда речь про 1000 серверов и не medium? Я про то, что обобщать по меньшей мере странно. Что может быть верно для небьльшого или среднего проекта, то оказывается фантастическими убытками на больших нагрузках, когда число тех же серверов давно идет на сотни и тысячи. Дешевле несколько заняться бизнес-процессами и устроить обучение в расках компании, заодно с нагрузочным приемочным тестированием. Как итог иметь разовые вложения в программистов против регулярных плат за впустую используемые мощности.
Вложения в программистов не бывают разовыми — любой код приходится сопровождать и развивать, чтобы он не умер. Если код меньше, его дешевле поддерживать. Оптимизированный код очень часто сложнее для понимания. Времена нынче таковы, что все быстро меняется и время жизни кода стало существенно меньше, чем раньше. Пока вы доведете до ума хорошо оптимизированный код, его, возможно, уже надо будет переделывать.
Исправление этой сетуации, если оно упрется вдруг в язык, на котором написана система, может похоронить. Долг долгу рознь. Если у нас спокойный сублинейный рост по мощности серверов, то можно такой долг и запланировать, когда и как его возвращать. А если рост в разы как минимум? Смогут ли программисты решить проблему такого «долга», когда требования растут от месяца к месяцу?
Я вновь возвращаюсь к вопросу, что обозначенное выше утверждение справедливо только в определенных рамках касательно размера бизнеса и размера нагрузки.
Я вновь возвращаюсь к вопросу, что обозначенное выше утверждение справедливо только в определенных рамках касательно размера бизнеса и размера нагрузки.
Еще момент про который часто забывают. Ваш сервис не застыл. Его надо развивать. Постоянно вносить изменения…
Люто бешенно плюсую.
Мало того, что нужно учесть цифры в разных перспективах (за год, за 5 лет, за 10), так я заметил и еще одну особенность — люди иногда пересказывают догму «программист дороже железа» без привязки к реальности.
Они не учитывают, что догма эта родилась в западных странах, где цены на железо такие же, как в России + куча скидок и отсроченных платежей, а зарплаты в 10 раз выше. Для России, где разработчики получают $1-2k нужно еще много раз пересчитать и убедиться, что догма не обратная. И опять же: с ростом экономики России нужно снова и снова ее пересчитывать.
Мало того, что нужно учесть цифры в разных перспективах (за год, за 5 лет, за 10), так я заметил и еще одну особенность — люди иногда пересказывают догму «программист дороже железа» без привязки к реальности.
Они не учитывают, что догма эта родилась в западных странах, где цены на железо такие же, как в России + куча скидок и отсроченных платежей, а зарплаты в 10 раз выше. Для России, где разработчики получают $1-2k нужно еще много раз пересчитать и убедиться, что догма не обратная. И опять же: с ростом экономики России нужно снова и снова ее пересчитывать.
возникает вопрос: что дешевле — платить квалифицированному по части оптимизаций специалисту или покупать новый сервер?
Автор как-то упускает/замалчивает тот момент, что для самой возможности "доставить ещё один сервер" приложение должно быть горизонально масштабиремо. А для этого, нередко, нужно чтобы разработчики достаточно сильно "вложились" в обеспечение такой возможности.
Бывают ситуации, когда быстрее и дешевле сделать решение на более производительном языке, и которое не будет (изначально) масштабироваться, но будет обрабатывать нагрузку с достаточной производительностью, чем делать мастабируемое решение на более удобном языке и тратить существенные усилия на обеспечение масштабируемости.
Думаю все уже знают и понимают, что если у вас проблемы с производительностью, то решение только в горизонтальном масштабировании т.к. ресурсы одного сервера имеют вполне конкретные ограничения и скорее всего всё равно придётся масштабировать горизонтально т.е. нет смысла тратить деньги на оптимизацию работы на одной железке, лучше сразу заниматься горизонтальным масштабированием.
Помимо этого горизонтальное масштабирование ещё и добавляет отказоустойчивости т.е. его всё равно придётся делать в том или ином виде.
Помимо этого горизонтальное масштабирование ещё и добавляет отказоустойчивости т.е. его всё равно придётся делать в том или ином виде.
Вот бы с автора подобных заявлений, с зарплаты вычесть все затраты (дешевле будет) всех пользователей приложения.
максимальная нагрузка на сервис. 30 rps или 6000rps с ноды
Представим что у вас 10 000 000 ежемесячных посетителей. То есть ваш сайт входит в US топ150 по посещаемости и находится рядом с такими ребятами как airbnb.com и steamcommunity.com Пусть каждый посетитель просматривает 10 страниц. Таким образом у вас 10000000*10/30/24/60/60 = 38 rps. Стоило оптимизировать сервис до уровня 6к?
Ах, если бы 1 страница это был 1 запрос.
Эх… Солидарен. Если бы одна страница == один запрос…
Легко, если данные важные, можно отдавать кеш 1 раз 5 секунд из файла, а если данные не очень важные то в любое назначенное время.
Сайты которые мы сдаем на Wordpress, вообще не используют Wordpress для вывода страниц, сразу отрубается WP и кешированные странциы достаются 1 запросом прямо из index.php, получается безумно быстро
Сайты которые мы сдаем на Wordpress, вообще не используют Wordpress для вывода страниц, сразу отрубается WP и кешированные странциы достаются 1 запросом прямо из index.php, получается безумно быстро
А есть еще миир realtime и highload…
Нельзя там кэшировать страницу целиком в файл. Максимум отдельные куски.
Нельзя там кэшировать страницу целиком в файл. Максимум отдельные куски.
realtime можно кешировать на 2,1 и 0.5 секунд если мы говорим про страницу, а не про какой-то интерактив
Представьте если за пол секунды заходит 20 человек, это 1 сборка вместо 20
Но суть с отдельными частями такая же, кешируйте все, что можно, а realtime оставьте
Представьте если за пол секунды заходит 20 человек, это 1 сборка вместо 20
Но суть с отдельными частями такая же, кешируйте все, что можно, а realtime оставьте
А если заходят тысячи покупателей и цены меняются очень часто и склады, опять-таки, а операционные издержки по отмене нескольких тысяч заказов, сделанных в момент, когда остатков на складах уже нет, будут весьма велики. Не считая ущерба для репутации.
И если у нас сотни серверов, тысячи, то мы приходим к задаче инвалидации кэша, которая, как известно, сложна.
И если у нас сотни серверов, тысячи, то мы приходим к задаче инвалидации кэша, которая, как известно, сложна.
Можно обновлять кеш по факту изменения цены, все просто. Контролировать кеш не только по времени, но по факту изменений, тогда изменения применяться моментально.
PS. Контролировать кеш при большом количестве серверов извне сложно, но можно делать 1 запрос на проверку изменений, а изменения хранить как отдельное поле, тогда будет 1 запрос, но не такой критичный.
PS. Контролировать кеш при большом количестве серверов извне сложно, но можно делать 1 запрос на проверку изменений, а изменения хранить как отдельное поле, тогда будет 1 запрос, но не такой критичный.
Это инвалидация кэша. И это сложная задача. Цену могут обносвлять разные сервисы: массовый импорт, просто редактирование продукта, изменение не самой цены, но скидки на нее, которая может считаться несколькими сервисами с совершенно различной бизнес-логикой, стоимость доставки и скидка на стоимость доставки для этого клиента. И кто и где должен сбрасывать кэш? Это не тауой простой вопрос и тут немало копий сломано, чтобы добиться качественной инвалидации.
Это если у вас в отдельных частях ничего не зависит от user_id и от фильтров, которые он вводит.
Мои цифры не претендуют на точность и учет всех параметров для проектов разной тематики. Они о том что ОЧЕНЬ МНОГО пользователей не значит что каждый элемент вашей системы нужно тестировать на абстрактные 6k rps. Нужно максиально быстро запускаться, выявлять под реальной нагрузкой узкие места и тюнить их.
Представим, что столько за приходит за час или меньше.
Почему-то все считают, что их проект обязательно доберется до той точки, где ему понадобятся сотни и тысячи серверов и при этом будет использоваться тот же код, что и в начале. Таких больших проектов реально единицы и обычно они начинают с дешевого говнокода от фрилансеров, который все равно потом приходится переписывать.
Верно и обратное: почему-то люди считают, что их проект никогда не столкнется с теми задачами, которые появляются при резком росте.
В сущности я весь разговор подвожу к тому, что оба суждения не верны, если обобщать. Нельзя утверждать, что проблемы решаются любым языком программирования + пара лишних серверов; равно для сервисов с нагрузкой в несколько тысяч в день или час не нужно кидаться оптимизировать для сокращения времени ответа с миллисекунд до микросекунд.
На мой взгляд статья неверна именно в своих основах: обобщение неправомерно и в чем-то непрофессионально — в стиле «надо быстро фигачить код, а плохую скорость компенсируем, это, мол, всегда работает». Нет, не всегда. Можно оказаться один на один с громадным техническим долгом и успешным проектом, который быстро растет по нагрузке, а времени уже не хватит, чтобы сделать хорошо. Должен быть заранее определенный порог, ниже которого не опускаемся по производительности и способности масштабироваться под нагрузку. И порог этот должен учитывать различные бизнес-сценарии, как негативный, так и позитивный.
В сущности я весь разговор подвожу к тому, что оба суждения не верны, если обобщать. Нельзя утверждать, что проблемы решаются любым языком программирования + пара лишних серверов; равно для сервисов с нагрузкой в несколько тысяч в день или час не нужно кидаться оптимизировать для сокращения времени ответа с миллисекунд до микросекунд.
На мой взгляд статья неверна именно в своих основах: обобщение неправомерно и в чем-то непрофессионально — в стиле «надо быстро фигачить код, а плохую скорость компенсируем, это, мол, всегда работает». Нет, не всегда. Можно оказаться один на один с громадным техническим долгом и успешным проектом, который быстро растет по нагрузке, а времени уже не хватит, чтобы сделать хорошо. Должен быть заранее определенный порог, ниже которого не опускаемся по производительности и способности масштабироваться под нагрузку. И порог этот должен учитывать различные бизнес-сценарии, как негативный, так и позитивный.
Не согласен с вами. Поведение под нагрузкой предсказать всегда сложно, и оно может упираться не в RPS, или не в тот RPS, который вы задумали. Уже было очень много случаев, когда делали оптимизированный сервер на Java/C++/Go/etc. и в большинстве случаев все равно все заканчивалось тем, что под взрывом нагрузки сервис несколько дней лежал, так как упор был не в процессор, а например в базу. Почитайте для примеров истории разных io-игр или погуглите на хабре словосочетание «не выдержал хабраэффекта».
Еще мне кажется, что автор не имел в виду, что надо всегда оставаться на питоне в любой ситуации. Вы можете наговнокодить за неделю прототип на Django и размножить его на 100 серверов при необходимости, а убедившись что 100 серверов действительно нужны, нанять в это время высокооплачиваемую Java-команду, которая за три месяца перепишет проект и уместит все в один мощный сервер.
И тогда цена проекта получится полностью оправданной — и 100 серверов, и профессионалы покупаются только если они действительно нужны. А если сервис понадобится только 1.5 пользователям, все что вы потеряете — это деньги на микроинстанс и неделю времени.
Еще мне кажется, что автор не имел в виду, что надо всегда оставаться на питоне в любой ситуации. Вы можете наговнокодить за неделю прототип на Django и размножить его на 100 серверов при необходимости, а убедившись что 100 серверов действительно нужны, нанять в это время высокооплачиваемую Java-команду, которая за три месяца перепишет проект и уместит все в один мощный сервер.
И тогда цена проекта получится полностью оправданной — и 100 серверов, и профессионалы покупаются только если они действительно нужны. А если сервис понадобится только 1.5 пользователям, все что вы потеряете — это деньги на микроинстанс и неделю времени.
Вот про последнее, про команду java: у вас был такой опыт и подобные задачи решались за квартал java командой или нет?
Про «не выдержал нагрузки» — где мне доводилось работать с приемочным нагрузочным тестированием с таким не сталкивались. Такое происходит, когда методология тестирования нарушена. Если есть обратные примеры, где и нагрузочное приемочное было и методология тестирования доступна для проверки, но все равно уперлись в неожиданное нечто, что тестирование не предсказывало, то буду рад примерам. Иначе несколько голословно звучит.
Про «не выдержал нагрузки» — где мне доводилось работать с приемочным нагрузочным тестированием с таким не сталкивались. Такое происходит, когда методология тестирования нарушена. Если есть обратные примеры, где и нагрузочное приемочное было и методология тестирования доступна для проверки, но все равно уперлись в неожиданное нечто, что тестирование не предсказывало, то буду рад примерам. Иначе несколько голословно звучит.
Про 3 месяца я загнул конечно, но если изначально был проект сделанный за неделю, то за 3 месяца уже могут что-нибудь да выкатить на прод. По опыту знакомых джавистов-аутсорсеров, где-то так все и происходит: приходят люди и просят переделать говнокод на питоне или еще чем-то во что-то приличное.
Тут мы и приходим к тому, что чтобы проект выдерживал нагрузки сразу, разработчик должен быть опытным (дорогим) и чтобы просто проверить идею (которая скорее всего не взлетит по статистике), придется потратить много денег и скорее всего времнеи. Естественно я не говорю о проектах, где большая нагрузка точно будет.
Такое происходит, когда методология тестирования нарушена.
Тут мы и приходим к тому, что чтобы проект выдерживал нагрузки сразу, разработчик должен быть опытным (дорогим) и чтобы просто проверить идею (которая скорее всего не взлетит по статистике), придется потратить много денег и скорее всего времнеи. Естественно я не говорю о проектах, где большая нагрузка точно будет.
Даже если проект добирается до такой точки, камнем преткновения, по-моему, становится не язык, а задачи и алгоритмы. В тех проектах, где работал я, сложности появлялись не из-за того, что Python «медленный» а из-за того, что какие-то задачи в принципе в лоб быстро сделать невозможно. И кэширование применить невозможно (потому что каждый вызов кода должен был возвращать уникальные данные). Приходилось придумывать какие-то алгоритмы и структуры данных, чтобы можно было максимально быстро генерировать требуемую информацию. И напиши это место хоть на C, ничего не изменилось бы, так как требовалось достать сотни тысяч строк из базы данных, и произвести над ними какие-то действия.
Кстати, Reddit, если не ошибаюсь, на Python написан, а это очень высоконагруженный сайт.
Бывает, что и в язык. Никто в здравом уме и трезвой памяти не будет делать жадные до данных алгоритмы на php, опыт был. Один и тот же алгоритм выявления спама на php съедал 32+ оперативки и прогноз работы был в день. Лоб в лоб переписанный на java без знания java алгоритм отработал в пределах 5и минут. Это времена php 5.6.
В PHP нет сборщика мусора, во всяком случае, раньше не было. Так что неудивительно, надо было все-таки сравнивать хотя бы с минимально полноценным языком.
Только что вы говорили, что язык не имеет значения и уже перешли к тому, что PHP — неполноценный? Вы противоречите своему утверждению «Даже если проект добирается до такой точки, камнем преткновения, по-моему, становится не язык, а задачи и алгоритмы».
Кстати, python на той задаче бинарной кластеризации показал не лучший результат.
Кстати, python на той задаче бинарной кластеризации показал не лучший результат.
И кстати http://php.net/manual/ru/features.gc.php
погодите. Сборщик мусора не увеличивает быстродействие (за исключением редких случаев, когда вм за сотни циклов понимает, что можно перевести пару выделения/освобождения памяти с кучи на стек).
Понятно, что оптимизировать питон в питон вряд ли есть резон, но если исходить из принципа достаточной эффективности, то далеко не всегда есть резон переписывать в си то, что достаточно быстро отработает на джаве. А иначе и выбора-то нет.
Понятно, что оптимизировать питон в питон вряд ли есть резон, но если исходить из принципа достаточной эффективности, то далеко не всегда есть резон переписывать в си то, что достаточно быстро отработает на джаве. А иначе и выбора-то нет.
Подправьте меня пожалуйста. Что если аренда сервера стоит 250$, и мы добавляем второй, вместо оптимизации, то это 500$. 6000$ каждый год, Программиста можно уволить или перевести на другой проект, а расходы останутся, а кто эти два сервера будет администрировать? Админу теперь вместо 1, надо администрировтать 2 сервера.
А что буде тесли 1 сервер упадет? (Риторический вопрос)
Это все сказки, что железо дешевое работы программиста, программисты разные и железо разное, если мы считаем VPS по 10-50 долларов в месяц и Senior с окладом 4000$ в месяц, то да, но если сервер стоит хотябы 250$, то тут другая история.
— Более того, я не согласен про скорость, понятие скорости очень размыто и зависит от прокладки. Такое ощущение, что каждая новая работа — это чистый лист. Потратил на 4000$ больше, зато экономишь каждый год 3000$, а это 15000$ за 5 лет
А что буде тесли 1 сервер упадет? (Риторический вопрос)
Это все сказки, что железо дешевое работы программиста, программисты разные и железо разное, если мы считаем VPS по 10-50 долларов в месяц и Senior с окладом 4000$ в месяц, то да, но если сервер стоит хотябы 250$, то тут другая история.
— Более того, я не согласен про скорость, понятие скорости очень размыто и зависит от прокладки. Такое ощущение, что каждая новая работа — это чистый лист. Потратил на 4000$ больше, зато экономишь каждый год 3000$, а это 15000$ за 5 лет
Уверен, что в компании, которая нуждается в серверах m4.2xlarge (а это 32Gb RAM и стоят они всего $2000/год), зарплаты программистов гораздо больше $4000/mo. К тому же я б разбил такой сервис на кучу маленьких серверов и засунул в autoscale группу — удобнее будет и спокойнее по ночам. Ну и ещё раз повторюсь — оптимизации никто не отменял, но это работа с высокими рисками по времени (может занять день, а может и неделю), так что лучше её проводить в спокойное время.
Уверен — не аргумент, вы так уверенно считаете чужие деньги ) Проекты очень разные, даже там где есть деньги, есть автоматические скрипты, которые не требуют суппорта годами. А есть проекты, где денег мало, клиентов мало, но данных очень много.
А что делать, если данные ждут сначала жесткий или SSD, а потом приходится еще и проц ждать )
А что делать, если данные ждут сначала жесткий или SSD, а потом приходится еще и проц ждать )
Про зарплаты — это не так. Достаточно вспомнить те же зарплаты в яндексе, которые несколько ниже рыночного уровня.
В больших компаниях спокойного времени часто не бывает вовсе: всегда есть горящая кампания, выход на новый рынок, развитие нового направления, мега-важная бизнес задача. По сути просто выше планка минимального приемлимого уровня по производительности.
С aws и большими компаниями тоже неоднозначно. Не дешевое оно удовольствие в highload: когда счета переваливают за тысячи в день, и когда понимаешь, что отсутствие возможности лично решать проблемы со связью — это задержки в недели и месяцы в важных задачах, а если вот прямо сейчас идут сотни и тысячи заказов в секунду… Все приходят к своим дц в итоге. И своей поддержке. И мы возвращаемся к вопросу оптимизации издержек на железо и поддержку.
В больших компаниях спокойного времени часто не бывает вовсе: всегда есть горящая кампания, выход на новый рынок, развитие нового направления, мега-важная бизнес задача. По сути просто выше планка минимального приемлимого уровня по производительности.
С aws и большими компаниями тоже неоднозначно. Не дешевое оно удовольствие в highload: когда счета переваливают за тысячи в день, и когда понимаешь, что отсутствие возможности лично решать проблемы со связью — это задержки в недели и месяцы в важных задачах, а если вот прямо сейчас идут сотни и тысячи заказов в секунду… Все приходят к своим дц в итоге. И своей поддержке. И мы возвращаемся к вопросу оптимизации издержек на железо и поддержку.
> Программиста можно уволить или перевести на другой проект
это только в сказочном мире так бывает, обычно программистов нужно всё больше если проект живёт, а если не живёт, то и сервера будут не нужны
> Админу теперь вместо 1, надо администрировтать 2 сервера.
для нормального админа разницы нет, сервера то типовые, хоть 50
это только в сказочном мире так бывает, обычно программистов нужно всё больше если проект живёт, а если не живёт, то и сервера будут не нужны
> Админу теперь вместо 1, надо администрировтать 2 сервера.
для нормального админа разницы нет, сервера то типовые, хоть 50
Замерил я производительность для своей задачи.
1 млн объектов в массива + легкая арифметика заняли около 30 секунд на Python и 11 секунд на php7, NodeJS и C = 9 секунд.
Убедительная прозьба не лошить на замеры, замеры сделаны аматорки, был написал 1 алгоритм на всех языках и запускались из под консоли не для точных замеров, а для быстро решения в чем массив обрабатывать.
Так вот, 20 секунд разницы против тоже простого, но более уродливого языка.
на 100 000 000 — это уже 2000 секунд, что есть 30 минут. Откуда берутся 100 млн циклы? Это когда у вас вложеные циклы. Вложеные циклы плохо? Ну а что делать, если задача брать 1 обхект из массива, у которого например 20 полей, проверять каждое поле по определенным патеррнам и тд (безумловно много чего было придумано для уменьшенитя этих итераций, но суть остается)
1 млн объектов в массива + легкая арифметика заняли около 30 секунд на Python и 11 секунд на php7, NodeJS и C = 9 секунд.
Убедительная прозьба не лошить на замеры, замеры сделаны аматорки, был написал 1 алгоритм на всех языках и запускались из под консоли не для точных замеров, а для быстро решения в чем массив обрабатывать.
Так вот, 20 секунд разницы против тоже простого, но более уродливого языка.
на 100 000 000 — это уже 2000 секунд, что есть 30 минут. Откуда берутся 100 млн циклы? Это когда у вас вложеные циклы. Вложеные циклы плохо? Ну а что делать, если задача брать 1 обхект из массива, у которого например 20 полей, проверять каждое поле по определенным патеррнам и тд (безумловно много чего было придумано для уменьшенитя этих итераций, но суть остается)
Чтобы убрать эти 30 минут, мне надо докупить еще 1 сервер за 500$, именно столько стоит текущий, мне этого делать не хочется, а я не корпоративная компания монстр с огроными бюджетами, а задача такая есть. И я не вижу разницы в скорости разработки между Python, NodeJS, php, можете объяснить где же это узкое место.
На конференциях везде проталкивают Джанго, как джина с батарейками, где все есть и ничего делать не нужно.
На конференциях везде проталкивают Джанго, как джина с батарейками, где все есть и ничего делать не нужно.
Бизнес-логику писать на python, а критичные числодробилки переписывать на C. Об этом и статья. Из личного опыта, за 5 лет пришлось написать два экстеншена на чистом C. И что, из-за двух мест писать весь продукт, например, на Java? И потерять на этом пару десятков человеко-лет?
Если эта числодробилка и есть весь ваш проект, то безусловно, выбираем язык под потребности. Но, мне кажется, есть много всего вокруг этого алгоритма: пользовательские интерфейсы, API и т.д. Их тоже обязательно писать на супер-быстром языке, жертвуя своей производительностью? Python как раз дает такую гибкость.
Поводом выбрать Java может быть наличие статических анализиторов кода, широкое сообщество, кол-во доступных разработчиков на рынке, особенности продукта. Но точно не скорость работы языка как такового.
Если эта числодробилка и есть весь ваш проект, то безусловно, выбираем язык под потребности. Но, мне кажется, есть много всего вокруг этого алгоритма: пользовательские интерфейсы, API и т.д. Их тоже обязательно писать на супер-быстром языке, жертвуя своей производительностью? Python как раз дает такую гибкость.
Поводом выбрать Java может быть наличие статических анализиторов кода, широкое сообщество, кол-во доступных разработчиков на рынке, особенности продукта. Но точно не скорость работы языка как такового.
Узкое место есть, просто оно дальше. В большинстве же небольших проектов оно в язык вряд ли упрется, разве что в вопрос, на каком языке лучше и шуствее код писать и поддерживать, то есть в первую очередь, читать, в том числе и новичками.
Подобные числодробилки и пишутся на Cython, о чем говорится в статье (и о чем говорил Гвидо).
Для примера вот вычисление чисел Фибоначчи на Python и Cython:
Время выполнения говорит само за себя.
p.s. А для работы с многомерными массивами, математическими функциями и т.п всегда есть NumPy.
Для примера вот вычисление чисел Фибоначчи на Python и Cython:
Python
def fib(n):
a, b = 1, 1
for i in range(n):
a, b = a + b, a
return a
%timeit fib(1000)
10000 loops, best of 3: 104 µs per loop
Сython
def cfib(int n):
cdef int i
cdef double a=0.0, b=1.0
for i in range(n):
a, b = a + b, a
return a
%timeit cfib(1000)
1000000 loops, best of 3: 1 µs per loop
Время выполнения говорит само за себя.
p.s. А для работы с многомерными массивами, математическими функциями и т.п всегда есть NumPy.
Справедливости ради стоит отметить, что целые числа в python — с абсолютной точностью(не ограничены по размеру), а значит сравнивать сложение их со сложением double совсем не корректно(потому что чем больше числа тем сложнее их складывать) подкорректировал чтоб считать модуль по большому простому числу каждый раз:
Разница уже не в 100 раз, а в 10, но конечно все еще существенна.
Python
In [11]: def fib(n):
....: p = 10**9 + 7
....: a, b = 1, 1
....: for i in range(n):
....: a, b = (a+b)%p, a
....: return a
In [12]: %timeit fib(1000)
10000 loops, best of 3: 58.5 µs per loop
Cython
In [16]: %%cython
....: def cfib(int n):
....: cdef int p=10**9 + 7
....: cdef int i
....: cdef int a=1, b=1
....: for i in range(n):
....: a, b = (a+b)%p, a
....: return a
In [17]: %timeit cfib(1000)
100000 loops, best of 3: 6.02 µs per loop
Разница уже не в 100 раз, а в 10, но конечно все еще существенна.
Почему в Cython 1000000 loops а в Python 10000 loops, при этом n что там что там 1000?
Зачем сравнивать C и Python, сравнивайте современные развивающиеся языки, которые намного быстрее, а во многом и удобнее питона.
И разница в серверах (а значит и всей инфраструктуре) может быть на порядки, если задача выполняется не в 2 раза медленнее, а в 100.
И разница в серверах (а значит и всей инфраструктуре) может быть на порядки, если задача выполняется не в 2 раза медленнее, а в 100.
Топ языков по исследованию SO: JavaScript, SQL, Java, C#, Python, PHP, C++, C. Все они стартовали в прошлом тысячелетии. И все они современные и развивающиеся, ИМХО.
ачем сравнивать C и Python, сравнивайте современные развивающиеся языки
Вы, даже если не сравнили, то хотя бы перечислили какие именно и для чего предлагагаете сравнивать.
В точку! автор прав, но это справедливо только для некоторой части рынка.
Но к сожелению это не относится к одной из самых крупных индустрий — игровой. Там проблемы с оптимизацией, которые последнее время стали бичем ААА проектов, равносилен провалу и убыткам.
Но к сожелению это не относится к одной из самых крупных индустрий — игровой. Там проблемы с оптимизацией, которые последнее время стали бичем ААА проектов, равносилен провалу и убыткам.
ИМХО статья несколько найвна, всё зависит от задачи.
Архитектура приложения и технологии выбираются исходя из постановки задачи и требований.
Если вам нужно приложение в короткие сроки ваш заказчик должен понимать чем он рискует и какие возможности буду ущемлены.
Другое дело если заказчик ставит изначально целью высоконагруженную систему которой точно будут пользоваться милионы пользователей. Для таких случаев систему требуется проектировать по другому и использовать другие технологии для возможностей горизонтального и вертикального маштабирования.
А Python отлично занимает свою нишу среди других ЯП и справляется со своими задачами в сферах big data & machine learning. Сравнивать его с другими ЯП как сравнивать молоток и ножницы.
Архитектура приложения и технологии выбираются исходя из постановки задачи и требований.
Если вам нужно приложение в короткие сроки ваш заказчик должен понимать чем он рискует и какие возможности буду ущемлены.
Другое дело если заказчик ставит изначально целью высоконагруженную систему которой точно будут пользоваться милионы пользователей. Для таких случаев систему требуется проектировать по другому и использовать другие технологии для возможностей горизонтального и вертикального маштабирования.
А Python отлично занимает свою нишу среди других ЯП и справляется со своими задачами в сферах big data & machine learning. Сравнивать его с другими ЯП как сравнивать молоток и ножницы.
Расскажите эти сказки производителям батареек. Они очень порадуются и расскажут как увеличить их емкость в сто раз.
Да, питон медленный, но иногда(давненько на хабре видел) питоп побыстрее плюсов. Но это редкость)
А можно ссылку? Прям даже интересно
Питон относительно медленно работает с простыми объектами типа чисел, но относительно быстро со сложными — хэш-таблицы и т.д. А множество встроенных функций для их обработки (всякие сортировки, поиски, слияния и пр.) написаны на C людьми, которые в этом разбираются гораздо лучше среднего C/C++ программиста, чья кастомная реализация наверняка будет медленнее. Что не отменяет того факта, что для C/C++ уже полно библиотек, которые делают то же самое.
А ещё Python уже давно двигается в сторону ленивых вычислений везде, где это оправдано. Это один из поводов переходить на Py3.
Но ведь это не совсем «но иногда(давненько на хабре видел) питоп побыстрее плюсов».
Я помню такую статью. Насколько я помню автор написал два файла на Си. В одном объявлялась функция для сложения двух чисел int, а во втором вызывалась. И аналогичный код на Python. И засчёт того, что компилятор Си анализирует файлы только по отдельности, питоновская версия получалась быстрее. Но точно не помню.
Ага, я кажется видел что-то подобное но связанное с PyPy (возможно даже в их блоге).
Но это ведь спекуляция, по сути? Если дать компилятору заинлайнить ф-ию, то сишная версия будет как минимум так же быстра.
Но это ведь спекуляция, по сути? Если дать компилятору заинлайнить ф-ию, то сишная версия будет как минимум так же быстра.
это невозможно как минимум потому, что питон хранит инты в куче и на создание/освобождение каждого инта в питоне уходит больше времени, чем на простой вызов (пусть и не встроенной) функции.
Да, такое бывает в случае, когда Python используется просто как обёртка над вылизанной и оптимизированной нативной библиотекой, то есть скорость выполнения зависит не от скорости интерпретации Python, а от производительности библиотеки.
Если для выполнения одной и той же операции C++ программист будет использовать более медленную библиотеку, то в данном случае код на Python будет более быстрым.
Пример: библиотеки для работы с регулярными выражениями. Стандартная библиотека C++ в этом отношении очень медленная, поэтому её обходят все, кому не лень.
Разработка на python действительно достаточная быстрая. Недостаток в производительности компенсирую за счет pyopencl(заодно можно запускаться на GPU).
Время на решение задачи на C меньше, чем на Java (и C++)?
Это что за задача такая? Задачу в студию! Хочу ознакомиться и лично сравнить.
Это что за задача такая? Задачу в студию! Хочу ознакомиться и лично сравнить.
Вопрос не в задаче, я думаю, вопрос в решении.
Если Вы вместо строки на С типа
if (A>B) do_something(); else do_other();
начнете создавать класс для A и делать у него перегруженный метод сравнения, одним из вариантов будет выше приведенное выражение, то да, время на подобные экзерсисы уйдет больше.
Недавно был диспут на подобную тему в ответ на заявление «Ну тут нужна фабрика ....».
Если Вы вместо строки на С типа
if (A>B) do_something(); else do_other();
начнете создавать класс для A и делать у него перегруженный метод сравнения, одним из вариантов будет выше приведенное выражение, то да, время на подобные экзерсисы уйдет больше.
Недавно был диспут на подобную тему в ответ на заявление «Ну тут нужна фабрика ....».
Это все хрень, которую зачем-то проталкивают вот такие авторы статей. У любого уважающего себя программиста на любом языке программирования есть инструментарий, с помощью которого он может быстро решить типичный набор задач. Никто не будет писать свой класс строки на плюсах, несмотря даже на то, что в стандартной либе поддержка так себе.
Мне кажется, отлично все эти споры разруливает Геннадий Короткевич под ником tourist, почти что ежегодный победитель соревнований Яндекс.Алгоритм, Google Code Jam и многих других. А фишка в том, что они пишет везде, где возможно, на Pascal. Хотя казалось бы.
Мне кажется, отлично все эти споры разруливает Геннадий Короткевич под ником tourist, почти что ежегодный победитель соревнований Яндекс.Алгоритм, Google Code Jam и многих других. А фишка в том, что они пишет везде, где возможно, на Pascal. Хотя казалось бы.
Зашел посмотреть его решения на Codeforces. Сплошь и рядом С++.
Ну как бы задача решения олимпиадных задач и задача промышленного программирования — это очень разные вещи. В олимпиадных задачах обычно не так много кода, довольно много работы с числами и жесткий лимит времени выполнения кода при выходе за который задача не засчитывается. А заниматься переписыванием узких мест на компилируемый язык просто нет времени, потому что решить надо всё как можно быстрее. Это не очень похоже на то, с чем обычно приходится сталкиваться в реальной жизни
Вопрос в решаемой задаче. Если внешнее устройство типа онлайн-кассы отвечает с задержкой в секунду, то нет никакого смысла бороться за доли секунды. Питона+GTK3 хватает за глаза.
У онлайн-кассы есть другая проблема — надёжность. Я бы не стал использовать Python, когда нужны какие-то реальные гарантии.
То есть питон, менее надежен чем любой другой язык?
Динамическая типизация это + N багов отлавливаемых только во время выполнения.
То есть в установке неверного типа, виноват язык а не программист, который позволил неверному типу в то или иное место программы?
Второй момент, типизация хоть и динамическая но сильная, и поэтому все баги с типами которые Вы описываете, целиком и полностью вина программистов… у нас тут массивы с числами не складывают.
Второй момент, типизация хоть и динамическая но сильная, и поэтому все баги с типами которые Вы описываете, целиком и полностью вина программистов… у нас тут массивы с числами не складывают.
Виноват программист, но в языках со статической типизацией ошибка вылезет в худшем случае на этапе компиляции, а вообще IDE сама подскажет, что с кодом что-то не так.
Нужно решить задачу, а не разобраться на кого возложить вину. В типизированных языках на этапе компиляции можно отсеять кучу явных багов.
Я не могу сказать про любой. Я про C/C++. На этих языках вы, приложив некоторые усилия, можете написать ПО, предъявляющее какие-то гарантии времени выполнения (в пределах, допустимых операционной системой и железом). На питоне заниматься системным программированием тоже можно, но подводных камней и ограничений слишком много.
Если под надежностью Вы подразумеваете время отклика онлайн кассы, в пределах опять таки железа, то тут ни Си ни любой другой язык не сможет этого обеспечить, из за присутствия сети между терминалами.
Второй момент, с которым я солидарен с автором, что критический участок можно переписать на Си/ASM и прочее, но зачем простите писать на Си бизнес логику? Или например UI? При умеренных количествах Python может реализовать отличный UI, при очень скромных затратах на разработку.
В целом, думаю данный разговор можно свести к утверждению «на каждую задачу — свой инструмент», но мне кажется, утверждать без контекста что питон — ненадежен, это реально преувеличенно и совершенно неверно.
Второй момент, с которым я солидарен с автором, что критический участок можно переписать на Си/ASM и прочее, но зачем простите писать на Си бизнес логику? Или например UI? При умеренных количествах Python может реализовать отличный UI, при очень скромных затратах на разработку.
В целом, думаю данный разговор можно свести к утверждению «на каждую задачу — свой инструмент», но мне кажется, утверждать без контекста что питон — ненадежен, это реально преувеличенно и совершенно неверно.
Я не про время отклика. В питоне довольно трудно писать адекватные обработчики сигналов, особенно когда начинается мультитрединг/мультипроцессинг и всё в таком духе. В стандартной библиотеке все модули работают на глобальных локах, так что элементарное логирование может повесить программу и убить логику завершения транзакции, например.
А почему бы не запускать UI в одном-двух потоках, а все остальное написать на С/С++ и пусть себе работает в многих потоках, посылая сообщения в UI? Я никогда не писал на питоне UI больше пары полей ввода, но вдруг стало интересно, насколько возможно в нем создать сложный асинхронный интерфейс к многопоточному приложению.
Мне кажется, что Python для UI — не лучший выбор. Если речь идёт исключительно об UI, то почему бы не использовать для этого более удобные средства, да хоть те же WinForms?
потому что это win forms
Ну как раз-таки UI я бы предпочёл писать на Питоне. Другое дело, что годных библиотек для этого как-то не видно на горизонте, но если бы они были, уверен, Питон бы отлично справился.
Мой опыт пока что показывает, что предоставление гарантий в одном месте приводят к их исчезновению в другом. Да, в питоне можно намудрить с типами, но в результате обработать исключение и восстановить процесс выполнения. В С можно намудрить с памятью-указателями, разыменовать null и получить необрабатываемый Access Violation. Умные указатели помогают, но всегда находится другой метод намудрить, источник багов воистину неиссякаем.
Хотя в том, что Pytjon не самый подходящий язык для системных задач — я полностью согласен. Но мы вроде бы и не про них сейчас.
Хотя в том, что Pytjon не самый подходящий язык для системных задач — я полностью согласен. Но мы вроде бы и не про них сейчас.
Графики, конечно, это да. Наверное, брался срез среди каких-то ученых, которым писать на Perl, Python быстрее чем на Java/.Net. Все соревнования показывают, что практически код одинаково пишется на всех языках С++, Java, Pascal (если умеешь писать конечно). По себе могу сказать, что пишу код быстрее, чем на python и чем другие пишут на питоне, правда, они вообще очень медленно пишут на Java. Знаю людей, которые еще быстрее пишут на С++.
Вброс про производительность против продуктивности не засчитан. Выучи язык и пиши на нем, если человек выучил только питон, то это его трудности.
Вброс про производительность против продуктивности не засчитан. Выучи язык и пиши на нем, если человек выучил только питон, то это его трудности.
А если человек выучил и Питон, и C++? :)
Вы не поверите, на питоне я буду писать скрипты не более 500 строк (примерно естественно). После этого объёма я возьму компилятор, бьющий по рукам хоть немного. Потому что в динамике любой мало-мальски объёмный рефакторинг — боль.
Отчего же, охотно верю. Но это отражает удобный Вам подход к разработке. Я, например, прежде чем кодить собственно проект, пишу много маленьких эскизов-черновичков, в которых решаются-проверяются-тестируются частные задачи-идеи-библиотеки, предположительно необходимые для реализации проекта. А потом вспоминаю паттерны проектирования и пишу большое полотно с учётом общей картины (видение которой как раз формируется на эскизном этапе). Причём подобным образом работаю и на С++ и на Питоне (надо ли говорить, что на Питоне в таком стиле работать удобней). Кстати, в последнее время стал замечать, что «большое полотно» всё чаще оказывается не таким уж большим, если правильно подобрать «фреймворк».
Что касается ошибок, отлавливаемых во время компиляции — ну вот честное слово, не припомню, чтобы на Питоне меня долго мучил какой-то неуловимо-критичный баг, связанный именно с перепутыванием типов (да, бывает, конечно же, но отлавливается очень быстро — активное использование аннотаций типов служит хорошую службу).
Про порог в полтысячи строк не совсем ясный принцип — это на весь проект или на один модуль (класс, компонент)?
Что касается ошибок, отлавливаемых во время компиляции — ну вот честное слово, не припомню, чтобы на Питоне меня долго мучил какой-то неуловимо-критичный баг, связанный именно с перепутыванием типов (да, бывает, конечно же, но отлавливается очень быстро — активное использование аннотаций типов служит хорошую службу).
Про порог в полтысячи строк не совсем ясный принцип — это на весь проект или на один модуль (класс, компонент)?
Дело вкуса и подхода. Я скорее пишу первичный каркас, на который навешиваю дополнительные плюшки и рефакторю по мере необходимости. Вот в процессе такой "перестройки" система типов помогает очень сильно.
Я сталкивался с подобным. Конечно подобные баги "мучили" меня не неделю и не день, а часа 2-3. Но осадочек остался. По поводу аннотаций — я работал с 2.7, и скрипт был подсобный, для прогона своего рода интеграционных тестов. Собственно, я столкнулся с неприятностями на немного извратном сравнении двух JSON документов.
Порог на один файл, и конечно очень условно. За счёт того, что питон таки умеет инкапсулцию на уровне файлов. Читаемым и легко поддерживаемым может быть и 1000-строчный скрипт.
сейчас работаю на проекте на C++ и смотрю в сторону Python, потому как просто нравится. Я диплом на нем написал за 1.5 дня, а на cpp заняло бы минимум 1 неделю
Удачи в использовании браузера, в написании которого программисты руководствовались идеей «производительность не важна».
Она не важна ровно до тех пор, пока не становится важна.
Она не важна ровно до тех пор, пока не становится важна.
Мы живём в эпоху тормозных неотзывчивых интерфейсов.
Браузер тут скорее в качестве исключения, как пример штучного оптимизированного приложения. Вся электроника ужасно тормозит — давно вы видели быстрый интерфейс в банкомате, информационное табло, которое сразу реагируюет на нажатия или телевизор без секундной задержки на любое действие?
Браузер тут скорее в качестве исключения, как пример штучного оптимизированного приложения. Вся электроника ужасно тормозит — давно вы видели быстрый интерфейс в банкомате, информационное табло, которое сразу реагируюет на нажатия или телевизор без секундной задержки на любое действие?
В веб-разработке важен только один показатель скорости — как быстро веб-приложение работает с точки зрения пользователя. Вот это и надо оптимизировать.
У меня впечатление, что я слышал эту мантру 10 лет назад.
Есть конечно задачи, которые отлично масштабируются горизонтально; есть задачи, где СУБД в любом случае узкое место. Но есть и задачи, в которых в зависимости от качества (говно)кода пользователь будет ждать или секунду, или минуту.
Правда, в таких случаях больше на скорость влияют эффективные алгоритмы, а не языки. И, кроме оптимизации (преждевременной или нет) этих алгоритмов, мало что может помочь.
Вот сравниваю я Skype и Telegram на своём смартфоне. И становится понятно, разработчики которого из IM руководствовались принципом «зато быстро накодили и оно даже работает». Мобильным Skype невозможно пользоваться без боли.
Так вам же сказали, вам просто мощнее смартфон надо купить, это дешевле времени разработчика
Кстати, да, вся эта демагогия про «время разработчика дороже» имеет право на существование до тех пор, пока затраты на отсутствие оптимизации не перекладываются на пользователей. ВСЕХ пользователей. Таким образом принцип — «лучше сэкономить на разработке» работает только с бэкендом онлайн приложений. А фронтенд уже работает в браузере и его извольте оптимизировать. Не только под последний Chrome. Не только под последний макбук разработчика. А для десктопных приложений, мобильных приложений производительность имеет большое значение. При прочих равных люди будут выбирать Telegram вместо FB Messenger, The Old Reader вместо Feedly, Google Keep вместо Microsoft OneNote и т.д.
Не мощнее, а ещё один.
Тема сравнения с perl не раскрыта. Зачем в вашей метрике продуктивности нужен питон, когда есть перл?
Питон аккуратно спроектирован, прямо вылизывается создателями, они всё стараются делать логично, выразительно, прямо радуешься когда читаешь как оно в питоне, а перл это перл, это альтернативное видение и синтаксиса и концепции ЯП — сигилы, глобальные переменные, контексты и так далее.
Эм, вас перл заставляет использовать глобальные переменные? use strict, my/our вот это всё. В перле есть довольно много разумных неявных умолчаний, удобных для его класса задач — сколько там строчек в питоне займёт аналог while(<>) { s/--MYVAR--/$ENV{MYVAR}/; print ;}? Другое дело, что если вам нужен не однострочник «прям щас», а нужен код, который прочитают и будут поддерживать другие люди, на перле надо писать как на питоне или на java. Но он не заставляет вас так делать (а питон да, пытается).
В приведённом вами коде используются как минимум две глобальные переменные.
Ваш пример годится только для однострочника, накиданного в командной строке по месту. Как только вы захотите переиспользовать этот код — упрётесь в чтение этой клинописи. Почему-то многие при сравнении "одноразовых" языков и "многоразовых" не учитывают, что сам автор может и не прочитать своё творение через недельку — из-за того, что писал в клинописном стиле.
По поводу use strict/my/our — у меня есть перед глазами замечательный пример в виде основного инструмента, С++. Языка, на 50-60% состоящего из легаси. Можно писать хорошо и красиво — но для этого придётся написать свою мини-обвязку, а также следовать правилам, в порверке которых компилятор вам просто так не поможет. Короткий вывод — есть языки, на которых легко писать криво и неправильно — и есть языки, на которых если писать криво и неправильно, придётся постоянно ублажать компилятор "обходными манёврами".
Ну тут уже вопрос вкусовщины/личного комфорта/корпоративных стандартов/сложности поддержки в долгую. Основной поинт автора статьи был в том, что интерпретируемые языки с динамической типизацией и компактным синтаксисом в лице питона экономят время программиста, которое — ключевой ресурс. При этом ровно в метрике времени на решение разовой задачи перл не хуже питона, как минимум. Другое дело, что да, питон строже и наваять на нём странный стрёмный нечитаемый код — сложнее. Но не невозможно. И да, если писать на перле с нужной обвязкой (какой-нибудь perlcritic на pre-commit навесить, например) — должно получаться неплохо. Но свобода этого не делать — остается.
Как по мне, вырисовывается вполне себе зависимость, где объём свободно поддерживаемого кода обратно пропорционален условной сложности компилятора
- На перле или APL/K (из-за эзотеричности их синтаксиса) легко писать короткострочники, но код средних размеров уже может стать нечитаем. Уточню, что и Перл может быть читаем в среднем объёме, если не использовать "клинопись".
- Питон, человеческий перл, яваскрипт и т.п. динамика читаемы и поддерживаемы в рамках среднего объёма (мои наблюдения — в среднем 500, до 1000 значащих строк). И в этом объёме в среднем более продуктивны чем языки со статической типизацией. Так как содежимое модуля и связи внутри вполне можно удержать в голове.
- Всё что выше — требует статической типизации, т.к. кол-во связей и общий объём уже таков, что прилетевший из ниоткуда инт вместо строки в рантайме приводит к боли при отладке. А транслятор в этом помогать не желает. И рефакторинг превращается в охоту за тараканами.
Биллинг на ~400 000 значащих строк на перле, строгие конвенции на проверку и передачу параметров (т.е. эмуляция статической типизации на уровне взаимодействия компонент), объектная модель, клинопись выпилена, юнит-тесты местами (увы), ~70% функций влезают в экран — полёт нормальный. Да, есть вещи, которые «пора бы отрефакторить», время от времени это делается. Может быть, если это вот всё делать сейчас и с нуля — покурить про язык можно было бы с большим выбором, но особого смысла переписывать столько с нуля сейчас нет и не предвидится — сложность поддержки вполне разумная.
Про прилетевший вместо строки инт для перла (в отличие от питона, кстати) так вообще не корректно — там строка и инт — одно и то же. Больнее будет, если вам в рантайме прилетит вместо скаляра ссылка на массив.
И да, сложность компилятора у ассемблера — минимальна. А вот поддерживать на нём даже 1000 строк — кошмар на улице вязов, имхо. Или это будут вставки по 10 строчек в C/C++.
А я Рома, пишу на Perl и мне не стыдно )))
Через лет 10 автор поймет, что язык Х не важен на начальном этапе разработки, архитектура, дизайн и high level оптимизация должна предшествовать низкоуровневой.
Думаю, все согласятся, что статически типизированные языки менее продуктивны
Классный аргумент. Я не согласен. Зря так думал.
Вот, например, недавно вышедшая книга «Kotlin in Action» повествует:
Following are some of the benefits of static typing:
Performance — Calling methods is faster because there’s no need to figure out at runtime
which method needs to be called.
Reliability — The compiler verifies the correctness of the program, so there are fewer
chances for crashes at runtime.
Maintainability — Working with unfamiliar code is easier because you can see what kind
of objects the code is working with.
Tool support — Static typing enables reliable refactorings, precise code completion, and
other IDE features.
Хорошие статически типизированные языки избавляют от множества ошибок сразу, ещё до компиляции, на уровне автоподсказок IDE. И до этапа тестирования. Подсказки IDE в них более качественные, потому что тип известен точно в подавляющем большинстве случаев. А когда он не известен, или нужно обеспечить большую гибкость, то можно использовать, например интерфейсы (в Go), вместо лямбд, которые возвращают чёрт-знает-что.
В итоге обеспечивается fearless refactoring — одна из заповедей TDD.
Так что давайте смотреть на продуктивность шире, чем количество строк.
В итоге обеспечивается fearless refactoring — одна из заповедей TDD.
Так что давайте смотреть на продуктивность шире, чем количество строк.
Меня не радует то, что так много кода в мире, от которого всё больше зависит наша жизнь, создаётся программистами, у которых плохо с логикой. Автор этой статьи не исключение, поскольку начав с того, что одной из причин, по которой люди отказываются от Python — это его медленная скорость, продолжает доказывать, что нет причин этого делать потому что: 1) скорость не важна 2) Python быстрый.
И как-то выпадает из этого доказательства то, что скорость Python — это далеко не единственный и, возможно, не главный недостаток. Главным недостатком, на мой взгляд, является слабая ошибкоустойчивость Python, которая всё с возврастающей нелинейной силой начинает проявляться по мере роста размера и сложности проекта. Для чего-то простого Python вполне приемлем, для чего-то сложного или ответственного — нет.
Ах да, скорость языка тоже важна для целей корректности программы, так как позволяет использовать более простые, а потому и более надёжные решения там, где для медленных языков придётся изгаляться.
И как-то выпадает из этого доказательства то, что скорость Python — это далеко не единственный и, возможно, не главный недостаток. Главным недостатком, на мой взгляд, является слабая ошибкоустойчивость Python, которая всё с возврастающей нелинейной силой начинает проявляться по мере роста размера и сложности проекта. Для чего-то простого Python вполне приемлем, для чего-то сложного или ответственного — нет.
Ах да, скорость языка тоже важна для целей корректности программы, так как позволяет использовать более простые, а потому и более надёжные решения там, где для медленных языков придётся изгаляться.
является слабая ошибкоустойчивость Python, которая всё с возврастающей нелинейной силой начинает проявляться по мере роста размера и сложности проекта
Обоснуете, или оценочное заявление?
Это стандартная особенность скриптовых языков — то, что хорошо для экономии строчек, плохо в отношении ошибкоустойчивости. Та же статическая типизация не только способствует скорости, но и позволяет вылавливать ошибки раньше. Чем больше программа — тем сложней её связи и тем больше в ней ошибок и вероятность их проявления и последствия от них. Тем критичней возможность отлавливать ошибки как можно раньше.
В последних версиях Python появилась возможность указать тип.
Это не делает его статически типизированным, если тип может изменяться по ходу дела.
def static_typing(i: int) -> int:
return "bla bla bla"
print(static_typing(11))
Вы правы, не делает. Но ошибки отлавливать стало проще с использованием MyPy https://www.google.com/amp/s/ericjmritz.wordpress.com/2015/10/08/static-type-checking-in-python-using-mypy/amp/.
В дополнение к этому, например, PyCharm подсвечивает потенциальные ошибки прямо в редакторе.
Зачем иметь сторонние тулзы если проверки типов можно встроить в сам язык? Мне сторонники динамических языков напоминают диких велосипедостроителей: сначала объявляем статическую типизацию злом, а потом начинаем впиливать собственную костыльную реализацию с помощью комментариев/атрибутов/специальных тулчейнов… Меня не оставляет вопрос — зачем, если можно довериться профессиональным решениям?..
Были у меня большие программы на питоне. Не помню ни разу, чтобы сложная проблема была последствием использования динамической типизации. Вот всякие race conditions, логические недоработки или просто ошибки в рассчетах — этого навалом, но что-то я не слышал, чтобы статически типизированные языки от подобного были защищены.
100 000 циклов CPU — на мой взгляд, это слишком абстрактно. Взял более близкое мне понятие: считается, что 0.1 с на генерацию веб-страницы — это достаточно быстро. По шкале из статьи, на которую ссылается автор, это 10 лет. Практически эквивалентно сетевым задержкам (туда 4 года и обратно 4 года).
И тут уже выбор языка, который медленнее в 5 раз, смотрится совсем по-другому
И тут уже выбор языка, который медленнее в 5 раз, смотрится совсем по-другому
Скорость была не важна года 3 назад. А нынче спираль пошла на новый круг и производительность снова готовится сесть на коня.
железо сейчас дёшево как никогда
а кто его покупать пользователям подобных поделок будет — компания? Или если имеется в виду только серверное оборудование и узкий круг веб-разработки — то так и надо писать.
Во-первых, автор обходит стороной вопрос о памяти (точнее, пишет, что раньше ресурсы процессора и памяти были дорогими, и дальше пишет только про CPU). Постепенно память становится все более узким местом — она дешевеет гораздо медленнее (в последний год в некоторых сегментах вообще подорожала), а упереться в нехватку памяти — это сразу либо резкое замедление работы (если swap есть), либо падение приложения.
Во-вторых, он сравнивает 'median hours to solve problem', и это неправильно. В реальных проектах важно среднее, а не медиана — потому что среднее учитывает те 10-20% затянувшихся задач, которые в итоге и тормозят весь проект, а медиана — нет.
Во-вторых, он сравнивает 'median hours to solve problem', и это неправильно. В реальных проектах важно среднее, а не медиана — потому что среднее учитывает те 10-20% затянувшихся задач, которые в итоге и тормозят весь проект, а медиана — нет.
Все сводится к задачам. Например, если вы занимаетесь скрапингом, то в 99% скорость вообще не имеет значения, т.к. все равно вы будете выставлять тайм-аут для избежания бана и т.д. Однако, можно с лёгкостью привести пример, когда производительность крайне важна. Хотя я согласен с мнением автора.
В ограниченном микросервисами и вебом мирке автора питон возможно действительно fast enough (хотя с этим тоже можно спорить). Но микросервисами разнообразие ПО не ограничивается.
Ядро ОС на питоне? СУБД на питоне? Может быть 3D? Ну хотя бы шифрование? Прошивка маршрутизатора на питоне?
Пользователю у которого тормозит софт на телефоне тоже предлагается кластер на пару десятков серверов в кармане носить?
В Питоне плохо без типизации. Для микросервисов ок, но когда проект подрастает — уже хочется больше проверок на этапе компиляции. Для прототипов и автоматизации действительно круто, потому что можно написать
Питон хорош, но не идеален, поэтому везде пихать не надо, как и любой другой язык…
import redmine # redis, pymongo, etc.
# Do something
Питон хорош, но не идеален, поэтому везде пихать не надо, как и любой другой язык…
чтобы написать код для обработки строк на разных языках
Ну, как бы на java можно написать и медленный код через стринги и быстрый через стрингбилдер, байты и прочие прибамбасы.
Не знаю что насчет общих задач, но, например, для парсинга скорость играет большое значение. Приведу пример из практики: ANTLR парсер кода PHP на Python работает примерно в 30 раз медленнее C#, вот issue на GitHub: Extremely Poor Performance Parsing PHP. Соответственно если в C# парсинг будет практически незаметен, то в Python придется ждать секунд 15. И в этом случае я пожалуй другой язык выберу.
Более того, динамическая система типов в Python будет адом при обработки древовидных структур. И в том же ANTLR я уже фиксил баг в рантайме, которого не было в статических языках из-за проверок на этапе компиляции.
Нужно исходить из бизнес-целей
1) Делается изначально веб-проект, где подразумевается много изменений и сдвигов = php/python/ruby
2) Проект вырос и начались траблы в каких-то местах? Перепиши ряд ключевых библиотек на C
3) Проект вырос и дает стабильное бабло? Перепиши проект на Java/C#
Вот такой алгоритм работы, который работает достаточно хорошо. И решает бизнес цели.
И хочется сказать сразу, что большая часть проектов остаются на 1 этапе. Некоторые переползают на 2 этап и буквально единицы на 3.
1) Делается изначально веб-проект, где подразумевается много изменений и сдвигов = php/python/ruby
2) Проект вырос и начались траблы в каких-то местах? Перепиши ряд ключевых библиотек на C
3) Проект вырос и дает стабильное бабло? Перепиши проект на Java/C#
Вот такой алгоритм работы, который работает достаточно хорошо. И решает бизнес цели.
И хочется сказать сразу, что большая часть проектов остаются на 1 этапе. Некоторые переползают на 2 этап и буквально единицы на 3.
3) Проект вырос и дает стабильное бабло? Перепиши проект на Java/C#Зачем если все хорошо?
Если и переписыать, то только если это даст положительный экономический эффект.
если проект не растет, значит он скоро начнет сбавлять обороты (пользователям наскучит). А если растет, то рано или поздно дорастет до кондиции, когда сервера не будут справляться. Разве что и Java, и C# — плохой выбор языка для серверного приложения
Знаете я тут после Джанги 1.10 попробывал Rails 5 — и заметил разницу в скорости старта ./manage.py runsever и rails s — невооруженным глазом.
Многие технологии в том числе и языки — вкусовщина. Кто-то может писать быстрый и надёжный код на Go или Java (Scala, Kotlin) продуктивней чем на Python. А в итоге получит ещё и прирост производительности. К чему это я?
Да — каждый инструмент под задачу, да — кто-то знает лучше технологию А чем B, но имхо, в современном мире энтропия технологий достигла такого уровня, что всегда есть некоторый пулл из них, в котором они приблизительно равны по требованиям к уровню инженера и скорости разработки, но среди них есть набор таких, что они просто работают лучше / быстрее / надёжнее архитектурно.
Да — каждый инструмент под задачу, да — кто-то знает лучше технологию А чем B, но имхо, в современном мире энтропия технологий достигла такого уровня, что всегда есть некоторый пулл из них, в котором они приблизительно равны по требованиям к уровню инженера и скорости разработки, но среди них есть набор таких, что они просто работают лучше / быстрее / надёжнее архитектурно.
Ну просто человек хорошо знает питон. Если мне надо быдл бы очень-очень быстро нафигачить простой бэк-енд, то я месяц назад ещё взял бы питон или перл (поскольку скилы набиты).
Сейчас поигрался с expressJS и если бэкенд REST — буду писать на JS. Просто JS нравится больше Py, а разница в инструменте для меня минимальная — и так можно и так.
Сейчас поигрался с expressJS и если бэкенд REST — буду писать на JS. Просто JS нравится больше Py, а разница в инструменте для меня минимальная — и так можно и так.
Очень-очень быстро (прям вот если очень-очень быстро) — это Вам на PHP надо писать, синтаксис просто песня. В прямом смысле. Плюс для веба заточен.
Ну можно взять PHP, но для меня на питоне быстрее. Хотя бы потому, что больше библиотек и функций помню. И в маны буду лазать меньше.
Если по условиям задачки есть только PHP, тогда другое дело. Из того, что провайдеры предлагают за копейку из коробки — пхп абсолютный лидер.
Так что сарказм не очень уместен. Если инструмент подходит к задаче и он есть в наличии, то надо брать ржавую лопату и копать, а не мечтать о сияющем экскаваторе. Особенно там, где копать -то пару часов)
Если по условиям задачки есть только PHP, тогда другое дело. Из того, что провайдеры предлагают за копейку из коробки — пхп абсолютный лидер.
Так что сарказм не очень уместен. Если инструмент подходит к задаче и он есть в наличии, то надо брать ржавую лопату и копать, а не мечтать о сияющем экскаваторе. Особенно там, где копать -то пару часов)
Суть статьи в полутора предложениях
… и теперь пришли к выводу, что уже сам Python является узким местом. Но он имеет возможность вызова кода на C…
Для питона очень легко пишутся расширения на C/C++. Кроме того есть уже библитеки для выноса операций в C-код, например numPy даёт сразу оптимизацию в полпорядка при работе с массивами.
Есть две вещи, за которые я не фанат питона:
— артефактный к другим языкам код (сложно переключаться)
— obj['key'] — вызывающий эксепшен (вот бесит меня писать obj.get('key')
… и теперь пришли к выводу, что уже сам Python является узким местом. Но он имеет возможность вызова кода на C…
Для питона очень легко пишутся расширения на C/C++. Кроме того есть уже библитеки для выноса операций в C-код, например numPy даёт сразу оптимизацию в полпорядка при работе с массивами.
Есть две вещи, за которые я не фанат питона:
— артефактный к другим языкам код (сложно переключаться)
— obj['key'] — вызывающий эксепшен (вот бесит меня писать obj.get('key')
Согласен. Переключаться с питона сложно — свой синтаксис=)
— obj['key'] — вызывающий эксепшен (вот бесит меня писать obj.get('key')
Извиняюсь за некропост, но не понял пример с гетом. Почему не подходит obj.key?
Во втором питоне (не знаю как в третьем) обращаться к ключу объекта dict как к свойству нельзя. Если же мы обращаемся к не существующем ключу как к ключу, то вылезает исключение и все ломается. get гарантирует, что мы не получим исключения при несуществующем ключе.
Вы просто написали obj, я не понял, что вы про словарь. Словарь — это частный случай.
Так это наоборот меня радует после пхп. Есть куча вариантов:
— названный вами get
— if 'key' in obj
— try / KeyError
— использовать свой объект (об этом ниже)
Возможно в каких-то ситуациях вам и не нужен словарь, а больше подойдет свой объект. А в объекте можно перегрузить поведение обращения к атрибуту.
В вашем примере вы же все равно потом делаете проверку, вернул ли вам словарь значение по ключу, верно? Поэтому ваш пример — иллюзия упрощения. Но может я неправильно вас понял, приведите кусок кода, вдруг посоветую что подходящее.
Так это наоборот меня радует после пхп. Есть куча вариантов:
— названный вами get
— if 'key' in obj
— try / KeyError
— использовать свой объект (об этом ниже)
Возможно в каких-то ситуациях вам и не нужен словарь, а больше подойдет свой объект. А в объекте можно перегрузить поведение обращения к атрибуту.
В вашем примере вы же все равно потом делаете проверку, вернул ли вам словарь значение по ключу, верно? Поэтому ваш пример — иллюзия упрощения. Но может я неправильно вас понял, приведите кусок кода, вдруг посоветую что подходящее.
В реальной жизни много ситуаций, когда что-то не заполнено или недополучено, потому что по сути является опциональным. И мне хочется писать в таких случаях кратко.
Случаи, которые нужно обрабатывать отдельно, я сам обработаю. А где нужно выкинуть исключение выкину его сам. Мне не очень нравится, когда из-за минорной ошибки, падает приложение.
Но на вкус и цвет фломастеры разные. Кому-то нравится контроль кода во времени исполнения, кому-то нет.
Вы не привели пример. Просто еще раз повторили те же доводы. Я уже объяснил, зачем нужен пример.
Типичный пример: кофигурационный файл. Второй типичный пример JSON или RPC ответ от сервера.
Вообще человеку проще разбирать структуру, в которой опциональным ключи отсутствуют.
Поэтому их возвращает много кто.
Типичный пример: кофигурационный файл. Второй типичный пример JSON или RPC ответ от сервера.
Да теории то я достаточно увидел, я просил пример кода. Мне чрезвычайно любопытно, как вы организуете программный поток без проверки на несуществующий ключ. Не само получение ключа, а что дальше происходит.
Всю голову сломал, придумал только случай, когда все директивы в конфиге или ключи в JSON булевы, и в этом случае вроде как можно пропустить проверку (что тоже не очень ортодоксально). Но больше придумать не смог.
Мне бы ваши проблемы)
В конф файле у нас может быть указано имя файла. Если имя файла не указано или пустое или false, то файл не обрабатываем.
В моём случае: десериализация JSON в строго типизированную структуру и дальнейшая работа с ней. Правда, это не Python.
Код:
var s = json.Deserialize<SomeStruct>();
...
if (s.Param.HasValue) ...
На самом деле, если посмотреть на время расцвета Java в начале 200x, скорость Java на тех железяках была еще меньше. Однако это не помешало Java занять свое место под солнцем.
Многие реальные практические задачи, с тех пор не изменились по нагрузке.
Многие реальные практические задачи, с тех пор не изменились по нагрузке.
но они никогда не заметят разницу между 35 мс и 25 мс
Посмотрите на этот онлайн секундомер:
http://sekundomer.net/
— и убейте меня. Я замечаю.
Да, сама по себе статья хорошая. Но не этот кусок. Тут автор оригинала ляпнул не проверив.
В смысле, как вы это замечаете на этом сайте? Я пробел-то не успеваю нажать быстрее 100 мс, о чем речь вообще?
Не в прямом смысле, конечно: частота мерцания монитора — 60 герц, а это 18 тысячных секунды на одно обновление экрана и всяко разно оно что-нибудь «съест» из этой секунды, поделённой на тысячные доли.
Но при должной концентрации можно начать выделять эти моргания, то есть — они не сливаются в сознании, а идут урывками.
Скорость нажатия клавиши пальцем упирается в вашу скорость реакции и нервного импульса, а также в скорость вставания клавиши пробела в то положение, из которого его можно было бы нажать заново.
А скорость восприятия времени зрительно упирается только в скорость мысленного сравнения двух изображений, которая может быть много быстрее.
Возьмите игру на скоростное сравнение — поймёте, о чём речь. В этом плане мозг может быть очень быстрым.
Но при должной концентрации можно начать выделять эти моргания, то есть — они не сливаются в сознании, а идут урывками.
Скорость нажатия клавиши пальцем упирается в вашу скорость реакции и нервного импульса, а также в скорость вставания клавиши пробела в то положение, из которого его можно было бы нажать заново.
А скорость восприятия времени зрительно упирается только в скорость мысленного сравнения двух изображений, которая может быть много быстрее.
Возьмите игру на скоростное сравнение — поймёте, о чём речь. В этом плане мозг может быть очень быстрым.
Ну слушайте, вы уж совсем за уши притягиваете. При чём тут моргания, которые при должной концентрации можно рассмотреть? Речь идет о скорости обработки запроса пользователя, и его восприятии этого. Что 25, что 35 мс — это воспринимается как мгновенно, реальный пользователь реальной системы разницы абсолютно не заметит. Об этом и идет речь, а не о разрешающей способности глаза/мозга при предельной концентрации
Это все сказки, что железо дешевое работы программиста, программисты разные и железо разное, если мы считаем VPS по 10-50 долларов в месяц и Senior с окладом 4000$ в месяц, то да, но если сервер стоит хотябы 250$, то тут другая история
по словам знакомого, который работал в яндексе, у них так часто и делали — если тормозит сервер, то им проще было добавить N гигабайт памяти, перевести на SSD, заменить на более производительный процессор, чем тратить N часов разработчиков/администраторов на поиск этих тормозов и попытку их устранить. Кстати не факт что она в итоге окажется успешной. Как минимум для dev окружения, насчет прода не помню
Интересно, что сегодня Python неофициально популярен в рамках идеологии «используй меньше Python в своих решениях».
К примеру, в WEB-разработке мы сталкиваемся с несколькими проблемами скорости Python:
1. Получение данных из хранилища и их обработка
2. Обработка данных из Request
3. Рендеринг шаблона.
Все три проблемы концептуально решаются минимизацией Python операций.
1. Большинство операций в популярных Python ORM — лишь обёртки для родных функций БД. Оптимизируя код обращения к БД, программист должен свести к минимуму обработку данных в Python.
2. Обработка данных в Request, в большинстве случаев, выносится на REST Endpoints с асинхронными обращениями. В результате, часть асинхронного программирования берёт на себя JS, который контролирует асинхронные запросы, частоту обращения к серверу и т.д. Но, если уж совсем сложная операция, на серверной стороне задействуются свои механизмы создания потоков или процессов. В любом случае, за получение результата будет отвечать JS код.
3. Аналогично дела обстоят с шаблонизаторами: мы либо используем готовые механизмы кеширования шаблонов, либо (что сегодня более популярно) делаем статику и шаблоны независимыми от Python. Благо есть ангуляры, реакты и т.д.
Полагаю, что в других отраслях существуют такие же способы обхода скорости Python, которые позволяют использовать этот язык для решения сложных задач, путём минимизации операций в интерпретаторе Python. И тут сам Python можно использовать как скриптовой язык. Вспомним тот же Ansible: Python в нём является лишь обёрткой для выполнения различных команд в среде операционной системы. Фактически, разработчики берут менее сахарный синтаксис того же bash'а и пишут скрипты на python для объединения объёмного bash кода в простые python команды.
Но вот что Python реально не может добиться, так это собственной производительности. Ему очень часто нужен чужой API для решения задачи. Однако, если осознать упомянутую концепцию «используй меньше Python в Python приложении», начинаешь учить другие языки… чтобы, как ни странно, обернуть их в Python код.
К примеру, в WEB-разработке мы сталкиваемся с несколькими проблемами скорости Python:
1. Получение данных из хранилища и их обработка
2. Обработка данных из Request
3. Рендеринг шаблона.
Все три проблемы концептуально решаются минимизацией Python операций.
1. Большинство операций в популярных Python ORM — лишь обёртки для родных функций БД. Оптимизируя код обращения к БД, программист должен свести к минимуму обработку данных в Python.
2. Обработка данных в Request, в большинстве случаев, выносится на REST Endpoints с асинхронными обращениями. В результате, часть асинхронного программирования берёт на себя JS, который контролирует асинхронные запросы, частоту обращения к серверу и т.д. Но, если уж совсем сложная операция, на серверной стороне задействуются свои механизмы создания потоков или процессов. В любом случае, за получение результата будет отвечать JS код.
3. Аналогично дела обстоят с шаблонизаторами: мы либо используем готовые механизмы кеширования шаблонов, либо (что сегодня более популярно) делаем статику и шаблоны независимыми от Python. Благо есть ангуляры, реакты и т.д.
Полагаю, что в других отраслях существуют такие же способы обхода скорости Python, которые позволяют использовать этот язык для решения сложных задач, путём минимизации операций в интерпретаторе Python. И тут сам Python можно использовать как скриптовой язык. Вспомним тот же Ansible: Python в нём является лишь обёрткой для выполнения различных команд в среде операционной системы. Фактически, разработчики берут менее сахарный синтаксис того же bash'а и пишут скрипты на python для объединения объёмного bash кода в простые python команды.
Но вот что Python реально не может добиться, так это собственной производительности. Ему очень часто нужен чужой API для решения задачи. Однако, если осознать упомянутую концепцию «используй меньше Python в Python приложении», начинаешь учить другие языки… чтобы, как ни странно, обернуть их в Python код.
Таким образом Python занимает позицию менеджера (управленца) над другими языками оторые умеют хорошо «крутить гайки».
Да, абсолютно согласен. В Питон удобно заворачивать бизнес-логику, которая обычно выполняется один раз на запрос и все равно плохо оптимизируется. Но как только дело доходит до непосредственно вычислений, итераций и всего, что упирается именно в аппаратную скорость вычислений, в бой сразу вступают сторонние библиотеки, написанные на С/C++/Cuda/etc и имеющие Python API.
Хотел бы спросить, пользуясь случаем, почему бы просто не использовать PHP, который лишен этих недостатков (а уж рендеринг шаблонов и вовсе занимает на нем не более доли секунды)? Зачем использовать язык для этого, тем более когда существует ЯП, заточенный конкретно для этого?
Потому что кроме Web, у Python есть множество других приложений, где он работает на порядок лучше, чем PHP. Я на питоне прототипирую алгоритмы и расчеты. Использовать для этого PHP мне и в страшном сне в голову не пришло бы.
Затем, что Python идеален для сетевых решений. Как ни странно, он пользуется огромной популярностью именно для распределения нагрузки при огромном объёме подключений. Серверная часть самой масштабной сетевой игры — Eve Online — была написана на python. Тому есть много причин. Но, если вкратце, то всё сводится к возможности python эффективно и сахарно задействовать решения на других языках. Это позволяет построить изящную архитектуру. PHP на это не способен. У него гораздо меньше готовых решений и обёрток. Ну а в случае с Web, мы имеем сахарный Python против усложнённого PHP. В большинстве случаев мы избавляемся от той же Jinja2 и задействуем Angular.js или React.js со сборщиком на gulp, bower или webpack. И нам требуется создать эффективный роутер запросов. Эффектичность здесь будет оцениваться колличеством файлов с кодом, их объёмом и возможностю повторного использования. На второй стадии нам потребуется ORM с такими же пожеланиями. Если у нас небольшой сайт, ORM должна давать нам возможность описать структуру и получить данные за минимальное число строк кода, с использованием самой минимальной логики. В случае с большими проектами, нам потребуется то же самое, только в больших объёмах. А значит, мы должны получать огромное число запросов, для каждого запроса создавать отдельный поток, а обработку записывать, по возможности, декларативно — в виде набора данных и команд, которые выполнятся в самой БД. И вот PHP так не может. Его роутер — это либо куча отдельных файлов в ФС, либо многотонный монстр, который с трудом повторяет функционал, хотя бы, Flask. ORM? Ну есть решения, в которых придётся написать фигову тучу строк кода и каждый запрос по отдельности. А ещё можно сказать об инвалидной модульности с непонятными пространствами имён, в которой потребуется убить время на закрытие доступа к отдельным файлам.
P.S. конечно, можно сказать, что на PHP хорошая шаблонизация… только вот беда, PHP, по сути и является шаблонизатором. При том, кривым. Вместо того, чтобы учить его работать с чистыми шаблонами, авторы стали нагружать эти шаблоны ненужной логикой. В итоге, конечно, появились достойные шаблонизаторы на пыхе… но они все просто убогие. С одной стороны, им нужно время, чтобы нарастить функционал, исправить ошибки… сдругой, нет у них времени. Сейчас идёт тенденция к отделению шаблонов в пространство Frontend со своими сборщиками и JS обработчиками. Так что, даже в условиях CMS разумнее будет выбрать python только за счёт потенциального масштабирования проекта с выносом фронта в JS фрэймворк и подключением REST API.
P.S. конечно, можно сказать, что на PHP хорошая шаблонизация… только вот беда, PHP, по сути и является шаблонизатором. При том, кривым. Вместо того, чтобы учить его работать с чистыми шаблонами, авторы стали нагружать эти шаблоны ненужной логикой. В итоге, конечно, появились достойные шаблонизаторы на пыхе… но они все просто убогие. С одной стороны, им нужно время, чтобы нарастить функционал, исправить ошибки… сдругой, нет у них времени. Сейчас идёт тенденция к отделению шаблонов в пространство Frontend со своими сборщиками и JS обработчиками. Так что, даже в условиях CMS разумнее будет выбрать python только за счёт потенциального масштабирования проекта с выносом фронта в JS фрэймворк и подключением REST API.
Немного дополню себя: мне довелось поработать с Silex. И это довольно хорошее решение. Однако, существуют уже описанные выше ограничения PHP, и несколько других, к слову сказать. Например, кривой composer. Необходимость защищать пакеты с классами при помощи .htaccess (или я чего-то не знаю о других методах ограничения исполнения) и т.д. Но тут важно знать, что фреймворки на PHP, как-правило, уже не так шустро рендерят шаблоны. А вот готовых решений для различных операций у них гораздо меньше.
Огого! Спасибо за содержательный ответ, прочитал с большим интересом! Действительно, все дело в том, что за его синтаксисом я забываю о том, что у меня у самого куча обверток для всего — для разных БД, свой шаблонизатор, несколько мегов функций на все случаи жизни, и так далее, поэтому процесс создания чего-либо на нем ничем не омрачается, без этого никуда, тут я не спорю, да и под нагрузку, он, мягко скажем, не предназначен, это да, но в его защиту хотел бы сказать, что так как он сам является, по сути, фреймворком для С, то и позволяет из коробки очень много всего того, что другие языки могут только с кучей костылей. Вот я сейчас пишу приложение для андройда на Яве как раз, это мой первый опыт действительно углубленного написания чего-либо серьезного на другом языке, но я, честно скажу, бы сильно удивлен, ибо я считал, что уж если PHP умеет очень много по дефолту, то уж типа «серьезные» языки — и подавно, однако для меня оказалось большим открытием то, что любые действия, будь то банальный trim (), массивы? запись и чтение, и тому подобное, потребует кучи костылей. Мой проект разрастается, и параллельно растет с ним и очередной мой фреймворк, только уже для явы, но только в отличии от PHP, на котором он расширял этот функционал — тут он его просто добавляет, и то хорошо :/ И Вы знаете, у меня смешанные чувства, вроде бы типа бОльшая гибкость, мобильность и все такое, другое дело, когда я «благодаря» этой абстрактной гибкости вынужден ежедневно перелопачивать весь Stackoverflow в поисках решения какой-либо относительно простой задачи, и даже если я его и нахожу — возникают вполне оправданные сомнения в оптимальности ее решения, там 90% индусов, им платят за количество кода, да, делятся своими наработками, помогают другим, похвально, но что как все это себя поведет в жизни — не известно, поэтому лично я сторонник максимального числа встроенных методов, ибо я всяко больше доверяю в этих вопросах компетенции создателей данного языка, а не непонятно кому, да и себе в том числе, у меня 10 лет опыта программирования, и то я даже себе не доверяю в таких вопросах)) Да, PHP реально те же индусы, однако всяко это лучше сторонних поделок школьников на коленке, взятых с какого-нибудь ЛОРа. Кстати, как в питоне с этим дела обстоят? И как к синтаксису, привыкли? Как-то никак не перестроится после PHP, уж там он просто для людей!
P. S. Вы, между прочем, зря .htaccess ругаете, сама эта задумка настолько удобна, что ради него даже специально ставят тяжеловесный и монструозный апач, отдавая ему статику (чтобы он хоть что-то делал, от большего серваки просто загнутся), ибо все настройки производятся по сути в одном файле, лежащем в корне сайта, для их применения не нужна даже перезагрузка (!), еще это удобно в плане удаленной настройки, вместо того, чтобы часами объяснять что и где нужно прописать и что и куда положить, достаточно прописать все настройки в одном файле и кинуть его человеку, чтобы он положил его в корень своего сайта, а уж где он находится — знает даже домохозяйка. И в этом файле будет все — и непосредственно сами настройки сервера, и формирование ссылок, и запреты на исполнение каких либо файлов, их отдачи, и т. д. На том же энджинксе нужно править не один файл, причем часто вписывать аналогичные строки одновременно в несколько файлов, причем часто с отсутствием какой-либо логики. Для меня загадка, почему ни один сервер еще такое не поддерживает. Имеются, конечно, некоторые решения, например, парсить его регулярками и перловыми скриптами чуть ли не по крону эти настройки применять, но это уже костыли, разумеется…
P. P. S. Минус не мой)
P. S. Вы, между прочем, зря .htaccess ругаете, сама эта задумка настолько удобна, что ради него даже специально ставят тяжеловесный и монструозный апач, отдавая ему статику (чтобы он хоть что-то делал, от большего серваки просто загнутся), ибо все настройки производятся по сути в одном файле, лежащем в корне сайта, для их применения не нужна даже перезагрузка (!), еще это удобно в плане удаленной настройки, вместо того, чтобы часами объяснять что и где нужно прописать и что и куда положить, достаточно прописать все настройки в одном файле и кинуть его человеку, чтобы он положил его в корень своего сайта, а уж где он находится — знает даже домохозяйка. И в этом файле будет все — и непосредственно сами настройки сервера, и формирование ссылок, и запреты на исполнение каких либо файлов, их отдачи, и т. д. На том же энджинксе нужно править не один файл, причем часто вписывать аналогичные строки одновременно в несколько файлов, причем часто с отсутствием какой-либо логики. Для меня загадка, почему ни один сервер еще такое не поддерживает. Имеются, конечно, некоторые решения, например, парсить его регулярками и перловыми скриптами чуть ли не по крону эти настройки применять, но это уже костыли, разумеется…
P. P. S. Минус не мой)
Переходил на Python с PHP. Проблем не испытывал. Гораздо сложнее было перейти с синтаксиса Joomla/Drupal к нормальному PHP коду с пространствами имён и тестами (имеется ввиду построение архитектуры с возможностью тестирования). Сейчас активно работаю с JS. В сравнении с пакетами npm, менеджер пакетов python радует. Можно подобрать очень и очень много готовых решений. Pypi — огромный репозиторий. И качество решений, зачастую, радует. Дело в том, что PHP в принципе не имеет единого стандарта оформления кода и Unit-тестов. Т.е. в случае популярных Python пакетов мы получаем код, отвечающий большинству пунктов соглашения PEP8, этот код будет содержать набор тестов для unittest, а если повезёт, то и докстринги по формату PEP257.
Насколько я помню, в PHP тоже есть различные соглашения об оформлении кода и всего пара нормальных решений для тестов. Но, скажем так, соглашения эти долгое время игнорировали, а своего нормального уровня пакеты для тестов достигли лишь несколько лет назад. Понятно, что старые решения было уже труднее переделывать под популяризованные стандарты разработки.
По Java ничего конкретного сказать не могу, поскольку не работаю с ним. По отзывам коллег могу представить, что там ситуация промежуточная: лучше чем в npm, но хуже, чем в Pypi.
Аналогично, JS — слабосахарный язык. По-умолчанию он не имеет даже команды форматирования даты/времени. Но, на него много готовых решений, которые берутся в npm. Но они, по большей части, собраны на коленке, либо это промышленные решения, но их гибкость оставляет желать лучшего (приходится под них подстраиваться, либо отказываться от них). Стандартов оформления JS кода — несколько. Тестирование вообще не популярно, хотя я пишу тесты на фронтэнд. И если уж говорить о синтаксисе, то мне и синтаксис JS нравится, и синтаксис Python. Синтаксис Ruby не совсем понятен. Но я его действительно не умею готовить. Вообще, вопрос синтаксиса и оформления кода уходит в холивар только тогда, когда человек банально не хочет изучать язык.
P.S. .htaccess не нужен! Это рудимент, как и Apache. Нормальный роутинг, так или иначе, реализуется на программном уровне, а в CGI мы вынуждены дополнять его .htaccess для корректной работы. Ну а в случае связки PHP и Java/Python/Ruby, мы вообще получаем дохлый апач с его CGI и родное решение от «святой троицы web-языков», которое охотней работает на Nginx и предлагает более гибкую и простую настройку.
P.P.S. Минус не принципиален. Интересно, конечно, узнать мнение его автора. Могу предположить, что ему не понравилось высказывание о скорости шаблонизации в отдельных PHP шаблонизаторах. Справедливости ради, стоит сказать, что эта скорость выше, чем у конкурентов. Ну или человек просто самозабвенно любит PHP.
Насколько я помню, в PHP тоже есть различные соглашения об оформлении кода и всего пара нормальных решений для тестов. Но, скажем так, соглашения эти долгое время игнорировали, а своего нормального уровня пакеты для тестов достигли лишь несколько лет назад. Понятно, что старые решения было уже труднее переделывать под популяризованные стандарты разработки.
По Java ничего конкретного сказать не могу, поскольку не работаю с ним. По отзывам коллег могу представить, что там ситуация промежуточная: лучше чем в npm, но хуже, чем в Pypi.
Аналогично, JS — слабосахарный язык. По-умолчанию он не имеет даже команды форматирования даты/времени. Но, на него много готовых решений, которые берутся в npm. Но они, по большей части, собраны на коленке, либо это промышленные решения, но их гибкость оставляет желать лучшего (приходится под них подстраиваться, либо отказываться от них). Стандартов оформления JS кода — несколько. Тестирование вообще не популярно, хотя я пишу тесты на фронтэнд. И если уж говорить о синтаксисе, то мне и синтаксис JS нравится, и синтаксис Python. Синтаксис Ruby не совсем понятен. Но я его действительно не умею готовить. Вообще, вопрос синтаксиса и оформления кода уходит в холивар только тогда, когда человек банально не хочет изучать язык.
P.S. .htaccess не нужен! Это рудимент, как и Apache. Нормальный роутинг, так или иначе, реализуется на программном уровне, а в CGI мы вынуждены дополнять его .htaccess для корректной работы. Ну а в случае связки PHP и Java/Python/Ruby, мы вообще получаем дохлый апач с его CGI и родное решение от «святой троицы web-языков», которое охотней работает на Nginx и предлагает более гибкую и простую настройку.
P.P.S. Минус не принципиален. Интересно, конечно, узнать мнение его автора. Могу предположить, что ему не понравилось высказывание о скорости шаблонизации в отдельных PHP шаблонизаторах. Справедливости ради, стоит сказать, что эта скорость выше, чем у конкурентов. Ну или человек просто самозабвенно любит PHP.
А зачем защищать пакеты с классами при помощи .htaccess? Они обычно не находятся в веб-доступной директории. Подозреваю, что из-за этого и был минус.
Ну потому я и написал, что возможно, чего-то не знаю о других методах защиты. И, при этом, на практике не встречал сайтов, в которых был бы один файл index.php, а классы были бы написаны в другой директории. Может, хотя бы вы подскажете каким образом директория, находящаяся в Site Root, исключается из веб-доступных?
Папка '/var/www/project', в ней все файлы и папки проекта, среди них есть папки 'public' и 'vendor', в 'vendor' пакеты composer, в 'public' файл 'index.php', и сюда же смотрит веб-сервер. Практически во всех фреймворках так.
При чём тут vendor? Речь шла о файлах, которые создаёт программист. Например, я создаю какую-то модель. Она у меня является классом, который лежит в отдельном модуле. Сама модель использует ORM, но представление, которое возвращает данные из БД, вынуждено импортировать этот класс. Разумеется, если я не ландух, который пишет весь код в index.php или пользуется прямым инклюдом PHP файлов. Правда, даже в случае инклюда, подключаемые файлы защищаются в .htaccess. Иначе их можно тупо скачать и посмотреть из чего состоит сайт.
В папке 'project' хранится весь код приложения. Модели например могут храниться в 'app/models'. В index.php подключается автозагрузчик через include '../vendor/autoload.php' и все, дальше используются только названия классов с пространством имен. В представлении или где-то еще пишем 'use app/models/MyModel;' и при первом обращении к классу MyModel файл подключится через composer. Отсчет естественно идет от корня проекта, а не от public. Сами представления тоже необязательно в папке public хранить, они подключаются механизмом рендеринга фреймворка.
Ну, в этом есть доля истины. Только всё как-то усложнено. Получается, что проект формально разделён на libraries в одном корне и файл запуска — в другом (public). Возможно, я не прав. Но тогда нужно посмотреть либо на уже существующие рекомендации по такому разделению, либо на авторитетные образцы. Есть такое?
Ну я бы не сказал, что разделен, просто объединяется уровнем выше.
/var/www/project:
app
config
resources
public
index.php
vendorХотя да, папку public можно вынести куда нужно, только пути в index.php поправить.
Рекомендации по автозагрузке кажется описаны в PSR. Образцы это проекты на фреймворках типа Yii, Laravel, Symfony.
Ну это, конечно, оптимальный подход. В любом случае, я не php-программер, и если сталкивался с решением задач на PHP, как-правило, хостинг был не настраиваемый, и я имел доступ только к public. Вообще, на PHP много забавных архитектурных решений. Но фреймворки, к счастью, по большей части, предлагают относительно верные варианты.
Извиняюсь, в своих делах просто забыл ответить…
Да, но в JS эта проблема практически полностью решается благодаря плагинам к jQuery (если речь идет о свистелках). Понятно, что тоже задействуется сторонний код, поэтому я, как правило, опять же, перелопачиваю код известных плагинов и пишу на их основе свои, при аналогичном функционале позволяет сократить исходный код почти в два раза, ибо часто логика произрастает неизвестно из какого места.
Хорошо, но все-таки, для Вас при переходе с PHP на Python принципиальны тесты, стандартизация и менеджеры пакетов? Просто первые нужны исключительно в промышленных масштабах, последнее решается непосредственно средствами языка и своими/сторонними фреймворками (если я правильно понял, как в случае Pypi, к которому тоже необходимо прибегать). Или может быть всему виной сложившиеся вокруг PHP известные предрассудки и оправданно его очерненная репутация школьниками, клепающими на нем сайтики для своих игровых кланов? Пока ответа на этот вопрос я не нашел, но мне интересно, честно признаюсь…
Да, но в JS эта проблема практически полностью решается благодаря плагинам к jQuery (если речь идет о свистелках). Понятно, что тоже задействуется сторонний код, поэтому я, как правило, опять же, перелопачиваю код известных плагинов и пишу на их основе свои, при аналогичном функционале позволяет сократить исходный код почти в два раза, ибо часто логика произрастает неизвестно из какого места.
Хорошо, но все-таки, для Вас при переходе с PHP на Python принципиальны тесты, стандартизация и менеджеры пакетов? Просто первые нужны исключительно в промышленных масштабах, последнее решается непосредственно средствами языка и своими/сторонними фреймворками (если я правильно понял, как в случае Pypi, к которому тоже необходимо прибегать). Или может быть всему виной сложившиеся вокруг PHP известные предрассудки и оправданно его очерненная репутация школьниками, клепающими на нем сайтики для своих игровых кланов? Пока ответа на этот вопрос я не нашел, но мне интересно, честно признаюсь…
Народ начал что-то подозревать, или еще 1 гвоздь в крышку гроба говнокодерства.
habrahabr.ru/post/338880
(В статье рассказывается, почему современный web даже хуже, чем программы времен Windows 98)
habrahabr.ru/post/338880
(В статье рассказывается, почему современный web даже хуже, чем программы времен Windows 98)
Sign up to leave a comment.
Да, Python медленный, но меня это не волнует