New Year’s Resolutions: Produce, Believe

I bring you two personal experimental hypotheses for 2010.

I am a Haskell module author. Constituting my released modules are those ideas which resisted the least when I opened the text editor. But two of them, data-memocombinators and graphics-drawingcombinators have gained some popularity, and I am feeling rewarded having written them.

Most of my ideas functionalize pieces of Haskell programming that are currently imperatively-minded, as you can see with the two aforementioned. But FRP, a particularly greedy such idea has been stealing my tuits away from the others. I have envisaged functional command lines, package management, event handling, persistence, testing, and probably more that presently slip my mind. This brings me to my first new year’s resolution for 2010: Produce! It’s time to start coding these up instead of letting one very hard problem block the solution of moderately hard ones. Kicking off the year, I rewrote graphics-drawingcombinators to have a stronger semantic foundation, becoming version 1.0.0 (thanks Peaker and sinelaw for egging me on!).

My second resolution addresses an irrational fear I noticed a few days ago. The story begins with Hubris Arts, the game studio my friend Max and I started in July. We released our first game in November. We are in development on our second (codename “R4”) and prototyping our third (codename “Evo”). All of our development so far has been in C# with XNA, for a familiar reason: it was the path of least resistance. But as I prototype Evo I see all my beloved functional design patterns leaping out at me from between the lines of imperative blasphemy. So far the implementation seems a great fit for Haskell, but I am uneasy. Some part of me doesn’t believe that Haskell can do it. Haskell’s role in my life so far has been that of a language for beautiful koans and interesting experiments, but not for Real Software. But why not? My only evidence is my own fear.

Thus the second resolution: Believe in Haskell! I have decided to do Evo in Haskell. It is only by tackling Real Software that a language matures — it may not be ready now, but by doing it anyway, we will make it ready. If we can do it, that will be a wonderful success for the language, perhaps permanently parting us from C# von Neumann’s clutches. If we can’t, at least we’ll have reasons why not — ideas for things to improve — instead of unsupported uneasiness and unconfidence.


13 thoughts on “New Year’s Resolutions: Produce, Believe

  1. Would be interested in you keeping us up to date with how Evo goes – I’m trying to structure a largish game in Haskell as well right now, and having lots and lots of second thoughts on a daily basis, even having dived into it :/

  2. I agree wholeheartedly we your uneasiness. Good luck with Evo, and I look forward to hearing about your engineering experiences!

  3. Yeah I will be releasing all the support libraries I write along the way, probably writing about them too. We’ll have to keep the main game content secret though — open source games don’t make money. But if I’m a good engineer, most of the work will be in the libraries, so fellow Haskellers will benefit :-)

  4. Very nice post ! It’s really just about providing Haskell developers tools for more and more domains. Haskell really is a language in which you can do real world stuff. The only problem with some domains is that there are no tools / libraries written *yet* to ease the task. Let’s make my previous sentence wrong during 2010 :-)

  5. Just reading along your blog posts. Thanks for publishing them and all the best wishes for 2010. I’m very interested in learning how Haskell fares for game development.

  6. Interested in seeing how it goes for Haskell in game dev. For me just trying to visualize how it would look drives me insane. I have to many tools (habits) that are difficult for a functional world. The elegance of Haskell wants me to give it a shot.

  7. Rozgo, why not give it a shot then, eh? Worst comes to worst, you can do it imperative-style. The more the merrier…

  8. Hi Luke,

    I stumbled on this post by accident. As it turns out, it’s very relevant to me right now. I am in a somewhat unique position of being able to choose any language which will be used for developing commercial software, at least for the next three years. I have been seduced by Haskell and I really love its beauty. I am constantly torn between Haskell, Lisp and Erlang. Lately, it’s has been Haskell that is soaking up all my free time.

    As much as I love Haskell, I am seriously considering switching to Clojure. The main reason for abandoning Haskell is the lack of tools to do any real world work. Sure there are many fine examples of Haskell — GHC, XMonad, s/w from Galois etc. However, support for decent tools to work with web services and well-documented and functionally complete libraries are missing. I can’t afford to spend months of tool development before being able to work on the product.

    I fully understand that most of Haskell code is written by volunteers and I am expecting more than what is due. I suspect, it’s impossible to adopt Haskell for a real-world application when support for what’s considered standard fare is missing in Haskell offerings. That is a shame! Haskell has the potential to truly make my work fun.

    I look forward to reading your experience in using Haskell for a serious real-world application.

  9. I wonder whether that is justified, though. There are two that scare me about developing this game.

    1) Native libraries. And that’s just a sad state of affairs wrt. cross-platform availability for interactive graphics. There does not seem to be a windowing library for OpenGL that works out of the box on all platforms. That is one of the things we will contribute to the community when developing this game.

    2) Engineering techniques for purely functional games are largely unexplored. While it’s scary, this is extremely exciting for me. How often does one get to be a pioneer in even a small field of engineering?!

    The company I’m working for chose Scala over Haskell largely because of HBase — maybe my boss has other reasons, but from looking at the requirements I am pretty confident Haskell could pull it off with almost as little effort as Scala. Jetty is not that cool, and replicating the subset of functionality we need would be a walk in the park.

    So it comes down to whether we could have come up with reasonable HBase bindings for Haskell in our short time frame. And now that I see that our code ultimately uses the HBase bindings for about 20 lines, we probably could have. It might have been a pain, but HBase is not terribly high order — its usage patterns are local and predictable, it would not have cross-boundary garbage collection issues, etc. But it would have taken it from 20 lines to probably 200. In exchange for getting to use Haskell, it would be worth it to me. But when we started, it looked like it would be more effort, and now we are fairly committed to Scala.

    If we really love Haskell, we have to get over our fears of its immaturity. It is young but has great potential, and I believe it is more ready than we realize. I see the situation as analogous to good hiring practices: when you hire engineers, you look for problem-solving ability and adaptability — not knowledge of specific platforms or technologies. Haskell is a great engineer who hasn’t yet learned the latest trades. The training time may be a bit longer, but it pays off quickly — and the knowledge stays around for every future project.

    I urge you to take a second look at Haskell for your project.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s