3 ms·

I read through part of the "Learn you a Haskell" book that was posted here yesterday, and started getting really excited to use this beautiful language. And th

by _bxg1 8y ago

I read through part of the "Learn you a Haskell" book that was posted here yesterday, and started getting really excited to use this beautiful language. And then I started looking into ways to use it for making games and was... disappointed. Maybe I've been spoiled by the vibrancy of JavaScript's ecosystem, but I hoped to find a library for simply rendering existing meshes with existing materials and the closest I found was a library of base OpenGL hooks. Add onto that the lack of half-decent UI libraries (on the web you can use Elm, which is similar but different) and it feels like the only thing Haskell is practical for is headless data-processing, which is a shame.

marcosdumay 8y ago
My conclusion about using Haskell to make games and device drivers¹ is: don't. Even if the ecosystem changed and some great libraries appeared since I last tried, the language itself is a bad match for those domains. Lazyness is great everywhere, except when it works against you, and the garbage collector will assure you notice it. 1 - On my case, userspace drivers. I'm still open to userspace filesystems (I have on on my TODO list, if I ever get there), but device controlling implies on some harder real time requirements.
- _bxg1 8y ago
  I can see why it would be bad for drivers, but why games? Functional programming has started to become popular in that space lately, and for good reason
  - marshray 8y ago
    Games are all about keeping the user in the 'flow'. Humans are really good at picking up on unpredictable timing. Action games are thus fundamentally hard-real-time systems.
    - _bxg1 8y ago
      My thinking was to have a top game loop that "ticks", and then passes the current game state + the time delta to a pure function which returns the new game state, which gets stored. Is the concern that Haskell's lazy-evaluation might lead to a higher level of variance in frame-rate than another language?
      - marshray 8y ago
        Right. One technique used for writing games to run on GC'd runtimes is to avoid allocations entirely in the game loop. With a lot of work, you can preallocate everything you're going to need and just modify it as you run. This technique is not a good match for Haskell's primary design principle of avoiding mutable state.
        _bxg1 8y ago
        To be clear, I'm not aiming to build the next Call of Duty; these days you can get pretty far building a medium-sized 3D game out of unoptimized JavaScript running on a web page. The GC optimization you mention is interesting to learn of, but probably irrelevant for the kinds of things I would be doing. Does that change your assessment of Haskell for this purpose?
        marcosdumay 8y ago
        That depends on how large is your state. The GHC GC is normally fast, but gets slower the more objects you keep around. Lazyness can severely increase the number of such objects. If your game has real time dynamics, it's not worth it. If it's some turn-based one without animation, it's not a problem.
        _bxg1 8y ago
        Good to know, thanks for the info
        gilmi 8y ago
  - marcosdumay 8y ago
    Haskell state keeping is either fast or convenient, not both. Timing has several issues, not only GC pauses, but the entire functional paradigm was not created for real time. Lazyness adds up fast if you keep passing stuff through clock ticks. None of that is a showstopper. But I'd rather use a language that doesn't suffer from fundamental drawbacks on the domain I will work. That said, Haskell is very promising for AI. If I ever get to that game again, I'm writing the main loop in Rust with an asynchronous AI in Haskell.
  - platz 8y ago
    https://github.com/Gabriel439/post-rfc/blob/master/sotu.md https://github.com/Gabriel439/post-rfc/blob/master/sotu.md Game programming Rating: Immature > Haskell is a garbage collected language, so Haskell is more appropriate for the scripting / logic layer of a game but not suitable manipulating a large object graph or for implementing a high-performance game engine due to the risk of introducing perceptible pauses due to GC pauses. Also, for simple games you can realistically use Haskell for the entire stack.
wool_gather 8y ago
Not exactly games, but The Haskell School Of Expression by Paul Hudak is targeted at multimedia work in Haskell. I haven't read it, but if that's what you want to work on, it might be worth checking out.
- _bxg1 8y ago
  I'll check it out. Mainly what I'm interested in is doing world simulation in Haskell; it seems like it would be a really interesting language for that. But that kind of thing isn't very useful without a decent way to visualize and interact with it.
