I'm writing a game that uses both behavior trees and coroutines (via C# generators), and I have found that they are not quite interchangeable.
The main thing is that the execution model is different. I think of the behavior tree as being evaluated from the root on every tick, whereas with coroutines, you are moving linearly through a sequence of steps, with interruptions. When you resume a coroutine, it picks up exactly where it left off. The program does not attempt to re-evaluate any preceding code in the coroutine in order to determine whether it's still the right thing to be executing. By contrast, a behavior tree will stop in the middle of a task if some logic higher up in the tree decides that you need to be on a different branch.
What we end up doing is composing behavior trees with coroutines as leaf nodes. It works quite nicely, although I wish there was a way to express the structure of the behavior tree in a more elegant way. We do the obvious thing: each node in the tree is some subclass of a Node base class, representing a logical operation like "if" or "do these in parallel".
I very much feel OP's angst about creating a pseudo-programming language-within-a-language by creating what are basically ad hoc AST nodes, but I haven't come up with a better solution. Maybe something like React, where you use basically imperative code to describe a structure, and there is some ambient state that gets properly reconciled by a runtime that you don't touch directly.
This is an old debate and yet one that is difficult to think through. I share your experience of having trouble convincing someone else not to combine things too hastily. Partly it's a "my gut feel is different to yours" situation, but I often don't have the confidence that I could articulate my reasoning without indulging in a wordy lecture on minutiae.
Lately I have been fixating on the following line of thinking: the unit of deduplication--usually a function, but sometimes even bigger--is the same thing as the unit of abstraction. When you dedupe, you've also given birth to a new abstraction, and those don't come for free. Now there's a new thing in the world that you had to give a name to, and that somebody else might come along and re-use as well, perhaps not in a context where you originally intended. The new thing is now bearing the load of different concerns, and without anyone intending it, it now connects those concerns. The cost of deduplication isn't just the work of the initial refactor; it's the risk that those future connections will break something or make your system harder to understand.
This reminds me of another famous Carmack pronouncement about the value of longer functions [1], which I think has some parallels here. In the same way we're taught to DRY up our code, we're taught to break up long functions. I sort of think of these two things as the same problem, because I view their costs as essentially the same: they risk proliferating new and imperfect abstractions where there weren't any before.
I can see how this could be a helpful reframing for some folks, but IME centering your attention on how to title yourself can have the reverse effect, which is to encourage you to indulge in an identity that doesn’t have much substance underneath.
I had a phase where me and my friends all thought of ourselves as writers and artists. At the extreme, there was a buddy of mine who would answer simple questions by prefacing with, “Well, as a writer, I tend to X.” And X would be many secondary tendencies you might associate with writers: look at the world differently; ask annoying questions at parties; overanalyze pop culture; drink too much caffeine; procrastinate; joke about procrastinating, etc.
The problem is that most of us didn’t do the only X that matters, which is to actually write. And I think we knew this on a subconscious level, and it was why we were so angsty all the time. (Being angsty is another X that writers are supposed to do, so it was a vicious cycle.)
Writers who don’t write seems like a niche phenomenon of a narrow and privileged set, but I feel like I see this elsewhere. I’m an engineer these days, and I occasionally come across junior folks who have a similar thing going on. Especially in bigger orgs, you can see people struggle for years with this: there’s something about the job they like (perhaps what the job seems to say about them as individuals), but they have a hard time with the actual moment-to-moment work. I generally think it’s not my place to judge people, let alone gatekeep or call people out on it, but I sometimes feel that I did those folks a disservice by not telling them: hey maybe this just isn’t for you.
There's some skepticism in the comments around the recommendation for xid. I'm curious if anyone here is using it in production at scale, and can comment on the practical realities.
I saw xid make the rounds about a year ago, and the promise of a pseudo-sortable 12-byte identifier that is "configuration free" struck me as a bit far-fetched.
In particular, I wondered if the xid scheme gives you enough entropy to be confident you wouldn't run into collisions. UUIDv4 doesn't eat a full 16 bytes of entropy for nothing. For example, if you look at the machine ID component of xid, it does some version of random assignment (either pulling the first three bytes from /etc/machine-id, or from a hash of the hostname). 3 bytes is 16777216 values, i.e., with 600 hosts you have a 1% chance of running into a collision. Probably too close for comfort?
There are settings where you can build some defense-in-depth against ID collisions, like a uniqueness constraint in your DB (effectively a centralized ticketing system). But there are many settings where that kind of thing wouldn't be practical. Off the top of my head, I'm thinking of monitoring-type applications like request or trace IDs.
No slight to anyone pursuing this strategy, but I also felt like using the shorter list for ranking candidate words was cheating. On the other hand, my solver ends up making silly suggestions that might be appropriate for early on in the game, but not for late guesses.
I've tried to think of what might be a good way of approximating a human's own sense of which words are viable Wordle answers. One thing I attempted was using a word frequency table to help bias the algorithm away from less common words. The funny thing is that some words rank low in word frequency but are otherwise count as "common knowledge". For example, "tapir" was a Wordle solution a few weeks ago, but it ranked lower than some obvious non-answers like "grovy". It could be that the frequency table I was using was weird, but I can believe that there are well-known words that aren't used that often. Maybe I could come up with a better corpus (e.g. only use the NYT or some other newspaper) to use as the basis for a custom frequency table. Seems like a lot of work!
+1, I'd also recommend doing a low-poly lesson before attempting the donut tutorial. I did Imphenzia's low-poly tutorials after a few false starts with the donut tutorial, and found the low-poly approach to be much better at establishing a foundation for working with geometric primitives.
This is my experience as well. I use both Chrome and Firefox across Mac and Windows, and I find the experiences to be pretty much interchangeable. I'm usually someone who gets annoyed at minor differences, but this really is one area where I'm not bothered at all.
I use Firefox most of the time, out of a desire to support Mozilla and promote a non-Google browser. Admittedly, this is a political motivation, but it comes at pretty much zero practical cost. If you are interested in trying out Firefox, I think the only significant inconvenience is disabling Pocket.
Like the parent, I'll occasionally switch to Chrome for separate profiles, or if I need something specific in DevTools. Chrome has much better multi-profile support, in the sense that it has it at all, but again, the differences between the two are so minor that I don't have any qualms switching back and forth.
I recently tried switching from an MBP to an X1 Carbon, in a yet another attempt to switch to Linux as my daily driver. I ended up being thwarted, to my surprise, by the touchpad support.
The big problem I encountered was poor palm detection: I learned through this process that I have a tendency to use the touchpad with my right hand, while my left hand is still in typing position. This means that the edge of my left palm rests along the upper-left corner of the touchpad. This would result in the driver sometimes detecting two touchpoints instead of one, and I would end up scrolling when I meant to move the pointer.
The result of this was pretty amazing to me: after a few hours of use I found that my wrists, shoulders, and neck hurt because I was subconsciously trying to adjust my hands to avoid this. After a couple of days trying different drivers and tweaking config files, I ended up conceding that it just wasn't there yet.
It's too bad: I have lots of imposter syndrome about understanding my OS and using Linux seems like a great cure. But after literally decades of trying, what I've noticed is that hardware (or at least, my acclimating to new hardware) always advances enough past Linux's capabilities that the switch is difficult. In the past, it was about getting sound cards or WiFi working, and nowadays it's about things like touchpads and high-resolution displays.
Question about the buffered writes and invalidation: is there anything that prevents race conditions between a Del() and a prior Set() on the same key? Just glancing at the source, it looks Set() ends up in a channel send, whereas Del() seems to synchronously update the internal map.
The main thing is that the execution model is different. I think of the behavior tree as being evaluated from the root on every tick, whereas with coroutines, you are moving linearly through a sequence of steps, with interruptions. When you resume a coroutine, it picks up exactly where it left off. The program does not attempt to re-evaluate any preceding code in the coroutine in order to determine whether it's still the right thing to be executing. By contrast, a behavior tree will stop in the middle of a task if some logic higher up in the tree decides that you need to be on a different branch.
What we end up doing is composing behavior trees with coroutines as leaf nodes. It works quite nicely, although I wish there was a way to express the structure of the behavior tree in a more elegant way. We do the obvious thing: each node in the tree is some subclass of a Node base class, representing a logical operation like "if" or "do these in parallel".
I very much feel OP's angst about creating a pseudo-programming language-within-a-language by creating what are basically ad hoc AST nodes, but I haven't come up with a better solution. Maybe something like React, where you use basically imperative code to describe a structure, and there is some ambient state that gets properly reconciled by a runtime that you don't touch directly.