Pokersource Poker-Eval, the open-source poker hand evaluation library, takes a lot of flack for being “low-level”. In The Great Poker Hand Evaluator Roundup, I wrote:
The Poker-Eval library is implemented in highly optimized, heavily macro’d C for unadulterated speed, but language mappings for .NET, Java, and Python are provided. Now, I’ll be honest. The first time I saw the poker-eval source code, I immediately unlearned about sixty-two months of best-practices software development…
That statement was a little tongue-in-cheek, but still: it seems like every time someone suggests Pokersource Poker-Eval, a disclaimer immediately follows:
Don’t use this library unless you’re a competent C programmer! Danger, Will Robinson!
Just the other day, for example, I was looking at poker-related questions on Stack Overflow when I came across this: How Do I Programatically Calculate Poker Odds?
Hello, I’m trying to write a simple game/utility to calculate poker odds. I know there’s plenty of resources that talk about the formulas to do so, but I guess I’m having trouble translating that to code. Particularly, I’m interested in Texas Hold-em …
I understand that there are several different approaches, one being that you can calculate the odds that you will draw some hand based on the cards you can see. The other approach is calculating the odds that you will win a certain hand. The second approach seems much more complex as you’d have to enter more data (how many players, etc.)
I’m not asking that you write it for me, but some nudges in the right direction would help
One of the answers suggested using Pokersource:
Take a look at pokersource if you have reasonably strong C abilities. It’s not simple, I’m afraid, but some of the things you’re looking for are complex. The poker-eval program that uses the library will probably do much of what you want if you can get the input format correct (not easy either). Sites such as this one or this also use this library AFAIK.
Still, it could be worse, you could be wanting to calculate something tricky like Omaha Hi-lo…
Again with the disclaimer! And it occurred to me: you know what? All this FUD is really kind of bogus. As of this writing, Pokersource is still the best and most complete library of publically available poker-related code in the world. Period. What’s more: the Pokersource evaluator is extremely easy to use provided you understand the Pokersource way of doing things.
So I thought, why not put together a brief Pokersource Poker-Eval primer?
The dash is probably the single most abused piece of punctuation in the English language. No, I mean it.
Dash abuse. It’s a serious crime, with serious consequences. I’m guilty of it; you might be guilty of it. We spend years—lifetimes—figuring out when to use commas, colons, and semicolons. We learn to do nonsensical things like putting the comma inside the quotations because, well, that’s the way it’s done.
We spend a lot of time and energy getting grammar and punctuation right. But when we need a dash (whether of the em or en variety), a hyphen, or even a minus sign, eh. We just mash the one-size-fits-all “dash/hyphen/minus/whatever” button next to the zero key.
We might even get crazy and press it two or three times — like this — and we might squirt in a couple of spaces on either side, just to make it clear that we mean business. It’s what you could call a descriptivist, anything-goes approach to punctuation, and it means there are about a dozen ways to represent the following Einstein quote:
Have you ever flipped a coin as a way of deciding something with another person? The answer is probably yes. And you probably did so assuming you were getting a fair deal, because, as everybody knows, a coin is equally likely to show heads or tails after a single flip—unless it’s been shaved or weighted or has a week-old smear of coffee on its underbelly.
So when your friend places a coin on his thumb and says “call it in the air”, you realize that it doesn’t really matter whether you pick heads or tails. Every person has a preference, of course—heads or tails might feel “luckier” to you—but logically the chances are equal.
Or are they?
This is your HTML markup:
This is your HTML markup on drugs ASP.NET:
ASP.NET offers a lot of horsepower, especially in its most recent incarnation. I give you jQuery, AJAX, Dynamic Data, control adapters, and more.
We could almost call clean markup the sacrificial lamb of ASP.NET WebForms development. It’s what you give up in order to achieve the illusion of state in the stateless medium known as the World Wide Web. If you develop in ASP.NET, then you’ve probably spent a lot of time chasing your tail as I have, ferreting out how to clean up ASP.NET-generated markup to make it palatable:
- Reduce or removing VIEWSTATE and other hidden fields
- Use control adapters to tweak generated markup of server controls
- Create customized HtmlTextWriters and hook them in to your page classes
- Override Page.Render and accomplish all kinds of mischief
- Apply regular expression replaces to your finished page output
But the problem with these hacks techniques is that they attack the symptoms, rather than the cause.
Dense, encrusted markup is the natural result of trying to graft a desktop application development paradigm (with events and easily recallable state and so forth) onto an inherently stateless, request-response medium: the World Wide Web. This is what ASP.NET tries to do, and that it succeeds at all (and it does succeed) is a testament to the ingenuity of the ASP.NET development team.
Still: the generated markup is ugly and loaded with boilerplate. There can be no arguing with this, although for many line-of-business applications, the cleanliness of your markup may not matter (although in some worst-case scenarios, unbridled viewstate has been known to grow to a few megabytes in size).
But if you’re a stickler, a purist, or if you’re building something that needs to be lean and mean, a typical ASP.NET WebForms application just doesn’t give you the fine-grained control over your own markup that you’ll want—at least, not without a lot of extra work.
Enter ASP.NET MVC
You’ve probably heard about ASP.NET MVC by now (the official beta was released just a few days ago but the previews have been around for months) so I’ll refrain from ranting about the architectural benefits of MVC versus the tightly-coupled ASP.NET “desktop” paradigm of yore and just point out that markup generated by ASP.NET MVC is an order of magnitude cleaner than what you’ll get under classic ASP.NET:
The above is actual markup generated by an ASP.NET MVC website I threw together last weekend. It’s still ASP.NET—ASP.NET is now a superset which includes both the WebForms and the MVC paradigm within it—it’s just not ASP.NET WebForms.
And it’s clean. It’s tight. It can be applied from the ground up, or grafted into an existing ASP.NET WebForms application. It’s works with AJAX. You can still use server controls. You still have a design surface. Master pages. User controls. All that stuff still applies, if you want it. In the words of Scott Hanselman:
I like to think of ASP.NET MVC as the raw, acoustic version of the more heavily produced and multi-layered ASP.NET WebForms we use today.
To me, ASP.NET MVC is one of the best and most forward-looking technologies to come out of Redmond in years. While it’s not an out-and-out replacement for ASP.NET WebForms, If you’re building web applications on the Windows stack, going forward you may need a very good reason to prefer WebForms to MVC.