Lambda the Ultimate

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.

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.

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".