Нет, все-таки давайте еще раз.Нахуй мне ваша чистота на практике? Хаскели-хуяскели.Вот пишу я арканоид. Ну ок, логика чистая, все как по книжке, четко-красиво.Манатки-хуятки, ну хуй с ними, вот просто моя логика отдает некие структуры, описывающие действия, а внешний грязный интерпретатор их потом выполняет.Но на практике я тупо вместо сайд-эффектного update или render возвращаю структуру, которая это описывает. И она тут же выполняется. Все, больше с ней ничего не происходит.В теории - ок, тестирование там, прозрачность, интроспекция, хуе-мое.Но у меня не эвент сорсинг, я арканоид пишу. А писал бы эвент сорсинг - вся эта хуйня все равно делалась бы через базу.Ну и нахуй мне ваша чистота на практике?
Вообще, тут все (как всегда) упирается в IoC. По сути, у нас есть два варианта: либо прямая глобальная зависимость, либо возвращение сценария для обработки внешним интерпретатором.То есть мы либо напрямую тыкаем палочкой глобальное состояние (например, берем и изменяем позицию мячика в нашем арканоиде). Либо мы возвращаем некую чистую структуру, которую мы можем взять и рассмотреть, и которая потом запихивается в грязный интерпретатор, который уже двигает наши шарики.Часто совмещают оба подхода: состояние мы читаем напрямую из read-only глобального контекста, а вместо прямых мутаций возвращаем описания мутаций. Ну это очевидный хороший вариант.Мой поинт в том, что в подавляющем большинстве случаев следует выбирать глобальную зависимость и прямые мутации. (Чтобы не было лапши, состояние нужно хранить централизовано, юнидирекшнл флоу там, все такое прочее - ну это в 2k20 даже жс-макаке понятно, считай уже закрытая проблема.)Потому что чистота (в таком виде, как мы ее тут обсуждаем) - это на самом деле совсем не про качество кода, минимизацию лапши и т.п. Это исключительно про интроспекцию. Если нам нужно (необходимо, обязательно) как-то анализировать наши потоки данных и строить по ним какие-то метаданные - ок, мы пилим чистую архитектуру. Вопрос тут не в сайд-эффектах как таковых, а именно в данных: либо они у нас идут неявно, лио мы их делаем явными. Сайд-эффекты как таковые тут вообще не первичны. Отличие между вызовом какого-нибудь условного BallManager.moveBall(...) и возвращением структуры {"event_type": "move_ball", ...} исключительно и только в том, что последнее мы можем визуализировать\сохранить в лог\среплеить на других данных\етк. Соответственно, если перед нами не стоит такой задачи или если наш стек технически не предоставляет возможности ее реализовать, то это все - карго-культ и мы занимаемся хуйней.tl;dr: манатки ненужны, сосите хуй.
>>1341650 (OP)>Нахуй мне ваша чистота на практике?Все равно что спросить "Зачем мне нужен хлеб, если я и сырым зерном не плохо питаюсь?".
>>1341650 (OP)Ну пиши свой арканоид так, раз тебе так больше нравится. Только потом не плачься, что для добавления новой фичи придется пилить арканоид 2, ибо посмотрев на код первого, ты скажешь: "ну его нахуй, проще переписать".>>1341872Привет, Егор. Как твой некрокраси?
>>1341877Нечего сказать по теме -> уебывай нахуй, обоссанное быдло.>>1341898По большому счету, то же самое можно адресовать и тебе. Я предлагаю на обсуждение вполне конкретный технический вопрос, а в ответ вместо контраргументов получаю какую-то детсадовско-гуманитарную чепуху, смысловое наполнение которой стремится к нулю. С тем же успехом ты мог бы просто написать "соси хуй" - стилистика другая, семантика та же.
>>1342349Я тебе дал конкретный технический ответ: маленькие изолированные куски всегда проще в поддержке и улучшайзинге, чем ёбаный монолит. Если не собираешься делать свой арканоид расширябельным, то хоть на гото пиши. Если собираешься, то надо декомпозировать задачу как можно сильнее, ослабляя зацепление и усиливая связность, в том числе: чистота отдельно, стейт отдельно, ио отдельно, конфиг отдельно итд. А на самом деле всем похуй как ты пишешь, лишь бы арканоид получился классным. И да, соси хуй.
>>1342401Ты вообще читал первый пост в этом треде? Я описываю два разных способа ослабления зацепления, и почему манаткоподобная архитектура - это на самом деле не про ослабление зацепления. В ответ ты пишешь, что надо ослаблять зацепление. Ну камон, сам понимаешь, как это выглядит.
>>1342423>предлагает тыкать палочкой в стейт из каждого уголка кода>Я описываю два разных способа ослабления зацепленияНу ок.
>>1342462>описываю, почему "тыканье стейта" полностью эквивалентно воображаемой манатной манячистоте>Ну ок.Ясно, значит не читал.
>>1342505Схуяли эквивалентно? Например, вот у тебя есть мячик и блок, под которым мячик может пролетать и снег на заднем плане идет. Ты в какой последовательности будешь всё это отрисовывать? А надо ли вообще мячик отрисовывать? Как ты эту ситуацию будешь разруливать, когда у тебя ИО вместе со стейтом по всему коду распихано? С манатками понятно - у тебя ИО инкапсулировано и делай че хочешь: сортируй по z-индексу структурки, определяй пересечения, видимость итд.
>>1342517В реальном мире (литералли во всех реальных библиотеках рендеринга) это решается через контейнеры-слои (2д) или ортографическую проекцию (2д в 3д). Какой-то неудачный пример.Определять пересечения через ИО - это вообще какая-то пушка. Где тут связь, але? У тебя есть координаты, бери и считай, какой тут ио? За уши притягиваешь.По-моему ты вообще не туда воюешь. Настоятельно рекомендую все-таки прочитать первый пост.
>чистота на практике?на практике зная про эту концепцию ты будешь в промышленных языках все же минимизировать сайд-эффекты в своих функциях и методах, зная что это в общем случае полезно
>>1342575Это и жс-макаке понятно (в 2019-то году), я про конкретный кейс описанный в оп-посте, а не про "минимизацию сайд-эффектов" вообще: >>1341657
>>1342401Один хуй лапша с зацеплением получится. Конкретный пример: ситуация, когда шарик сталкивается с блоком и нужно отрисовать частицы и проиграть звук. Шарик может либо сам это сделать, либо как-то дать понять, что произошло столкновение.В первом случае шарик должен знать о существовании и иметь доступ к графической и аудио системам, что снижает связность, усиливает зацепление и усложняет конструкторы.Во втором случае у шарика и систем должно быть какое-то соглашение, чтобы они понимать друг друга и реагировать на сообщения. Шарик может кинуть сообщение BallEvent.Impact и это опять же усилит зацепление, еще и Егор вылезет и даст пизды за енумы.И это еще очень простой пример. А если игра имеет текстуры, а звук и частицы столкновения зависят от материала (камень или дерево, например) платформы?Так что на хуй этих Егоров и Вестов. И программирование на хуй.
>>1356848>столкновение.Очевидно же, что в результате образовался, например, объект УничтожениеБлока, который, например, создаст объекты ЗвукУдараОБлок и РазлетающиесяЧастицыБлока. Шарик в свою очередь создаст объект ЗвукУдараОШарик.И зацепление тут нахуй ушло, и звуки разные у разных объектов, и вообще архитектура заебись стала.
>>1356890>в результате образовался, например, объект УничтожениеБлокаnew не во вторичном конструкторе?Откуда создаваемые объекты узнают о системах звука и графики?
>>1343503Ваистину язык богов. Взял и компильнул одной командой без задней мысли и можно играть. И даже не нужно устанавливать пять менеджеров зависимостей предварительно скачав менеджер менеджеров зависимостей, а после загружать несколько гигов зависимостей раздристанных по 200000 файлам по нескольким десяткам дотдриста в home директории.
>>1356975>Откуда создаваемые объекты узнают о системах звука и графики? Эти объекты уже написаны так, что используют некий HAL.
>>1357115Так нельзя. Выводов может быть несколько, еще в игре есть настройки громкости звука, которые тоже нужно учитывать.
>>1356890>объект УничтожениеБлока, который, например, создаст объекты ЗвукУдараОБлок и РазлетающиесяЧастицыБлока. Шарик в свою очередь создаст объект ЗвукУдараОШарик.А потом оказывается, что когда уничтожается весь ряд блоков, то нужно играть специальный общий звук вместо индивидуальных для каждого блока (иначе все превращается в кашу), и твоя красивая архитектура идет по пизде.
>>1357125>А потом оказывается, что когда уничтожается весь ряд блоковОчевидно, тогда создается объект УничтожитьРядБлоков
>>1356890>объект УничтожениеБлока, который, например, создаст объекты ЗвукУдараОБлок и РазлетающиесяЧастицыБлока. Шарик в свою очередь создаст объект ЗвукУдараОШарик.А потом оказывается, что когда уничтожается весь ряд блоков, то нужно играть специальный общий звук вместо индивидуальных для каждого блока (иначе все превращается в кашу), и твоя красивая архитектура идет по пизде.
>>1357130А с графикой как? До HAL еще далеко: надо специальный эффект с другими шейдерами отрисовать (которые еще надо загрузить).Да и чтобы доступ к HAL получить, надо чтобы он доступен был - то есть нужен static.
>>1357157if(collided){new SoundBlockImpact(this, collisionBlock).play();new EffectBlockImpact(this, collisionBlock).draw();}Так (хоть и неправильно использовать new в методах)? Что дальше?
>>1357187>хоть и неправильно использовать new в методахА где их еще использовать, лол?>ТакПочти. Раз у нас игра, значит объект должен тригерриться в тик игры. Значит объект имплементирует интерфйс Tickable и коннектится к источнику тиков, который вызывает интерфейсный метод tick(). А не play / draw в методе как ты сделол.
>>1357215>А где их еще использовать, лол?Пик, EO Chapter 3.6>Значит объект имплементирует интерфйс Tickable и коннектится к источнику тиков, который вызывает интерфейсный метод tick()new SoundBlockImpact(tickSource, this, collisionBlock).play();?Потому что объект должен знать о чем-то, перед тем как это что-то вызвать.
>>1357219>EO Chapter 3.6Егор сильно загоняется. В модели акторов, например, это нормальная ситуация.Я имею ввиду как-то так:constructor SoundBlockImpact(TickSource t) {t.connect(this)}class TickSource {Tickable objects;....method processTick() {foreach o in this.objects: o.tick();}}...new SoundBlockImpact(tickSource);
>>1356975>>1357118Ты про IoC и депенденси инджекшн вообще ничего не слышал? Иди какую-нибудь книжку по хаскелю прочитай, там все объяснят. Вообще, для таких вопросов есть ньюфаг-тред, нахуй итт скатывать?
>>1357242>>1357219Вообще, у вас просто фестиваль говнокода какой-то. У одного игровая логика зависит от ввода-вывода и звука, у другого шарик занимается проверкой столкновений, вообще охуеть.
>>1357244Ты чем читаешь? Чтобы IoC или DI объект в конструктор передать, надо чтобы вызывающий объект имел к нему доступ через аргументы метода, либо состояние.Суть в том, что чем глубже и шире зарываешься, тем больше приходится эти объекты за собой тянуть, и они сами увеличиваются либо в размере, либо в количестве.А Егор говорит, что 5+ аргументов в конструкторе или 3+ метода у интерфейса - говнокод.>>1357248Ну покажи нормальный код, хули ты?
>>1357248Мы тут обсуждаем и критикуем различные подходы к решению интересных задач, пока ты велосипедишь очередной круд.
>>1357260>А Егор говорит, что 5+ аргументов в конструкторе или 3+ метода у интерфейса - говнокод.Кстати, что Егор говорит по поводу композиции интерфейсов? В мейнстримных ООП язычках этого нет, а очень хочется.
>>1357271Я - оп итт треда, долбоеб. Ты тут постишь говнокод.>>1357260Какие 5 аргументов? Вообще, забудь про все свои конструкторы, объекты и прочую хуйню. У тебя есть функция. Функция делает конкретную полезную работу (считает протеины, например). Она принимает на вход все, что ей нужно, и возвращает результат. "Все, что ей нужно" - это обычно мапа, в которой компоненты, конфигурации и т.п. (контекст). И дальше тут есть 2 подхода: либо каждая функция принимает контекст целиком, и там уже достает из него нужные ей вещи, либо каждая функция принимает минимальный набор компонентов, который ей нужен для выполнения задачи (первое удобнее, второе очевиднее). Если у тебя какая-то функция начинает принимать 5+ на самом деле 2+ таких аргументов, то это значит, что тебе нужно абстрагировать их в новый компонент (вместо коннектов к постгресу и к редису делай один компонент персистенс лэйер). А дальше ты указываешь реализации компонентов в конфиге и твоя DI-либа строит граф зависимостей, инициализирует (и завершает) их в нужном порядке ну и все заверте...Объекты - это просто нескучный синтаксис для связанного набора функций с нужными им компонентами. к которому заодно прилеплены неймспейсы, статики, конструкторы, типы, фиксированная модель работы с памятью, семантика эквивалентности и прочая хуйня, накидано все в кучу и заcouplено потому что можем и "ну удобно же, ну чо">>1357260>Ну покажи нормальный код, хули ты? Столкновениями занимается система обработки коллизий, мячик просто имеет компонент "координаты" и все. Игровая логика (любая бизнес-логика) никогда не зависит от внешнего мира (и желательно реализована чистыми функциями, если возможно).
>>1357286>Что это может нарушить SRP.Композиция объектов и так его нарушает.>>1357300>Игровая логика (любая бизнес-логика) никогда не зависит от внешнего мира (и желательно реализована чистыми функциями, если возможно). Сказал ОП, у которого все функции гадят в ИО и стейт.
>>1357300>Вообще, забудь про все свои конструкторы, объекты и прочую хуйню.>Объекты - это просто нескучный синтаксис для связанного набора функций с нужными им компонентами.Ты вот это серьезно сейчас?>мячик просто имеет компонент "координаты" и всеМячик имеет компоненты, в том числе и физический, который и содержит "координаты", "векторы скорости и ускорения", да еще и сам решает, как и куда ему двигаться. Потому что это реальный объект, а не какая-то абстрактная система.Так же как и твое тело и Земля сами притягиваются друг к другу, не потому, что какая-то там система говорит им как поступать, а благодаря поведению, присущим объектам с массой во Вселенной.>>1357315>Композиция объектов и так его нарушаетКаким образом?
>>1357315>Сказал ОП, у которого все функции гадят в ИО и стейт. Прочитай первый пост в треде надо было сразу в оп-пост пихать видимо, поинт вообще не в этом.>>1357318>Ты вот это серьезно сейчас?Давай без вот этой хуйни, ок? Есть что по делу сказать - говори, приводи аргументы, а вот эти риторические вздыхания нахуй не нужны.>да еще и сам решает, как и куда ему двигатьсяНе решает, компоненты только хранят данные, поведения у них нет.>Потому что это реальный объект, а не какая-то абстрактная система."Физический компонент мячика" - это реальный объект, а не какая-то абстрактная система. Ок.>Так же как и твое тело и Земля сами притягиваются друг к другуНе притягиваются, никакого поведения и взаимодействия у них нет, просто пространство так деформировано. Учи физику, чтобы не быть баттхертом.
>>1357330>Давай без вот этой хуйни, ок? Есть что по делу сказать - говори, приводи аргументы, а вот эти риторические вздыхания нахуй не нужны.Давай просто представим ситуацию, что у шарика может быть бустер, который несколько тиков ускоряет шарик, либо позволяет проходить сквозь блоки. Как ты это с ФП решишь (код)?>Не решает, компоненты только хранят данные, поведения у них нет.Ты точно туда воюешь? Я тебе про ООП говорю, где всё (в идеале) - объекты. А объекты (в идеале) не хранят данные - у них есть только состояние (неизменяемое) и поведение.>просто пространство так деформированоИ это пространство двигает материальные объекты, да? Типа МЕНЕДЖЕР?
>>1357343>у шарика может быть бустерИ в чем проблема? Цепляешь компонент CanHazBusterz, или по нажатию цепляешь сам бустер, или как там у тебя задумано.>Как ты это с ФП решишь (код)?При чем тут фп вообще, если речь об архитектуре как таковой?>Ты точно туда воюешь?Я никуда не воюю. Ты сказал, что у тебя компоненты решают, куда им двигаться. Я тебе отвечаю, что компоненты ничего не решают, компоненты просто хранят данные, по определению.>не хранят данные - у них есть только состояниеНу такое, да.>И это пространство двигает материальные объекты, да?Нет, объекты просто находятся в кривом-косом пространстве. Движение - это чисто хьюманская абстракция физика 7 класс привет. Алсо, какое это имеет отношение к разработке софта, напомни? весьма АБСТРАКТНОЕ евпочя
Ебанутые в этом итт треде пытаются сделать движок на все случаи жизни, получая в итоге жидкое нефасованное.Все юнитятки, годоты и т.д. годятся только для лёгкой хуйни без задач на пару моделей/спрайтов с блумом и ЭшДиАр.
>>1357356Ну ты код-то покажи, хули?>При чем тут фп вообще, если речь об архитектуре как таковой?При том, что дизайны отличаются.
>>1357375Какой код? На каком языке, с какой реализацией ecs, что конкретно он должен делать? Чо по срокам? Может ты все-таки сам погуглишь, что такое компоненты в ецс, ну или хотя бы сформулируешь, что тебе непонятно?>При том, что дизайны отличаются.Какие дизайны, чем отличаются? Единственная фп-специфичная вещь в моих постах - упоминание в скобочках того, что бизнес-логика в идеале должна быть на чистых функциях.
>>1357398Ты ебанутый? Ты спизданул>Вообще, у вас просто фестиваль говнокода какой-тоПри этом ты отказываешься показать не говнокод, маняврируя.Просто любое решение >>1356848 с "не говно" кодом покажи, чтобы я мог тебя лицом в него макнуть.
>>1357412>Ты ебанутый?Почему ты отвечаешь вопросом на вопрос?>Конкретный пример: ситуация, когда шарик сталкивается с блоком и нужно отрисовать частицы и проиграть звук.Ну, у тебя есть система, которая бегает по компонентам position+collider и кидает эвент collision(e1, e2), ты на него подписываешься и в зависимости от типов твоих энтитей проигрываешь нужный звук и спавнишь нужные частицы. Что конкретно тебе в этом решении непонятно?
>>1357454Pubsub - говнокод? Или что ты хочешь сказать? Если у тебя не хватает ума сформулировать полноценное предложение, то съеби лучше в /b или хотя бы ньюфаг-тред.
>>1357491Капитан Относительность, мое почтение.>>1357495Ты совсем аутист? Я тебе три поста назад все подробно описал. Давай ты уже съебешь в другой тред троллить тупостью, ладно?>>1357503Ну, это зависит. Для laba1 действительно ненужно, азаза. Что именно ты понимаешь под DI?
>>1357356>Цепляешь компонент CanHazBusterz, или по нажатию цепляешь сам бустерИ сосешь хуй потому что скорость инкапсулирована.
>>1357516>То же что и все.Ну то есть ты не понимаешь, что это такое, и просто хотел привлечь внимание, чтобы тебе объяснили :3 ЧТД.Попробуй написать любую систему, которая подразумевает расширение посредством плагинов (веб-фреймворк навелосипедь например, классека же), на практике сразу все встанет на свои места.
>>1357513>Капитан Относительность, мое почтение.Ну во-первых, Капитан Граница Применимости, во-вторых не деформация, а кривизна пространства-времени. А в-третьих тот анон прав и твой выпук про деформацию пространства совершенно неуместен.
>>1357532НЕ НУЖНО>веб-фреймворкСм Rails>посредством плагиновНужен код который эти плагины подтягивает, DI тут вообще никаким боком. Тут еще есть момент - с перекомпиляцией или без (или на динамике); с первым попроще, а второй нахуй не нужен в 99 процентах.
>>1357695>Капитан Граница ПрименимостиУ ОТО или у классмеха? ;) Вопрос риторический.>не деформация, а кривизна пространства-времени>объекты просто находятся в кривом-косом пространствеТы какой-то аутист и сам не понимаешь, к чему приебываешься. Деформация = изменение кривизны. Иди уроки делай.>выпук про деформацию пространства совершенно неуместенА по-моему в этом треде неуместен ты со своими безаргументными высерами. Иди в /b с одноклассниками спорь но сперва уроки.
>>1357531Куда инкапсулирована? Иди уже погугли, что такое ecs, заебал троллить тупостью.>>1357710>Нужен код который эти плагины подтягивает, DI тут вообще никаким боком))
>>1357798>Ты какой-то аутист и сам не понимаешь, к чему приебываешься. Сказал доебывающийся до модели гравитации аутист.>Деформация = изменение кривизны.Иди-ка ты нахуй со своими определениями. Понятие деформации относится к ФТТ.>А по-моему в этом треде неуместен тыСвое мнение можешь запихать себе в жопу. Кривизна пространства-времени одна из возможных моделей гравитации.А теперь иди учи физику и не пизди о том, чего не понимаешь.
>>1357866>Сказал доебывающийся до модели гравитацииТы обознался, я до гравитации не доебывался. Перечитай диалог.>Кривизна пространства-времени одна из возможных моделей гравитации.Капитан Относительность, ну мы ведь уже здоровались.
>>1357997>я до гравитации не доебывался.Ой вей, память отшибло?>>1357330>>Так же как и твое тело и Земля сами притягиваются друг к другу>Не притягиваются, никакого поведения и взаимодействия у них нет, просто пространство так деформировано. Учи физику, чтобы не быть баттхертом.
>>1357799>>Нужен код который эти плагины подтягивает, DI тут вообще никаким боком>))Пока что совсем жиденько. Ты уж постарайся еще, промытка дядюшки Боба и его подсосов.>>1357802Суббота же. Да и твоя мамка сама себя не выебет.
>>1357356>компоненты просто хранят данные, по определению.У тебя все определения - какое-то не общепринятое говно.То деформация = кривиза, то ньютоновская гравитация - не гравитация, то компонент содержит только данные. Ты наркоман, чтоле?
>>1358290Вообще-то я просто разместил объ указал, что существует более общая модель, в которой утверждения того анона не выполняются, да и в целом его утверждения не имеют к "Реальному Миру"(с)(тм) никакого отношения, ибо все зависит от выбранной модели (абстракции). Что не так-то?>>1358371>У тебя все определения - какое-то не общепринятое говно.Ты за выходные так и не смог погуглить, что такое ecs. У тебя айкью где-то на уровне табуретки, покинь этот тред.
>>1358667>Вообще-то я просто разместил объ указал, что существует более общая модельПрекращай вилять жопой, ты просто доебался до модели, что абсолютно несущественно в той беседе.
>>1358668>При чем тут дядюшка Боб? Передачу аргументов в функции придумал анклбоб? Просрал ньюфагам мозги до состояния>хоть и неправильно использовать new в методахскорее всего именно он. А еще эти охуительные истории про методы не более трех строк и то что лучше вынести кусок кода чтобы дать ему имя блядь лучше чем написать комментарий. Хочется его подвесить за яйца о ставить висеть пока они сами не оторвутся.>Ну такое. Чмо тупое. В сраку тебя ебал.
>>1356848>еще и Егор вылезет и даст пизды за енумы.Не вылезет, потому что его здесь сразу же накормят потными нигерскими хуйцами.
>>1358844В беседе о том, как многое зависит от выбранной модели, абсолютно несущественно, что существуют разные модели. Ок.>>1359011>скорее всего именно он. Ты здесь недавно, да?
>>1359156>В беседе о том, как многое зависит от выбранной модели, абсолютно несущественно, что существуют разные модели. Ок.Выбор базовой модели основан лишь на том, какую систему моделируем. Тот анон предложил находиться в рамках классическойможет задача у него такая, но ты за каким-то хуем влез со своим релятивизмом.
Какие нахуй DI IOC Монады хуяды сайдеффекты. Вы что ебанутые?Память - плоская. Там вперемешку данные и инструкции для ЦП.ЦП делает то, что написано в памяти, пока не остановится.Все нахуй.
>>1341650 (OP)>Но на практике я тупо вместо сайд-эффектного update или render возвращаю структуру, которая это описывает. И она тут же выполняется. Все, больше с ней ничего не происходит.Не-а.Если при создании игры ты в любой момент можешь поставить твои эвенты на паузу, откатить, смотреть покадрово и т. п., это очень сильно облегчит тебе тюнинг игровой механики, записывание демок, а если говорить не про игры, то undo-redo и прочее прочее. По умолчанию это лучшая архитектура. На практике.
>>1359336>Я тут самый алтфак))>>1359223>Тот анон предложил находиться в рамках классическойНет, он такого не предлагал. Он начал заливать про то, что ВОТ В РЕАЛЬНОМ-ТО МИРЕ у нас объекты друг в друга гравитацией кидаются и время существует, на что я ему провел по губам своим релятивизмом.
>>1359614Первый коммент по теме треда, мое почтение.Нюанс в том, что на практике все эти undo-redo и прочие откаты нужны в одном случае из ста. (Вообще, я об этом писал в начале треда.) А в 99 случаях из ста они висят мертвым весом, пока ты думаешь, что ну вот в следующий раз оно обязательно пригодится. Вообще, это (оверинжиниринг) - одна из форм преждевременной оптимизации. Вместо того, чтобы решать поставленную задачу, ты выдумываешь сам себе новые задачи, которые к изначальной, как правило, имеют мало отношения.Так вот, а в том 1 случае из ста, когда тебе это действительно нужно, на практике ты можешь добиться того же эффекта просто грамотно подходя к хранению данных. Если стейт у тебя лежит в едином хранилище (а это справедливо и для современного клиент-сайда, и для игрушек на ецс, и даже внезапно для типичной веб-хуйни), то тебе не составит труда навесить вотчеров на это хранилище и точно так же записывать свои эвенты - при том только те, что тебе нужны, и только тогда, когда тебе это нужно. Без оверхеда в остальных случаях.
>>1360484>Нюанс в том, что на практике все эти undo-redo и прочие откаты нужны в одном случае из ста.Undo-redo нужны в любом пользовательском софте.В одном случае из ста при выбранных архитектурных решениях добавление undo-redo системы в текущий код выгодно. В 99 - не выгодно. Но это не значит, что не нужно.Иными словами, кодер пишет как придется, через год его программа выстреливает и юзеры молят об undo-redo, а менять что-либо в этой императивной лапше уже тяжело, вот и отписывается он, не нужно мол, я не буду два месяца перепиливать код.А если писать сразу как надо, то тебе и undo-redo реализовать просто, и сам код не становится сложнее, чем был. Что касается оверхеда, то вряд ли он будет на самом деле. Если у тебя игра, то список не обязательно хранить - выполнил и выкинул. А самые тяжелые части у игр это точно не подобная логика.>одна из форм преждевременной оптимизацииНаоборот. Это у тебя преждевременная оптимизация - ты заранее решил, что такая архитектура якобы затратна по сравнению с грязным стейтом. Это в худшем случае преждевременная пессимизация.Тут дело в другом - так писать непривычно. Но не сложнее.
>>1360635>Undo-redo нужны в любом пользовательском софте.Ну вот джвач как бы тоже "пользовательский софт". Куда тут андо-редо? Анон, не нужно таких сомнительных овергенерализаций.>В 99 - не выгодно. Но это не значит, что не нужно.Ну хуй знает, какие-то у тебя странные представления о мире. I'm a simple man, u menya rynochek reshaet В твоем примере это же как раз выгодно (не пришлось бы переделывать архитектуру, чтобы решить поставленную задачу), просто кодер с перспективой не угадал.>А самые тяжелые части у игр это точно не подобная логика.Ну ты выше говорил о реплеях и подобной шняге. Для этого тебе все изменения состояния в игровой логике нужно прогонять через "создал - выкинул".>Это у тебя преждевременная оптимизация - ты заранее решил, что такая архитектура якобы затратнаЯ ведь говорю не только (и не столько) о затратах памяти и цпу. Я говорю об усложнении архитектуры, об усложнении кода, об увеличении когнитивных затрат. Без видимых преимуществ.>Тут дело в другом - так писать непривычно. Но не сложнее.Ну кому как, мне-то как раз привычно. Ты вообще почему-то выше говорил об "императивной лапше", хотя я в общем-то рассматриваю два подхода, которые применимы в функциональном коде.Алсо, ты никак не адресовал мой последний абзац, который решает все описанные тобой в этом посте проблемы с использованием другого подхода и без оверхеда.
>>1360635>через год его программа выстреливает и юзеры молят об undo-redo, а менять что-либо в этой императивной лапше уже тяжелоЕсли ты делаешь какой-то редактор, то undo-redo подразумевается изначально, и соответственно закладывается при проектировании. В функциональщине у тебя отмены вот прямо искаропки не будет, все равно придется какую-то полноценную систему проектировать. Задавать сущности для стека команд, слияния команд, и т.д.
>>1359614>при создании игры ты в любой момент можешь поставить твои эвенты на паузу, откатить, смотреть покадровоЭто легко делается на крестах без всякой функциональщины. Выделяется арена под стейт игры, и туда пишутся стейты кадров, как в кольцевой буфер. Так, кстати, менеджмент ресурсов получается проще, чем с персистентным мутабельным стейтом.
>>1360829Ну если ты юзаешь например что-то типа https://github.com/tonsky/datascript для хранения стейта, то именно что будет и именно что искаропки. Но для этого тащем-то манаток и ивент сорсинга как раз и не надо. Да и в принципе в любом языке с персистентными структурами простейший андо-редо делается нахаляву в полторы строчки. Это если тебе надо как в имаксе например строить дерево всех путей редактирования, по-умному объединять отдельные изменения в целостные команды - это да, тут придется немного повозиться. Но все равно на порядок проще, согласись.>>1360830>Так, кстати, менеджмент ресурсов получается проще, чем с персистентным мутабельным стейтом.Раскрой мысль, если не затруднит?>>1360484-кун
>>1360921>Раскрой мысль, если не затруднит?С мутабельным стейтом надо велосипедить фактически маленький перемещающий сборщик мусора, менеджить удаление/добавление компонентов, поддерживать консистентность ссылок (например, если компоненты лежат в линейном массиве и при удалении последний элемент перемещается на место удаленного).С (почти) иммутабельным стейтом все делается в одну фазу при копировании компонентов в новый фрейм. Внутри фрейма компоненты только добавляются, мертвые компоненты просто помечаются на удаление. В фазу копирования в новый фрейм копируются только живые компоненты, одновременно обновляются ссылки.То есть сразу исчезают проблемы с компактностью, поскольку все компоненты лежат линейно после копирования в новый фрейм, и с валидностью ссылок, поскольку перемещение компонентов происходит только между кадрами.
>>1361830>смутило выражение "персистентный мутабельный" Ну я не знаю как еще описать такую структуру, которая мутабельная, но при этом сохраняет состояния.
>>1360952> С (почти) иммутабельным стейтом все делается в одну фазу при копировании компонентов в новый фрейм. Внутри фрейма компоненты только добавляются, мертвые компоненты просто помечаются на удаление. В фазу копирования в новый фрейм копируются только живые компоненты, одновременно обновляются ссылки.Я понимаю, что с т.з. прямоты кода персональный GC это персональный ад, но все же после> все компоненты лежат линейно после копирования в новый фреймя думаю, что это прям deep копирование и жестокий memory pressure, это же не может работать быстро, не? а если там иммутабельность и ссылки, то какая к черту компактность?
>>1369945>я думаю, что это прям deep копирование и жестокий memory pressure, это же не может работать быстро, не? Copy on modify.
>>1370498хотел сказать copy on write? но анон же действительно хочет писать/компактить, а значит cow не имеет значения для вопроса
>>1370585Если под компактностью понимается: прям вот друг за дружкой в памяти, то это делается только для одного: избежать промахов кэша цп и хорошо работает только в случае DOD, что вообще не вяжется с какой ни было вменяемой предметно-ориентированной архитектурой.
>>1370718>что вообще не вяжется с каким ни было вменяемым геймдевом кроме соснульных эксклюзивов, где подобная анальная акробатика вынуждена в ввиду немощности соснулей. Поправил тебя. Если заглянуть в ванильные сорцы хоть уеча, хоть круйзиспихла, то никакого DOD ты там не найдешь. Алсо, дивитесь якой говнокод отвечал за топ графин несколько лет назад:https://github.com/CRYTEK/CRYENGINE/tree/release/Code
>>1370724Ну это вообще ПУШКА https://github.com/CRYTEK/CRYENGINE/tree/release/Code/GameSDK/GameDll/Turret/Turret
>>1370726Пиздец. Если опустить байтолюбство, то тут вот прямо говнокомбо как в тырпрайзном проекте на жабе с прошлой работы. И это вот каждый батяодобряе еба-шутан так написан?
>>1360815>Ну вот джвач как бы тоже "пользовательский софт". Куда тут андо-редо? Анон, не нужно таких сомнительных овергенерализаций.Двач - бесплатный серверный софт с сомнительной окупаемостью. Ундо-редо есть на уровне браузера, это спасает. Впрочем, я бы не отказался бы и от отката постов и тому подобного. Да что там, двач даже пост при закрытии вкладки не сохраняет, хотя trello это много лет как умеет. Но trello это бизнес, а двач хуйня из по коня.>Ну ты выше говорил о реплеях и подобной шняге. Для этого тебе все изменения состояния в игровой логике нужно прогонять через "создал - выкинул".Это не обязательно должно быть дорого. Изменения можно хранить в кольцевом буфере произвольной длины, вплоть до длины 2. То есть следующий кадр - функция от пользовательского инпута и предыдущего кадра. В итоге ты пишешьx[t] = x[t-1] + 1 вместо x = x + 1. Это не стоит практически нихуя. Нужны логи - увеличиваешь размер буфера.>>1360830>Это легко делается на крестах без всякой функциональщины.Да я против функциональных языков как явления. У опа был вопрос про "логика отдает некие структуры, описывающие действия, а внешний грязный интерпретатор их потом выполняет".Вот это охуенно, а функциональщину, которая даже мутабельные локальные переменные не признает, в пизду.
>>1370737>мутабельные локальные переменныеА нахуя они нужны? В результате TCO при компиляции всё немутабельное, до чего сможет доебаться оптимизатор, становится мутабельным.
>>1370774>А нахуя они нужныХранить промежуточный стейт>В результате TCO при компиляции всё немутабельное, до чего сможет доебаться оптимизатор, становится мутабельным. Вот то, что ты описал, точно нахуй не нужно. Если мне нужен цикл, я напишу цикл, а не буду делать хвосторекурсивную функцию, которая этот цикл эмулирует забив на какую-либо структурность программирования, и дальше надеяться на то, что оптимизатор что-то там соптимизирует. В этом ноль смысла.
>>1370782>хвосторекурсивную функциюНе обязательно только хвосто рекурсивную, TCO подразумевает несколько более широкий спектр задач.>забив на какую-либо структурность программированияРекурсия чаще выглядит понятной, нежели цикл.
>>1370737>В итоге ты пишешь x[t] = x[t-1] + 1 вместо x = x + 1>=Бля, анон, перечитай цепочку диалога внимательнее, пожалуйста, ты вообще мимо на тот гринтекст ответил.>Вот это охуенноТак это и есть чистый функциональный дизайн а-ля хаскель, привет.>функциональщину, которая даже мутабельные локальные переменные не признаетВообще-то признает, с добрым утром но они ненужны, кроме редких случаев оптимизации или написания какого-то хитровыебанного алгоритма, который проще с локальной мутабельностью с псевдокода в пейпере списать>>1370782>Если мне нужен цикл, я напишу циклТак тебе не нужен цикл.
Объясните нафане в архитектуре как сделать пиздато.Читаю всякие ништяки как люди делают движки на функциональщине, DataOrientedDesign и с ECS, сам пилил максимум демо-портянки, которые нормальным людям показывать нельзя.Реально ли мочь в дизайн и код одновременно или в одно ебало это нереально?
>>1370726Не, самая ПУШКА это вот: - ШЕФ, У НАС ПРОБЛЕМА, НАМ НУЖНО ПОРТИРОВАТЬ ДВИГ С ШИНДОШС НА ДРУГИЕ ПЛАТФОРМЫ, А У НАС РЕНДЕР ГВОЗДЯМИ ЗАХАРДКОЖЕН ПОД DirectX , НАМ ПИЗДЕЦ ШО ДЕЛАТЬ?-СПАКУХА, ПОТСОНЫ:https://github.com/CRYTEK/CRYENGINE/blob/release/Code/CryEngine/RenderDll/XRenderD3D9/DXGL/CryDXGL.cpphttps://github.com/CRYTEK/CRYENGINE/blob/release/Code/CryEngine/RenderDll/XRenderD3D9/Vulkan/D3DVKConversionUtility.hpphttps://github.com/CRYTEK/CRYENGINE/blob/release/Code/CryEngine/RenderDll/XRenderD3D9/Vulkan/CryVulkanWrappers/Resources/CCryVKShaderReflection.cpp
https://github.com/CRYTEK/CRYENGINE/blob/release/Code/CryEngine/CryPhysics/ropeentity.cppМощноhttps://www.pcgamer.com/crysis-3-performance-issues-caused-by-ropey-physics/Как бы неудевительно, что это писали СНГ-шные слесари
>>1370958Надо сказать код крайтек довольно аккуратный, за исключением мест, написанных блохастыми. В индустрии все было хуже и намного.https://github.com/JACoders/OpenJK/blob/master/code/game/wp_saber.cpp
>>1370961>Надо сказать код крайтек довольно аккуратный>https://github.com/CRYTEK/CRYENGINE/blob/release/Code/CryEngine/RenderDll/XRenderD3D9/
>>1370977Ну старые апи до вулкана и дх12 по причине их глобально-стейтовой природой действительно сложно абстрагировать красиво без прибивания гвоздями к коду.
