Согласен, я прочитал невнимательно. Но опять же, вы об этом пишете в комментарии. В статье это ваше "без отказа от массива" исходно не упоминалось вообще, а потом вы добавили короткую отписку "на отвали", всю суть оставив прежней, "ололо, генераторы экономят память!!!".
Потом начитавшись таких статей очередной гений засовывает в генератор массив и гордо пишет "Memory Efficient: Built with generators to process massive XML without running out of memory." И ведь он прав! С точки зрения утверждения "генераторы экономят память" у него всё в порядке. Засунул массив внутрь генератора - сэкономил память.
Именно поэтому ваша статья приносит вред
Причём вред её многократно умножается тем, что она повторяет ту же глупость, что и множество других.
А то что вы начинаете где-то в комментариях добавлять "без отказа от массива" суть статьи не меняет вообще никак.
Теперь давайте разбираться с этим вашим "без отказа от массива". Получается, что генератор экономит память тогда, когда обработчик по какой-то причине требует массив. А требовать он может только ради более оптимального/универсального кода. То есть и получается, что генератор позволяет писать более универсальный код, разделять источник получения данных и их обработчик, сохраняя при этом эффективность по памяти. В от это была бы нормальная формулировка, и вам бы сказали большое спасибо за статью.
Если бы вы сначала показали эффективный по памяти, но организационно неоптимальный код, потом предложили сделать его более универсальным, с разделением источника и обработчика данных с помощью массива - но при этом упёрлись бы в неоптимальность по памяти, и в финале представили бы генератор, завернув в него исходный оптимальный по памяти код, то это была бы прекрасная статья, в которой правильно расставлены акценты: память экономит всё тот же старый while или for, а генератор просто позволяет сделать этот код мобильным, предоставляет универсальный интерфейс для любых циклов.
А так у вас получился просто мусор, непонятно зачем написанный (таких статей и так как грязи) и непонятно для кого.
Да. Но к экономии памяти это отношения не имеет. Есть гении, которые внутри генератора читают файл в массив (ачотакова, генератор сам же всё сэкономит!) и генератор дальше прекрасно отдаёт этот массив, "сохраняя состояние". Но не экономя ни байта памяти.
Генератор не всегда служит для экономии памяти. Когда же речь заходит про "экономию памяти", то это всегда делает цикл, который у генератора него внутри. А удобство генератора в том, что он позволяет выполнять этот цикл не сразу, а в другом месте. А не в "экономии памяти".
Правильно. Генератор это - это удобная обертка. Это про упаковочный материал, а не про память. В эту обёртку, кроме прочего, можно завернуть тривиальный механизм экономии памяти. Но при этом надо понимать, что генератор - это не про сэкономить, а про обернуть то, что экономит.
[генератор нужен] для того, чтобы загружать данные не все сразу
Я попробую последний раз, дальше повторять не вижу смысла. "Чтобы загружать данные не все сразу, а по мере необходимости" служит цикл, который читает из потока по одной ложке. Генератор к этому тривиальному алгоритму никакого отношения не имеет.
Вы сейчас редкую чушь написали. Генератор к этому коду вообще никакого отношения не имеет. Механизмы, которые используются в генераторе - это остановить выполнение, запомнить стек, и вернуть значение.
Некая конкретная реализация генератора может использовать этот код, но и тут не надо переворачивать с ног на голову. Это реализация генератора будет использовать, причём не "те же", а именно этот механизм. Который и без генератора прекрасно справляется. А вот генератор без него не сэкономит и байта. Получается, что память экономит "механизм". А смысл генератора в том, что он может перенести "механизм" в другое место.
Генераторы. Не. Про. Экономию. Памяти. Память они экономить не умеют. Память экономит цикл, который работает у него внутри. Этот цикл без генератора прекрасно сэкономит память. Генератор без этого цикла не с экономит вам ни байта. Реальная польза генераторов не про память. А про то, что вы сами же писали в комментарии выше: про "разделение источника данных и их обработчика" и "унификацию интерфейса".
Это какая-то дурацкая отмазка, я её слышу уже 20 лет. "статья делалась для начинающих" (и это каким-то образом оправдывает наличие в коде SQL инъекций). "Статья писалась для среднего уровня" (и поэтому в ней заявляется рассказ об итераторах, но никакой информации по ним прочему-то не приводится). Впору воскликнуть, вслед за Вовочкой из анекдота, "Где логика, где разум?".
Отсылка к воображаемой аудитории не является универсальным оправданием для кривого кода или дурацкой статьи.
Я вам привел конкретные замечания - упор на экономию памяти, полное отсутствие упоминания настоящих причин использовать генераторы, отсутствие заявленной информации про итераторы. Вы пошли к своему ИИ за исправлениями и ещё больше запутались. В итоге обиделись почему-то на меня и вернули статью в исходное положение. Не думали для разнообразия обидеться на ИИ, который вам это всё подсунул? Или на свою попытку написать статью по теме, в которой сами ничего не понимаете, а полагаетесь на мнение ИИ?
Всё это очень хорошо, но почему-то вы мне об этом рассказываете только сейчас в комментариях. Это до боли напоминает реакцию генеративного ИИ, когда тыкаешь его носом в его bullshit.
В статье я хотел показать
Если честно, то сложно поверить, что вы действительно что-то такое хотели. Если бы хотели, то статья была бы построена совершенно по-другому, с упором на "разделить источник данных и обработку" и "унификацию интерфейса". Но в исходном варианте вы об этом даже не заикнулись - там один только стандартный бубнёж про "экономию памяти". При этом исправленный вариант не стал лучше, акцент так и остался на экономии памяти.
Пример: взять первые 100 машин дороже 1 млн, лишние страницы не дергаются
Это какой-то высосанный из пальца пример. Если в API есть сортировка или условия, то их и надо использовать. Если нет - то надо не с умным лицом делать вот это вот take filter, а тупо загнать всю инфу в локальную БД и уже по ней искать нормальными средствами, а не перебором. И про "лишние страницы не дёргаются" вас обманули. Вы дёргаете лишние страницы до тех пор, пока не наберете случайно разбросанные строки, попадающие под условие. Фасад красивый, а внутри та же неоптимальность. Если задать не миллион, а, скажем, 10, то ваш хвалёный генератор так и будет молотить, пока не переберёт все страницы.
И напоследок - совет: никогда не скармливайте фидбек по статье той ЛЛМ, которая её написала. Она запутается и будет ещё хуже.
В первом сезоне в качестве великого решения всех проблем, позволяющего стать царицею морскою "хранить состояние, управлять ключами или даже динамически менять источник данных", вы нам продавали итератор. А в исправленном и дополненном издании со всеми этими задачами прекрасно справился... генератор! И статья в итоге приобрела лёгкий оттенок шизофрении. Вы уж тогда что ли совсем задвиньте эти итераторы пяткой под шкаф, чтобы не отсвечивали - всё равно они тут были ни к селу, ни к городу.
Да не, сам по себе генератор - это не бином Ньютона. И при правильном применении сделает код удобнее и проще. Вот только автору статьи про это неизвестно. Ну точнее не было известно на момент написания статьи.
На редкость бессмысленная статья. Выглядит так, как будто мне хотят продать кусок дерева под видом чудодейственной реликвии, а местами напоминает анекдот. Первая же строчка,
Вы когда-нибудь пытались загрузить в память CSV-файл на миллион строк?
сразу напоминает бессмертное "Доктор, когда я делаю так, мне больно." А мысль не загружать в память CSV-файл на миллион строк в голову не приходила?
Но самое главное, нигде никак не объясняется, зачем делать
function fetchCars(): Generator {
$page = 1;
do {
$data = apiRequest('cars', ['page' => $page]);
foreach ($data['items'] as $car) {
yield $car;
}
$page++;
} while (!empty($data['items']));
}
если можно сделать
$page = 1;
do {
$data = apiRequest('cars', ['page' => $page]);
// process data
$page++;
} while (!empty($data['items']));
}
Ведь если цель - экономия памяти, то в каждом случае можно обойтись исходным циклом!
На середине я было понадеялся, что прочитаю что-то новое про итераторы - там обещалось всякое, про "хранить состояние, управлять ключами или даже динамически менять источник данных" - но увы, из всего этого великолепия в наличии оказалась только копипаста примера из мануала.
Для кого эта статья - непонятно. Зачем она автору - загадка.
Ну вот собственно автор открытым текстом подтверждает, что статья написана ЛЛМ.
Я только не пойму - зачем это вам? Самоутверждаетесь? Набиваете портфолио? Хотите устроиться работать клоуном из известной цитаты Пелевина писателем в корпоративный блог?
Идея-то может и интересная, но в реальности это никакая не "игра", а просто набор заданий на знание синтаксиса конкретной БД, которую и пытается рекламировать. Никакого "изучения" там нет и в помине, от тебя ожидается, что ты и так уже знаешь, какой запрос писать. А для изучения, внезапно, предлагается документация. Как в сказке про кашу из топора или анекдоте "И вышел таки обратно на Дерибасовскую".
Ну, Денвер-то тут не нужен от слова совсем. Это же консольная игра, то есть достаточно скачать и распаковать зип-архив c PHP. Другое дело, что игра под виндой не запустится, поскольку использует функции, не поддерживаемые в этой ОС...
Согласен, я прочитал невнимательно. Но опять же, вы об этом пишете в комментарии. В статье это ваше "без отказа от массива" исходно не упоминалось вообще, а потом вы добавили короткую отписку "на отвали", всю суть оставив прежней, "ололо, генераторы экономят память!!!".
Потом начитавшись таких статей очередной гений засовывает в генератор массив и гордо пишет "Memory Efficient: Built with generators to process massive XML without running out of memory." И ведь он прав! С точки зрения утверждения "генераторы экономят память" у него всё в порядке. Засунул массив внутрь генератора - сэкономил память.
Именно поэтому ваша статья приносит вред
Причём вред её многократно умножается тем, что она повторяет ту же глупость, что и множество других.
А то что вы начинаете где-то в комментариях добавлять "без отказа от массива" суть статьи не меняет вообще никак.
Теперь давайте разбираться с этим вашим "без отказа от массива". Получается, что генератор экономит память тогда, когда обработчик по какой-то причине требует массив. А требовать он может только ради более оптимального/универсального кода. То есть и получается, что генератор позволяет писать более универсальный код, разделять источник получения данных и их обработчик, сохраняя при этом эффективность по памяти. В от это была бы нормальная формулировка, и вам бы сказали большое спасибо за статью.
Если бы вы сначала показали эффективный по памяти, но организационно неоптимальный код, потом предложили сделать его более универсальным, с разделением источника и обработчика данных с помощью массива - но при этом упёрлись бы в неоптимальность по памяти, и в финале представили бы генератор, завернув в него исходный оптимальный по памяти код, то это была бы прекрасная статья, в которой правильно расставлены акценты: память экономит всё тот же старый while или for, а генератор просто позволяет сделать этот код мобильным, предоставляет универсальный интерфейс для любых циклов.
А так у вас получился просто мусор, непонятно зачем написанный (таких статей и так как грязи) и непонятно для кого.
Да. Но к экономии памяти это отношения не имеет. Есть гении, которые внутри генератора читают файл в массив (ачотакова, генератор сам же всё сэкономит!) и генератор дальше прекрасно отдаёт этот массив, "сохраняя состояние". Но не экономя ни байта памяти.
Генератор не всегда служит для экономии памяти. Когда же речь заходит про "экономию памяти", то это всегда делает цикл, который у генератора него внутри. А удобство генератора в том, что он позволяет выполнять этот цикл не сразу, а в другом месте. А не в "экономии памяти".
Правильно. Генератор это - это удобная обертка. Это про упаковочный материал, а не про память. В эту обёртку, кроме прочего, можно завернуть тривиальный механизм экономии памяти. Но при этом надо понимать, что генератор - это не про сэкономить, а про обернуть то, что экономит.
Я попробую последний раз, дальше повторять не вижу смысла. "Чтобы загружать данные не все сразу, а по мере необходимости" служит цикл, который читает из потока по одной ложке. Генератор к этому тривиальному алгоритму никакого отношения не имеет.
Вы сейчас редкую чушь написали. Генератор к этому коду вообще никакого отношения не имеет. Механизмы, которые используются в генераторе - это остановить выполнение, запомнить стек, и вернуть значение.
Некая конкретная реализация генератора может использовать этот код, но и тут не надо переворачивать с ног на голову. Это реализация генератора будет использовать, причём не "те же", а именно этот механизм. Который и без генератора прекрасно справляется. А вот генератор без него не сэкономит и байта. Получается, что память экономит "механизм". А смысл генератора в том, что он может перенести "механизм" в другое место.
Ну вам сто раз уже отвечали на этот вопрос.
Генераторы. Не. Про. Экономию. Памяти.
Память они экономить не умеют.
Память экономит цикл, который работает у него внутри.
Этот цикл без генератора прекрасно сэкономит память.
Генератор без этого цикла не с экономит вам ни байта.
Реальная польза генераторов не про память.
А про то, что вы сами же писали в комментарии выше: про "разделение источника данных и их обработчика" и "унификацию интерфейса".
Это какая-то дурацкая отмазка, я её слышу уже 20 лет. "статья делалась для начинающих" (и это каким-то образом оправдывает наличие в коде SQL инъекций). "Статья писалась для среднего уровня" (и поэтому в ней заявляется рассказ об итераторах, но никакой информации по ним прочему-то не приводится). Впору воскликнуть, вслед за Вовочкой из анекдота, "Где логика, где разум?".
Отсылка к воображаемой аудитории не является универсальным оправданием для кривого кода или дурацкой статьи.
Я вам привел конкретные замечания - упор на экономию памяти, полное отсутствие упоминания настоящих причин использовать генераторы, отсутствие заявленной информации про итераторы. Вы пошли к своему ИИ за исправлениями и ещё больше запутались. В итоге обиделись почему-то на меня и вернули статью в исходное положение. Не думали для разнообразия обидеться на ИИ, который вам это всё подсунул? Или на свою попытку написать статью по теме, в которой сами ничего не понимаете, а полагаетесь на мнение ИИ?
Всё это очень хорошо, но почему-то вы мне об этом рассказываете только сейчас в комментариях. Это до боли напоминает реакцию генеративного ИИ, когда тыкаешь его носом в его bullshit.
Если честно, то сложно поверить, что вы действительно что-то такое хотели. Если бы хотели, то статья была бы построена совершенно по-другому, с упором на "разделить источник данных и обработку" и "унификацию интерфейса". Но в исходном варианте вы об этом даже не заикнулись - там один только стандартный бубнёж про "экономию памяти". При этом исправленный вариант не стал лучше, акцент так и остался на экономии памяти.
Это какой-то высосанный из пальца пример. Если в API есть сортировка или условия, то их и надо использовать. Если нет - то надо не с умным лицом делать вот это вот take filter, а тупо загнать всю инфу в локальную БД и уже по ней искать нормальными средствами, а не перебором.
И про "лишние страницы не дёргаются" вас обманули. Вы дёргаете лишние страницы до тех пор, пока не наберете случайно разбросанные строки, попадающие под условие. Фасад красивый, а внутри та же неоптимальность. Если задать не миллион, а, скажем, 10, то ваш хвалёный генератор так и будет молотить, пока не переберёт все страницы.
И напоследок - совет: никогда не скармливайте фидбек по статье той ЛЛМ, которая её написала. Она запутается и будет ещё хуже.
В первом сезоне в качестве великого решения всех проблем, позволяющего
стать царицею морскою"хранить состояние, управлять ключами или даже динамически менять источник данных", вы нам продавали итератор. А в исправленном и дополненном издании со всеми этими задачами прекрасно справился... генератор! И статья в итоге приобрела лёгкий оттенок шизофрении. Вы уж тогда что ли совсем задвиньте эти итераторы пяткой под шкаф, чтобы не отсвечивали - всё равно они тут были ни к селу, ни к городу.Да не, сам по себе генератор - это не бином Ньютона. И при правильном применении сделает код удобнее и проще. Вот только автору статьи про это неизвестно. Ну точнее не было известно на момент написания статьи.
Тут нет никакого генератора, а память не расходуется. Что я делаю не так?
И это я ещё не упоминаю, что про "если бы я сделал 10 запросов по 100000 строк" вас нагло и цинично обманули.
На редкость бессмысленная статья. Выглядит так, как будто мне хотят продать кусок дерева под видом чудодейственной реликвии, а местами напоминает анекдот. Первая же строчка,
сразу напоминает бессмертное "Доктор, когда я делаю так, мне больно." А мысль не загружать в память CSV-файл на миллион строк в голову не приходила?
Но самое главное, нигде никак не объясняется, зачем делать
если можно сделать
Ведь если цель - экономия памяти, то в каждом случае можно обойтись исходным циклом!
И никаких генераторов не нужно!
На середине я было понадеялся, что прочитаю что-то новое про итераторы - там обещалось всякое, про "хранить состояние, управлять ключами или даже динамически менять источник данных" - но увы, из всего этого великолепия в наличии оказалась только копипаста примера из мануала.
Для кого эта статья - непонятно. Зачем она автору - загадка.
Ну вот собственно автор открытым текстом подтверждает, что статья написана ЛЛМ.
Я только не пойму - зачем это вам? Самоутверждаетесь? Набиваете портфолио? Хотите устроиться работать
клоуном из известной цитаты Пелевинаписателем в корпоративный блог?Идея-то может и интересная, но в реальности это никакая не "игра", а просто набор заданий на знание синтаксиса конкретной БД, которую и пытается рекламировать. Никакого "изучения" там нет и в помине, от тебя ожидается, что ты и так уже знаешь, какой запрос писать. А для изучения, внезапно, предлагается документация. Как в сказке про кашу из топора или анекдоте "И вышел таки обратно на Дерибасовскую".
У меня линукс прямо в линуксе :)
Но спасибо за информацию, может быть, когда-нибудь пригодится.
https://habr.com/ru/companies/habr/articles/802683/
Сорян, не разбираюсь в виндовых прибамбасах :) Денвер - помню, было такое лет 20 назад. WSL уже не застал.
Ну, Денвер-то тут не нужен от слова совсем. Это же консольная игра, то есть достаточно скачать и распаковать зип-архив c PHP. Другое дело, что игра под виндой не запустится, поскольку использует функции, не поддерживаемые в этой ОС...
Вот, кстати, коллеги тоже интересуются, по смежному вопросу.
"Увы, так было раньше. А нынче попробуйте постоять у любого детсада..." 🤪
С первых же строк видно непонимание темы самим автором.
3.Код, полученный с сайта evil.com, заставляет ваш браузер тайно отправить запрос Get /api/account на bank.com.
Ну и все признаки текста, сгенерированного ИИ. Печально.
Я - нет. Но в этом как бы вся соль данной "новости" - что Линус считает это нормальным.