Возможно, эти рассуждения и внутренне логичны, но совершенно нерелевантны. Если фича не взлетела - значит она не взлетела. И без всяких живущих под корягой пользователей. В ней изначально не было никакого смысла. Поэтому и оказалась невостребованной. А не потому что про неё не добили каждый день, раздражая немногих оставшихся активных пользователей.
Важно познакомить с генераторами и посеять зерно о том что не стоит бездумно наполнять память
К сожалению, вы здесь повторяете ошибку, которая, как я надеялся, подробно объяснена в комментарии выше. Давайте я попробую ещё раз. Только вы не раздражайтесь и не обижайтесь. Возможно, дело исключительно в формулировках, но в текущем виде они доносят неверную мысль.
Вышеприведённая цитата буквально вбивает в головы ваших учеников мысль о том, что генераторы экономят память, и являются чуть ли не панацеей. Повторюсь - возможно, вы не имели этого в виду. Но в такой формулировке она звучит именно так. И это тонкий момент, который надо увидеть. Смотрите. Вот вы пишете,
Есть масса проектов, где разработчик выбирает из базы все значения и обходит их в цикле.
Совершенно верно. И ниже вы сразу говорите про генераторы. При том, что
Во-первых, есть гораздо более простое и очевидное решение. Не получать из базы сразу все значения. Но вы его не упоминаете.
А во-вторых, в основе "экономии памяти" генератором лежит именно оно. Вы берёте код, который вместо получения всех значений разом, берет их по одному, и помещаете его в генератор.
Но вашей формулировкой вы сбиваете фокус с этого очевидного решения на генератор. И это представляется мне большой ошибкой.
Ответ на вопрос, как экономить память - это "не получать все значения разом, а получать и обрабатывать по одному". Очень простой, очевидный и универсальный.
А "использовать генератор" - это всего лишь частный случай применения этого подхода. К сожалению, многие студенты, воспитанные на этом утверждении, умудряются писать код, в котором внутрь генератора помещают то же самое получение всех значений разом. И их логика при этом безупречна: "Генератор же экономит память"!
Понимаете, о чём я?
Вы в своих объяснениях пропускаете ключевой момент: тот самый подход, "получать по одному, а не скопом", который на самом деле экономит память.
И не даже не упоминаете условие, при котором генератор действительно может "сэкономить память". При том, что это условие надо наоборот, подчеркивать специально: "если надо обработать большой поток данных, но функция-обработчик ожидает массив".
При такой вводной - когда функция-обработчик данных ожидает на вход массив, который она будет перебирать через foreach - решением для экономии памяти действительно является генератор. В основе которого, тем не менее, будет лежать универсальный подход "получать по одному".
Извините, а можно уточнить, откуда такой пиетет перед Отусом? Есть какой-то источник объективной оценки? Так-то их курсы я не видел, но если судить по их статьям на Хабре, то там всё очень плохо.
А можно не извращаться, а всего лишь использовать змеиный регистр, и читать без малейших затруднений, is_least_relevant_multiple_of_next_larger_prime_factor
Но увы, поезд уже ушёл, и верблюжий стал незыблемым стандартом. При том что длинные строки объективно читать легче в змеином.
С этой точки зрения для приближения к реальности задачу стоило бы развернуть наоборот: функция не отдаёт массив, а принимает. Скажем, у нас есть уже существующая функция, которая принимает на вход массив. Но при большом объеме обрабатываемых данных тратится много памяти. При этом данные поступают из какого-либо потока - файла или например базы данных. Вот в этом случае в функцию имеет смысл передавать вместо массива генератор.
В итоге нам не придётся для экономии памяти переписывать код, обрабатывающий массив, помещая его в функцию, которая вызывается внутри цикла получения данных - как это пришлось бы делать до появления генераторов. А всего лишь надо будет немного переписать код, получающий эти данные - не в массив, а в генератор.
Если честно, мне ужасно не хочется выглядеть занудой. Но ещё я ужасно не люблю недопонимания :)
В общем, я имел в виду пример не для статьи, а для курса. То, что он в статье - это как раз нормально. А вот в курсе он как раз довольно слабый. Просто в реальной жизни очень редко, практически никогда нельзя заменить массив генератором. Даже для "случайных" чисел, которые чаще всего используются в примерах про "экономящие память" генераторы, скорее всего требуются не просто случайные, а случайные уникальные. То есть, уже выданные номера надо где-то хранить. И никакой экономии не будет. Не говоря уже о каких-то реальных данных.
Достоинство генератора не в том, что он "экономит память", а в том, что он может превратить цикл в массив. То есть взять любой цикл получения данных, и подать на вход функции, которая ждёт массив. И в итоге не функцию вызывать внутри цикла, а наоборот - внутрь функции передать цикл. Это часто позволяет написать более удобный или универсальный код.
А память он экономит только на таких вот вырожденных и не имеющих практического смысла примерах.
Я так и подумал, но тут есть нюанс: генераторы не имеют отношения к потреблению памяти. Собственно, данный пример это как раз прекрасно и иллюстрирует: память экономит написание осмысленного кода (вызывать функцию не 1 раз, а 80000), а не генератор.
Я просто надеялся, что поскольку курс делают практикующие специалисты, то и примеры они будут брать из практики, а не про кошечек и собачек. Но, в общем, это было наивное ожидание: разумеется, не на всякий аспект языка можно найти пример из непосредственной практики. И всё же я бы порадовался примеру, в котором генератор используется по своему назначению: для написания более удобного кода.
Интересно, где в реальном коде можно применить функцию, которая отдаёт 80000 рандомных значений. А точнее, почему вместо неё нельзя применить функцию, которая отдаёт одно рандомное значение, вызвав её 80000 раз.
Самое неприятное, что элемента с индексом 0 может и не быть, то есть сначала надо проверить, что он есть, а потом уже читать дальше
Это не совсем так. "Сначала" проверять ничего не надо, эта строка вполне рабочая. Если индекса нет, то мы просто получим значение после ??
элемент "formatted" может внезапно оказаться с типом bool вместо string.
А вот тут уже спорный вопрос, что делать в этом случае. По моим представлениям, в таком случае пришедшие данные скорее не стоит обрабатывать вообще, чем как-то подрихтовывать, только чтобы они пролезли в нужное отверстие, пусть и с пустым значением.
И в любом случае, эта проблема решается тем же (string). Куда интереснее вопрос, что делать, если тип boolean окажется у элемента Address, а не formatted. И в этом смысле мне интереснее была бы библиотека с встроенной валидацией по схеме. Ну то есть такое переизобретение SOAP для JSON. Вот такое я бы действительно назвал типобезопасным. А предложенный вариант скорее типоигнорирующим.
ОМГ, какой-то детский сад. Теперь понятно, что вы пришли не платформу обсудить, а поплакаться, что вас на ней жестоко обидели. И привести свои объяснения этому, сообразно своему уровню развития и образования.
Просто для информации:
Во-первых, вам пора научиться не обижаться на реальность. Она от этого всё равно не изменится. Если вы высказали на редкость дурацкую идею о том, что на SO кто-то кого-то набирает, а вам сообщили, что это не так, то апеллировать тут не к чему. Это факт. Который надо или принять, или проверить, а потом принять. А не обижаться, что вам об этом сообщили без реверансов.
Во-вторых, студенты там лезут только отвечать. Сообразно своим микроскопическим знаниям. Вопросы закрывают не они. И уж тем более в модераторы никто студента не выберет.
В-третьих, в подавляющем большинстве случаев вопросы закрывают не модераторы, а пользователи с достаточным для этого рейтингом. Нужно всего три голоса. Обычно там всегда зависает достаточное количество таких завсегдатаев, чтобы оперативно закрыть вопрос, который не соответствует формальным критериям (а под них попадает 90% всех вопросов).
И в-четвёртых, средний возраст, как этих пользователей, так и модераторов - хорошо за 40, студенчеством там и не пахнет. А стиль поведения диктуется не возрастной группой, а представлениями о предназначении сервиса, а так же специфическим когнитивным искажением, которое проявляется у завсегдатаев любых форумов, когда они видят миллионы одинаковых вопросов.
Во-первых, там никто никого не "набирает". Это не военкомат. Тем более первокурсников, которым там и так мёдом намазано - показать всем, что они умеют умножать два на два.
Во-вторых, проблема не в токсичности, а в попытке усидеть на двух стульях: сделать одновременно q&a и библиотеку готовых ответов. Поскольку эти две задачи противоречат друг другу если решать их в лоб, то и возникает проблема "косят всё подряд". Потому что с точки зрения библиотеки вопрос либо уже задавался, либо не имеет смысла. А диалоговый режим в принципе не предусмотрен, поскольку явно декларируется, что SO - не место для дискуссий.
Реддит - это платформа для мемасиков и войнушки за всё хорошее против всего плохого. Так что если даже мемасики будет генерировать нейросеть, сами хомячки никуда не денутся.
Молодые люди, я знаю, что вы оба профессионалы. И можете нагнать хоть сотню комментариев, хоть пять. Можно вас попросить делать это где-то ещё? Мне не хочется отписываться от комментариев в своей собственной новости.
Да-да, надои начали более лучше колоситься по сравнению с 1913 годом. Осталось только посмотреть, сколько в этих красивых цифрах ИИ-шлака.
Возможно, эти рассуждения и внутренне логичны, но совершенно нерелевантны. Если фича не взлетела - значит она не взлетела. И без всяких живущих под корягой пользователей. В ней изначально не было никакого смысла. Поэтому и оказалась невостребованной. А не потому что про неё не добили каждый день, раздражая немногих оставшихся активных пользователей.
...написал супер-вовлечённый пользователь, активность которого составила, в среднем, 0 комментариев за 10 лет. Очень, очень релевантное мнение.
К сожалению, вы здесь повторяете ошибку, которая, как я надеялся, подробно объяснена в комментарии выше. Давайте я попробую ещё раз. Только вы не раздражайтесь и не обижайтесь. Возможно, дело исключительно в формулировках, но в текущем виде они доносят неверную мысль.
Вышеприведённая цитата буквально вбивает в головы ваших учеников мысль о том, что генераторы экономят память, и являются чуть ли не панацеей. Повторюсь - возможно, вы не имели этого в виду. Но в такой формулировке она звучит именно так. И это тонкий момент, который надо увидеть. Смотрите. Вот вы пишете,
Совершенно верно. И ниже вы сразу говорите про генераторы. При том, что
Во-первых, есть гораздо более простое и очевидное решение. Не получать из базы сразу все значения. Но вы его не упоминаете.
А во-вторых, в основе "экономии памяти" генератором лежит именно оно. Вы берёте код, который вместо получения всех значений разом, берет их по одному, и помещаете его в генератор.
Но вашей формулировкой вы сбиваете фокус с этого очевидного решения на генератор. И это представляется мне большой ошибкой.
Ответ на вопрос, как экономить память - это "не получать все значения разом, а получать и обрабатывать по одному". Очень простой, очевидный и универсальный.
А "использовать генератор" - это всего лишь частный случай применения этого подхода. К сожалению, многие студенты, воспитанные на этом утверждении, умудряются писать код, в котором внутрь генератора помещают то же самое получение всех значений разом. И их логика при этом безупречна: "Генератор же экономит память"!
Понимаете, о чём я?
Вы в своих объяснениях пропускаете ключевой момент: тот самый подход, "получать по одному, а не скопом", который на самом деле экономит память.
И не даже не упоминаете условие, при котором генератор действительно может "сэкономить память". При том, что это условие надо наоборот, подчеркивать специально: "если надо обработать большой поток данных, но функция-обработчик ожидает массив".
При такой вводной - когда функция-обработчик данных ожидает на вход массив, который она будет перебирать через foreach - решением для экономии памяти действительно является генератор. В основе которого, тем не менее, будет лежать универсальный подход "получать по одному".
Ну то есть это ваше личное мнение, под которое вы подписали всё РНР коммюнити?
Извините, а можно уточнить, откуда такой пиетет перед Отусом? Есть какой-то источник объективной оценки? Так-то их курсы я не видел, но если судить по их статьям на Хабре, то там всё очень плохо.
Зато на пиар вот не поскупились.
А можно не извращаться, а всего лишь использовать змеиный регистр, и читать без малейших затруднений,
is_least_relevant_multiple_of_next_larger_prime_factorНо увы, поезд уже ушёл, и верблюжий стал незыблемым стандартом. При том что длинные строки объективно читать легче в змеином.
С этой точки зрения для приближения к реальности задачу стоило бы развернуть наоборот: функция не отдаёт массив, а принимает. Скажем, у нас есть уже существующая функция, которая принимает на вход массив. Но при большом объеме обрабатываемых данных тратится много памяти. При этом данные поступают из какого-либо потока - файла или например базы данных. Вот в этом случае в функцию имеет смысл передавать вместо массива генератор.
В итоге нам не придётся для экономии памяти переписывать код, обрабатывающий массив, помещая его в функцию, которая вызывается внутри цикла получения данных - как это пришлось бы делать до появления генераторов. А всего лишь надо будет немного переписать код, получающий эти данные - не в массив, а в генератор.
Если честно, мне ужасно не хочется выглядеть занудой. Но ещё я ужасно не люблю недопонимания :)
В общем, я имел в виду пример не для статьи, а для курса. То, что он в статье - это как раз нормально. А вот в курсе он как раз довольно слабый. Просто в реальной жизни очень редко, практически никогда нельзя заменить массив генератором. Даже для "случайных" чисел, которые чаще всего используются в примерах про "экономящие память" генераторы, скорее всего требуются не просто случайные, а случайные уникальные. То есть, уже выданные номера надо где-то хранить. И никакой экономии не будет. Не говоря уже о каких-то реальных данных.
Достоинство генератора не в том, что он "экономит память", а в том, что он может превратить цикл в массив. То есть взять любой цикл получения данных, и подать на вход функции, которая ждёт массив. И в итоге не функцию вызывать внутри цикла, а наоборот - внутрь функции передать цикл. Это часто позволяет написать более удобный или универсальный код.
А память он экономит только на таких вот вырожденных и не имеющих практического смысла примерах.
Так вроде практически вся последующая статья как раз подробно все вузы и описывает?
Я так и подумал, но тут есть нюанс: генераторы не имеют отношения к потреблению памяти. Собственно, данный пример это как раз прекрасно и иллюстрирует: память экономит написание осмысленного кода (вызывать функцию не 1 раз, а 80000), а не генератор.
Я просто надеялся, что поскольку курс делают практикующие специалисты, то и примеры они будут брать из практики, а не про кошечек и собачек. Но, в общем, это было наивное ожидание: разумеется, не на всякий аспект языка можно найти пример из непосредственной практики. И всё же я бы порадовался примеру, в котором генератор используется по своему назначению: для написания более удобного кода.
Интересно, где в реальном коде можно применить функцию, которая отдаёт 80000 рандомных значений. А точнее, почему вместо неё нельзя применить функцию, которая отдаёт одно рандомное значение, вызвав её 80000 раз.
Небольшая поправка
Это не совсем так. "Сначала" проверять ничего не надо, эта строка вполне рабочая. Если индекса нет, то мы просто получим значение после ??
А вот тут уже спорный вопрос, что делать в этом случае. По моим представлениям, в таком случае пришедшие данные скорее не стоит обрабатывать вообще, чем как-то подрихтовывать, только чтобы они пролезли в нужное отверстие, пусть и с пустым значением.
И в любом случае, эта проблема решается тем же (string). Куда интереснее вопрос, что делать, если тип boolean окажется у элемента Address, а не formatted. И в этом смысле мне интереснее была бы библиотека с встроенной валидацией по схеме. Ну то есть такое переизобретение SOAP для JSON. Вот такое я бы действительно назвал типобезопасным. А предложенный вариант скорее типоигнорирующим.
ОМГ, какой-то детский сад. Теперь понятно, что вы пришли не платформу обсудить, а поплакаться, что вас на ней жестоко обидели. И привести свои объяснения этому, сообразно своему уровню развития и образования.
Просто для информации:
Во-первых, вам пора научиться не обижаться на реальность. Она от этого всё равно не изменится. Если вы высказали на редкость дурацкую идею о том, что на SO кто-то кого-то набирает, а вам сообщили, что это не так, то апеллировать тут не к чему. Это факт. Который надо или принять, или проверить, а потом принять. А не обижаться, что вам об этом сообщили без реверансов.
Во-вторых, студенты там лезут только отвечать. Сообразно своим микроскопическим знаниям. Вопросы закрывают не они. И уж тем более в модераторы никто студента не выберет.
В-третьих, в подавляющем большинстве случаев вопросы закрывают не модераторы, а пользователи с достаточным для этого рейтингом. Нужно всего три голоса. Обычно там всегда зависает достаточное количество таких завсегдатаев, чтобы оперативно закрыть вопрос, который не соответствует формальным критериям (а под них попадает 90% всех вопросов).
И в-четвёртых, средний возраст, как этих пользователей, так и модераторов - хорошо за 40, студенчеством там и не пахнет. А стиль поведения диктуется не возрастной группой, а представлениями о предназначении сервиса, а так же специфическим когнитивным искажением, которое проявляется у завсегдатаев любых форумов, когда они видят миллионы одинаковых вопросов.
Во-первых, там никто никого не "набирает". Это не военкомат. Тем более первокурсников, которым там и так мёдом намазано - показать всем, что они умеют умножать два на два.
Во-вторых, проблема не в токсичности, а в попытке усидеть на двух стульях: сделать одновременно q&a и библиотеку готовых ответов. Поскольку эти две задачи противоречат друг другу если решать их в лоб, то и возникает проблема "косят всё подряд". Потому что с точки зрения библиотеки вопрос либо уже задавался, либо не имеет смысла. А диалоговый режим в принципе не предусмотрен, поскольку явно декларируется, что SO - не место для дискуссий.
Реддит - это платформа для мемасиков и войнушки за всё хорошее против всего плохого. Так что если даже мемасики будет генерировать нейросеть, сами хомячки никуда не денутся.
Молодые люди, я знаю, что вы оба профессионалы. И можете нагнать хоть сотню комментариев, хоть пять. Можно вас попросить делать это где-то ещё? Мне не хочется отписываться от комментариев в своей собственной новости.
А оригинал, типа, зарифмован?
Да уж, придирка так придирка. То ли дело немая зарь или умна - нормальный русский язык же.