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.

I think they use machine learning now.

> Modern elevators are strange and complex entities. The ancient electric winch and “maximum-capacity-eight-persons" jobs bear as much relation to a Sirius Cybernetics Corporation Happy Vertical People Transporter as a packet of mixed nuts does to the entire west wing of the Sirian State Mental Hospital.

> This is because they operate on the curious principle of “defocused temporal perception.” In other words they have the capacity to see dimly into the immediate future, which enables the elevator to be on the right floor to pick you up even before you knew you wanted it, thus eliminating all the tedious chatting, relaxing and making friends that people were previously forced to do while waiting for elevators.

> Not unnaturally, many elevators imbued with intelligence and precognition became terribly frustrated with the mindless business of going up and down, up and down, experimented briefly with the notion of going sideways, as a sort of existential protest, demanded participation in the decision-making process and finally took to squatting in basements sulking.

> An impoverished hitchhiker visiting any planets in the Sirius star system these days can pick up easy money working as a counselor for neurotic elevators.

The Hitchhiker's Guide to the Galaxy by Douglas Adams

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

so are you saying that, similar to the elevator programming challenge itself, writing the elevator programming challenge was more difficult than it looked?

cool. that probably put a bigger smile on my face than it should've, but still cool.

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

indeed it is. i think i'm especially bad at it, but a lot of people probably feel that way.

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?

I think this is all about trade off.

I do agree with your point 1,2,3, rule-based is better in some cases, but it's not as expressive, sometimes you have to express the logic in a non-straightforward way to satisfy your need, when the logic get complicated. We're trying to make the system flexible from the backend, and improve the usability at the UX level. For example, the constants inside the language will go to a separate section in the UI and will have various components of tuning them.

If the DSL code is organized well, it's going to look as clean as the rule based one.