sridca 8y ago
You can use Haskell to do the things Elm does (and more, like deploying to mobile). Checkout reflex and obelisk: http://docs.reflex-frp.org/en/latest/ http://docs.reflex-frp.org/en/latest/ https://github.com/obsidiansystems/obelisk https://github.com/obsidiansystems/obelisk

by _bxg1 8y ago

marcosdumay 8y ago

My conclusion about using Haskell to make games and device drivers¹ is: don't. Even if the ecosystem changed and some great libraries appeared since I last tried, the language itself is a bad match for those domains. Lazyness is great everywhere, except when it works against you, and the garbage collector will assure you notice it. 1 - On my case, userspace drivers. I'm still open to userspace filesystems (I have on on my TODO list, if I ever get there), but device controlling implies on some harder real time requirements.

_bxg1 8y ago
I can see why it would be bad for drivers, but why games? Functional programming has started to become popular in that space lately, and for good reason
- marshray 8y ago
  Games are all about keeping the user in the 'flow'. Humans are really good at picking up on unpredictable timing. Action games are thus fundamentally hard-real-time systems.
  - _bxg1 8y ago
    My thinking was to have a top game loop that "ticks", and then passes the current game state + the time delta to a pure function which returns the new game state, which gets stored. Is the concern that Haskell's lazy-evaluation might lead to a higher level of variance in frame-rate than another language?
    - marshray 8y ago
      Right. One technique used for writing games to run on GC'd runtimes is to avoid allocations entirely in the game loop. With a lot of work, you can preallocate everything you're going to need and just modify it as you run. This technique is not a good match for Haskell's primary design principle of avoiding mutable state.
      - _bxg1 8y ago
        To be clear, I'm not aiming to build the next Call of Duty; these days you can get pretty far building a medium-sized 3D game out of unoptimized JavaScript running on a web page. The GC optimization you mention is interesting to learn of, but probably irrelevant for the kinds of things I would be doing. Does that change your assessment of Haskell for this purpose?
        marcosdumay 8y ago
        That depends on how large is your state. The GHC GC is normally fast, but gets slower the more objects you keep around. Lazyness can severely increase the number of such objects. If your game has real time dynamics, it's not worth it. If it's some turn-based one without animation, it's not a problem.
        _bxg1 8y ago
        Good to know, thanks for the info
        gilmi 8y ago
- marcosdumay 8y ago
  Haskell state keeping is either fast or convenient, not both. Timing has several issues, not only GC pauses, but the entire functional paradigm was not created for real time. Lazyness adds up fast if you keep passing stuff through clock ticks. None of that is a showstopper. But I'd rather use a language that doesn't suffer from fundamental drawbacks on the domain I will work. That said, Haskell is very promising for AI. If I ever get to that game again, I'm writing the main loop in Rust with an asynchronous AI in Haskell.
- platz 8y ago
  https://github.com/Gabriel439/post-rfc/blob/master/sotu.md https://github.com/Gabriel439/post-rfc/blob/master/sotu.md Game programming Rating: Immature > Haskell is a garbage collected language, so Haskell is more appropriate for the scripting / logic layer of a game but not suitable manipulating a large object graph or for implementing a high-performance game engine due to the risk of introducing perceptible pauses due to GC pauses. Also, for simple games you can realistically use Haskell for the entire stack.

wool_gather 8y ago

Not exactly games, but The Haskell School Of Expression by Paul Hudak is targeted at multimedia work in Haskell. I haven't read it, but if that's what you want to work on, it might be worth checking out.

_bxg1 8y ago
I'll check it out. Mainly what I'm interested in is doing world simulation in Haskell; it seems like it would be a really interesting language for that. But that kind of thing isn't very useful without a decent way to visualize and interact with it.

sridca 8y ago

You can use Haskell to do the things Elm does (and more, like deploying to mobile). Checkout reflex and obelisk: http://docs.reflex-frp.org/en/latest/ http://docs.reflex-frp.org/en/latest/ https://github.com/obsidiansystems/obelisk https://github.com/obsidiansystems/obelisk