|
 |
Haskell has a reputation [among people who've actually *heard* of it]
for being a bizarre, baffling and opaque language. Most people agree
that no sane human could possibly comprehend something so utterly weird
and confusing.
Which is strange, because to those of us that know it, Haskell is an
especially /simple/ language, which very directly allows you to express
what you want to say. Theories about its perceived "hardness" include
the unusual syntax, the unfamiliar mode of operation, the lack of good
documentation, the excessive amount of opaque mathematical jargon, or
possibly the ludicrous number of monad tutorials. I know Warp's
favourite theory is that people just don't "think functionally". But now
I've come up with my own suggestion:
Hypothesis: The Haskell language isn't hard. Typical Haskell *programs*
are hard.
Now what the heck do I mean by that? Well, to put it bluntly, Haskell is
an extraordinarily powerful language, so people tend to use it to solve
"hard" problems. It's not that there's anything hard about the Haskell
language itself. It's just that people only use Haskell to solve
problems that are hard to understand, using solutions that are even
harder to understand. After all, the /really cool thing/ about Haskell
is that you *can* solve hard problems with it.
To illustrate what I mean, consider a typical introductory Java
textbook. Such a thing will contain chapters about how to set up some
kind of Java compiler, the basic syntax rules of Java, how to create
variables, how to write loops, and so forth. It will probably have a
huge class reference at the back, because Java's standard class library
is frankly rococo. Throughout the text, you'll find little (and not so
little) code snippets which demonstrate one particular feature or idea.
But what actual /example programs/ might you find?
Obviously this varies by author, but typical programs will usually include:
- Hello world. (As required by RFC 2100.)
- What is your name?
- Guess which random number I just picked.
- My command-line arguments are...
- This is how you read and write files.
- Open a window containing every widget type and print a message every
time the user clicks something.
- A 4-function calculator. (Either CLI or GUI.)
- Tic Tac Toe.
- A simple client/server (so you can demonstrate network sockets).
- A simple program that runs in two threads.
- A simple program that runs in two threads and avoids race conditions.
- This is how you run SQL statements via ODBC.
- This is how you play media. (Sounds, pictures, video, etc.)
- One program that doesn't actually "do" anything, but implements an
insanely complex class hierarchy just so the authors can demonstrate
ever OO feature of Java ALL AT ONCE!
- Possibly a bad knock-off of MS Paint.
In other words, the example programs cover specific tasks line running
SQL or loading graphics or making network connections, and then a few
very simple things like Tic Tac Toe that take these elements and make a
minimally "useful" program out of them. Hey, it /is/ an introductory
book, right?
What might a typical introductory Haskell textbook contain? Well, there
aren't actually many of those in print. There's a surprising number of
books that assume that you /already know/ Haskell and use it as the
vehicle for implementing stuff. But there aren't many books that aim to
/teach/ you Haskell.
If you manage to find one, though, typical introductory programs might
include:
- The factorial function, the Fibonacci numbers, Pascal's triangle, the
prime numbers...
- A skeleton implementation of a self-balancing binary search tree.
- A small parser combinator library.
- A simple shell-style interpreter for the SKI combinator calculus.
- A domain-specific language for specifying search predicates.
- Hello World (in an advanced chapter, after you've finished learning
the monadic identities).
- A simple web server (so we can show how easy concurrency is).
- An implementation of the Barnes-Hut N-body simulation algorithm (so we
can show off Haskell's trippy parallelism support).
- A solution to the Santa Claus problem (showcasing Haskell's software
transactional memory).
Now take a step back for a moment and just look at that list. These
items are all very, *very* CS-heavy. I defy you to find me an
introductory Java textbook that teaches you how to build a
self-balancing binary search tree. Most Java programmers would retort
"the library already *has* a perfectly good BST implementation; why
write another?" Of course, writing a real, usable library isn't the
point; /enlightenment/ is the point. The difference, it appears, is that
Java programmers think that implementing a BST is pointless and silly,
while Haskell programmers think this is "instructive" and "interesting".
In short, the languages make different assumptions. Java seems to think
that you're either building enterprisey DB front-ends (either desktop
applications, browser applets or server-side HTML generators) or
scripting DVD menu pages. Haskell, on the other hand, seems to fully
expect you to be designing a compiler or something.
In case you think my example page above is exaggerated, let's see what
example code is contained in Real World Haskell, an actual book actually
published by O'Reilly, an actual publisher. The book contains:
- A Haskell to JSON conversion library. (Includes a small
text-formatting library as a component.)
- A function to translate glob patterns into (POSIX) regular expressions.
- A domain-specific language for expressing file search predicates,
together with an engine that searches the file system for matches.
- Build a trivial parser monad and use it to parse the PGM file format.
(I.e., write a program that loads PGM images.)
- A program that loads a PPM image of a barcode, and decodes the digits
of the barcode. (EAN-13 barcodes only.)
- A program to parse /etc/passwd and allow interactive username lookups.
- Half a dozen small Parsec examples, parsing CSV files, JSON, HTTP
headers, etc.
- A library implementing a bloom filter.
How many Java textbooks teach you how to read barcodes?
Post a reply to this message
|
|
