disillusionist

holy gorilla! i think QBasic Gorillas is the first graphics game i have memory of playing as a child. i remember attempting to read the code as a kid and being wildly confused by it. thanks for the brief trip down memory lane.

I've been using this pattern for the past couple years for the benefits the author mentions. In addition to that, it can help with overly complicated functions (which, ok, could probably be refactored) that have multiple optional arguments.

My company just finished a several week review period of Greptile. Devs were split over the usefulness of the tool (compared to our current solution, Cursor). While Greptile did occasionally offer better insights than Cursor, it also exhibited strange behavior such as entirely overwriting PR descriptions with its own text and occasionally arguing with itself in the comments. In the end we decided to NOT purchase Greptile as there were enough "not quite there" issues that made it more trouble than worthwhile. I am certain, though, that the Greptile team will resolve all those problems and I wish them the best of luck!

i can only speak to my personal experiences and not the entire "Job Market" but i have seen qualified, competent team members let go during "positive transformations" and expectations that their workload will be covered by others while corporate crows about how using AI will be such a force multiplier for those who remain.

To me, I see pushing rules boundaries as part and parcel with exploring fantastical worlds. Elves, dwarves, and dragons exist. Those aren't "real". Magic spells that allow you to fly and shoot fire from your finger-tips also exist but also aren't "real". If we're already breaking biology and meta-physics, why assume basic physics works exactly the same way either? For some, I think it is re-capturing the child-like attitude of wonder, excitement, adventure, and asking the question "what if?". This, of course, may be tempered by campaign tone; something that might happen in a DnD campaign but likely not in Call of Cthulu, Kids on Bikes, Monster of the Week, etc

If we were trying to create a real-time simulation system, then YES you are totally correct. However, many table-top RPGs rules only make sense in the context of adjudicating atomic actions (such as one creature passing an item to another) rather than multi-part or longer running activities. Readied actions are already a bug-a-boo that break down when pushed to extremes. While not listed in the rules, it might make sense for a DM to limit the distance or number of hand-offs that the "rail" can travel in a single round to something "reasonable" based on their own fiat.

I just Write Like That. It always takes me longer to write things than intended because I tend to overthink things, too. :/

I personally adore the Peasant Railgun and other such silly tropes generated by player creativity! Lateral problem solving can be one of the most fun parts of the DnD experience. However, these shenanigans often rely on overly convoluted or twisted ways of interpreting the rules that often don't pass muster of RAW (Rules As Written) and certainly not RAI (Rules As Intended) -- despite vociferous arguments by motivated players. Any DM who carefully scrutinizes these claims can usually find the seams where the joke unravels. The DnD authors also support DMs here when they say that DnD rules should not be interpreted as purely from a simulationist standpoint (whether physics, economy, or other) but exist to help the DM orchestrate and arbitrate combat and interactions.

In the case of the Peasant Railgun, here are a few threads that I would pull on: * The rules do not say that passed items retain their velocity when passed from creature to creature. The object would have the same velocity on the final "pass" as it did on the first one. * Throwing or firing a projectile does not count as it "falling". If an archer fires an arrow 100ft, the arrow does not gain 100ft of "falling damage".

Of course, if a DM does want to encourage and enable zany shenanigans then all the power to them!

because i'm likely going to refactor this function "tomorrow" with additional properties. :)

you can do this rather easily by returning an object rather than a primitive. if you're using a language like TypeScript, destructuring the resulting returned object is rather trivial and (in my opinion) delightful to read. eg

  function combineNames({ first, last }) {
    const fullName = `${first} ${last}`;
    return { fullName };
  }
  const { fullName } = combineNames({first: 'John', last: 'Doe' });

I started using this pattern years ago and haven't looked back. React components are defined using a single properties param and it feels natural to extend the practice to other methods and helper functions that I write.

One nice unexpected side effect is that I end up with more consistency in variable naming when using a param object in order to benefit from object definition shortcuts.

ie I will usually write something like

  const firstName = getFirstName(); doTheThing({ firstName });

  const fName = getFirstName(); doTheThing({ firstName: fName });