[w0utert]

So, I know literally nothing about Haskell, and I would rate my knowledge of functional programming theory as 'beginner' at best, but I still get baffled every time when reading Haskell code that implements anything other than something trivial like a fibonacci sequence. The poker server code looks extremely tidy and well engineered, so that can't be the problem, but to me it's utterly incomprehensible. It seems like every expression implements 20 different things at the same time, which makes it really hard to decode what is going on.

Is it just me, or is this typical for all non-trivial Haskell code? I don't have any problems interpreting e.g. Clojure, or Javascript written in a functional style for that matter, but Haskell...

[whateveracct]

The nice thing about Haskell from a readability standpoint is to unpack what code does at any point, you only have to perform substitution (i.e. beta reduction) over and over. This is a key difference from most other programming languages, which require you to have a little VM in your head. "Localized reasoning" is what Haskellers call this.

To read it quickly, you do have to learn & internalize abstractions. Both a common set of them (the usual type classes) & abstractions custom-built in your project. Abstractions in Haskell tend to be true abstractions & not encapsulations. You don't necessarily need to know the internals to understand the abstraction. I've seen this put off systems programmers before (people used to writing C etc and understanding the assembly).

I wouldn't expect someone with no Haskell knowledge to understand Haskell code. I've seen higher-level people (e.g. VPE-level) get upset by this and knee-jerk decide Haskell is problematic. I'm of the opinion that such knee-jerks aren't worth listening to..I don't care about opinions of people who haven't met (or honestly tried to meet) the prerequisites.

Regardless, I will say as someone who has learned Haskell: Once you learn it, it becomes so stupid easy to do everything. I feel like I can solve more complex problems faster & better in Haskell than other programming languages I have comparable (or more!) experience in.

[verttii]

You mean that decomposing abstractions with substitution works better in Haskell than in a lot of the other languages because programs in Haskell are essentially (pure) functions and abstractions are built by composing functions?

[whateveracct]

Yeah - referential transparency is what allows it to Just Be Substitution.

