setr

The game simulation will get more detailed/granular as aesthetics dial down in perceived value. You can always go bigger/wider/more procedural/more multiplayer.

This is also why every hard problem eventually shows up — games are just simulation + interaction, and eventually everything that can be simulated will have some attempted implementation out there, struggling along. (For some reason, this does not appear to stop at “interesting” things to simulate — see all the literal simulators on steam)

I’ve been of the opinion that every hard problem in CS shows up somewhere in gamedev. It’s a great space for inspo.

Because what was once an active decision became a default, what was a default became an expectation, what was an expectation became an effective-requirement.

And lo, norms are made, the ratchet turns, culture solidifies, a new line written to the social contract. And tip-dependent workers have non-optional tipping.

If you really want a logic to follow strictly — any worker class whose wages are depressed by expected tipping should be tipped

The only correct syntax/format

    [
      , a
      , b
      , c
    ]

If only there existed a language designer intelligent enough to support it

I don’t think that matters that much; it’s still just a popularity contest, and if something manages to break through that threshold, it’ll be trivial enough to make the default.

No one knew Reddit boards and 4chan boards either; you just knew to go to /b/ or /r/funny. The other boards, the other fediverse servers, are just details that enable other subcommunities to survive. The major community will just route to a single server, and most will probably never use a second

One of the things I find most annoying about DBAs is they don’t understand just how utterly awful their tooling is. The error messages alone should be enough to throw a hissy fit, but as a group they’ve never dreamed of a life better than the misery of ERROR ON LINE 1: <entire query>

The aggressively common pipe-delimited sproc output (the standard hack to get around commas being common in strings, instead of finding a legitimate data format) is another clear example of the brain damage the poor DBA incurs through constant investment in “modern” relational databases.

The main value of regexes is expressing a fairly convoluted ask in a fairly concise form. While I’d expect LLMs to eventually generate regexes correctly, I’m not sure how you’re going to prompt the thing in a way that’s not harder than writing regexes directly.

Excluding the classic problems where you shouldn’t be using a regex in the first place (parsing email, names, html, etc) and the “draw the rest of the owl” where it simply solves everything from the input alone

Isn't a circular array implemented with a modula to begin with? I don’t see how you bypass it

I’m fairly positive the answer is trivially logical equivalence for pretty much any substring operation. I can’t imagine bitwise equivalence to ever be the “normal” use case, except to the implementer looking at it as a simpler/faster operation

I feel like if you’re looking for bitwise equivalence or similar, you should have to cast to some kind of byte array and access the corresponding operations accordingly

If you’re recording events as intent, then the event table is the source of truth and the state of the database is effectively snapshot of the state. In principle, you should be able to replay the events to produce the current state. If it calculates wrong, go fix your calculator, assume your events table isn’t wrong, and replay.

If you’re storing a log of database changes (what’s usually meant by an audit table), as in

(Table_Name, Column_Name, Old_Value, New_Value, Timestamp)

Then the database state is the source of truth, and the audit table is simply a record of changes ever occurred that reached that state.

In either case, there’s a single source of truth.

The original premise, from TFA, is

    Another is the Twitter-optimized “you’re a terrible engineer if you ever store booleans in a database” clever trick

That is, universal application. My point is: doing that, for the most part, will not the track the things you actually want, because bools are not the driving decision maker on value of tracking (and many things that need to be tracked will not be bools). It may accidentally capture useful tracking, but it’s more by accident than anything else. Thus, universal application is clearly wrong, and TFA is right to apply it conditionally.

You appear to agree on all of these points. I’m not arguing that, should you need to timetrack a bool, bool—>timestamp is a bad way to do it. As I’ve said, the universal application of it is only stated because it’s free to do. But being free doesn’t make it useful, and since you agree on that as well, I don’t know if there’s any argument actually occurring here.

> Including timestamps on rows (including created_at and updated_at) are real bacon savers when you've deployed a bug and corrupted some rows and need to eg refund orders created in a certain window.

But that’s my point. You’re making an active decision to record timestamps on important events (and no bool was being converted here); bool —> timestamp everywhere is not the same thing — the bool data type is not a useful signal for whether this change needs to be timestamp-tracked.

Either think and choose to track these particular changes or not, and drop in the appropriate tracking. The mindless Bool—>timestamp change is only ever suggested because it’s a “why not”, not because it’s a good practice that often leads to good things.

The audit table is of course just deciding “every change ever is important”

If you take the statement at face value — essentially storing booleans in the db ever is a bad smell - then he’s correct.

Although I’m not even sure it’s broadly a good principle, even in the on_at case; if you actually care about this kind of thing, you should be storing it properly in some kind of audit table. Switching bool to timestamp is more of a weird lazy hack that probably won’t be all that useful in practice because only a random subset of data is being tracked like that (Boolean data type definitely isn’t the deciding factor on whether it’s important enough to track update time on).

The main reason it’s even suggested is probably just that it’s “free” — you can smuggle the timestamp into your bool without an extra column — and it probably saved some effort accidentally; but not because it’s a broadly complete solution to the set of problems it tries to solve for

I’ve got the same suspicion with soft-deletes — I’m fairly positive it’s useless in practice, and is just a mentally lazy solution to avoid proper auditing. Like you definitely can’t just undelete it, and it doesn’t solve for update history, so all you’re really protecting against is accidental bulk delete caught immediately? Which is half the point of your backup

