Rio Manson-Hay retweeted
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.
One of the longest running schisms in programming is that of static vs dynamic typing. I've heard a million arguments from both sides throughout my entire career, but seen very few of them ever convinced anyone of anything. As rationalizations masquerading as reason rarely do in matters of faith. The rider will always justify the way of the elephant. That's not to say there aren't people who've switched camps. In fact, such individuals usually shout the loudest rationalizations of all. Often with the charm of a livelong omnivore suddenly turning vegan or a traditional banker who caught a lucky ride on crypto. The shorter the faith, the brighter the flame. Personally, I'm unashamedly a dynamic typing kind of guy. That's why I love Ruby so very much. It takes full advantage of dynamic typing to allow the poetic syntax that results in such beautiful code. To me, Ruby with explicit, static typing would be like a salad with a scoop of ice cream. They just don't go together. I'll also confess to having embraced the evangelical position for dynamic typing in the past. To the point of suffering from a One True Proposition affliction. Seeing the lack of enthusiasm for dynamic typing as a reflection of missing education, experience, or perhaps even competence. Oh what folly. Like trying to convince an introvert that they'd really like parties if they'd just loosen up a bit. That actually it's really fun to be in crowded rooms, for hours on end, shouting to communicate, because how about that VIBE! These days, I've come to appreciate the magnificence of multiplicity. Programming would be an awful endeavor if we were all confined to the same paradigm. Human nature is much too varied to accept such constraint on its creativity. Could you imagine if all visual art had to be rendered in the style of cubism? Or realism? Or all novels written in the short, direct flavor of Hemmingway? What a bore it would all quickly be! It would ruin the magic of programming. This unique fusion of art and engineering. But it took a while for me to come to these conclusions. I'm a recovering solutionist. So when I see folks cross their heart in disbelief that anyone, anywhere might fancy JavaScript over TypeScript, I smile, and I remember the days when I'd recognize their zeal in the mirror. That's not to say all matters of programming approaches boil down to equal but different mindsets. There are limits to this relativism. But dynamic vs static typing is certain within its confines. So too is functional vs object-oriented programming. Poles on both these axes have shown to deliver excellent software over the decades (and awful stuff too!). Now people are blessed with a capacity to express themselves equally well from either end. Such ambidextrous nature seems rare, though, as evidenced by the utter disbelief so frequently expressed by either side that the other might hold a reasonable position. I am not ambidextrous. I do not enjoy static typing, and objects animate my mind's eye. But I have come to appreciate the fact that others illuminate their creativity with just as much intensity as I do mine, using functional programming constraints and explicitly spelled out types. As long as I never have to soil my Ruby with type hints or write all front-end code in TypeScript, I can so happily coexist with those who adore Go or can't stand JavaScript. Vive la différence!
38
14
547
56,790
Rio Manson-Hay retweeted
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.
43
71
1,412
70,220
Rio Manson-Hay retweeted
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
1
1
15
1,518