Programming thread

[SchizoDaemon]

not a gamedev but from what i've seen 'entity component system' is mostly just another way to describe doing OOP, no?
like, instead of 'objects' you call your things 'entities' and maybe you don't do the big deep inheritance hierarchies and polymorphism as much as OOP textbooks tell you to, but at the end of the day you still work with class based things that have data members and member functions (or fields and methods or however you want to call it)

Not quite.

I haven't looked at this for a while; my understanding is that you associated the components with the entity, which is just a reference/identifier.
The component can be just structs holding data. A struct is a known size, which means it helps with data locality, and thus you get a performance benefit because there aren't any cache misses.

 

[Anti Snigger]

not a gamedev but from what i've seen 'entity component system' is mostly just another way to describe doing OOP, no?
like, instead of 'objects' you call your things 'entities' and maybe you don't do the big deep inheritance hierarchies and polymorphism as much as OOP textbooks tell you to, but at the end of the day you still work with class based things that have data members and member functions (or fields and methods or however you want to call it)

also i think that dynamic typing SUCKS

It's more like SoA than AoS if that makes sense, instead of a pointer/reference/value for a field, it's an index into a pool of the component.
It's really nice because you get the advantages of uniform striding, (assuming no variable length data), which makes a lot of code easier to write

 

[CrunkLord420]

Opus is killing it on CyberChud. Performance optimizations, aesthetic palettization techniques, headless benchmarking, mipmapping, bug fixes and more. I've only encountered a genuine regression when using Sonnet. At worst Opus does things in a way that mildly offends my strict memory management ideology, but would be considered normal and perfectly fine in any other codebase. To save tokens on my basic 'Pro' plan I just clear context and one-shot entire projects. No planning phase. It implemented mipmapping in a single prompt, and I see nothing wrong the code.

Maybe LLMs work really well on codebases where everything is immediately accessible and nothing is a black-box or API call.

It's more like SoA than AoS if that makes sense, instead of a pointer/reference/value for a field, it's an index into a pool of the component.
It's really nice because you get the advantages of uniform striding, (assuming no variable length data), which makes a lot of code easier to write

You can take a look at my SoA ECS in the CyberChud Engine: https://gitgud.io/CrunkLord420/cyberchud/-/blob/master/src/ecs.h?ref_type=heads#L284

 

[polyester]

What does it have to do with dynamic typing, which the book explains like so

It has nothing to do with dynamic typing, the author is being inaccurate/retarded.

I wouldn't say "has nothing to do with".

• dynamic typing = the types of variables/parameters/expressions aren't fixed (and thus not validated) at compile time
• dynamic object model = the structure of user-defined types (classes/structs) isn't fixed (and thus not validated) at compile time

So they're similar concepts. A dynamic object model (at the language-level) only makes sense with dynamic typing, I think - so you could view it as a extension of dynamic typing, that seems to be common among dynamic languages.

I also feel like the concept of static-vs-dynamic typing is a bit blurry, anyway. Like if your code passes around lots of values as `object` in C# / `Object` in Java / etc., then is that really still fully statically-typed code?

 

[analrapist]

Maybe LLMs work really well on codebases where everything is immediately accessible and nothing is a black-box or API call.

Thank you for sharing positive experiences. There's a lot of FUD out there right now. I've had similar experiences, but I've been doing LLM-assisted dev work for a couple years now, as even early versions helped paper over some of my weaknesses as a developer. (Biggest is that schooling drilled me to think about programs as a logician, which had a huge negative impact on my "velocity"; LLM inference papers it all over with generic code that I can adapt quickly.) But IT work provides much less revenue for me than other things at the moment, so I'm not a pro any more.

 

[306h4Ge5eJUJ]

I wouldn't say "has nothing to do with".

• dynamic typing = the types of variables/parameters/expressions aren't fixed (and thus not validated) at compile time
• dynamic object model = the structure of user-defined types (classes/structs) isn't fixed (and thus not validated) at compile time

So they're similar concepts. A dynamic object model (at the language-level) only makes sense with dynamic typing, I think - so you could view it as a extension of dynamic typing, that seems to be common among dynamic languages.

Thematically related maybe, but you can have the two in any combination: dynamic typing + dynamic objects (Python, JS, Lua), dynamic typing + static objects (Common Lisp), static typing + static objects (C, Java, ...) and static typing + dynamic objects. I don't know why you'd want the last one, but you could specify certain attributes on an object together with their type while treating other attributes as having some fixed type like string. I could see that happen in a weird DSL.

I also feel like the concept of static-vs-dynamic typing is a bit blurry, anyway. Like if your code passes around lots of values as `object` in C# / `Object` in Java / etc., then is that really still fully statically-typed code?

It's certainly blurry. A dynamically typed language is technically a statically typed language where every variable has the top type ("object", usually), which is why some people propose calling them unityped instead. Never really took off though, I think.

 

[Anti Snigger]

You can take a look at my SoA ECS in the CyberChud Engine: https://gitgud.io/CrunkLord420/cyberchud/-/blob/master/src/ecs.h?ref_type=heads#L284

What I love about the 'binding a table' pattern is that it completely decouples the semantics of where the memory comes from from the object itself
In my personal project, for every type with attached memory, I define a "bind_buffers" and "detach_buffers" function, and it composes super well.
I use exclusively system pages for memory, but were I to go insane and use malloc, I could very easily

Scalarcucks stay malding, SoA chads stay based

 

[Marvin]

I recently learned that postgres coerces boolean values to strings and numbers and all kinds of bullshit.

Like I'm doing this project in a dynamically typed language, which is fine. I know that for my purposes, I'll need to deliberately impose types on values from untrusted sources (and parts of my code in general).

But still, I expected that when I pass a value to be inserted into a table with typed fields, that it should throw some sort of error when I try to insert the wrong type. Not just silently insert something that sorta looks correct if you squint at it.

 

[SchizoDaemon]

I recently learned that postgres coerces boolean values to strings and numbers and all kinds of bullshit.

Like I'm doing this project in a dynamically typed language, which is fine. I know that for my purposes, I'll need to deliberately impose types on values from untrusted sources (and parts of my code in general).

But still, I expected that when I pass a value to be inserted into a table with typed fields, that it should throw some sort of error when I try to insert the wrong type. Not just silently insert something that sorta looks correct if you squint at it.

I've been caught by this before. JavaScript is the worst for doing this, of course.