Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: I built a poker site with Haskell

github.com

Post reply on HN
Print view View original

101–110 of 121 posts

Re: Show HN: I built a poker site with Haskell

#101

Post by KirinDave »

icedchai wrote: post #100
KirinDave wrote: post #93

Earlier quoted context omitted.

It might be in Python, but it's sorta oranges to apples for you to just not do the same thing your Rosetta code is supposed to do. What's the value of your exercise if you just redefine the problem to get rid of the tricky part?

I’d say the original code was wrong. anyway catching an exception isn’t tricky.

If it's easy then why did you fail twice at even making a valid python expression?

When we talk about the oppressive nature of Python culture—how the "there is only one way to do it" culture leaks out of the place where it's applicable and starts to be focused on other communities that have different requirements—we think of examples like this. "Your code in a language I don't now or use is wrong."

Over focusing on how the example code polls the environment is the least interesting thing you could hyperfocus on. What's more, I think it's a bit more normal to use something like optparse-applicative, which leads to inevitable complaints about using infix operators that every Haskell novice knows but that armchair Haskell programmers hem and haw about asking, "is this too many operators?"

Re: Show HN: I built a poker site with Haskell

#102

Post by icedchai »

KirinDave wrote: post #101
icedchai wrote: post #100

Earlier quoted context omitted.

I’d say the original code was wrong. anyway catching an exception isn’t tricky.

If it's easy then why did you fail twice at even making a valid python expression? When we talk about the oppressive nature of Python culture—how the "there is only one way to do it" culture leaks out of the place where it's applicable and starts to be focused on other communities that have different requirements—we think of examples like this. "Your code in a language I don't now or use is wrong." Over focusing on h…

I only answered once. The other code was from another guy.

Re: Show HN: I built a poker site with Haskell

#103

Post by KirinDave »

icedchai wrote: post #102
KirinDave wrote: post #101

Earlier quoted context omitted.

If it's easy then why did you fail twice at even making a valid python expression? When we talk about the oppressive nature of Python culture—how the "there is only one way to do it" culture leaks out of the place where it's applicable and starts to be focused on other communities that have different requirements—we think of examples like this. "Your code in a language I don't now or use is wrong." Over focusing on h…

I only answered once. The other code was from another guy.

Okay, my apologies. I accept the correction.

Do you want to respond to the rest or just let it stand?

Re: Show HN: I built a poker site with Haskell

#104

Post by icedchai »

KirinDave wrote: post #103
icedchai wrote: post #102

Earlier quoted context omitted.

I only answered once. The other code was from another guy.

Okay, my apologies. I accept the correction. Do you want to respond to the rest or just let it stand?

I'm going to take another look at Haskell first.

Re: Show HN: I built a poker site with Haskell

#106

Post by dllthomas »

anchpop wrote: post #52
chowells wrote: post #47

Earlier quoted context omitted.

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.

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

IME, this isn't consistent. If you can write it as `f . g . h` then point-free will probably be clearest. If you need to use each argument in a few places, I find going all the way to point-free is usually much less clear than some intermediate points or even the fully pointful version.

Re: Show HN: I built a poker site with Haskell

#107

Post by dllthomas »

6gvONxR4sf7o wrote: post #82
w0utert wrote: post #2

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…

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." M…

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.

Re: Show HN: I built a poker site with Haskell

#108

Post by enobayram »

daenz wrote: post #8
w0utert wrote: post #2

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…

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 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. Co…

here's ho I'd write it:

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

Re: Show HN: I built a poker site with Haskell

#109

Post by enobayram »

enobayram wrote: post #108
daenz wrote: post #8

Earlier quoted context omitted.

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 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. Co…

here's ho I'd write it: getSocketAPIPort :: Int -> IO Int getSocketAPIPort defaultPort = readWithDefault lookupEnv "socketPort" where readWithDefault mbPort = fromMaybe defaultPort $ readMaybe =

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"

Re: Show HN: I built a poker site with Haskell

#110

Post by johnday »

dllthomas wrote: post #107
6gvONxR4sf7o wrote: post #82

Earlier quoted context omitted.

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." M…

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.

This is very good style.
Post reply on HN