@eclairwolf yum yum 4.7 uF 50v spicy

@freeplay fox that try better than human that dont

@kasdeya using ecs as an example: it’s found a home in game development because it solves a non-trivial amount of game dev specific problems.

some common problems in game dev

• game objects can be expensive to create / destroy but games often require this very frequently
  • in non-ecs development, this is often solved with object pools – a collection of objects which are pulled from the pool, manipulated for whatever use its needed for, and then released back to the pool
• many game objects are variations of one another with just a few changes but many standard object-oriented patterns (inheritance) become fragile when applied and force a lot of redundant code
  • there are object-oriented patterns which are similar to ECS like what godot and unity do
• much of a game’s code runs 60+ times per second. it needs to be fast and organized such that only code which needs to run that often actually does, and it should be as done as cheaply as possible

enter ecs: component-based development allows for extremely modular design, data-oriented programming is focused on highly performant code, and entities being simple identifiers means that creating/destroying them is very cheap.

however, explaining this to say – a web dev, they may only understand this at a conceptual level if they’ve had little or no exposure to making applications like this. they may look at whats required to write ECS code and think to themselves, “couldnt we just solve this with observables / events / whatever other pattern we use frequently?” thats because these are the tools in their daily toolset and its how they solve their problems elegantly. they are very proficient with using these tools and will reach for them first.

to be clear: that web dev is not stupid. it is not a statement to their proficiency as a developer or anything else. its just that programming and computer science is both vast in breadth ( ) and depth and we have to specialize.

@kasdeya im of the school of thought that much of this is at the intersection of domain-specific needs and personal preference. it’s really difficult to explain this because, in order to explain it, one must recreate the original problem in its entirety and then layout the history of all the other things we’ve done to get to [current solution]. not to mention, we all think about problems differently – one approach may seem exceedingly simple to one individual and needlessly complex to another (looking at you, functional programming). this isn’t even including familiarity because of course, once you learn a toolset, you then begin to expand your understanding of all the ways a tool may be applied. within your chosen toolset, it may seem elegant and simple to solve it with X when the rest of the world is using Y. is X better than Y? maybe, but probably not. it’s more likely because Y isn’t in your typical toolset for some reason so reaching for it feels unnatural.

Roll 1d20 for every interrogation that's none of their fuckin business actually

Lie on every prompt that asks for your gender

@vivi lie on every prompt