Home

Haskell web store

Until yesterday, I wasn't aware of any web stores implemented in Haskell. Most users of languages like Haskell and ML tend to be focused on other kinds of applications. This sometimes leads to discussions about the "real-world suitability" of these languages, which we've occasionally seen here on LtU.

The next time the subject comes up, it will be possible to point to a real, complete web store written in Haskell, which was announced on Haskell-Cafe back in April. The store is Braintree Hemp, and the code behind it was written by Adam Peacock. It's an impressive program, written in a little over 4200 lines of Haskell, sporting the following features:

  • Written in Haskell, using WASH
  • Shopping basket and checkout
  • Google Maps
  • Google Analytics
  • Google Webmaster tools
  • Template Haskell for HaskellDB description (describe a table or a field in one line)
  • GPL, execpt where stated otherwise.
  • Heavyweight Content Management System (CMS)
  • Froogle RSS generator
  • Configurable help for each page
  • Concept of inventory levels
  • Concept of users and permissions
  • Naive-user management of products, users, and page content
  • XML import tool and wizard for inventory level reconciliation
    between warehouse and site database

Why did I write the site in Haskell? First, I was ask to fix the site
that was selling products they didn't have in stock. Once I looked at
the source code, 25000 lines of ASP, I reckoned it would be easier to
rewrite it in a real language. Second, I couldn't find any commercial
sites written in Haskell, and I thought this would be a good chance.

The new site has considerably more functionality and is a little over
4200 lines of Haskell. The original site could only display and sell
products, without consideration of whether any were currently in
stock. Furthermore, the site content could only be maintained by an
expert user.

Read the announcement for additional details, including a link to the source code (note: source code is a slightly older than that running on the live site).

By Anton van Straaten at 2007-06-28 21:51 | Functional | other blogs | 25204 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

What's the big deal?

While I don't doubt the suitability of Haskell for real-world application development (given the right tools and libraries), rewriting a badly written 25,000 line ASP application from scratch to use fewer lines of code is an extremely minor achievement.

There are dozens of languages people are using to develop much larger pieces of software, and I just don't see why someone writing a trivial web-application in Haskell is worth mentioning on the front page of this site.

By cdiggins at Thu, 2007-06-28 23:15 | login or register to post comments

Relevance

The point is very few people have actually written such an application in Haskell. In fact, this is the only example I'm aware of that's actually running as a live, commercial site. Claiming that such applications can be written effectively in a language is nowhere near as convincing as pointing to an example.

Also, the feature list is significantly more complete than is often the case for these kinds of systems when done as demos. Papers have been written about tackling awkward real-world issues in Haskell, which is one of the purest of the functional languages. This application deals with many such issues in a business context that's familiar to many programmers in mainstream languages. See e.g. the discussion of Haskell for C programmers.

As mentioned in the story, part of the relevance of this is as an example to use in the kinds of discussions that arise here, and elsewhere, from time to time.

By Anton van Straaten at Thu, 2007-06-28 23:39 | login or register to post comments

Because only a tiny fraction of people know it's possible

I work with very smart and knowledgable people who think that purely functional programming is nothing but an academic exercise and that a trivial demonstration of this is that you can't perform I/O in a purely functional programming language. I think it's worth spreading the message that you can actually do stuff in the real world with such a language, even if it's something as trivial as ecommerce.

There have been many arguments about why purely functional programming is an unsuitable paradigm for a wide variety of tasks. At the very least, we'll now be able to abbreviate those arguments by providing this as a counterexample. So I think this post serves the valuable purpose of allowing us to focus on the aspects of purely functional programming that really might make it unsuitable for some tasks.

By sigfpe at Thu, 2007-06-28 23:45 | login or register to post comments

Ouch

... even if it's something as trivial as ecommerce.

By Koray Can at Fri, 2007-06-29 01:03 | login or register to post comments

It was intended with irony...

'cos of the tone of the parent post :-)

By sigfpe at Fri, 2007-06-29 01:15 | login or register to post comments

Hmmm....

Based on what you say, I'm not convinced that the people you work with are truly very smart and knowledgeable. Very smart, perhaps.

By Michael Vanier at Fri, 2007-07-06 00:17 | login or register to post comments

Too Generous

I'm not willing to ascribe the property of "very smart" to anyone who says, in seriousness, that purely functional programs can't do I/O!

By Paul Snively at Fri, 2007-07-06 01:51 | login or register to post comments

Smart != knowledgeable...

...about any particular domain of knowledge.

By neelk at Fri, 2007-07-06 02:51 | login or register to post comments

Can they?

I'm not willing to ascribe the property of "very smart" to anyone who says, in seriousness, that purely functional programs can't do I/O!

But of course they cannot. They can just compute requests for I/O, and pray that their (impure!) runtime will respect these requests.

One could of course argue that the same reasoning applies to imperative programs as well, so I may be completely wrong here...

By Andris Birkmanis at Fri, 2007-07-06 15:32 | login or register to post comments

Perpetual Null Hypothesis

