jeremycw

It omits that the prisoners are deceased and uses the term "vanish" which implies it's not known where the organs have gone.

"Alabama prisoners' organs vanish, and there's a whole lot of passing the buck" could easily be "Deceased prisoners' organs taken by University of Alabama against families wishes" but that's not going to get the clicks.

The overhead of cgo seems like it would not be an issue if you could pass in an array of vectors and moved the outer loop into the procedure instead of calling the procedure for each vector. This may only be viable if there is a low overhead way to pass arrays back and forth between go and C. I'm no expert but a quick google makes me think this is possible.

I get that hand rolling assembly is fun but as a theoretical future maintainer I would much prefer C to ASM.

I am not a lawyer and please correct me if I'm wrong but as I understand it rules and mechanics are not copyrightable. What is copyrightable is the flavor text and specific compilation of the rule set into the "Rule Book". The rule book becomes a copyrightable work. This means that your are within your legal right to make a game called "Dragons & Daggers" where all the combat mechanics, rules, etc are identical to Dungeons & Dragons as long as the "glue" text and flavour text is original content. It seems to me like a community fork licensed under CC that plays exactly the same is not impossible.

I think you need to be a bit more humble on a topic that's clearly going over your head.

Imagine a scenario where you are testing out a brand new RISC-V development board. The vendor has only provided a C compiler for this board as is often the case. You want to be able to use the zig language to write programs for your new development board but no zig compiler exists for this board yet. That means you need to compile the zig compiler from source. The latest version of the zig compiler is written in zig. Again you don't have a zig compiler so how will you compile the zig compiler from source? You need a way to go from C compiler to Zig compiler. That's what this is describing. It does not make sense to maintain two completely separate versions of the compiler. The "real" one written in Zig and the "bootstrap" one for compiling from C. So the zig source is compiled into WASM and stored in the repo. On a system with only a C compiler this WASM can be ran instead of a native zig binary. The WASM version can then be used to compile an actual native zig binary.

I've seen a few large Rails codebases that included a state machine library like mentioned in the article. Every single one was worse because of it. It pushes the code down a path where hidden hooks run when magic methods are called. At this point in my career I'm just done with that type of "clever" code.

The article starts with examples that just define the state machine by hand. This is a much better approach and scales to larger code much better. You can grep "def start!" and just read what the method does. A state machine DSL is really not providing much value and eventually just gets in the way.

The problem with these types of gems is that they're good for refactoring functional style code that takes an input and produces a result and has "few side effects" as they mention, but this is generally not the type of code you find in an old legacy rails application that you want to refactor. The whole thing that makes these refactors tricky is that they can just write to the db anywhere in a non obvious way.

If you naively go about refactoring something like:

POST /users

Thinking all you need to do is match the output of the current request and match the record it makes in the users table you're potentially missing a ton of side effects you didn't even know about.The problem has always been the side effects and until one of these gems can track and compare side effects in an intelligent way I don't see how they are that useful.

Sometimes I find it a little depressing that (at least through my laymen eyes) we are nearing a technological plateau and that more research into physics is unlikely to get us to a world describe in traditional science fiction with FTL drives and large metal spaceships that can take you from planet to planet.

Then something like this reminds me that if we as a species were able to unlock the secrets of bio-chemistry (not sure if that's the right term) it would be a game changer unlike any seen so far. And the fact that there is a huge corpus of evidence out there in the world called "life" proving some of the possibilities already gives me hope that while we may never have FTL, the future could still be pretty wild.

You're right, when I mentioned "taxonomy, abstraction and world-modeling" I meant as it pertains to code organization in the tradition OOP/OOD sense where it's generally about naming classes, creating inheritance hierarchies, etc. Data-oriented design is _absolutely_ concerned with the data schema. I would, however, disagree that the focus should be on "building the world" with your schema. To me this means creating the schema based off of some gut/fuzzy feeling you get when the names of things all end up being real world nouns. To me creating a good schema is less about world building than it is about having the exact data that you need, well normalized and in a format that works well with the algorithm you want to apply to it.

> Doesn't the former enable the latter?

Not necessarily. ECS is a local maxima when developing a general purpose game engine. Since it's general purpose it can do nothing more than provide a lowest common denominator interface that can be used to make any game. If you are building a game from scratch why would you limit yourself to a lowest common denominator interface when there's no need? Just write the exact concrete code that needs to be there to solve the problem.

> Our job as engineers is to make software that functions according to some set of desires, and those desires may directly conflict with approaching an optimal transform.

All runtime desires of the software must be encoded in the transform. So no software functionality should get in the way of approaching the optimal transform. What does get in the way of approaching the optimal transform is code organization, architecture and abstraction that is non-essential to performing the transform.

I think the focus on ECS when talking about data-oriented design largely misses the point of what data-oriented design is all about. Focusing on a _code_ design pattern is the antithesis of _data_-oriented design. Data-oriented is about breaking away from the obsession with taxonomy, abstraction and world-modeling and moving towards the understanding that all software problems are data transformation problems.

It's that all games essentially (and most software in general) boil down to: transform(input, current_state) -> output, new_state

Then, for some finite set of platforms and hardware there will be an optimal transform to accomplish this and it is our job as engineers to make "the code" approach this optimal transform.