Да взять хотя бы самое банальное: есть тайм-критикл задачи, в них не до красоты. Там хоть ассемблерные вставки и макросы фигачь, главное чтобы быстро.
Ну или вот например высоконагруженные серверы. Самое простое решение (которое по питон дзен стоит использовать) один поток на одно соединение. При 1000+ одновременных пользователей такой подход накроется медным тазом. _________________ На опушке маленький мальчик плакал от страха и кричал: "Волк, волк!", а волк, стоя за кустом, с тоской думал, что главная беда с маленькими мальчиками - их совершенное неумение расставаться.
Обычно тайм критикал задачи обосновываются простым "надо". То есть в принципе те кому надо могут и месяц подождать, но просто вдруг "надо" и все. В таком случае обычно лучше тем кто разговаривает непосредственно с заказчиком отказаться от задачи либо сдвинуть сроки. А еще если программист не успевает лучше его не торопить иначе он напишет бажную херню. Короче я не верю в тайм критикал задачи в нормальной конторе на нормальных условиях.
В том самом дзене про это написано:
Цитата:
Хотя зачастую никогда лучше, чем прямо сейчас
Дзен не показывает тебе как надо писать программы. Там нет совета всегда выбирать самое простое решение. Там описаны наставления на путь истинный. То есть если тебе совесть позволяет писать программу с одним потоком на 1к пользователей - окей там есть пункт
Цитата:
Красота лучше уродства
Потому что это именно что уродство, если не стоит конкретной задачи сделать соединение однопоточным. А задача может и так стоять. Это уже не высоконагруженный сервер конечно, но там вполне может быть 1к пользователей.
Если читать дзен питона как руководство к действию - ничего хорошего не выйдет. Но если ты во время написания программы не можешь решить как тебе действовать, через дзен ты 100% выберешь нужный тебе вариант.
Например ты хочешь забацать адовую инкапсуляцию и тут читаешь дзен и там первым пунктом...
Я имел ввиду, не быстро и сейчас решить задачу, а написать приложение, которое бы работало максимально быстро, где каждый процессорный такт на счету.
Doredel писал(а):
То есть если тебе совесть позволяет писать программу с одним потоком на 1к пользователей - окей там есть пункт...
Что не так с 1 потоком на 1к пользователей? Ну, понятно, не 1 поток, а "кол-во ядер". Это нормальная практика.
В любом случае, я не понял твоих контраргументов по поводу хай-лоад.
Добавлено спустя 10 минут 14 секунд:
Doredel писал(а):
Но если ты во время написания программы не можешь решить как тебе действовать, через дзен ты 100% выберешь нужный тебе вариант.
Тут согласен. Если у тебя есть выбор как писать, то да, в этом случае всё хорошо. Я имел ввиду немного другое: бывают задачи, в которых у тебя нет выбора, как писать. Бывают задачи, в которых простые и красивые решения не работают. _________________ На опушке маленький мальчик плакал от страха и кричал: "Волк, волк!", а волк, стоя за кустом, с тоской думал, что главная беда с маленькими мальчиками - их совершенное неумение расставаться.
максимально быстро, где каждый процессорный такт на счету
Я пишу на абапе, там это не идет вразрез с дзеном. Красота кода часто идет вразрез с быстродействием - это да. Но там в дзене про это тоже вроде бы написано.
Narsil писал(а):
В любом случае, я не понял твоих контраргументов по поводу хай-лоад.
Многосессионное соединение не идет вразрез с простотой. Все зависит от задачи. То есть если ты знаешь что у тебя будет 1к пользователей в одновременном ожидании, тут к дзену обращаться не нужно за советом.
Я не писал низкоуровневые механизмы взаимодействия клиент-сервер, но не думаю что они как-то противоречат простоте и красоте решения. Ты приводишь пример когда якобы можно обойтись однопоточным соединением, сам же сразу говоришь что это решение будет неудачным, так как пользователей много. Получается что это не решение вовсе и не нужно здесь применять дзен, оно отсечено еще до его использования.
Красота кода часто идет вразрез с быстродействием - это да.
В красоту можно объединить тут всё. И красоту, и лаконичность, и понятность, и читаемость и прочее. Я говорю, что когда есть возможность, надо стараться писать так. Но иногда её просто нет.
Doredel писал(а):
Ты приводишь пример когда якобы можно обойтись однопоточным соединением
Не якобы можно, а оно жизненно необходимо на хайлоаде.
Doredel писал(а):
сам же сразу говоришь что это решение будет неудачным, так как пользователей много
Я говорю что неудачным будет решение 1 пользователь 1 поток. Оно будет простым и понятным, но совершенно неоптимальным. Оптимальным будет решение в 1 поток на всех клиентов (ну опять же, не 1 поток, а кол-во ядер). _________________ На опушке маленький мальчик плакал от страха и кричал: "Волк, волк!", а волк, стоя за кустом, с тоской думал, что главная беда с маленькими мальчиками - их совершенное неумение расставаться.
Salevol, тебя кто-то заменил на скрипт с вытягиванием рандомного поста или ты просто решил разговаривать только с помощью цитат?
Narsil, у тебя какая задача стоит? Написать оптимальное решение или написать простое решение? Или у тебя нет задачи и тебе даже никто не сказал какое соединение должно быть у пользователя? Во втором случае да, можно обойтись простым решением. Это не возможности навести красоту нет, это задача так стоит, что исключает самые простые и красивые решения. Это означает что из оставшихся нужно найти самое простое и красивое.
Это не возможности навести красоту нет, это задача так стоит, что исключает самые простые и красивые решения.
Я про это и говорю.
Doredel писал(а):
Это означает что из оставшихся нужно найти самое простое и красивое.
Вот у тебя есть два пути. Вот именно, что всего два. Первый путь решения задачи порождает проблемы (при овердохуя пользователей сервер "1 поток на 1 клиента" загнется), второе не красивое и не простое будет работать на ура (1 поток на весь сервер).
Например, задача стоит "написать сервер на 500 пользователей". Дзен говорит, что нужно брать первый вариант (простота лучше сложности). Мой опыт говорит брать второй вариант, ибо требования могут изменится, а там где 500 пользователей, там теоретически и 5000. _________________ На опушке маленький мальчик плакал от страха и кричал: "Волк, волк!", а волк, стоя за кустом, с тоской думал, что главная беда с маленькими мальчиками - их совершенное неумение расставаться.
Все основные принципы настолько размыты или тривиальны, что было бы органичнее услышать их из уст проповедника, нежели разработчика.
В рассматриваемом примере пул потоков по числу ядер - и есть то самое неочевидное очевидное красивое решение. _________________ grammar nazi,
scientific whore.
В рассматриваемом примере пул потоков по числу ядер
Пул потоков гораздо сложнее писать и запутаннее выглядит. _________________ На опушке маленький мальчик плакал от страха и кричал: "Волк, волк!", а волк, стоя за кустом, с тоской думал, что главная беда с маленькими мальчиками - их совершенное неумение расставаться.
Narsil, third party либа, нет ничего проще)
а про запутанность можно поспорить. Если потоков на обработку клиентов не больше, чем ядер, то ты обретаешь ясность в понимании питондзена - контролировать такой процесс гораздо проще. _________________ grammar nazi,
scientific whore.
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах
FAQ
Поиск
Пользователи
Группы
Регистрация
Профиль
Войти и проверить личные сообщения
Вход
