Announcing The Pragmatic Haskeller

We are working programmers. Even though we are carried away by the beauty and formalism of functional languages, at the end of the day we still need to get the job done. The Haskell community has been accused during the years of navel gazing, and usually the misconception is that “Haskell is an academic language, but you can’t tackle real world problem with it”.

Despite internet is full of fantastic resources for learning Haskell (including the awesome and recently-released School of Haskell) I wanted to use a peculiar approach: I tried to create a web application in a similar fashion of what I would have done during my everyday job in Scala, to see if I was able to replicate a large subset of the features normally present in my Scala apps. Not only was the experiment a success, but I finally had the chance of experimenting with a lot of cool libraries which were in my “to-play-with-list” for a while. So without further ado I’m happy to announce The Pragmatic Haskeller, a collection of small building blocks for creating a full-fledged webapp:

As you might notice, we have a lot of small subfolders. Each folder is a self-contained, working, incremental example experimenting with a new library or technique. Even though you could rush and play with each app all at once, I aim to write a dedicated blog post to each sub-project, introducing the used library, in a similar way of what Oliver Charles did with 24 days of Hackage, with the difference we’ll use the same example episode after episode, until transforming our naive bunch of modules into a complete app.

The Pragmatic Bakery

We couldn’t be Cake Solutions without a bakery, so here we go! What we’ll accomplish, at the end of this journey, is create a small DSL to create recipes, which will be serialised into Haskell records and finally encoded to JSON. Eager to see how the final product will look like? You can take a peek to this live demo, which is hosted on my Amazon Micro Tier:

It uses Snap under the hook, along with a couple of other cool libraries. It’s still a bit rough under the corner, but it should work pretty well. Try to click the red button, and voilà, you get some JSON back! And we have also some naive syntax checking (try to remove a quote from a string!)

Final note

Well, I hope this will be enough to whet your appetite! Each subfolder should work,but I’ll refactor each example when a new episode will be published, so feel free to submit pull requests or bug report, because I’m pretty sure to have broken something along the way (small example, I was using my custom fork of snaplet-mongodb-minimalistic but now my patch got merged so I need to refactor the code to reflect the fact we’ll use the hackage version). I think that’s all for now, I hope you will enjoy your baking!


This entry was posted in Alfredo's Blog and tagged , . Bookmark the permalink.

6 Responses to Announcing The Pragmatic Haskeller

  1. Robert says:

    The biggest drawback for Haskell is the very steep learning curve.
    You have to take multiple shots at it, and multiple time-off periods, before you get anywhere.

    The number of proficient Haskell programmers is always going to be quite tiny.

  2. Roger says:

    Robert, you say that like it’s a bad thing. ;)

    For a long time everyone said the same thing sorts of things about Object Orientation. It was too academic. Nobody was going to use it in the “real world.” Then one day, everyone did. Monads are no more difficult to learn than polymorphism. It’s not a question of difficulty, it’s a question of familiarity. And if there are problems that can’t be solved in imperative languages, programmers will pick up FP, simply because they will have to in order to stay employed.

    The three biggest obstacles to Haskell adoption, as I see it, are

    1) The ecosystem — the Github README mentions “cabal hell,” which is itself a byproduct of Haskell’s non-existent Application Binary Interface and its tendency to aggressively optimize its existing libraries against what’s currently installed. When you pull down a new library, any number of your current libraries may need to be recompiled on the fly against the new one. The resulting instability more or less prevents Haskell programs from growing beyond a certain size.

    2) Laziness — When you get deep into Haskell development, you end up needing to profile a lot because of space leaks and just plain difficult-to-predict performance. On the flip side, Haskell developers have a lot of great profiling tools at their disposal. But it will be a while before you see Haskell used for performance-critical apps like 3d first-person shooters.

    3) Opportunity cost — For a while, it looked like concurrency and parallelism would be Haskell’s big selling points. They are still big wins if you look at something like STM versus just about any example in the book “Java Concurrency in Practice.” But plain old Java has acquired some tools that shrink the distance between itself and FP solutions like Haskell and Scala. So suddenly the cost of moving to something like Haskell looks that much steeper. Companies that use Haskell have not yet demonstrated sufficient increase in productivity to convince managers to adopt it.

    Alfredo, thank you very much for this. I’ve played around with Yesod, but I’ve been thinking of moving over to Snap because Yesod relies a bit too much on Template Haskell for my tastes. This repo can act as my tutorial. Thanks again!

  3. This is a great idea, and we appreciate your linking to School of Haskell. Have you considered posting any of this to SoH? Active code is very hands-on for the reader, and I’d be happy to help if you hit any snags.

  4. Alfredo Di Napoli says:

    Wow, it’s an honor to receive a comment from you guys, your work in spreading Haskell to the world is just awesome, and I’m a big fun of yours :) Chad, your idea is indeed a good one, my only concern would be the following. I remember the introductory video of SOH by Bartosz, which told us that the code gets compiled to a remote machine and the output gets back to the user’s machine. Obviously most of this episode will rely on Hackage libraries. Whilst some packages are “famous” like aeson,snap,etc others are niche one or created in-house (the aeson-bson one, a mod of an existing package). So there is the risk that not every package could be available on the cloud machine for the compilation, resulting in a “no-go” in terms of interactivity for the final user. How does SOH deal with that?

    Thanks again for the feedback!

  5. Roger,
    Have you seen this?

    Our server uses Stackage for libraries.

    Michael Snoyman’s original announvement:

    Adding libraries to Stackage:

  6. Alfredo Di Napoli says:

    Ah Stackage, of course. I’ve seen Michael’s announcement on the day one, never used it “in the wild”, and this seems a good chance to do it :)
    Thanks for the precious info, I didn’t realise Stackage could be used to install libraries for SOH, that’s neat :)


Leave a Reply