[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.

[daenz]

Haskell is dense. I'm picking it up now[0], so this project was very useful for me to see how some "real world" Haskell is written. But yes, take for example this function

  getSocketAPIPort :: Int -> IO Int
  getSocketAPIPort defaultPort = do
    maybeEnvPort <- lookupEnv "socketPort"
    case maybeEnvPort of
      Nothing   -> return defaultPort
      Just port -> maybe (return defaultPort) return (readMaybe port)

It gets a port from an environment variable, if it can, otherwise a default port. Conceptually, this is easy to understand, but translating your understanding of that process to Haskell is not 1 to 1. For example, the last line alone:

  Just port -> maybe (return defaultPort) return (readMaybe port)

You have to understand Maybe (and failure contexts), you have to understand that "return" does not return from a function like typical imperative languages, instead it wraps a type in a Monad (in this case, the IO Monad), and you also have to understand that most of those things on that line, including the "return" function, are parameters to the "maybe" function.

There's a lot to understand in terms of the underlying machinery of Haskell to be able to read its cryptic flow and syntax. But it is worth it imo.

0. http://learnyouahaskell.com

[chowells]

Ouch. That function is actually written in a pretty convoluted and redundant way.

    getSocketAPIPort :: Int -> IO Int
    getSocketAPIPort defaultPort = do
        maybeEnvPort <- lookupEnv "socketPort"
        return . fromMaybe defaultPort $ maybeEnvPort >>= readMaybe

That's starting to border on over-terse, so you could expand the bind operator into do notation if you wanted to spread it out a bit further. On the other hand, it's also starting to feel over-verbose, using do notation for only a single IO action. Maybe...

    getSocketAPIPort :: Int -> IO Int
    getSocketAPIPort defaultPort = fromMaybe defaultPort . (readMaybe =<<) <$> lookupEnv "socketPort"

That might be going too far. But maybe it's what I'd write. Just depends on how much I expect to make this more complicated in the future. This form has the simplest flow to read. I mean... it's dense. Really dense. But it has the fewest total things going on, and it neatly divides into three interesting parts, easily understood in isolation, plumbed together with two common combinators. But it's also pretty rigid in structure. If you ever want to add other sources for finding the port or change the priorities of them, that form would need to be totally rewritten, and probably would end up back in do notation.

But in every case, all the various return calls should be combined into one (or none, if you use fmap or <$>), and the fallback to the default should only be written once.

[danidiaz]

In your first version, I think I would use =<< to keep "flow" of information right-to-left. I also use parentheses instead of . and $ when there isn't a lot of nesting, I got that habit from this post about writing legible Haskell http://www.haskellforall.com/2015/09/how-to-make-your-haskel...

    getSocketAPIPort :: Int -> IO Int
    getSocketAPIPort defaultPort = do
        maybeEnvPort <- lookupEnv "socketPort"
        return (fromMaybe defaultPort (readMaybe =<< maybeEnvPort))

Keeping the pattern match instead of using "fromMaybe" wouldn't be a bad idea, either:

    getSocketAPIPort :: Int -> IO Int
    getSocketAPIPort defaultPort = do
        maybeEnvPort <- lookupEnv "socketPort"
        return (case readMaybe =<< maybeEnvPort of
            Nothing   -> defaultPort
            Just port -> port)

It makes the default value stand out a bit more.

[nilkn]

I've written a fair bit of Haskell, including some production software. Your second version here is my personal favorite of the variants proposed so far. It's the version I can look at and more or less instantly understand. I think sometimes folks go a little too far with using library functions to manipulate Maybe values -- not that `fromMaybe` is particularly onerous, but something about the structure of pattern matching just conveys information to my brain much faster.

[dllthomas]

For my part, for that logic I'd consider MaybeT. I don't like that a malformed environment variable gets the same treatment as a missing environment variable, though.

[daenz]

I feel like I'm in a unique place of learning Haskell, so I'll try to translate the last line of your first function:

  return . fromMaybe defaultPort $ maybeEnvPort >>= readMaybe

Basically this is composing a function out of "return" and "fromMaybe" (using the composition operator "."), then partially applying defaultPort to that composed function, so you now have a function that takes one argument. The resulting function is then applied (using $) to the result of "maybeEnvPort >>= readMaybe".

In "maybeEnvPort >>= readMaybe", ">>=" is an infix function that takes maybeEnvPort as its first argument (which is a Maybe Monad), "unpacks" it, applies "readMaybe" to the unpacked result. readMaybe returns another Maybe Monad.

The result of everything after the $ is a Maybe Monad that contains the port from the environment, or a failure condition. The result of applying the composed-and-partially-applied function (from before the $) to it is that the port from the environment is chosen if it didn't fail, otherwise the defaultPort is used, and then the whole thing is wrapped in an IO Monad.

[chowells]

The only place I would offer a correction is to say that values aren't monads. "Maybe Monads" and "IO Monads" aren't getting created or passed around because only values exist at runtime.

The only thing that can be a Monad is a type. You could say you have a value of a monadic type, I suppose...

But that gets into something I've learned over time answering beginner questions. Call things types or values. "a Maybe value" (this is a little sloppy, but perfectly fine in conversation) or "the IO type". Don't call types with a Monad instance "Monads" except in the case when you are talking about all of them generically. "The IO Monad" is an incredibly self-limiting and distracting way to think about the IO type. There's nothing inherently interesting about being a Monad. Why not call it "the IO Functor" or "the IO Alternative" or even "the IO MonadRandom"? Those are all instances the type has. None are particularly more important than the rest. Sometimes what you want to do is most easily done via a type class other than Monad. Don't tie yourself so much to a single detail. This is actually really important, because our habits shape our intellectual exploration. When you find a habit that shoehorns you into one direction, it's a good idea to try to weaken it.

[platz]

i like it, for some reason my brain dislikes switching from left/right a lot, so that's why i often avoid the $ operator, so instead I'd write:

    return . fromMaybe defaultPort (maybeEnvPort >>= readMaybe)

[dllthomas]

"Have the data flow in one direction" is a good rule of thumb in writing clear Haskell code.

That said, your conversion away from $ changes the meaning here (in a way that doesn't typecheck, I think - remember that regular function application binds tightest whereas dollar binds loosest) and you still don't achieve your goal.

Instead, maybe

   return . fromMaybe defaultPort $ readMaybe =<< maybeEnvPort

or even

   return $ fromMaybe defaultPort $ readMaybe =<< maybeEnvPort

If you still don't like the dollar signs, we can parenthesize instead in two correct ways, although I don't find them more readable:

    (return . fromMaybe defaultPort) (readMaybe =<< maybeEnvPort)

    return (fromMaybe defaultPort (readMaybe =<< maybeEnvPort))

[llimllib]

tbf, I (as a person with some very basic haskell understanding) can more or less read the parent's code, but can't make heads or tails out of yours.

"Convoluted and redundant" is in the eye of the beholder I guess

[chowells]

Is it?

There's no part of you that looks and that and wonders why it's stuffing return into every leaf of a branching structure instead of just leaving it at the root? That's just objectively redundant.

And there's no part of you that's wondering why it's using nested branches to implement the railway oriented programming pattern? That's just objectively more convoluted than using the combinators that abstract that out and coalesce all the failure branches into one spot.

My second version has an extra really nice property. It consists of three subexpressions that can be understood in totality in isolation from the rest of the code. It is compositional code of the sort we all claim we want to work with.

What my code does have as a real downside is a much higher burden of knowledge to understand. You have to know much more of the contents of the base library. You have to be familiar with how idioms like the aforementioned railway oriented programming work.

But that knowledge has its rewards. You get to reduce manual plumbing in your own code, replacing it with standard library plumbing. When you know Haskell, the standard plumbing fades into the background. I guess it's like what lispers talk about with their parenthesis.

So yes, there is an additional burden in understanding my versions of the code. But that burden amortizes very nicely over a lifetime of getting the advantages of having all that plumbing just there when you need it.

[marcosdumay]

Yes, Haskell is the one language where you can always invest some more time learning something more advanced that will provide you a large boom in productivity.

That has the downside that Haskell developers speak many different idioms, just like Lisp. I'm prone to claim that the code you posted is basic enough that we can consider that people that don't get it are not proficient on the language yet, but there are way too many things right on the fence for that, and they can't all be required.

[llimllib]

> So yes, there is an additional burden in understanding my versions of the code. But that burden amortizes very nicely over a lifetime of getting the advantages of having all that plumbing just there when you need it.

I definitely didn't argue this point (although I admit to skepticism).

It sounds like you're actually aware that it's easier to read the redundant code when you are not an expert, so we don't have any disagreement there.

[chowells]

> It sounds like you're actually aware that it's easier to read the redundant code when you are not an expert, so we don't have any disagreement there.

Actually, there is minor disagreement. I don't think I used anything requiring expert-level understanding. I would put the tools I used at the level of day-to-day proficiency, not expert level. Roughly, the level it took me 3 months to reach, not the level I'm still working towards after 10 years.

[mrkeen]

If you've wandered in from another language and are wondering what it might look like in a less terse language, here's an attempt:

    static IO<Integer> getSocketApiPort(@NotNull final Integer defaultPort) {
      return lookupEnv("socketPort")
        .flatMap((Optional<String> maybeEnvPort) -> {
          if(!maybeEnvPort.isPresent()) {
            return IO.of(defaultPort);
          } else {
            String strEnvPort = maybeEnvPort.get();
            Optional<Integer> envPort = readMaybe(strEnvPort);
            return IO.of(envPort.orElse(defaultPort));
          }
        });
    }

[nemetroid]

It's some time since I last worked in Haskell (and I never worked on anything useful), but I would write the function this way:

  getSocketAPIPort :: Int -> IO Int
  getSocketAPIPort defaultPort = do
    maybeEnvPort <- lookupEnv "socketPort"
    return $ case maybeEnvPort of
      Nothing   -> defaultPort
      Just port -> fromMaybe defaultPort (readMaybe port)

[zeendo]

100% this is how I'd write it (except probably with pure instead of return). I don't get the desire to sprinkle bind throughout the other replies in this thread. I feel like it makes things less clear.

[hombre_fatal]

Though notice that you picked literally the most trivial example in the entire codebase that anyone can understand without explanation.

Elm is onto something with its obsession with simplicity and lack of features. I go back to old Haskell code and have to completely recredentialize in Haskell before I remember what's going on. I return to old Elm code and need very little ramp up.

I'm not making an "Elm > Haskell" argument, I just think experimentation with simplicity does this family of languages a favor.

[jscholes]

> Though notice that you picked literally the most trivial example in the entire codebase that anyone can understand without explanation.

I needed the explanation to understand what the code snippet was doing. Careful with those generalisations.

[hombre_fatal]

Well, non-programmers are even more helpless in understanding the code, but that's just not the point I'm making. Let's not require everyone to couch every statement in disclaimers, especially such an ancillary one.

And you surely can understand that code is trying to read a port or use a default one.

[jscholes]

> And you surely can understand that code is trying to read a port or use a default one.

In programming languages which use paradigms I'm more familiar with, yes. In Haskell, not so much, which is the entire point of this thread.

[KirinDave]

Weird, I thought the point of this thread was how to bikeshed looking up environment variables while folks look at the proverbial camera and appeal to the hypothetical audience that `if x == null: ` would surely be morally superior.

[hombre_fatal]

> In Haskell, not so much, which is the entire point of this thread.

Yes, that's my point, too. I'm not sure what you're arguing with.

That you don't understand even the most trivial snippet in the code base is only a point in my favor. You're picking beef with an irrelevant detail and confusing it for disagreement.

Remember, I was replying to someone who is trying to show that Haskell isn't so hard once you break down a snippet. I pointed out that the snippet was the most trivial selection they could have picked, that the rest of the code is even harder so it's not a very big consolation. You chimed in that even the simplest snippet was still alien to you.

[verttii]

On the other hand, Haskell's strength is its abstraction power. Elm intentionally lacks (some of) that punch, as do a lot of other languages.

But since Elm is a DSL it can afford to cap the abstraction somewhere whereas Haskell is perhaps built for more complex problems than just a client facing web UI.

Having learned both, I feel the abstraction level is capped too low on Elm, sadly.

[jecxjo]

Do you have a better example from this code base? I'm looking but unfortunately I'm not seeing anything that isn't either trivial or just a lot of monad stack handling.

[hombre_fatal]

Better examples of how Haskell can make the OP's eyes glaze over? Basically the rest of it.

[ArminCherusker]

monad transformers can help alot here:

  getSocketAPIPort :: Int -> IO Int
  getSocketAPIPort defaultPort =
    fromMaybe defaultPort <$> runMaybeT do
      envPort <- MaybeT $ lookupEnv "socketPort"
      MaybeT $ return $ readMaybe envPort

[empath75]

in python:

  def getSocketAPIPort(defaultport):
       try:
           return os.environ["socketPort"]
       except KeyError:
           return defaultport

[daenz]

Close, but values from os.environ are always string, and not guaranteed to be parsable numbers.

[icedchai]

This is a bit clearer:

    def getSocketAPIPort(defaultport): 
      return int(os.getenv('socketPort', defaultport))

[daenz]

Closer, but int can throw a ValueError. The original Haskell code defaulted to the defaultPort if the specified port could not be cast to an int.

[icedchai]

I see. Though I think it's better to throw an error. I wouldn't want my app just coming up on default port if I had configured it incorrectly.

[enobayram]

here's ho I'd write it:

    getSocketAPIPort :: Int -> IO Int
    getSocketAPIPort defaultPort = readWithDefault <$> lookupEnv "socketPort"
      where 
        readWithDefault mbPort = fromMaybe defaultPort $ readMaybe =<< mbPort

[enobayram]

Though I should add that it's in general against the Haskell spirit to write code against needlessly specific types and to combine unrelated functionality. So, I'd first look for a function or write one myself in some utils module that looks up and parses a value from an environment variable:

    readEnv :: Read a => String -> IO (Maybe a)
    readEnv var = (readMaybe =<<) <$> lookupEnv var

Then the function in question becomes much easier (and probably unnnecessary too):

    getSocketAPIPort defaultPort = fromMaybe defaultPort <$> readEnv "socketPort"

[AzzieElbab]

Haskell is not a difficult language to learn, but unlike imperative languages, you can't just start reading the code if you "know literally nothing about Haskell". One thing to keep in mind is that every other line in Haskell is basically just composing functions together, but you need to know how all those weird >>= and <*> and <$> effect code/composition flow

[preommr]

> is not a difficult language to learn

People say this about every single programming language.

[AzzieElbab]

dunno. to me PHP and CPP are the hardest, because I cant figure out the logic behind their design.

[6gvONxR4sf7o]

Some have genuinely uniquely confusing bits. Like `this` in javascript. Or `Hold` and `Evaluate` in mathematica.

[KirinDave]

Probably because they're all right.

[KirinDave]

> So, I know literally nothing about Haskell, and I would rate my knowledge of functional programming theory as 'beginner' at best, but I still get baffled every time when reading Haskell code that implements anything other than something trivial like a fibonacci sequence.

Then perhaps you should fix these before indicting the code?

Haskell isn't just a different language to learn because it's different, it's also a different language because it has a community that values math-driven models of things. As such, you're going to end up at a disadvantage trying to understand every aspect of it without any prior consideration.

Sorta like how templates often baffle new programmers but are considered absolutely essential by folks who get a year or three of C++ experience.

[anchpop]

I think part of the problem is that Haskell code can be very terse. When reading Python I expect to be able to easily understand what's going on in a 5 line function because the pythonic style limits what you can do in 5 lines. But in haskell a 5 line function can be pretty sophisticated.

[chucky_z]

Careful about sweeping generalizations... The internet has shown what is possible in "one line" of python, and I've seen this in the real world scarily enough!

[jakear]

What you can accomplish in 5 lines of “ready for production, maintainable, easily understandable by coworkers” python is vastly less than what you can accomplish in 5 lines of similarly constrained Haskell.

[thedufer]

Unfortunately, a lot of work there is done by the Haskell community having utterly absurd standards for those things. I work in a different functional programming language, and you would not believe the amount of time I spend convincing new hires with Haskell backgrounds to spend the extra few characters to expand out the unreadable point-free/single-character-names style that Haskell folks prefer.

[chowells]

Has it ever occurred to you that Haskell programmers prefer single-letter variable names in some contexts because it makes the code better? Perhaps it is not the children who are wrong.

[anchpop]

Right, I find pointfree style to be much more readable than pointful, I expect the GP would too if they became used to it

[thedufer]

I have spent quite a bit of time in both styles, and there's a pretty clear winner in my experience. I don't work in Haskell, but in another statically-typed FP language - maybe type classes are the feature that flip everything we know about readability from other languages?

[marcosdumay]

By the comment, the GP is not a Haskell developer and those people are not programming in Haskell.

So, even though it is well known that short named variables and point free syntax often improve the readability of Haskell code, it probably does not improve the readability of his code.

[jakear]

Oh believe me, I’d believe.

My Haskell background comes from building upon academic proofs of concept during a stint at CSAIL. Never again.

[KirinDave]

That world has very little to do with commerical Haskell though, now does it? Why, we even discourage the use of Singletons and if you import a unification library everyone will immediately demand to know why.

[elwell]

> Is it just me[?]

It's not just you, I came here to say the same thing. I just feel dumb when I try to read Haskell, though I've been using Clojure in production for over 5 years.

[friedbrice]

While I feel like writing Clojure for 5 years would improve one's ability to /write/ Haskell, I feel it'd have almost no impact on one's ability to read Haskell.

With all pros (e.g. local reasoning, referential transparency, no destructive updates) and all cons (e.g. tons of marshalling/converting, piles of imports, shitty records) aside for a moment, I think you learn to read Haskell like you learn to read any other programming language: by writing a lot of it.

[the_af]

It's not a good idea to try reading Haskell by "brute force", trying to figure it out as you go.

I suggest you first read through something that teaches you the basics like "Learn You a Haskell" or similar.

In a way, the experience is more like Clojure than Javascript. If you've read a Java-like language before, figuring another one tends to be easy. But if you've never read a Lisp-like, all the Java-like experience in the world won't help you to read a non-trivial Lisp program. You will just see some weird parentheses and won't be able to make head or tails of it.

Haskell is similar. Some upfront learning is needed before reading non-trivial programs.

[quickthrower2]

As someone who learned Haskell in their spare time: Yes you are correct sort of.

I'd say 50% of the reason it's hard to read is you are not familiar and 50 hours of learning Haskell would sort that out. Training your visual memory to get used to (f a b) rather than f(a,b) etc. I liked to add redundant parens in my play code just to help me with this.

The other 50% is those damn library authors and their love of funny operators and advanced GHC extensions. And also some people like to play code golf with "point-free" style where instead of the x -> f x you'd just use f.

Which if taken to the extreme produces hard to read code that is lovingly called "pointless".

Code golf in Haskell is rife. I really prefer longAndMeaningfulVariableNamesThatErrOnTheSideOfBeingTooLong, but the Haskell culture isn't that way, and they prefer names like: s'.

[6gvONxR4sf7o]

One problem is very generic tooling in Haskell. In many languages, you'll have a library that might provide a function like "iteratePokerGameStep." In the haskell community, the author is more likely to realize that this could just be implemented via "BiApplicativeProfuctorCategory.map." So instead of writing a 6 line "iteratePokerGameStep" which gets its own name, you're more likely to see someone just call "map." Much simpler code in some ways, much less simple in others.

[dllthomas]

If it's not obvious why someSuperGenericThing is thisSpecificThingINeed in this case, I'll often give it an appropriate name and more specific type locally. It helps the next reader (which, of course, might be me) and can also help keep type errors better localized. It takes noticing, though, to be sure.

[johnday]

This is very good style.

[KirinDave]

"BiApplicativeProfuctorCategory".

Please don't just make things up.