Live data from Hacker News

Show HN: A simple Poker API to calculate the winning hand/s

pokerapi.dev

41–45 of 45 posts

Re: Show HN: A simple Poker API to calculate the winning hand/s

#41

Earlier quoted context omitted.

Would you do this in a different way now?

I wouldn’t do it in Objective C again, that’s for sure. But no, I think the class structure worked well for this. Just too many esoteric rules in these games. And it’s getting worse from what I hear of the high stakes games. Archey was just getting popular when I quit and now there is like a half dozen new games they play. It’s a constant arms race to see who can master a new set of rules to skin the fish with.

What challenges were from Obj-C, specifically?

Re: Show HN: A simple Poker API to calculate the winning hand/s

#42

Earlier quoted context omitted.

I wouldn’t do it in Objective C again, that’s for sure. But no, I think the class structure worked well for this. Just too many esoteric rules in these games. And it’s getting worse from what I hear of the high stakes games. Archey was just getting popular when I quit and now there is like a half dozen new games they play. It’s a constant arms race to see who can master a new set of rules to skin the fish with.

What challenges were from Obj-C, specifically?

It’s a pointer based language, ie its C. Swift makes it far easier to write correct code and not have to chase down wild pointer problems.

Re: Show HN: A simple Poker API to calculate the winning hand/s

#43
post #35

Earlier quoted context omitted.

I wouldn’t do it in Objective C again, that’s for sure. But no, I think the class structure worked well for this. Just too many esoteric rules in these games. And it’s getting worse from what I hear of the high stakes games. Archey was just getting popular when I quit and now there is like a half dozen new games they play. It’s a constant arms race to see who can master a new set of rules to skin the fish with.

As crazy as it sounds, this is why I'd try to keep it simple and just keep each implementation separate. Sure I'd save some keystrokes having a base abstraction and whatnot, but I feel like Poker is one of those "i'll make an interface" traps that is much more complex than it originally seems

The abstraction is pretty simple, and close to that. IIRC I had base Hand object that defines a comparison routine that takes a Hand object.

The Hand object has a method that returns Card objects by index with a high to low order so subclasses can do their comparisons in either 4 or 5 card games.

The you need like a best hand method, so games like Holdem that make best 5 card hands out of 7 cards work. Then a bunch of utility functions.

It’s also useful to have your Card objects have their comparison functions.

Re: Show HN: A simple Poker API to calculate the winning hand/s

#44

Reminds me of the 2+2 poker hand evaluator - they basically built an insanely fast giant lookup table that fit in ~100megs of ram IIRC. The main idea was to do monte-carlo simulations and give you your odds of winning at any point in the game by dealing random cards for the unknowns. Interesting read on that and other evaluators as well: http://web.archive.org/web/20130116102452/http://www.codingt...

With a fast evaluator you generally don't need to do Monte Carlo approximation - you can just brute force all combinations.

Re: Show HN: A simple Poker API to calculate the winning hand/s

#45

Earlier quoted context omitted.

What challenges were from Obj-C, specifically?

It’s a pointer based language, ie its C. Swift makes it far easier to write correct code and not have to chase down wild pointer problems.

Fair enough. My Obj-C experience was all years before Swift existed... mostly pre-ARC, even!
Post reply on HN