[Haskell-cafe] Announcement - HGamer3D - 0.2.1 - why netwire

Peter Althainz althainz at gmail.com
Fri Mar 22 20:13:08 CET 2013


Peter Althainz wrote:

> Dear All,
>
> I'm happy to announce release 0.2.1 of HGamer3D, the game engine with
> Haskell API, featuring FRP based API and FRP based GUI. The new FRP API
> is based on the netwire package. Currently only available on Windows:
> http://www.hgamer3d.org.

Nice work!

Of course, I have to ask: what influenced your choice of FRP library in
favor of  netwire  instead of  reactive-banana ?


Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com




Hi Heinrich

good question, actually I need to thank you for your excellent tutorials
on FRP and GUI on the WEB. I tried the version of reactive-banana
without switches as the first FRP framework to have contact with and I
liked its simplicity and the cool introduction around Excel cells you gave on the Web.
HGamer3D is my personal way to get more insight into FP and Haskell
especially and from the beginning I wanted to have a FRP API to try it
with game examples. So your intro on FRP and the examples were very
helpful with that.

After reading a lot on the web it became clear, that currently
reactive-banana and netwire are good candidates to start with. So why in
the end I decided to use netwire for the binding?

It's some personal things and I do not claim to have done a proper
evaluation or comparison. I also cannot judge on performance or other
relevant topics. Having said that, I can give you some points why I choosed netwire:
- The cool simplicity of reactive-banana API seems to have suffered a
little bit after the introduction of the switch functionality.
- After getting around Monads and Applicative by great help of "Learning
a Haskell for great good" I was shocked to see, there is even more to
learn, when I detected Arrows. So I started to look at it and discovered
some nice tutorials for Arrows.
- What struck me was introduction of netwire author Ertugrul Söylemez on
Arrows and the explanations of local state, which can be kept into an
arrow. Since I was also curious on OOP and FP and game state handling,
actually this raised some interest. So I think this "Arrows keep local
state" argument was the killer feature. But also behaviours keep
local state and maybe I got misguided here.
- I then did some trials with netwire and I felt it's a quite
comprehensive and nice API, so I got started with that.

regards

Peter




More information about the Haskell-Cafe mailing list