mshang0
Gfycat raises $10M to help creatives fire up the memes
Re:So You Think You Can Program an Elevator
on Tuesday January 12, 2016 @09:37PM (#10891998)
Yeah, but that can't be surprising. Software estimation is hard.
Re:So You Think You Can Program an Elevator
on Tuesday January 12, 2016 @07:03PM (#10891369)
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.
Re:So You Think You Can Program an Elevator
on Tuesday January 12, 2016 @07:00PM (#10891355)
Totally agree. That's basically the challenge that I wanted to make, but I found that I bit off more than I could chew.
Re:So You Think You Can Program an Elevator
on Tuesday January 12, 2016 @06:58PM (#10891350)
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.
Re:So You Think You Can Program an Elevator
on Tuesday January 12, 2016 @06:57PM (#10891340)
This game is basically what I set out to make, not knowing it existed at the time.
So You Think You Can Program an Elevator
Re:Flexible Feature Control at Instagram
on Thursday October 01, 2015 @04:29PM (#10314435)
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?