Rio Manson-Hay

Programmer.

[Ryan Fleury @rfleury]

On the static vs. dynamic typing "debate".

First, static typing is more fundamental than dynamic typing. Different code must agree on some encoding in order to communicate about what is stored where. You can only implement a dynamically typed system on top of a statically typed system; in a sense, a dynamically typed system is just a system where all variables have the same static type, and that static type is sufficiently generic to express the desired space. In other words, static types are strictly more capable from a low level perspective. The set of low level possibilities of dynamic types is a subset of the set of those of static types.

Because general-purpose dynamic types are implemented with static types, special-purpose dynamic types can also be implemented with static types. This includes techniques like the "fat struct", or "mega struct", where one static type is used to span a larger space of concrete possibilities (consider entities in a game, as an example), at the expense of some "wasted" space (a misnomer, but for the purposes of this post, it'll do).

Special-purpose dynamic types can be vastly more performant than general-purpose; general-purpose dynamic types generally require a dynamic "object properties" system (see JavaScript, Python, etc.), whereas special-purpose dynamic types are confined to a limited system (see extra fields to cover a larger set of encoded information).

Paying the cost of general-purpose dynamic types everywhere is prohibitively expensive in a wide array of cases. And, again, special-purpose dynamic types often achieve the same ends, without many of the costs.

Therefore, for core building blocks of an ecosystem, it is an extremely poor design choice to enforce a general-purpose dynamic type as the core type which all code must use to communicate. It needs to be a strictly opt-in concept, so that you don't force everyone to pay for it.

[Rio Manson-Hay @Emerald_Slash]

@antoniosarosi Also this is kinda stupid, but I've seen in one language that using a linked list ended up being more efficient than using the built-in data structures when dealing with large n. It is what it is ¯\_(ツ)_/¯

[Rio Manson-Hay @Emerald_Slash]

@antoniosarosi Mid take. Yes, you should always start with arrays first. But, linked lists and other pointer-based structures can become useful optimizations once you understand the computational problem better. Bonus points if you allocate the nodes in an arena so you're not spamming allocs.

[Jonathan Blow @Jonathan_Blow]

I am working on a fun gameplay thing, that is small in the scheme of the whole game, but still pretty interesting. It involves syncing state between a level and the overworld.

I implemented most of it yesterday, then I realized, "hey, I need to guard against weird race conditions where you close the game while exiting the level but before loading into the overworld, maybe the overworld is already loaded and maybe it's not, maybe something weird happens where the campaign state file gets saved but the undo history for the overworld does not, ... ..."

The difference between a robust implementation, and a mostly-works-but-will-cause-lots-of-bugs-for-people version, is huge, in terms of how much you consider and how the solution is structured.

This is one example of many. Programming is *full* of this kind of stuff as soon as you are doing nontrivial programs.

People who are good-boy-dog enthusiastic about "vibe coding" have no idea about any of this. They think if stuff shows up on the screen, you have a mostly good program and just need to tweak it a little bit.

[Tyler Glaiel @TylerGlaiel]

@imnonplussed @Jonathan_Blow its also people not knowing how to fix bugs, "this thing is null, let me just add an if(not null) check before the code that crashed...." which is usually a bandaid that's just hiding whatever the actual problem is. but hey it "fixes it", so bug closed

[Rio Manson-Hay @Emerald_Slash]

@sleitnick This is why you should use coroutine.create()🙂

[Rio Manson-Hay @Emerald_Slash]

@sleitnick In the best case it's turns a full table clear from O(n^2) to strictly O(n).

[Rio Manson-Hay @Emerald_Slash]

@sleitnick It's also faster because fewer elements need to be shifted down on each removal (e.g. if you remove 10 elements iterating forwards, that's 10 extra elements that will be shifted every removal, whereas backwards it's always 0 extra).

[Rio Manson-Hay @Emerald_Slash]

@sleitnick Those are my thoughts anyway. I haven't investigated things super thoroughly, but because of all the uncertainties and limitations it has never seemed worth the effort to me ¯\_(ツ)_/¯

[Rio Manson-Hay @Emerald_Slash]

@sleitnick If the data you are working with is highly connected with other parts of the game, or uses a non-idiomatic-Luau data structure (like a linked list), then it can't be shared without repackaging..

[Rio Manson-Hay @Emerald_Slash]

@ArbuthnottKnox @rfleury Programmers like Ryan are an exception, in my opinion. Anyway, interesting discussion, thank you! Feel free to make another response, but be aware that I won't reply cause I must focus on other things now haha

[Rio Manson-Hay @Emerald_Slash]

@ArbuthnottKnox @rfleury But this is not inevitable: consider GPU shaders as an example of how "sum-type" kinds of problems can be solved without branching (e.g. rendering different shapes with different properties using the same shader). Alas, legacy APIs still influence the way programmers think.