Inspired by Ollie Charles 24 days of Hackage, I decided to try my hand at writing a series of daily blog posts about my experience developing a web application in Haskell.
Why on earth am I doing that? From the set of programming languages I have not tried yet, there were two that I really wanted to try in a real project: Clojure and Haskell. I am in the process of wrapping up a client project I did with Clojure. I hope to write more about that. With Haskell, like with Clojure before, I mostly did small exercises, and a side project. The best way to learn a language is to do a project with it. That way you get all of the benefits and warts, and it gives more of a feel for what kinds of things the language, it libraries and community is most suitable for.
This series is called N days, and not 24 days, because I don’t know how many days I’m going to need.
More Why, for the project.
So I want to try Haskell for real. What benefits and pitfalls do I expect for this particular project. What project? At QWAN we have developed our own registration system for courses, that we want to roll out and sell to more people like us. We wanted something that we could easily on top of a simple static site or a wordpress blog, that respects the branding of our site, and that does not charge a percentage of our revenues.
Why? It looks like Haskell can do with a few more complete sample projects, warts and all, that people can use. I also hope to get some feedback on my choices and coding style, and maybe publish a little library for things that are not yet there in the eco-system (I was looking for something to support A/B testing and could not find it, for instance, other things are well covered however).
We started last year, and now I want to continue. I probably will spend a lot more time on this. I want to have fun, iterate fast, and be sure I make a reasonable choice for development and deployment. So I’ll evaluate one more option. If it fails, it’s back to Ruby, or perhaps forward in Clojure.
So what do I expect from Haskell?
Test interesting things, in interesting ways
I love TDD, and one of the basic tenets is ‘test everything that could possibly break’. I love TDD best when I can use it to drive a design, and every test gives me new insight about what I am trying to do. I find tests for correct routing and links not to be very insightful, and often the most useful of these tests are integration tests, running slowly against the whole application.
QuickCheck, a very powerful testing library I played around with, originates from Haskell. I want to try it out in a real project and see how it goes.
Performance and elegance
The Haskell community seems sufficiently performance obsessed, so I hope to marry elegance and performance. Some people believe they are opposites, I don’t. TDD and simple design have helped me do that before, and the small experiments I’ve done so far have shown me a good type system helps baby steps most of the time, and at other times forces you to step back and drive the design differently. Safety, speed and understandable design all come from the same source: thinking hard about what you are trying to do, and getting as much feedback from as many sources as you can and incorporate it in your work. Haskells’ type system is an additional source of feedback.
Out of our comfort zone
In our trainings we consistenly ask participants to go out of their comfort zone and learn new things. We should lead by example and do the same.
What am I going to start with?
Gabriel Gonzales wrote in [Introductions to advanced haskell topics]((http://www.haskellforall.com/2014/03/introductions-to-advanced-haskell-topics.html):
I wish people would spend more time diversifying coverage on more mundane topics, like how to apply well-established libraries to architect various types of applications.
I don’t know how to apply Yesod, being a well established library, to architect an application. I can show you how I, being a somewhat newbie Haskell programmer, go about it. So I hope fellow newbies might find this useful, and experienced Haskelites maybe rejoice in the Arrival of the idiots and get inspiration for the kind of things not yet covered in documentation.
Yesod Web Framework
I’m going to start with the Yesod framework. Normally in Ruby I would start most of the time with a micro-framework, because we know our way around the ecosystem. Sometimes I still use Rails, if the problem fits its model well. In Haskell, I don’t know my way around, and from what I’ve read so far, the Yesod maintainers have thought hard about the tradeoffs they make, and explain the trade-offs they made well. The Yesod Book. explains things simply, and where necessary explains where you need to look if you want something more complicated. They also show how you can use Yesods’ pieces in isolation, so you can combine them with something else. An open attitude that gives me confidence diving in.
What I like most is that they strive to use type-safety together with Don’t Repeat Yourself to eliminate the errors I commonly make, which should free up time for more interesting things, like solving business problems or spending time with my family.
I hope to reuse the domain model and validation logic that we write on the server-side on the client-side.
I’d rather sit with a client to see if the flow I come up with is understandable, than spend time writing end-to-end test automation to catch all the silly mistakes I made. I might stil write some, but I hope it is going to be less than before.
Where does the data go?
In the upcoming episodes I’m going to work as patiently as I can through the Yesod Book and start working on the multi-tenant contact form. I chose something with almost no domain model, so that we can pay attention to ‘non-functional’ aspects of the software and see how that works - things like authentication, authorization, cross-domain scripting, performance, persistence and last but not least, how fast we can iterate on an idea, ship and incorporate feedback.
I would love your feedback. I’m @mostalive on Twitter, the comment section is also open.