Делаете годное дело, но сложное. Скептиков не слушайте. Анализируйте и двигайтесь.
В свое время играл во все подряд. Переучивался на все виду устройств: клавиатура, мышка, пады, рули, стики, мышка с вертикальным реверсом в 3Д шутерах, 3Д шутеры на кнопках и на мыше, ... Проблем не видел никогда. Но то были времена, когда мы готовы были играть во все ради игр.
Сейчас аудитория требовательна, потому что игр много. Вы правильно делаете, что упрощаете. И интерфейс и меню тоже. Это нужно 100% для подгонки под современного пользователя.
Я ребенку попробовал дать ретроконсоль. Не зашла от слова совсем. Помогал как мог, но очень тяжело. Сложна и менюха и игры. Спотыкался буквально везде.
Пример: когда я играл в Comix Zone например, когда это было в тренде, я знал что вот это начало (первый экран) и дальше могут убить (буквально в следующем экране) и я разбирался с управлением в первом, тренил все удары, комбы и т.д.; а потом уже шел на второй экран и там уже заруба. И так +/- во всех играх. Сегодня ребенок запускает игру (если не подсказывать), видит стрелку вправо, идет туда, переходит на второй экран и там отгребает по полной ибо не шарит бойца совсем. Стрелка ж не говорила, что потренься в начале. А игру как бы не поправить. Обучалок в начале игр как сейчас делают раньше не было. Поэтому игры выглядят сложнее.
Менюхи всех ретро эмулей и т.д. с миллионами игр - это отдельная песня. С вами согласен полностью. Они сильно сложные для чисто геймера и тем более ребенка.
В общем ретро я отложил на пару лет. Только танчики +/- получилось втащить :)
При этом телефона у него нет. И когда предложил поиграть на телефоне в современные игры - он уже знал четко во что хочет играть и как. Сообщество решает. У сверстников (в школе) они видят, что хотят и как это потреблять. Это сложный момент, так как там не все хороше только :(
В общем пока выбрал способ - современные игры с фильтром через меня на адекватность.
И параллельно ищу способы прививать старые хорошие игры. Но это сложно.
Отдельно про вашу новую нишу - ретрогеймеры: думаю годная идея для расширения выхлопа всей затеи, но есть пара моментов: эта ниша может со временем уменьшаться и она может со временем потребовать для себя каких то сильных отличий в дизайне (от детской ниши), что прийдется разделять продукт как то.
Но в целом ваш ход мысли кажется полностью верным: все создатели ретроХ заботятся лишь о том, что бы максимально точно провести эмуляцию и максимально быть совместимыми; но детям важна простота адаптации вашей платформы (максимально понятно и просто от их сегодняшней базы) + сообщество (дети хотят играть в то, что другие дети играют; но это уже для вас наверное потом). Просто мысли в копилку. Вам удачи!
В Pascal строки индексируются с 1, потому что в 0-ом байте хранится ее размер
В Fortran индексация может заходить за рамки в любую сторону, и в минус тоже, и можно вообще в память ОС выйти без проблем; в том его и сила
Языков с индексацией с 1 не только много, но и хватает продвигателей именно этого подхода (это один из разработчиков NeoVim, поэтому - Lua)
Как было сказано ранее, есть куча языков, в которых я могу начать индексацию с любого (JavaScript, ...), так как они список могут хранить не массивом, а деревом и т.д.
Как и многие, искал лучшее положение для рук. Пришел к тому, что нужно смотреть на предков. И подсмотрел у пианистов. Они держат кисть ровно, не сгибают. Их ремесло гораздо старше нашего, поэтому думаю, что у них уже все шишки набиты в этом.
Правда с мышкой тут дело сложнее. Но это лишний повод больше учить горячие клавиши и пользовать клавиатуру.
Но если не выражать кг через м и с, то размерности не сводятся к базису м и с. В этом базисе могут быть только их проекции.
Всм? Возьмите подставьте по методу размерности любые величины - все сходится.
Вы говорите, масса должна быть в базисе. Вот человек сделал попытку выразить все без массы. Возможно он прав. Пока не ясно. По крайней мере мне. Но опровержений я не вижу и выглядит все складно.
Знаний дальше у меня не хватает что-то здесь супердоказать дополнительно.
Ваше мнение я полностью понимаю и оно должно быть. Думаю только время покажет в итоге что будет.
П.С. Законов нет, потому что это новый базис, в котором новые законы над которыми нужно работать. В старом базисе не будет законов для этого. Почему дальше не развивается это и т.д. - я не в курсе.
Как по мне - это не просто новая таблица. А именно попытка по итогу свести базис от 3 к двум величинам. Посмотрим.
П.С.С. В общем я к тому, что человек начал делать нечто новое и очевидно не закончил. Вы говорите, что эта лошадь мертва. Я говорю, что вроде как нет. Дальше если кто-то захочет он продолжит эту работу. Проблем тут не вижу. Ошибок тут тоже нет. Просто не законченная работа. Никто никого не заставляет.
А того, что вы говорите и не требуется. Не нужно выражать/выводить кг через м и с.
То что он делал - это развитие "метода размерностей" в физике. Он сводил размерности в таблице к определенному базису. Это не значит, что мы уже умеем все величины вывести/представить через все. Это лишь говорит об общей природе этих понятий и подобных вещах. Это характеризует систему в целом. Способ говорить о системе в общем.
И так же способ понять величины, никак не входящие в таблицу. И так же увидеть, что мы возможно пропустили.
Он поставил себе цель все вывести в базисе 2ух величин. Вроде как получилось. В том и челендж - как можно меньше величин в базисе. И то, что нельзя выразить пока - может быть эта таблица и может подсказать как.
Не уверен, что таблица прям строго доказана, но она как минимум намекает на путь и направление мысли. Я смотрю на это, как на попытку что-то систематизировать. Закона еще нет, в той форме, что вы имели ввиду. Может еще рано. Но результаты точно есть.
Насколько я понял - вывод в том, что причина более быстрой работы - это разное число операций в байткоде (разница в 2 раза).
Мне кажется - это утверждение ошибочным (и несоответствие экспериментальным данным это подтверждают - 2 против 1.5).
И главная причина ошибки - это допущение:
Итак, если принять стоимость каждой команды за условную единицу, ...
Думаю этого делать не стоит никак. Думаю, что все операции помещения в стек адресов и переменных, джампы и т.д. - это все пыль и примерно одинаковы в обоих методах. А реальная потеря времени происходит в методах АППЕНД. Т.е. вам фактически сравнивать нужно:
C1 + N*CALL(APPEND)
vs
C2 + N*LIST_APPEND
Но данным способом вы эти методы сравнить не можете. Они тут для вас как черные ящики. Нужно смотреть внутрь их, что бы понять в чем суть.
Для начала можно провести испытания хотя бы просто с этих методов, без циклов. Попробовать для подтверждения. Подтвердить где теряется время. В вашем методе - вы не знаете где оно теряется и размазываете вину равномерно между всеми операциями, что не верно абсолютно (вы можете подтвердить это замерами через пустые циклы или АППЕНДы без циклов и т.д.).
Моя теория совпадает с комментариями выше: разница в том, что быстрый аппенд знает финальный размер и потому выделяет место под список только один раз, а медленный - постоянно пересоздает список с большим размером. Эти процессы примерно одинаковы везде.
И это скорее всего объясняет причину. Ваши выводы только показывают направление, но не показывают причину. Число операций не значит ничего в данном случае. Это просто хороший старт.
В общем начало есть, но нужно мерять дальше и глубже. И скорее всего все крутится вокруг аппендов. Думаю круто было бы увидеть дальнейшее погружение в это сравнение от вас.
П.С. Еще бы проверил и сравнил те методы что названы ФАСТ в быстрой версии - STORE_FAST, LOAD_FAST - все равно думаю, что их вклад незначителен, но сравнить интересно какова разница.
Получается, что если перезагрузить его или потушить ненадолго - он может недодать или выдать лишний кофе, верно? Или например девайс отключили что бы протереть, а я как раз иду и по дороге проплатил, то когда его включат - моя транзакция "старая" и уже обработанная. Можно еще кейсов придумать.
Я имею ввиду, что из-за того, что контракт не полностью замкнут в крипте, всегда будет вариант такой проблемы в подобных решениях: после сбоя возможно падение надежности, так как нарушена связность информации об оплатах и о выполненных обязательствах.
Если я все правильно понял, то решение было бы более "крипто" и надежно, если его контракт полностью затащить в крипту.
Это все в рамках рассуждений и мыслей. Так или иначе - ваше решение автоматизирует большую часть случаев. Просто прикладываю мысли про крайние и редкие.
Где вы храните сумму на которую вы уже сделали кофе? Не ту что вам зашла, а ту что вы уже отработали. Или идентификатор не последней, а отработанной транзакции.
На первый взгляд, оборачивание increment в useCallback и Button в React.memo должно предотвратить ненужные перерисовки Button. Но в данном случае выигрыш в производительности будет либо незначительным, либо его не будет вообще.
Ответ не совсем верный. Если кейс именно как в статье - ускорения не будет вообще. Так как ваш инкремент мемоизируется следующим образом:
С зависимостью - count. А значит коллбек будет пересоздаваться после каждого клика на кнопку. Значит и кнопка будет рендериться заново после каждого клика, потому как ссылка на коллбек новая.
Что бы этого не было, нужно создавать коллбек без зависимости (как вы делали ранее):
И мне кажется нужно было специально обратить внимание на эту фишку создания коллбека без зависимости.
Именно данная зависимость на count и ломает полностью оптимизацию в вопросе. А если сделать коллбек без зависимости - тогда уже можно рассуждать о том, будет ли перформанс буст и имеет ли смысл, но так он хотя бы возможен.
Отдельно про рассуждения про сложность, целесообразность, ..., скорость оптимизации из вашего вопроса:
Для тех кто это все умеет - эта информация не ценна, а для тех кто новичек - они тут ничего не запомнят и не поймут, будет просто как вода. Потому что у вас просто общие рассуждения, по верхам.
Нужно делать как в вашем же утверждении в пунктах: все мерять и сравнивать (скорость, память, сложность, размер, ...). Без замеров перформанс статьи неполны.
Просто заметил, что вам там в первых комментах накидали про то, что метод в 10 строк превращается в сложное и большое. И в других подобных статьях такой аргумент видел тоже. Эти люди просто упустили точку приложения метода. Бывает.
Хорошая статья. Тот, кто пытался минимизировать число невидимых связей к коде (особенно инфраструктурном, логических хардкодов), которые нужно "просто помнить" - тот поймет. Не раз этим занимался.
Цена у всего этого конечно не малая - резкое усложнение кода. Над поиском золотой середины между простым ЖСом и "абсолютной" типизацией ТСа и будет работать и спорить сообщество. Посмотрим к чему в итоге прийдем.
П.С. Для избежания путаницы, а бы указывал, что большая часть этих сложностей упадет на код инфры и фреймворка и их поддержку. Пользователи же (авторы клиентского кода и конкретных реализаций) получат же в основном +- те же интерфейсы, только с магической проверкой и т.д. Что бы не создавалось впечатления, что каждый мелкий метод РЕСТа на 10 строк заменится на кучу сложной дженерик магии.
Пока читал в голове мелькали воспоминания, как в свое время лопались дешевые CD-диски в приводе прямо во время игры. Было внезапно и пугающе. Один раз даже форточка (крышка) дисковода вылетела как вертолетик от удара...
П.С. Скажите, а есть статистика о том сколько разработчиков Java покинули РФ и сколько остались (из-за известных событий)? Хотя бы в процентном соотношении или больше/меньше половины?
Да. Так и есть. Мой посыл был в том, что там, например, это нормально и часть ожидаемого поведения. Но не только там. Просто был как пример.
Делаете годное дело, но сложное. Скептиков не слушайте. Анализируйте и двигайтесь.
В свое время играл во все подряд. Переучивался на все виду устройств: клавиатура, мышка, пады, рули, стики, мышка с вертикальным реверсом в 3Д шутерах, 3Д шутеры на кнопках и на мыше, ... Проблем не видел никогда. Но то были времена, когда мы готовы были играть во все ради игр.
Сейчас аудитория требовательна, потому что игр много. Вы правильно делаете, что упрощаете. И интерфейс и меню тоже. Это нужно 100% для подгонки под современного пользователя.
Я ребенку попробовал дать ретроконсоль. Не зашла от слова совсем. Помогал как мог, но очень тяжело. Сложна и менюха и игры. Спотыкался буквально везде.
Пример: когда я играл в Comix Zone например, когда это было в тренде, я знал что вот это начало (первый экран) и дальше могут убить (буквально в следующем экране) и я разбирался с управлением в первом, тренил все удары, комбы и т.д.; а потом уже шел на второй экран и там уже заруба. И так +/- во всех играх. Сегодня ребенок запускает игру (если не подсказывать), видит стрелку вправо, идет туда, переходит на второй экран и там отгребает по полной ибо не шарит бойца совсем. Стрелка ж не говорила, что потренься в начале. А игру как бы не поправить. Обучалок в начале игр как сейчас делают раньше не было. Поэтому игры выглядят сложнее.
Менюхи всех ретро эмулей и т.д. с миллионами игр - это отдельная песня. С вами согласен полностью. Они сильно сложные для чисто геймера и тем более ребенка.
В общем ретро я отложил на пару лет. Только танчики +/- получилось втащить :)
При этом телефона у него нет. И когда предложил поиграть на телефоне в современные игры - он уже знал четко во что хочет играть и как. Сообщество решает. У сверстников (в школе) они видят, что хотят и как это потреблять. Это сложный момент, так как там не все хороше только :(
В общем пока выбрал способ - современные игры с фильтром через меня на адекватность.
И параллельно ищу способы прививать старые хорошие игры. Но это сложно.
Отдельно про вашу новую нишу - ретрогеймеры: думаю годная идея для расширения выхлопа всей затеи, но есть пара моментов: эта ниша может со временем уменьшаться и она может со временем потребовать для себя каких то сильных отличий в дизайне (от детской ниши), что прийдется разделять продукт как то.
Но в целом ваш ход мысли кажется полностью верным: все создатели ретроХ заботятся лишь о том, что бы максимально точно провести эмуляцию и максимально быть совместимыми; но детям важна простота адаптации вашей платформы (максимально понятно и просто от их сегодняшней базы) + сообщество (дети хотят играть в то, что другие дети играют; но это уже для вас наверное потом).
Просто мысли в копилку. Вам удачи!
Добро пожаловать на обратную сторону луны ! :)
В Pascal строки индексируются с 1, потому что в 0-ом байте хранится ее размер
В Fortran индексация может заходить за рамки в любую сторону, и в минус тоже, и можно вообще в память ОС выйти без проблем; в том его и сила
Языков с индексацией с 1 не только много, но и хватает продвигателей именно этого подхода (это один из разработчиков NeoVim, поэтому - Lua)
Как было сказано ранее, есть куча языков, в которых я могу начать индексацию с любого (JavaScript, ...), так как они список могут хранить не массивом, а деревом и т.д.
Согласен полностью. Так и делаю.
Как и многие, искал лучшее положение для рук. Пришел к тому, что нужно смотреть на предков. И подсмотрел у пианистов. Они держат кисть ровно, не сгибают. Их ремесло гораздо старше нашего, поэтому думаю, что у них уже все шишки набиты в этом.
Правда с мышкой тут дело сложнее. Но это лишний повод больше учить горячие клавиши и пользовать клавиатуру.
Всм? Возьмите подставьте по методу размерности любые величины - все сходится.
Вы говорите, масса должна быть в базисе. Вот человек сделал попытку выразить все без массы. Возможно он прав. Пока не ясно. По крайней мере мне. Но опровержений я не вижу и выглядит все складно.
Знаний дальше у меня не хватает что-то здесь супердоказать дополнительно.
Ваше мнение я полностью понимаю и оно должно быть. Думаю только время покажет в итоге что будет.
П.С. Законов нет, потому что это новый базис, в котором новые законы над которыми нужно работать. В старом базисе не будет законов для этого. Почему дальше не развивается это и т.д. - я не в курсе.
Как по мне - это не просто новая таблица. А именно попытка по итогу свести базис от 3 к двум величинам. Посмотрим.
П.С.С. В общем я к тому, что человек начал делать нечто новое и очевидно не закончил. Вы говорите, что эта лошадь мертва. Я говорю, что вроде как нет. Дальше если кто-то захочет он продолжит эту работу. Проблем тут не вижу. Ошибок тут тоже нет. Просто не законченная работа. Никто никого не заставляет.
А того, что вы говорите и не требуется. Не нужно выражать/выводить кг через м и с.
То что он делал - это развитие "метода размерностей" в физике. Он сводил размерности в таблице к определенному базису. Это не значит, что мы уже умеем все величины вывести/представить через все. Это лишь говорит об общей природе этих понятий и подобных вещах. Это характеризует систему в целом. Способ говорить о системе в общем.
И так же способ понять величины, никак не входящие в таблицу. И так же увидеть, что мы возможно пропустили.
Он поставил себе цель все вывести в базисе 2ух величин. Вроде как получилось. В том и челендж - как можно меньше величин в базисе. И то, что нельзя выразить пока - может быть эта таблица и может подсказать как.
Не уверен, что таблица прям строго доказана, но она как минимум намекает на путь и направление мысли. Я смотрю на это, как на попытку что-то систематизировать. Закона еще нет, в той форме, что вы имели ввиду. Может еще рано. Но результаты точно есть.
Хорошая подборка. В закладки.
Только бы еще примеров с замерами ;)
Насколько я понял - вывод в том, что причина более быстрой работы - это разное число операций в байткоде (разница в 2 раза).
Мне кажется - это утверждение ошибочным (и несоответствие экспериментальным данным это подтверждают - 2 против 1.5).
И главная причина ошибки - это допущение:
Думаю этого делать не стоит никак. Думаю, что все операции помещения в стек адресов и переменных, джампы и т.д. - это все пыль и примерно одинаковы в обоих методах. А реальная потеря времени происходит в методах АППЕНД. Т.е. вам фактически сравнивать нужно:
Но данным способом вы эти методы сравнить не можете. Они тут для вас как черные ящики. Нужно смотреть внутрь их, что бы понять в чем суть.
Для начала можно провести испытания хотя бы просто с этих методов, без циклов. Попробовать для подтверждения. Подтвердить где теряется время. В вашем методе - вы не знаете где оно теряется и размазываете вину равномерно между всеми операциями, что не верно абсолютно (вы можете подтвердить это замерами через пустые циклы или АППЕНДы без циклов и т.д.).
Моя теория совпадает с комментариями выше: разница в том, что быстрый аппенд знает финальный размер и потому выделяет место под список только один раз, а медленный - постоянно пересоздает список с большим размером. Эти процессы примерно одинаковы везде.
И это скорее всего объясняет причину. Ваши выводы только показывают направление, но не показывают причину. Число операций не значит ничего в данном случае. Это просто хороший старт.
В общем начало есть, но нужно мерять дальше и глубже. И скорее всего все крутится вокруг аппендов. Думаю круто было бы увидеть дальнейшее погружение в это сравнение от вас.
П.С. Еще бы проверил и сравнил те методы что названы ФАСТ в быстрой версии -
STORE_FAST, LOAD_FAST- все равно думаю, что их вклад незначителен, но сравнить интересно какова разница.Получается, что если перезагрузить его или потушить ненадолго - он может недодать или выдать лишний кофе, верно? Или например девайс отключили что бы протереть, а я как раз иду и по дороге проплатил, то когда его включат - моя транзакция "старая" и уже обработанная. Можно еще кейсов придумать.
Я имею ввиду, что из-за того, что контракт не полностью замкнут в крипте, всегда будет вариант такой проблемы в подобных решениях: после сбоя возможно падение надежности, так как нарушена связность информации об оплатах и о выполненных обязательствах.
Если я все правильно понял, то решение было бы более "крипто" и надежно, если его контракт полностью затащить в крипту.
Это все в рамках рассуждений и мыслей. Так или иначе - ваше решение автоматизирует большую часть случаев. Просто прикладываю мысли про крайние и редкие.
Я может где то упустил, но:
Где вы храните сумму на которую вы уже сделали кофе? Не ту что вам зашла, а ту что вы уже отработали. Или идентификатор не последней, а отработанной транзакции.
Или просто в памяти?
Ответ не совсем верный. Если кейс именно как в статье - ускорения не будет вообще. Так как ваш инкремент мемоизируется следующим образом:
С зависимостью -
count. А значит коллбек будет пересоздаваться после каждого клика на кнопку. Значит и кнопка будет рендериться заново после каждого клика, потому как ссылка на коллбек новая.Что бы этого не было, нужно создавать коллбек без зависимости (как вы делали ранее):
И мне кажется нужно было специально обратить внимание на эту фишку создания коллбека без зависимости.
Именно данная зависимость на
countи ломает полностью оптимизацию в вопросе. А если сделать коллбек без зависимости - тогда уже можно рассуждать о том, будет ли перформанс буст и имеет ли смысл, но так он хотя бы возможен.Отдельно про рассуждения про сложность, целесообразность, ..., скорость оптимизации из вашего вопроса:
Для тех кто это все умеет - эта информация не ценна, а для тех кто новичек - они тут ничего не запомнят и не поймут, будет просто как вода. Потому что у вас просто общие рассуждения, по верхам.
Нужно делать как в вашем же утверждении в пунктах: все мерять и сравнивать (скорость, память, сложность, размер, ...). Без замеров перформанс статьи неполны.
Правильное дело делаете и у вас явно получается!
На сравнения с Масками и Безосами не обращайте внимание. Мы всегда делаем по другому и часто сильно дешевле.
ТО же самое и по поводу "зачем это все и для кого". Циолковский вроде как тоже, когда все это изучал, рынка еще не было.
Просто заметил, что вам там в первых комментах накидали про то, что метод в 10 строк превращается в сложное и большое. И в других подобных статьях такой аргумент видел тоже. Эти люди просто упустили точку приложения метода. Бывает.
Хорошая статья. Тот, кто пытался минимизировать число невидимых связей к коде (особенно инфраструктурном, логических хардкодов), которые нужно "просто помнить" - тот поймет. Не раз этим занимался.
Цена у всего этого конечно не малая - резкое усложнение кода. Над поиском золотой середины между простым ЖСом и "абсолютной" типизацией ТСа и будет работать и спорить сообщество. Посмотрим к чему в итоге прийдем.
П.С. Для избежания путаницы, а бы указывал, что большая часть этих сложностей упадет на код инфры и фреймворка и их поддержку. Пользователи же (авторы клиентского кода и конкретных реализаций) получат же в основном +- те же интерфейсы, только с магической проверкой и т.д. Что бы не создавалось впечатления, что каждый мелкий метод РЕСТа на 10 строк заменится на кучу сложной дженерик магии.
Настоящий пример инженера:
Он делал, что делал, не потому что платили или любили, а потому что не мог не делать. Хоть и мало что вышло в серию. Хоть и была тюрьма.
Просто занимался чем хотел и что умел. И получил результат по-итогу и вошел в историю.
Дж, кг, м, с - в одной формуле. Есть еще вот такая вот константа.
Такая строка в списке сокращений в книге - это мощный интригующий фактор продвижения! :)
Плюсую за изменение шрифта. Сравните на Хабре например и у вас. Он сильно не стандартный. Может в этом и фишка, но я не оценил именно этот момент.
Мне режет глаз больше всего разная ширина вертикальных линий в шрифте. Взгляд все время о них спотыкается.
П. С. В целом - дело годное делаете! Книгу прочту обязательно и отпишу по сути если что-то еще будет.
Пока читал в голове мелькали воспоминания, как в свое время лопались дешевые CD-диски в приводе прямо во время игры. Было внезапно и пугающе. Один раз даже форточка (крышка) дисковода вылетела как вертолетик от удара...
В общем я бы место рядом с маховиком не брал бы.
Отличная статья, продукт и команда! Удачи вам!
П.С. Скажите, а есть статистика о том сколько разработчиков Java покинули РФ и сколько остались (из-за известных событий)? Хотя бы в процентном соотношении или больше/меньше половины?