Не кольцо а стрела, стрела раскручивается, груз отцепляется и улетает, стрела тормозится рекуперируя энергию. У колец/спиралей большие невосполнимые потери на центробежную составляющую.
Сам паттерн только про интерпретацию набора команд для достижения вариативности результата путём предоставления различного набора команд, лексический разбор и даже AST не обязательны.
К примеру PNG формат состоит из команд, которые обрабатываются интерпретатором для построения изображения.
Другой пример-любая GUI программа содержит в себе интерпретатор, т.к. ОС в Event Loop присылает команды на которые программа должна реагировать (нажатия кнопок, действия мышью итд)
Я придерживаюсь мнения что если отдельная команда не осилила толстые клиенты то и тонкие она бы не осилила, а выбор между ними диктуется приложением, стеком технологий и планами на 3 года
Я бы посоветовал заменить имя "ос" т.к. plan9 уже занял эту цифру, ну и рассмотреть почему все фичи ОС, которые вам не нравятся вообще были созданы и какие задачи они решают.
С++ итераторы у вас реализованы некорректно- begin() и end() должны возвращать одинаковый тип, ни один стандартный алгоритм из <algorithm> не будет работать с вашими итераторами.
И это кстати общий случай который 11l ломает- для итераторов в таком стиле каждый алгоритм требует быть определённым для пустого begin() - не удобно, раздуваем итератор (т.к optional теперь деталь реализации итератора)
Касательно реализации итератора по строкам - во первых странно строить новые типы итераторов на базе iostream который сам итератор и понятно что получается сложно местами. has_next можно убрать если проверять поток на окончание.
Из C# итератора вы выкинули главное его свойство - ленивость(создание итератора не запускает чтение данных)
С итерацией по директориям вы тоже перемудрили.
Ну и итераторы это то где как раз уместно оптимизировать производительность вплоть до инструкций.
В общем тема интересная, но над содержанием и выводами надо критически поработать.
нет таких примеров, более мощный двигатель это замена коробки, подвески, всей электроники двигателя и после этого возможно трактор слишком тяжелый чтобы работать в поле
конечно можно сказать что мы заменим на аналогичный, но в мире софта такое не возможно
Идея интересная, но ваш кортеж (не тупль, пожалуйста) не constexpr
Прикольно было бы реализовать обёртку поверх стандартного кортежа, которая бы пересортировывала элементы, тогда она была бы и эффективной по памяти, и constexpr
Совсем прикольно было бы сделать это всё на С++11 (но не уверен что это возможно) :)
Вы внесли в LLM кучу правок и уточнений из за того, что у вас есть навыки программирования, если бы вы этого не сделали то эта хрень бы не заработала.
Но если бы вы были условным пастухом который сразу бы начал промптить то как вы узнали бы что нужно уточнять и спрашивать? Чтение сгенерированого LLM кода вас не научит программированию, LLM не понимает что пишет, она просто даёт статистически средний результат, она не может объяснить почему надо так а не иначе.
То же самое с безопасностью - LLM может элементарно воспроизводить типичные проблемы безопасности т.к. средний программист делает те же самые ошибки. И LLM так же ленив как и средний программист, потому что не понимает что часто люди пишут не идеальный пуленепробиваемый код, а "и так сойдёт".
Не кольцо а стрела, стрела раскручивается, груз отцепляется и улетает, стрела тормозится рекуперируя энергию. У колец/спиралей большие невосполнимые потери на центробежную составляющую.
Сам паттерн только про интерпретацию набора команд для достижения вариативности результата путём предоставления различного набора команд, лексический разбор и даже AST не обязательны.
К примеру PNG формат состоит из команд, которые обрабатываются интерпретатором для построения изображения.
Другой пример-любая GUI программа содержит в себе интерпретатор, т.к. ОС в Event Loop присылает команды на которые программа должна реагировать (нажатия кнопок, действия мышью итд)
Я придерживаюсь мнения что если отдельная команда не осилила толстые клиенты то и тонкие она бы не осилила, а выбор между ними диктуется приложением, стеком технологий и планами на 3 года
ну да, пока у тебя один юзер действительно все равно кто толстый
Я бы посоветовал заменить имя "ос" т.к. plan9 уже занял эту цифру, ну и рассмотреть почему все фичи ОС, которые вам не нравятся вообще были созданы и какие задачи они решают.
С++ итераторы у вас реализованы некорректно- begin() и end() должны возвращать одинаковый тип, ни один стандартный алгоритм из <algorithm> не будет работать с вашими итераторами.
И это кстати общий случай который 11l ломает- для итераторов в таком стиле каждый алгоритм требует быть определённым для пустого begin() - не удобно, раздуваем итератор (т.к optional теперь деталь реализации итератора)
Касательно реализации итератора по строкам - во первых странно строить новые типы итераторов на базе iostream который сам итератор и понятно что получается сложно местами. has_next можно убрать если проверять поток на окончание.
Из C# итератора вы выкинули главное его свойство - ленивость(создание итератора не запускает чтение данных)
С итерацией по директориям вы тоже перемудрили.
Ну и итераторы это то где как раз уместно оптимизировать производительность вплоть до инструкций.
В общем тема интересная, но над содержанием и выводами надо критически поработать.
а зачем её отключать?
В деревнях таких франкенштейнов достаточно на ремонте стоит, но это не то как мы хотим разрабатывать ПО.
Ну если следовать аналогии то это замена одной библиотеки на другую, а один двигатель в разных моделях тракторов это конечно не новость
нет таких примеров, более мощный двигатель это замена коробки, подвески, всей электроники двигателя и после этого возможно трактор слишком тяжелый чтобы работать в поле
конечно можно сказать что мы заменим на аналогичный, но в мире софта такое не возможно
ну а теперь замените двигатель в тракторе чтобы добавить мощности, и смотрите как вся эта красивая картинка рассыпается
многие покупали толстый аккум и крышку к нему
Но если 26 это не современная версия, то какая же тогда современная?
Идея интересная, но ваш кортеж (не тупль, пожалуйста) не constexpr
Прикольно было бы реализовать обёртку поверх стандартного кортежа, которая бы пересортировывала элементы, тогда она была бы и эффективной по памяти, и constexpr
Совсем прикольно было бы сделать это всё на С++11 (но не уверен что это возможно) :)
в плюсах есть стектрейсы (с++23), и концевая оптимизация начиная с С++11
конечно трейс не покажет полную вложенность хвостовой рекурсии, однако для диагностики этого достаточно
Срослось и не один раз
https://ru.m.wikipedia.org/wiki/%D0%A3%D1%80%D1%82%D0%B0%D0%B1%D1%83%D0%BB%D0%B0%D0%BA%D1%81%D0%BA%D0%BE%D0%B5_%D0%B3%D0%B0%D0%B7%D0%BE%D0%B2%D0%BE%D0%B5_%D0%BC%D0%B5%D1%81%D1%82%D0%BE%D1%80%D0%BE%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5
https://ru.m.wikipedia.org/wiki/%D0%92%D0%B5%D0%B3%D0%B0_(%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82)
Вы внесли в LLM кучу правок и уточнений из за того, что у вас есть навыки программирования, если бы вы этого не сделали то эта хрень бы не заработала.
Но если бы вы были условным пастухом который сразу бы начал промптить то как вы узнали бы что нужно уточнять и спрашивать? Чтение сгенерированого LLM кода вас не научит программированию, LLM не понимает что пишет, она просто даёт статистически средний результат, она не может объяснить почему надо так а не иначе.
То же самое с безопасностью - LLM может элементарно воспроизводить типичные проблемы безопасности т.к. средний программист делает те же самые ошибки. И LLM так же ленив как и средний программист, потому что не понимает что часто люди пишут не идеальный пуленепробиваемый код, а "и так сойдёт".
для тех кто в танке, из свежего: https://xakep.ru/2024/04/23/rkn-vpn-blocking/
Если очень не верится давайте на вас в РКН донесем и посмотрим есть репрессии или нет.
информация об использовании впн тому пример
Потому что тот же Яндекс согласовывал свою новостную ленту с хотелками АП годами и скрывал это?
Жаль, что в ваших она гомеопатическая