Smart people can also think that impure functional programming, which passes their I/O test, adds no value. This strikes me as the most common null hypothesis. They don't need to assume FP in any form is unsuitable for non-academic tasks, just that it's no better.

Real world examples may help skew the opinion from totally useless academic exercise to just no better. But, to reject the hypothesis once and for all, we'll need real scientific trials. We don't do that sort of thing often or well in this discipline.

By Koray Can at Fri, 2007-07-06 18:07 | login or register to post comments

in this form, it might be counter-productive

Declaring "hey, look, we are relevant" is somewhat counter-productive.
An well-dosed imperative like "use Haskell for web now !" may work much better, if supported by the right marketing machinery. Haskell yet has to find somebody that writes like why on hackety.org, I doubt it will happen. Focusing on technical matters in an academic style is not such a bad thing, anyway.

By Burak Emir at Sat, 2007-06-30 15:47 | login or register to post comments

sign of things to come

This story is a sign of things to come (or that are arriving).

I don't think this is just a story about haskell code being more compact than a less functional (pun intended) ASP version. Rather, it's a story about smart application of high-level programming techniques to collapse a few big layers of an application stack.

In this case, the top layers of the application stack formerly went something like web-server under asp run-time under visual basic under the original 25,000 LOCs of domain-specific code. The web server abstracts away protocols. The ASP run-time abstracts away client-side differences and adds a bus for language bindings. VB provides a canonical language binding. And only then, finally, do we get to our application code.

The new stack seems to go something like: web-server under domain-specific code.

That collapse is enabled partly because the client-side has settled out a bit since ASP was invented, and partly because the API ASP offered "up the stack" to domain specific code was, in order to manage its own internal complexities, more limiting than it had to be and more limiting than desirable. And, of course, it was enabled by haskell becoming ever more a production language and haskell programmers ever more numerous and more skilled.

In other threads on LtU we've seen the support beams of other parts of the application stack starting to shake and buckle. At the very low end, work like trickles gets us closer and closer to more-or-less solid-state IP stacks. In the middle, Pardu Linux at least begins to show practically (what is conceptually obvious) that, with fresh programming using higher level abstractions, the layers between OS kernel and web server can collapse.

It's easy to imagine, if money were no object, that we could engineer this fine web store even more radically: as kind of mostly-solid-state network appliace whose network-stack, os, HTTP protocol implementation, and domain-specific code is so compact and simple that it can run on hyper-cheap hardware (e.g., do we need much memory? do we need VM and/or process protection?

Building such hardware probably won't be the goal for quite a long time -- we can't currently fabricate cheap hardware cheaply except in very large quantities and with a large ramp-up investment. Yet, virtualizing systems designed to run on such hardware may very well be quite practical, in the near term, as a substitute for things like virtualizing Linux hosts.

Such radical simplification -- especially around highly portable standard components like haskell and the various web standards in play -- can be a huge win for hosting providers, application developers, and application customers (who buy and combine hosting and application development). It can significantly lower hosting costs measured in hardware costs, energy costs, and administrative costs. It can significantly lower development costs by encouraging an ecology of simple, standard, re-usable parts. For customers, it leads sharply away from lock-in and regular upgrades and towards the possibility of "set it and forget it" service creation.

In short, when we look at the world of computing as being comprised of lots and lots of software stacks, separately deployed -- when we take that "holistic" view of software systems -- then it seems clear that radical simplification is possible, desirable, in some sense necessary, in some sense inevitable, and in some sense: at hand.

This isn't a time for LTU-ers to turn their noses up and say "A small web store? Pshaw -- who cares!" Rather, research that makes these radical stack simplifications reliably repeatable, with known-up-front costs and back-end pay-offs is Where It's At[*].

-t

[*] Well, it's one of several "Where"s where "It" is "At".

By Thomas Lord at Sun, 2007-07-01 18:37 | login or register to post comments

This isn't a time for

This isn't a time for LTU-ers to turn their noses up and say "A small web store? Pshaw -- who cares!"

I tend to agree. In fact, I think this was always the case: you can't push the state of the art from the sidelines.

By Ehud Lamm at Sun, 2007-07-01 18:55 | login or register to post comments

a moment of silence for radical simplification

I would like to have lived a life where I only worked with things that had already gone through "radical simplification". Or, worked with folks who at least considered such goals worthwhile and thought about it when evaluating decisions. Instead I'm surrounded with reams of complicated cruft (*cough-anything-to-do-with-Java-cough*).

By raould at Fri, 2007-07-06 23:51 | login or register to post comments

Binary choice

As Tony Hoare famously wrote:

There are two ways to construct a piece of software: One is to make it so simple that there are obviously no errors, and the other is to make it so complicated that there are no obvious errors.

By Allan McInnes at Sat, 2007-07-07 21:31 | login or register to post comments

Must not be talking about GUI code

I see so much complicated code that when run creates a GUI that takes no more than 10 or 30 seconds to reveal how utterly bad it is. :-}

By raould at Mon, 2007-07-09 18:58 | login or register to post comments