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. ;-)
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