If ptr is some kind of global, then it makes sense for it not to be deallocated by the destructor? It’s apparently not really managed by this class, so why would its lifetime be tied to it?

I mean it’s psychotic to half-manage it like this but I don’t think the lack of a destructor is suspicious here; in fact I think it’s correct once the global pointer was introduced

The missile knows where it is because it knows where it is not…

https://youtu.be/bZe5J8SVCYQ?si=QrIlpJ6BuJADd_zF

I think the problem with this one is that LLMs are somehow both unreasonably effective as well as unreasonably ineffective. Letting the code editor llms do their suggestions, I’ve gotten a ton of useless boilerplate garbage suggestions, but periodically, a couple times of day, it suggests blocks of code that are far more complete, comprehensive and correct than it has any right to be.

Whether you’ll get the high IQ or low IQ LLM on the next suggestion is a crapshoot; how much consideration you give to either outcome (focus on the random instances of brilliance, or the constant stream of bullshit) drives the final perception.

I suppose that’s what cobol copybooks are; untagged unions, everywhere, all the time, all at once

This article seems perfectly valid? They aggregated all of the blades, and it’s ugly, and it Sweetwater never actually gets to processing (eg bankrupts), it’s effectively permanent.

Though I don’t see why sweetwater cant simply put up a fence and call it a day

the issue isn't the value of i, the issue is that i is still available after the loop ends. in most other languages, if it was instantiated by the for-each loop, it'd die with the for-each loop

> I mean, trees don't get eaten alive by bacteria.

Neither do I but I don’t think my natural antibacterial properties are sufficient for a hospital

The primary impetus is to enforce the constraint: a billing is either insured or uninsured. Insured has additional metadata X, Y, Z. Uninsured has additional metadata A,B,C. A billing cannot be both.

If you separate them into different insured and uninsured tables, then any tables associated with billing generally needs to be cascaded into an insured/uninsured variants as well. Billing_customer and billing_customer_details now becomes uninsured_billing_customer and insured_billing_customer and uninsured_billing_customer_details, etc.

As you add more data of this constraint, everything fragments again, scaling at 2^n tables. This is similar to the async coloring problem; what you wanted is to locally fragment the data model, but instead anything that touches it gets poisoned.

Ideally the DB would let you enforce the constraint UNIQUE(uninsured.billing_id, insured.billing_id) and split-table would suffice

I’m not seeing any top-level comments that resolve this —- other than ignoring the problem altogether (let the data model encode invalid states, handle it in app code), or switching to a different database.

Given that its India, I struggle to imagine any movement about 10mph

I mean this particular problem would be resolved if the database let you define/defend a UNIQUE constraint across tables. Then you could just do approach #2 without the psychotic check constraint.

If 95% of the data can be trivially modeled in a relational database, your recommendation is to switch databases or add a new system entirely?

Only the first strategy shoves it into the same table? The fundamental problem is record A can have type X Y or Z, with each type having additional metadata. You could flatten the model and have a table for each type X Y Z and query them independently, and pay the cost of duplicate schema structure and having to ensure they’re always synchronized manually (including any dependent tables), or you pluck out the common core and run into the article’s problem

You wouldn’t do what? Have polymorphic data to begin with? I don't see how you can choose to avoid the scenario that record A has one of several possible related metadata, other than just ignoring it and allowing invalid representations

I think the question is notable though — there’s having the challenge, and then there’s considering it as part of your identity. Personally I wouldn’t; my various issues are just things I’ve got going on, but I don’t think of myself in those terms. Maybe a cause for parts of my “identity”, but not actually a part of it

with enough people, and a sufficiently high view, all problems are about human-management. This is the case for any subject.

Management is not a product of university MBA programs and power-hungry corporate animals seeking to impose their will on others; it is an inevitably of group labour.

Found an example that you're correct: https://www.reddit.com/r/AnaMains/comments/14gsuot/whats_wit...

> You say "the state never happened on the server" but what does that even mean? You're not replicating look rotation with enough fidelity to know that and its not the job of the server to simulate "what actually happened."

The video in that post is what I was essentially talking about; the server tracks player A's attack-input, and player B's movements, and ignores the fact that the two don't at all line up. The final reconciliation of the event sequence is nonsensical -- player A is hitting player B in a manner which simply should not work. The violation of game rules / simulation state is occurring, it's just being accepted and ignored (and I don't know what, if any, verification the server is doing here, since actually doing the hit-registration check would reject this).

This is upsetting to me, but so be it.

Ok what happens in scenario

Player A fires at B at time 0

Player B moves at time 0, causing A to miss

Due to lag, player A receives B movement at time 3

So player A fired at a still target, and hit. Player B moved, and dodged. Rollback would apply to player A.

Does the hit register or no?

If player A receives the rollback, and now witnesses B dodge, but the hit registers anyways, then I don’t see how there can be a server validity check — from the perspective of the server, the state of the game in which A landed the hit never existed

My understanding of AAA fps games is they show the hit animation as a prediction, but it’s still up to the server whether the hit registers. Eg, if I lag in overwatch and everyone stands still, nothing I shoot lands (except by accident). When my inputs finally reach the server, reconciled and replayed on my machine, it turns out I was shooting at a wall.