[Haskell-cafe] On the verge of ... giving up!

[Andrew Coppin]

David Stigant wrote:
> Haskell programs tend to be structured to restrict IO to the surface 
> level of the program, and use purely functional ideas to solve the 
> meat of the problem. This seems to be one of the major design features 
> of the language.

Yep, that's the idea. :-D

> However, most widely-used programs (ex: web browsers, word processors, 
> email programs, data bases, IDEs) tend to be 90% IO and 10% (or less) 
> computation. This can make Haskell quite unweildy for solving these 
> types of problems. On the otherhand, writing something like a compiler 
> (which requires a small amount of IO - read a file(s), write results 
> to a file - and a large amount of "unseen" computation - generating 
> and optimizing code) is right up Haskell's alley.

Au contrare... ;-)

Let us examine "web browser" for a moment. Yes, it does some input 
(typically fetching resources by HTTP), and some output (mainly 
displaying stuff on your screen). But wait a moment there... For a 
typical web page, you might well have to perform all of the following 
operations:

- Parse an XHTML file into a document tree. (That's pretty algorithmic.)
- Parse multiple CSS style sheets, and apply them to the document. (This 
involves processing possibly-complex element selectors, observing 
inheritance relationships, and merging the properties from several 
sources into a single result set. That's A LOT of algorithm!)
- Parse some JavaScript and execute it. (That's an entire programming 
language, remember.) Watch in horror is it uses the DOM to *modify* the 
XHTML data you just parsed and applied CSS to...
- Load several JPEG files. (You might think that "load a JPEG file" is 
I/O, but really, getting the data into memory is just the beginning. 
You've got a file to parse, you've got an arithmetic code to decompress, 
and then you've got an inverse Discrete Cosine Transform to do. Again, 
LOTS of algorithm.)
- Let us hope to God the page doesn't contain any SVG... (Think of the 
massacre!)
- Perform final layout (frames, tables, justification, backgrounds, 
transparency...) and rendering to incorporate all this data into one 
huge bitmap that can be dumped into the framebuffer.

OK, so if you wrote this program today, the JPEG part would probably be 
an external library. And SVG, if you supported it. But you get the 
point; there is A LOT of heavily algorithmic stuff happening there that 
has little or nothing to do with I/O. The browser is sucking in XHTML, 
CSS, JavaScript, JPEG, SVG and God only knows what else (XSLT, anyone?), 
doing a mountain of processing with it, and only then showing the final 
result on your computer screen. There's a lot more I/O than your typical 
compiler, but don't go thinking there's nothing algorithmic happening 
here. ;-)

Similarly, any good "word processor" is going to have layout algorithms 
(would you like that left-justified or right-justified? what happens if 
you have several typeface sizes in the same block of text? how does text 
flow round images?), and possibly cross-referencing. Email programs need 
to efficiently store and retrieve user's mail, and often have search 
facilities (and even Baysian filters for eliding spam). Even a humble 
IDE usually has syntax recognition...

So you see, they may not spend quite as much *time* on computation as a 
compiler does, but there's still plenty of *complexity* there. ;-)