mshang0

Yeah, but that can't be surprising. Software estimation is hard.

Elevators enable skyscrapers. As you build taller skyscrapers, more and more of the floor space is given over to elevators. There must be a huge incentive to improve elevator routing. I'd love to peek behind that curtain.

Totally agree. That's basically the challenge that I wanted to make, but I found that I bit off more than I could chew.

I had no idea that it was a common problem assigned to students, but it makes sense. Somebody on reddit also mentioned that Knuth also covers it.

This game is basically what I set out to make, not knowing it existed at the time.

The systems that I've seen of this nature have been rules-based, like this:

if A allow, else continue to next rule

if B deny, else continue to next rule

if C allow, else continue to next rule

deny all

For example, ufw rules have that form.

I see a few advantages compared to Boolean operators:

1. Easier to diff and version control.

2. Easier to build UI for, for example, to show which rule fails for a particular user.

3. Simpler to implement, no recursion in the DSL.

4. Arguably simpler to use.

5. Immediately obvious how short-circuiting works.

Why did you choose to go with Boolean operators rather than rules?