[doctorpangloss]

Game servers aren’t typical. Texas Hold’Em especially.

Like a chat application is also multi-user real-time. It’s obvious that when a chat participant disconnects you hold onto the messages to deliver to them for later. When you disconnect from a Texas Hold’em online and you were small blind, what should you do? Wait? Shift the blinds over? The next player in line gets big or small? Copy the leading product’s behavior? It’s hard to reproduce all the states in someone else’s live, production game.

It’s not at all obvious and this logic has to live somewhere. It touches a bajillion things, like the raw connection state, timers, transient and long-term persistent state. Your programming language isn’t going to make it simpler for you. It can’t just hide in your database’s conflict resolution or some AWS service.

This is a great Haskell demo because it shows that you can’t hide this code anywhere. It stares back at you with all its ugliness.

[shoo]

> This is a great Haskell demo because it shows that you can’t hide this code anywhere. It stares back at you with all its ugliness.

i enjoyed your comment and these last two lines in particular. different programmers might interpret these lines in completely different ways: one as a critique of haskell for not being able to tidy the details away to make the code appear simpler, another as praise of haskell for making these mechanics explicit.

[verttii]

Our ways to hide that logic has been building libraries that handle nearly all of it.

But since Haskell's ecosystem is small by comparison a lot of that logic leaks to your own application code. Especially when dealing with something like stateful websocket applications.

[twitchard]

A general-purpose library able to hide the necessarily specific logic of how network events and a poker game should interact seems... unlikely?

[verttii]

Sure, but the original argument was: > raw connection state, timers, transient and long-term persistent state

Much of this surely can be abstracted away to 3rd party libraries/frameworks. Haskell, even though a higher level language than most out there, lacks the ecosystem support for a lot of things that are handled by some library in lower level languages.

[dllthomas]

The point was that these things need to be handled unusually in the case of a poker server in particular. If that's true, then a general purpose library that's handling them invisibly is probably handling them wrong for this use case.