No seriously, before you get like a million users you should switch to a much slower hashing alg that's designed for passwords, not for checksums. Scrypt is good, bcrypt is good, and there are a few others. But here's a(n?) scrypt package on Haskell that will do it for you and has a really nicely designed API: http://hackage.haskell.org/packages/archive/scrypt/0.3.1/doc...
It comes down to this: Why use something which is designed for speed like hashes to do something that can be broken by highspeed guessing?
Perhaps you have hundreds of millions of users? The slower your hash algorithm the more resources it takes to run it.
2800M/s SHA1 hashes on a ATI HD 7970.
PBKDF2 is still very much harder to crack then SHA1 with any reasonable length of salt.
While you may use better passwords than this, it's certain that some of your users do not.
Is that true? Wouldn't that mean that typical Haskell applications aren't very modular, if every module needs access to all types? How can this be a good thing?
[I'm not good with Haskell; I sort of like it, but it makes me feel rather unintelligent.]
I'm not sure the author's explained this point quite as clearly as it could have been. One doesn't want to expose every type used in the program across all modules: there are many that are just used in internal representations within particular modules.
Here's an example from a project of mine, which is a command line program to produce truth tables. There's a Core module which contains the types shared across the whole program, and the most fundamental operations on them.
Then there are other modules like Parser which just exposes a single function, but of course makes use of the core types.
The command line program itself is defined as a Main module, which imports the pure library modules and does all the I/O. It has a few types of its own but these aren't shared across the program, because the library doesn't need to know about all this stuff.
Isn't this enough? You learn something and you'll probably get something useful out of it in the end, as well.
Huh? How do those even compare?
That sounds a bit snarky; it just seems like purity/impurity is the favorite bikeshed for haskell programmers.
Sometimes people like to write about their pleasant experience before the project is completely finished. I'm bookmarking the project as a good example of Cabal Project structuring and use of some network libraries. Good examples like these aren't very well curated from the universal Haskell repertoire.
Since it's an internal effort, simplicity trumps security and features. I doubt making the IRC server more complete would be worth the effort and maintenance cost. It's much better to add features only of they are obviously missing when they actually use the server.
It's his project, he calls the shots. If you want a feature, get in and write it. Being Right On The Internet doesn't mean shit.
Or you can use any of the thousand services running IRC servers ;-)